observability-and-instrumentation

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

Instrument software systems with structured logs, metrics, and distributed traces.

4|Updated Jun 10, 2026

Search Tags:#monitoring #logging #metrics #observability #tracing #instrumentation #opentelemetry

Ready to run

npx skills add https://github.com/mymx2/foreman --skill observability-and-instrumentation-mymx2

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: observability-and-instrumentation
Source: https://github.com/mymx2/foreman/tree/main/.agents/skills/observability-and-instrumentation
Command: npx skills add https://github.com/mymx2/foreman --skill observability-and-instrumentation-mymx2

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This skill addresses the critical issue of blind production systems by providing a structured framework for implementing telemetry that makes system behavior visible, diagnosable, and actionable.

Core Features & Use Cases

Structured Telemetry: Standardizes logging, metrics, and tracing to ensure data is queryable and consistent.
Symptom-Based Alerting: Shifts focus from monitoring system causes (like CPU usage) to monitoring user-facing symptoms, reducing alert fatigue.
Use Case: When deploying a new microservice, use this skill to define RED metrics for endpoints, implement OpenTelemetry tracing for cross-service requests, and set up actionable alerts that notify the team only when user experience is degraded.

Quick Start

Use the observability-and-instrumentation skill to audit the current telemetry implementation and add structured logging and RED metrics to the new service.

Frequently Asked Questions about observability-and-instrumentation

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I implement structured telemetry for a new microservice?▼

Structured telemetry standardizes logging, metrics, and distributed tracing to ensure production data is queryable and consistent. This approach instruments services with RED metrics and OpenTelemetry traces to make system behavior diagnosable.

What is symptom-based alerting and how does it reduce alert fatigue?▼

Symptom-based alerting monitors user-facing symptoms rather than system causes like CPU usage. This approach reduces alert fatigue by notifying teams only when user experience is degraded, ensuring alerts remain actionable.

How do I add OpenTelemetry distributed tracing to background jobs?▼

OpenTelemetry distributed tracing instruments background jobs by implementing cross-service request traces. This provides production visibility into system behavior, enabling reliable incident diagnosis for asynchronous workloads.

How do I manage high-cardinality metrics for production observability?▼

High-cardinality metric management structures telemetry data to maintain queryability without overwhelming storage. This framework ensures metrics remain consistent and actionable for reliable incident diagnosis.

Can I use this approach to audit existing telemetry implementations?▼

You can audit current telemetry implementations to identify blind spots in production systems. This process evaluates structured logging and RED metrics coverage to ensure system behavior is visible and diagnosable.

What's the best way to define RED metrics for service endpoints?▼

Defining RED metrics for endpoints standardizes Rate, Error, and Duration measurements to monitor user-facing symptoms. This structured approach ensures reliable monitoring and actionable alerting for deployed services.