observability-and-instrumentation

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

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

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 you 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: Emits JSON log events with stable event names, mandatory correlation IDs, entry-point attribution, and consistent log levels, while keeping secrets and PII out of telemetry. - Metrics and Tracing: Applies RED/USE metrics with bounded label cardinality and histogram percentiles, plus OpenTelemetry distributed tracing with context propagation across services and queues. - Symptom-Based Alerting and Runbooks: Defines actionable alerts on user-facing symptoms with thresholds, severities, and linked runbooks, then verifies the telemetry itself by inducing failures in staging. - Use Case: When adding a payment retry flow, use this Skill to define the on-call questions first, then add structured payment_failed log events, RED metrics on the provider calls, trace spans around charging, and an alert on error rate with a runbook link. ## Quick Start Use the observability-and-instrumentation skill to add structured logging, RED metrics, tracing, and an alert with a runbook to my new checkout endpoint.

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 production service?▼

Structured logging means emitting JSON objects with a stable event name and machine-readable fields instead of string-interpolated prose. Attach a correlation ID generated at the system boundary to every log line, and use consistent levels: error, warn, info, and debug.

What metrics should I instrument for HTTP endpoints?▼

Use RED metrics on every endpoint and external dependency: rate, errors, and duration as a latency histogram. Labels must come from small fixed sets like route template and status class, and you should read p50/p95/p99 percentiles rather than averages.

Should I use OpenTelemetry or Prometheus for instrumentation?▼

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

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 take down the metrics backend. High-cardinality lookups belong in logs and traces instead.

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, and observability is what makes future debugging fast. It also does not cover profiling measured slowness or launch-day monitoring checklists.

How do I write alerts that do not create pager noise?▼

Alert on symptoms users feel, such as error rate or p99 latency, not on causes like CPU usage. Every alert must be actionable, link to a runbook, have a justified threshold and duration, and use only page and ticket severities.