अलर्ट्स

अलर्ट्स शेड्यूल के अनुसार एक नियम का मूल्यांकन करते हैं और आपको सूचित करते हैं जब कुछ थ्रेसहोल्ड पार करता है। वे AgentEye को एक निष्क्रिय डैशबोर्ड से एक पेजिंग सर्फेस में बदल देते हैं जो महत्वपूर्ण चीजों के लिए है: त्रुटि दर स्पाइक्स, विलंबता प्रतिगमन, मूल्यांकनकर्ता स्कोर ड्रॉप, या कोई भी कस्टम इवेंट जो आप ClickHouse क्वेरी के रूप में व्यक्त कर सकते हैं। यह गाइड कवर करती है कि एक अलर्ट क्या है, पांच ट्रिगर प्रकार, चार सूचना चैनल, घटना जीवनचक्र, और परिचालन नियंत्रण।

अवधारणाएं

अलर्ट — नियम। यह कहता है क्या जांचना है (ट्रिगर), कितनी बार (मूल्यांकन अंतराल), कब इसे टूटा हुआ मानें (मिश्रित तर्क), कितना तत्काल (गंभीरता), और किसे/कहां सूचित करें (चैनल)।
घटना — जब एक अलर्ट निकलता है तो क्या होता है। एक अलर्ट के पास एक बार में अधिकतम एक खुली घटना होती है। दोहराए गए उल्लंघन एक ही घटना के प्रमाण को अपडेट करते हैं। घटनाओं को एक ऑपरेटर द्वारा हल किया जाता है; जब नियम निकलना बंद हो जाए तो स्वचालित समाधान की योजना है लेकिन वर्तमान में सक्षम नहीं है।
चैनल — एक सूचना कहाँ जाती है: ईमेल, Slack, सामान्य वेबहुक, या इन-डैशबोर्ड। प्रत्येक अलर्ट किसी भी संयोजन को संलग्न कर सकता है।

अलर्ट्स और घटनाएं एक संगठन के अंतर्गत आती हैं और उस संगठन के ऑपरेटरों में साझा की जाती हैं (एक एकल-किरायेदार तैनाती में यह सरलता से निर्मित default संगठन है)। घटनाओं को एक व्यक्तिगत ऑपरेटर के लिए छंटाई के लिए असाइन किया जा सकता है।

ट्रिगर प्रकार

पाँच प्रकार, प्रत्येक का अपना JSON विनिर्देश। उसे चुनें जो यह बताता है कि “टूटा हुआ” कैसा दिखता है। डैशबोर्ड का नया अलर्ट फॉर्म आपके लिए एक ही विनिर्देश बनाता है, ट्रिगर प्रकार से मेल खाने के लिए स्थिति संपादक को स्विच करता है:

नए-अलर्ट फॉर्म, बेसिक्स (नाम, विवरण, सक्षम) और ट्रिगर पिकर के साथ मीट्रिक थ्रेसहोल्ड, कस्टम SQL, मूल्यांकन स्कोर, मूल्यांकन विफलताएं, और प्रति-इवेंट विकल्प दिखाता है

1. `metric_threshold`

सबसे सरल। एक बंद सूची से मीट्रिक, एक ऑपरेटर, थ्रेसहोल्ड, और एक समय विंडो चुनें।

मीट्रिक	यह क्या गिनता है
`event_count`	विंडो में कुल इवेंट्स
`error_count`	`event_type = 'error'` या `error_type IS NOT NULL` वाली कोई भी इवेंट
`error_rate`	`error_count / event_count` (0..1)
`p95_latency_ms`	`quantile(0.95)(duration_ms)` `duration_ms` वाली सभी इवेंट्स के पार
`p99_latency_ms`	`quantile(0.99)(duration_ms)`
`token_sum`	`SUM(input_tokens + output_tokens)`

ऑपरेटर: >, >=, <, <=, == (भी स्वीकार किए गए gt, gte, lt, lte, eq के रूप में)। वैकल्पिक फिल्टर: environment, event_type। उदाहरण विनिर्देश:

