otel-collector

name: otel-collector description: OpenTelemetry Collector component configuration. Use when authoring, reviewing, or debugging Collector YAML for a specific receiver, processor, exporter, connector, or extension — config keys, defaults, validation rules, signal support, stability levels, and component-level gotchas. Triggers on questions about specific components such as log_dedup / logdedup, interval (metric aggregation), tail_sampling, drain, redaction, filter, transform, probabilistic_sampler, attributes, resource, k8s_attributes / k8sattributes (Kubernetes metadata enrichment), routing (connector — route telemetry to pipelines by OTTL condition), memory_limiter (OOM safety valve / backpressure), load_balancing / loadbalancing (trace-ID/service-aware exporter that pins related telemetry to one backend, for scaling tail_sampling), otlp receiver (the canonical OTLP/gRPC + OTLP/HTTP ingress; localhost vs 0.0.0.0 default), otlp / otlp_grpc exporter (OTLP/gRPC egress with sending_queue.batch, retry_on_failure; renamed from otlp), file_log / filelog receiver (tail and parse log files via stanza operators; start_at, multiline, offset tracking), resource_detection / resourcedetection (auto-detect host/cloud/k8s/env resource attributes via detectors), file_storage (storage extension — persist receiver read offsets, exporter persistent send queues, and processor decision caches to local disk via bbolt so they survive a restart), prometheus receiver (scrape Prometheus-format endpoints into OTLP metrics via an embedded prometheus/prometheus scrape manager; scrape_configs, target_allocator, trim_metric_suffixes, native histograms), prometheus exporter (expose pipeline metrics on a /metrics HTTP endpoint for a Prometheus server to scrape — pull not push, contrast prometheusremotewrite; endpoint, namespace, const_labels, metric_expiration, add_metric_suffixes/translation_strategy, enable_open_metrics), prometheus_remote_write / prometheusremotewrite exporter (push OTLP metrics to Prometheus Remote Write backends like Cortex/Mimir/Thanos — contrast the pull-based prometheus exporter; renamed in v0.154.0, RW1 by default with RW2 behind a feature gate, TLS-on default, snappy-only, remote_write_queue, external_labels, wal), and other Collector components covered in components/.

OpenTelemetry Collector

This skill covers the configuration surface of individual OpenTelemetry Collector components. It targets opentelemetry-collector and opentelemetry-collector-contrib.

It does not cover OTTL expressions (see otel-ottl), declarative SDK configuration (otel-declarative-config), or end-to-end pipeline design choices. Reach for those skills when the question is about transformation language, SDK setup, or pipeline composition.

Workflow

1. Identify the component. Find the type in the user's config or question (log_dedup, interval, otlp, …). Note that several components were renamed to snake_case in v0.150.0–v0.151.0 with deprecated aliases preserved — see Recent renames.
2. Load the component page. If the component is in the Component index, read components/<type>/README.md first — it carries the metadata, description, main use-cases, and a Details index. Open the linked detail files (configuration.md, verification.md, advanced.md, quirks.md, …) only as the question requires; don't load files you don't need.
3. If the component is not indexed, say so explicitly and fall back to the upstream README under processor/<name>/, receiver/<name>/, exporter/<name>/, connector/<name>/, or extension/<name>/ in opentelemetry-collector-contrib. Don't invent config keys from memory — Collector components evolve quickly.
4. Apply Collector-wide conventions. Named instances (type/name), stability levels, and pipeline placement rules in Collector-wide conventions apply to every component.
5. Verify. Run the component page's Verification recipe — telemetrygen (see the otel-telemetrygen skill) plus a debug or file exporter — to confirm the component behaves as the docs claim. Alpha- and Development-stability components are common here, and behavior changes between releases. See Verification harness for how to run a recipe end-to-end.

Component index

Each component is a directory under components/<type>/. The File column points at the lean README.md (metadata, description, main use-cases, and a Details index); the full config reference, verification recipe, advanced use-cases, and quirks live in on-demand detail files linked from that README.

Collector-wide conventions

Named instances

