5个系统管理员常用的警报和可视化工具

　　这些开源工具帮助用户了解系统行为和输出，并为潜在问题提供警报。

　　你可能使用警报和可视化工具，为什么我要将它们作为可观察性工具进行讨论，特别是某些系统将可视化作为特征?

　　可观察性来自控制理论，描述了我们根据其输入和输出理解系统的能力。本文重点介绍可观察性的输出组件。

　　警报和可视化工具分析系统的输出，并提供这些输出的结构化表示。警报基本上是对负系统输出的综合理解，并且可视化是消除用户理解的消歧结构化表示。

　　一、常见警报和可视化类型

　　警报

　　让我们首先介绍哪些不是警报。如果人员响应者无法对问题采取任何措施，则不应发送警报。这包括发送给多个人的警报，只有少数人可以响应，或者系统中的每个异常都触发警报的情况。这导致警报疲劳并且接收器忽略特定介质内的所有警报，直到系统升级到尚未饱和的介质。

　　例如，如果运维每天从警报系统接收数百封电子邮件，该运维将很快忽略来自警报系统的所有电子邮件。只有当他或她遇到问题，由客户发送电子邮件或由老板打电话时，运维才会回复真实事件。在这种情况下，警报已失去其意义和用途。

　　警报不是一个恒定的信息流或状态更新。它们旨在传达系统无法自动恢复的问题，并且它们仅发送给最有可能恢复系统的个人。超出此定义的所有内容都不是警报，只会损害员工和公司文化。

　　每个人都有一组不同的警报类型，因此我不会讨论优先级(P1-P5)或使用“信息”，“警告”和“严重”等字样的模型。相反，我将描述复杂系统事件响应中出现的通用类别。

　　你可能已经注意到我提到了一个“信息”警报类型，警报不应该是信息性的。嗯，不是每个人都同意，但如果没有发送给任何人，我不会认为是警报。它是许多系统称为警报的数据点。它代表了一些应该知道但没有响应的事件。它通常是警报工具的可视化系统的一部分，而不是触发实际通知的事件。Mike Julian在他的“实用监控”一书中介绍了警报的这一方面和其他方面。这是该领域工作的必读书。

　　非信息警报由可以响应或需要操作的类型组成。我将这些分为两类：内部中断和外部中断。(大多数公司都有两个以上的级别来确定其响应工作的优先级。)由于对每个用户的影响通常是未知的，因此系统性能下降被认为是此模型的中断。

　　内部中断的优先级低于外部中断，但仍需要快速响应。它们通常包括公司员工使用的内部系统或仅对公司员工可见的应用程序组件。

　　外部中断包括任何会立即影响客户的系统中断。这些不包括阻止释放系统更新的系统中断。它们确实包括面向客户的应用程序故障，数据库中断和网络分区，如果这两者都可能影响用户，则会损害可用性或一致性。它们还包括可能不会对用户产生直接影响的工具中断，因为应用程序继续运行，但这种透明的依赖性会影响性能。这在系统使用某些外部服务或数据源时很常见，这些服务或数据源对于完整功能不是必需的，但是当应用程序执行重试或处理来自此外部依赖项的错误时可能会导致延迟。

　　可视化

　　有许多可视化类型，我不会在这里全部介绍它们。这是一个迷人的研究领域。在我职业生涯的数据分析方面，学习和应用这些知识是一项持续的挑战。我们需要提供复杂系统输出的简单表示，以便最广泛地传播信息。Google Charts和Tableau提供了多种可视化类型。我们将介绍最常见的可视化和一些创新解决方案，以便快速了解系统。

　　折线图

　　折线图可能是最常见的可视化方式。随着时间的推移，它可以很好地理解系统。度量系统中的折线图将为每个唯一度量标准或某些度量标准聚合提供一条线。当同一个仪表板中存在大量指标时，这会让人感到困惑(如下图所示)，但大多数系统可以选择要查看的特定指标，而不是让所有指标都可见。此外，如果异常行为足以逃避正常操作的噪音，则很容易发现异常行为。下面我们可以看到可能表示异常行为的紫色，黄色和浅蓝色线条

　　折线图的另一个特征是可以经常堆叠它们以显示关系。例如，可能希望单独查看每个服务器上的请求，但也可以聚合查看。这使你可以了解整个系统以及同一图表中的每个实例。

　　热力图

