监控体系

监控与告警体系

在系统运维一章中我们就已经讨论了独立 Linux 服务器中简单的系统指标的获取与分析,本篇着重讨论复杂分布式系统下基于度量的监控解决方案,广义的监控往往还会涉及日志聚合与分布式追踪等。

黑盒监控与白盒监控

传统上,如果组织中有 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 命令。

Logging,Metrics 和 Tracing

笔者在 DevOps 中的设计的三个关键方面即是:Logging,Metrics 和 Tracing,分别对应着日志聚合、监控与告警以及分布式追踪。Logging,Metrics 和 Tracing 有各自专注的部分:

  • Logging:用于记录离散的事件。例如,应用程序的调试信息或错误信息。它是我们诊断问题的依据。

  • Metrics:用于记录可聚合的数据。例如,队列的当前深度可被定义为一个度量值,在元素入队或出队时被更新;HTTP 请求个数可被定义为一个计数器,新请求到来时进行累加。

  • Tracing:用于记录请求范围内的信息。例如,一次远程方法调用的执行过程和耗时。它是我们排查系统性能问题的利器。

Logging, Metrics, Tracing 三者同异

通过上述信息,我们可以对已有系统进行分类。例如,Zipkin 专注于 tracing 领域;Prometheus 开始专注于 metrics,随着时间推移可能会集成更多的 tracing 功能,但不太可能深入 logging 领域; ELK,阿里云日志服务这样的系统开始专注于 logging 领域,但同时也不断地集成其他领域的特性到系统中来,正向上图中的圆心靠近。

度量作为时序数据,是跨时间间隔的可聚合和测量的数字。度量针对存储和数据处理进行了优化,因为它们只是一段时间内聚合的数字。基于度量的监控的一个优点是度量生成和存储的开销是恒定的,它不像基于日志的监控那样,与系统负载的增加成正比,随之改变。这意味着磁盘和处理利用率不会根据流量的增加而改变。磁盘存储利用率仅根据时序数据库上存储的数据而增加,当你在应用程序代码中添加新指标或启动新服务/容器/主机时,才会发生这种情况。

度量比查询和聚合日志数据更有效。但是日志可以提供准确的数据,如果你想获得服务器响应时间的准确平均值,你可以记录它们,然后在 ELK 上编写聚合查询。度量不是百分之百准确,而是使用一些统计算法。类似 Prometheus 和常见的度量客户端这些工具实现了一些高级算法,以便为我们提供最准确的数字。

链接