通过Telegraf Operator扩展Kubernetes监控

作者：Wojciech Kocjan / 用例，产品，开发者
2021年12月3日

导航到

本文最初发表在The New Stack。

监控是云计算的一个关键方面。在任何时候，您都需要知道什么在运行，什么没有运行，并且能够对给定环境中发生的变化做出反应。有效的监控始于收集整个生态系统中的性能数据并在有用的方式下展示它们的能力。因此，在生态系统中管理监控数据越容易，那些监控解决方案就越有效，该生态系统就越高效。

Kubernetes是云计算的得力助手，它提供的自动化是一个游戏规则的改变者。然而，不受控制的自动化可能会引发问题，因此有必要监控那些自动化过程。Kubernetes环境中的一个流行监控解决方案是Prometheus。

然而，并非所有应用程序都仅运行在Kubernetes上。如果您想使用Prometheus从多个环境（包括自定义应用程序服务器、遗留系统和技术）中收集指标数据，您将不得不编写大量自定义代码才能访问和消费这些指标。

Enter Telegraf Operator，一个与环境无关的Prometheus替代品。

什么是Telegraf Operator？

首先，我们应该区分Telegraf和Telegraf Operator。

Telegraf 是一款开源服务器代理，旨在从堆栈、传感器和系统中收集指标。

另一方面，Telegraf Operator是一个应用程序，用于在Kubernetes集群中创建和管理单个Telegraf实例。本质上，它充当管理Kubernetes集群中部署的各个Telegraf实例的控制平面。Telegraf Operator是一个独立的应用程序，它独立于Telegraf部署。

Telegraf Operator注意事项

在基本层面，Telegraf Operator从您的Kubernetes集群中具有公开端点的应用程序中抓取指标。

部署监控代理有两种主要机制，即DaemonSet和sidecar。具体要监控的内容不同，您应选择的机制也不同。在使用InfluxDB的情况下，我们建议

  • 使用DaemonSet来监控节点、Pod和容器指标。
  • 对暴露大量指标的微服务使用sidecar监控。

在DaemonSet场景中，Telegraf在每个节点上运行并收集节点的基础设施指标。

相比之下，在sidecar部署中，Telegraf的容器实例与应用容器共享Pod，并从该应用程序的公开端点抓取数据。

sidecar部署

但是，sidecar Telegraf容器从何而来？这正是Telegraf Operator发挥作用的地方。

Telegraf Operator在Pod级别工作，因此您可以使用它与Kubernetes环境中创建Pod对象的任何内容一起使用。当某个东西——一个部署、有状态集、DaemonSet、作业或定时作业——发送创建新Pod的请求时，Telegraf Operator会拦截该请求，利用Kubernetes中的mutating webhooks功能，并有机会对其进行更改。

Telegraf Operator读取请求中的Pod注解，如果注解指示添加Telegraf sidecar，则Telegraf Operator会将该实例添加为Pod中的额外容器。换句话说，Telegraf Operator查看新Pod的容器列表，如果注解指示，则添加另一个容器到列表中。

一旦Telegraf sidecar容器就位，它就可以开始抓取数据并将指标推送到数据库，如InfluxDB。

使用sidecar部署进行Kubernetes监控具有几个优点。sidecar监控代理允许您定义自定义指标和特定应用程序的监控，而不会影响其他工作负载共享的整体监控框架。这种方法使端点暴露可管理。随着应用程序暴露的端点越来越多，sidecar方法通过只抓取Pod中应用程序的数据来促进更好的可伸缩性。

Telegraf Operator适合您吗？

这个问题的答案实际上取决于您的生态系统和您要监控的内容。有许多不同的选项和可能性。我们在这里概述了一些。

替换Prometheus

Telegraf可以充当Prometheus服务器，因此您可以使用Telegraf Operator收集任何您想要使用Prometheus收集的指标。因此，可以简单地用Telegraf Operator替换Prometheus。在这种情况下，您会用Telegraf sidecar容器替换Prometheus导出器，向Pod规范添加Telegraf Operator期望的注解，并将数据存储从Prometheus服务器切换到InfluxDB。

然而，如果您认为完全移除Prometheus监控的想法太过破坏性，那么有许多方法可以使用Telegraf和Telegraf Operator来增强或补充您当前的Prometheus监控，包括旧的和自定义应用程序指标。

替换部分Prometheus

如果您想要对各种指标有更大的灵活性和可访问性，一个选项是将您的Prometheus服务器配置为直接写入Telegraf。您可以通过Prometheus Remote Write Telegraf插件来做到这一点。您可以配置插件将收集的指标发送到任何您想要的数据库，例如InfluxDB。这种设置允许您将Prometheus服务器上的指标直接发送到InfluxDB，或者根据您的配置，您甚至可以将指标发送到多个位置。如果您想进行双重写入或为您的指标数据创建备份系统场景，这将非常有用。

Telegraf也可以作为Prometheus服务器使用，因此另一个选项是用Telegraf替换您的Prometheus服务器。您可以保留您的Prometheus导出器，因为Telegraf能够摄取这些数据。一旦Telegraf收集了这些数据，您就可以将其发送到任何您想要的地方，这提供了同样的灵活性。

