Skill: logging-observability
What I do
I provide expertise in implementing structured logging, tracing, and metrics to ensure system observability. I focus on creating a clear, actionable data trail that allows for rapid debugging and performance analysis in production environments.
When to use me
- When designing a new service's logging strategy
- When instrumenting code with distributed tracing spans
- When adding metrics to track business-critical KPIs or system health
- When debugging complex, distributed issues that span multiple services
Core principles
- Structure over prose: Use structured formats like JSON to make logs easily searchable and machine-readable.
- Actionability: Every log message and metric should have a clear purpose. Avoid noise that obscures real issues.
- Context is king: Include correlation IDs, request IDs, and relevant metadata (e.g., user ID, tenant ID) in every log entry.
- The three pillars: Combine logs (discrete events), traces (request flow), and metrics (aggregates) for a complete view of system health.
Patterns & examples
Structured logging (JSON):
{
"level": "info",
"ts": "2026-02-22T21:00:00Z",
"msg": "processed order",
"order_id": "ORD-123",
"user_id": "USR-456",
"duration_ms": 150,
"correlation_id": "CORR-789"
}
Log levels guide:
- DEBUG: Verbose information for development and troubleshooting.
- INFO: General operational events (e.g., service started, request completed).
- WARN: Unexpected but non-critical events that might require attention.
- ERROR: Critical failures that require immediate investigation.
Distributed tracing:
Use OpenTelemetry to start spans at the beginning of a request and inject the context into downstream calls. This allows you to visualize the entire lifecycle of a request across multiple services.
Metrics types:
- Counters: For events that only increase (e.g., total requests, error count).
- Gauges: For values that go up and down (e.g., current memory usage, active connections).
- Histograms: For distributions of values (e.g., request latency, payload size).
Anti-patterns to avoid
- ❌ Log noise: Logging every trivial operation at the INFO level. This increases storage costs and makes finding real issues harder.
- ❌ Sensitive data in logs: Never log passwords, PII, or secrets. Always scrub or mask sensitive fields.
- ❌ Missing correlation IDs: Logs without a way to link them across services are nearly useless in distributed systems.
- ❌ Ignoring metrics: Relying solely on logs for health monitoring. Use metrics for real-time alerting and dashboards.
KB Reference
~/vaults/baphled/3. Resources/Knowledge Base/AI Development System/Skills/DevOps-Operations/Logging Observability.md
Related skills
devops: For infrastructure and deployment considerations
automation: For setting up alerting based on metrics and logs
security: For ensuring logging practices meet compliance and data privacy standards
performance: For using traces and metrics to identify and fix bottlenecks
1---2name: logging-observability-53description: Implement structured logging, tracing, and metrics for debugging4---5
6# Skill: logging-observability
7
8## What I do
9
10I provide expertise in implementing structured logging, tracing, and metrics to ensure system observability. I focus on creating a clear, actionable data trail that allows for rapid debugging and performance analysis in production environments.
11
12## When to use me
13
14- When designing a new service's logging strategy
15- When instrumenting code with distributed tracing spans
16- When adding metrics to track business-critical KPIs or system health
17- When debugging complex, distributed issues that span multiple services
18
19## Core principles
20
211. **Structure over prose**: Use structured formats like JSON to make logs easily searchable and machine-readable.
222. **Actionability**: Every log message and metric should have a clear purpose. Avoid noise that obscures real issues.
233. **Context is king**: Include correlation IDs, request IDs, and relevant metadata (e.g., user ID, tenant ID) in every log entry.
244. **The three pillars**: Combine logs (discrete events), traces (request flow), and metrics (aggregates) for a complete view of system health.
25
26## Patterns & examples
27
28**Structured logging (JSON):**
29```json
30{
31 "level": "info",
32 "ts": "2026-02-22T21:00:00Z",
33 "msg": "processed order",
34 "order_id": "ORD-123",
35 "user_id": "USR-456",
36 "duration_ms": 150,
37 "correlation_id": "CORR-789"
38}
39```
40
41**Log levels guide:**
42- **DEBUG**: Verbose information for development and troubleshooting.
43- **INFO**: General operational events (e.g., service started, request completed).
44- **WARN**: Unexpected but non-critical events that might require attention.
45- **ERROR**: Critical failures that require immediate investigation.
46
47**Distributed tracing:**
48Use OpenTelemetry to start spans at the beginning of a request and inject the context into downstream calls. This allows you to visualize the entire lifecycle of a request across multiple services.
49
50**Metrics types:**
51- **Counters**: For events that only increase (e.g., total requests, error count).
52- **Gauges**: For values that go up and down (e.g., current memory usage, active connections).
53- **Histograms**: For distributions of values (e.g., request latency, payload size).
54
55## Anti-patterns to avoid
56
57- ❌ **Log noise**: Logging every trivial operation at the INFO level. This increases storage costs and makes finding real issues harder.
58- ❌ **Sensitive data in logs**: Never log passwords, PII, or secrets. Always scrub or mask sensitive fields.
59- ❌ **Missing correlation IDs**: Logs without a way to link them across services are nearly useless in distributed systems.
60- ❌ **Ignoring metrics**: Relying solely on logs for health monitoring. Use metrics for real-time alerting and dashboards.
61
62## KB Reference
63
64`~/vaults/baphled/3. Resources/Knowledge Base/AI Development System/Skills/DevOps-Operations/Logging Observability.md`
65
66## Related skills
67
68- `devops`: For infrastructure and deployment considerations
69- `automation`: For setting up alerting based on metrics and logs
70- `security`: For ensuring logging practices meet compliance and data privacy standards
71- `performance`: For using traces and metrics to identify and fix bottlenecks