Project reference ↗

The OpenTelemetry Collector receives logs, numerical measurements and request traces, then sends them to monitoring tools. Maintaining many Collector deployments and application instrumentation settings can become repetitive. OpenTelemetry Operator lets platform teams describe those deployments through Kubernetes resources and manages the corresponding components. It can also arrange supported automatic instrumentation, which adds telemetry to an application without requiring every integration to be configured manually. Support depends on the language, runtime and chosen versions. The operator manages these components; a separate backend still stores and presents the resulting data.

Separate the release layers

The operator, Collector distribution, instrumentation libraries and telemetry backend have different compatibility constraints. Installing the operator does not mean every language, runtime or application can be instrumented without changes. Pin the selected versions and read the instrumentation documentation for the relevant runtime.

Adoption checks

Start with one noncritical service. Verify exported attributes, sensitive-data filtering, startup behavior and failure when the collector is unavailable. If instrumentation injection changes a workload, retain its prior deployment configuration and measure both application performance and telemetry quality. Review admission-webhook availability and the permissions used by the operator.

Use the Collector architecture guide to decide where the resulting telemetry should go before enabling injection broadly.

Sources & further reading

  1. Official Kubernetes Helm guidance
  2. OpenTelemetry Operator
  3. Dedicated Operator documentation

Spotted something that needs another look?

Help improve this page →