qa-distributed-tracing
Distributed tracing assertion testing: 6 skills (jaeger-trace-tests, opentelemetry-trace-assertions, otel-collector-config-tester, tempo-trace-tests, trace-spec-author, zipkin-trace-tests) and 1 agent (trace-coverage-reviewer). Asserts on production trace shape (spans, attributes, parent links, status), not just on aggregate metrics.
Install this plugin
/plugin install qa-distributed-tracing@testland-qaPart of role bundle: qa-role-backend
qa-distributed-tracing
Sets the observability assertion testing pattern for the marketplace - assertions on production trace shape (spans, attributes, parent links, status semantics), not just on aggregate metrics. An in-process assertion skill, one backend query skill (Jaeger, with Zipkin + Tempo in its references), a collector-config tester, a spec-authoring skill, and a reviewer agent that audits coverage + cardinality + spec drift.
Pairs naturally with qa-shift-right (synthetic monitoring), qa-saga-cqrs (saga trace shape), and qa-resilience (DR / runbook tracing).
Components
| Type | Name | Description |
|---|---|---|
| Skill | opentelemetry-trace-assertions | In-process span capture via InMemorySpanExporter + SimpleSpanProcessor (Python), getFinishedSpans() (JS), OpenTelemetryExtension (Java); name + attribute + status + parent assertions; SemConv enforcement |
| Skill | jaeger-trace-tests | Backend query tests for Jaeger (all-in-one Docker, OTLP :4317/:4318, /api/traces on :16686), Zipkin (references/zipkin.md: :9411 REST API, B3 propagation), and Tempo (references/tempo.md: TraceQL, /api/search) |
| Skill | trace-spec-author | Build-an-X for trace specifications: per-feature span set + required SemConv attributes + status semantics + cardinality rules + assertion checklist |
| Agent | trace-coverage-reviewer | Adversarial reviewer: untraced critical paths + missing SemConv attrs + deprecated keys + hand-rolled span code + cardinality risks + spec drift |
| Skill | otel-collector-config-tester | Validate an OpenTelemetry Collector pipeline config (receivers/processors/exporters) end to end. |
Install
/plugin marketplace add testland/qa
/plugin install qa-distributed-tracing@testland-qaSkills
jaeger-trace-tests
Author integration tests that query a tracing backend for cross-service trace verification - Jaeger, Zipkin, or Grafana Tempo, same run-query-assert workflow. Jaeger all-in-one Docker for CI (OTLP gRPC :4317 + HTTP :4318 ingest, query API on :16686), `/api/traces?service=X&operation=Y` query patterns, span set + parent-child + duration assertions; Zipkin (:9411 REST API, B3 single/multi-header propagation tests, dependency graph) in references/zipkin.md; Tempo (TraceQL span selectors + structural operators, /api/search, single-binary Docker) in references/tempo.md. Use when verifying that a request produces the expected spans across service boundaries in a running Jaeger, Zipkin, or Tempo backend.
opentelemetry-trace-assertions
Author trace-shape assertions in tests using OpenTelemetry SDK in-memory exporter - capture spans during test execution, assert on span name + attributes + status + parent-child structure + duration. Cross-language patterns (Python `InMemorySpanExporter` + `SimpleSpanProcessor`, JS `getRecordedSpans()`, Java `OpenTelemetryExtension`); CI integration. Use when a service is instrumented with the OpenTelemetry SDK and downstream alerts, SLOs, or dashboards depend on specific span names or attributes that a refactor could silently drop.
otel-collector-config-tester
Validates OpenTelemetry Collector pipeline configurations and verifies spans flow end-to-end through the collector: runs `otelcol validate --config`, wires the `debug`/`file` exporter for span-output assertions, and integrates the full cycle into CI. Use when a collector config change (new receiver, processor swap, exporter wiring) needs correctness verification before deployment.
trace-spec-author
Build a trace specification document per feature - defines the trace shape (root span + child spans + key attributes per OpenTelemetry semantic conventions) that production code MUST emit. The spec drives both implementation reviews AND trace-assertion tests, so a single declarative document is the source of truth for what observability "looks like" for a feature. Use before instrumenting a new feature, when existing spans have grown organically with no agreed shape, or after an incident where a debugging session stalled on missing span attributes.