principle-observability

Design observability instrumentation with logs, metrics, traces, and SLO-based alerts.

2|8|Updated Apr 20, 2026
One-click install
npx skills add https://github.com/lugassawan/swe-workbench --skill principle-observability
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: principle-observability
Source: https://github.com/lugassawan/swe-workbench/tree/main/skills/principle-observability
Command: npx skills add https://github.com/lugassawan/swe-workbench --skill principle-observability

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents unreliable monitoring by teaching you how to choose the right observability signal and design alerts that reflect real user impact.

Core Features & Use Cases

  • Choose the right signal: Use logs for discrete events, metrics for time-based aggregations, and traces for causal latency and dependency mapping.
  • Avoid observability failure modes: Enforce structured logging, correlation/trace context propagation, and strict cardinality controls.
  • Make alerts actionable: Define SLIs/SLOs with error budgets, use RED/USE methods for consistent instrumentation, and alert on symptoms tied to user pain.

Quick Start

Ask the skill to help you design logging, metrics, and tracing for a service endpoint and propose SLI/SLO-based alerts with safe metric cardinality.

Frequently Asked Questions about principle-observability

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

FAQPage Schema
How do I choose between logs, metrics, and traces for service observability?

Use logs for discrete events, metrics for time-based aggregations, and distributed tracing for causal latency and dependency mapping. Selecting the right observability signal prevents unreliable monitoring and ensures you capture the correct system behavior.

How do I design SLO alerts based on user-visible symptoms?

Design SLO alerts by defining SLIs with error budgets and alerting on symptoms tied to user pain. Use the RED or USE methods for consistent instrumentation to ensure alerts are actionable and reflect real user impact.

What is metric cardinality and how do I control it when instrumenting services?

Metric cardinality refers to the number of unique label combinations in time-based aggregations. Control it by applying strict cardinality-safe metric design, preventing observability failure modes and backend resource exhaustion during service instrumentation.

How do I implement distributed tracing context propagation with OpenTelemetry?

Implement distributed tracing by applying OpenTelemetry-compatible trace propagation across services. This enables causal latency attribution and dependency mapping, ensuring you can track requests through complex distributed systems.

When should I use histogram-based duration metrics for latency monitoring?

Use histogram-based duration metrics when monitoring latency to support SLO error budget calculations. They provide accurate time-based aggregations for latency attribution, which are essential for debugging user-visible incidents.

What is the RED method and how does it apply to observability instrumentation?

The RED method measures Rate, Errors, and Duration for consistent observability instrumentation. Apply it alongside SLIs and SLOs to define error-budget thinking and create symptom-driven alert criteria for user-visible incidents.