多维度立体化监控，才是真的监控

标签：nginx日志   架构设计   类型   dao   命令   keepaliv   文件   cache   互联网   

监控这个topic本来有很多细节可以聊，既然大伙公司都做得比较完善，后续就不纠细节了，聊聊方向上的思考，架构上的设计。今天和大伙聊聊多维度立体化监控。

一、什么是多维度立体化监控

不同公司或多或少有一些自动化监控手段，除了前文提到的：

• http接口监控
• log关键字监控

还有很多维度的监控：

• 操作系统，进程，端口
• http状态码
• 服务存活性
• 接口处理时间
• RPC接口监控
• 用户层面监控

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

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

例如：

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

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

前文介绍的http接口监控，log关键字监控，在设计上都讲究通用+可扩展，接下来介绍的四个维度的监控，在设计上也是看重“通用”“非侵入性”，即被监控的站点和服务无需任何埋点，无需任何修改，被监控模块的负责人无需配合做任何事情，就能全方位cover住。
画外音：如果有一天你有机会负责框架，组件，基础服务，技术平台等部门，你就会明白“非侵入性”有多重要了，在公司推一个技术产品太困难了。

二、操作系统，进程，端口监控

监控需求：

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

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

常见方案二：shell
写一些非常简单的脚本，就能够获取到网络、磁盘、CPU、内存、load、JVM的信息，在配合一些阈值的配置，就能实现超出阈值告警的功能。

如果配合集群信息管理服务，通过ps, netstat, telnet等命令，也能快速实现进程，端口，连通性的简易监控。

实现要点：

• 重点考虑扩展性，可配置性，非侵入性
• 集群信息管理服务（如果没有服务，有集群信息配置文件也行）
  关于集群信息管理服务，详见《集群信息管理，架构设计中最容易遗漏的一环》。

三、404状态码监控

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

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

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

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

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

D-DAO和D-KV两个组件并没有大伙想的复杂，初期只是简单的封装了一层而已，具体的实现方案在《框架组件，究竟要不要自研？》一文中有深入的讨论。

四、服务存活性监控

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

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

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

强调两点：

• 如果开源框架不提供ping-pong接口，可以二次开发（要慎重，任何开源框架的二次开发，都是大坑的开始）
• 统一集群信息管理服务，或者，统一集群信息管理配置文件，真的很重要，是技术体系统一的基石
• 关于集群信息管理服务，详见《集群信息管理，架构设计中最容易遗漏的一环》。

五、接口执行时间监控

监控需求：

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

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

• 在web-framework里，对所有http接口进行数据上报，可以上报url，参数，执行时间等核心数据
• 在service-framework里，对所有RPC接口进行数据上报，可以上报接口，参数，执行时间等核心数据
• 在DAO里，对所有数据库SQL访问进行数据上报，可以上报sql，参数，执行时间等核心数据
• 早KV-client里，对所有cache访问进行数据上报，可以上报key，执行时间等核心数据
  统一上报是思路，具体上报细节，是通过flume刷日志，还是storm/spark实时流处理，都可以。

六、总结

监控是一个技术活，并不是大家评论里说的“搭一个ELK就搞定了，何必这么麻烦”：

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

相关文章：
《框架组件，究竟要不要自研？》
《集群信息管理，架构设计中最容易遗漏的一环》
《人员信息管理，告警策略管理，统一技术体系的基石》
《通用+可扩展http监控平台/框架》
《通用+可扩展log监控平台/框架》

小手一抖，文章转走。

多维度立体化监控，才是真的监控

标签：nginx日志   架构设计   类型   dao   命令   keepaliv   文件   cache   互联网   

原文地址：https://blog.51cto.com/jyjstack/2549411