关于构建监控系统的一点感想（一）：监控什么

我与监控的缘分

可能真的是与监控这个事情挺有缘分的，从第一份工作的第一个项目开始，就跟监控有关系。
一开始是做ELK，用于数据收集和分析的，后来就利用各种beat和logstash的一些能力尝试做系统监控；后来又配合过另外一位同事基于Zabbix改造公司的监控系统，再后来简单的做过基于Promethues对k8s进行监控；最近一段时间又开始带着构建部门的监控系统，回头一看，发现我工作四年多一点，竟然一共做了4次跟监控相关的事情。
但是每一次做的形式和收获都有一点不太一样。

监控的目的

其实做监控系统的目的很简单，就是了解被监控的对象的运行情况，看它是不是能正常工作。

说是这么说，但是真正在实施的过程中，很多人都走偏了。

比如对一个后端服务进行监控，很多人做监控的人，尤其是纯粹的运维出身的人，很可能第一反应就是监控CPU、内存、磁盘和网络这些指标。这么做也不能说是错的，事实上，网络上现在和监控相关的资料大部分也都是教我们怎么去监控这些指标， 但是思路可能要换一下。

这里推荐去了解一下谷歌和微软关于监控的维度的内容，或者读一下《SRE Google运维解密》中关于监控的章节，非常不错，里面很明白的讲清楚了该怎么做监控系统。

我不想在这里照搬书里面的内容，就按照自己的经验记录下来。

我比较推荐的在监控系统应该关注的维度有三个：

• 可用性： 就是看一个系统的功能还能不能用，比如监控一个网站的登录功能
• 延迟： 监控请求的耗时
• 流量： 这里的流量指的是系统的并发，比如同时有多少人登录到一个系统

前面说面的监控CPU那些其实可以看做是“原因”。 比如我们通过监控发现延迟变得很高，那很可能是网络带宽被占满了，然后通过网络监控发现带宽确实被占满了；又或者是我们发现系统部分功能变得不可用或者是响应很慢，然后通过监控CPU发现服务器的CPU被吃满了。后面的都是前面的原因。

我们应该着重于监控上面的三个指标，然后在这些指标出现问题的时候再去找原因，这个时候对于CPU、内存的监控可能就是可以帮助进行排查。

本末倒置

现在想想刚开始做的监控系统有一点本末倒置。

那个时候监控系统会对接公司的工单平台，每当监控系统产生一个告警的时候都会顺带产生一个工单。

比如，对某一台服务器的内存进行监控，当利用率达到85%发生告警并产生一个工单。这个时候就要去处理这个工单，要去排查为什么内存的利用率会达到85%。一台服务器的内存达到85%很多可能的原因，也许是真的发生了故障了，也许就是触发了代码里面某一个场景消耗了很多内存，也许使用系统的人变多了等等，这是很难查到具体原因的，更何况每天都会产生几十个工单，到后来接工单的同事甚至为了应对这一类工单都发明了一个回复模板，每次就照着这个模板填写，也不管是不是真的有问题了。