在GCP上使用Collector Builder和示例配置

OpenTelemetry Collector 是一个用于处理和导出遥测数据的多功能工具。由于其模块化设计，它支持从许多不同的源接收输入，并将其路由到许多可观测性后端。这种设计基于独立的接收器（receivers）、处理器（processors）和导出器（exporters），使第三方可以开发新的后端支持。它还允许用户配置适合他们用例的遥测流水线。

collector-builder工具进一步提供了一种简单的方法，可以编译只包含特定摄入和导出组件的构建与GCP的Collector二进制文件。与默认捆绑很多组件的公开可用二进制版本不同，定制的Collectors可以缩减到只包含您真正关心的组件。这意味着编译的Collector可以比公开版本更小、更快、更安全。

Google Cloud最近推出了一个示例GitHub仓库，用于在GCP上构建和部署您自己的自定义OpenTelemetry Collector。这消除了在GCP上运行collector的猜测工作，但也使您可以自由地根据您的用例进行扩展。

该仓库将帮助您完成以下任务：

• 使用collector-builder编译为GCP设计的自定义Collector。借助上游collector-builder工具，您可以实现低开销的Collector构建，因此我们提供了针对GCP服务的构建轻量级collector的设置文件。这是GCP推荐的在GCP上运行或与GCP服务一起工作时使用的基本组件集。OpenTelemetry可能会很复杂和令人生畏，所以我们提供了一个经过策划和测试的配置作为起点。

• 使现有的OpenTelemetry Collector教程适应GCP的用例。通过提炼可用的有关使用Collector的广泛资料，并将设置抽象为几个简单的命令，该仓库将简化自定义collector的设置过程。

• 保持Collector部署的最新状态。通过将自定义Collectors纳入您的CI/CD流水线中，您可以自动化构建，确保您的Collector始终与最新功能和修复版本保持一致。在此仓库中，我们将展示使用Cloud Build的一种方法。

每个任务都代表了使用OpenTelemetry Collector的“入门”过程的一部分，因此通过识别和整合这些步骤，我们希望加速和简化体验，仅需几个点击即可完成。

构建适合您需求的OpenTelemetry Collector

虽然OpenTelemetry社区有一些公共的Collector的Docker镜像发布出来，但这些镜像的大小可能高达40MB。这是由于默认将所有的接收器、处理器和导出器都捆绑在镜像中。使用所有这些默认组件，还存在可能引发安全问题的潜在风险，这也是为什么Collector维护者建议仅启用必要的组件的原因之一。

collector-builder工具通过一个简单的YAML配置文件加速了只包含必要组件的精简Collector镜像的编译过程。该文件声明了在构建过程中要包含的组件，而collector-builder仅包含这些组件（没有其他组件）。这与默认Collector构建的过程不同，后者会在编译的二进制文件中包含更多的组件（即使它们在Collector的运行时配置中没有被启用）。这种差异是您可以通过删除许多多余组件来获得优于包含许多额外依赖项的公共镜像的改进。现在，这些额外组件无法占用空间，因为它们在定制构建中甚至不可用。

为了展示这是如何工作的，我们从该仓库中的示例配置文件开始，该文件已填充了几个适用于GCP的最相关的OpenTelemetry组件。但是，我们鼓励您修改该示例文件以适应您的用例。

例如，下面的构建文件仅包含OTLP接收器和OTLP导出器，以及一个日志导出器：

receivers:
  - import: go.opentelemetry.io/collector/receiver/otlpreceiver
    gomod: go.opentelemetry.io/collector v0.57.2

exporters:
  - import: go.opentelemetry.io/collector/exporter/otlpexporter
    gomod: go.opentelemetry.io/collector v0.57.2
  - import: go.opentelemetry.io/collector/exporter/loggingexporter
    gomod: go.opentelemetry.io/collector v0.57.2

编辑仓库中的this file并运行make build以自动生成本地二进制文件，或者运行make docker-build以编译一个容器镜像。

快速在GKE上启动

为了方便起见，该仓库包括了在GKE集群中部署Collector所需的最小Kubernetes清单，同时还包括了用于示例collector-builder组件的兼容运行时配置。当一起使用时，提供了用于构建和推送图像到Artifact Registry的Make命令，这些命令将自动更新仓库中的清单以使用新创建的图像，提供端到端的构建和部署参考。

在GKE上部署Collector

正如在本文之前提到的，Collector提供了与厂商无关的日志、指标和跟踪遥测数据的路由和处理能力。例如，虽然您可能已经在GKE上使用了一个收集器代理（例如用于指标和日志），但Collector可以为导出跟踪提供一条路径。这些跟踪可以发送到您选择的可观察性后端。它还具有处理和导出其他遥测信号到任何后端的灵活性。

使用提供的Kubernetes清单，您只需要一个kubectl命令即可部署Collector：

kubectl apply -f k8s/manifest.yaml -n otel-collector

使用此示例配置文件生成的Collector，匹配的OpenTelemetry Collector配置类似于以下内容：

receivers:
  otlp:
    protocols:
      grpc:
      http:
exporters:
  otlp:
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp]

