监控杂谈

“监控”这事情，一说谁都能有一个概念，大概就是“看某个服务是否正常”。落到执行的时候，那就看某个服务比较重要，就做一个监控算法，出事的时候告警通知就完了。但面对分布式架构的服务而言，监控复杂程度就上升好几个层次，简单想到哪里监控哪里显然不合适。我们开发组其实也做了不少监控指标，即使梳理过服务功能的优先级，但还是觉得不全，而且告警通知也无法较好地定位具体问题，逻辑存在监控漏报也是存在，每次告警还需要研发逐层跟进。

开发周期中的角色，从产品、研发、测试、运营、运维都有各种套路，以研发为例，设计模式就是其中经典的套路。监控这一工作有点尴尬，首先我没有听过“监控工程师”这专业职位；也没有看过专门介绍监控理论的书籍，拿开发的书或运维的书，也鲜有提到监控这技能。

感觉监控是一个被忽视的领域，不过再想一下，监控好像不算一类专业技能，是一种通用技能，不管职场生活还是男女老幼多少都会涉及到（比如说产品经理需要监控用户行为，秘书需要留意老板行为，女的要监控男的私房钱状况等）。而且某些角度看，监控也许是做事的一个层次，以开发登录这功能为例，第一层次就是会把功能实现了，用户能登录成功就完事了；第二层次就是会罗列各种异常路径并捕获处理，比如用户不合法、某些服务不可用处理、甚至还要加验证码防暴力破解等；第三就是监控，出了问题可以不需要用户反馈，甚至可以根据趋势预知问题，第一时间做出响应……后面还有更高层次，我就看不到了。

监控不只是运维的事，系统基本参数网络状态也许有运维可以代劳，但对于用户真正可用的服务来说，哪个位置最可能有毛病最需要监控，这就只有开发人员最清楚不过。自己的狗粮自己吃，如果研发发现自己的东西不好监控，那就说明代码实现欠缺可维护性，需要重构。

我想起了之前看过一本书《微服务设计》有一章说监控的讲得不错，一年多前看的，心里没装什么想法没啥实战没啥体会忘得差不多了，我重看了这一章并结合近期现实遇到的问题，得到一些总结供大家作为参考，希望以后可以形成套路。

监控杂谈

要跟踪 web api 的响应时间、请求量和错误码
每个web服务器日志都有记录，这些指标可以从整体看web站点的运行状况，另外也可以看出哪些api请求较多，说明是重点功能，后续可以做针对性优化。

跟踪所有下游服务健康状态，也是包括响应时间和错误率
我们要清楚服务所有下游依赖的健康状态，这个跟踪对错误定位非常有好处，特别是“级联”故障会更容易识别和定位。

不仅要对服务监控，还要设计“语义监控”
文中对语义监控的定义是，我们会根据业务或具体使用场景设计一些合成事务，使用这些事务来确保系统行为在语义上的正确性。比较绕，举个例子，比如登录功能。登录站点，依赖基础组建（如redis），也依赖各种服务（如ldap，第三方登录等），单独监控这些服务也许都是正常的，但真实用户还是可能登录异常，因为可能某个网络连接有异常，某个监控漏洞导致漏报等。因此要监控登录，最好还是模拟“登录”，这就是一个“语义”，针对这个“语义”进行监控。

标准化收集和存储指标
日志的内容，存放位置，监控接口等尽可能标准化，方便后续使用工具聚合以及维护、统计这些数据。这也是要求，在设计系统的初期最好就要考虑监控这一元素，否则肯定会有重构的一天。

使用关联标识跟踪横跨多个服务的调用
关联标识的好处是便于跟踪问题的时候，把整条调用链可以串起来。但要完美实现这个目标比较困难，需要保持一致性，在调用链上的服务都支持读取此标识，这一般来说做不到。因此实现这个关联标识要选择轻量级的方式传递，比如http里面的header。

容量规划
收集监控指标足够长时间，直到有清晰的模式浮现。了解这个趋势的好处就是帮助我们做容量规划。

工具
书中也提了一些工具，有时间可以去了解一下，现在我就只是百度了一下概念而已。
nagios：Nagios是一个监视系统运行状态和网络信息的监视系统。类似zabbix。
ssh-multiplexers：多个主机运行相同命令。
elk：收集日志的解决方案，包含了三个子系统。ElasticSearch，搜索引擎；logstash，日志收集工具；kibana，图形化搜索日志的系统。
graphite：一个Python写的web应用采用django框架，用来进行收集服务器所有的即时状态，用户请求信息。
zipkin，dapper：跨系统调用跟踪方案。
riemann：一个分布式的监控系统。可以接收各种event上报，然后通过强大的脚本和插件，展示曲线，柱状，饼图等来对系统进行监控。
suro：Netflix开源工具，可以收集来自多个应用服务器的事件数据，并实时定向发送到目标数据平台如Hadoop和Elasticsearch。