open-telemetry/opentelemetry-collector

★ 6,982GoAudience · ops devopsComplexity · 4/5LicenseSetup · moderate

Mindmap

mindmap
  root((repo))
    What it does
      Collect observability data
      Route to monitoring tools
      Vendor agnostic pipeline
    Data types
      Metrics
      Traces
      Logs
    Run modes
      Agent on same machine
      Standalone network collector
    Extend it
      Custom receivers
      Custom processors
      Custom exporters
    Tech
      Go language
      Config file driven

mindmap root((repo)) What it does Collect observability data Route to monitoring tools Vendor agnostic pipeline Data types Metrics Traces Logs Run modes Agent on same machine Standalone network collector Extend it Custom receivers Custom processors Custom exporters Tech Go language Config file driven

Click or tap to explore — scroll the page freely

Things people build with this

USE CASE 1

Replace multiple monitoring agents with one Collector that routes data to Prometheus, Jaeger, and a cloud provider simultaneously.

USE CASE 2

Filter out noisy health-check spans before they reach your paid tracing backend to reduce costs.

USE CASE 3

Run the Collector as a sidecar container to centralize telemetry from a multi-service app without changing application code.

Tech stack

Getting it running

Difficulty · moderate Time to first run · 30min

Requires writing a YAML config file and understanding your app's telemetry output format before the Collector can route data correctly.

Open-source under Apache 2.0, use freely in any project, commercial or otherwise, with attribution.

In plain English

The OpenTelemetry Collector is a piece of software that sits between your applications and your monitoring tools. Its job is to receive observability data, which means metrics (numbers about how your app is performing), traces (records of requests as they flow through your system), and logs (text records of what happened), process or filter that data, and then send it on to wherever you store and analyze it. The reason this middle layer exists is that different monitoring and storage systems speak different data formats. Without something like the Collector, you might need to run a separate agent for each destination: one for Prometheus, one for Jaeger, one for a commercial monitoring service. The Collector speaks many input formats and many output formats, so you configure it once and it handles the translation and routing. This is what the README means by vendor-agnostic: it is not tied to any one monitoring company's product. You can run it in two modes. As an agent, it runs on the same machine as your application and collects data locally. As a standalone collector, it runs separately and receives data sent to it over the network from multiple applications at once. Both modes use the same configuration file format. The project is part of the OpenTelemetry initiative, which is a set of open standards and tools for observability maintained by the Cloud Native Computing Foundation. The Collector is written in Go and is designed to be extended: you can add new input receivers, processors, or output exporters without changing the core code. The README covers community meeting schedules (weekly video calls open to everyone), image signature verification for those downloading container images, Go version compatibility rules, and links to the configuration documentation and security guidelines. The project is actively maintained with regular releases and is considered stable.

Copy-paste prompts

Prompt 1

Write an OpenTelemetry Collector config.yaml that receives traces from a Python app via OTLP gRPC, drops health-check spans using a filter processor, and exports to both Jaeger and a Prometheus metrics endpoint.

Prompt 2

I want to run the OpenTelemetry Collector as a Docker service alongside my Node.js app. Write the docker-compose definition and a minimal config.yaml to collect application logs and ship them to Loki.

Prompt 3

My OpenTelemetry Collector is dropping data under high traffic. What batch processor and exporter retry settings should I configure to handle backpressure without losing telemetry?

Prompt 4

How do I build a custom exporter for the OpenTelemetry Collector in Go that sends spans to a proprietary in-house API without modifying the core collector code?

Open on GitHub → Explain another repo

← open-telemetry on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.