在GKE中，Collector通过安装在Collector Pod中的Kubernetes ConfigMap来消耗此配置文件。可以使用一个简单的kubectl命令创建该ConfigMap：

kubectl create configmap otel-config --from-file=./otel-config.yaml -n otel-collector

修改Collector配置

OpenTelemetry配置文件格式允许通过最小的中断重新路由遥测数据来热替换Collector配置。例如，临时启用“日志记录”导出器可能很有用，该导出器提供有关Collector的调试洞见。只需编辑上述本地配置文件，添加两行即可实现：

receivers:
  otlp:
    protocols:
      grpc:
      http:
exporters:
  otlp:
  logging:
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp, logging]

然后可以使用kubectl apply重新应用运行时配置：

kubectl create configmap otel-config --from-file=./otel-config.yaml --dry-run=client -n otel-collector -o yaml | kubectl apply -f -

重新启动Collector Pod（例如使用kubectl delete或应用新的清单，如下所示），新的配置更改将生效。您可以通过启动kubectl apply进行此操作：

kubectl apply -f manifest.yaml -n otel-collector

这将触发新的Collector部署的滚动更新，以捕获配置更改和编译到更新图像中的新组件。

添加接收器和处理器

您可以添加更多组件，并按照与上述相同的步骤构建和部署新的Collector映像。例如，可以启用Zipkin导出器（用于将跟踪发送到Zipkin后端服务）和批处理处理器，方法是像下面这样编辑你先前的Builder配置：

receivers:
  - import: go.opentelemetry.io/collector/receiver/otlpreceiver
    gomod: go.opentelemetry.io/collector v0.57.2

processors:
  - import: go.opentelemetry.io/collector/processor/batchprocessor
    gomod: go.opentelemetry.io/collector v0.57.2

exporters:
  - import: go.opentelemetry.io/collector/exporter/otlpexporter
    gomod: go.opentelemetry.io/collector v0.57.2
  - import: go.opentelemetry.io/collector/exporter/loggingexporter
    gomod: go.opentelemetry.io/collector v0.57.2
  - import: github.com/open-telemetry/opentelemetry-collector-contrib/exporter/zipkinexporter
    gomod:
      github.com/open-telemetry/opentelemetry-collector-contrib/exporter/zipkinexporter
      v0.57.2

运行make docker-build将编译您的新版本Collector映像。如果您在GKE集群中设置了Artifact Registry以托管Collector图像，您还可以运行make docker-push并设置环境变量，以使图像在您的GKE集群中可用（有关此设置步骤的详细信息，请参见README）。

启用新的接收器和处理器，也遵循与上述相同的步骤，从编辑本地Collector配置文件开始：

receivers:
  otlp:
    protocols:
      grpc:
      http:
processors:
  batch:
    send_batch_max_size: 200
    send_batch_size: 200
exporters:
  otlp:
  logging:
  zipkin:
    endpoint: http://my-zipkin-service:9411/api/v2/spans
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp, logging, zipkin]

运行相同的kubectl apply命令来将配置更新到集群中：

kubectl create configmap otel-config --from-file=./otel-config.yaml --dry-run=client -n otel-collector -o yaml | kubectl apply -f -

现在，一旦您的Collector pod使用新镜像重新启动，它将开始使用新的导出器和处理器。当您运行make docker-build时，该命令会自动更新仓库中提供的Kubernetes部署清单，以指向您的新Collector图像。因此，只需再次运行kubectl apply即可将新图像更新到现有运行的Collector中：

kubectl apply -f manifest.yaml -n otel-collector

这将触发Collector部署的新滚动更新，捕获配置更改和编译到更新图像中的新组件。

自动化构建安全、最新的映像

构建自己的Collector使您可以控制Collector图像的更新和部署。在此仓库中，我们提供了一些示例，展示了如何在GCP上拥有您自己的Collector构建。

使用Cloud Build配置支持Serverless、自动化的Collector构建。通过这样做，您可以使Collector的组件在最短的延迟内从Collector的新版本中获益。结合Artifact Registry，这些构建可以作为Docker镜像推送到您的GCP项目中。这提供了图像的可移植性和可访问性，并使得支持Artifact Registry的容器漏洞扫描能够确保Collector部署的供应链安全性。

Serverless构建和容器漏洞扫描是可靠CI/CD流水线的重要组成部分。在这里，我们希望通过在该仓库中提供一些示例配置文件，抽象出周围这些流程的一部分复杂性。虽然我们提供了一些在GCP上设置这些操作的示例步骤，但其他供应商也可以采用类似的方法。

总结

OpenTelemetry Collector使遥测数据的接收和导出变得容易。这要归功于OpenTelemetry的供应商无关数据模型，也归功于支持不同后端自定义组件的活跃社区贡献者。这些组件为OpenTelemetry提供了支持各种用例的灵活性。

我们希望这个示例以及我们在这里讨论的一些示例用例能够帮助消除一些开发人员在开始使用OpenTelemetry时可能会遇到的障碍。如果您想提供一些反馈，请随时通过在GitHub上提issue报告任何功能请求或问题。

• ←上一页
• 下一页→