聊聊监控

简述

工作中经常发现这样一个问题，大多数开发人员只专注于开发，对于系统的整体架构缺乏系统性的认知，特别是监控体系。我也问过很多开发人员，一部分人觉得监控是运维的事情，写好业务代码就行；也有一部分人一开始就没有这种全局的意识，对监控了解的少之甚少

基于这种情况，我打算写几篇关于监控的文章，跟大家分享一些监控的知识。因为我觉得服务监控不只是运维的工作，开发人员也应该了解一些服务监控的知识。除了能让我们站在全局的角度考虑问题外，还能帮助我们排查线上的一些问题，而且监控也是软件架构的重要一环，一个合格的开发人员，应该对监控系统有所了解

监控的分类

监控可以分为以下四类：业务监控、应用监控、组件监控、资源监控业务监控：业务监控指的是对业务指标的监控，不同业务系统关注的业务指标不一样。比如电商业务关注的是订单量，直播业务关注的可能是直播在线观看人数。业务监控有点类似于 BI 报表，不过业务监控于 BI 报表有两点不同

对精确度要求不高，业务监控只要发现业务异常即可，对精确度没有硬性要求，BI 报表则不同，BI 报表要求数据很精确
实时性要求高，业务监控要求很高的实时性，因为业务异常一般会直接影响用户体验，或者造成直接损失，所以要求很强的实时性，即使发现业务异常。BI 报表一般是小时/天级别的

应用监控：应用监控指对应用程序的监控，监控应用的各项运行指标，如果是 Java 程序，监控的就是 JVM 的堆栈等信息，正常的公司都应该有统一的应用性能管理方案，统一对应用性能进行监控

组件监控：我们统一把对各种数据库、中间件、云平台组件的监控统称为组件监控的范畴。组件监控需要我们对组件的各项指标都有很深的了解，比如对 redis 跟 kafka 的监控，虽然都是组件监控，但监控的指标不一样，redis 我们可能关注更多的是缓存的命中率，kafka 关注的是消息的堆积程度，leader 分区数量等

资源监控：基础资源的监控，主要分两种：设备监控跟网络监控，设备监控可以理解为对服务器的监控，比如 CPU、内存使用率等的监控。网络监控一般是对网络带宽、网络流量等网络信息的监控，如果网络流量激增，导致带宽不够用，我们可能考虑对带宽进行扩容等

需要对什么指标进行监控

我们知道，不同组件或服务的指标都不一样，我们很难用一套统一的方法对所有的组件/服务进行监控，那么有什么方法能指导我们需要对什么指标进行监控呢？这就不得不提到 Google 对监控提出的四个黄金指标（The Four Golden Signals）
The Four Golden Signals 主要针对的是应用监控，强调我们应该对以下四个指标进行监控：

延迟：服务请求所花费的时间，如某个接口的请求时间。需要注意的一点是，这里需要区分成功请求和失败请求，因为失败请求响应时间可能很短（比如接口报错或者熔断），把失败请求一起统计进去，不能客观反映接口的延迟
流量：对于 HTTP 服务来说，流量就是每秒的 HTTP 请求数。RPC 服务就是每秒的 RPC 请求数，对于数据库来说，流量就是每秒的事物数
错误：请求失败的速率，即每秒有多少个失败请求，对于 HTTP 服务来说，接口返回 500 错误码就证明接口请求失败
饱和度：描述系统有多“满”，比如 CPU 负载，网络带宽使用量等指标可以作为饱和度指标