x-observability

What problem does it solve?

This Skill ensures consistent OpenTelemetry observability when you add new external operations, adapter packages, or server middleware, so traces and metrics are meaningful and middleware ordering doesn’t hide failures.

Core Features & Use Cases

• App-level monitoring bootstrap: initialize monitoring via monitoring.InitDefault with safe shutdown semantics.
• Package-level tracer/meter discipline: define one tracer and one meter per package and use consistent span naming like packageName.Operation.
• HTTP/gRPC/GraphQL observability ordering: set middleware/interceptors order so monitoring is outer to recovery, preserve parent spans for GraphQL, and follow the established gRPC middleware chain.
• Meaningful telemetry only: add spans and metrics only where they reflect real request/error/latency signals, avoiding sensitive data in span attributes.

Quick Start

Add observability for your new adapter or middleware by wiring monitoring.InitDefault at the application bootstrap, creating a package tracer/meter with consistent span names, and placing HTTP monitoring outside recovery while keeping GraphQL as a child of the HTTP monitoring span.