observability-and-instrumentation

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

Updated Jul 9, 2026
One-click install
npx skills add https://github.com/assafmanor/waypoint --skill observability-and-instrumentation-assafmanor
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: observability-and-instrumentation
Source: https://github.com/assafmanor/waypoint/tree/main/.claude/skills/observability-and-instrumentation
Command: npx skills add https://github.com/assafmanor/waypoint --skill observability-and-instrumentation-assafmanor

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Production features often ship without telemetry, so when something breaks, 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 day one. ## Core Features & Use Cases - Structured Logging: Enforces JSON log events with stable event names, consistent log levels, mandatory correlation/request IDs, and strict rules against logging secrets or PII. - Metrics and Tracing: Applies RED (Rate, Errors, Duration) and USE (Utilization, Saturation, Errors) methods with bounded label cardinality, histogram-based latency percentiles, and OpenTelemetry distributed tracing. - Symptom-Based Alerting: Designs actionable alerts tied to user-facing symptoms with runbook links, justified thresholds, and two-severity paging, plus a verification pass that test-fires alerts and validates telemetry output. - Use Case: When adding a payment retry flow with an external provider, use this Skill to define the on-call questions first, then emit structured failure events, RED metrics on the provider calls, and an alert on elevated error rates. ## Quick Start Instrument my new checkout endpoint with structured logs, RED metrics, and an OpenTelemetry trace, then define the alerts an on-call engineer would need.

Frequently Asked Questions about 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 Node.js service?▼

Emit JSON log events with a stable event name and machine-readable fields instead of string interpolation. Attach a correlation ID via a child logger per request, and use consistent levels: error for broken invariants, warn for handled degradation, info for business events.

What metrics should I track for an HTTP endpoint?▼

Use the RED method: request rate, error rate, and duration as a histogram with p50/p95/p99 percentiles rather than averages. Keep label cardinality bounded to small fixed sets like route template and status class, never user IDs or raw URLs.

Should I use OpenTelemetry or Prometheus for instrumentation?▼

OpenTelemetry is the vendor-neutral standard for tracing and metrics with auto-instrumentation for HTTP, gRPC, and common DB clients. Prometheus prom-client is one common metrics backend; the RED/USE and cardinality rules apply identically either way.

Why do high-cardinality metric labels cause problems?▼

Every unique label combination creates a separate time series, so labels like user IDs, request IDs, or error messages explode storage and query costs in the metrics backend. High-cardinality lookups belong in logs and traces instead.

When should an alert page someone versus create a ticket?▼

Page only for user-facing symptoms requiring immediate action, such as error rate above 1% for five minutes. Use ticket severity for degradations actionable within a week, and avoid alerting on causes like CPU usage that fire when nothing is wrong.