- 《架构师》2019年11月
- InfoQ中文站
- 910字
- 2020-06-26 06:06:51
监控
我之前从来没想过监控也会归自己管。坦白讲,在接受全职编码职位之前,我从来不管系统维护这些事。我只是构建系统,用上一个礼拜,然后再换一套系统。
现在,我日常使用的是两套系统,其中一套拥有良好的监控机制,另一套的监管机制则比较差。通过实际体验,我感受到了监控的重要意义。毕竟如果意识到问题,我又怎么能解决问题呢?最差的情况,就是连客户都发现bug了,我自己还蒙在鼓里。“我在做什么?!我连自己的系统出了问题都不知道?”
我认为监控机制主要包含三大组件——日志记录、指标与警报。
日志记录以代码的形式存在,类似于人类记录,这是一种渐进的过程。
我们可以找到需要监控的内容,记录这些内容,同时运行系统。随着时间的推移,我们可能会发现自己缺少某些解决bug所需要的信息。这正是调整日志记录的好机会——我们忘了记录哪些重要的内容?
我认为,最重要就是直观地理解哪些内容值得进行记录。作为我的观察对象,他(标题中的高级软件工程师)和我在记录服务方面的想法有着很大的不同。我认为记录请求-响应就足够了,但他却列出了很多指标,比如查询执行时间、代码中的一些特定内部调用以及何时轮换日志等等。
很明显,如果没有日志记录作为参考,我们几乎不可能进行任何调试工作——如果我们不清楚系统的当前状态,重建系统自然也就成了痴人说梦。
指标可以从日志当中提取,也可以在代码当中单独建立。(例如将事件发送至AWS CloudWatch以及Grafana)。大家可以自行设定指标,并在代码运行时发出对应的数字。
警报则是将所有内容整合在优秀监控系统中的重要粘合剂。如果某项指标代表着当前正处于生产状态的机器数量,那么这个数字下降到50%则代表着一种严重警报——肯定是出了什么大问题。
失败计数超过栽个阈值?又会有新警报给我们发出提醒。
这样我就能安心睡觉了,因为我很清楚即使出了什么问题,系统也会马上提醒我~对吧……
而这中间又隐藏着另一种重要的习惯。在修复bug时,我们不应单纯关注如何解决问题,而是为什么我们没能早点发现?警报有没有及时提醒?如何更好地设置监控以防止出现类似的问题?
我到现在也没弄明白如何监控UI。目前的组件选项还无法了解问题究竟来自哪里。而且,仍有相当一部分问题是由客户上报过来的——这里头肯定还有提升空间。