logging-observability-standardslisted

# Logging & Observability Standards ## Purpose Logs are the black box recorder of your system. When failures happen at 2 AM in production, logs are your only witness. This skill ensures application state and failures are highly searchable, machine-readable, and traceable across system boundaries WITHOUT leaking sensitive user data. ## When to use - Bootstrapping a new backend microservice or monolithic API - Refactoring code filled with disorganized `console.log` or `print` statements - Designing a system that spans multiple services/functions - Setting up monitoring, alerting, and debugging infrastructure ## When NOT to use - Application performance monitoring (APM) - related but different concern - Security incident response (use SIEM/security tools) - User analytics (different use case, different tool) ## Inputs required - Backend service with multiple endpoints/functions - Logging infrastructure (ELK, DataDog, Grafana Loki, CloudWatch, etc.) - Understanding of structured logging concepts ## Workflow 1. **Implement Structured Logging**: Configure logger to output NDJSON (Newline Delimited JSON) instead of plain text 2. **Inject Context**: Attach a `correlation_id` (or `trace_id`) at HTTP entry point and pass through all downstream calls 3. **Standardize Levels**: ERROR (system broken), WARN (unexpected but recovered), INFO (lifecycle), DEBUG (verbose tracing) 4. **Sanitize Data**: Implement redaction middleware to mask credentials, tokens, and PII before logs hit the