observability

Design structured logging, metrics, tracing, and alerting for production systems.

Updated Aug 3, 2026
One-click install
npx skills add https://github.com/m-de-graaff/skills --skill observability-m-de-graaff
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: observability
Source: https://github.com/m-de-graaff/skills/tree/main/skills/observability
Command: npx skills add https://github.com/m-de-graaff/skills --skill observability-m-de-graaff

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Systems often ship without the instrumentation needed to diagnose failures, leaving teams unable to answer which users are affected, since when, and what changed when an incident occurs at 3am. ## Core Features & Use Cases - Structured Logging Standards: Enforces event-based logs with stable names, variable fields, consistent levels, and logger-level redaction of secrets and personal data. - Metrics and Cardinality Control: Applies RED and USE methods, mandates latency histograms and error ratios, and prevents unbounded label cardinality that turns metrics bills into outages. - Tracing and Alerting Design: Covers context propagation across HTTP, queues, and jobs, plus symptom-based alerts tied to SLO burn rates with runbook guidance. - Use Case: Before shipping a new payment endpoint, use this Skill to decide which spans, histograms, error ratios, and alerts to add so a future latency regression is diagnosable without a deploy. ## Quick Start Use the observability skill to design the logging, metrics, traces, and alerts for the new checkout service before it ships.

Frequently Asked Questions about observability

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

FAQPage Schema
How do I structure logs so they are queryable in production?▼

Write logs as events with a stable name and variable fields instead of prose sentences. For example, log "upload_failed" with fields like user_id and duration_ms, so you can filter, group, and aggregate on any field later.

What metrics should I add to a new service before shipping?▼

Use RED for request-serving code (rate, errors, duration) and USE for resources (utilization, saturation, errors). Always use histograms for latency, express errors as ratios, and instrument every outbound dependency with its own duration and error rate.

Why is high label cardinality dangerous in metrics?▼

A metric's cost is the product of its label values, so adding a label like user_id can multiply thousands of series into millions and cause an outage. Keep high-cardinality identifiers like user ids and request ids in logs and traces instead.

Should I alert on log patterns or metrics?▼

Alert on metrics, because a reworded log message silently disables a log-based alert. Alert on user-visible symptoms such as SLO burn rate and p99 latency, then diagnose with traces and confirm with logs.

What data must never appear in application logs?▼

Never log passwords, tokens, session ids, API keys, card numbers, government ids, Authorization headers, or full personal records. Log a reference such as a user id or hash, and enforce redaction at the logger rather than at each call site.