{
  "metric": "p95_latency_ms",
  "filter": { "environment": "production" },
  "window_secs": 900,
  "op": ">",
  "value": 5000
}

2. `custom_sql`

जो कुछ भी पूर्वनिर्धारित मीट्रिक्स को कवर नहीं करते। ऑपरेटर-आपूर्ति SQL उसी /queries/run गार्ड के माध्यम से जाता है (केवल SELECT/WITH, एकल स्टेटमेंट, 10,000-पंक्ति कैप) डिस्पैचर इसे चलाता है। दो मोड:

पंक्तियों मोड (कोई op/value नहीं): अलर्ट तुरंत निकलता है जैसे ही क्वेरी कम से कम एक पंक्ति देता है।
मान मोड: क्वेरी को एक कॉलम को metric_value के रूप में उपनाम देना चाहिए; डिस्पैचर पहली पंक्ति के metric_value की तुलना value के साथ op का उपयोग करके करता है।

{
  "sql": "SELECT count() AS metric_value FROM agenteye.events WHERE event_type = 'error' AND ts >= now() - INTERVAL 1 HOUR",
  "op": ">",
  "value": 100
}

3. `evaluation_score`

agenteye.evaluations पढ़ता है और एक विंडो के पार एक नामित स्कोर के औसत की तुलना करता है।

{
  "score_key": "hallucination",
  "op": ">",
  "value": 0.6,
  "window_secs": 3600,
  "min_count": 5,
  "environment": "production"
}

min_count एकल-नमूना आउटलायर्स से रक्षा करता है; डिस्पैचर विंडो में कम से कम N मूल्यांकन तक मौजूद होने तक निकलेगा नहीं।

4. `eval_compound`

एक गुणवत्ता प्रतिगमन को पकड़ें जो केवल कई मूल्यांकनकर्ता स्कोर्स में एक साथ दिखाई देता है। जहाँ evaluation_score एक एकल नामित स्कोर को देखता है, eval_compound कई मूल्यांकन-स्कोर शर्तों को एक अलर्ट में रचता है और उन्हें एक चुने हुए तर्क के साथ जोड़ता है; तो एक नियम व्यक्त कर सकता है “निकल जाएं यदि सहायकता या मतिभ्रम चढ़ता है”, “निकल जाएं यदि सहायकता और उपकरण-दक्षता दोनों ड्रॉप हों”, या “निकल जाएं यदि कम से कम 2 से ये तीन जांच उल्लंघन करें”। प्रत्येक शर्त साझा विंडो में agenteye.evaluations से एक नामित स्कोर के औसत को पढ़ता है और इसे अपने स्वयं के ऑपरेटर और थ्रेसहोल्ड के साथ परीक्षण करता है। बूलियन परिणाम फिर combinator द्वारा जोड़े जाते हैं:

कॉम्बिनेटर	तर्क	कब निकलता है
`"any"`	OR	कम से कम एक शर्त उल्लंघन करती है
`"all"`	AND	हर शर्त उल्लंघन करती है
`{ "at_least": N }`	M-of-N	कम से कम N शर्तें उल्लंघन करती हैं

{
  "combinator": { "at_least": 2 },
  "conditions": [
    { "score_key": "hallucination", "op": ">", "value": 0.8 },
    { "score_key": "helpfulness",   "op": "<", "value": 0.6 },
    { "score_key": "tone",          "op": "<", "value": 0.5 }
  ],
  "window_secs": 3600,
  "min_count": 5,
  "environment": "production"
}

combinator: "any", "all", या { "at_least": N }।
conditions[]: प्रत्येक { score_key, op, value }, अन्य ट्रिगर्स के समान ऑपरेटर्स का उपयोग करते हुए (>, >=, <, <=, ==)।
window_secs: हर शर्त पर लागू साझा लुकबैक (डिफ़ॉल्ट 3600)।
min_count: प्रति-शर्त न्यूनतम संख्या मूल्यांकन जिसके बाद वह शर्त उल्लंघन कर सकती है; बहुत कम नमूनों वाली एक शर्त विंडो में “उल्लंघन नहीं” के रूप में गिनती है (डिफ़ॉल्ट 1)।
environment: वैकल्पिक; हर शर्त को एक पर्यावरण तक सीमित करता है।

