> ## Documentation Index > Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt > Use this file to discover all available pages before exploring further. # अलर्ट्स > AgentEye अलर्ट्स दस्तावेज़। अलर्ट्स शेड्यूल के अनुसार एक नियम का मूल्यांकन करते हैं और आपको सूचित करते हैं जब कुछ थ्रेसहोल्ड पार करता है। वे 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`। उदाहरण विनिर्देश: ```json theme={null} { "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` का उपयोग करके करता है। ```json theme={null} { "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` पढ़ता है और एक विंडो के पार एक नामित स्कोर के औसत की तुलना करता है। ```json theme={null} { "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 शर्तें उल्लंघन करती हैं | ```json theme={null} { "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 से मेल खाने वाली कोई भी इवेंट आ गई है" अलर्ट्स के लिए। कोई एकत्रीकरण नहीं; डिस्पैचर तुरंत निकलता है जैसे ही यह लुकबैक विंडो में मेल देखता है। ```json theme={null} { "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` और लक्ष्य `` के साथ एक `alert_notifications` पंक्ति रिकॉर्ड करता है (आपको वैश्विक रूप से रोकने देता है, उदाहरण के लिए, सभी Slack वितरण हर नियम को संपादित किए बिना)। इन-डैशबोर्ड चैनल हमेशा अनुमत है। [कॉन्फ़िगरेशन](#configuration) देखें। ### ईमेल OTP लॉगिन ईमेल भेजने वाली ही SMTP ट्रांसपोर्ट को पुनः उपयोग करता है। प्राप्तकर्ता क्रम में समाधान करते हैं: 1. प्रति-चैनल `recipients[]` ओवरराइड (जब गैर-खाली)। 2. `alerts.email_default_recipients` सेटिंग (ईमेल स्ट्रिंग्स की एक array)। यदि SMTP अनकॉन्फ़िगर किया गया है तो चैनल एक no-op है; डिस्पैचर अभी भी लक्ष्य `` के साथ एक `alert_notifications` पंक्ति रिकॉर्ड करता है ताकि ऑडिट ट्रेल गलतकॉन्फ़िगरेशन को दृश्यमान बनाता है। ### Slack एक [incoming webhook URL](https://api.slack.com/messaging/webhooks) के लिए एक 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 एकीकरण। बॉडी आकार: ```json theme={null} { "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=` हेडर शामिल है, गुप्त का उपयोग करके बॉडी का 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`)। एक प्रकार को यहां हटाने से हर अलर्ट के लिए संपादित किए बिना उस चैनल को वैश्विक रूप से दबा दिया जाता है। इन-डैशबोर्ड चैनल हमेशा वितरित किया जाता है और इस सेटिंग से प्रभावित नहीं है। *** ## एक नए अलर्ट को सत्यापित करें एक नए अलर्ट पर निर्भर करने से पहले: 1. इसे कम से कम एक सूचना चैनल के साथ सक्षम के रूप में सहेजें। 2. अलर्ट विवरण पृष्ठ पर **परीक्षण** का चयन करें और पुष्टि करें कि प्रत्येक कॉन्फ़िगर किया गया गंतव्य सिंथेटिक सूचना प्राप्त करता है। 3. पहली वास्तविक उल्लंघन के बाद, पुष्टि करें कि घटना **घटनाएं** के अंतर्गत दिखाई देती है और इसका मापा मूल्य संबंधित डैशबोर्ड क्वेरी से मेल खाता है। जब एक शर्त स्पष्ट हो जाती है तो घटनाएं स्वचालित रूप से हल नहीं होती हैं। एक ऑपरेटर को घटना विवरण पृष्ठ से उन्हें हल करना चाहिए। *** ## समस्या निवारण | लक्षण | संभावित कारण | | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | अलर्ट कभी निकलता नहीं | `enabled = false`, या कोई चैनल संलग्न नहीं, या अंतर्निहित CH क्वेरी 0 पंक्तियां देता है। चैनल की पुष्टि करने के लिए *परीक्षण* का उपयोग करें; मीट्रिक की पुष्टि करने के लिए `/queries/run` का उपयोग करें। | | Slack सूचना गायब | `alerts.slack_default_webhook` (या प्रति-अलर्ट ओवरराइड कुंजी) अनसेट है: `alert_notifications.target` में `` पंक्तियों के लिए जांचें; या `slack` प्रकार `alerts.enabled_channels` में वैश्विक रूप से अक्षम है: `alert_notifications` पंक्तियों को स्थिति `skipped_disabled` और लक्ष्य `` के साथ जांचें। | | सामान्य वेबहुक 401 | प्राप्तकर्ता एक हस्ताक्षर की आवश्यकता है लेकिन `alerts.webhook_signing_secret` अनसेट है। प्राप्तकर्ता पर सत्यापित करें कि HMAC `hmac_sha256(secret, body)` से मेल खाता है। | | ईमेल "सभी भेजने विफल से" | SMTP क्रेडेंशियल गलत या `from` पता आपके रिले द्वारा अस्वीकृत है। एक ही सतह जो OTP ईमेल भेजती है: यदि वह काम करते हैं, SMTP ट्रांसपोर्ट ठीक है। | | घटना बार-बार फिर से खुलती है | मिश्रित नियंत्रण बहुत आक्रामक हैं: `min_breaches` बढ़ाने या `eval_window` बढ़ाने का प्रयास करें ताकि अस्थायी स्पाइक्स आप हल की गई घटनाओं को फिर से न खोलें। |