架构|微服务下的报警设计 microservices|架构|微服务

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

名称	类型	指标
接收数量	请求数量	超过阈值【架构\|微服务下的报警设计】变化剧烈
请求返回错误率/错误量	返回错误	超过阈值变化剧烈
响应延迟	响应时间	超过阈值变化剧烈

服务内部

名称	类型	指标
内部逻辑错误	错误名称	次数
申请资源失败	资源名称	次数
超时控制	请求时间开销	次数

对接下游

名称	类型	指标
接收数量	请求数量	超过阈值变化剧烈
请求返回错误率/错误量	返回错误	超过阈值变化剧烈
响应延迟	响应时间	超过阈值变化剧烈