OpenTelemetry 用于监控 VNF 和 CNF

OpenTelemetry 是最流行的可观察性框架之一，涵盖了全面的用例，不仅适用于 VNF/CNF，还适用于基础设施特性。

https://blueprints.launchpad.net/tacker/+spec/otel-monitoring

问题描述

在 tacker 方面，之前有一些使用 OpenStack 服务进行监控的实现，例如使用 mistral 工作流服务 [1] 或 ceilometer 告警服务 [2]，旨在实现可扩展的 VNF 组件，在 Yoga 中引入了用于自动修复的 prometheus 监控 [6]。这些包含在所谓的旧版 tacker 中的监控插件已被最新版本弃用，因为这些旧实现未得到维护，并且在基于 ETSI-NFV 的 tacker 中将不再支持。

引入 prometheus 的主要目的是支持 ETSI-NFV SOL 003 规范中定义的故障管理接口，该接口使 tacker 能够监控 VNFs 是否处于良好状态，并在发生故障时采取行动，换句话说，用于自动修复。在 Zed 和下一个版本中，该功能已进一步改进，以支持使用外部监控工具进行自动缩放的性能管理接口 [3] [4]。因此，可以说 tacker 现在与 ETSI-NFV SOL 规范中的 FM/PM 接口兼容。

然而，这些监控功能侧重于标准，并且对于考虑在大型云环境中发生的许多其他广泛案例，以及运营商感兴趣的案例，其用例仍然有限。对于此类系统，仅“监控”是不够的，而是需要“可观察性”来维护高度分布式和复杂的系统。

OpenTelemetry，也称为 OTel，是一种供应商中立的开源可观察性框架，用于工具化、生成、收集和导出遥测数据，例如追踪、指标和日志。作为行业标准，许多供应商、通过许多库、服务和应用程序集成，并被许多最终用户采用 [#otel-doc]。本提案旨在将 OpenTelemetry 引入以部署可观察性功能 [7]。

用例

在旧版 tacker 中，监控被实现为类似于引脚的保活机制。例如，之前的 mistral 工作流用于引脚注册的 VIM 或 VNF [5]。这是一个基于 mistral 的监控的简单用例。(1) Tacker 服务器上传一个监控工作流，例如针对 VNF 的 HTTP ping，通过中间消息队列传递给 conductor。(2) 然后执行监控，以及 (3) 删除工作流。即使对于这样一个简单的用例，这些旧功能也将在不久的将来被弃用。

../../../_images/mistral-plugin.svg

下一个用例是使用 prometheus 进行自动修复 [6]。如果从 prometheus 发现了一些表明不良情况的行为，tacker 将尝试删除故障节点，并使用 VnfFm 驱动程序和 Vnflcm 驱动程序创建一个新的节点以进行修复。可以通过 ETSI-NFV 合规 API 从客户端完全管理此监控。

../../../_images/prometheus-plugin.svg

在 FM 和 PM 的标准化方面，tacker 中的基于 Prometheus 的解决方案足以适应要求。尽管 tacker 应该照顾设计，以在 tacker 特定消息和数据格式下中介 Prometheus 和 VIM。这意味着如果我们将在不同的 VIM（例如 OpenStack 和 Kubernetes 之外）上拥有比当前基于 Prometheus 的解决方案更多的功能，我们将需要付出很多努力。这样的需求可能会出现于使用多云系统集成服务或类似用例的情况。它还需要提供针对此类复杂用例的可观察性功能。

提议的变更

本规范的目的是引入 OpenTelemetry 组件的驱动程序作为可观察性框架。它提供以下功能，使运营商能够获得细粒度的信息，这些信息不仅用于自动化资源管理，还用于分析非常复杂的故障案例。

  • 追踪：用于获取在向应用程序发出请求时发生情况的全局视图。

  • 指标：在运行时捕获的服务测量值，称为指标事件，它不仅包括测量值本身，还包括捕获时间和相关元数据。

  • 日志：带有元数据的带时间戳的文本记录，可以是结构化的（推荐）或非结构化的。

OpenTelemetry 的典型用例之一是分布式追踪。它记录了请求（由应用程序或最终用户发出）在多服务架构中传播时所采取的路径。许多可观察性后端将追踪可视化为瀑布图，如下所示

https://opentelemetry.io/img/waterfall-trace.svg

如图所示，OpenTelemetry 支持多种基础设施，例如 Kubernetes 或其他主要基础设施，以收集数据和共享客户端。

https://opentelemetry.io/img/otel-diagram.svg

Tacker 的 otel 驱动程序用于部署 OpenTelemetry 的组件并与之通信，以设置组件或收集数据。tacker 中的组件设计类似于 prometheus 插件和驱动程序，但略有不同。

在 Otel 的组件中，有两个关键角色，Collector 和 Exporter。

  • Collector 是一个供应商无关的代理，可以接收、处理和导出遥测数据。它支持以多种格式（例如，OTLP、Jaeger、Prometheus 以及许多商业/专有工具）接收遥测数据，并将其发送到一个或多个后端。它还支持在导出之前处理和过滤遥测数据。

  • Exporter 用于将数据导出到 OpenTelemetry Collector 或后端，例如 Jaeger、Zipkin、Prometheus 或供应商特定的后端。

对于 Exporter，它由 Tacker Conductor 中的 OtelDriver 控制，并用于将数据发送到 Otel Collector。Otel Collector 类似于 Exporters 的管理器，并聚合来自驱动程序的数据。聚合的数据被总结或处理，以成为更有用的可观察性数据。

../../../_images/tacker-otel-driver.svg

从 tacker 来看，它应该在任何目标节点上部署 Otel 的组件，在部署 VNF 的主机或虚拟机上。因此，tacker 的 otel 驱动程序应该这样做。与 prometheus 插件不同，OpenTelemetry 的所有数据和 API 都定义为 OpenTelemetry 规范 [8]。在 Caracal 中，Tacker 的插件遵循 OpenTelemetry 规范版本 1.27.0。

备选方案

无

数据模型影响

需要存储在 tacker DB 中的每个数据都会产生影响。

REST API 影响

在不添加额外的 API 的情况下，无法实现。

安全影响

遥测数据的使用必须仅限于运营商或维护人员。

通知影响

无

其他最终用户影响

无

性能影响

无

其他部署者影响

无

开发人员影响

无

升级影响

无

实现

负责人

主要负责人

工作项

  • 支持 devstack 脚本以安装 OpenTelemetry 组件。

  • 实现 Otel 插件。

  • 添加单元和功能测试。

  • 添加文档，用于设置和使用插件的指南。

依赖项

无

测试

添加单元测试和功能测试。测试场景将被固定。

文档影响

  • OpenTelemetry 工具的安装指南。

  • 示例用例指南。

参考资料

历史

无