Use when an OpenTelemetry Collector config changes (a new receiver, processor or exporter) and must be verified before deploy. Runs otelcol validate, uses the debug or file exporter to assert spans flow through the pipeline, and wires the check into CI.
88%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
Full GitHub Actions workflow: validate the config, start the collector in Docker, send test spans, assert on the file exporter output, then tear down the container.
jobs:
collector-config-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Validate config
run: |
docker run --rm \
-v $PWD/collector-config.yaml:/etc/otel/config.yaml \
otel/opentelemetry-collector:0.153.0 \
validate --config=/etc/otel/config.yaml
- name: Start collector
run: |
docker run -d --name otel-test \
-p 4317:4317 \
-v $PWD/collector-config-test.yaml:/etc/otel/config.yaml \
-v /tmp/spans:/tmp/spans \
otel/opentelemetry-collector-contrib:0.153.0 \
--config=/etc/otel/config.yaml
- name: Send test spans and assert
run: |
sleep 2 # collector startup
# send spans (via SDK or grpcurl)
python3 tests/send_test_spans.py
sleep 2 # file exporter flush
# assert at least one span in output
[ $(wc -l < /tmp/spans/output.jsonl) -gt 0 ]
- name: Stop collector
if: always()
run: docker stop otel-test && docker rm otel-testNotes:
0.153.0 above) - the latest tag changes component
stability levels between releases.Source: OTel Collector quick-start docs - Docker image, port mapping.