|
前文介绍了通用+可扩展的http监控平台与log监控平台的架构： 结果，评论里各种冷嘲热讽。 监控这个topic本来有很多细节可以聊，既然大伙公司都做得比较完善，后续就不纠细节了，聊聊方向上的思考，架构上的设计。今天和大伙聊聊多维度立体化监控。
一、什么是多维度立体化监控 不同公司或多或少有一些自动化监控手段，除了前文提到的：
还有很多维度的监控：
如果只监控一个或少数几个维度：
例如：
这里的观点是：单维度监控易漏报，多维度立体化监控才是监控平台的根本之道。
前文介绍的http接口监控，log关键字监控，在设计上都讲究通用+可扩展，接下来介绍的四个维度的监控，在设计上也是看重“通用”“非侵入性”，即被监控的站点和服务无需任何埋点，无需任何修改，被监控模块的负责人无需配合做任何事情，就能全方位cover住。 画外音：如果有一天你有机会负责框架，组件，基础服务，技术平台等部门，你就会明白“非侵入性”有多重要了，在公司推一个技术产品太困难了。
二、操作系统，进程，端口监控 监控需求：
常见方案一：zabbix 搞运维的都懂，不展开细聊了，聊多了怕被骂。
常见方案二：shell 写一些非常简单的脚本，就能够获取到网络、磁盘、CPU、内存、load、JVM的信息，在配合一些阈值的配置，就能实现超出阈值告警的功能。 如果配合集群信息管理服务，通过ps, netstat, telnet等命令，也能快速实现进程，端口，连通性的简易监控。
实现要点：
关于集群信息管理服务，详见《集群信息管理，架构设计中最容易遗漏的一环》。
三、404状态码监控 监控需求：监控http异常状态码。
监控方案：nginx日志统一监控 如果实现了http接口统一监控，404监控的必要性并不是这么强，但毕竟实现简单，整一个通用的花不了多少时间。
在聊存活性监控，接口处理时间监控之前，多说几句系统架构，如果实现了框架与组件的统一，统一监控会省非常多的力气。 上图是一个典型的互联网分层架构图：
D-DAO和D-KV两个组件并没有大伙想的复杂，初期只是简单的封装了一层而已，具体的实现方案在《框架组件，究竟要不要自研？》一文中有深入的讨论。
四、服务存活性监控 监控需求：进程和端口的监控，只能保证进程在，端口在，但并不能确定服务是否能响应请求，需要确定服务“活着”。
监控方案：ping-pong式监控，在站点框架，服务框架层面统一实现，提供keepalive接口：
强调两点：
关于集群信息管理服务，详见《集群信息管理，架构设计中最容易遗漏的一环》。
五、接口执行时间监控 监控需求：
例如：一个接口平均响应时间是100ms，突然有一天增加到300ms，即使没有超时，也有理由怀疑接口出现了问题
监控方案：框架组件统一上报（如上图1,2,3,4）
统一上报是思路，具体上报细节，是通过flume刷日志，还是storm/spark实时流处理，都可以。
六、总结 监控是一个技术活，并不是大家评论里说的“搭一个ELK就搞定了，何必这么麻烦”：
相关文章： 小手一抖，文章转走。 |
|
|
来自： xujin3 > 《高可用高并发高性能》
