监控哪些指标，一般是研发拍脑袋决定，要么是指标太多抓不住重点，给监控系统和运维人员带来很大压力。 要么是遗漏关键指标，不能提前感知异常，或在故障出现时提供线索。

面试时偶尔会问的一道题，候选人对某服务进行监控的话要考虑哪些指标。希望听到的回答，不仅全面，而且有体系，但是答案通常都杂乱无章、想一个是一个。

分享下个人的总结。

对象

• 系统监控
• Linux 系统状态，包括软件、硬件，例如CPU、内存、Raid卡、温度等
• 进程监控
• 进程状态，例如进程状态，进程Crash事件、JVM FULL GC次数和耗时，JVM 各类堆栈大小等。
• 这里的进程，不一定绝对是进程，而是进程脱离具体业务的指标，例如nginx 丢弃连接数，框架例如tomcat会暴露出与业务无关的指标。
• 业务监控
• 和具体业务相关
• 例如 各类http 请求占比、耗时

系统监控，一般系统运维会做好。不过在云上，这块细节变少，至少没有那么多硬件要监控。 业务监控的角度一般不会漏，但是进程监控角度常常被忽略，或者也是因为两者界限不是很强。 是“进程”还是“业务”，具体情况具体分析，例如一个基础服务，那么它的一些基础指标就是业务，例如Redis集群。

黄金指标

• 延迟（请求处理时间、响应时间）
  • 服务器处理某个请求所需要的时间
  • 剔除非正常请求（限流、错误请求）以免误导，既然要剔除，那就也需要监控
  • 例如 http 请求时间99值
• 流量（请求qps、带宽速率、io速率、iops）
• 针对系统负载锁所进行度量的指标
• 错误
• 单位时间内的失败量。
• 不仅包含协议层面的，例如http 500，也包含业务层面的，例如登录失败。
• 饱和度
• 针对系统内~~最为~~受限资源的度量指标
• 可以是系统层面的，例如磁盘容量、带宽容量，也可以是业务层面的，例如并发拉流数，并发在线人数。
• 书里面针对饱和度有“最为”2个字，但是我认为“最为”是比较难以衡量的，对于一个负载的系统来说，受限的资源方方面面，不同场景下触发的上限可能不同。这里的指标，我认为其实只是一种角度，我们要做的只是需要针对饱和度进行设置监控指标。

延迟这个指标非常有用，除了发现异常，还可用于预报异常（饱含度），，当延迟变高，往往以为接近性能拐点，饱含度异常。 延迟指标还可用于性能监控，例如更新版本之后，延迟（http 响应时间99值）的变化。 所以，不要忘记针对延迟设计监控。

参考：《Google SRE 第六章》#The Four Golden Signals

示例

某Nginx 静态文件服务，按以上角度，设置的部分指标。

对象

• 系统监控
• CPU 利用率、磁盘占有率、带宽、全连接队列、半连接队列等
• 进程监控
• Nginx status模块暴露的指标：丢弃连接数、并发连接数

Active connections: 291
server accepts handled requests
16630948 16630948 31070465
Reading: 6 Writing: 179 Waiting: 106    

• nginx error.log
• 业务监控
• 访问日志分析，状态码、响应时间等

黄金指标

• 延迟
• 2xx 请求响应时间99值
• 流量
• 当前活跃连接数，http 请求qps
• 当前机器带宽
• 错误
• 5xx 请求qps，该服务下一般不会出现
• 404 请求qps，可能意味着文件同步失败
• nginx 拒绝连接数
• 周期检测error.log 新日志
• 饱和度
• 磁盘容量，静态文件较多
• 当前活跃连接数，距离nginx 设置的最大连接数