为什么你需要集中式监控方法

作者：Jason Myers / 用例
2023年2月6日

本文最初发表于 The New Stack，并经许可在此转载。

通过在整个组织中监控数据的标准模型，不同的团队可以使用通用基础设施并从中提取最大价值。

监控（有时也称为可观测性）涉及随时间推移从源收集和分析数据，以跟踪其健康状况和/或性能。由于变化随时间发生，几乎所有监控数据都是时间序列数据，这意味着它具有时间戳。因此，当任何人谈论监控数据时，他们默认谈论的是时间序列数据。

在一个组织内，通常会发现多个团队，每个团队都有自己的监控解决方案。例如，有些团队可能将监控数据存储在关系数据库中，而另一些团队则使用更适合此类时间序列数据的工具——时间序列数据库。即使在同一组织内，某些团队使用比其他团队更有效的工具这一事实也说明了组织孤岛的问题。

这些通常反映了组织结构以及组织内部如何进行投资审批。然而，这种既定的做事方式会因采购和部署成本而产生冗余开销，并且在处理数据本身时可能会产生低效率。

每个使用监控数据的团队或角色对其都有不同的要求，这使得数据本身成为一种资产。但是，利益相关者需要分析数据才能从中获得价值。从重用和重新利用数据（如制造工厂的原材料）中获得的额外见解，用于其他用途会产生更多价值。如果一个团队将数据存储在专有解决方案中，他们将限制组织中所有其他团队的能力。

为了充分利用收集的数据，同时及时满足所有监控数据用户的需求，工程团队正在采用集中式监控方法，即“指标即服务”模型。

指标即服务 (MaaS) 是一种组织数据管理方法，公司将监控数据存储在中央位置，以便不同的利益相关者可以轻松访问它。通过在整个组织中提供监控数据的标准模型，不同的团队可以使用通用基础设施并从中提取收集数据的最大价值。这种方法避免了孤岛和供应商锁定，提供了更好的投资回报率 (ROI)，并使人们能够腾出手来从事更高价值的任务。

监控数据利益相关者

为了构建 MaaS 解决方案，重要的是要了解利益相关者是谁以及他们如何使用监控数据。我们可以识别至少三个通常使用此类数据的关键群体。

IT 运维

这些用户关心生产环境的稳定性、可用性和可靠性。因此，对于他们来说，至关重要的是要了解资源消耗情况，监控系统健康状况和状态，并使用诊断数据进行快速恢复。监控数据来自各种来源，以确保底层计算和网络基础设施功能正常，并能响应在其上运行的应用程序的需求。

IT 运维监控的主要关注点包括但不限于资源状态和以下状态：

• 物理设备、操作系统和虚拟机
• 容器和容器化服务的编排
• 网络和网格服务

应用程序开发者

这组用户主要关注敏捷性和性能。为了深入了解这些领域，开发人员需要与系统间和系统内可观测性、跟踪和端到端体验相关的细粒度数据。

应用程序开发人员的关注点包括：

• 应用程序及其依赖项的性能如何
• 使新代码可用需要多长时间
• 他们能多快找到问题的根本原因并恢复功能状态

通过控制代码，开发人员可以轻松地公开应用程序自定义指标、推送事件、生成日志和跟踪延迟，以满足他们的观察需求。一旦公开，开发人员需要一种方法来摄取、可视化、分析和存储这些数据，这需要高性能的写入和读取。开发人员使用这些数据来构建有效的解决方案，并最大限度地降低变更失败率。

业务经理

这群人寻求发现影响利润和增长的趋势，并寻找提高效率和效力的机会。为了实现这一目标，业务经理和数据工程师依赖于监控交易、用户活动和业务成果的动态和成功率，并将其与其他业务维度相关联。

衡量成功与否取决于关键绩效指标 (KPI)，这些指标告知利益相关者事情的运作情况，甚至可以阐明如何取得更好的结果。生成输入以馈送 KPI 需要执行相关性、聚合、求和以及跨度量和多个数据源的操作的高级分析。跨多种因素处理数据反映了影响业务指标的系统的复杂性，并呈现出更全面的图景。

