Service और उसके उपयोगकर्ताओं का व्यवहार देखें

प्रश्न से शुरू करें

Monitoring ज्ञात स्थितियाँ जाँचती है। Observability system का व्यवहार जाँचने में मदद करती है, जिसमें वे failures भी हैं जिनका अनुमान नहीं था। अधिक dashboards से उत्तर अपने आप बेहतर नहीं होते।

काल्पनिक export service में उपयोगकर्ता के प्रश्न से शुरू करें: क्या अधिकृत उपयोगकर्ता सहमत समय में सही export पा सकता है? फिर उस प्रश्न और failures की व्याख्या में मदद करने वाले signals चुनें।

OpenTelemetry telemetry के लिए instrumentation और standards देता है। वह signals को compatible backends में भेज सकता है। Storage, queries, access controls, retention और प्रमाण पर कार्रवाई करने वाले लोग फिर भी चाहिए। Observability primer।

अलग तरह के प्रमाण जोड़ें

Metric समय के साथ कोई मात्रा मापता है। Log घटना दर्ज करता है। Trace, system में request आगे बढ़ने पर संबंधित operations जोड़ता है। Span trace के भीतर एक operation को दिखाता है।

Asynchronous काम में submitted job और worker execution का सुरक्षित संबंध बनाए रखें। HTTP 202 response का अर्थ काम स्वीकार होना हो सकता है। इससे export पूरा होना सिद्ध नहीं होता।

कार्रवाई जरूरी हो तो alert दें

SLO तय करने से पहले SLI और उसका मापन आधार तय करें। उदाहरण में सहमत अवधि के भीतर सही पूरे हुए योग्य exports गिनें। तय करें कि लंबे चलने वाले और छोड़े गए jobs मापन में कैसे शामिल होंगे।

Error budget, SLO की अवधि में स्वीकार्य failure बताता है। Burn rate बताता है कि failures यह budget कितनी तेजी से खर्च कर रही हैं। Google की guidance समय पर detection और alert noise में संतुलन के लिए कई समय-अवधियाँ इस्तेमाल करती है। Alerting on SLOs।

समय पर कार्रवाई जरूरी हो तो संबंधित व्यक्ति को तत्काल alert दें। कम urgent काम queue में भेजें। हर alert का जिम्मेदार व्यक्ति, असर का विवरण, जाँच का link और response instruction होना चाहिए। बार-बार बिना कार्रवाई खत्म होने वाले alerts का review करें।

हर service के लिए एक सामान्य threshold न रखें। उपयोगकर्ताओं पर असर, traffic, business hours और response capacity निर्णय को प्रभावित करते हैं।

Telemetry pipeline सुरक्षित रखें

Telemetry में personal data, tokens, request parameters और गोपनीय documents हो सकते हैं। Collection से पहले स्वीकार्य fields तय करें। Access और retention सीमित करें। External backend में export करने से पहले secrets हटाएँ। संवेदनशील telemetry।

Customer email या unique job ID को metric label न बनाएँ। असीमित labels से time series की संख्या बढ़ती है और identifiers उजागर हो सकते हैं। Metrics के लिए नियंत्रित dimensions इस्तेमाल करें। स्वीकृत correlation identifiers को access-controlled logs या traces में रखें।

Pipeline को भी मापें। Ingestion failures, dropped data और नवीनतम observation की उम्र जाँचें। Error chart सपाट हो तो अर्थ कोई error नहीं या कोई telemetry नहीं, दोनों हो सकते हैं। यह अंतर दिखाएँ।

ठोस विफलता की जाँच करें

काल्पनिक service हर request के लिए HTTP 202 देती है। उसकी queue age seconds से बढ़कर 15 मिनट होती है। Worker logs में बार-बार database timeouts हैं। Sampled traces में worker का अधिकांश समय database calls में है।

यह प्रमाण केंद्रित जाँच में मदद करता है। इससे यह सिद्ध नहीं होता कि कारण query change, connections खत्म होना या database capacity है। Debugging के तरीके से इन धारणाओं की तुलना करें।

Taiga Monitoring availability और browser experience signals के साथ product-health view देता है। यह infrastructure और application observability का पूरक है; उनकी जगह नहीं लेता। Monitoring।