　　另一种常见的可视化是热力图。在查看直方图时很有用。此类可视化类似于条形图，但可以在条形图中显示表示整体度量标准的不同百分位数的渐变。例如，假设正在查看请求延迟，并且希望快速了解所有请求的总体趋势和分布。热力图对此非常有用，它可以使用颜色快速浏览每个部分的数量。

　　下面的热力图显示了图表中心线周围较高的浓度，每个时间段的垂直分布可以很容易理解。我们可能想要查看分布变宽的几个时间点，而其他时间点在14:00时相当紧张。此分布可能是负面的绩效指标。

　　压力表

　　我将在这里介绍的最后一个常见可视化是仪表，它可以帮助用户快速了解单个指标。仪表可以代表单个指标，例如车速表代表行驶速度，或者汽油表代表汽车中的汽油量。与燃气表类似，大多数监控仪表清楚地表明什么是好的，什么不是。通常(如下图所示)，好用绿色代表，橙色代表性差，红色代表“一切都破坏”。下面的中间一行显示了传统的仪表。

　　此图像显示的不仅仅是传统的仪表。其他仪表是单一的统计表示，类似于经典仪表的功能。它们都使用相同的配色方案，只需一瞥即可快速指示系统健康状况。可以说，底行可能是衡量仪表的最佳示例，它允许您浏览仪表板并知道一切都是健康的(或不是)。这种类型的可视化通常是我放在顶层仪表板上的。它可以在几秒钟内全面，高层次地了解系统运行状况。

　　火焰图

　　不太常见的可视化是由Netflix的Brendan Gregg于2011年推出的火焰图。它不是仪表板或快速观察高级系统问题的理想选择。在尝试理解特定的应用程序问题时通常会看到它。此可视化关注于CPU和内存以及关联的帧。 X轴按字母顺序列出帧，Y轴显示堆栈深度。每个矩形都是一个堆栈帧，包括被调用的函数。矩形越宽，它在堆栈中出现的越多。在尝试在应用程序级别诊断系统性能时，此方法非常有用，我建议大家尝试一下。

　　工具选择

　　报警有几种商业选择，但由于这是Opensource.com，我将仅涵盖真实公司大规模使用的系统，可以免费使用。希望你能够贡献新的和创新的功能，使这些系统更好。

　　二、警报工具

　　1.Bosun

　　如果你曾经使用计算机做过任何事情并且卡住了，那么你收到的帮助可能归功于Stack Exchange系统。Stack Exchange围绕众包问答模型运行许多不同的网站。Stack Overflow非常受开发人员欢迎，超级用户很受操作的欢迎。然而，现在有数百个网站，从育儿到科幻，哲学到自行车。

　　Stack Exchange开源其警报管理系统Bosun，同时Prometheus及其AlertManager系统也已发布。这两个系统有许多相似之处，这是一件非常好的事情。像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技能创建任何人见过的最糟糕的电子邮件提醒。

　　2.Cabot

　　Cabot是由一家名为Arachnys的公司创建的。你可能不知道Arachnys是谁或它做了什么，但你可能已经感受到它的影响：它构建了领先的基于云的解决金融犯罪的解决方案。这听起来很酷，对吗?在以前的公司，我参与了“了解你的客户”法律的类似职能。大多数公司认为与恐怖组织联系是一件非常糟糕的事情，例如，通过他们的系统汇集资金。这些解决方案也有助于防范对欺诈者等不那么残暴的罪犯，也可能对该机构构成风险。

　　为什么Arachnys创造abot?嗯，这对每个人来说都是一个圣诞礼物，因为这是一个圣诞节项目，因为它的开发人员无法围绕Nagios。真的，谁可以怪他们? Cabot是用Django和Bootstrap编写的，因此对大多数人来说应该很容易为项目做出贡献。 (另一个有趣的事实：名字来自创作者的狗。)

　　Cabot架构与Bosun类似，因为它不收集任何数据。相反，它通过其提醒的工具的API访问数据。因此，Cabot使用拉动(而非推动)模型进行警报。它可以访问每个系统的API，并根据特定的检查检索所需的信息。 Cabot将警报数据存储在Postgres数据库中，并且还具有使用Redis的缓存。

　　Cabot原生支持Graphite，但它也支持Jenkins，这在该领域很少见。Arachnys使用Jenkins就像一个集中式的cron，但我喜欢这种处理构建失败的想法，比如停机。显然，构建失败并不像生产中断那么重要，但如果失败未得到解决，它仍然可以提醒团队并升级。每次收到有关构建失败的电子邮件时，谁真正检查Jenkins?我也是!

