拥有一套合适的监控基础设施意味着可以衡量系统的性能并保留这些测量数据的历史记录。同时，还意味着可以为测量数据确定阈值并在其超过阈值后自动发送通知。
不过，有一件事是需要记住的，系统很容易达到信息过多告警泛滥的状态。最终，信息过载所造成的危害要远大于它的好处（如果情况进一步恶化，人们会开始忽略重复出现的告警）。需要确保所发出的告警是可执行的，是会被处理掉的，并且这些告警要发给组织中正确的人员。
虽然服务可以消费某些告警和自动执行某些操作，比如当队列中的消息出现积压时，对服务进行自动扩容，但人也需要消费一些告警和采取某些行动。
要确保这些告警到达正确的人群中并且包含足够多的信息，这样诊断问题原因时就会尽可能地简单。
还需要对告警进行优先级排序，因为服务或基础设施中的任何问题都有可能触发多个告警。无论是谁在处理这些告警，都需要立即知道每个告警的紧急程度。通常，将服务的告警直接发送到负责这些服务的团队中。应该将应用映射到组织结构中，因为这有助于确定告警的目标人群。
系统出错时哪些人需要知悉
在日常操作中，告警应该面向团队的开发者和维护者。这反映了“谁开发，谁运行”这一支配着微服务工程团队的理念。作为创建和部署服务的团队，想让每个人对于部署的每个服务都一清二楚，即便不是不可能的，那也是非常困难的事情。对服务最了解的人是对服务产生的告警进行说明和采取行动的最合适人选。
根据紧急程度来将告警进行分类。并不是所有的问题都需要立刻被关注，但是有一些问题是影响大局的，需要在了解这些告警后第一时间将其修复。
严重问题应该触发通知并确保有人能正常接收到，不管是开发相应服务的开发团队中的工程师还是值班的工程师。中度危险的问题应该生成告警并采用适当的渠道将通知发送出去，这样，监控这些告警的人员就可以收到这些通知了。低优先级的告警可以只生成一条记录，这些告警并不严格要求有人员来处理。
症状，而非原因
触发告警的应该是症状，而非原因，比如用户会遇到的错误。如果用户不能再访问某个服务，那么这种能力的丧失应该生成一条告警。在只有部分信息的情况下，并不能够了解发生了什么事情或者问题是什么。
股票市场中订单发布的流程图中，网关作为该功能的消费访问入口和4个服务共同协作。一个或多个服务可能出现执行错误或过载的情况。由于组件间的通信主要是异步的，很难确定为什么会发生指定的错误。
如果将到达网关的请求数以及订单发布所发出的通知数配置一个告警。随着时间的推移，将这两个指标关联起来并确定两者之间的比值将非常容易，也就有了一个症状：提交订单的数量大于完成的数量，可以以此着手然后尝试了解哪个组件（也可能是多个组件）出现了问题，是事件队列或者某个基础设施的问题，还是系统负载太高不能及时处理导致的？这些症状是展开调查的起点，从那里开始跟随线索，直至找到一个或多个原因。
总结：常见的方法是告警关联，告警框架根据告警关联规则将有关系的告警关联起来，从症状到根因。
尽可能减少告警通知的数量并保持这些通知的可操作性来避免出现告警疲劳。系统正常行为的每次偏差都生成一条告警通知很快就会导致人们不再关心这些告警或者认为这些告警并不重要。这样会导致一些重要告警被忽视。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论