您可能知道（或可以猜测）警报和可视化工具的用途。 为什么我们要将它们作为可观测性工具来讨论，尤其是一些系统已经包含可视化功能？
可观测性源于控制理论，描述了我们基于系统的输入和输出来理解系统的能力。 本文重点关注可观测性的输出部分。
警报和可视化工具分析其他系统的输出，并提供这些输出的结构化表示。 警报基本上是对负面系统输出的综合理解，而可视化是消除歧义的结构化表示，有助于用户理解。
常见的警报和可视化类型
警报
我们首先来讨论一下警报不是什么。 如果人工响应者无法解决问题，则不应发送警报。 这包括发送给多个人的警报，但只有少数人可以响应，或者系统中每个异常都触发警报的情况。 这会导致警报疲劳，接收者会忽略特定媒介中的所有警报，直到系统升级到尚未饱和的媒介。
例如，如果操作员每天从警报系统收到数百封电子邮件，那么该操作员很快就会忽略来自警报系统的所有电子邮件。 操作员只有在自己遇到问题、收到客户的电子邮件或老板的电话时才会对真正的事件做出响应。 在这种情况下，警报失去了它们的意义和用途。
警报不是持续的信息流或状态更新。 它们旨在传达系统无法自动恢复的问题，并且仅发送给最有可能恢复系统的人员。 任何不符合此定义的内容都不是警报，只会损害您的员工和公司文化。
每个人都有不同的警报类型，因此我不会讨论优先级级别（P1-P5）或使用“信息性”、“警告”和“严重”等词语的模型。 相反，我将描述复杂系统事件响应中出现的通用类别。
您可能已经注意到，在我写完警报不应该是信息性的之后，我提到了“信息性”警报类型。 好吧，并非所有人都同意，但是如果某事没有发送给任何人，我就不认为它是警报。 它是许多系统称为警报的数据点。 它表示应该知道但不应响应的某些事件。 它通常是警报工具的可视化系统的一部分，而不是触发实际通知的事件。 Mike Julian 在他的著作 Practical Monitoring 中涵盖了警报的这一方面和其他方面。 这是该领域工作的必读之作。
非信息性警报由可以响应或需要采取措施的类型组成。 我将它们分为两类：内部中断和外部中断。 （大多数公司有超过两个级别的优先级来确定他们的响应工作。）在此模型中，系统性能下降被认为是中断，因为对每个用户的影响通常是未知的。
内部中断的优先级低于外部中断，但仍需要快速响应。 它们通常包括公司员工使用的内部系统或仅对公司员工可见的应用程序组件。
外部中断包括任何会立即影响客户的系统中断。 这些不包括阻止发布系统更新的系统中断。 它们包括面向客户的应用程序故障、数据库中断以及损害可用性或一致性的网络分区（如果两者都可能影响用户）。 它们还包括可能不会对用户产生直接影响的工具的中断，因为应用程序继续运行，但这种透明的依赖关系会影响性能。 当系统使用一些外部服务或数据源时，这很常见，这些外部服务或数据源对于完整功能不是必需的，但可能会导致应用程序执行重试或处理来自此外部依赖关系的错误时出现延迟。
可视化
可视化类型有很多，我不会在这里全部介绍。 这是一个引人入胜的研究领域。 在我职业生涯的数据分析方面，学习和应用这些知识始终是一项挑战。 我们需要为复杂系统输出提供简单的表示形式，以便最广泛地传播信息。 Google Charts 和 Tableau 提供了多种可视化类型。 我们将介绍最常见的可视化以及一些用于快速理解系统的创新解决方案。
折线图
折线图可能是最常见的可视化。 它在随着时间的推移产生对系统的理解方面做得很好。 指标系统中的折线图将为每个唯一指标或指标的某些聚合绘制一条线。 当同一仪表板中存在大量指标时，这可能会让人感到困惑（如下所示），但是大多数系统可以选择要查看的特定指标，而不是让所有指标都可见。 此外，如果异常行为足够显着以至于可以摆脱正常操作的噪音，则很容易发现。 在下面，我们可以看到紫色、黄色和浅蓝色线条，这些线条可能表示异常行为。
折线图的另一个特点是，您通常可以将它们堆叠起来以显示关系。 例如，您可能想分别查看每个服务器上的请求，但也想汇总查看。 这使您可以了解整个系统以及同一图表中的每个实例。
图片来源：Grafana (© Grafana Labs)
热图
另一种常见的可视化是热图。 当查看直方图时，它非常有用。 这种类型的可视化类似于条形图，但可以在条形图中显示渐变，表示总体指标的不同百分位数。 例如，假设您正在查看请求延迟，并且您想快速了解总体趋势以及所有请求的分布。 热图非常适合这种情况，它可以使用颜色来消除快速浏览时每个部分的数量歧义。
下面的热图显示了围绕图表中心线较高的浓度，并且易于理解每个时间段的垂直分布的可视化。 我们可能想查看几个时间点，在这些时间点分布变得很宽，而其他时间点则相当紧密，例如 14:00。 这种分布可能是负面的性能指标。
图片来源：Grafana.org (© Grafana Labs)
仪表盘
我在这里要介绍的最后一种常见可视化是仪表盘，它可以帮助用户快速理解单个指标。 仪表盘可以表示单个指标，例如您的速度表表示您的行驶速度，或者您的油表表示您汽车中的油量。 与油表类似，大多数监控仪表盘清楚地表明什么是好的，什么是不好的。 通常（如下所示），绿色表示良好，橙色表示越来越差，红色表示“一切都崩溃了”。 下面的中间行显示了传统的仪表盘。
图片来源：Grafana.org (© Grafana Labs)
此图像显示的不仅仅是传统的仪表盘。 其他仪表盘是单统计量表示，类似于经典仪表盘的功能。 它们都使用相同的颜色方案，只需 glance 一眼即可快速指示系统健康状况。 可以说，底行可能是仪表盘的最佳示例，它使您能够 glance 一眼仪表板并知道一切是否健康（或不健康）。 这种类型的可视化通常是我放在顶级仪表板上的内容。 它可以在几秒钟内提供对系统健康状况的全面、高级别的理解。
火焰图
一种不太常见的可视化是火焰图，由 Netflix 的 Brendan Gregg 于 2011 年引入。 它不适合用于仪表板或快速观察高级系统问题； 通常在尝试理解特定的应用程序问题时看到它。 此可视化侧重于 CPU 和内存以及关联的帧。 X 轴按字母顺序列出帧，Y 轴显示堆栈深度。 每个矩形都是一个堆栈帧，包括正在调用的函数。 矩形越宽，它在堆栈中出现的次数就越多。 当尝试在应用程序级别诊断系统性能时，此方法非常宝贵，我敦促每个人都尝试一下。
工具选项
有几种商业警报选项，但由于这是 Opensource.com，我将仅介绍真实公司大规模使用的、您可以免费使用的系统。 希望您能够贡献新的和创新的功能，使这些系统变得更好。
警报工具
Bosun
如果您曾经使用计算机并遇到问题，那么您获得的帮助可能要归功于 Stack Exchange 系统。 Stack Exchange 围绕众包问答模式运行着许多不同的网站。 Stack Overflow 在开发人员中非常受欢迎，而 Super User 在运维人员中很受欢迎。 然而，现在有数百个网站，范围从育儿到科幻，从哲学到自行车。
Stack Exchange 在 Prometheus 及其 AlertManager 系统发布前后开源了其警报管理系统 Bosun。 这两个系统有很多相似之处，这是一件非常好的事情。 与 Prometheus 一样，Bosun 也是用 Golang 编写的。 Bosun 的范围比 Prometheus 更广泛，因为它可以与指标聚合之外的系统进行交互。 它还可以从日志和事件聚合系统中提取数据。 它支持 Graphite、InfluxDB、OpenTSDB 和 Elasticsearch。
Bosun 的架构由单个服务器二进制文件、OpenTSDB、Redis 等后端以及 scollector 代理组成。 scollector 代理自动检测主机上的服务并报告这些进程和其他系统资源的指标。 此数据被发送到指标后端。 然后，Bosun 服务器二进制文件查询后端以确定是否需要触发任何警报。 Bosun 也可以被 Grafana 等工具使用，通过一个通用接口查询底层后端。 Redis 用于存储 Bosun 的状态和元数据。
Bosun 的一个非常棒的功能是它允许您根据历史数据测试警报。 这是几年前我在 Prometheus 中错过的一个功能，当时我有想要发出警报的问题的数据，但没有简单的方法来测试它。 为了确保我的警报正常工作，我不得不创建并插入虚拟数据。 此系统减轻了非常耗时的过程。
Bosun 还具有显示简单图表和创建警报等常用功能。 它具有用于编写警报规则的强大表达式语言。 但是，它只有电子邮件和 HTTP 通知配置，这意味着连接到 Slack 和其他工具需要更多自定义（其文档涵盖了这一点）。 与 Prometheus 类似，Bosun 可以为这些通知使用模板，这意味着它们可以看起来像您希望的那样棒。 您可以使用所有 HTML 和 CSS 技能来创建任何人见过的最糟糕的电子邮件警报。
Cabot
Cabot 由一家名为 Arachnys 的公司创建。 您可能不知道 Arachnys 是谁或做什么的，但您可能已经感受到了它的影响：它构建了领先的基于云的金融犯罪打击解决方案。 听起来很酷，对吧？ 在之前的一家公司，我参与了与 “了解您的客户” 法律相关的类似职能。 大多数公司都会认为与恐怖组织有联系是一件非常糟糕的事情，例如，通过其系统转移资金。 这些解决方案还有助于防御不太残暴的罪犯，例如也可能对机构构成风险的欺诈者。
那么 Arachnys 为什么要创建 Cabot 呢？ 嗯，这有点像给每个人的圣诞礼物，因为它是一个圣诞节项目，构建它的原因是它的开发人员无法理解 Nagios。 真的，谁能责怪他们呢？ Cabot 是用 Django 和 Bootstrap 编写的，因此大多数人应该很容易为该项目做出贡献。 （另一个有趣的事实：这个名字来自创建者的狗。）
Cabot 的架构与 Bosun 类似，因为它不收集任何数据。 相反，它通过它正在警报的工具的 API 访问数据。 因此，Cabot 使用拉取（而不是推送）模型进行警报。 它访问每个系统的 API 并检索做出基于特定检查的决策所需的信息。 Cabot 将警报数据存储在 Postgres 数据库中，并且还使用 Redis 进行缓存。
Cabot 原生支持 Graphite，但它也支持 Jenkins，这在该领域很少见。 Arachnys 将 Jenkins 用作集中式 cron，但我喜欢将构建失败视为中断的想法。 显然，构建失败不如生产中断那么严重，但如果失败未解决，它仍然可以向团队发出警报并升级。 谁会在每次收到有关构建失败的电子邮件时实际检查 Jenkins？ 是的，我也是！
另一个有趣的功能是 Cabot 可以与 Google 日历集成以进行值班轮换。 Cabot 将此功能称为 Rota，Rota 是英国术语，表示花名册或轮换。 这很有意义，我希望其他系统能够进一步发展这个想法。 Cabot 不支持比主要和后备人员更复杂的功能，但肯定有增加附加功能的空间。 文档说，如果您想要更高级的功能，则应该考虑商业选项。
StatsAgg
StatsAgg？ 它是如何进入列表的？ 嗯，您不是每天都能遇到一家创建了警报平台的出版公司。 我认为这值得认可。 当然，Pearson 不再仅仅是一家出版公司了； 它有多个网站，并与 O'Reilly Media 合资。 但是，我仍然认为它是出版我的教科书和考试的公司。
StatsAgg 不仅仅是一个警报平台； 它也是一个指标聚合平台。 而且它有点像其他系统的代理。 它支持 Graphite、StatsD、InfluxDB 和 OpenTSDB 作为输入，但它也可以将这些指标转发到它们各自的平台。 这是一个有趣的概念，但随着中央服务负载的增加，可能存在风险。 但是，如果 StatsAgg 基础设施足够强大，即使后端存储平台发生中断，它仍然可以生成警报。
StatsAgg 是用 Java 编写的，仅由主服务器和 UI 组成，这最大限度地降低了复杂性。 它可以基于正则表达式匹配发送警报，并且专注于按服务而不是主机或实例发出警报。 它的目标是填补开源可观测性堆栈中的空白，我认为它做得很好。
可视化工具
Grafana
几乎每个人都知道 Grafana，并且许多人使用过它。 每当我需要一个简单的仪表板时，我都会使用它多年。 我之前使用的工具已被弃用，我对此感到非常不安，直到 Grafana 使其变得可以接受。 Grafana 是 Torkel Ödegaard 赠送给我们的。 与 Cabot 类似，Grafana 也是在圣诞节前后创建的，并于 2014 年 1 月发布。 在短短几年内，它已经走了很长一段路。 它最初是一个 Kibana 仪表板系统，Torkel 将其分叉成后来的 Grafana。
Grafana 的唯一重点是以更可用和更令人愉悦的方式呈现监控数据。 它可以原生从 Graphite、Elasticsearch、OpenTSDB、Prometheus 和 InfluxDB 收集数据。 有一个企业版，它使用插件来获取更多数据源，但是没有理由不能将其他数据源插件创建为开源的，因为 Grafana 插件生态系统已经提供了许多其他数据源。
Grafana 为我做了什么？ 它为理解我的系统提供了一个中心位置。 它是基于 Web 的，因此任何人都可以访问信息，尽管可以使用不同的身份验证方法对其进行限制。 Grafana 可以使用多种不同类型的可视化技术 glance 一眼提供知识。 但是，它已开始集成警报和其他传统上不与可视化结合的功能。
现在您可以直观地设置警报。 这意味着您可以查看图表，甚至可能查看显示由于系统某些降级而应触发警报的图表，单击要触发警报的图表，然后告诉 Grafana 将警报发送到哪里。 这是一个非常强大的补充，它不一定会取代警报平台，但它肯定可以通过提供关于警报标准的不同视角来帮助增强它。
Grafana 还引入了更多的协作功能。 用户长期以来一直能够共享仪表板，这意味着您不必为您的 Kubernetes 集群创建自己的仪表板，因为已经有几个可用的仪表板 - 其中一些由 Kubernetes 开发人员维护，另一些由 Grafana 开发人员维护。
围绕协作的最重要的补充是注释。 注释允许用户向图表的某一部分添加上下文。 然后，其他用户可以使用此上下文来更好地理解系统。 当团队处于事件中间，并且沟通和共同理解至关重要时，这是一个非常宝贵的工具。 将所有信息都放在您已经查看的位置，可以使知识更快速地在团队中共享。 在事后剖析（blameless postmortem）期间使用它也是一个不错的功能，当团队试图了解故障是如何发生的并更多地了解他们的系统时。
Vizceral
Netflix 创建了 Vizceral，以便在执行流量故障转移时更好地了解其流量模式。 与 Grafana 这种更通用的工具不同，Vizceral 服务于非常特定的用例。 Netflix 不再在内部使用此工具，并表示它不再积极维护，但它仍然会定期更新该工具。 我在这里重点介绍它主要是为了指出一种有趣的可视化机制以及它如何帮助解决问题。 值得在演示环境中运行它，以便更好地掌握概念并见证这些系统可以实现的功能。
评论已关闭。