observability-and-instrumentation

Instruments production code with structured logs, metrics, traces, and symptom-based alerts.

Updated Mar 14, 2026
One-click install
npx skills add https://github.com/yourlabpt/yourlabpt_website --skill observability-and-instrumentation-yourlabpt
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: observability-and-instrumentation
Source: https://github.com/yourlabpt/yourlabpt_website/tree/main/projects/skills/observability-and-instrumentation
Command: npx skills add https://github.com/yourlabpt/yourlabpt_website --skill observability-and-instrumentation-yourlabpt

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires prom-client, @opentelemetry/sdk-node, @opentelemetry/auto-instrumentations-node.

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: Emit JSON log events with stable event names, correlation IDs, and entry-point attribution, while keeping secrets and PII out of log pipelines. - Metrics and Tracing: Apply RED/USE metrics with bounded label cardinality using Prometheus or OpenTelemetry, and add distributed tracing with context propagation across services and queues. - Alerting and Runbooks: Design symptom-based alerts with justified thresholds, two severity levels, and linked runbooks, then verify telemetry by inducing failures in staging. - Use Case: When adding a payment retry flow, define the on-call questions first, then add a payment_failed structured log event, a latency histogram for the provider call, trace spans around the charge step, and an alert on elevated error rate with a runbook link. ## Quick Start Use the observability-and-instrumentation skill to add logging, metrics, tracing, and alerting 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 means emitting JSON objects with a stable event name and machine-readable fields instead of interpolated strings. Attach a correlation ID via a child logger per request, use consistent log levels, and never log secrets or full request bodies.

What metrics should I track for an HTTP API?▼

Use the RED method: rate, errors, and duration for every endpoint and external dependency. Track latency as a histogram so you can query p95/p99 percentiles, and keep label values bounded to small fixed sets like route templates and status classes.

OpenTelemetry vs Prometheus for application monitoring?▼

They serve different signals: OpenTelemetry provides vendor-neutral tracing and metrics APIs with auto-instrumentation for HTTP and database clients, while Prometheus is a common metrics backend. The RED/USE and cardinality rules apply identically regardless of backend choice.

Why do metric labels with user IDs cause problems?▼

Every unique label combination creates a separate time series, so unbounded values like user IDs, raw URLs, or error messages explode cardinality and can crash the metrics backend. High-cardinality lookups belong in logs and traces instead.

When should I not use this instrumentation approach?▼

Do not use it to diagnose an active incident, which belongs to debugging workflows, or to profile measured slowness, which belongs to performance optimization. This Skill covers writing telemetry alongside features, not operating on it after the fact.