Observability - Reliability and Consistency with OpenTelemetry Weaver

OpenTelemetry Weaver (v0.16.1) revolutionizes observability by enforcing Semantic Conventions in CI/CD pipelines. This CLI tool validates telemetry data, generates type-safe SDKs, and auto-documents signals, ensuring consistent, governable observability across systems.

Observability - Reliability and Consistency with OpenTelemetry Weaver
Photo by JJ Ying / Unsplash
"quality insights come from quality data"
opensight.ch - roman hüsler

Open Telemetry - Semantic Conventions

image - telemetry collection flow

Recently I've encountered significant challenges with observability data governance. When onboarding telemetry data from systems, inconsistent naming and labeling of that telemetry data across those systems often lead to a fragmented, chaotic mess in the observability platform, making it difficult to derive meaningful insights.
Problems that can arise from inconsistent telemetry data:

  • Broken alerts and Dashboards due to metric name changes
  • Hard-to-read queries from inconsistent naming
  • Undocumented telemetry leading to confusion
  • Missing instrumentation, only discovered in production

After researching the issue, I discovered that the observability industry is actively addressing this problem through collaborative standardization efforts. One standout initiative is OpenTelemetry Semantic Conventions, part of the broader OpenTelemetry project under the Cloud Native Computing Foundation (CNCF).

OpenTelemetry brings together major players like Dynatrace, Datadog, Elastic, and others to establish a unified standard for telemetry data—spanning metrics, logs, and traces. By defining consistent naming, structure, and metadata, these Semantic Conventions enable interoperability across observability tools, reducing fragmentation and enhancing data portability. This industry-wide push toward standardization promises to streamline observability workflows, minimize vendor lock-in, and tackle data governance challenges head-on. While OpenTelemetry is not a silver bullet, it represents a significant step toward a more cohesive and efficient observability ecosystem.

To illustrate the power of OpenTelemetry Semantic Conventions in standardizing telemetry data, consider the metric http.server.request.duration, which measures the duration of HTTP server requests in milliseconds. According to the OpenTelemetry Semantic Conventions for HTTP Metrics (available in the OpenTelemetry specification), this metric must include required attributes like http.request.method (e.g., "GET" or "POST") and http.response.status_code (e.g., 200 or 404) to ensure consistent interpretation across tools like Dynatrace or Grafana Alloy. For example, a conforming metric might look like: {name: "http.server.request.duration", value: 120.5, unit: "ms", attributes: {"http.request.method": "GET", "http.response.status_code": 200, "service.name": "my-web-app"}}. These attributes adhere to the conventions’ strict naming and typing rules, enabling seamless correlation of request durations across distributed systems. By enforcing such standards, OpenTelemetry ensures tools like Weaver can validate this metric in CI/CD pipelines, while Collectors like Grafana Alloy can filter out non-conforming data, maintaining a clean and governable observability pipeline.

Open Telemetry Weaver

GitHub - open-telemetry/weaver: OTel Weaver lets you easily develop, validate, document, and deploy semantic conventions
OTel Weaver lets you easily develop, validate, document, and deploy semantic conventions - open-telemetry/weaver

Now there is a new tool (introduced in 2025) open telemetry weaver, which is focused on design-time validation and could be run directly as part of a CI/CD-pipeline in order to validate observability data quality.
It is called "observabilty by design", because observability is integrated and designed right into the product. By aligning with OpenTelemetry’s Semantic Conventions, Weaver helps standardize observability data, paving the way for a more cohesive ecosystem. Versioned as CLI v0.X, Weaver is production-ready with active releases (v0.16.1 as of July 4, 2025)

image - open telemetry weaver live check (high level)

Weaver is basically a command line utility that supports multiple functions.

  • Schema Definition
    Define telemetry schemas via semantic conventions
  • Validation
    Validate telemetry against defined schemas manually or in CI
  • Type-safe Code Gen
    Generate idiomatic client SDKs (Go, Rust, etc.) from those schemas.
  • Documentation Gen
    Auto-generate markdown docs for your signals
  • Live Checking (Focus of this Blog)
    Integrate in CI or runtime to ensure emitted telemetry conforms

In your CI/CD pipeline, you can spin up your application and send telemetry to weaver, which will then validate the telemetry against the semantic conventions and output a report. A more sophisticated architecture drawing of weaver can be found here.

Example App

In order to try out weaver, I created a test app that runs inside a docker container. it spins up an open telemetry collector and weaver directly in its own container and sends some telemetry to it. (Code is available on my Github)

# start testapp on docker http://localhost:3000
docker-compose up -d --build

Once the testapp is started, we can send some telemetry to weaver which is not compliant with the open telemetry semantic conventions by pressing the button "send non-compliant metrics". It will spin up an open telemetry collector, spin up weaver and then send some bad telemetry data.

image - sending some incorrect telemetry data to weaver

As an example, it sends a metric my_custom_counter_123{bad_label="test_value_1760100097079"}. That metric name does not exist in the open telemetry semantic conventions. Also the label attribute bad_label is not allowed according to semantic conventions. So lets look at the output of weaver:

image - weaver results

As a result we can see that weaver has detected the violations in the poorly formatted telemetry data. Here is the full raw output of weaver: github - weaver example output

The tool is still quite young - but I am excited about what it can bring to the table. The tool's value proposition is compelling: it treats telemetry schemas (derived from semantic conventions) as versioned, enforceable "public APIs," generating code, tests, and docs to catch inconsistencies early in the SDLC. Weaver's architecture explicitly plans for a WASM plugin system to extend its platform, which could enable direct runtime integration with Collectors (e.g. Grafana Alloy) for schema injection, validation, or even dynamic evolution.
opensigh.ch - roman hüsler