observability-and-instrumentation

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

5|Updated Feb 12, 2026
One-click install
npx skills add https://github.com/PHenrique07/Sementis-IFSP-Pirituba --skill observability-and-instrumentation-phenrique07
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: observability-and-instrumentation
Source: https://github.com/PHenrique07/Sementis-IFSP-Pirituba/tree/main/.github/skills/observability-and-instrumentation
Command: npx skills add https://github.com/PHenrique07/Sementis-IFSP-Pirituba --skill observability-and-instrumentation-phenrique07

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Production features often ship without telemetry, so when incidents occur 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 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 log pipelines. - 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 with context propagation. - Alerting and Runbooks: Defines symptom-based alerts with page/ticket severities, thresholds, durations, and linked runbooks, plus a verification step that test-fires alerts and validates telemetry output. - Use Case: When adding a payment retry flow, you define the on-call questions first, then add a payment_failed structured log event, a latency histogram for the provider, an OpenTelemetry span around the charge call, 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 emits JSON objects with stable event names and machine-readable fields instead of interpolated strings. 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 the RED method on every endpoint and external dependency: Rate, Errors, and Duration as a latency histogram. Keep label cardinality bounded to small fixed sets like route templates and status classes, and read p50/p95/p99 percentiles rather than averages.

Should I use OpenTelemetry for distributed tracing?▼

OpenTelemetry is the vendor-neutral standard for tracing, with auto-instrumentation covering HTTP, gRPC, and common database clients. Add manual spans only around meaningful internal units of work and propagate context across async boundaries 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 on CPU or disk fire when nothing is wrong and miss unpredicted failures, so causes belong on dashboards.

Can I use user IDs as metric labels for debugging?▼

No, user IDs, raw URLs, and error message text create unbounded cardinality that overwhelms metrics backends. High-cardinality identifiers belong in structured logs and traces, while metric labels must come from small fixed sets.

When should I not use this observability skill?▼

Do not use it to diagnose an active failure; that belongs to debugging workflows. It also does not cover performance profiling of measured slowness or launch-day monitoring checklists, which are separate concerns.