Geekly articles weekly

Zabbix审查：如何组织代码审查以监视配置

代码审查-采用灵活的开发方法的工程实践。 这是对代码的分析（检查），以识别代码编写风格中的错误，缺点，差异并了解代码是否可以解决任务。



今天，我将讨论我们如何组织审查流程来监控Zabbix中的配置。 本文对于在大型团队中和单独使用Zabbix监视系统的人员都将很有用，即使您有“十个主机，有什么要复习”。


我们要解决什么问题


为了监控我们的内部服务和构建基础架构，我们使用Zabbix。 我们有命名约定- 名称约定 （我们使用带有角色突出显示的角色模型，用于监视的Profile模板），但是没有专门的监视团队（有高级工程师在监视事务方面“吃狗了”），有工程师和初级工程师，〜 500个主机，约150个模板（小型但非常动态的基础结构）。


该基础结构用于支持公司的开发流程并使之自动化 ，除了它的支持外，我们还开发自动化和集成工具，因此我们对内部开发流程缺乏经验和了解。


随着员工数量的增加以及监视系统中进行的更改，越来越多的典型错误开始出现，这些错误很难跟踪：


  1. 绑定项直接在模板外部触发主机（某些主机保持不受监视）。
  2. 触发器的值不正确（某种程度上同意3 GB的可用空间，但是有一个错字，我们得到了34 GB的永不工作的触发器）。
  3. 未能遵循名称约定 -我们将获得脚本失败的触发器（虽然这意味着更新交付系统不起作用）或Gitlab模板模板（监视哪个服务器或代理？）的名称令人费解。
  4. 暂时禁用触发器以进行测试。 结果，我们错过了有关基础架构的警告并站了起来。

在程序员的世界中，所有这些问题都非常简单地解决了：linter，codereview。 那么，为什么不采用这些最佳实践进行Zabbix配置审查呢？ 收下



我们之前已经写过代码审查的优缺点和示例： 在开发过程 中实现代码检查，实现代码检查的实际示例，代码 检查。 总结


为什么您可能需要查看Zabbix配置：


  • 检查主机和模板是否在命令中被命名为接受（ 名称约定 ）。
  • 培训新员工并验证他们是否按照讨论的那样完成了任务。
  • 在经验丰富的员工之间传递知识。
  • 通知触发器意外或暂时关闭。
  • 请注意item或trigger- last（0）而不是min（5m）中的错误值。

将您的问题添加到评论中，尝试一起解决如何通过审核解决问题。


像Zabbix一样具有变更跟踪


Zabbix有一个Audit子系统，在它的帮助下，我们了解了谁对配置进行了更改。 它的显着缺点是保存了大量事件，因为它保存了每个用户事件。


想象一下，对代码的任何更改都保留在git历史记录中，您尝试获取一个小时的变量名，尝试了40个选项，并且所有选项现在都已保存，每个更改都是一个单独的提交，然后将这些提交的历史记录提交给审阅，而无法比较开始和结束版本。 糟透了吧？


在Zabbix Audit中，这是正确的。 它可以用来跟踪更改，但是它不允许您快速查看系统的两种状态（在一周的开始和结束时）之间的差异（diff）。 此外，她的所有动作均按类型划分：添加，更改，删除必须在不同的窗口中查看。 您可以在Zabbix的“审核”选项卡上找到一个示例（或查看屏幕快照）。 很难理解什么是初始状态，什么是当前状态，一周中发生了什么变化。 当我们每周进行数十次更改时，情况就变得很复杂。



我希望有一种机制可以允许：


  1. 每周一次或在完成更改监视逻辑的任务后，对系统状态进行转换。
  2. 将当前配置块与先前的块（差异）进行比较。
  3. 自动检查名称约定。
  4. 检查任务的质量，提供建议，建议，讨论解决方案。
  5. 检查更改是否合法-所有更改均根据任务进行。
  6. 使用开发人员熟悉的工具-git，diff，mergerequest。
  7. 回滚到系统的某些状态，但不会丢失数据（因此，备份不适合）。
  8. 控制Zabbix实体-主机，模板，操作，宏，屏幕，地图。

现在，让我们谈谈我们如何实现该机制，以及该机制如何对您的Zabbix基础架构有用。


进行Zabbix配置审查


要存储Zabbix配置，我们使用以下格式：


  1. 原始XML-使用原始Zabbix导出导出 。 用于主机，模板，屏幕对象。 有以下功能：
    • XML难以阅读和查看更改；
    • 包含所有字段，包括空字段；
    • 包含字段日期 -导出日期，我们将其删除。
  2. 原始JSON - Zabbix的某些类型的对象不知道如何导出 （动作，媒体类型），但是它们很重要，我想查看更改，因此我们从ZabbixAPI提取原始数据并将其保存在JSON中。
  3. 可读的YAML-我们处理导出的XML和原始JSON，并将其保存在易于人读，方便的原始YAML中。 有了它，您就可以轻松处理大量的变化。 在此处添加小处理：
    • 删除没有值的字段是有争议的，因此我们可以跳过一个空白字段，尽管应该填充它，例如，在触发器处带有问题描述的字段（trigger.description）。 经过讨论，决定最好删除空字段，因为它们太多了。 如果愿意，可以在某些空白字段上设置例外，而不删除它们。
    • 我们删除日期-它们每次更改，并且合并请求显示为每个主机的更改。
    • 您可以选择添加其他操作来填充信息-例如，在实际操作中写入用户ID而不是用户。

