在云和容器云时代，衡量一个服务的成功与否不再是你怎么构建一个完美的产品，而是持续的服务能力。怎么定义这个能力呢？根据ITIL标准，有客户定义质量和性能服务水平协议 (SLA)， 为了持续了解目前在线服务的SLA，需要部署监控以跟踪它，确保满足SLA的要求。说到监控可能大家都熟悉基本的监控项目（比如zabbix）和一些接口质量的监控（nagios） ,但是这些对SLA来说是不足的。为了监控SLA，我们需要想要创建监控仪表板，通过可视化收集的一些日志和指标并了解产品的行为。本文虫虫就给大家说说如何创建一个监控SLA的仪表板，仪表盘应该添加哪些指标。

常见误区

所有指标一个仪表板 ：一张图像对应一个指标，在一个仪表板中添加1000个小图表。所以，根本没法看到（查到）需要的指标或趋势。

指标图表/面板之间没有相关性或流程： 仪表板的凝聚力无关紧要。从任何级别和层以任何顺序绘制指标。迫使团队花时间在仪表板上扫描相距很远的相关指标面板。

不要聚合指标： 在每个面板上为每个进程/服务器/服务实例绘制一条单独的线。 是否有100个服务实例报告响应时间？在响应时间面板上绘制100行。

在同一面板中混合来自不同级别的指标：在同一面板中混合基础设施和应用程序级别的指标。在同一面板中绘制服务实例计数和响应时间。绘制同一面板中的进程数和错误率。

没有变量，没有深入研究：没有提供任何可变参数或向下钻取选项来选择和查看特定客户端/服务/环境的指标。假设仪表板将被克隆，并且在每个新克隆中硬编码任何此类选择。

无概览仪表板：为每个指标级别创建单独的仪表板。为每个组件创建一个单独的仪表板。让团队浏览3个仪表板，需要在心里将业务与应用程序联系起来，再到基础设施指标，以确定整体系统健康状况。

正解：自顶向下，从概览开始

概览仪表板：构建仪表板以快速概览系统的健康状况。提供一个胜过一切的顶部面板，显示指示系统性能（或正在跟踪的内容）的最高级别指标。看一眼那个面板就可以知道系统是否正常。

监控项：检测代码以公开有意义的指标，实现快速地评估当前行为。公开有关运行状况、性能、负载或服务质量的指标。 用监控系统来收集这些指标并随着时间的推移捕捉行为趋势和模式。 使用这些趋势和模式作为系统/应用程序改进的基础。

日志：使用日志记录来帮助追踪问题的根源。当生产问题发生时，重要的是要有足够的日志记录来快速追踪其根本原因。如果可以在生产组件上启用按需信息/调试级别信息而无需更改代码和/或发布，会有所帮助。

自上而下的结构：按行和列构建仪表板面板。从顶部行的最高级别指标开始，并在添加其他行时降低指标级别。例如，影响业务的指标将位于顶部面板行中，然后应用程序指标和基础设施将位于最后。

每个组件的列：如果可能，为每个组件或处理阶段保留一列面板。在同一行的单独水平排列的面板中为每个组件/阶段绘制相同的度量。如果系统有问题，应该第一眼看到仪表板。然后，应该会看到哪个组件/处理阶段有问题。最后，应该会看到问题的根源。

左右结构： 当从左到右导航仪表板时，如果可能，面板应根据系统中的数据流绘制指标。应该能够快速确定数据流中存在问题的位置。

可变参数和向下钻取： 提供的选项限制指标，特别是客户端，服务或环境的显示，使用可变参数和向下钻取的菜单选项。当问题仅出现在单个客户端或服务上时，这非常有用，并使工程师在调试时能够专注于它们。

单独的详细仪表板：提供单独的仪表板用于调试单个服务和组件。通过这些组件能够深入研究和调试特定服务或组件的问题。为各个仪表板保持相同的自上而下的左右结构。仪表板之间的一致性减少了调试工作。

有多种策略可以让您了解系统/应用程序的运行状况、性能或质量。 快速检测和修复对客户产生负面影响的问题所需的可见性。 通过告警、监控和日志记录的组合获得可见性。

告警

再好的监控和再美观仪表盘，也只是个样子，最终也要落实到响应，及时发出准确的告警是实现最快响应的基础。

告警：使用告警快速发现系统/应用程序处于对客户端产生负面影响的状态。尝试以尽可能少的告警覆盖整个系统/应用程序的健康状况。对聚合指标和统计数据发出告警，例如百分比、一段时间内的错误率、百分位数（95%，90%，60%）。调整告警以最大程度地减少误报并避免噪音。

综合：通知告警潜在问题。当触发告警时，应使用监控来快速评估情况并确定问题。确定问题后可以使用日志记录来跟踪问题的根源。

提醒重要的事情并优化静音

服务水平指标告警：确定所有系统层的最小指标集，这些指标可以捕获系统的质量和性能。当这些指标表明违反了SLA时发出告警。 从更接近客户的指标开始，然后向下工作。提醒客户端 API 错误率而不是数据库连接错误率。 监控 API 响应时间百分位数。 当第95个百分位数超过SLA时发出告警。当接到客户呼入通知时，有90% 的机会出现问题。

聚合指标并捕获上下文：聚合来自不同系统层的指标以获得更准确的告警。例如，警告“响应时间高和数据库时间高”而不是“响应时间高”。为每个告警提供额外的基于文本的通知。文本应包含上下文：百分位数、监控快照、趋势。

根据SLA 调整告警级别：设置为CRITICAL或 Sev 1 仅告警指示客户端影响。 对于Sev 1告警，预计值班人员会收到通知并立即做出反应。如果某些内容已关闭但尚未对客户产生负面影响，则可以将其设置为WARNING 或Sev 2，并预计有人会在几个小时内查看它。对 Sev 2告警使用干扰较小的通知渠道，例如邮件，钉钉或者微信。根据SLA调整告警级别。如果目标是99.99可用性，则可能需要设置为CRITICAL告警，对于99.9系统可能是告警。

优化告警：对误报告警做出反应的工程师，仍需花时间验证和监控告警条件。为了减少误报，需要随时间聚合的指标发出告警。提高/降低利率的告警。将新告警部署为警告。监控其触发频率，并调整其阈值。当90%确定它们仅在出现生产问题时才会触发时，将它们提升为 CRITICAL。

总结

本文我们给出了容器云时代，基于SLA的监控、监控仪表盘以及告警该如何做。虽然仍然基于基本监控项和告警，但是更加立足于综合性和服务性，这就要求在熟悉的传统监控思想和方法基础上进行优化和完善。