This repository is a demonstration of the capabilities of OpenTelemetry Weaver for designing your observability.
The key principle is treating observability (metrics, logs, spans, etc.) just as you would an API.
This project demonstrates the following key capabilities of weaver:
weaver registry check: Ensures defined observability signals match policies (e.g. backwards compatibility)weaver registry generate: Creates example applications.sides from Observability Day EU 2025 talk
The example application is a dead simple HTTP service that provides "auction" capabilities. New bids are posted to the /auction/{auction_id}/bid endpoint.
This example showed tracking bids via metrics and spans.
auction.bid.count metric, defined in the o11y
directory.o11y/ directory contains all defined observability signals specific to this application.docs/o11y directory contains autogenerated documentation about the defined metric.go/o11y directory contains autogenerated Go library that will simplify writing
all defined metrics in the project.policies/ directory contains policies that will be enforced on observability signal definitions.templates/registry directory contains templates for autogenerating documentation and code.
templates/registry/markdown contains documenation generatoin templates.templates/registry/go contains Go code generation templates.templates/registry/rust contains Rust code generation templates.go/ contains the Go example application code.make generate-gomake generate-rustcd gogo run .curl localhost:8080/auction/1/bid e.g.curl localhost:2223/metricsRun make generate-docs.
All docs in the docs/ directory will be updated.
Run make check and all defined policies for Weaver will be checked against
defined telemetry.
Note: We recommend including policy checks in CI/CD pipelines.
Jinja
51.4%
Open Policy Agent
35.2%
Go
8.4%
Makefile
4.7%
This repository is a demonstration of the capabilities of OpenTelemetry Weaver for designing your observability.
The key principle is treating observability (metrics, logs, spans, etc.) just as you would an API.
This project demonstrates the following key capabilities of weaver:
weaver registry check: Ensures defined observability signals match policies (e.g. backwards compatibility)weaver registry generate: Creates example applications.sides from Observability Day EU 2025 talk
The example application is a dead simple HTTP service that provides "auction" capabilities. New bids are posted to the /auction/{auction_id}/bid endpoint.
This example showed tracking bids via metrics and spans.
auction.bid.count metric, defined in the o11y
directory.o11y/ directory contains all defined observability signals specific to this application.docs/o11y directory contains autogenerated documentation about the defined metric.go/o11y directory contains autogenerated Go library that will simplify writing
all defined metrics in the project.policies/ directory contains policies that will be enforced on observability signal definitions.templates/registry directory contains templates for autogenerating documentation and code.
templates/registry/markdown contains documenation generatoin templates.templates/registry/go contains Go code generation templates.templates/registry/rust contains Rust code generation templates.go/ contains the Go example application code.make generate-gomake generate-rustcd gogo run .curl localhost:8080/auction/1/bid e.g.curl localhost:2223/metricsRun make generate-docs.
All docs in the docs/ directory will be updated.
Run make check and all defined policies for Weaver will be checked against
defined telemetry.
Note: We recommend including policy checks in CI/CD pipelines.
Jinja
51.4%
Open Policy Agent
35.2%
Go
8.4%
Makefile
4.7%