我们区分了三个git存储库（我们使用gitlab进行存储，但是任何VCS都可以做到）：


  1. zabbix-review- export-这将存储gitlab-ci作业的导出代码（Python脚本）和参数。
  2. zabbix-xml-我们将XML + JSON存储在一个分支中。 审查此业务既困难又耗时。 用于在特定时间内恢复Zabbix配置状态。
  3. zabbix-yaml是我们的主要存储库，在这里我们提出合并请求，查看更改，讨论所做出的决定，如果没有评论，请在master中合并。

在这些存储库中，我们保存配置数据，规则如下：



现在我们可以清楚地看到对象的类型发生了变化，并且很清楚哪个对象发生了变化。 在以下示例中， 配置文件模板已更改。 Scmdev。 FlusContinuousTest 。



在示例中显示


要查看更改，我们在gitlab中使用merge-request机制。


更改了配置文件模板。 DevOps。 测试 -更改了触发器表达式。 模板，与在templates文件夹中一样：


在触发器和优先级中更改了表达式：


链接到另一个模板：


更改了操作-默认情况下，在文本末尾添加了新行：


合并请求中的讨论示例（就像程序员一样！）-可以看出它们将标准模板直接连接到主机，但是值得强调一下将来的单独作用。 旧评论的屏幕截图，然后仍然使用配置的XML表示。


总的来说，一切都很简单：


  1. 添加了新的主机或其他对象-创建了一个新文件。
  2. 更改了主机或其他对象-看起来比较。
  3. 已删除-文件已删除。

假设您完成了一项任务，想让一位同事看看您是否忘记了什么。 我们要求进行审查：为此，在zabbix- review-export存储库中，以手动启动方式运行gitlab-ci作业。


我们向查看，讨论和更正代码监视基础结构的同事分配合并请求。


每周一次，将启动一个新审阅以跟踪较小的更改，为此，根据计划（ Schedule ），将配置导出并保存到git存储库（带有新的提交），然后监视大师审阅更改。


你轻轻地传播，但你必须尝试


现在，我们将告诉您如何配置该系统以进行Zabbix配置审核（ 我们喜欢开源，并尝试与社区分享我们的最佳实践）。


有两种可能的用途：


  1. 只需手动运行导出脚本，然后查看更改，使git add * && git commit && git push 。 此选项适用于罕见的更改或仅在使用监视系统时使用。
  2. 使用gitlab-ci实现自动化-然后，您只需要单击开始按钮（请参见上面的屏幕截图）。 选项更适合大型 懒惰的 团队或经常更换。

仓库https://gitlab.com/devopshq/zabbix-review-export中描述了这两个选项，您需要的所有内容都存储在其中-脚本，gitlab-ci和README.md设置以及如何放入基础结构中。


首先，尝试第一个选项（或者如果您没有gitlab-ci基础结构）：使用手动模式-运行zabbix-export.py脚本导出（备份）配置，在您的工作计算机上执行git add * && git commit && git push 。 累了时，转到第二个选项-自动化自动化！


问题和可能的改进


现在，更改已取消个性化设置，要找出更改者，您需要使用审计系统，这会造成痛苦。 但是，并非所有事情都如此可怕，而且很少需要审核，通常在团队聊天中显示一条消息即可找到合适的员工。


另一个问题：当主机或项目在主机中更改时，它不包含在XML中。 也就是说，我们可以关闭特定主机上的所有触发器，或将其优先级更改为较低的触发器-没有人会知道并更正我们！ 我们正在等待对此的修复程序， 网址为https://support.zabbix.com/browse/ZBX-15175


直到他们提出了一种自动恢复的机制。 假设模板或主机发生了重大更改，我们知道更改是不正确的，因此您需要按原样返回所有内容。 现在，我们正在寻找对应主机的必要XML，将其手动导入到UI中，但是我们只想单击按钮“将TemplateName模板回退到commit-hash提交状态”。


您可以实现双向同步-在对Yabb进行更改时对Zabbix配置进行更改时，则不必转到Zabbix系统Web界面。 在github上，我们遇到了一个类似的项目，但是它以某种方式很快消失了，社区没有接受这个想法。 显然，要在YAML中实施您可以在网络界面中用鼠标单击的内容并不容易。 因此，我们决定进行单向交互。


理想的选择是在Zabbix中嵌入此系统，以将配置保存为代码，即使只是XML格式。 如何在TeamCity CI服务器中完成此操作：通过UI配置的配置代表更改配置的用户进行提交。 事实证明，这是一种非常方便的查看更改的工具，还消除了取消个性化更改的问题。


试一下


开始导出您的Zabbix配置，提交到存储库（足够本地），等待一周，然后再次运行。 现在，更改由您控制！ https://gitlab.com/devopshq/zabbix-review-export


谁会对Zabbix框中的此功能感兴趣-请投票给问题https://support.zabbix.com/browse/ZBXNEXT-4862


全部100％正常运行时间！

Source: https://habr.com/ru/post/zh-CN433126/

More articles:


All Articles