详解ZabbixBSM是啥？业务服务监控达到全新高度

感谢本文译者赵广生 ! 欢迎更多资深用户，结合自己使用经验翻译原厂博文！

本文是关于高级业务服务和 SLA 监控以及相关用例的文章。你们中的一些人可能已经熟悉业务服务及其背后的核心思想。在绝大多数组织中，我们都有提供给客户或/和供内部使用的服务。这些服务的可用性通常基于硬件、软件或人员的存在和可用性。

但无论我们的监控配置得多么好，有时我们都会错过每个特定设备如何影响我们的业务，而这正是业务服务监控可以帮助我们的地方。

借助业务服务监控，可以根据基础架构每个部分的状态查看您的业务到底发生了什么。这让我们、管理员和服务所有者能够理解当硬件损坏或设备无法访问时的真正含义。通过业务服务监控，我们可以了解究竟是什么影响了我们的业务以及情况有多严重，包括计算 SLA（服务水平协议）并根据定义的 SLO（服务水平目标）对其进行评估。

因此，让我们查看一些示例，了解现实生活中的业务服务可能是什么样子。

在此示例中，我们有一个基于支持服务的服务树。它有电话，电话插入 PBX，而 PBX 插入交换机。这只是一个例子，在现实中，我们可以有一个更复杂的基础设施，包括容器、CRM 服务等。我们当然会监控所有这些，但如果我们也对业务角度感兴趣怎么办？

要查看业务透视图，我们需要转到主菜单中的新服务部分，我们可以在其中创建和查看服务树本身。此外，在同一部分中，我们可以配置操作，这使我们能够在其中一项服务发生问题时做出反应。我们还可以指定我们努力实现的 SLO，并查看有关当前情况的 SLA 报告。

服务视图还可以让我们查看是否存在影响我们服务的问题并跟踪其根本原因。

定义哪个服务受到哪个问题的影响是通过使用问题标签来完成的，问题标签本质上将它们链接在一起。服务也可以有自己的标签，我们用它来对服务进行分组并了解一项服务与另一项服务的关系。我们还可以使用服务标签来构建 SLA 报告或在服务受到问题影响时执行操作。权限也基于服务标签，允许为不同的用户创建不同的视图。

但这些只是基础知识——更有趣的是实际用例。让我们看看 Zabbix 用户如何根据真实的业务示例实际使用业务服务监控来发挥自己的优势。

真实的业务服务用例可能是有用的示例，可以帮助您设计自己的 Zabbix 业务服务树。也许您已经拥有自己的类似业务，并且您需要一切都可以“点击”的起点——该起点可以是现实生活中的例子。

第一个例子看起来有点复杂，但实际上非常简单。这里我们可以看到一个真实的金融机构业务服务树。你可以看到他们有很多不同的互连服务。首先查看服务树原始模式可能有点混乱，但在 Zabbix 中它非常简单。

内部服务连接到电子邮件，电子邮件同时与客户服务相关，因为我们确实需要与客户沟通，而不仅仅是内部！此外，我们还必须定义代表支持我们电子邮件服务的底层系统和应用程序的服务。使用 Zabbix 服务很容易做到这一点。

现在想象一下，如果您根本没有服务功能，当您只有多个设备的问题列表时，您能多快检查电子邮件服务的状态？如何查看全年的服务统计数据？这是服务所有者和管理员在此用例中遇到的问题，他们通过定义 Zabbix 业务服务树解决了这个问题。

我们首先定义根业务服务——金融机构。它与 15 项主要服务相关联。这 15 项服务分为内部服务和外部服务。较低级别的服务还包含主要服务所基于的子服务。即，我们有一个基于特定 VM 可用性的会计服务，会计软件驻留在其中。

服务分为特定类别，因此服务所有者可以更轻松地了解情况，而无需花费大量时间来弄清楚哪个问题导致了哪种情况。只需单击一下，服务所有者就可以立即看到每个服务基于哪些组件或子服务以及实际的服务 SLA。这还有利于显示根本原因问题，并能够快速识别哪些子服务导致特定业务服务出现问题。

不要忘记，业务服务树可以是多级的——子服务可以有自己的子服务，服务也可以相互连接。例如——在父子服务关系截图中，我们可以看到我们有一个会计服务。会计使用Microsoft服务。Microsoft服务也在内部使用。那么当Microsoft服务停止工作时会发生什么？我们将知道会计将受到影响，内部服务将受到影响，我们将看到确切的事件链——组织中到底出了什么问题以及如何出错，以及哪些组件需要修复。

