observability-and-instrumentation

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

Updated Sep 5, 2026
One-click install
npx skills add https://github.com/nntoan/ultra-omp --skill observability-and-instrumentation-nntoan
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: observability-and-instrumentation
Source: https://github.com/nntoan/ultra-omp/tree/main/packages/proflow/skills/observability-and-instrumentation
Command: npx skills add https://github.com/nntoan/ultra-omp --skill observability-and-instrumentation-nntoan

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires prom-client, @opentelemetry/sdk-node, @opentelemetry/auto-instrumentations-node, and includes references (resource) components.

What problem does it solve? Production features often ship without telemetry, leaving teams blind when incidents occur and unable to answer what the system is doing or why. This Skill guides you to instrument code alongside development so failures are diagnosable from logs, metrics, and traces instead of guesswork. ## Core Features & Use Cases - Structured Logging: Enforces JSON log events with stable event names, correlation IDs, entry-point attribution, and consistent log levels, while blocking secrets and PII from telemetry. - Metrics and Tracing: Applies RED/USE metric patterns with bounded label cardinality and histogram percentiles, plus OpenTelemetry-based distributed tracing with context propagation. - Symptom-Based Alerting: Designs actionable alerts tied to user-facing symptoms with runbook links, and verifies telemetry by inducing failures in staging. - Use Case: When adding a payment retry flow with a queue and an external provider, use this Skill to define on-call questions, emit structured payment_failed events, add RED metrics for the provider, and create a symptom-based alert before shipping. ## Quick Start Use the observability-and-instrumentation skill to add structured logging, RED metrics, and OpenTelemetry tracing to my new checkout endpoint before it ships.

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 emits JSON objects with stable event names and machine-readable fields instead of interpolated strings. Attach a correlation ID via a child logger per request, use consistent levels (error, warn, info, debug), and never log secrets or full request bodies.

What metrics should I track for an HTTP API?▼

Track RED metrics on every endpoint and external dependency: rate, errors, and duration as a histogram. Keep label cardinality bounded to route templates and status classes, and read p50/p95/p99 percentiles rather than averages.

How do I set up distributed tracing with OpenTelemetry?▼

OpenTelemetry auto-instrumentation covers HTTP, gRPC, and common database clients by initializing the NodeSDK before other imports. Add manual spans around meaningful internal work and propagate context across HTTP headers and queue metadata so traces do not break.

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

Symptom-based alerts fire exactly when users are hurt, such as error rate above 1% for five minutes, regardless of cause. Cause-based alerts like CPU thresholds fire when nothing is wrong and miss unpredicted failures, training teams to ignore pages.

When should I not use this observability skill?▼

Do not use it to diagnose an active failure, which belongs to debugging workflows, or to profile measured slowness, which belongs to performance optimization. It covers instrumentation written alongside features, not launch-day monitoring checklists.