Kubernetes 注释驱动的 OpenTelemetry Collector 发现

在容器和 Kubernetes 的世界里，可观察性至关重要。用户需要随时了解其工作负载的状态。换句话说，他们需要对移动对象进行可观察性。

这就是 OpenTelemetry Collector 及其 receiver creator 组件发挥作用的地方。用户可以采用自助服务方法设置相当复杂的监控方案，遵循集群级别的最小权限原则。

自助服务方法很棒，但它实际上能有多自助？在这篇博文中，我们将探讨 Collector 中一项新添加的功能，该功能使动态工作负载发现更加容易，为管理员和用户提供了无缝的体验。

容器和 Pod 的自动发现

运行在容器和 Pod 上的应用程序对监控系统来说变成了移动的目标。通过自动发现，像 Collector 这样的监控代理可以跟踪容器和 Pod 级别的更改，并动态调整监控配置。

今天，Collector — 特别是 receiver creator — 可以提供这样的体验。通过使用 receiver creator，可观察性用户可以定义依赖于环境条件的配置“模板”。例如，作为一名可观察性工程师，您可以配置 Collector，在 NGINX Pod 部署在集群上时启用 NGINX receiver。以下配置可以实现此目的

receivers:
  receiver_creator:
    watch_observers: [k8s_observer]
    receivers:
      nginx:
        rule: type == "port" && port == 80 && pod.name matches "(?i)nginx"
        config:
          endpoint: 'http://`endpoint`/nginx_status'
          collection_interval: '15s'

之前的配置在通过 Kubernetes API 发现一个暴露端口 80（NGINX 的已知端口）且其名称与 nginx 关键字匹配的 Pod 时启用。

这很棒，作为一名管理可观察性解决方案的 SRE 或平台工程师，您可以依赖此来满足用户对监控 NGINX 工作负载的需求。但是，如果另一个团队想要监控不同类型的工作负载，例如 Apache 服务器，会发生什么？他们需要通知您的团队，您需要使用新的条件配置块更新配置，经过 Pull Request 和审查流程，然后进行部署。此部署将需要 Collector 实例重新启动才能使新配置生效。虽然此过程对某些团队来说可能不是什么大问题，但确实有改进的空间。

那么，如果作为 Collector 用户，您只需启用自动发现，然后让您的集群用户通过正确注解他们的 Pod 来告诉 Collector 如何监控他们工作负载，会怎么样？这听起来很棒，而且实际上并不是什么新鲜事。OpenTelemetry 已经通过 Kubernetes operator 支持自动插装，允许用户仅通过注解他们的 Pod 来自动插装他们的应用程序。此外，这是可观察性行业中其他监控代理已支持的功能，用户对其也很熟悉。

所有这些动力促使 OpenTelemetry 社区 (GitHub issue) 为 Collector 创建了一个类似的功能。我们很高兴地宣布，Collector (GitHub issue) 现在支持基于 Kubernetes 注解的自动发现！

一个解决方案

该解决方案建立在 Kubernetes observer 和 receiver creator 提供的现有功能之上。

K8s observer 会将 Kubernetes 集群中出现的对象通知 receiver creator，并提供有关它们的全部信息。除了 K8s 对象元数据之外，observer 还提供有关 Collector 可以连接到的已发现端点的信息。这意味着每个发现的端点都可以由特定的 scraping receiver 用于获取指标数据。

每个 scraping receiver 都有一个默认配置，只有一个必需字段：endpoint。鉴于端点信息由 Kubernetes observer 提供，用户需要显式提供的唯一信息是应该使用哪个 receiver/scraper 来从发现的端点抓取数据。该信息可以在 Collector 上配置，但如前所述，这很不方便。一个更方便的位置来定义哪个 receiver 可以用于从特定 Pod 抓取遥测数据是 Pod 本身。Pod 的注解是放置此类细节的自然位置。鉴于 receiver creator 可以访问注解，它可以实例化具有 receiver 默认配置和发现的端点的正确 receiver。

以下注解指示 receiver creator，此特定 Pod 运行 NGINX，并且 NGINX receiver 可用于从中抓取指标

io.opentelemetry.discovery.metrics/scraper: nginx

除此之外，还需要使用以下注解显式启用 Pod 上的发现

io.opentelemetry.discovery.metrics/enabled: 'true'

在某些情况下，默认 receiver 的配置不适用于连接到特定 Pod。在这种情况下，可以在另一个注解中定义自定义配置

io.opentelemetry.discovery.metrics/config: |
  endpoint: "http://`endpoint`/nginx_status"
  collection_interval: '20s'
  initial_delay: '20s'
  read_buffer_size: '10'

需要注意的是，注解中定义的配置不能将 receiver creator 指向另一个 Pod。Collector 将拒绝此类配置。

除了指标抓取之外，基于注解的发现还支持使用 filelog receiver 收集日志。可以使用以下注解在特定 Pod 上启用日志收集

io.opentelemetry.discovery.logs/enabled: 'true'

与指标类似，可以选择以下形式提供可选配置

io.opentelemetry.discovery.logs/config: |
  max_log_size: "2MiB"
  operators:
  - type: container
    id: container-parser
  - type: regex_parser
    regex: '^(?P<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) (?P<sev>[A-Z]*) (?P<msg>.*)$'

如果需要更改 filelog receiver 操作符的集合，则必须重新定义完整的列表，包括默认的容器解析器，因为当列表配置字段合并到默认配置结构时，它们将被完全替换。

必须在 receiver creator 中通过添加以下配置字段来显式启用发现功能

receivers:
  receiver_creator:
    watch_observers: [k8s_observer]
    discovery:
      enabled: true

试试吧

如果您是 Kubernetes 上的 OpenTelemetry Collector 用户，并且觉得这项新功能很有趣，请参阅 Receiver Creator configuration 部分以了解更多信息。

试试吧，并通过 CNCF Slack 工作区的 #otel-collector 频道告诉我们您的想法。

• ←上一篇
• 下一篇→