监控维度

监控的目的是为了预防以及提前告警，简单的出现问题了在告警，说明已经发生了。 告警说明有问题，不告警就没有问题吗？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客户端进行数据上报，这个多维度的数据统一通过日志进行上报后，即可实现超时和其他业务规则的监控告警，并且能够追查到具体某个接口和某个参数。

监控是个技术活，如果遇到日志量特别大的，还要考虑大数据平台，分布式的解决方案来搭建监控平台，而对于初创企业就无需考虑那么多，先有，在优化，快速上线才是王道。