observability

Applies observability engineering practices for instrumentation, tracing, metrics, SLOs, and production debugging.

1|Updated May 21, 2026
One-click install
npx skills add https://github.com/vnovakovits/claude-skills --skill observability-vnovakovits
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: observability
Source: https://github.com/vnovakovits/claude-skills/tree/main/plugins/engineering-practices/skills/observability
Command: npx skills add https://github.com/vnovakovits/claude-skills --skill observability-vnovakovits

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Engineers often ship code they cannot interrogate in production: logs are unstructured strings, metrics explode with high-cardinality labels, alerts fire on causes instead of symptoms, and debugging relies on guesswork. This Skill provides a disciplined framework for making systems answerable to arbitrary questions without redeploying. ## Core Features & Use Cases - Instrumentation guidance: Structured logging, wide canonical events, OpenTelemetry setup (including .NET/ASP.NET Core examples), distributed tracing with sampling strategies, and context propagation. - Metrics and SLO discipline: RED, USE, and Four Golden Signals methods, cardinality rules, histogram-based latency, plus SLI/SLO/error-budget design and SLO-burn alerting. - Production debugging workflow: A hypothesis-driven loop using wide events and traces to localize, compare, and verify fixes. - Use Case: When adding a new endpoint, use this Skill to wrap the operation in spans, emit one canonical event per request, define an SLO, and set symptom-based alerts on its burn rate. ## Quick Start Ask Claude to review this service's instrumentation and suggest what to log, trace, and measure following observability best practices.

Frequently Asked Questions about observability

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

FAQPage Schema
How do I instrument a new service with OpenTelemetry?▼

Start with auto-instrumentation for HTTP server, HTTP client, and database calls, then add custom spans around business-critical operations using an ActivitySource or tracer. Export via OTLP to a collector, and follow OpenTelemetry semantic conventions for attribute names.

What is the difference between observability and monitoring?▼

Monitoring answers known-unknowns with pre-defined dashboards and alerts, while observability lets you ask new questions of a running system without redeploying. Observability relies on high-cardinality event data for root-cause investigation of unanticipated failures.

Should I put customer IDs on metric labels?▼

No. High-cardinality values like customer ID, user ID, or trace ID explode metric storage costs and should never be metric labels. Attach them as attributes on spans or wide structured events instead, and keep metric labels bounded.

How do I set SLOs and error budgets for a service?▼

Define an SLI reflecting user experience, such as percent of requests returning 2xx under 500ms, then set an SLO target over a window like 99.9% over 30 days. The error budget is 1 minus the SLO, and alerts should fire on budget burn rate.

Why is mean latency misleading on dashboards?▼

A mean of 100ms can hide a p99 of 5 seconds where users actually suffer. Always emit histograms and report percentiles such as p50, p95, p99, and p99.9 instead of averages.

When should I use wide events instead of the three pillars?▼

Use one wide structured event per unit of work when you face unanticipated debugging questions, multi-tenant slicing needs, or tail-latency investigations. Metrics and traces can be derived from these events at read time rather than stored separately.