并行运行Telegraf和Prometheus

另一种选择是并行运行Prometheus和Telegraf。这两个应用程序以相同的方式工作，抓取Prometheus导出器呈现的数据。您可以配置这两个服务抓取数据，并在必要时对数据进行并行比较。

在这个设置中，您还可以使用Telegraf实例将数据写入Kubernetes环境之外的某个地方，并使用Prometheus服务器来满足您在Kubernetes环境中的任何需求。

大规模数据收集

除了这些边车用例之外，您还可以使用Telegraf Operator同时运行DaemonSet监控，这样您可以获取实际pods和节点的指标。这样做可以将整个生态系统的指标数据保存在一个地方，为您的生态系统提供集中式监控。

如果Kubernetes只是您的系统运行的环境之一，Telegraf Operator可能更合适。如上所述，如果您正在使用Kubernetes并且想从非Kubernetes环境中收集指标，事情会更复杂。您将必须为希望收集指标的所有类型的技术编写自定义导出器，然后将其配置为Prometheus服务器可以抓取这些指标。

相比之下，Telegraf有数百个可用的插件，可以收集不仅来自Kubernetes，还来自外部环境的指标。

在Kubernetes中安装Telegraf Operator

telegraf-operator在集群中启动一个属于其自己的命名空间的pod。安装telegraf-operator非常简单，您可以通过以下命令使用kubectl完成安装

kubectl apply -f telegraf-operator.yml

(您可以在部署目录中找到yml文件的示例。）

您还可以使用其他工具，例如Helm或Jsonnet来安装telegraf-operator。

helm upgrade --install my-release influxdata/telegraf-operator

安装后，Telegraf Operator 会监视部署了特定一组pod 注解的 pod，如上所述。使用 Telegraf Operator 的优势在于，您只需在创建 pod 注解时定义 Telegraf 的输入插件配置。然后，Telegraf Operator 会为整个集群设置配置，因此您的用户在部署应用程序时无需担心配置指标目标。

开始抓取指标

安装 Telegraf Operator 后，您只需为应用程序容器的 pod 标记注解，即可开始抓取您的应用程序或指标端点。

以下是一个包含 Telegraf 配置数据的 DaemonSet 部署 YAML 文件示例

apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: my-application
 namespace: default
spec:
 selector:
   matchLabels:
     app: my-application
 template:
   metadata:
     labels:
       app: my-application
     annotations:
       telegraf.influxdata.com/class: app
       telegraf.influxdata.com/port: "8080"
       telegraf.influxdata.com/path: /v1/metrics
       telegraf.influxdata.com/interval: 5s
       telegraf.influxdata.com/scheme: http
       telegraf.influxdata.com/internal: "true"
   spec:
     containers:
     - name: my-application
       image: my-application:latest

以下是包含 Telegraf 配置数据的 Redis 状态集部署 YAML 文件示例

apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: redis
 namespace: test
spec:
 selector:
   matchLabels:
     app: redis
 serviceName: redis
 template:
   metadata:
     labels:
       app: redis
     annotations:
       telegraf.influxdata.com/inputs: |+
         [[inputs.redis]]
           servers = ["tcp://127.0.0.1:6379"]
       telegraf.influxdata.com/class: app
   spec:
     containers:
     - name: redis
       image: redis:alpine

配置 Telegraf Operator

如上所述，telegraf-operator 读取 pod 注解以确定是否注入 Telegraf 侧车以及应用什么配置。

使用 telegraf.influxdata.com/inputs 注解传递 telegraf 配置语句。您可以通过这种方式传递 200 多个 Telegraf 插件中的任何配置。对于基于 Prometheus 的指标，除了任何其他注解，如 telegraf.influxdata.com/path 或 telegraf.influxdata.com/interval 之外，还需添加 telegraf.influxdata.com/port，然后 telegraf-operator 会生成 inputs.prometheus 的部分配置。

telegraf.influxdata.com/class 注解指定 pod 的监控类别。Kubernetes 机密定义了类别，由 telegraf-operator 读取，并随后与 Telegraf 的最终配置结合。

类别通常指定数据应发送到的输出位置，例如

apiVersion: v1
kind: Secret
... 
spec:
  stringData:
    app: |+
      [[outputs.influxdb]]
        urls = ["http://influxdb.influxdb:8086"]
      [[outputs.file]]
        files = ["stdout"]
      [global_tags]
        hostname = "$HOSTNAME"
        nodename = "$NODENAME"
        type = "app"

Pod 级注解文档描述了所有支持的注解。全局配置 - 类别文档定义了类别。

截至版本 1.3.0，telegraf-operator 支持热重载配置。这也需要 Telegraf 版本 1.19。有了这些新功能，更改全局配置将触发所有 Telegraf 侧车的配置由 telegraf 进程更新和重新加载，无需手动重新启动任何 pod。更多详细信息请参阅热重载文档。

为 Telegraf Operator 贡献

在 InfluxData，我们热爱开源，如果您有兴趣为 Telegraf Operator 插件做出贡献，我们非常乐意听到您的声音。您可以通过 Slack 联系我们，或查看我们的GitHub 仓库以获取更多信息。