logging-sucks

Generate structured, context-rich log events with correlation IDs for debugging.

Updated Aug 23, 2021
One-click install
npx skills add https://github.com/undg/.dot --skill logging-sucks-undg
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: logging-sucks
Source: https://github.com/undg/.dot/tree/main/opencode/.config/opencode/skill/logging-sucks
Command: npx skills add https://github.com/undg/.dot --skill logging-sucks-undg

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Logs are often unstructured and hard to query, making debugging and incident response slow. This skill promotes structured, context-rich logging with wide events per request, correlation IDs, and high-cardinality fields to enable fast root-cause analysis.

Core Features & Use Cases

  • Wide events / canonical log lines: emit one comprehensive event per request with 30-50 fields for effective debugging.
  • Structured logging requirements: enforce timestamp, level, event, request_id, trace_id, service, environment, and privacy considerations.
  • Context propagation and observability: ensure correlation IDs traverse service boundaries for end-to-end tracing.
  • Use cases: incident response, post-incident analysis, and real-time dashboards for service health.

Quick Start

Configure your services to emit a single, wide, structured event per request with correlation IDs and high-cardinality fields.

Frequently Asked Questions about logging-sucks

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

FAQPage Schema
What is structured logging and how does it improve debugging?

Structured logging improves debugging by emitting context-rich, wide events per request with enforced fields like timestamp, level, and trace_id. This format enables fast querying and root-cause analysis during incident response.

How do I propagate trace IDs for cross-service tracing in microservices?

To propagate trace IDs for cross-service tracing, configure services to emit structured events containing request_id and trace_id fields. This ensures correlation IDs traverse service boundaries for end-to-end visibility.

What's the best way to format logs for incident response and post-incident analysis?

The best way to format logs for incident response is using canonical log lines. Emit one comprehensive, wide event per request containing 30-50 high-cardinality fields for effective, fast root-cause analysis.

Does structured logging work for distributed systems and microservices?

Structured logging works effectively for distributed systems and microservices by enforcing context propagation. Correlation IDs traverse service boundaries, providing per-request visibility and supporting end-to-end observability.

What fields should be included in structured log events for observability?

Structured log events for observability must include timestamp, level, event, request_id, trace_id, service, and environment fields. They should also incorporate high-cardinality data while ensuring non-sensitive data handling.

Why are unstructured logs hard to query during incident response?

Unstructured logs are hard to query because they lack context-rich, wide events and correlation IDs. Without enforced fields like trace_id and request_id, cross-service tracing and root-cause analysis become slow.