1、业务监控

这类指标是管理层非常关注的，代表企业营收，或者跟客户主流程相关，类似 BI 数据。不过相比 BI 数据，业务监控指标有两点不同。

• 对精确度要求没有那么高：因为监控只要发现趋势异常就可以，至于是从 5000 变成了 1000 还是变成了 1001，没有什么区别。
• 对实时性要求很高：很多 BI 数据可能是小时级别或天级别的，这个时效性无法满足监控的需求，监控是希望越早发现问题越好，要是一个小时才发现问题，黄花菜都凉了。

技术人员应该针对这类指标做高优保障，如果所有的指标都同等对待，重要的告警就容易被普通告警淹没，所以告警一定要分级对待。

在微服务和云原生技术盛行的当下，某个机器的 CPU 飙高了，或者 IO 打满了，对最终用户的体验可能是没有任何影响的，但是核心业务指标异常，一定是故障，因为这类指标异常代表着最终用户体验受损，或者造成了直接资损。

2、应用监控

应用监控就是指对应用程序（Application）的监控，Google 的四个黄金指标、RED 方法主要就是针对应用监控的。

每个公司都应该有统一的 APM（Application Performance Management），也就是应用性能管理方案，从指标着手的话一般使用埋点机制来做，比如 StatsD、Prometheus SDK 等，或者直接分析接入层日志，从日志提取指标；从链路追踪着手的话可以使用 Zipkin、SkyWalking 等。

像 Java 这种字节码技术的语言，采用 JavaAgent 技术可以做到代码无侵入埋点。但是像 Go、C++ 这类语言，一般都是采用埋点机制来做，由统一的工具团队提供一些框架，在框架里内置埋点逻辑，这样普通研发人员也就基本不会有代码侵入的感觉了。

3、组件监控

把各类数据库、中间件、云平台，统称为组件，组件监控是非常考验知识广度的。一般监控系统的研发人员，很难把每个组件的机理都搞清楚，所以定义统一的接入数据规范，让专业的人去采集各个组件的数据是更合理的做法。

有个好现象是，很多组件的研发人员，已经开始让组件自身直接支持 Prometheus 协议，吐出 metrics 数据，除了 etcd、Kubernetes 这些云原生时代的组件，一些老的组件，比如 RabbitMQ、ZooKeeper 等，也在新版本里直接做了支持。

4、资源监控

基础资源的监控，主要是针对设备和网络，设备又分为服务器、网络设备，网络监控又分为连通性监控、质量监控、流量监控。

5、设备监控

一提起设备监控，你可能立马会想到 CPU、内存使用率监控，除了这些之外，如果我们想获取硬件模块的健康状况，比如电源电压、风扇转速、主板环境温度等，就需要走 IPMI 协议，通过带外网络采集。

网络设备，典型的就是交换机、防火墙，一般是通过 SNMP 协议获取指标，比如交换机各个网口的流量、包量。也可以通过 syslog 的方式，把交换机的日志转存出来，到服务器上分析。

6、网络监控

网络连通性监控最为常见，通过 ICMP 协议，部署探针机器，对目标设备做 PING 探测，能探通就表示能连通，探测失败就是连不通。当然，有些机器可能是禁 PING 的，此时就需要用 TCP 或 HTTP 之类的协议去探测了。

PING 探测可以拿到丢包率和延迟数据，我们可以用这些数据分析网络质量。比如两个机房之间的专线，我们用 A 机房的探针去探测 B 机房的目的设备，就能轻易知道机房之间的网络质量情况。

最后是流量监控，也会用在多个地方，比如机器的网卡流量、交换机的网口流量、机房出口流量，也是整个监控体系的重要一环。