4.1监控策略的理想特征

Desirable Features of a Monitoring Strategy

监控策略的理想特征

在选择监控系统时，了解并优先考虑对您而言最优的功能非常重要。如果您正在评估不同的监控系统，本节可以帮助您了解哪种解决方案最适合您的需求。根据您的需要，一个监控系统可能会解决您的所有问题，或者您也可能希望使用组合的监控系统。

速度

在数据的更新和数据检索的速度方面，不同的企业有不同的需求。

数据应该在您需要的时候实时可用：数据的更新速度会影响您的监控系统在出现问题时向您通知的时间。 此外，不实时的数据可能会导致您做出一些不正确的判断和操作。例如，在故障期间，如果采取操作的时间和看到监控中所反映出来的时间相差太多，您可能会认为操作没有生效或推断原因和结果之间有误差。过期四到五分钟的数据可能会明显的影响您对故障的响应速度。

如果您根据这个标准选择监控系统，则需要提前确定对实时速度的要求。当您查询大量数据时，数据检索的速度是主要的一个问题。如果图表必须从多个监控系统中计算大量数据，那么可能需要一些时间来加载图表。为了加快速度较慢的图表的加载，监控系统可以预先计算出常用的数据，根据传入的参数创建和存储新的时间序列，这非常有用。

计算

对计算的支持应该要覆盖各种复杂程度的用例。至少，您可能希望系统保留多个月的数据。如果没有长期的数据视图，就无法分析系统的增长趋势。就粒度而言，摘要数据（即您无法深入研究的汇总数据）就足以反应增长趋势并促进更新升级计划。保留所有详细的指标可能有助于回答诸如“这种故障异常之前发生过吗？”之类的问题。但是，数据存储的开销可能会比较昂贵同时可能检索起来也不那么容易。

所以理想情况下您保留的有关事件或者资源消耗的指标应该是采用单调递增的计数器。使用计数器，您的监控系统可以随时进行计算累加，例如：每秒的请求速率。通过较长的时间窗口（最多一个月）计算这些速率，可以构建出基于SLO（服务等级目标）的报警系统。

最后，支持更完整的统计函数可能会很有用，因为琐碎的操作可能会掩盖一些问题。在记录延迟时支持计算百分位数（即第50,95,99百分位数）的监控系统可以让您看出50％，5％或1％的请求是否太慢，而算术平均值只能告诉您 - 没有细节 - 请求时间较慢。或者，如果您的系统不直接支持计算百分位数，您可以通过以下方式实现此目的：

  • 通过将请求耗时相加并除以请求数来获得平均值

  • 记录每个请求并通过扫描或采样日志来计算百分位数值

您可能希望将原始度量数据记录在单独的系统中以便进行离线分析 - 例如，在每周或每月报告中使用，或者执行在监控系统中比较难执行的更复杂的计算。

仪表界面

强大的监控系统应该允许您在图表中简明地显示时间序列数据，还可以在表格或一系列图表中构建数据。您的仪表板将是显示监控的主要界面，因此选择能清晰显示您关注的数据的图表格式非常重要。一些选项包括热图，直方图和对数比例图。

您可能需要根据受众提供相同数据的不同视图，例如高层管理可能希望查看到与SRE完全不同的信息。具体内容应该根据受众创建对他们有意义的仪表板。对于每组仪表板，始终如一地显示相关的数据对于分析问题是非常有价值的。

您可能需要跨不同指标聚合（例如机器类型，服务器版本或请求类型）实时绘制信息。您的团队可以轻松地对您的数据进行查询分析。根据各种指标对数据进行切片，您可以在需要时查找数据的关联性和数据模型。

报警

能够对警报进行分类是非常帮助的：多种警报应该允许按比例进行响应。为不同警报设置不同严重性级别的功能也很有用：例如您可以对低错误率的警报延后超过一小时再提交你的处理工单，而100％错误率却是一种应该立即响应的紧急情况。

警报抑制功能可以避免不必要的通知，以免过多的分散工程师的注意力。 例如：

  • 当所有节点都遇到相同的高错误率时，您只需警告一次全局错误率，而不是为每个节点发送单独的警报。

  • 当您的某个服务所依赖的服务触发报警时（例如，响应慢的后端），您无需报警您服务的错误率。

您还需要确保在事件结束后不再抑制警报。

您对系统的控制级别将决定您是使用第三方监控服务还是部署并运行您自己的监控系统。谷歌内部开发了自己的监控系统，但同时也有大量的开源和商业监控系统可供使用。