सूचना का प्रमाण प्रत्येक शर्त के अवलोकित औसत, इसे परीक्षित किया गया थ्रेसहोल्ड, कितने मूल्यांकन देखे गए, और क्या यह उल्लंघन हुआ रिकॉर्ड करता है; तो आप देख सकते हैं कि कौन सी जांचें ट्रिप हुईं।

5. `per_event`

“X से मेल खाने वाली कोई भी इवेंट आ गई है” अलर्ट्स के लिए। कोई एकत्रीकरण नहीं; डिस्पैचर तुरंत निकलता है जैसे ही यह लुकबैक विंडो में मेल देखता है।

{
  "event_type": "error",
  "lookback_secs": 60,
  "environment": "production",
  "tool_name": "bash",
  "agent_id": "caa",
  "error_type": "TimeoutError",
  "message_contains": "vertex-ai timed out"
}

सभी फिल्टर्स AND-संयुक्त हैं; कोई भी फील्ड जिसे आप छोड़ते हैं वह अनबाध है।

फील्ड	उद्देश्य
`agent_id`	एक विशिष्ट एजेंट (जो `/errors` पंक्ति पर दिखाया गया है) से त्रुटियों तक सीमित करें।
`error_type`	एक विशिष्ट त्रुटि वर्ग तक सीमित करें (जैसे `TimeoutError`) सभी त्रुटियों के बजाय।
`message_contains`	`payload.message` के विरुद्ध केस-असंवेदनशील सबस्ट्रिंग मेल। एक विशिष्ट विफलता मोड को पकड़ने के लिए उपयोगी (जैसे `prompt is too long`) एक ही एजेंट से हर त्रुटि पर अलर्ट किए बिना। 200 वर्णों तक सीमित; एक शाब्दिक स्ट्रिंग के रूप में मेल किया गया, पैटर्न नहीं।

टिप: lookback_secs को अलर्ट के eval_interval_secs से मोटे तौर पर मेल खाने के लिए सेट करें ताकि आप एक ही इवेंट पर दोबारा सूचित न हों। /errors से शॉर्टकट: प्रत्येक त्रुटि समूह की प्रतिनिधि पंक्ति त्रुटि दृश्य पर (और एक त्रुटि इवेंट के लिए सत्र इवेंट-विवरण पैनल) में एक + alert बटन है जो /alerts/new को खोलता है जो per_event ट्रिगर के साथ भरा होता है उस पंक्ति के event_type + पर्यावरण के लिए, जब मौजूद हो तो पेलोड के error_type से बीजित नाम सहित। आप अभी भी चैनल चुनते हैं और लुकबैक की पुष्टि करते हैं, लेकिन मेल आपके लिए भरा होता है। ऑपरेटर्स को बटन दिखाई देने के लिए alerts:write की आवश्यकता होती है।

मिश्रित तर्क (M of N)

हर अलर्ट में ट्रिगर के अलावा दो पूर्णांक नियंत्रण होते हैं:

eval_window: हाल के कितने मूल्यांकन देखने के लिए (डिफ़ॉल्ट 1)
min_breaches: उनमें से कितने अलर्ट निकलने से पहले उल्लंघन करना चाहिए (डिफ़ॉल्ट 1)

1 of 1 (डिफ़ॉल्ट) “पहली उल्लंघन पर निकल जाएं” है। 3 of 5 का अर्थ है “निकल जाएं जब नियम पिछली 5 मूल्यांकन में से 3 को उल्लंघन कर चुका हो”, झिलमिलाते हुए संकेतों के लिए उपयोगी जहां एक एकल खराब माप शोर है। डिस्पैचर प्रति अलर्ट एक रिंग बफर बनाए रखता है; आपको राज्य प्रबंधित करने की आवश्यकता नहीं है।

मूल्यांकन अंतराल

