这些开源工具可以帮助用户通过输出了解系统的运行状态，并对可能出现的潜在问题进行预警。您可能已经知道（或猜测）警报和可视化工具的用途。先说说为什么要讨论这样的工具，甚至有些系统专门把可视化作为一个独特的功能。可观察性的概念来自控制理论，它描述了我们理解系统输入和输出的能力。本文将重点关注具有可观察性的输出组件。报警可视化工具可以分析其他系统的输出，然后将输出信息以结构化的方式呈现出来。告警实际上是对系统异常状态的描述，可视化是一种结构化的表示，让用户直观的了解。常见的视觉告警和警示首先要明确warning警示的含义。在人们无法响应警报内容的情况下不应发送警报——包括发送给许多人但只有少数人可以响应的警报，以及系统中的每个异常都触发的警报。由于这会造成警报疲劳，警报接收者往往会忽略过多的警报，直到系统恶化到不经常报告警报的程度。例如，如果管理员每天收到来自警报系统的数百封警报电子邮件，他很容易忽略所有来自警报系统的电子邮件。除非他真的看到问题，或者被客户或上级询问，否则管理员不会再关注告警信息。在这种情况下，报警就失去了它本来的意义和用途。警报不是连续的信息流或状态更新。警报的目的是暴露系统无法自动恢复的问题，警报应该只发送给最有可能解决问题的人。超出这个定义的任何东西都不应作为警告，否则会对实际工作产生不良影响。不同的报警系统会有自己的报警类型，所以不能用优先级（P1-P5）或“信息”、“警告”、“严重”等词来概括。下面我将介绍一些新兴的复杂系统事件响应中常见的事件分类。刚才我提到了一个告警类型的“信息”，其实告警不应该是一个信息，虽然有些人可能不这么认为。但是我觉得如果不向任何人发送警报，那它不应该是警报，而只是一些在许多系统中被认为是警报的数据点，代表一些应该知道但不需要响应的事件。它应该是警报可视化工具的一部分，而不是触发警报的事件。《实用监控》是该领域的必读书籍，其作者MikeJulian在书中介绍了自己对报警的看法。非信息性警报表示需要响应并需要采取措施的警报。我将这些警报大致分为内部故障和外部故障，对于大多数公司来说，通常有两个以上的级别来确定响应警报的优先级。系统降级是一种失败，因为它对用户的影响通常是未知的。内部故障的优先级低于外部故障，但也需要快速响应。内部故障通常包括公司员工使用的内部系统故障或仅对公司员工可见的应用程序故障。外部故障包括对业务有直接影响的任何系统故障，但不包括影响系统更新的故障。外部故障一般包括应用故障、数据库故障、网络故障等导致客户面临的系统可用性或一致性故障，影响用户的正常使用。不直接影响用户的依赖组件故障也属于外部故障。随着应用程序的持续运行，一旦依赖的组件出现故障，系统的性能也会受到影响。这种情况对于使用一些外部服务或数据源的系统来说很常见。尽管这些外部服务或数据源可能不涉及系统的主要功能，但系统在处理相关依赖组件时可能会出现错误。明显的延迟。可视化的种类很多，就不一一细说了。这是一个有趣的研究领域，以我多年的数据分析经验来看，学习和应用可视化知识是相当具有挑战性的。我们需要将复杂的系统输出以直观的方式展示给他人，以便有效地传播信息。GoogleCharts和Tableau都提供了许多可视化工具。下面介绍了一些最常见的可视化创新解决方案。折线图折线图可能是最常见的可视化方式，它可以让用户按照时间维度直观地了解系统的情况。系统中的每个单个或聚合指标将在图中以虚线表示。但是，当同一个图表中有多条折线时，可能会影响阅读（如下图所示），所以在大多数情况下，您可以选择只查看其中的几条折线，而不是让所有折线同时显示。如果指标的值波动超过正常值，则很容易发现。比如下图中异常的紫线、黄线、淡蓝线。折线图的另一个用途是堆叠多条线以显示它们之间的关系。例如，要通过折线图反映服务器请求的数量，您可以单独查看每个服务器上的请求，也可以将它们聚合在一起。这提供了查看整个系统以及同一图表中的每个实例的灵活性。热图的另一种常见可视化是热图。热力图类似于柱状图，也可以在柱状图的基础上显示某一部分在整体中所占比例的变化。例如，在查看网络请求时延时，可以通过热图快速查看所有网络请求的整体趋势和分布情况。另外，它可以用不同的颜色来表示不同部分的数值。在下面的热力图中，通过每个时间段的色块数量在垂直方向上的分布，可以清楚地看到大部分数据都集中在整个范围的中心。我们还可以发现，大部分时间段的色块分布比较松散，而14:00-15:00这段时间分布较密集，可能是不健康的状态。仪表图另一种常见的可视化方式是仪表图，通过仪表图用户可以快速了解单个指标。仪表一般用于显示单一的指标，例如车速表代表汽车的行驶速度，燃油表代表油箱中的汽油量等。大多数仪表图都有一个共同点，那就是它们会划分所显示指标的相应状态。如下图，绿色代表正常状态??，橙色代表不良状态，红色代表极差状态。下图中间一行模拟了真实仪器的显示。上图中，除了常规的仪表样式展示外，还有更直接的数据展示方式。采用相同的配色方案，一眼就能看出各个指标的状态，这与仪器的特性相似。因此，底线可能是显示仪器图形的最佳方式。用户无需仔细阅读即可大致了解各指标的不同状态。这种可视化是我最常使用的，几秒钟内，我就可以全面了解系统各个方面的运行情况。火焰图火焰图由Netflix的BrendanGregg于2011年发起，是一种不太常见的可视化。它不像仪表图那样可以快速从图中获取关键信息，通常只有在需要解决一个应用程序的问题时才会使用这种图。火焰图主要用来表示CPU、内存和相关帧。X轴按字母顺序一一列出帧，而Y轴表示堆栈的深度。图中的每个矩形都是一个堆栈框架，用于标识被调用的函数。矩形越宽，它出现在堆栈中的频率就越高。在分析系统性能问题时，火焰图可以发挥很大的作用，不妨试试看。工具选择在告警工具方面，市面上有几款相当不错的工具。但由于这是一篇介绍开源技术的文章，我将只介绍已经被广泛使用的免费工具。我希望你也能为这些工具贡献你自己的代码，使它们变得更好。警报工具Bosun如果您的计算机出现问题，您可以通过StackExchange在线找到解决方案。StackExchange在众包问答模型上运行着许多不同类型的网站。其中有深受开发者欢迎的StackOverflow，也有在运维方面颇有名气的SuperUser。此外，StackExchange涵盖了从育儿经验到科幻小说，从哲学讨论到自行车论坛的方方面面。StackExchange开源了其告警管理系统Bosun，同时发布了Prometheus及其AlertManager系统。这两个系统有一些共同点。Bosun和Prometheus一样是用Golang开发的，但是Bosun比Prometheus更强大，因为它可以通过指标聚合以外的方式与系统交互。Bosun还可以从日志和事件收集系统中提取数据，并支持Graphite、InfluxDB、OpenTSDB和Elasticsearch。Bosun的架构由单个服务器二进制文件、后端（例如OpenTSDB、Redis和scollector代理）组成。scollector代理自动检测主机上运行的服务并报告这些进程和其他系统资源。这些数据将被发送到后端。然后Bosun的二进制服务文件会查询后台，判断是否需要触发告警。也可以通过Grafana等工具通过通用接口查询Bosun的底层后端。Redis用于存储Bosun的状态信息和元数据。Bosun有一个非常巧妙的功能，就是可以根据历史数据来测试告警。这是我几年前使用Prometheus时非常需要的功能。当时我有一个异常数据需要报警，但是没有简单的方法可以测试。为了保证报警能够正常触发，我不得不创建相应的数据进行测试。但是，Bosun大大缩短了这一步的耗时。Bosun甚至涵盖了所有常用功能，包括简单的图形表示和警报创建。它还带有用于编写警报规则的强大的表达式语言。但是Bosun默认只自带邮件通知配置和HTTP通知配置，所以如果需要对接Slack或者其他工具，需要更大程度的自定义配置（在它的文档中）。与Prometheus类似，Bosun也可以使用模板通知，您可以使用HTML和CSS来创建您需要的电子邮件通知。CabotCabot是由Arachnys公司开发的。您可能不了解Arachnys，但它很有影响力：Arachnys构建了一个先进的基于云的解决方案来预防金融犯罪。我也曾在之前的公司参与过诸如了解你的客户(KYC)之类的工作。大多数公司会认为与恐怖组织有关联会产生相当糟糕的后果，因为恐怖组织可能会使用他们的系统来筹集资金。这些解决方案将有助于防止欺诈类犯罪，此类犯罪虽然相对较小，但仍会对组织构成风险。Arachnys为什么要开发Cabot？这真的只是因为Arachnys的开发者对Nagios不是很熟悉。卡博特的出现对很多人来说是个好消息。它是基于Django和Bootstrap开发的，所以如果你想为这个项目做出自己的贡献，门槛并不高。（同样值得注意的是，Cabot这个名字来自开发人员的狗。）与Bosun一样，Cabot不收集数据，而是使用监控对象的API提供的数据。因此，Cabot警报的模型是拉式而非推送式。它访问各个监控对象的API，根据特定的指标获取需要的数据，然后将告警数据使用Redis缓存，然后持久化存储在Postgres数据库中。Cabot一个不太常见的特性是它原生支持Graphite，但也支持Jenkins。Jenkins在这里被看作是一个中心化的定时任务，它会像对待失败一样对待构建失败。构建失败当然没有系统故障那么紧急，但是一旦出现构建失败，团队还是需要采取措施进行处理。毕竟，并不是每个人在收到构建失败的电子邮件时都会亲自检查Jenkins。Cabot的另一个有趣的功能是它可以访问GoogleCalendar来安排值班人员。这个称为Rota的功能非常有用。希望其他报警系统也能加入类似的功能。Cabot目前仅支持主副触点的排列，但仍有改进空间。它自己的文档还提到，如果需要完整的功能，则应考虑付费解决方案。StatsAggPearson作为开发StatsAgg警报平台的出版公司，这是极为罕见的，当然也令人钦佩。此外，Pearson还经营着其他几个网站以及与O'ReillyMedia的合资企业。但我仍然会将其视为一家出版教学书籍的公司。StatsAgg除了是一个告警平台，还是一个指标聚合平台，甚至有点类似于其他系统代理。StatsAgg支持Graphite、StatsD、InfluxDB、OpenTSDB的数据输入，也支持转发到各个平台。但随着中央服务的负载不断增加，风险也随之增加。但是，如果StatsAgg的基础设施足够强大，即使后端存储平台出现故障，也不会影响生成警报的过程。StatsAgg是用Java开发的，为了尽可能降低复杂性，它只包含主要服务和一个UI。StatsAgg支持基于正则表达式匹配发送警报，它更侧重于服务端警报而不是基于服务器的警报。我认为它填补了开源监控工具的空白，这是它自己的目标。可视化工具GrafanaGrafana众所周知并被广泛采用。每当我需要使用数据面板时，我总是会想到它，因为它比我用过的任何同类产品都要好。Grafana由Torkel?degaard开发，与Cabot一样，也是在圣诞节前后开发并于2014年1月发布的。在短短几年内，它已经取得了长足的进步。Grafana是基于Kibana开发的，Torkel开了一个新的分支，并命名为Grafana。Grafana注重实用性和数据呈现的美观性。它以原生方式从Graphite、Elasticsearch、OpenTSDB、Prometheus和InfluxDB收集数据。另外还有Grafana商业版插件可以获取更多数据源的数据，但是其他数据源插件也不是没有开源版本。Grafana的插件生态已经提供了各种数据源。Grafana能做什么？Grafana提供了一种了解系统的集中方式。它通过网络显示数据，任何人都有机会访问相关信息。当然，也可以使用身份验证来限制访问。Grafana使用各种可视化来提供对系统的一目了然的了解。Grafana还支持不同类型的可视化，包括集成警报可视化的能力。现在您可以更直观地设置警报。使用Grafana，您可以查看图表，您可以看到由于系统性能下降而触发警报的位置，单击您希望触发警报的位置，并告诉Grafana将警报发送到哪里。这是对警报平台的一个非常强大的补充。报警平台不一定会因此而被取代，但报警系统一定会得到更多的启发和发展。Grafana还引入了许多团队协作功能。数据平面可以在不同的用户之间共享，你不再需要为Kubernetes集群创建单独的数据平面，因为一些由Kubernetes开发人员和Grafana开发人员共同维护的数据平面已经可用。团队协作过程中的一个重要功能是注释。注释功能允许用户为图表添加上下文，以便其他用户可以通过上下文更直观地理解图表。当团队成员在处理一个事件，需要沟通和理解时，这个功能就非常重要。在需要的地方拥有所有相关信息，可以在整个团队中快速达成共识。当团队需要调查故障原因并确定事件的责任时，此功能会派上用场。VizceralVizceral由Netflix开发，用于在发生故障时更好地了解交通状况。Grafana是一个更通用的工具，而Vizceral是特定领域的。尽管Netflix表示内部不再使用Vizceral，也不再积极维护它，但Vizceral仍会定期更新。我在这里介绍这个工具主要是介绍它的可视化机制，以及如何使用它来辅助解决问题。您可以在示例环境中使用它，以更好地掌握此类系统的特点。
