1.7k 字 18 分钟

监控不告警，系统就一定没有问题么？
怎样的监控，才真正说明系统有问题？

今天和大伙聊聊多维度立体化监控。

什么是多维度立体化监控

不同公司或多或少有一些自动化监控手段，例如：

  1. http 接口监控；
  2. log 关键字监控；
  3. 操作系统，进程，端口；
  4. http 状态码；
  5. 服务存活性；
  6. 接口处理时间；
  7. RPC 接口监控；
  8. 用户层面监控；

如果只监控一个或少数几个维度：

  1. 监控到异常时，基本确信系统出现了问题；
  2. 反过来，没有监控到异常，不能确信系统没有问题；

例如：

  1. 监控到操作系统 CPU100%，系统大概率出现了问题，但 CPU 正常，并不能说明系统正常，例如 tomcat 挂了，CPU 肯定是正常的，但操作系统监控却探测不到，于是需要进程，端口，存活性等其他监控予以辅助；
  2. 进程，端口监控到异常，系统大概率出现了问题，但进程在运行，端口在监听，并不能说明系统正常，例如程序死锁，进程和端口是正常的，于是需要接口处理时间等其他监控予以辅助；
  3. 接口处理时间监控到超时，系统大概率出现了问题，但接口处理时间不超时，并不能说明系统正常，例如数据库挂了，数据库连接拿不到，服务层每个接口都很快返回，并不超时；

这里的 观点 是： 单维度监控易漏报， 多维度立体化监控才是监控平台的根本之道。

前文介绍的两篇, 在设计上都讲究通用+可扩展：

接下来介绍的四个维度的监控，在设计上也是看重“ 通用 ”“ 非侵入性”，即被监控的站点和服务无需任何埋点，无需任何修改，被监控模块的负责人无需配合做任何事情，就能全方位 cover 住。

维度一，如何进行操作系统，进程，端口监控？

监控需求 ：

  1. 系统的 网络 是否被打满， 磁盘 是否有空间， CPU 是否繁忙， 内存 是否用完， 负载 值是否过高， JVM 是否正常；
  2. 服务进程是否运行；
  3. 监听端口是否正常；
  4. 机器间是否联通； !

常见方案一：zabbix
搞运维的都懂，不展开细聊了，聊多了怕被骂。

常见方案二：shell
写一些非常简单的脚本，就能够获取到网络、磁盘、CPU、内存、load、JVM 的信息，在配合一些阈值的配置，就能实现超出阈值告警的功能。
如果配合集群信息管理服务，通过 ps, netstat, telnet 等命令，也能快速实现进程，端口，连通性的简易监控。

实现要点：

  1. 重点考虑扩展性，可配置性，非侵入性；2. 集群信息管理服务（或者，集群信息配置文件）；

维度二，如何进行 404 状态码监控？

监控需求 ：监控 http 异常状态码。

监控方案：nginx 日志统一监控

如果实现了 http 接口统一监控，404 监控的必要性并不是这么强，但毕竟实现简单，整一个通用的花不了多少时间。

在聊存活性监控，接口处理时间监控之前，多说几句系统架构，如果实现了框架与组件的统一，统一监控会省非常多的力气。

上图是一个典型的互联网分层架构图：

  1. 最上游是 APP 和 browser；
  2. 反向代理层 是 nginx，统一 http404 状态码监控就实现在这一层；
  3. web 层 ，假设自研了 web-framework；
  4. service 层 ，假设自研了 service-framework，web 层会通过 RPC-client 调用 service；
  5. 数据层 db，假设自研了 Daojia-DAO 组件调用 db；
  6. 缓存层 cache ，假设自研了 Daojia-KV 组件调用 cache；

D-DAO 和 D-KV 两个组件并没有大伙想的复杂，初期只是简单的封装了一层而已。

维度三，如何进行服务存活性监控

监控需求：进程和端口的监控，只能保证进程在，端口在，但并不能确定服务是否能响应请求，需要确定服务“活着”。

监控方案 ：ping-pong 式监控，在站点框架，服务框架层面统一实现，提供 keepalive 接口：

  1. 在框架层面就可以实现 ping-pong 接口；
  2. 监控中心通过集群信息管理服务（或者是配置文件）获取集群类型（web/service），集群 IP 列表；
  3. 监控中心统一往集群发送内置的 ping-pong 请求；

强调两点 ：

  1. 如果开源框架不提供 ping-
    pong 接口，可以二次开发（要慎重，任何开源框架的二次开发，都是大坑的开始）；
  2. 统一集群信息管理服务，或者，统一集群信息管理配置文件，真的很重要，是技术体系统一的基石；

维度四，如何进行接口执行时间监控

监控需求：

  1. http 站点接口有没有超时；
  2. RPC 服务接口有没有超时；
  3. db 访问有没有超时；
  4. cache 访问有没有超时；
  5. 除了超时，还要监控同一个接口的执行时间有没有同比、环比的大幅度波动，例如：一个接口平均响应时间是 100ms，突然有一天增加到 300ms，即使没有超时，也有理由怀疑接口出现了问题；

监控方案 ：框架组件统一上报（如上图 1,2,3,4）。

  1. 在 web-framework 里，对所有 http 接口进行数据上报，可以上报 url，参数，执行时间 等核心数据；
  2. 在 service-framework 里，对所有 RPC 接口进行数据上报，可以上报 接口，参数，执行时间
    等核心数据；
  3. 在 DAO 里，对所有数据库 SQL 访问进行数据上报，可以上报 sql，参数，执行时间 等核心数据；
  4. 在 KV-client 里，对所有 cache 访问进行数据上报，可以上报 key，执行时间 等核心数据；

统一上报是思路，具体上报细节，是通过 flume 刷日志，还是 storm/spark 实时流处理，都可以。

总结

监控是一个技术活：

  1. 监控平台的思路是 多维度立体化监控 ；
  2. “统一操作系统、http404，服务存活性，接口处理时间”等四大类统一监控的设计核心是“非侵入性”，不需要任何人配合修改，就能实现诸多功能的技术平台，才是好技术平台；
  3. 统一集群信息管理服务，统一人员信息管理服务，统一告警策略服务（或者配置文件），是统一技术体系的基石；

参考文章

https://mp.weixin.qq.com/s/1lSdfafmJeNgCrXDe7pLhw

 目录