otel-collector-config

# OpenTelemetry Collector config — doctor Generate correct configs from a plain-English description, and diagnose broken ones. The Collector is a small set of concepts with a lot of sharp edges; this skill encodes the edges so the output validates on the first try. ## Mental model (get this right and everything follows) A Collector config has four component blocks plus a `service` block that wires them: ``` receivers: # where data comes IN (otlp, prometheus, hostmetrics, filelog, kafka…) processors: # what happens in the MIDDLE, in order (memory_limiter, batch, transform…) exporters: # where data goes OUT (otlp, otlphttp, debug, prometheus, prometheusremotewrite…) connectors: # bridge one pipeline's OUTPUT into another's INPUT (spanmetrics, routing…) extensions: # collector-level features, not in the data path (health_check, pprof, zpages…) service: extensions: [health_check] pipelines: traces: { receivers: [...], processors: [...], exporters: [...] } metrics: { receivers: [...], processors: [...], exporters: [...] } logs: { receivers: [...], processors: [...], exporters: [...] } telemetry: { ... } # the Collector's OWN logs/metrics ``` **The #1 rule everyone violates:** defining a component under `receivers:` / `processors:` / `exporters:` does **nothing** on its own. A component only runs if it is referenced inside a `service.pipelines.<signal>` list. A config can be "valid" yet do nothing because a pipeline was never wired. Always che...