服务会对您的业务产生不同的影响。有些服务比其他服务更重要。附加规则使 Zabbix 能够考虑潜在的服务影响。前两个附加规则分析受影响的子服务的百分比，并相应地设置服务问题的严重性。

但如果这两个最关键的服务受到影响，那将立即成为一场灾难。例如网上银行——你可以想象现在任何一家银行都有网上银行服务，如果它出现故障——所有的客户都会受到影响；它甚至可以登上新闻，而不仅仅是监控。因此，他们当然想立即了解那种灾难，而使用 Zabbix 服务——他们会的。通过定义额外的规则和服务权重，您可以先发制人地对问题做出反应并在问题导致最终用户停机之前解决问题。

在Zabbix中，我们可以选择计算SLA的时间段——每天、每周、每月、每年，或者这些的混合选择。根据我们的选择，我们可以看到服务的实时报告，例如，到年底或一天，了解最需要关注的内容并审查服务绩效。或者举一个更接近现实的例子——通过会计报告找出许可证是否及时更新，以便会计使用的软件始终可用。我们还可以构建一个包含报告的仪表板，显示服务的当前摘要是什么，以便他们可以计划、购买新软件、购买新许可证和获得新硬件，并始终领先于可能发生的任何事情。

用户角色中的服务权限可用于创建不同的服务视图。这可用于隐藏敏感的服务信息或仅以所需的详细程度显示服务。例如，可以为内部支持用户提供更详细的视图，因为他们需要尽可能多的信息来解决任何与服务相关的问题。可以为会计和管理团队提供单独的视图，仅显示相关数据以确保快速可靠的决策过程。

如果我们想让会计和管理团队的工作变得更加简单怎么办？我们可以使用操作和计划报告功能将所需信息传递到用户邮箱，而无需他们定期登录 Zabbix。

另一个例子是 MSP（托管服务提供商）服务树。这个用例经常遇到，即使在原始模式视图中，树也总是很容易阅读，如下所示：

我们以托管公司为例。该公司为其用户提供一组特定的服务。还有一些内部服务也可以被客户使用——例如，Zabbix 本身。

Zabbix 可以成为 MSP 场景中的一个很好的工具，因为它可以直接为客户提供对 Zabbix 的访问权限，并使用与特定用户相关的最新统计信息构建仪表板视图。在这个例子中，我们可以看到托管的主要服务，划分给客户，其中每个客户都是该树的一个分支，使用公司提供的托管服务。我们还看到监控本身就是一项服务，因为在这种情况下，客户还可以利用 Zabbix 获取有关他们使用的服务及其当前状态的详细信息。查看他们使用的服务器的当前 SLA 级别，是否符合预期。

当然，MSP 保留了客户的完整视图，所有客户都同等重要，都应该得到适当的服务质量，因此当然每个客户都会被分配到相同的权重。一旦任何客户出现问题，相关服务将在服务树上标记为高级别严重性。这样，MSP 将立即看到受影响的客户，从而可以尽快为他们提供帮助。

如果你有一个更大的环境——也许你有数百个客户，你可能会选择不在你的配置中定义服务权重，因为服务的数量变化非常快。那么我们如何应对全球性问题呢？我们可以使用百分比规则，而不是仅对静态重量数字做出反应。通过这种方式，我们可以检查问题是与单个客户有关，还是全球性的，现在每个人都受到影响。

服务中的根本原因视图将使您能够立即开始修复所有问题。同时，可以使用服务动作和条件单独通知每个客户。如果我们正确命名或标记了服务，这应该很容易做到。

不要忘记定义权限，这样任何客户，就像这里的 Mooyani，都可以在登录后立即访问他们的服务，确保信息不仅保持私密性，而且与当前用户相关。

客户的所有信息都可以放在他们的个人仪表板上，他们可以在需要时随时查看所有详细信息。监控通过其 VM 的流量、资源使用情况、应用程序状态和任何其他受监控的实体。不要忘记服务 SLA 报告也可以放在 Zabbix 仪表板上。通过这种方式，您的客户可以看到 MSP 符合协议中定义的条款，并且一切都按预期执行。

总而言之——从任何角度监控您的基础设施都很棒，包括业务监控。将此视图作为 MSP 提供给您的客户始终是一个好主意，这样他们就可以看到我们满足了我们为自己定义的标准以及对用户的课程承诺。

扫一扫｜加入技术交流群

微信号｜17502189550

备注“使用Zabbix年限+企业+姓名”

5000+用户已加入！