addy-observability-and-instrumentation

Instruments production code with structured logging, metrics, tracing, and alerting.

Updated Aug 21, 2026
One-click install
npx skills add https://github.com/TylerSimons1127/vibe --skill addy-observability-and-instrumentation-tylersimons1127
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: addy-observability-and-instrumentation
Source: https://github.com/TylerSimons1127/vibe/tree/main/skills/addy-observability-and-instrumentation
Command: npx skills add https://github.com/TylerSimons1127/vibe --skill addy-observability-and-instrumentation-tylersimons1127

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Production features often ship without telemetry, so when incidents occur engineers cannot tell what happened from the available data. This Skill guides you to instrument code alongside the feature so production behavior is visible and diagnosable from the outside. ## Core Features & Use Cases - Structured Logging: Enforces JSON log events with stable event names, consistent log levels, and mandatory correlation IDs propagated across services. - Metrics and Tracing: Applies RED/USE metric patterns with bounded label cardinality and OpenTelemetry distributed tracing with context propagation. - Symptom-Based Alerting: Designs actionable alerts tied to user-facing symptoms with runbooks, plus a verification process that test-fires alerts and validates telemetry output. - Use Case: When adding a payment retry flow to a checkout service, use this Skill to define on-call questions, add structured payment_failed log events, RED metrics on the provider calls, and a symptom-based error-rate alert before shipping. ## Quick Start Use the observability skill to instrument my new checkout endpoint with structured logs, RED metrics, tracing, and an alert before it ships to production.

Frequently Asked Questions about addy-observability-and-instrumentation

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

FAQPage Schema
How do I add structured logging to a production service?▼

Structured logging means emitting JSON log events with stable event names and machine-readable fields instead of string-interpolated prose. Attach a correlation ID generated at the system boundary to every log line, and never log secrets, tokens, or unredacted PII.

What metrics should I instrument for HTTP endpoints?▼

Use the RED pattern for every endpoint and external dependency: Rate, Errors, and Duration as a latency histogram. Labels must come from small fixed sets like route templates and status classes, never user IDs or raw URLs, to avoid cardinality explosions.

Should I use OpenTelemetry for distributed tracing?▼

OpenTelemetry is the vendor-neutral standard and its auto-instrumentation covers HTTP, gRPC, and common database clients with near-zero code. Add manual spans only around meaningful internal units of work and propagate trace context across every async boundary.

Why should alerts be symptom-based instead of cause-based?▼

Symptom-based alerts fire exactly when users are hurt, regardless of the underlying cause, while cause-based alerts like CPU thresholds fire when nothing is wrong and miss unpredicted failures. Every alert must be actionable, link to a runbook, and use only page and ticket severities.

When should I not use this observability skill?▼

Do not use it to diagnose a failure happening right now; that belongs to a debugging skill. It also does not cover performance profiling of measured slowness or launch-day monitoring checklists, which are handled by separate skills.