概要
之前我写过一篇文章,介绍微服务框架下如何打印日志
虽然通过日志记录,我们可以获取到任何时刻的异常情况。但是打印日志毕竟是一种“被动”行为,当线上服务出现问题时,我们需要一种主动通知的机制。这就是报警。
架构设计
通常有两种报警通知的设计模式。
一是日志收集,在服务器上有个log-agent,通过事先制定的正则表达式去匹配服务打印的每行日志。一旦匹配上,会统计相关参数,发送给消息队列,最后数据被灌入数据库中。
二是metrics上报,服务直接调用metrics函数,通过udp的方式将报警内容发送给本机的一个agent上,agent的作用是聚合metrics指标,避免过多的网络开销。agent会定期将收集到的metrics信息上报到服务器上。
第一种方式实现简单,第二种方式更专业。
指标
最长用的报警指标有也是有两类。
一是计数,如统计上游的调用量,某种错误出现的次数等;
二是RPC,它是专门针对rpc调用设计的,包括返回错误码,latency,caller,callee,function等参数。
公用的参数包括metric_name, tags等。
如何添加报警
介绍一些通用的设计思路,每个服务需要根据其自身的独特性,再进行单独设计。
对接上游
名称 | 类型 | 指标 |
接收数量 | 请求数量 | 超过阈值 变化剧烈 |
请求返回错误率/错误量 | 返回错误 | 超过阈值 变化剧烈 |
响应延迟 | 响应时间 | 超过阈值 变化剧烈 |
服务内部
名称 | 类型 | 指标 |
内部逻辑错误 | 错误名称 | 次数 |
申请资源失败 | 资源名称 | 次数 |
超时控制 | 请求时间开销 | 次数 |
对接下游
名称 | 类型 | 指标 |
接收数量 | 请求数量 | 超过阈值 变化剧烈 |
请求返回错误率/错误量 | 返回错误 | 超过阈值 变化剧烈 |
响应延迟 | 响应时间 | 超过阈值 变化剧烈 |
在此基础上我们还可以对报警的名称进行统一规范,达到一目了然的效果。