structured-logginglisted

# Structured Logging ## Core Principle Emit **one wide event per request per service**, not scattered log statements. - Build context throughout the request lifecycle - Emit once at the end (in a finally block) - Optimize for **querying**, not writing - Include high-cardinality fields (user_id, request_id) that enable debugging - Include high-dimensionality (50+ fields) capturing full context ## Anti-patterns Avoid these common mistakes: ``` // String concatenation - loses structure log("User " + userId + " payment failed: " + error) // Scattered statements - 17 lines for one request log("Starting request") log("Validating token") log("Token valid") log("Fetching user") log("User found") log("Processing payment") log("Payment failed") // Low cardinality only - can't debug specific users log({level: "error", message: "Payment failed"}) // Missing business context - no debugging power log({user_id: "123", error: "failed"}) ``` ## Wide Event Structure One comprehensive event per request: ```json { "timestamp": "2025-01-15T10:23:45.612Z", "level": "error", "request_id": "req_8bf7ec2d", "trace_id": "abc123", "span_id": "span_456", "service": "checkout-service", "version": "2.4.1", "deployment_id": "deploy_789", "region": "us-east-1", "method": "POST", "path": "/api/checkout", "status_code": 500, "duration_ms": 1247, "user": { "id": "user_456", "subscription": "premium", "account_age_days": 847, "lifetime_value_cents": 284