Logging - ELK Stack, Structured Logging
בסוף 2019, אחד מה-backend services של Monzo - הבנק הdigital הבריטי - התחיל לייצר timeout errors. ה-on-call engineer פתח את ה-logs וגילה שהם מלאים בshit כזה:
2019-11-14 03:47:22 ERROR: error occurred2019-11-14 03:47:22 ERROR: request failed2019-11-14 03:47:22 ERROR: connection errorשלושה שעות חקירה אחר כך, הם הבינו מה קרה. בpostmortem שלהם הם כתבו: "הזמן שבזבזנו על debug היה יכול להיות 20 דקות אם ה-logs היו מכילים request ID, user ID, ו-relevant context."
Logging זה לא על כמות - זה על איכות.
ב-2021, חברת SaaS ישראלית בתחום HR עברה incident שבו payment service החל לייצר errors בשעות הלילה. ה-on-call engineer, שנקרץ בשעה 2:34, פתח את Kibana וחיפש level:error AND service:payment. קיבל 47,000 שורות. כל שורה הייתה בformat שונה - חלק Python tracebacks, חלק unstructured strings, חלק JSON חלקי. שלושה engineers ישבו עד השעה 5 בבוקר. MTTR: 2.5 שעות. Revenue impact: ~$18,000.
בpostmortem מצאו שה-root cause היה DB connection string שהוחלף בdeploy - הנחה שנראתה פשוטה. הזמן שאבד לא היה בפתרון - אלא ב-finding. אם כל log היה מכיל connection_string_host כfield, החיפוש היה לקח 30 שניות.
ה-postmortem action item #1: "standardize structured logging across all Python services using structlog." ה-action item #2: "add correlation_id to all logs within 2 weeks." שבועיים לאחר מכן, incident דומה נפתר ב-14 דקות - כולל גילוי שהconnection string שוב הוחלף בdeploy.