eval_interval_secs नियंत्रित करता है कि डिस्पैचर आपके नियम को कितनी बार चलाता है। [30, 86400] तक क्लैंप किया गया। डैशबोर्ड में प्रीसेट्स: 1m / 5m / 15m / 1h। एक अंतराल चुनें जो अंतर्निहित संकेत कितनी तेजी से चलता है इससे मेल खाता है: एक 5-मिनट की त्रुटि-दर अलर्ट हर 15 सेकंड में मूल्यांकन किया गया CPU बर्बाद करता है; एक प्रति-इवेंट अलर्ट को एक छोटे लुकबैक की आवश्यकता है या यह टिक्स के बीच घटनाओं को चुप्पी से ड्रॉप करेगा।

चैनल्स

प्रत्येक अलर्ट इन चारों में से किसी संयोजन को संलग्न कर सकता है। प्रति-चैनल क्रेडेंशियल्स (Slack वेबहुक URL, सामान्य वेबहुक URL + हस्ताक्षर गुप्त, डिफ़ॉल्ट ईमेल प्राप्तकर्ता) /settings में एक बार कॉन्फ़िगर किए जाते हैं और प्रत्येक अलर्ट से कुंजी द्वारा संदर्भित होते हैं। इस तरह एक Slack चैनल कई अलर्ट्स को सेवा दे सकता है बिना प्रत्येक का अपना वेबहुक URL की कॉपी संग्रहीत किए। तीन बाहरी चैनल प्रकार (ईमेल, Slack, वेबहुक) भी एक संगठन-व्यापी किल स्विच द्वारा गेटेड हैं, alerts.enabled_channels। जब एक निकली अलर्ट एक चैनल प्रकार को संलग्न करती है जो इस सेट में नहीं है, डिस्पैचर इसे छोड़ता है और स्थिति skipped_disabled और लक्ष्य <channel_disabled> के साथ एक alert_notifications पंक्ति रिकॉर्ड करता है (आपको वैश्विक रूप से रोकने देता है, उदाहरण के लिए, सभी Slack वितरण हर नियम को संपादित किए बिना)। इन-डैशबोर्ड चैनल हमेशा अनुमत है। कॉन्फ़िगरेशन देखें।

ईमेल

OTP लॉगिन ईमेल भेजने वाली ही SMTP ट्रांसपोर्ट को पुनः उपयोग करता है। प्राप्तकर्ता क्रम में समाधान करते हैं:

प्रति-चैनल recipients[] ओवरराइड (जब गैर-खाली)।
alerts.email_default_recipients सेटिंग (ईमेल स्ट्रिंग्स की एक array)।

यदि SMTP अनकॉन्फ़िगर किया गया है तो चैनल एक no-op है; डिस्पैचर अभी भी लक्ष्य <smtp_unconfigured> के साथ एक alert_notifications पंक्ति रिकॉर्ड करता है ताकि ऑडिट ट्रेल गलतकॉन्फ़िगरेशन को दृश्यमान बनाता है।

Slack

एक incoming webhook URL के लिए एक Block Kit संदेश भेजता है।

डिफ़ॉल्ट URL: alerts.slack_default_webhook (/settings में सेट)।
प्रति-अलर्ट ओवरराइड: चैनल के webhook_setting_key को किसी अन्य URL-प्रकार की सेटिंग कुंजी पर सेट करें, जैसे alerts.slack_oncall, alerts.slack_costs।

शीर्षलेख में एक गंभीरता इमोजी (:rotating_light: / :warning: / :bell:) शामिल है, और संदेश एक बटन ले जाता है जो घटना पृष्ठ को गहराई से लिंक करता है।

सामान्य वेबहुक

PagerDuty, Opsgenie, या आपकी स्वयं की ingestion endpoint के लिए एक JSON-POST एकीकरण। बॉडी आकार:

{
  "schema_version": 1,
  "event": "alert.firing",
  "incident": { "id": "uuid", "url": "https://…/incidents/uuid", "opened_at": "2026-…" },
  "alert":    { "id": "uuid", "name": "errors > 50/hr", "severity": "critical" },
  "breach":   { "value": 73.0, "summary": "ErrorCount > 50 (observed 73.000)", "evidence": { … } }
}

