loom-logging-observability

Solid

Logging and observability patterns for production systems.

DevOps & Infrastructure 56 stars 3 forks Updated today MIT

Install

View on GitHub

Quality Score: 87/100

Stars 20%
58
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# Logging and Observability ## Overview Understand system behavior through the three pillars — logs, metrics, traces — correlated by shared IDs. This skill covers structured logging, OpenTelemetry tracing, Prometheus metrics, aggregation backends, and alerting, with emphasis on the cost/cardinality traps and sampling decisions that separate a working setup from an expensive broken one. ## Three Pillars — what each answers, and its cost model | Pillar | Answers | Cost driver | Use for | | ----------- | ------------------------------------ | ----------------------------------- | ---------------------------------------------- | | **Metrics** | "Is it broken? how much?" (aggregate) | Label **cardinality** (# series) | Dashboards, SLOs, alerting — always-on, cheap | | **Traces** | "Where in the request path?" (causal) | Span volume → **sampling** | Latency breakdown, cross-service dependency | | **Logs** | "What exactly happened?" (event detail) | Volume + **indexing** strategy | Forensics, audit, the specifics of one request | Reach for metrics first (cheap, aggregate), traces to localize, logs for the detail. Link all three by `trace_id`/`correlation_id` so you can pivot: alert fires on a metric → jump to an exemplar trace → read that trace's logs. ## Structured Logging Emit JSON, one object per event — never string-interpolated prose. Structured field...

Details

Author
cosmix
Repository
cosmix/loom
Created
9 months ago
Last Updated
today
Language
Rust
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

observability

Production observability done right — structured logs, distributed traces, metrics, alerting, SLO/SLI. Use when adding logging to a new service, designing dashboards, choosing between OpenTelemetry / Datadog / Grafana stack, defining SLOs for a feature, writing alert rules, or untangling a noisy alert channel. Stack-agnostic; recipes target OpenTelemetry as the canonical instrumentation, Prometheus + Grafana / Datadog as the canonical backends. Pairs with performance (perf budgets), security-web (audit logs), and incident-response (alert → runbook).

6 Updated 5 days ago
kouroshez
DevOps & Infrastructure Listed

logging-and-observability

Instrument a service so production problems are diagnosable: structured JSON logs with consistent fields and levels, correlation ids across requests and jobs, the RED and USE metrics, distributed tracing with OpenTelemetry, health and readiness endpoints, alerts on symptoms with runbooks, and dashboards per service; with the setup for Node, Python, and Go and the cost and privacy rules that keep it sustainable. Use when a service goes to production, when an incident could not be traced, when logs are noisy or expensive, or when alerts fire without meaning.

5 Updated 3 days ago
KhaledSaeed18
Code & Development Listed

observability-slo

Observability and reliability engineering — structured logging, metrics, distributed tracing, correlation ids, error tracking, dashboards, SLIs/SLOs and error budgets, alerting that pages on symptoms rather than causes, on-call practice, incident response and blameless postmortems. Use when the user says "logging", "monitoring", "observability", "metrics", "tracing", "Prometheus", "Grafana", "Datadog", "Sentry", "OpenTelemetry", "SLO", "SLA", "uptime", "alerting", "on-call", "incident", "postmortem", "how do we know if it breaks", "it broke and we didn't notice" or "debugging production"; and as a pass in any project audit. By Devleck.

3 Updated 1 months ago
Kin9Zeus