observability-and-instrumentation

Implements structured logging, metrics, tracing, and alerting for production code.

Updated Jul 10, 2026
One-click install
npx skills add https://github.com/CodeCrafterAdi2006/Ink-and-Code --skill observability-and-instrumentation-codecrafteradi2006
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: observability-and-instrumentation
Source: https://github.com/CodeCrafterAdi2006/Ink-and-Code/tree/main/Skills/observability-and-instrumentation
Command: npx skills add https://github.com/CodeCrafterAdi2006/Ink-and-Code --skill observability-and-instrumentation-codecrafteradi2006

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

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, and mandatory correlation/request IDs propagated across services. - Metrics and Tracing: Applies RED (Rate, Errors, Duration) and USE (Utilization, Saturation, Errors) methods with bounded label cardinality, plus OpenTelemetry-based distributed tracing with context propagation. - Symptom-Based Alerting: Designs actionable alerts tied to user-facing symptoms with runbook links, thresholds, and two severity tiers, then verifies telemetry by inducing failures in staging. - Use Case: When adding a payment retry flow with external provider calls, use this Skill to define on-call questions, emit structured payment_failed events, add latency histograms for provider calls, trace requests end-to-end, and create an alert on elevated error rates. ## Quick Start Instrument my new checkout endpoint with structured logs, RED metrics, and an OpenTelemetry trace, then define one symptom-based alert for it.

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 application?

Structured logging means emitting JSON objects with stable event names and machine-readable fields instead of interpolated strings. Attach a child logger per request carrying a correlation ID, and use consistent levels: error for broken invariants, warn for handled degradation, info for business events.

What metrics should I track for an HTTP API?

Use the RED method: Rate (requests per second), Errors (failure rate), and Duration (latency histogram). Track percentiles like p95 and p99 rather than averages, and keep label cardinality bounded to route templates and status classes.

How do I set up distributed tracing with OpenTelemetry?

Initialize the OpenTelemetry NodeSDK with auto-instrumentations before any other imports; it covers HTTP, gRPC, and common database clients automatically. Add manual spans around meaningful internal work and propagate context across async boundaries so traces do not break.

Why should I avoid user IDs as metric labels?

High-cardinality labels like user IDs, raw URLs, or error messages create a separate time series per unique value, which can overwhelm the metrics backend. Unbounded identifiers belong in logs and traces; metric labels must come from small fixed sets.

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 that can wait a week, and delete any alert whose response is to ignore it.