जब alerts.webhook_signing_secret सेट किया गया है, तो अनुरोध में एक X-AgentEye-Signature: sha256=<hex> हेडर शामिल है, गुप्त का उपयोग करके बॉडी का HMAC-SHA256। पेलोड पर विश्वास करने से पहले प्राप्त करने वाले पक्ष पर इसे सत्यापित करें। हेडर X-AgentEye-Event alert.firing / alert.test ले जाता है। (alert.resolved योजना बद्ध auto-resolve फीचर के लिए आरक्षित है और वर्तमान में उत्सर्जित नहीं है।)

इन-डैशबोर्ड

कोई बाहरी वितरण नहीं: अलर्ट केवल एक alert_notifications पंक्ति लिखता है जो डैशबोर्ड का घटनाएं पृष्ठ सतह करता है। जब आप एक नियम को ट्यून कर रहे हैं और बाहरी सिस्टम को स्पैम नहीं करना चाहते हैं तो उपयोगी, या कम-तत्काल अलर्ट्स के लिए जो ऑपरेटर सामान्य छंटाई के दौरान जांचते हैं।

घटना जीवनचक्र

firing  ──ack──▶  acknowledged
   │                    │
   └────────────────────┴───── operator resolve ───▶  resolved

firing — डिस्पैचर बस घटना को खोलता है या एक और उल्लंघन का पता लगाता है। निकली सूचना बिल्कुल एक बार प्रशंसकों की ओर है (घटना पर notified_firing_at टाइमस्टैम्प द्वारा गेटेड)।
acknowledged — एक ऑपरेटर /incidents/:id पर ack दबाता है। घटना अभी भी खुली मानी जाती है; बाद की उल्लंघनें इसके प्रमाण को अपडेट करेंगी बिना पुनः-सूचित किए।
resolved — एक ऑपरेटर resolve दबाता है। जब नियम निकलना बंद हो जाए तो स्वचालित समाधान की योजना है लेकिन वर्तमान में सक्षम नहीं है, इसलिए एक खुली घटना एक ऑपरेटर द्वारा इसे हल करने तक खुली रहती है।

एक नई घटना किसी भी समय पिछली को हल करने के बाद एक ही अलर्ट पर फिर से खुल सकती है। गतिविधि समयरेखा। घटना पर हर कार्य — खोला, स्वीकार किया, हल किया — एक append-only गतिविधि लॉग में रिकॉर्ड किया जाता है और घटना की गतिविधि समयरेखा पर दिखाया जाता है, प्रत्येक प्रविष्टि इसे करने वाले ऑपरेटर को (ईमेल द्वारा) या स्वचालित के लिए जो कार्य डिस्पैचर ने अपने आप पर किए (उल्लंघन पर auto-open)। स्वीकृति साझा की जाती है: कई ऑपरेटर एक ही घटना को ack कर सकते हैं और प्रत्येक एक अलग, विशेषीकृत प्रविष्टि के रूप में दिखाई देता है। घटनाएं इनबॉक्स राज्य द्वारा खुली घटनाओं को समूहित करता है और आपको गंभीरता और असाइनी द्वारा फिल्टर करने देता है:

घटनाएं इनबॉक्स अलर्ट-लिंक्ड और ad-hoc घटना कार्ड्स गंभीरता बैजेस और असाइनी के साथ दिखा रहा है

एक घटना विवरण खोलना उल्लंघन प्रमाण, असाइनी और सदस्य, विशेषीकृत गतिविधि समयरेखा, और एक टिप्पणी थ्रेड दिखाता है:

एक घटना विवरण दृश्य: मातृ अलर्ट, उल्लंघन सारांश, असाइनी, सदस्य, विशेषीकृत गतिविधि लॉग, और बातचीत

आवश्यक अनुमतियां

अलर्ट नियमों को लिखना और घटनाओं को ट्रिएज करना अलग-अलग चिंताएं हैं जिनके अलग-अलग अनुदान हैं, इसलिए आप एक ऑन-कॉल रोटेशन को घटना पहुंच दे सकते हैं बिना नियमों को फिर से लिखने की क्षमता भी सौंप दिए।

