监控告警实践
介绍监控系统的各个组成部分是如何实现这些功能要求的。然后，我们将讨论如何将您的监控策略转化为仪表板和警报策略，为你的团队提供所需的信息。
监控系统的构成
Distributed Monitoring Agents and Data Exporters
代理作为系统中每个主机上始终运行的守护程序。它们可能包括用于与远程数据端点进行安全身份验证的基本配置，定义数据频率或采样策略，并为主机数据设置唯一标识符。为了减少对其他服务的影响，代理必须使用最小的资源，并且能够在几乎不需要管理的情况下运行。理想情况下，在新节点上安装代理并开始向中央监控系统发送指标应该是非常简单的。
Data Exporters 有推/拉两种方式。 采用了推送架构，代理将数据推送到Collector服务器。 在基于拉取的监控系统中，各个主机负责在Endpoint中收集、汇总和提供指标。监控服务器轮询每个主机上的指标端点以收集指标数据。通过Endpoint收集和呈现数据的软件通常需要更少的配置，因为它不需要知道如何访问其他机器。
Metrics Ingress
对于基于推送的系统，Metrics采集入口端点是网络中的一个中央位置，监控Agent或统计聚合器将其收集的数据发送到该位置。Endpoint应能够同时验证和接收大量主机的数据。用于Metrics的入口端点通常在规模上进行负载均衡或分布，既用于提高可靠性，又用于跟上高流量。
对于基于拉取的系统，相应的组件是轮询机制，通过它可以访问并解析各个主机上公开的Metrics Endpoint。额外的工作，如果各个主机实施了身份验证，那么Metrics收集过程必须能够提供正确的凭据以并访问安全端点。
Data Management Layer
Metrics 数据通常以称为时间序列的格式记录，表示值随时间的变化。 时间序列数据库（专门存储和查询此类数据的数据库）经常在监控系统中使用。
Data Management Layer还需要提供对存储信息的有组织的访问。 对于使用时间序列数据库的系统，主要消费者可能是数据呈现仪表板和警报系统。
Visualization and Dashboard Layer
略
Alerting and Threshold Functionality
警报定义由通知方法和度量阈值组成。阈值通常定义了在指定时间框架内度量的最大或最小平均值，而通知方法描述了如何发送警报。
Black-Box and White-Box Monitoring
Black-Box监控描述的是仅基于外部可见因素的警报定义或图表。这种监控方式采用外部视角，以保持对应用程序或服务的运行情况的关注。
White-Box监控描述的是基于关于基础架构的内部信息的任何监控。例如，通过跟踪资源使用情况的变化，可以在需要扩展某些服务时发出告警。White-Box监控有预测机制，支持可编程能力。
告警分类
Pages
最高优先级的警报类型开始，Pages是试图紧急引起对系统中的关键问题的注意的通知。这类警报应该表明系统遇到了严重性问题，并且需要立即解决的情况。
Secondary Notifications
严重程度次于Pages，这类报警并不意味着需要立即处理，但仍需要后续处理的情况。
Logging Information
虽然从技术上讲这不是警报，但需要一个特定的服务，来辅助分析观察到的行为。 在这些情况下，仅记录信息的阈值可能会很有用。 这些可以写入文件或用于增加监控系统仪表板上的计数器。如Java 应用的warn 级的日志数量
此策略仅适用于优先级非常低且无需自行响应的场景。
什么时候无需告警
明确警报对于你的团队表示什么。每个警报都表示出现了需要人工干预或决策处理的问题。考虑要发出哪些指标的警报时，请注意任何可以自动化Response的机会。
如下情况，可以进行自动化的处理措施：
- 可靠地识别问题，如network traffic已到达阈值
- 响应总是相同的，如http 5XX errors rate
- 响应不需要任何人的输入或决策，如auto restart
设计有效的阈值和警报
基于影响真实用户的事件触发
目标是可靠地指出当前或即将影响用户的告警指标。离用户越近，数据越重要。
合理阈值的设置
在确定了告警指标后，下一个挑战是确定其阈值。对于一些指标，你可能需要使用试错法来发现正确的阈值。
如果有历史值可用，请检查历史值和需要进行补救处理的情景是否一致。对于每个指标，定义一个会触发Pages的“紧急”阈值和一个或多个与较低优先级消息相关联的“金丝雀”（Sencondary Notification）阈值是很好的做法。在定义新的警报后，需要征求不同团队意见，了解阈值是否过于激进或不够敏感，以便你可以微调系统，以最好地满足团队的期望。
警报需要包含适当的上下文
最大限度地缩短oncall人员开始调查问题所需的时间可以帮助我们更快地从事件中恢复。 为此，尝试在警报文本中提供上下文非常有用，以便Ops可以快速了解情况并开始采取适当的后续步骤。
警报应清楚地表明受影响的应用和服务、触发的指标阈值以及事件开始的时间。 该警报还应提供可用于获取更多信息的链接。这些可能是指向与触发的指标关联的特定仪表板的链接，指向您的Ticket系统（工单处理）的链接，或者指向监控系统的警报页面的链接，其中提供了更详细的上下文。
警报发给合适的人
oncall轮换应包括足够有能力处理的工程师，以避免倦怠和报警疲劳。
升级计划是确保事件传达给正确人员的第二个工具。遇到无法处理的情况，立即向上升级，交给下一个处理员工。