　　另一个有趣的功能是Cabot可以与Google日历集成以进行随叫随到的轮换。Cabot将此功能称为罗塔(Rota)，这是英国名单或轮换名词。这很有意义，我希望其他系统能够进一步理解这个想法。Cabot不支持比主要和备用人员更复杂的任何东西，但肯定有额外功能的空间。文档说如果你想要更先进的东西，你应该看一个商业选择。

　　3.StatsAgg

　　StatsAgg?这是怎么做到的?好吧，并不是每天都会遇到一家创建了警报平台的出版公司。我认为值得认可。当然，皮尔森不再只是一家出版公司了;它有几个网站和O'Reilly Media的合资企业。但是，我仍然认为它是出版我的教科书和考试的公司。

　　StatsAgg不仅仅是一个警报平台;它也是一个指标聚合平台。它有点像其他系统的代理。它支持Graphite，StatsD，InfluxDB和OpenTSDB作为输入，但它也可以将这些指标转发到各自的平台。这是一个有趣的概念，但随着中央服务的负载增加，可能存在风险。但是，如果StatsAgg基础结构足够强大，即使后端存储平台出现中断，它仍然可以生成警报。

　　StatsAgg是用Java编写的，只包含主服务器和UI，可以将复杂性降至最低。它可以基于正则表达式匹配发送警报，并专注于服务而不是主机或实例的警报。它的目标是填充开源可观察性堆栈中的空白，我认为它做得很好。

　　三、可视化工具

　　1.Grafana

　　几乎每个人都知道Grafana，很多人都使用过它。每当我需要一个简单的仪表板时，我已经使用了它多年。我之前使用过的工具已经弃用了，在Grafana做好之前我对此非常不满。Grafana被Torkel?degaard创建。像Cabot一样，Grafana也是在圣诞节期间创建的，并于2014年1月发布。在短短几年内它已经走过了漫长的道路。它起源于Kibana仪表板系统，Torkel将其分为Grafana。

　　Grafana的唯一重点是以更加实用和令人愉悦的方式呈现监控数据。它可以原生地从Graphite，Elasticsearch，OpenTSDB，Prometheus和InfluxDB收集数据。有一个企业版使用插件来获取更多数据源，但是没有理由将这些其他数据源插件创建为开源，因为Grafana插件生态系统已经提供了许多其他数据源。

　　Grafana为我做了什么?它为理解我的系统提供了一个中心位置。它是基于Web的，因此任何人都可以访问这些信息，尽管可以使用不同的身份验证方法对其进行限制。 Grafana可以使用许多不同类型的可视化提供一目了然的知识。但是，它已开始集成警报和其他传统上与可视化相结合的功能。

　　现在，你可以直观地设置警报。这意味着可以查看图表，甚至可以查看由于系统性能下降而应该触发警报的位置，单击要触发警报的图表，然后告诉Grafana将警报发送到何处。这是一个非常强大的补充，不一定会取代警报平台，但它肯定可以通过提供警报标准的不同视角来帮助增强它。

　　Grafana还引入了更多协作功能。用户已经能够长时间共享仪表板，这意味着不必为Kubernetes集群创建自己的仪表板，因为有几个已经可用，其中一些由Kubernetes开发人员和其他人由Grafana开发人员维护。

　　协作中最重要的补充是注释。注释允许用户将上下文添加到图形的一部分。然后，其他用户可以使用此上下文更好地理解系统。当团队处于事件中并且沟通和共同理解至关重要时，这是一个非常宝贵的工具。将所有信息都放在你正在查看的位置，这样可以更快地在整个团队中共享知识。当团队试图了解失败的原因并了解他们的系统时，这也是一个很好的功能，可用于无可指责的事后。

　　2.Vizceral

　　Netflix创建了Vizceral，以便在执行流量故障转移时更好地了解其流量模式。与Grafana不同，Grafana是一种更通用的工具，Vizceral提供了非常具体的用例。Netflix不再在内部使用此工具，并表示不再主动维护，但它仍会定期更新。我在这里强调它主要是指出一个有趣的可视化机制以及它如何帮助解决问题。值得在演示环境中运行它，以便更好地掌握概念并见证这些系统的可能性。