监控方法、警报和通知、可视化
监控方法论
-
Brendan Gregg的USE（Utilization、Saturation和Error）方法，侧重于主机级监控。
-
Google的四个黄金指标，专注于应用程序级监控。
USE方法
USE是使用率（Utilization）、饱和度（Saturation）和错误（Error）的缩写，该方法是由Netflix的内核和性能工程师Brendan Gregg开发的。USE方法建议创建服务器分析清单，以便快速识别问题。
USE方法可以概括为：针对每个资源，检查使用率、饱和度和错误。该方法对于监控那些受高使用率或饱和度的性能问题影响的资源来说是最有效的。让我们快速查看每个术语的定义以帮助理解。
- 资源：系统的一个组件。在Gregg对模型的定义中，它是一个传统意义上的物理服务器组件，如CPU、磁盘等，但许多人也将软件资源包含在定义中。
- 使用率：资源忙于工作的平均时间。它通常用随时间变化的百分比表示。
- 饱和度：资源排队工作的指标，无法再处理额外的工作。通常用队列长度表示。
- 错误：资源错误事件的计数。
Google的四个黄金指标
Google的四个黄金指标来自Google SRE手册，它们采用与USE类似的方法，指定要监控的一系列通用指标类型。此方法中的指标类型主要关注的不是系统级的时间序列数据，更多是针对应用程序或面向用户的部分：
- 延迟：服务请求所花费的时间，需要区分成功请求和失败请求。例如，失败请求可能会以非常低的延迟返回错误结果。
- 流量：针对系统，例如，每秒HTTP请求数，或者数据库系统的事务。
- 错误：请求失败的速率，要么是HTTP 500错误等显式失败，要么是返回错误内容或无效内容等隐式失败，或者基于策略原因导致的失败——例如，强制要求响应时间超过30ms的请求视为错误。
- 饱和度：应用程序有多“满”，或者受限的资源，如内存或IO。这还包括即将饱和的部分，例如正在快速填充的磁盘。
黄金指标使用起来很简单。依次选择对应的高阶指标，然后为它们设置警报。如果其中一个指标出现问题，那么警报就会响起，然后你可以去诊断或解决问题。
警报和通知
警报和通知是监控工具的主要输出。那么警报和通知之间有什么区别呢？警报会在某些事件发生（如指标达到阈值）时触发。然而，这并不意味着有人被告知此事件发生，这是通知的来源。**通知接收警报并告知某人或某事：通过发送电子邮件、发送短信或者创建工单等。**看起来这应该是一个非常简单的领域，但它通常包含很多复杂因素，并且很难实施和管理。
要建立一个出色的通知系统，需要考虑以下基础信息：
- 哪些问题需要通知·谁需要被告知
- 如何告知他们
- 多久告知他们一次
- 何时停止告知以及何时升级到其他人
如果配置不当，导致生成了过多通知，那么人们将无法对它们采取任何行动，甚至可能将它们忽略掉。
最重要的是，你需要考虑通知内容。通常当出现问题或者有事件需要你注意时，通知是唯一的途径。它们需要简洁、清晰、准确，易于理解并且可操作。设计有价值、有意义的通知至关重要。让我们通过一个示例来看看通知内容为什么很重要。以下是Nagios关于磁盘空间的通知。
想象一下，你刚刚在凌晨3点36分收到这条通知。它都告诉了你哪些信息？首先，这是一个主机磁盘空间警报，并且/data目录存储已达到91%。乍一看这很有价值，但实际上并没有那么实用。首先，这是由一个存储空间突增导致的？还是逐渐增长的结果？增长速度是多少？（1 GB分区上9%的可用磁盘空间与1 TB磁盘上9%的可用磁盘空间完全不同。）你可以忽略这类通知或将其静音吗？还是需要立即采取行动？如果没有其他上下文，那么采取的行动就会受到限制，你需要投入相当多的时间来收集上下文。
在我们的框架中，将重点关注以下内容：
- 使通知清晰、准确、可操作。使用由人而不是计算机编写的通知在清晰度和实用性方面有显著差异。
- 为通知添加上下文。通知应包含组件的其他相关信息。
- 仅发送有意义的通知。
可视化
数据可视化既是一门非常强大的分析和解释技术，也是一种令人惊叹的学习工具。指标及其可视化通常很难解释。人们在查看可视化图像时，往往会幻想出并不存在的事物间的联系：从随机数据中找到有意义的模式。这通常会导致从相关性到因果关系的突然飞跃，而数据的颗粒度或分辨率、表示数据的方式以及数据的规模可能会进一步加剧这种飞跃。
导致从相关性到因果关系的突然飞跃，而数据的颗粒度或分辨率、表示数据的方式以及数据的规模可能会进一步加剧这种飞跃。
理想的可视化应该能够清晰地显示数据，突出重点而不仅是提高视觉效果。