🕴🏽 💣 ❄️ 关于类固醇的Zabbix：Sbertech的统一监控平台如何工作 👩🏾‍✈️ 🌮 🌋

哈Ha！我叫Sergey Prutskikh，负责Sberbank技术的监控方向。我们组织的主要目标是为Sberbank开发和测试软件产品。为此，该公司拥有大型的IT基础架构-将1.5万台服务器划分为大约1,500个测试环境，这些环境与500多个自动化系统相关。总共约有1万名专家与他们合作。

2015年，我们开始创建集中监控服务。而且，一切都不仅限于实施。在监控框架中，有必要制定出许多法规，说明以及Sbertech各个部门之间的关系。在这篇文章中，我将详细告诉您我们如何选择平台，创建一切的原理以及最终的结果。

项目的主要目标和思想

这是我们在项目中追求的目标：

获得有关IT基础架构规模和组成的可靠数据；
优化IT设施的使用；
降低支持和运营开发和测试环境的IT基础架构的成本；
支持IT基础架构以准备进行开发和测试；
及时通知专家有关测试环境工作中的问题；
对测试环境和工业AFM的合规性审核对于我们来说不是一项非常典型的任务；
用于测试结果报告的数据收集，可在测试的所有阶段提供关键参数的测量。

展望未来，我可以说，到目前为止，一个或另一个学位的所有目标都已经完成。还有一些相关问题，监控也有助于解决。

除了目标，我们还制定了原则和意识形态，在整个项目中我们都遵循这些原则：

用户满意度是监控的主要指标之一。在ITSMf 2017大会上，我谈到了监视IT基础架构，而第五条不在该报告中：“请勿强迫您的员工使用监视系统。” 关键是要激励而不是义务。这是通过正确构建的KPI实现的。在服务开始时，此类KPI可能尚未出现。但是，从监控的第一天开始，使潜在客户受益就非常重要。
优化的最短时间。为此，我们使用敏捷元素。它们有助于尽快提供新功能并收到客户的反馈。
该系统的开放性，即为了改进（在创建单个积压订单时表示），任何员工都可以写的请求以及在提供信息方面-我们的服务允许您获取有关监视配置的信息，通常该信息是隐藏的。
高度融入日常工作。我们的首要任务是实现用户每天所需的功能。这有助于在相对较短的时间内在公司内普及监控服务。

监控系统的选择

在我参与的几乎所有项目中，迟早都会弹出一个表格，比较各种系统的功能，其中特定系统具有明显的优势。

我认为，这样的比较分析不能在立即开始使用监视服务之前进行，甚至更重要的是，不值得根据此分析做出选择一个或另一个解决方案的决定。只要贵公司的系统至少在短时间内无法工作，就不可能明确判断贵公司需要哪些特定功能。如果您出于某种原因要更改监视系统，则此类表可以提供帮助。

与其他Zabbix安装的比较

您可以谈论很多有关如何比较多个监视系统安装大小的问题，但是我认为为此选择的所有特征都是相当主观的。为了使您对我们的安装规模有一个更准确的了解，我决定举一些其他公司提供类似服务的示例，Zabbix代表在Highload会议上谈到了这些服务。

如您所见，Sbertech中的Zabbix实例并不比大型安装逊色很多，就总负载而言，它与它们相当。

Zabbix的好处

在2017年下半年，我们进行了Zabbix试点以监视PROM基础结构。然后，我们制定了一些定性标准，这些定性标准归因于Zabbix的绝对优势：