Every component type supports the type/name pattern so the same type can be configured more than once. The pipeline references the named form:

processors:
  log_dedup/health-checks:
    interval: 30s
    conditions:
      - 'attributes["log.type"] == "health_check"'
  log_dedup/access-logs:
    interval: 10s

service:
  pipelines:
    logs/health:
      processors: [log_dedup/health-checks]
    logs/access:
      processors: [log_dedup/access-logs]

Stability levels

Components publish a stability level per signal. Treat these as load-bearing when recommending production use:

Stability now varies per component — and per signal for multi-signal components (e.g. redaction is Beta for traces but Alpha for logs/metrics). Don't assume a single level for the indexed set: check each component's README header metadata table for the authoritative stability and surface it when the user asks about production readiness.

Recent renames

Many components were renamed to snake_case in v0.150.0–v0.151.0. The legacy names remain as deprecated aliases — old configs keep working but new configs should use the new names. Check the upstream component README for the exact rename version before flagging a config as broken.

Examples: logdedup → log_dedup, hostmetrics → host_metrics, spanmetrics → span_metrics, servicegraph → service_graph, k8sattributes → k8s_attributes, plus several _log and _check receivers.

Pipeline placement

Two rules of thumb that apply across components:

• memory_limiter belongs first in any processor list, before anything that allocates buffers (log_dedup, transform, tail_sampling, …).
• Batching is now done by the exporter's sending_queue.batch, not by a separate batch processor. Don't add batch to new pipelines.

Verification harness

Each component page's Verification section gives a config, a telemetrygen command, and the expected output. To run any of them:

1. Save the YAML to a file and start a collector that bundles the component — for components in the contrib/k8s distributions, otelcol-contrib --config <file>.yaml; for components not in any distribution, build a custom collector with the OpenTelemetry Collector Builder (OCB) first.
2. Send telemetry with telemetrygen (see the otel-telemetrygen skill).
3. Watch the debug exporter's stdout (or the file exporter's output) for the expected result.

The Verification configs are minimal repros: they omit memory_limiter and other production scaffolding on purpose, to isolate the component under test. Don't copy them verbatim into production.

Adding a new component to this skill

When extending coverage:

1. Create the directory components/<type>/. Files carry no frontmatter — only SKILL.md has frontmatter.
2. Write a lean README.md — always loaded, kept small:
   • Header metadata table — kind, type name, signals, per-signal stability, distributions, Go module, upstream README link, and a rename note if the component was renamed.
   • Description — what the component does and the mechanism, in 1–2 tight paragraphs (push detailed mechanism/reference into configuration.md).
   • Main use-cases — "Use when" / "Avoid when".
   • Related components — cross-links.
   • Details index — a bullet list where each item links a detail file followed by an em dash and a short description of its contents (e.g. - [Configuration](configuration.md) — config keys, defaults, validation), so the reader loads only what a question needs.
3. Split the rest into on-demand detail files under the same directory:
   • configuration.md — full config-reference table (key, type, default, validation) plus any mechanism/reference tables.
   • verification.md — a telemetrygen + debug/file exporter recipe that proves the documented behavior; cross-reference the otel-telemetrygen skill. Verify every telemetrygen flag against that skill — never assert a flag that doesn't exist. If telemetrygen can't produce the input the component needs, say so and point to an alternative (OTTL/transform, a custom emitter). Keep the config a minimal repro (see Verification harness).
   • advanced.md — named instances, multi-pipeline setups, combinations, and edge configs.
   • quirks.md — gotchas, stability caveats, memory model, a validation-error→fix table, anti-patterns, and troubleshooting.
   • Split a heavy section into its own file when it's large (e.g. policies.md for a big policy catalog); merge trivial sections into a sibling rather than create a stub. Repoint any in-page anchor links that now cross files.
4. Use components/log_dedup/ and components/interval/ as reference implementations of this structure.
5. Add a row to the Component index above (the File column points at components/<type>/README.md).
6. Update the description trigger phrases in this file's frontmatter if the new component introduces a clearly distinct user-facing keyword.