ln-627-observability-auditor
Observability audit worker (L3). Checks structured logging, health check endpoints, metrics collection, request tracing, log levels. Returns findings with severity, location, effort, recommendations.
When & Why to Use This Skill
The Observability Auditor is a specialized AI worker designed to automate the evaluation of system visibility and reliability. It systematically audits codebases for structured logging, health check endpoints, metrics collection, and request tracing, providing actionable insights, severity-rated findings, and compliance scores to enhance SRE practices and production readiness.
Use Cases
- Automated Production Readiness Reviews: Integrate into CI/CD pipelines to ensure every service meets observability standards before being deployed to production.
- Technical Debt Assessment: Scan legacy microservices to identify gaps in logging, missing health checks, or inadequate monitoring instrumentation.
- Distributed Systems Optimization: Verify the implementation of request tracing and correlation IDs to improve debugging efficiency and system transparency in complex architectures.
- SRE Compliance Auditing: Generate detailed reports with severity levels and remediation effort estimates to help engineering teams prioritize observability improvements.
| name | ln-627-observability-auditor |
|---|---|
| description | Observability audit worker (L3). Checks structured logging, health check endpoints, metrics collection, request tracing, log levels. Returns findings with severity, location, effort, recommendations. |
| allowed-tools | Read, Grep, Glob, Bash |
Observability Auditor (L3 Worker)
Specialized worker auditing logging, monitoring, and observability.
Purpose & Scope
- Worker in ln-620 coordinator pipeline
- Audit observability (Category 10: Medium Priority)
- Check logging, health checks, metrics, tracing
- Calculate compliance score (X/10)
Inputs (from Coordinator)
Receives contextStore with tech stack, framework, codebase root.
Workflow
- Parse context
- Check observability patterns
- Collect findings
- Calculate score
- Return JSON
Audit Rules
1. Structured Logging
Detection:
- Grep for
console.log(unstructured) - Check for proper logger: winston, pino, logrus, zap
Severity:
- MEDIUM: Production code using console.log
- LOW: Dev code using console.log
Recommendation: Use structured logger (winston, pino)
Effort: M (add logger, replace calls)
2. Health Check Endpoints
Detection:
- Grep for
/health,/ready,/liveroutes - Check API route definitions
Severity:
- HIGH: No health check endpoint (monitoring blind spot)
Recommendation: Add /health endpoint
Effort: S (add simple route)
3. Metrics Collection
Detection:
- Check for Prometheus client, StatsD, CloudWatch
- Grep for metric recording:
histogram,counter
Severity:
- MEDIUM: No metrics instrumentation
Recommendation: Add Prometheus metrics
Effort: M (instrument code)
4. Request Tracing
Detection:
- Check for correlation IDs in logs
- Verify trace propagation (OpenTelemetry, Zipkin)
Severity:
- MEDIUM: No correlation IDs (hard to debug distributed systems)
Recommendation: Add request ID middleware
Effort: M (add middleware, propagate IDs)
5. Log Levels
Detection:
- Check if logger supports levels (info, warn, error, debug)
- Verify proper level usage
Severity:
- LOW: Only error logging (insufficient visibility)
Recommendation: Add info/debug logs
Effort: S (add log statements)
Scoring Algorithm
penalty = (high * 1.0) + (medium * 0.5) + (low * 0.2)
score = max(0, 10 - penalty)
Output Format
{
"category": "Observability",
"score": 6,
"total_issues": 5,
"high": 1,
"medium": 3,
"low": 1,
"findings": [
{
"severity": "HIGH",
"location": "src/api/server.ts",
"issue": "No /health endpoint for monitoring",
"principle": "Observability / Health Checks",
"recommendation": "Add GET /health route returning { status: 'ok', uptime, ... }",
"effort": "S"
}
]
}
Version: 3.0.0 Last Updated: 2025-12-23