监控指标

监控系统指标

监控已然成为了整个产品生命周期非常重要的一环，运维关注硬件和基础监控，研发关注各类中间件和应用层的监控，产品关注核心业务指标的监控。可见，监控的对象已经越来越立体化。在系统的质量保障中，我们常常希望能实现所谓的立体化监控，实时感知，提前预警。但是越全面，成本越高。所以，根据所处的时期从中挑选合适的监控方式更加重要。本节即着重讨论我们在搭建监控体系时候的指标考量。

指标的划分

对于监控指标，我们可以有很多种的划分方式。其一即根据目标来划分，将其分为系统指标、程序指标、业务指标等。

系统指标主要是网络IO、网络延迟、磁盘IO、磁盘占用大小、CPU使用率、内存使用率、交换分区等等。
程序指标除了和系统指标一样的CPU使用率、内存使用率这种外部表现的指标之外，还有应用程序错误数、应用程序请求量、应用平均响应时间这种内部表现的指标；对于程序指标的落地我们常常就会徘徊于侵入式与非侵入式两种。
业务指标即每一个业务会经过的关键状态，都可以作为业务指标来监控。但是由于业务指标往往不具有通用性，所以，需要手动在程序里埋点打桩。因此，对业务指标的监控必然是侵入性的。

无论业务系统如何复杂，监控指标如何眼花缭乱，但万变不离其宗，监控的目的无非是为了解服务运行状况、发现服务故障和帮助定位故障原因。为了达成这个目的，Google SRE总结的监控四个黄金指标对我们添加监控具有非常重要的指导意义。

其中，吞吐量（Throughout）与时延（Latency）是衡量软件系统的最常见的两个指标，系统的吞度量（承压能力）与请求对CPU的消耗、外部接口、IO等等紧密关联；单个请求对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。吞吐量与时延是天生矛盾的，吞吐量增加也就意味着同一时间请求并发的增加；而由于资源的限制，同一时刻可以处理的请求数是固定的，取决于整个请求处理过程中最小的那个环节。当并发请求数大于这个值时，就会有请求排队等待被处理。所以，要提升服务的吞吐量，必定会增加整体延迟。另外，如果服务的延迟（单个请求的耗时）减少，由于排队的请求的等待时间也减少了，所以吞吐量会上升。

Logging，Metrics和Tracing

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

Logging：用于记录离散的事件。例如，应用程序的调试信息或错误信息。它是我们诊断问题的依据。
Metrics：用于记录可聚合的数据。例如，队列的当前深度可被定义为一个度量值，在元素入队或出队时被更新；HTTP请求个数可被定义为一个计数器，新请求到来时进行累加。
Tracing：用于记录请求范围内的信息。例如，一次远程方法调用的执行过程和耗时。它是我们排查系统性能问题的利器。

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

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

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

指标枚举

硬件监控

包括：电源状态、CPU状态、机器温度、风扇状态、物理磁盘、raid状态、内存状态、网卡状态。

服务器基础监控

CPU：单个CPU以及整体的使用情况
内存：已用内存、可用内存
磁盘：磁盘使用率、磁盘读写的吞吐量
网络：出口流量、入口流量、TCP连接状态

数据库监控

包括：数据库连接数、QPS、TPS、并行处理的会话数、缓存命中率、主从延时、锁状态、慢查询

中间件监控

Nginx：活跃连接数、等待连接数、丢弃连接数、请求量、耗时、5XX错误率
Tomcat：最大线程数、当前线程数、请求量、耗时、错误量、堆内存使用情况、GC次数和耗时
缓存：成功连接数、阻塞连接数、已使用内存、内存碎片率、请求量、耗时、缓存命中率
消息队列：连接数、队列数、生产速率、消费速率、消息堆积量

应用监控

HTTP接口：URL存活、请求量、耗时、异常量
RPC接口：请求量、耗时、超时量、拒绝量
JVM：GC次数、GC耗时、各个内存区域的大小、当前线程数、死锁线程数
线程池：活跃线程数、任务队列大小、任务执行耗时、拒绝任务数
连接池：总连接数、活跃连接数
日志监控：访问日志、错误日志
业务指标：视业务来定，比如PV、订单量等