在GCP上使用带有示例配置的Collector Builder

OpenTelemetry Collector 是一个用于处理和导出遥测数据的通用工具。凭借其模块化设计，它支持从许多不同的来源接收数据，并将数据路由到同样多的可观察性后端。这种基于独立接收器、处理器和导出器的设计，使第三方能够开发新的后端支持。它还允许用户配置定制化的遥测管道以满足其用例。

这个 collector-builder 工具将这种可定制性推向了一个新的高度，提供了一种方式来轻松编译一个只包含特定接收和导出组件的 Collector 二进制文件。与默认捆绑了许多组件的公开可用二进制版本不同，自定义 Collector 可以精简，只包含你真正关心的组件。这意味着编译后的 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 的设置过程简化为几个简单的 Make 命令。

• 保持 Collector 部署的最新。 通过将自定义 Collector 集成到您的 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 接收器和导出器，以及一个日志导出器

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

编辑存储库中的 此文件，运行 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 来消耗此配置文件。这个 ConfigMap 是通过一个基本的 kubectl 命令创建的。

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

修改 Collector 配置

OpenTelemetry 配置文件格式允许热插拔 Collector 配置，以最小的干扰来重新路由遥测数据。例如，暂时启用 logging 导出器可能很有用，它提供 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 或应用新的清单，如下所示）后，新的配置更改将生效。此工作流程可用于启用或禁用任何 OpenTelemetry 导出器，许多流行的可观察性后端都有可用的导出器。

添加接收器和处理器

您可以按照上述相同过程添加更多组件并构建和部署新的 Collector 镜像。例如，您可以启用 Zipkin 导出器（用于将追踪发送到 Zipkin 后端服务）和 batch 处理器，通过编辑之前的构建配置，如下所示：

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 镜像的新版本。如果您设置了 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 镜像。因此，使用新镜像更新现有的运行中 Collector 只需再次运行 kubectl apply。

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

这将触发您的 Collector 部署的新一轮滚动更新，采纳配置更改和编译到更新镜像中的新组件。

自动化构建，确保镜像安全且最新

构建自己的 Collector 使您能够控制 Collector 镜像的更新和部署。在此存储库中，我们提供了一些示例，说明如何在 GCP 上拥有自己的 Collector 构建。

使用 Cloud Build 配置支持 Collector 的无服务器自动化构建。通过这样做，您可以最小延迟地受益于 Collector 组件的新版本、功能和错误修复。结合 Artifact Registry，这些构建可以作为 Docker 镜像推送到您的 GCP 项目。这提供了镜像的可移植性和可访问性，并允许在 Artifact Registry 中进行容器漏洞扫描，以确保您的 Collector 部署的供应链安全。

无服务器构建和漏洞扫描是可靠 CI/CD 管道的重要组成部分。在这里，我们希望通过在此存储库中提供示例配置来抽象出这些流程中的一些复杂性。虽然我们提供了一些设置这些功能的示例步骤，但类似的实现方法也可用于许多其他供应商。

总结

OpenTelemetry Collector 使数据的摄取和导出变得容易。这得益于 OpenTelemetry 的供应商无关数据模型，也得益于活跃的社区支持用于不同后端的自定义组件。这些组件为 OpenTelemetry 支持各种用例提供了灵活性。

我们希望这个示例以及我们在这里讨论的一些示例用例，能够帮助您克服在开始使用 OpenTelemetry 时遇到的一些困难。如果您想提供反馈，请随时通过 在 GitHub 上打开一个 issue 来报告任何功能请求或问题。

• ←上一篇
• 下一篇→