https://github.com/jsuereth/o11y-by-design
Example code for KubeCon Observability by Design talk.
https://github.com/jsuereth/o11y-by-design
Last synced: about 1 year ago
JSON representation
Example code for KubeCon Observability by Design talk.
- Host: GitHub
- URL: https://github.com/jsuereth/o11y-by-design
- Owner: jsuereth
- License: apache-2.0
- Created: 2025-03-21T22:24:20.000Z (about 1 year ago)
- Default Branch: main
- Last Pushed: 2025-04-07T15:32:36.000Z (about 1 year ago)
- Last Synced: 2025-04-07T16:41:30.765Z (about 1 year ago)
- Language: Jinja
- Size: 56.6 KB
- Stars: 7
- Watchers: 2
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Observability by Design
This repository is a demonstration of the capabilities of [OpenTelemetry Weaver](https://github.com/open-telemetry/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](https://docs.google.com/presentation/d/1U36ageT5_oIiPTKGFcR7L0yqJP805zwU/edit?usp=sharing&ouid=116090704407622565882&rtpof=true&sd=true)
## Example Application
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.
- Spans leverage OOTB http semantic conventions from the OpenTelemetry project.
- Metrics use a newly deifned `auction.bid.count` metric, defined in the `o11y`
directory.
## Directory layout
- The `o11y/` direcotry contains all deifned observability signals specific to this application.
- THe `docs/o11y` directory contains autogenerated documentation about the defined metric.
- The `go/o11y` directort contains autogenerated Go library that will simplify writing
all defined metrics in the project.
- The `policies/` directory contains policies that will be enforced on observability signal definitions.
- The `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.
## Building
1. Generate code for Go: `make generate-go`
2. Generate code for Rust: `make generate-rust`
## Running
1. Running the Go Example
- Move to the go directory: `cd go`
- Run the go server `go run .`
- In a separate terminal, issue some requests
`curl localhost:8080/auction/1/bid` e.g.
- Check the prometheus metrics:
`curl localhost:2223/metrics`
2. Running the Rust Example
TODO
## Generating Docs
Run `make generate-docs`.
All docs in the `docs/` directory will be updated.
## Verify Policy
Run `make check` and all defined policies for Weaver will be checked against
defined telemetry.
_Note: We recommend inlcuding policy checks in CI/CD pipelines._