监控

我之前从来没想过监控也会归自己管。坦白讲，在接受全职编码职位之前，我从来不管系统维护这些事。我只是构建系统，用上一个礼拜，然后再换一套系统。

现在，我日常使用的是两套系统，其中一套拥有良好的监控机制，另一套的监管机制则比较差。通过实际体验，我感受到了监控的重要意义。毕竟如果意识到问题，我又怎么能解决问题呢？最差的情况，就是连客户都发现bug了，我自己还蒙在鼓里。“我在做什么？！我连自己的系统出了问题都不知道？”

我认为监控机制主要包含三大组件——日志记录、指标与警报。

日志记录以代码的形式存在，类似于人类记录，这是一种渐进的过程。

我们可以找到需要监控的内容，记录这些内容，同时运行系统。随着时间的推移，我们可能会发现自己缺少某些解决bug所需要的信息。这正是调整日志记录的好机会——我们忘了记录哪些重要的内容？

我认为，最重要就是直观地理解哪些内容值得进行记录。作为我的观察对象，他（标题中的高级软件工程师）和我在记录服务方面的想法有着很大的不同。我认为记录请求-响应就足够了，但他却列出了很多指标，比如查询执行时间、代码中的一些特定内部调用以及何时轮换日志等等。

很明显，如果没有日志记录作为参考，我们几乎不可能进行任何调试工作——如果我们不清楚系统的当前状态，重建系统自然也就成了痴人说梦。

指标可以从日志当中提取，也可以在代码当中单独建立。（例如将事件发送至AWS CloudWatch以及Grafana）。大家可以自行设定指标，并在代码运行时发出对应的数字。

警报则是将所有内容整合在优秀监控系统中的重要粘合剂。如果某项指标代表着当前正处于生产状态的机器数量，那么这个数字下降到50%则代表着一种严重警报——肯定是出了什么大问题。

失败计数超过栽个阈值？又会有新警报给我们发出提醒。

这样我就能安心睡觉了，因为我很清楚即使出了什么问题，系统也会马上提醒我～对吧……

而这中间又隐藏着另一种重要的习惯。在修复bug时，我们不应单纯关注如何解决问题，而是为什么我们没能早点发现？警报有没有及时提醒？如何更好地设置监控以防止出现类似的问题？

我到现在也没弄明白如何监控UI。目前的组件选项还无法了解问题究竟来自哪里。而且，仍有相当一部分问题是由客户上报过来的——这里头肯定还有提升空间。