监控告警

本部分主要着眼于服务端系统的监控与告警，前端相关的监控体系建设请参考 Web Series。

目的与方法

正所谓无监控，不运维，监控系统的地位不言而喻。不管你是监控系统的开发者还是使用者，首先肯定要清楚：监控系统的目标是什么？它能发挥什么作用？

• 实时采集监控数据：包括硬件、操作系统、中间件、应用程序等各个维度的数据。
• 实时反馈监控状态：通过对采集的数据进行多维度统计和可视化展示，能实时体现监控对象的状态是正常还是异常。
• 预知故障和告警：能够提前预知故障风险，并及时发出告警信息。
• 辅助定位故障：提供故障发生时的各项指标数据，辅助故障分析和定位。
• 辅助性能调优：为性能调优提供数据支持，比如慢SQL，接口响应时间等。
• 辅助容量规划：为服务器、中间件以及应用集群的容量规划提供数据支撑。
• 辅助自动化运维：为自动扩容或者根据配置的SLA进行服务降级等智能运维提供数据支撑。

可见光有一套好的监控系统还不够，还必须知道如何用好它。一个成熟的研发团队通常会定一个监控规范，用来统一监控系统的使用方法。

• 了解监控对象的工作原理：要做到对监控对象有基本的了解，清楚它的工作原理。比如想对JVM进行监控，你必须清楚JVM的堆内存结构和垃圾回收机制。
• 确定监控对象的指标：清楚使用哪些指标来刻画监控对象的状态？比如想对某个接口进行监控，可以采用请求量、耗时、超时量、异常量等指标来衡量。
• 定义合理的报警阈值和等级：达到什么阈值需要告警？对应的故障等级是多少？不需要处理的告警不是好告警，可见定义合理的阈值有多重要，否则只会降低运维效率或者让监控系统失去它的作用。
• 建立完善的故障处理流程：收到故障告警后，一定要有相应的处理流程和oncall机制，让故障及时被跟进处理。

黑盒监控与白盒监控

传统上，如果组织中有IT运维部门，可能会有人使用Nagios等工具进行黑盒监控。这个工具给你一些信号，如系统停机、服务器/服务停机、CPU消耗高等。这是必须的，非常有利于识别问题的症状，但没法知道根本原因。

一旦你得到的症状告诉你有什么不对劲。你需要深入了解并理解根本原因。这个时候需要用到白盒监控。白盒监控可以帮助你确定问题的根本原因，更重要的是，如果设计正确，可以通过查看系统上的某些趋势，对于可能出现的可预防问题，为你提供主动告警。因为应用程序的内部可以提供更有价值和可操作的告警，使得对边界场景和类似性能问题采取行动时更加主动，并在问题发生之前采取行动。

白盒监控还包括日志记录、度量和分布式跟踪，它们指的是一类使用系统内部报告的数据的监控工具和技术。我想写一下白盒监控范围内可观察性的这三个支柱。当正确使用这些工具时，通常你可能就不需要进行黑盒监控了，但如果你问我，继续进行黑盒监控当然很好。

白盒与黑盒分别从内部和外部来监控系统的运行状况，例如机器存活、CPU内存使用率、业务日志、JMX等监控都属于白盒监控，而外部端口探活、HTTP探测以及端到端功能监控等则属于黑盒监控的范畴。

• 日志：日志可以包含服务运行的方方面面，是重要的监控数据来源。例如，通过Nginx access日志可以统计出错误（5xx）、延迟（响应时间）和流量，结合已知的容量上限就可以计算出饱和度。一般除监控系统提供的日志采集插件外，如Rsyslog、Logstash、Filebeat、Flume等都是比较优秀的日志采集软件。

• JMX：多数Java开发的服务均可由JMX接口输出监控指标。不少监控系统也有集成JMX采集插件，除此之外我们也可通过jmxtrans、jmxcmd工具进行采集。

• REST：提供REST API来进行监控数据的采集，如Hadoop、ElasticSearch。

• OpenMetrics：得益于Prometheus的流行，作为Prometheus的监控数据采集方案，OpenMetrics可能很快会成为未来监控的业界标准。目前绝大部分热门开源服务均有官方或非官方的exporter可供使用。

• 命令行：一些服务提供本地的命令来输出监控指标。

• 主动上报：对于采用PUSH模型的监控系统来说，服务可以采取主动上报的方式把监控指标push到监控系统，如Java服务可使用Metrics接口自定义sink输出。另外，运维也可以使用自定义的监控插件来完成监控的采集。

• 埋点：埋点是侵入式的监控数据采集方式，其优点是其可以更灵活地为我们提供业务内部的监控指标，当然缺点也很明显：需要在代码层面动手脚（常常需要研发支持，成本较高）。

• 其它方式：以上未涵盖的监控指标采集方式，例如Zookeeper的四字命令，MySQL的show status命令。

Links

• https://mp.weixin.qq.com/s/uk0qKcmlHwlCeC_zJhWgow 我经历过的监控系统演进史