x-observability

Establish OpenTelemetry observability for HTTP, gRPC, and GraphQL instrumentation.

2|Updated Apr 12, 2026
One-click install
npx skills add https://github.com/pure-golang/level85 --skill x-observability
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: x-observability
Source: https://github.com/pure-golang/level85/tree/main/.agents/skills/x-observability
Command: npx skills add https://github.com/pure-golang/level85 --skill x-observability

SYSTEM DOCUMENTATION & REQUIREMENTS

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.

Frequently Asked Questions about x-observability

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I set up OpenTelemetry tracing and metrics for a new HTTP or gRPC operation?

To set up OpenTelemetry observability, initialize monitoring via monitoring.InitDefault at bootstrap, define one package-level tracer and meter, and apply consistent span naming like packageName.Operation for HTTP and gRPC operations.

What is the correct middleware ordering for OpenTelemetry monitoring and recovery?

OpenTelemetry monitoring middleware must be placed outside recovery middleware. This ordering ensures monitoring captures the full request lifecycle, preventing recovery handlers from hiding latency or error signals from traces.

How do I preserve parent-child trace relationships when instrumenting GraphQL operations?

To preserve parent-child trace relationships in GraphQL, ensure the GraphQL operation span is created as a child of the outer HTTP monitoring span. This maintains continuous trace context across transport and application layers.

Can telemetry or tracing failures block my application's main execution flow?

No, telemetry and tracing failures must not block the application. Observability instrumentation should be handled safely so that errors in span creation or metrics recording do not interrupt the primary business logic.

When should I add spans and metrics to an adapter package?

Add spans and metrics to adapter packages only when they reflect real request, error, or latency signals. Avoid creating meaningless telemetry and never include sensitive data in span attributes to maintain security compliance.