开源的 无限的处理和定制可能性。
机制的开放性和指标收集的来源。 在商业企业解决方案中，许多指标是无法理解的-各种僵尸网络，内存泄漏，甚至连供应商的技术支持也常常无法解释。 Zabbix没有这样的问题-您始终可以清楚地说出它如何收集某些指标。因此，系统管理员提高了系统的信誉。
相对容易扩展 -主要是由于引入了其他代理服务器，您可以将部分负载转移到这些代理服务器。如果达到一个实例的性能极限，则可以在一个可视化系统（Grafana）下提高第二个实例并将两者结合起来。
酷API-我认为，这是Zabbix的主要优势之一。高质量，完善且易于理解的API为与相关系统，自动化等集成提供了巨大的机会。
监视动态对象是一件小事，但是很好。在Zabbix中，此监视既简单又直观，使您可以非常快地获得良好的结果。动态对象是在服务器生命周期中出现或消失的任何对象：文件系统，网络接口等。因此，需要使这些对象的设置和监视自动化。
相对较少的组件。 在商业解决方案中，每个组件都是一个单独的子系统，具有自己的基础，必须单独安装。 Zabbix是一个单一系统，其中所有监视方法都集中在一起：代理，无代理，网络和其他（仅14种）。
使用Grafana进行数据可视化。 与Grafana的集成使构建图形和创建真正方便的仪表板成为可能。
监视IT服务的可用性。 Zabbix有一个内置子系统，可以计算IT服务的可用性以供将来在SLA中使用。
创建指标及其阈值的灵活性。 在这里，Zabbix有足够的机会配置复杂的监视指标：
-首先，它是计算得出的指标的创建：根据几个简单的指标，将计算一个复杂的指标。
- 可以对指标值进行预处理 -例如，当您将一些大数据数组加载到Zabbix中时，然后在将特定指标放入数据库中之前，Zabbix会分析该数组并准确提取要保存为指标的数据。
- 主指标。 可以在一个调查中将一个对象上的一组数据收集到一个大型度量中，然后将其用作其他度量的数据源。这使您可以减少查询数量并及时同步所有指标的集合。
内部监控的可能性。 Zabbix作为开源产品存在性能问题。但是，经过深思熟虑的内部监视系统有助于快速解决这些问题。

Zabbix的缺点

公平地讲，我不禁提到Zabbix的主要缺点。您还可以列出其中一个体面的清单：

后端自动化程度低。 我将保留一下我没有机会尝试所有DBMS变体的机会。我们公司使用Oracle DBMS作为Zabbix后端。大规模操作可能要花费一个多小时的时间-例如，更新或更改指标，该指标与大量对象（1.5万个网络节点）相关。
缺少内置的监视代理程序管理工具。 这样的产品可在商业产品中获得。 Zabbix还没有这个。甚至没有针对代理的工具包更新。当然，一切都可以独立完成，但是最好将这些功能立即使用。
到目前为止，监视IT服务可用性的工作量较低。 有了监视非常棒，但是还需要进一步开发。现在，不可能以某种方式将用户访问限制在服务资源模型（以下称为CPM）的任何单独部分中。如果CPM树很大，则Web界面开始变慢。而且在该子系统中定制可用性计算的可能性仍然很小。
长时间更新。 最近的数据库更新花了我们大约8个小时。目前，监视服务不可用。或者，您可以请求支持脚本并单独更新。
内置可视化子系统的适度功能。 Grafana解决了这个问题，但是内置的可视化功能还有很多不足之处。
集成的DBMS监视（ODBC）。 事实是，每次对度量进行轮询时，此类监视都会为Zabbix打开一个单独的连接。并且，如果数据库很大（收集了大量指标），则其中的连接池可能已满，并且数据库将停止响应，包括针对目标系统的响应。 Zabbix有一个替代的监视工具（例如，DBforBIX），但是为大量对象设置它是一项相当费力的任务。另外，您需要编写一个单独的自动化程序。
IT基础架构缺乏库存灵活性。 一方面，很高兴拥有它。另一方面，对于任何监视对象，它看起来像是一个单独的选项卡，在该监视对象上有一组具有硬编码名称的硬设置清单字段。为了进行某些更改，您需要进入前端的源代码。更改这些字段的数量和大小也是不可能的-在下次更新中可能会破坏某些内容。
缺乏自动构建网络地图的功能。 为了进行比较，我们可以引用HP OpenView网络节点管理器，它非常能够以自动模式构建网络拓扑图。 Zabbix将必须手动构建所有内容。也许由于这个原因，实际上我们不需要这种功能。
榜样缺乏灵活性。 Zabbix仅提供具有固定功能的四个用户角色。此外，没有开箱即用的方式来限制用户对Zabbix API的访问。也就是说，如果用户有权访问前端，那么他将自动有权访问API。对于我们来说，这导致了一个事实，即请求处理不力的用户严重加载了系统。此外，无法授予用户访问权限，例如，无需访问即可读取度量标准，也无法编辑监视对象的设置。

