Alert सिस्टम को मानकीकृत करना और IaC से ऑपरेट करना
(engineering.ab180.co)शुरुआत में
सेवा के बढ़ने के साथ ऑपरेशन के दौरान जांचे जाने वाले संकेत भी बढ़ते गए। इस लेख में हम Alert को code के रूप में manage करने और Slack व PagerDuty तक जाने वाले response flow को standardize करने की प्रक्रिया का परिचय देते हैं।
शुरुआती लक्ष्य सरल था। Alert को बनाना आसान करना, उसे बेहतर तरीके से भेजना, और यह स्पष्ट करना कि उसे कौन देखे। बाद में ऑपरेशन जारी रखते हुए grouped Alert, दोहराई जाने वाली definitions, response automation, और monitoring system की stability तक को साथ-साथ बेहतर किया गया।
प्रेरणा
सेवा की availability बढ़ाने और user impact कम करने के कई तरीके होते हैं।
उनमें से इस काम का फोकस Alert system को बेहतर बनाने पर था।
Alert, incident prevention और incident response के बीच जुड़ने वाले operational interface जैसा होता है। अगर जोखिम के संकेत जल्दी मिल जाएं, तो असली incident बनने से पहले कार्रवाई की जा सकती है, और incident होने के बाद भी जिम्मेदार व्यक्ति उसे जल्दी समझकर response शुरू कर सकता है।
उस समय सुधार की दिशा भी स्पष्ट थी। जोखिम के संकेत बेहतर पकड़ना, जिम्मेदार लोगों को जल्दी पता चलवाना, जांच और response तक सीधे जोड़ना, और दोहराए जाने वाले response flows को कम करना था।
शुरू से ही सब कुछ quantitatively measure करके शुरू नहीं किया गया था, लेकिन यह समस्या-बोध स्पष्ट था कि Alert कोई साधारण notification नहीं, बल्कि incident को रोकने और response से जोड़ने वाला operational system होना चाहिए।
Alert की भूमिका
स्थिर सेवा के लिए incidents को रोकना महत्वपूर्ण है, लेकिन चल रही सेवा में abnormal signs को जल्दी detect करना भी उतना ही महत्वपूर्ण है।
Alert इस बिंदु पर दो भूमिकाएं निभाता है। incident होने से पहले यह जोखिम के संकेत को जल्दी पहचानने और असली incident बनने से पहले पहले से कार्रवाई करने में मदद करता है, और incident होने के बाद जिम्मेदार व्यक्ति को समस्या बताकर situation समझने के लिए जरूरी context और Runbook, Dashboard, Log, Silence जैसे next actions से जोड़ता है।
यानी Alert सिर्फ "समस्या आ गई है" बताने वाला notification नहीं, बल्कि incident prevention और response को जोड़ने वाला operational interface है।
मौजूदा Alerts में क्या कमी थी
मौजूदा Alerts में मुख्य रूप से तीन कमियां थीं। वे बनाने में कठिन, मिलने के बाद तुरंत समझने में कठिन, और किसे response देना व manage करना है, यह स्पष्ट नहीं था।
Alert बनाना कठिन था
उस समय Alert बनाने और deliver करने में Grafana, Slack, PagerDuty, CloudWatch, EventBridge, Lambda जैसे कई systems जुड़े हुए थे, और data sources भी NewRelic, VictoriaMetrics, Steampipe, OpenSearch, Druid, MySQL आदि कई तरह के थे।
हर Alert का काम करने का तरीका भी अलग था। कोई Alert Grafana से सीधे Slack पर भेजा जाता था, किसी में CloudWatch Alarm के बाद Lambda जोड़ा गया था, कोई Steampipe से AWS resource status query करके decision लेता था, और PagerDuty integration की जरूरत होने पर अलग settings तक consider करनी पड़ती थीं।
समस्या यह थी कि organization-level conventions की कमी थी। कौन-सा Alert कहां manage होगा, सिर्फ Slack भेजना है या PagerDuty तक जोड़ना है, message में कौन-सी explanation और links डालने हैं, responsible team और delivery route कहां manage होंगे—इन सबकी व्यवस्था अधूरी थी।
नतीजतन Alerts जरूरत पड़ने पर बनते रहे, लेकिन समय के साथ creation और management के तरीके लगातार fragmented होते गए।
Alert देखना कठिन था
Alert बना देने का मतलब यह नहीं था कि असली Slack message हमेशा readable form में आता था। बनाने वाले व्यक्ति और system के हिसाब से format और information quality अलग-अलग थी; कुछ Alerts के title लंबे और complex थे, और Value या Labels जैसे internal values वैसे ही expose हो जाते थे।
Link होने पर भी यह स्पष्ट नहीं होता था कि पहले क्या देखना है, और Dashboard या Log buttons होने के बावजूद असल में integration नहीं हुआ होता था। साथ ही, Alert का context कम होने के कारण responsible person को service, cluster, resource, time range फिर से ढूंढने पड़ते थे।
Incident situation में कुछ मिनटों का फर्क भी बहुत बड़ा महसूस होता है। इसलिए Alert मिलते ही यह किस समस्या के बारे में है, कितना महत्वपूर्ण है, किस service और resource की समस्या है, सबसे पहले कहां check करना है, और अगला action क्या है—ये सब तुरंत समझ में आना चाहिए था।
Alert की response responsibility manage करना कठिन था
Alert बजने पर कौन check करेगा और response देगा, यह भी कई बार अस्पष्ट होता था। अगर responsible team या person स्पष्ट न हो, तो Alert देखने वाले व्यक्ति को पहले "क्या यह मुझे देखना चाहिए?", "किससे पूछूं?" जैसे सवालों का फैसला करना पड़ता है, और incident situation में यह छोटा-सा decision भी response delay का कारण बन सकता है।
साथ ही, Alert बजने के बाद की response responsibility ही नहीं, बल्कि Alert को खुद कौन own और manage करता है यह भी महत्वपूर्ण था। यह किस team की service से जुड़ा Alert है, कौन condition बदल सकता है, message या threshold की review कैसे होगी, पुराने Alerts कौन साफ करेगा—ये सब भी सामने दिखना चाहिए था।
संक्षेप में, जिन situations को सुधारना था वे ये थीं:
- Alert बनाने और manage करने का तरीका fragmented था
- Alert मिलने पर भी उसका मतलब एक नजर में समझना कठिन था
- Alert बजने पर कौन check और response करेगा, यह अस्पष्ट था
- Alert को खुद कौन-सी team own और manage करेगी, यह भी unclear था
क्या और कैसे सुधार किया गया
सुधार की दिशा तीन चीजों पर थी। Alert बनाने के तरीके को standardize करना, Slack message में जरूरी information को consistent structure में देना, और हर Alert में responsible person और delivery route दिखे ऐसा structure बनाना।
Alert creation और management को standardize करना
सबसे पहले Alert creation और management को एक जगह इकट्ठा किया गया। Alert rule evaluation और execution को Grafana पर unified किया, Grafana·Slack·PagerDuty के बीच integration को Terraform Module से abstract किया, और सभी Alert definitions को internal alerts repo के alerts/ directory के नीचे IaC के रूप में manage किया। Slack channel connection, PagerDuty integration, message format, common buttons बनाना—ये सब common module handle करे, इस तरह व्यवस्थित किया गया।
अब Alert author को पूरे Alert pipeline को समझने के बजाय, कौन-सी condition detect करनी है, Alert कितना महत्वपूर्ण है, कौन check करेगा, और response के लिए कौन-सी information चाहिए—इन पर ज्यादा focus कर पाना संभव हुआ।
Repo के अंदर writing method, directory structure, required fields, recommended conventions भी साथ manage किए गए, और Alert को code के रूप में manage करने से reviews और change history भी PR और commit level पर रह गई।
Alert directory structure
सभी Alerts को {main-category}/{sub-category}/{severity}/{alert-name}.yml structure follow करने के लिए व्यवस्थित किया गया।
उदाहरण के लिए:
infra/kubernetes/critical/pod-unhealthy.ymldata/airflow/warning/task-failed.ymlfinops/aws/warning/cost-increase.yml
इस structure से सिर्फ file location देखकर यह किस area का Alert है, इसे कितनी severity के साथ handle करना है समझा जा सकता था। साथ ही, किसी specific area के Alerts को एक साथ देखने, duplicate Alerts और पुराने Alerts check करने, या Slack channel, PagerDuty Service, CODEOWNERS जोड़ने के आधार के रूप में भी इसका उपयोग हो सका।
Alert definition का तरीका
हर Alert file में datasource, query, threshold, condition, message जैसी information साथ रखी जाती है।
कोई अलग DSL नया नहीं बनाया गया। यह Grafana Alert के JSON में serialized content को YAML में express करने जैसा था, और इसी वजह से Grafana में define किए जा सकने वाले अधिकांश Alerts को उसी structure में IaC में बदला जा सकता था।
हाल में LLM का भी इस्तेमाल किया जा रहा है। जब कोई व्यक्ति natural language में "किस condition में किस message के साथ Alert पाना चाहता हूं" बताता है, तो LLM मौजूदा examples और conventions देखकर YAML form में Alert definition का draft बनाता है। इससे Alert author complex serialization format की बजाय क्या detect करना है और वह क्यों जरूरी है पर ज्यादा focus कर पाता है।
Alert message को तुरंत समझकर response दे सकने लायक बनाना
Alert message को भी एक interface माना गया। incident situation में message को धीरे-धीरे interpret करने की ज्यादा गुंजाइश नहीं होती, इसलिए कोई भी Alert आए, same location पर same type की information check कर पाना जरूरी था।
इसलिए Slack message की संरचना को लगातार एक जैसे रूप में व्यवस्थित किया। title में Alert का नाम, status और severity रखी, और body में ऐसा विवरण जो इंसान तुरंत समझ सके, साथ ही owner, team, service, region, resource name और मुख्य labels डाले। buttons को भी common buttons और optional buttons में बांटा, ताकि default रूप से IaC, PagerDuty, Silence दिए जाएं और जरूरत पड़ने पर ही Runbook, Dashboard, Log दिखाए जाएं
common buttons को system से automatically generate होकर link होने दिया, और Alert status में होने वाले सभी बदलाव Slack thread में छोड़े। किसने Acknowledge किया, Slack से handle किया गया या PagerDuty से, कब Resolve हुआ, और response के दौरान कौन-से notes छोड़े गए—यह सब एक ही flow में देखा जा सके, यही उद्देश्य था
नतीजतन, कोई भी व्यक्ति कोई भी Alert बनाए, Slack में दिखने वाला format लगभग समान हो गया, और members ज्यादा जल्दी तय कर सके कि उन्हें कहां देखना है
Alert ownership structure को स्पष्ट करना
Alert को देखकर तुरंत समझ पाना जितना महत्वपूर्ण था, उतना ही महत्वपूर्ण यह दिखाना भी था कि उस Alert को किसे ownership लेकर check करना चाहिए
इसलिए resources के tags और labels की जानकारी को response flow में इस्तेमाल किया। हर Alert के लिए responsible team या person को सीधे specify करने के बजाय, service·team·resource·environment जैसे metadata का उपयोग किया, ताकि Slack message में उचित responsible team और person automatically mention हो जाएं
delivery path को भी उन्हीं rules के तहत व्यवस्थित किया। Alert के category और severity के आधार पर Slack channel, PagerDuty Service और Escalation Policy automatically connect हों, ऐसा किया; Warning level के Alerts को केवल Slack channel तक भेजा, और user impact या outage की संभावना ज्यादा वाले Critical Alerts के लिए PagerDuty Incident भी create होने दिया
CODEOWNERS का भी साथ में उपयोग किया। Alert files को category और service area के अनुसार directories में बांटा, और हर path के responsible team को CODEOWNERS में specify किया, ताकि repo के अंदर ही दिख सके कि कौन-सी team कौन-सा Alert area own करती है
नतीजतन Alert responsibility को दो points पर manage किया गया। जब Alert सच में बजता है, तो tags और labels के आधार पर responsible team और person mention होते हैं, और Alert definition बदलते समय directory structure और CODEOWNERS के आधार पर यह check होता है कि वह किस team का area है
Alert proxy की भूमिका
इस structure को सच में काम करने के लिए बीच में Alert को interpret और deliver करने वाली layer की जरूरत थी। इसलिए Grafana और Slack, PagerDuty के बीच AWS Lambda-based proxy रखा
Grafana Alert rule को evaluate करके webhook भेजता है। proxy इस webhook को लेकर category, severity, label, annotation, fingerprint जैसे Alert context को interpret करता है, और तय करता है कि इसे किस Slack channel में भेजना है, कौन-सा PagerDuty Incident बनाना है, किसे mention करना है, कौन-से buttons जोड़ने हैं, existing Slack thread को कैसे update करना है, और Ack/Resolve lifecycle को कैसे manage करना है
यानी अगर Terraform module और directory structure ने "Alert को कैसे define करना है" इसे standardize किया, तो proxy ने यह भूमिका निभाई कि वह definition actual operations flow में एक ही तरह से दिखाई दे और काम करे
proxy की वजह से Slack message format, responsible person mention, PagerDuty integration, Slack thread update और Ack/Resolve interaction को एक जगह consistent तरीके से manage किया जा सका, और बाद में grouped Alert, custom action button, AI agent integration, common Alert model जैसे improvements को भी आसानी से expand किया जा सका
और क्या कमी रह गई
पहले improvement के बाद Alert definitions IaC से manage होने लगीं, और Slack messages व delivery paths भी consistent rules के तहत चलने लगे। लेकिन Alert system कोई ऐसा tool नहीं था जिसे एक बार बनाकर खत्म मान लिया जाए। करीब 1 साल operate करने के बाद, Alerts बढ़ने पर नए issues दिखने लगे: एक ही Alert के भीतर बनी कई instances को कैसे दिखाया जाए, repeated Alert definitions को कैसे manage किया जाए, इंसान Alert देखने के बाद वास्तव में क्या कर सके, और Alert system की अपनी stability कैसे secure और verify की जाए
एक ही Alert कई targets पर एक साथ बजे तो देखना मुश्किल होता है
Alert बनाना आसान होने के साथ Alert की संख्या भी स्वाभाविक रूप से बढ़ी। इस दौरान खास तौर पर असुविधाजनक मामला यह था कि एक Alert rule कई targets के लिए एक साथ trigger हो जाए
Grafana में, भले ही rule वही हो, अगर region, name, node, pod, app जैसे label values अलग हों तो हर एक को अलग Alert instance माना जाता है। उदाहरण के लिए Pod unhealthy Alert में अगर कई pods एक साथ unhealthy state में आ जाएं, तो हर pod के लिए Alert instance बनता है
Grafana में Alert Grouping feature पहले से था, लेकिन उन्हें सिर्फ group में बांध देना पर्याप्त नहीं था। महत्वपूर्ण यह था कि grouped Alerts की स्थिति operators के लिए समझने में आसान तरीके से दिखे; group में कौन-से targets हैं, कौन अभी भी firing है, कौन अभी-अभी resolve हुआ है, क्या कोई नया target add हुआ है, और क्या उसी group की state changes एक ही flow में जुड़ रही हैं—ये बातें अहम थीं
दोहराई जाने वाली Alert definitions बढ़ने लगीं
Alert definitions बढ़ने के साथ YAML copy करके थोड़ा-थोड़ा बदलने वाला तरीका भी अपनी सीमा दिखाने लगा। SQS lag, CloudWatch error log, Pod OOM, ALB 5xx, Lambda error/throttle जैसे Alerts बार-बार बनाने पड़ते थे, और शुरुआत में existing file copy करके name, query, threshold, label बदल देना काफी था
लेकिन files बढ़ने पर common behavior बदलना मुश्किल होने लगा, और एक ही intent वाले Alerts में भी dashboard link, labels configuration और threshold expression थोड़े-थोड़े अलग होने लगे। इसलिए दोहराए जाने वाले patterns को reuse कर सकने वाला structure जरूरी था
Alert देखने के बाद भी next action तक दूरी रहती है
Slack message में Runbook, Dashboard, IaC, PagerDuty buttons जोड़ना मददगार था, लेकिन real incident response में कई बार केवल links काफी नहीं होते थे। खासकर Runbook का असर साफ था, लेकिन हर Alert के लिए अच्छी Runbook जोड़ना और उसे लगातार up to date रखना आसान नहीं था
इसके अलावा actual response में Kubernetes logs check करना, pod status check करना, rollout history देखना, SQS·Lambda metrics check करना, error log check करना जैसी investigation tasks हर बार दोहराई जाती हैं। ये tasks ज्यादातर Slack message के बाहर होते थे, और owner को Alert से label और value पढ़कर दूसरे tool में जाना पड़ता था, values transfer करनी पड़ती थीं, फिर result को वापस Slack thread में share करना पड़ता था
आखिरकार पहले improvement से Alert को बेहतर तरीके से पढ़ना तो संभव हुआ, लेकिन investigation और response अभी भी Alert message के बाहर काफी हद तक रह गए
monitoring system में SPOF बढ़ गए
Alert system को व्यवस्थित करते हुए ऐसे points भी बढ़े जो SPOF बन सकते थे। Alert rule की definition और deployment alerts repo और Terraform में आ गए, Alert rule evaluation Grafana के जिम्मे था, और Slack message·PagerDuty Incident·Ack/Resolve lifecycle proxy manage करने लगा
roles स्पष्ट होना अच्छा बदलाव था, लेकिन उन points के fail होने पर पूरे Alert flow के प्रभावित होने की संभावना भी बढ़ गई। और मुश्किल बात यह थी कि ऐसी failure बाहर से साफ दिखाई न दे सकती थी। अगर दूसरे systems की समस्या बताने वाला path चुपचाप रुक जाए, तो actual outage होने पर भी किसी को पता नहीं चल सकता
आखिर यह सवाल बन गया: "monitoring system को कौन monitor करेगा"
दूसरा improvement
पहले improvement से Alert system का basic skeleton बन गया था, लेकिन Alert बनाना और भेजना आसान होने के बाद operations में देखने लायक problems भी बदल गईं
दूसरे improvement में चार चीजों पर focus किया। एक ही Alert rule से कई targets एक साथ trigger हों तो state changes को एक साथ group करके एक नजर में दिखाना, दोहराई जाने वाली Alert definitions को common patterns के रूप में reuse करने लायक बनाना, Runbook को complement करते हुए repeated investigation और limited mitigation tasks को Slack buttons से जोड़ना, और SPOF बन सकने वाले Alert definition·evaluation·delivery path की stability को measure और verify करना
Grouped Alert को सही तरीके से handle करना
सबसे पहले grouped Alert के expression तरीके को बेहतर किया। जब एक ही Alert rule से कई instance एक साथ fire होते हैं, तो हर एक को अलग message के रूप में भेजने पर Slack channel cluttered हो जाता है; और उल्टा, अगर सबको सिर्फ एक group में मिला दिया जाए, तो असल में कौन-सा resource problem में है, यह छूट जाना आसान हो जाता है।
मुख्य बात थी group करना, लेकिन group के अंदर की state न खोना। Slack में grouped Alert को एक representative message के रूप में दिखाया गया, साथ ही अभी प्रभावित targets भी साथ में दिखाए गए। कोई नया target जुड़ने या मौजूदा target resolve होने पर वह बदलाव उसी thread में छोड़ा गया। जब एक बार में बहुत सारे state changes होते थे, तो कई changes को batch में group करके दिखाया गया, और PagerDuty side को भी Slack में दिखने वाले grouped Alert वाली ही problem की ओर point करने के लिए align किया गया।
नतीजा यह हुआ कि एक ही cause से निकले कई Alert को Slack में एक flow के रूप में देखा जा सका।
दोहराई जाने वाली Alert definitions घटाना
Copy करके थोड़ा-थोड़ा बदलने वाला तरीका Alert की संख्या बढ़ने के साथ maintenance cost और गलती की संभावना बढ़ाता है। इसे घटाने के लिए global/templates और matrix जोड़े गए।
global/templates दोहराई जाने वाली Alert structure को common template के रूप में define करने की capability है, और matrix वही Alert कई region, queue, datasource, service combinations में expand करके कई Alert बनाने की capability है।
SQS queue lag, CloudWatch error log, कई clusters में Pod OOM, ALB 5xx, Lambda error/throttle, ECS memory/CPU/max-capacity जैसे repetitive patterns को template बनाया गया, और queue name, region, cluster, threshold, dashboard variables जैसे बदलने वाले values ही matrix में input करने लायक रखे गए।
इससे common message structure, buttons, Runbook/dashboard link handling, datasource handling के तरीके को एक ही जगह पर ठीक किया जा सका, और Alert बढ़ने पर पैदा होने वाली inconsistencies और maintenance cost भी घटाई जा सकी।
Slack message से सीधे response शुरू करना
इसके बाद Slack message के अंदर किए जा सकने वाले काम बढ़ाए गए। Runbook और dashboard links अब भी अहम हैं, लेकिन हर बार एक जैसे दोहराए जाने वाले lookups या सीमित mitigation tasks को Slack message के अंदर ही कम करना चाहते थे।
इसलिए existing buttons के अलावा custom action button जोड़ा गया। Alert YAML के message.actions में command define करने पर वह Slack message में button के रूप में दिखाई देता है, और button दबाने पर proxy अलग Lambda invocation से command execute करता है, फिर किसने कौन-सा button दबाया और execution result क्या रहा, यह उसी Slack thread में comment के रूप में छोड़ता है।
इन buttons से log lookup, Kubernetes rollout status check, सीमित situations में rollout restart, single command execution, और कई commands को sequentially execute करने जैसे tasks provide किए जा सके।
सबसे ज्यादा ध्यान safety पर दिया गया। अगर button name ! पर खत्म होता है तो Slack confirm dialog दिखाया गया; ${labels.namespace}, ${labels.pod} जैसी label values को command में substitute किया गया, लेकिन shell quoting apply करके command injection रोका गया; और जिन tasks को extra permissions चाहिए, उन्हें actionRole के जरिए IAM role assume करने दिया गया। Unallowed role usage को fail-closed से handle किया गया, और webhook तथा Slack interactions को क्रमशः Bearer token, HMAC-SHA256 signature और replay protection से verify किया गया।
AI agent के साथ integrate करना
Alert मिलने के बाद जरूरी information collect करने की process भी कम करना चाहते थे। इसलिए internal AI agent abot को Alert flow से जोड़ा गया।
Slack message में abot button दबाने पर proxy Alert name, description, labels, values, IaC link, और user ने modal में अतिरिक्त रूप से input किया हुआ context इकट्ठा करके analysis request भेजता है। abot button दबाने वाले व्यक्ति की OAuth-based identity से operate करता है, ताकि Grafana·AWS·Kubernetes जैसी जरूरी information lookup करते हुए भी केवल उसी scope में data लाए जिसे user वास्तव में देख सकता है।
Analysis result उसी Slack thread में comment के रूप में छोड़ा जाता है। कौन-से metrics और logs check किए गए, किन possibilities पर पहले शक किया जा सकता है, और RCA में summarize करने लायक clues क्या हैं—यह सब साथ में छोड़ा गया, जिससे कई systems खोलकर information दोबारा collect करने में लगने वाला time घट सका।
Monitoring system को monitor करना
दूसरे improvement में Alert को define, evaluate और deliver करने की process खुद भी observability target में शामिल की गई।
सबसे पहले proxy के operational metrics collect किए गए। Ack तक लगने वाला time, Resolve तक लगने वाला time, अभी active Alert count, Alert कितनी देर से active है, और वही Alert कितनी बार फिर से बजा जैसे metrics collect किए गए; और Lambda timeout के करीब आने पर detect करने वाला watchdog भी जोड़ा गया। अगर proxy processing के दौरान fail होता है, तो full stack trace और original event payload साथ में छोड़ने लायक बनाया गया।
लेकिन proxy के खुद alert भेजने के तरीके की limits थीं। क्योंकि अगर proxy वह alert भेजने से पहले ही मर जाए, तो जो Alert भेजा जाना चाहिए था वह वैसे ही miss हो सकता है।
इसलिए proxy के बाहर, अलग-अलग systems पर निर्भर detection devices रखे गए। एक Grafana था, ताकि proxy द्वारा भेजे गए metrics को monitoring domain के Alert के रूप में evaluate करके anomalies सामने लाई जा सकें। हालांकि Grafana और VictoriaMetrics उसी EKS पर हैं, इसलिए अगर EKS या Grafana पूरा ही down हो जाए, तो detect नहीं किया जा सकता।
दूसरा deadman switch था। Grafana normal होने पर /api/health को heartbeat के रूप में भेजता है, और heartbeat को EKS से independent CloudWatch receive करता है। CloudWatch alarm heartbeat गिरने या missing होने पर इसे failure मानता है, और ऐसे में Grafana या proxy से गुजरे बिना PagerDuty और Slack को सीधे notify करता है।
यानी detect करने वाली side और detect होने वाली side को अलग infrastructure पर रखा गया, और इससे जब तक EKS और CloudWatch एक साथ down न हों, monitoring system का down होना पता चल सकता है।
आगे के improvement tasks
दूसरा improvement पूरा हो गया, लेकिन अभी भी और improve करने वाली चीजें बाकी हैं।
Collect किए गए operational metrics का सही इस्तेमाल करना
proxy के Alert operational metrics collect करने से अब data के आधार पर इन सवालों का जवाब दिया जा सकता है: किस channel में कौन-सा Alert कितनी बार बजता है, क्या किसी specific owner या team पर Alert जरूरत से ज्यादा concentrate हो रहे हैं, और क्या कोई ऐसा Alert है जो बिना किसी interaction के सिर्फ firing और auto resolve दोहराता रहता है।
लेकिन data देख पाना और उसके आधार पर actual Alert को refine करना अलग चीजें हैं। अभी तक threshold adjustment, मिलते-जुलते Alert group करना, अनावश्यक Alert हटाना, noisy alert कम करना, और awareness time व resolution time को वास्तव में घटाने की दिशा में improvements को गंभीरता से शुरू नहीं किया जा सका है।
Alert IaC improvement
फिलहाल Alert definitions alerts repo से CI/CD के जरिए deploy होती हैं, लेकिन अभी भी Grafana Terraform provider के grafana_rule_group resource पर निर्भर हैं। Problem यह है कि सिर्फ एक rule बदलने पर भी PR में ऐसा दिखता है जैसे पूरा rule group बदल गया हो, जिससे diff पढ़ना मुश्किल होता है; और interval_seconds rule group level पर है, इसलिए हर Alert को अलग evaluation interval देने के लिए groups को छोटे-छोटे हिस्सों में तोड़ना पड़ता है।
हाल ही में Grafana में Alert rule को Kubernetes resource की तरह handle करने वाली नई alerting API आई है, और Terraform provider में भी grafana_apps_rules_alertrule_v0alpha1 resource जोड़ा गया है। अभी alpha होने के कारण तुरंत adopt करना hold पर है, लेकिन stable होने पर existing grafana_rule_group की जगह migrate करने पर विचार किया जाएगा।
Expectations साफ हैं। rule group और rule को अलग-अलग define करना, सिर्फ एक rule बदलने पर केवल वही change साफ दिखाने वाला diff पाना, हर rule के लिए evaluation interval को granular तरीके से adjust करना, और monitoring resources को ज्यादा efficiently use करना।
समापन
शुरुआती goal simple था। Alert बनाना आसान करना, मिलने पर उसे एक नज़र में समझने लायक बनाना, और कौन responsible है यह स्पष्ट करना।
पहले phase के improvement में Alert definitions को IaC में centralize किया गया, Slack messages और delivery paths standardize किए गए, owner mention और CODEOWNERS को connect किया गया, और proxy के जरिए Slack/PagerDuty lifecycle management को व्यवस्थित किया गया।
ऑपरेशन जारी रखते हुए जो समस्याएँ सामने आईं, उन्हें दूसरे सुधार चरण में ठीक किया गया। एक ही rule से आने वाले Alerts को एक साथ दिखाया गया, दोहराई जाने वाली definitions को template और matrix से घटाया गया, Slack messages के भीतर ही investigation और mitigation शुरू करना संभव बनाया गया, और monitoring system खुद रुक जाए तो उसका पता चल सके—ऐसी व्यवस्था भी तैयार की गई।
इससे Alert बनाना, भेजना और उस पर response देना पहले से आसान हो गया।
हालाँकि data को देख पाना और उस data के आधार पर वास्तविक operations में सुधार करना, ये दो अलग बातें हैं। अब तक का काम Alert system को standardize करके measurable बनाना था; अब आगे उन metrics को देखते हुए वास्तव में कम करना और refine करना बाकी है।
इस लेख में लंबाई की वजह से कुछ बातें शामिल नहीं हो पाई हैं। अगर आप और विस्तार से जानना चाहते हैं, तो मूल लेख भी साथ में पढ़ने की सलाह है।
अभी कोई टिप्पणी नहीं है.