服务监控的目的是为了尽早发现出现的问题,减少或避免可能造成的损失。
监控首先要解决的问题是监控什么,即监控的方法,其次是如何有效告警,最后是如何跟踪处理告警
如何监控
根据监控的方式,一般有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工具,提供对应的调用链信息。
告警跟踪与处理
告警需要进行告警分级,从告警系统本身定义到人工二次辨认,首先对告警需要进行分级,对于立即处理的,则告警发生就需要进行处理。其他的,告警系统可以在告警发送端记录告警信息,直接实现告警的处理系统或批量导入企业的问题处理系统,进行告警问题的处理跟踪。这里需要注意的是告警问题的合并,即相同/类似的告警根据特定规则进行告警合并,使开发人员专注于解决问题。
本作品的版权所有权归作者所有,受法律保护。未经作者书面许可,任何个人或组织均不得以任何形式使用、复制、修改、传播、展示或在未获得授权的情况下进行商业利用。