高可用系列六：服务监控

服务监控的目的是为了尽早发现出现的问题，减少或避免可能造成的损失。

监控首先要解决的问题是监控什么，即监控的方法，其次是如何有效告警，最后是如何跟踪处理告警

如何监控

根据监控的方式，一般有pull和push两种，即监控服务主动拉取相关监控对象的健康状态和监控对象主动push监控事件到监控服务本身。

然后可以根据监控的对象来进一步区分，主要有基础设施、中间件、应用程序。

基础设施

基础设施主要就是服务器节点本身，也可以说是操作系统层面，首先是机器节点是否正常运行：

1、系统的可触达，一般通过pull的方式，定期检查监控程序是否可触达监控对象，即服务器的node信息采集器，比如Prometheus 的node exporter。

2、系统指标，比如cpu、内存、硬盘的使用情况

中间件

这里的中间件指的是第三方或者自己开发的独立组件服务，比如mysql、MQ等等。因为中间件非常多，这里拿RocketMQ举例：

1、系统的可触达，也即监控触达，即系统本身的监控指标入口可以被访问到。

2、消息延迟，比如一段时间内（如5分钟）消息的延迟情况，可以知晓是否系统需要增加队列和消费者来提升消费能力

3、系统本身的GC等情况

4、死信，即是否下游服务出现异常，导致死信产生，此时除了监控报警外，还应监听记录死信消息，以便后续进行消息回放

5、事务消息，当事务消息确认到达阈值，此时RocketMQ只会记录一条日志，此时需要监听日志或修改相关实现，进行事务消息记录、告警

应用程序

这里的应用程序特指团队自身开发的业务信息，主要可以分为通用指标和业务告警事件。

通用指标包括服务的失败率、访问延迟、服务GC等所有服务通用的指标。

业务告警则是，业务额外定义的特定异常和特定事件，需要人工介入的情况。比如异步处理中因为代码问题，某个业务要求没有达到，引发的系统业务告警。

如何有效告警

当告警事件发生，需要通过邮件、电话、短信或企业微信、钉钉等将告警信息发出来。

告警是一个先增后减的过程，先增指的是，需要找到、完善相关的告警指标，此时是增加的过程。后减指的是，某些告警情况实际并不需要人工知晓和介入处理，此时要剔除相关的告警。

因此有效告警的关键在于，告警出来以后的信息就需要人工介入，而把一些不需要的或者误报的情况剔除、重复报警的事件进行告警抑制，使得接收到告警时能保持“敏感度”，避免出现如一天到晚告警，相关人员对于告警进入“疲态”，使得告警信息不被重视，从而失去的告警的实际意义。

其中一个典型需要解决的告警问题是解决毛刺，比如瞬时的CPU飙升，此时可以将该指标转化为监控一段时间的指标状态，即持续多少时间，居高不下时方进行告警。

最后，告警需要提供有效信息，可以在告警信息中将实际告警的服务/机器、告警级别、告警指标、告警原因、告警点明确出来，如果是应用告警，应提供具体的如订单信息等关键内容，也可结合apm工具，提供对应的调用链信息。

告警跟踪与处理

告警需要进行告警分级，从告警系统本身定义到人工二次辨认，首先对告警需要进行分级，对于立即处理的，则告警发生就需要进行处理。其他的，告警系统可以在告警发送端记录告警信息，直接实现告警的处理系统或批量导入企业的问题处理系统，进行告警问题的处理跟踪。这里需要注意的是告警问题的合并，即相同/类似的告警根据特定规则进行告警合并，使开发人员专注于解决问题。

本作品的版权所有权归作者所有，受法律保护。未经作者书面许可，任何个人或组织均不得以任何形式使用、复制、修改、传播、展示或在未获得授权的情况下进行商业利用。