架构设计笔记_18_关键模式_监控体系
Posted 昌明说
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了架构设计笔记_18_关键模式_监控体系相关的知识，希望对你有一定的参考价值。
2009年3月 清华大学
监控维度
监控的目的是为了预防以及提前告警，简单的出现问题了在告警，说明已经发生了。告警说明有问题，不告警就没有问题吗？CPU没有到100%，但是tomcat已经挂了。所以监控应该是多维度来实施。维度如下：
log日志关键字监控
操作系统，进程，端口
http状态码、接口监控
服务存活性
接口处理时间
RPC接口监控
用户层面监控
监控设计
设计思路是考虑可扩展，通用性以及少侵入性。被监控系统不修改，不需要配合即可实现监控，可扩展要求新增监控项时可以添加，无须修改监控逻辑；监控项结合具体业务实现特定业务规则监控，比如监控某个接口，通过返回结果中包含特定关键字来判断接口是否正常，而不是200状态码，告警策略可配置。
监控展示统一化，监控平台化设计思路，根据系统大小，考虑集中式或者分散式监控设计（对于日志监控来说）。
监控实现
进程，端口，cpu磁盘和内存，负载，jvm，网络
通过zabbix实现，或者基于linux的shell脚本都可以做到。
日志关键字
日志ELK是一种比较成熟的方案，logstash统一收集节点日志，ES汇总分析，由kibana进行统一展示，但是这种集中式的日志方案，前提是有统一的日志命名规范，日志目录规范，日志分级规范，日志切分规范。结合配置的监控规则即可对日志进行集中式监控和告警。
服务存活
端口和进程存在不能说明服务还或者，由开发框架或者服务本身提供pong服务，再有监控中心统一进行pong请求即可。
http接口超时，数据库超时，rpc超时，cache超时
采取统一集中日志上报方式，网关层记录每个接口访问时间和参数进行上报，rpc在业务层进行数据上报，db访问时间在dao层进行数据上报，cache层在cache客户端进行数据上报，这个多维度的数据统一通过日志进行上报后，即可实现超时和其他业务规则的监控告警，并且能够追查到具体某个接口和某个参数。
监控是个技术活，如果遇到日志量特别大的，还要考虑大数据平台，分布式的解决方案来搭建监控平台，而对于初创企业就无需考虑那么多，先有，在优化，快速上线才是王道。
以上是关于架构设计笔记_18_关键模式_监控体系的主要内容，如果未能解决你的问题，请参考以下文章