observability-and-instrumentation

Name: observability-and-instrumentation
Availability: InStock
Author: ByronWilliamsCPA

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

Updated Jul 9, 2026

Search Tags:#metrics #observability #tracing #instrumentation #alerting #opentelemetry #structured logging

Ready to run

npx skills add https://github.com/ByronWilliamsCPA/plugin --skill observability-and-instrumentation-byronwilliamscpa

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: observability-and-instrumentation
Source: https://github.com/ByronWilliamsCPA/plugin/tree/main/plugins/wff-code/skills/observability-and-instrumentation
Command: npx skills add https://github.com/ByronWilliamsCPA/plugin --skill observability-and-instrumentation-byronwilliamscpa

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Production features often ship without telemetry, so when incidents occur engineers cannot tell what happened. This Skill guides you to instrument code alongside the feature so on-call questions can be answered from logs, metrics, and traces instead of guesswork. ## Core Features & Use Cases - Structured Logging: Emit JSON log events with stable event names, consistent levels, and mandatory correlation IDs, while keeping secrets and PII out of the pipeline. - Metrics and Tracing: Apply RED metrics for endpoints and dependencies, USE metrics for resources, bounded label cardinality, histogram percentiles, and OpenTelemetry distributed tracing. - Symptom-Based Alerting: Create actionable alerts on user-facing symptoms with runbook links, test-firing, and a separate security-alerting axis. - Use Case: When adding a payment retry flow, define the on-call questions first, then add a payment_failed log event, a provider latency histogram, and an error-rate alert, and verify each signal in staging before shipping. ## Quick Start Ask the AI to instrument a new endpoint or background job with structured logging, RED metrics, tracing, and an alert using this observability skill.

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 log events with stable event names and machine-readable fields instead of interpolated strings. Attach a correlation ID at the request boundary, use consistent levels (error, warn, info, debug), and never log secrets or full PII.

What are RED metrics and when should I use them?▼

RED metrics are Rate, Errors, and Duration, applied to every request-driven endpoint and external dependency. For resources like queues and pools, use USE metrics instead: Utilization, Saturation, and Errors. Track latency as histogram percentiles, not averages.

Should I use OpenTelemetry or Prometheus for instrumentation?▼

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

Why do metric labels with user IDs cause problems?▼

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. Labels must come from small fixed sets such as route templates and status classes; unbounded values belong in logs and traces.

When should I not use this observability skill?▼

Do not use it to diagnose an active failure; use debugging skills for that, since observability is what makes future diagnosis fast. It also does not cover performance profiling of measured slowness or launch-day monitoring checklists, which belong to separate skills.