总体目标是保持业务增长的积极趋势，并控制服务级别协议 (SLA) 和服务级别目标 (SLO)。

构建指标即服务产品

虽然这些角色中的每一个角色对监控数据都有不同的要求，但我们可以看到他们的综合需求如何涵盖从支持应用程序的基础设施到实际应用程序的功能，再到这些应用程序的最终用户结果的整个范围。一切都是相关的，因此可以合理地认为，每个组的监控数据都会对其他组产生影响。

这种相互关联性正是 MaaS 解决方案有意义的原因。该模型的吸引力之一在于，它将与监控相关的成本转化为对信息的投资，公司可以从中获利。

这代表着从旧的、针对孤立的、沉没成本的监控解决方案的窄焦点预算审批模式向前迈进了一大步。由于指标即服务模型涉及所有这些不同的群体，为了充分发挥其潜力，它无法通过点解决方案有效地实施。它需要专门构建的时间序列平台的可扩展性、性能和功能。

任何指标即服务解决方案都始于数据收集。它应该能够从任何来源收集数据，并支持推送和拉取方法。像 Telegraf 这样的开源数据收集代理有数百个插件，因此它可以处理几乎任何数据源。

Telegraf 是一个轻量级工具，因此它可以运行在传统基础设施上，也可以运行在边缘设备或容器和虚拟机中。这种灵活性使其非常适合监控利益相关者的不同需求。

收集的数据需要去某个地方，而存储这些数据的最佳工具是时间序列数据库。像 InfluxDB 这样的专用时间序列数据库提供了多种部署选项，包括自管理和完全托管的云。它与 Telegraf 无缝集成，以创建高效、持久且可靠的数据管道。

同样重要的是，InfluxDB 可以使用 Telegraf 将数据输出到各种目标源，并且它还公开 HTTP 端点，以便广泛的用户可以访问数据库中存储的数据。

使用这两个工具，每个组都可以设置自己的 Telegraf 实例来收集他们需要的数据，并将数据发送到 InfluxDB 实例中的单独数据桶。这种方法允许每个组在 InfluxDB 平台内创建隔离的数据管道，但由于他们将所有内容都存储在 InfluxDB 中，因此用户可以查询他们有权访问的任何数据桶中的数据。

从数据中创造价值

指标即服务模型带来的变化超越了数据集中化。它将监控数据从战术和情境决策过程转变为组织的战略规划层面。这种转变从根本上影响了管理者、提供商和消费者看待监控数据的方式，因为它引发了由以下因素主导的视角转变：

• 投资回报率 (ROI)：这是根据数据对业务绩效的影响来量化数据价值的能力。该领域的一个潜在结果是将 IT 转化为利润中心的机会。
• 问责制：增加了数据消耗的可见性，这与监控请求的 ROI 方法相一致。

利益相关者需要处理、分析和可视化他们的监控数据，以便更好地理解它并从中获得见解和价值。InfluxDB 提供了多种查询数据的方式，包括 SQL 和 Flux lang（InfluxDB 的原生脚本语言）。

InfluxDB 具有原生的仪表板和可视化工具，但用户也可以利用与 Grafana 等工具的第三方集成来创建可视化效果。该平台还提供 Restful API，使用户可以精细地控制他们的数据，并灵活地将平台的功能扩展到其他应用程序和系统中。

结论

当涉及到使用时间序列平台构建指标即服务解决方案时，这只是冰山一角。但作为一个广泛的框架，这种方法在各个垂直领域和用例中都是成立的。利用专门构建的时间序列平台来处理关键的时间序列数据，使所有利益相关者受益，因为它简化了从数据中创造价值的过程。

此外，像 InfluxDB 这样基于开源的平台提供了一种经济高效的方式来整合整个组织的监控解决方案。像 InfluxDB 这样的平台的灵活性还简化了数据集中化过程，鼓励跨职能协作和创新，并使数据访问民主化，以便关键利益相关者拥有他们做出决策以使其组织受益所需的信息。