alerts:read: अलर्ट नियमों को देखें।
alerts:write: अलर्ट नियमों को बनाएं, संपादित करें, हटाएं, और एक परीक्षण सूचना ट्रिगर करें।
incidents:read: घटनाओं को देखें।
incidents:write: मैनुअल (ad-hoc) घटनाएं खोलें जो एक अलर्ट से जुड़ी नहीं हैं।
incidents:ack: घटनाओं को स्वीकार करें, असाइन करें, टिप्पणी करें, और हल करें।

विरासत alerts:ack। कुंजियां और ऑपरेटर जिन्हें पुरानी alerts:ack टोकन दी गई थी काम करते रहें: इसे incidents:ack के रूप में सम्मानित किया जाता है (और incidents:read को दर्शाता है), इसलिए मौजूदा ऑन-कॉलर्स को क्रेडेंशियल फिर से जारी किए बिना अपनी पहुंच बनाए रखते हैं। incidents:* परिवार के साथ नए अनुदान जारी करें।

API कुंजियों पर अनुदान (POST /keys) और ऑपरेटर (PUT /users/:id)। डैशबोर्ड का PermGate संबंधित बटनों को तब लॉक करता है जब कोई अनुमति गायब हो; आप कार्य के आगे // 403 देखेंगे।

ईमेल-प्राप्तकर्ता पिकर। अलर्ट संपादक का प्राप्तकर्ता पिकर आपके संगठन के सदस्यों को सूचीबद्ध करता है ताकि आप उन्हें नाम से चुन सकें। यह किसी भी ऑपरेटर के लिए लोड होता है जिसके पास alerts:read या alerts:write है; इस उद्देश्य के लिए अपनी टीम की निर्देशिका देखना users:read की आवश्यकता नहीं है, और पिकर केवल सदस्य ईमेल पते लौटाता है, पूर्ण उपयोगकर्ता रिकॉर्ड कभी नहीं।

कॉन्फ़िगरेशन

डिस्पैचर द्वारा उपभोग किए गए पर्यावरण चर:

चर	डिफ़ॉल्ट	उद्देश्य
`ALERT_WORKERS`	`1`	प्रति सर्वर उदाहरण कार्य कार्य। अधिकांश तैनाती को केवल एक की आवश्यकता है।
`ALERT_CLAIM_BATCH`	`16`	अधिकतम अलर्ट्स एक एकल कार्यकर्ता टिक प्रक्रिया करता है।
`ALERT_POLL_IDLE_SECS`	`5`	जब कतार खाली हो तो कार्यकर्ता नींद।
`ALERT_REQUEST_TIMEOUT_MS`	`15000`	प्रति-ट्रिगर मूल्यांकन समय सीमा।
`DASHBOARD_URL`	`https://app.befailproof.ai`	मूल जिसका उपयोग सूचनाओं में घटना जादू-लिंक बनाने के लिए किया जाता है। अपने डैशबोर्ड होस्ट पर सेट करें।

एक अनुपस्थित मूल्यांकन विफलता के बाद (ClickHouse पहुंचने योग्य नहीं, एक क्वेरी समय सीमा), डिस्पैचर घातीय backoff के साथ नियम को फिर से प्रयास करता है। एक बार जब एक नियम 5 लगातार अनुपस्थित विफलताओं को जमा कर दिया है तो यह backoff जारी रखने के बजाय अपने सामान्य cadence पर फिर से अनुसूचित किया जाता है, इसलिए एक लगातार विफल नियम अभी भी फिर से मूल्यांकन किए जाते रहते हैं। यह सीमा तय की गई है और ऑपरेटर-tunable नहीं है। चैनल सेटिंग्स (/settings से प्रबंधित, env नहीं):