系统架构

现在谈谈定量指标和我们系统的体系结构。

目前，有超过1.6万个对象（主要是服务器）受到监视，总共收集了将近两百五十万个指标。它们在系统上的总负载约为每秒19000个值。所有监视对象分布在1800多个设备组中，其中绝大多数对应于特定的测试环境。当前，系统中注册了1000多名用户，这些用户分为365个功能组。

如您所见，我们非常关注设备和用户的分组分布。这使您可以大大提高我们服务发出警报的准确性。

总共，我们有三个Zabbix实例。该图显示了其中最大的架构，该架构监视开发和测试的主要IT基础架构。另一个实例负责监视监视基础结构。第三实例与我们一起用于开发和测试新的监视工具。主实例的整个结构是基于VMWare虚拟化的。通常，如果可能的话，最好不要使用任何虚拟化系统，因为在虚拟基础架构的情况下搜索和解决性能问题要困难得多。

后端基于Oracle Active Data Guard，由两个数据库组成-主数据库和副本数据库。我们有三个方面：

对于管理任务-它被配置为执行繁重，复杂和长期的操作，从而使服务器负载沉重；
自定义-具有更严格的设置，不允许用户使主监视系统过载过多；
为了进行报告，它查看副本，并已调整为与只读数据库进行交互。 Grafana连接到它，从而提供监视数据的高质量可视化。

实施功能

在这个故事中，我决定不专注于几乎所有监视中实现的基本功能-修复崩溃，收集有关IT系统性能或可用性的信息。我将专注于我们服务的特色。

这些功能主要包括典型任务的高度自动化。实际上，我们实际上没有花费时间来设置用于监视的服务器，提供对监视结果的访问，而是主要专注于开发服务并向其中添加新的非标准功能。从监视服务投入试运行以来，开发了200多个自动化脚本，这在很大程度上帮助了我们。

但是在Zabbix中注册代理之前，仍然需要安装该代理。正如我在上面所写，Zabbix的缺点之一是缺少监视代理程序管理工具。因此，要安装代理，我们在DevOps流程中安排了一个单独的工作。下图显示了代理安装图。

我们有两个主要切入点。这是Python脚本-通过REST API，它将有关要在其上安装或更新代理的主机，其他变量列表以及需要在Ansible上运行的剧本的名称的信息传递给作业Jenkins。或者默认数据可以来自Bitbucket。但是在詹金斯，可以根据我们传递的变量完全替换它们。例如，这有助于我们更新受不同代理服务器监视的代理。我们过程的独特之处在于Zabbix代理配置几乎是动态形成的。

报告中

在项目开始时就已经很清楚，由Zabbix工具提供的标准报告工具将无法使我们满足所有需求。在这方面，基于微服务架构，实现了一个单独的报告子系统，这大大扩展了基本监视报告的功能。现在，我们有二十多个报告在运行。以下是一些示例以及正在实现的目标：

警报

在整个服务过程中，电子邮件警报不断发展。这是他们目前的样子：

存在有关问题及其状态以及监视对象的信息。有指向相关指标和事件的链接，用于描述问题的字段，与说明的链接以及反馈表。对于更严重的事故，我们当然也有SMS分发。

这种信息丰富的警报使我们能够最大程度地减少大多数用户与Zabbix本身的交流。足以接收此邮件列表。我们对用户进行了很好的分组-有365个群组可供1080人使用。因此，时事通讯实际上是点缀的-因此，并不令人讨厌。我们的许多用户几乎都忘记了我们实际上拥有的Zabbix-他们使用Grafana新闻通讯和可视化系统。