alerts.email_default_recipients (email_list): ईमेल स्ट्रिंग्स की JSON array — ईमेल चैनल्स के लिए डिफ़ॉल्ट प्राप्तकर्ता।
alerts.slack_default_webhook (url): डिफ़ॉल्ट Slack incoming-webhook URL।
alerts.webhook_default_url (url): डिफ़ॉल्ट सामान्य-वेबहुक URL।
alerts.webhook_signing_secret (secret): HMAC-SHA256 कुंजी। GET प्रतिक्रिया में हमेशा "" के रूप में लौटाया जाता है; घुमाने के लिए एक नया मान टाइप करें।
alerts.enabled_channels (channel_set): बाहरी चैनल प्रकार्स का संगठन-व्यापी सेट जो अलर्ट निकलता है; सभी तीन के लिए डिफ़ॉल्ट (email, slack, webhook)। एक प्रकार को यहां हटाने से हर अलर्ट के लिए संपादित किए बिना उस चैनल को वैश्विक रूप से दबा दिया जाता है। इन-डैशबोर्ड चैनल हमेशा वितरित किया जाता है और इस सेटिंग से प्रभावित नहीं है।

एक नए अलर्ट को सत्यापित करें

एक नए अलर्ट पर निर्भर करने से पहले:

इसे कम से कम एक सूचना चैनल के साथ सक्षम के रूप में सहेजें।
अलर्ट विवरण पृष्ठ पर परीक्षण का चयन करें और पुष्टि करें कि प्रत्येक कॉन्फ़िगर किया गया गंतव्य सिंथेटिक सूचना प्राप्त करता है।
पहली वास्तविक उल्लंघन के बाद, पुष्टि करें कि घटना घटनाएं के अंतर्गत दिखाई देती है और इसका मापा मूल्य संबंधित डैशबोर्ड क्वेरी से मेल खाता है।

जब एक शर्त स्पष्ट हो जाती है तो घटनाएं स्वचालित रूप से हल नहीं होती हैं। एक ऑपरेटर को घटना विवरण पृष्ठ से उन्हें हल करना चाहिए।

समस्या निवारण

लक्षण	संभावित कारण
अलर्ट कभी निकलता नहीं	`enabled = false`, या कोई चैनल संलग्न नहीं, या अंतर्निहित CH क्वेरी 0 पंक्तियां देता है। चैनल की पुष्टि करने के लिए परीक्षण का उपयोग करें; मीट्रिक की पुष्टि करने के लिए `/queries/run` का उपयोग करें।
Slack सूचना गायब	`alerts.slack_default_webhook` (या प्रति-अलर्ट ओवरराइड कुंजी) अनसेट है: `alert_notifications.target` में `<unset:…>` पंक्तियों के लिए जांचें; या `slack` प्रकार `alerts.enabled_channels` में वैश्विक रूप से अक्षम है: `alert_notifications` पंक्तियों को स्थिति `skipped_disabled` और लक्ष्य `<channel_disabled>` के साथ जांचें।
सामान्य वेबहुक 401	प्राप्तकर्ता एक हस्ताक्षर की आवश्यकता है लेकिन `alerts.webhook_signing_secret` अनसेट है। प्राप्तकर्ता पर सत्यापित करें कि HMAC `hmac_sha256(secret, body)` से मेल खाता है।
ईमेल “सभी भेजने विफल से”	SMTP क्रेडेंशियल गलत या `from` पता आपके रिले द्वारा अस्वीकृत है। एक ही सतह जो OTP ईमेल भेजती है: यदि वह काम करते हैं, SMTP ट्रांसपोर्ट ठीक है।
घटना बार-बार फिर से खुलती है	मिश्रित नियंत्रण बहुत आक्रामक हैं: `min_breaches` बढ़ाने या `eval_window` बढ़ाने का प्रयास करें ताकि अस्थायी स्पाइक्स आप हल की गई घटनाओं को फिर से न खोलें।

​अवधारणाएं

​ट्रिगर प्रकार

​1. metric_threshold

​2. custom_sql

​3. evaluation_score

​4. eval_compound

​5. per_event

​मिश्रित तर्क (M of N)

​मूल्यांकन अंतराल

​चैनल्स

​ईमेल

​Slack

​सामान्य वेबहुक

​इन-डैशबोर्ड

​घटना जीवनचक्र

​आवश्यक अनुमतियां

​कॉन्फ़िगरेशन

​एक नए अलर्ट को सत्यापित करें

​समस्या निवारण