Grafana: टेम्प्लेट वेरिएबल का उपयोग करके प्रश्नों के लिए अलर्ट समर्थन

+1

1. केवल सभी का उपयोग करने की तुलना में क्या अंतर होगा?

+1
कम लाइफ टाइम (एडब्ल्यूएस ऑटो स्केलिंग) के साथ सर्वर पर अलर्ट जोड़ने में सक्षम होना अच्छा होगा, ग्राफाना पर सर्वर को ऑटो रजिस्टर करना टेम्प्लेटिंग के साथ आसान है, लेकिन उन पर अलर्ट नहीं कर पाना दुखद है

@bergquist उदाहरण के लिए सभी का उपयोग करना अव्यावहारिक है जब आपके पास एक दर्जन से अधिक होस्ट हैं।

उदाहरण के लिए यदि उनमें से केवल कुछ ही विफल हो रहे हैं, (मान लें 5), प्रत्येक विफल होने वाले अलर्ट के लिए एक ईमेल प्राप्त करना बहुत उपयोगी है। इस तरह से अन्य उपकरणों के साथ एकीकृत करना भी बहुत आसान है जो सामान्य रूप से प्रति मीट्रिक एक अलर्ट की अपेक्षा करते हैं।

वर्तमान दृष्टिकोण (सभी का उपयोग करके) बहुत साफ है, हालांकि जब कम उदाहरण हैं या जब आप सेवा स्तर पर अलर्ट कर रहे हैं (उदाहरण के लिए कतार में नौकरियों की #)।

क्या @calind ने कहा, मेरे पास कई $ होस्ट चर हैं जो influxDB के साथ ठीक काम कर रहे हैं लेकिन अलर्ट के साथ नहीं

+1 भी।

बस एक विचार, चूंकि आप एक टेम्प्लेट वैरिएबल के साथ क्वेरी करने में सक्षम हैं, क्या आप अलर्टिंग मेट्रिक्स के साथ एक ही क्वेरी करने में सक्षम नहीं होंगे और शायद परिणामों के माध्यम से यह देखने के लिए कि अलर्ट मानदंड को पूरा करते हैं?

@NotSoCleverLogin यह संभव होगा। लेकिन क्या आप इस आधार पर अलर्ट नियम के व्यवहार को बदलना चाहेंगे कि कौन-सा टेम्प्लेट varlue चुना गया है?

टेम्पलेट के लिए सभी विकल्प का उपयोग करना ही मेरे लिए समझ में आता है।

+1

मेरे पास प्रत्येक वातावरण में समान घटकों के साथ X परिवेशों का एक सेटअप है। हम वर्तमान में सीपीयू उपयोग/डिस्क उपयोग इत्यादि पर अलर्ट करने के लिए प्रोमेथियस का उपयोग कर रहे हैं। वहां हम एक क्वेरी के लिए अलर्ट निर्दिष्ट करते हैं, और जब अलर्ट ट्रिगर होता है तो यह केवल यह बताएगा कि अलर्ट किस पर्यावरण से ट्रिगर किया गया था।

अगर हम इसे All वेरिएबल के साथ करेंगे, तो यह कुछ हद तक काम करेगा। लेकिन, @calind के उदाहरण का उपयोग करते हुए, स्क्रीनशॉट मेरे सभी परिवेशों से सभी cpus की प्रवृत्ति से भर जाएगा, न कि केवल उस वातावरण से जहां मैं उक्त समस्या के बारे में सूचित होना चाहता हूं। ग्राफ़ अन्य परिवेशों की जानकारी के साथ (या कर सकता है) अस्पष्ट हो जाएगा। कुछ परिदृश्यों में अन्य वातावरणों में सीपीयू की तुलना करना दिलचस्प हो सकता है, लेकिन इस बात की कोई गारंटी नहीं है कि परीक्षण वातावरण में जो हो रहा है वह हमारे उत्पादन वातावरण में हो रहा है, आदि।

हम ऐसे डैशबोर्ड बनाने पर भी विचार कर रहे हैं जिनका उपयोग संचालन द्वारा किया जा सकता है, जो "मानक" अवलोकन डैशबोर्ड में अलर्ट के लिए एनोटेशन दिखा रहा है। यह देखते हुए कि हम इस तरह के डैशबोर्ड के लिए 'env' टेम्प्लेट वैरिएबल का उपयोग करते हैं, हमारे लिए यह वास्तव में संभव नहीं है कि इसे अभी कैसे लागू किया जाए। मुझे मैन्युअल रूप से (कम से कम कुछ हद तक) एक "छाया" डैशबोर्ड उत्पन्न करना होगा जहां अलर्ट ट्रिगर होते हैं (जो मुझे अवलोकन डैशबोर्ड में एनोटेशन को ढीला कर देता है)।

एक और चीज जो मुझे लगता है कि टेम्पलेट चर आपकी मदद कर सकते हैं, अलर्ट को रूट करना (क्या आपको ऐसी सुविधा को लागू करना चुनना चाहिए) विभिन्न स्रोतों (कुछ उत्पादन में संचालन के लिए, क्यूए/डेवलपर्स को परीक्षण वातावरण आदि में)।

टेम्प्लेट किए गए प्रश्नों पर अलर्ट का समर्थन करने के लिए +1।

@bergquist , कुछ डैशबोर्ड में _All_ विकल्प नहीं होता है। उदाहरण के लिए सिस्टम मेट्रिक्स एकत्रित करके (https://grafana.net/dashboards/24)। मान लीजिए कि 10 या अधिक सर्वरों के लिए _All_ विकल्प होना निश्चित रूप से व्यावहारिक नहीं होगा। यही कारण है कि गर्त टेम्पलेट चर को पुनरावृत्त करने की आवश्यकता है।

सभी का उपयोग करने की अनुमति देना एक अच्छी और स्वागत योग्य शुरुआत है।

प्रोमेथियस में, सभी को अनुमति देने के लिए प्रश्नों को एक अलग तरीके से लिखा जाना चाहिए:

some.metric{hostname=~"$Hostname"}

वहां अतिरिक्त टिल्ड पर ध्यान दें, नियमित अभिव्यक्ति खोज (और सभी में वाइल्डकार्ड) की अनुमति देता है।

मैंने सीधे क्वेरी से रेगेक्स खोज क्वेरी पर जाने के संभावित प्रदर्शन प्रभाव को बेंचमार्क नहीं किया है, लेकिन कम से कम अभी के लिए यह स्पष्ट रूप से हमारी समस्याओं का समाधान करेगा।

+1

+1

सुनिश्चित नहीं है कि इसे कैसे कार्यान्वित किया जाना चाहिए, बस यह जान लें कि इसकी आवश्यकता है ..

+1
हम अपने ऑन-प्रेम K8S क्लस्टर्स और हमारे AWS K8S क्लस्टर्स के लिए अपने Kubernetes Infrastructure की निगरानी के लिए डेटा स्रोत के रूप में Prometheus का उपयोग करते हैं।
हमारे सभी डैशबोर्ड डेटा स्रोत ($पर्यावरण), $Instance/Node, $Namespace, और $Pod के लिए टेम्प्लेट किए गए वैरिएबल का उपयोग करते हैं।
प्रोमेथियस क्वेरी संरचना जिस तरह से है; सभी प्रश्नों में टेम्पलेट चर हैं; जो अलर्ट रूल्स को सेव करने से रोकता है।
मुझे चेतावनी में जोड़े गए टेम्प्लेटेड वेरिएबल क्वेरीज़ को देखना अच्छा लगेगा।

+1

+1
हम बहु-सर्वर वातावरण के लिए टेम्प्लेटिंग डैशबोर्ड का उपयोग करते हैं जो तार्किक तरीका है (और कई लोग इसका उपयोग करते हैं), इसलिए हम अभी ग्राफाना के साथ अलर्टिंग का उपयोग नहीं कर सकते हैं। एकमात्र तरीका यह है कि प्रोमेथियस के साथ एक अलग गैर-टेम्पलेटिंग डैशबोर्ड या सेटअप अलर्ट किया जाए जो आसान नहीं है।

शायद अगर सभी क्षेत्रों में समर्थित/पूर्व-रेंडर किए गए टेम्पलेट चर के साथ डैशबोर्ड को सहेजने/निर्यात करने का कोई विकल्प या आसान तरीका था ...

टेम्प्लेट किए गए प्रश्नों पर अलर्ट का समर्थन करने के लिए +1। वर्तमान में हम अपने सभी डैशबोर्ड पर टेम्प्लेटिंग का उपयोग करते हैं, इसलिए इस बहुत बढ़िया सुविधा का लाभ नहीं उठा सकते हैं।

+1, हमारे पास बहुत सारे टेम्प्लेटेड डैशबोर्ड हैं, और हम अभी अलर्टिंग का उपयोग नहीं कर सकते हैं, हमें अलर्ट रखने के लिए डैशबोर्ड को डुप्लिकेट करना होगा, और हम टेम्प्लेटिंग पावर खो देते हैं

+1, हमारे लगभग सभी डैशबोर्ड टेम्प्लेट वैरिएबल (और नेस्टेड टेम्प्लेट वैरिएबल) का उपयोग करते हैं।

यदि आवश्यक हो तो हम प्रति टेम्पलेट-चर समूह के लिए अलग-अलग अलर्ट प्राप्त करने के लिए रिपीट पैनल पर अलर्ट सेट करने में सक्षम होना चाहते हैं। साथ ही इसका मतलब है कि अलर्ट गतिशील है और सुपर मैनुअल नहीं है जैसा कि अभी है।

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

+1

ग्राफाना के साथ काम करते समय ऐसा लगता है कि टेम्प्लेटिंग को हर जगह प्रोत्साहित किया जाता है और केवल अलर्टिंग फीचर का उपयोग करने के लिए चर का उपयोग न करते हुए ग्राफ़ का एक अतिरिक्त सेट बनाना गलत लगता है ...

टेम्प्लेट किए गए प्रश्नों पर अलर्ट का समर्थन करने के लिए +1।
साथ ही, हमने पाया कि जब हम चीनी नियम नाम या चीनी शीर्षक का उपयोग करते हैं, तो हमें नियम ट्रिगर के साथ असामान्य ईमेल प्राप्त होता है। उदाहरण के लिए, हमें "个股分时线接口请求时间(getTimeTrend) अलर्ट" की उम्मीद थी, लेकिन हमें "ä¸ªè‚¡åˆ†æ—¶çº¿æŽ¥å £è¯·æ±‚æ—¶é—´( getTimeTrend) अलर्ट", हो सकता है कि वर्णसेट सही न हो।

अलर्ट में टेम्प्लेट किए गए वर्रों को लागू करने के लिए +1

+1

+1 को एक बढ़िया अतिरिक्त मिलेगा

+1

अलर्ट में टेम्प्लेट किए गए वर्रों को लागू करने के लिए +1

+1

+1 इसके लिए तत्पर हैं

+1

+1

+1

+1

कृपया +1 लिखना बंद करें!
इस मुद्दे की सदस्यता लेने वाले प्रत्येक व्यक्ति को एक ईमेल प्राप्त होगा...

केवल उन +1 टिप्पणियों से छुटकारा पाने के लिए एक जीथब सुविधा है:
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

@thetechnick ई-मेल में एक लिंक है जहां आप थ्रेड को म्यूट कर सकते हैं और कोई ई-मेल प्राप्त नहीं कर सकते हैं। लेकिन मैं समझता हूं कि हो सकता है कि आप इस सुविधा के पूर्ण होने पर केवल सूचना प्राप्त करना चाहें, लेकिन मैं इस मुद्दे को टकराना भी पसंद करता हूं ताकि उम्मीद है कि यह जल्द ही काम कर लेगा :)

समग्र रूप से सतर्क करने पर शानदार प्रगति।
चेतावनी में टेम्पलेट चर के लिए, मुझे यह भी याद आ रहा है। +1: डी

=
इसके शीर्ष पर एक तरह से एक बग हो सकता है, ग्राफाना यह पता लगाता है कि query में प्रयुक्त मीट्रिक टेम्पलेट चर का उपयोग करता है या नहीं।

जब आपके पास एक श्रृंखला होती है जो अप्रत्यक्ष रूप से टेम्पलेट चर का उपयोग करती है, तो Grafana आपको उस श्रृंखला को अलर्ट के रूप में जोड़ने से नहीं रोकता है। अलर्ट स्पष्ट रूप से सही ढंग से काम नहीं करता है।

#K देखें (यह #D का उपयोग करता है, जो #A का उपयोग करता है और #A templ का उपयोग करता है। var):

मैं अभी भी इसे चुन सकता था:

हर जगह टेम्प्लेट, जिसका मतलब है कि कहीं भी अलर्ट करना।
सुनिश्चित नहीं है कि अलर्टिंग को कैसे लागू किया गया है, लेकिन एक साधारण ग्राफ के लिए क्वेरी को "अनुवादित" किया जाता है, डेटा स्रोत पर कॉल करने से पहले टेम्पलेट वैरिएबल को मानों के साथ प्रतिस्थापित किया जाता है, है ना? तो इस मामले में क्यों नहीं? किसी भी तरह से, जैसा कि पहले कहा गया है, टेम्पलेट चर का उपयोग करने वाले लगभग सभी प्रश्नों के होने पर, अलर्ट करना पूरी तरह से मेरे लिए है। कृपया, क्या आप इसे लागू कर सकते हैं ताकि हमें ग्रैफाना के बाहर अलर्ट करने की आवश्यकता न पड़े? बहुत - बहुत धन्यवाद!

मुझे लगता है कि हमें यह पहचानना चाहिए कि टेम्प्लेटिंग के साथ अलर्ट करना मामूली नहीं है और मुझे लगता है कि सभी विकल्प जाने का रास्ता है क्योंकि हम नहीं चाहते कि जब कोई डैशबोर्ड का उपयोग कर रहा हो तो हमारे अलर्ट बदल जाएं।
लेकिन अगर टेम्प्लेट क्वेरी नए परिणाम देती है तो ग्राफाना को अभी भी नए अलर्ट बनाने होंगे...
यदि आप InfluxDB का उपयोग कर रहे हैं तो इससे और समस्याएं होती हैं क्योंकि हम में से कई टैग/टैग मानों का उपयोग कर रहे हैं, और उनके लिए कोई समय फ़िल्टर नहीं है ... इसलिए ग्राफाना किसी भी होस्ट पर मौजूद सभी सेवाओं के लिए अलर्ट तैयार करेगा। .

+1

अलर्ट में डेटा स्रोत निर्दिष्ट करने की अनुमति देना मेरे लिए ठीक रहेगा। यह किसी भी तर्क को नहीं तोड़ेगा, और मैं देखने के लिए कम से कम उत्पादन और स्टेजिंग वातावरण निर्दिष्ट कर सकता हूं।

सभी एक विकल्प है, निश्चित रूप से। क्वेरी में टेम्प्लेट वेरिएबल्स की पहचान और उपयोगकर्ता को अलर्ट कंडीशन कॉन्फ़िगरेशन में मान सेट करने की अनुमति देना अधिक लचीला होगा। मुझे लगता है कि सबसे अच्छा, लेकिन जटिल, एकाधिक अलर्ट होना होगा (उसी तरह कई प्रश्न हैं) ताकि क्वेरी में एक अलग टेम्पलेट वैरिएबल मानों के लिए एक अलग अलर्ट सेट अप किया जा सके। यह व्यवस्थापक को उदाहरण के लिए अलग-अलग होस्ट के लिए अलग-अलग अलर्ट शर्तें सेट करने में सक्षम करेगा।

एकाधिक अलर्ट प्रोफाइल बहुत अच्छे होंगे, लेकिन प्रारंभिक पास के लिए, केवल वही टेम्पलेट चयनकर्ता प्रदान करना जो अलर्ट पैनल में डैशबोर्ड पर उपलब्ध हैं, बहुत सारी समस्याओं का समाधान करेंगे।

मुझे यह भी लगता है कि प्रत्येक चर के लिए उस चर के परिणामों को एक अधिसूचना में एकत्रित करने के लिए एक टॉगल होना चाहिए, यह शायद केवल टेम्पलेट वर्र्स के लिए सक्षम है जिसमें बहु-चयन सक्षम है। यह सूचनाओं की वाचालता को नियंत्रित करने के लिए एक सरल लेकिन प्रभावी तरीका प्रदान करता है - आप एकाधिक संबंधित मीट्रिक के लिए केवल एक बार सूचित करना चाह सकते हैं, लेकिन प्रत्येक होस्ट के लिए सूचित करें जहां कोई मीट्रिक विफल हो रहा है। या, हो सकता है कि आप विफल मीट्रिक के लिए केवल एक बार सूचित करना चाहें, चाहे कितने भी होस्ट प्रभावित हों।

क्या हमारे पास इस बग के लिए कोई लक्षित मील का पत्थर है?

मुझे जटिल प्रश्नों और टेम्पलेट चर प्रश्नों पर अलर्ट करने में कुछ समस्याएं थीं। मुझे आसान कामकाज मिल गया है, जो शायद सुंदर नहीं है, लेकिन यह मेरे उपयोग के मामले के लिए काम करता है।
यह आपके द्वारा बनाए जाने के बाद ही क्वेरी को निकाल रहा है, इसलिए कोई टेम्पलेट चर और कोई #ROW संदर्भ नहीं हैं। यह आपके लिए स्पष्ट हो सकता है, कोई रॉकेट साइंस नहीं है, लेकिन मेरे लिए यह जीवन परिवर्तक था।

मैं क्या करता हूं कि मैं एक प्रश्न तैयार करता हूं:

फिर क्रोम देव टूल्स का उपयोग करके इसे निकालें (लक्ष्य पैरामीटर मान कॉपी करें):

इसे दूसरी पंक्ति में रखें (पहले संपादन मोड को टॉगल करने के लिए स्विच करें):

अलर्ट सेट करें:

वोइला!

@siteshbehera यह कोई बग नहीं है। यह एक सुविधा अनुरोध है।

लेकिन कोई नहीं। वर्तमान में हमारे पास इसके लिए कोई मील का पत्थर नहीं है।

इस सुविधा के लिए आर्टिफिशियल इंटेलिजेंस ग्राफाना प्लगइन को कमिट में शामिल किया जाना चाहिए।

अलर्ट में टेम्प्लेट की प्रतीक्षा भी +1

शुरुआती पोस्ट में संभावित कार्यान्वयन के रूप में प्रदान किए गए कैलिंड के पक्ष में भी मैं बहुत अधिक हूं। ऐसा लगता है कि कितने (मुझे शामिल) टेम्प्लेटेड डैशबोर्ड का उपयोग करते हैं - जहां आपके पास एक डैशबोर्ड है, लेकिन विशिष्ट चीजों को मैन्युअल रूप से देखने के लिए कुछ चर को स्विच/सीमित करता है। मुझे लगता है कि "सर्वर" का उदाहरण - परिवर्तनीय सबसे उपयुक्त हो सकता है। वहां, टेम्प्लेट वैरिएबल (बिना _all_-value) मेरे डैशबोर्ड में "_tab_" के विपरीत कुछ नहीं बन जाएगा - मैं डेटा के विभिन्न सेट देखने के लिए उनके बीच स्विच कर सकता हूं। तब यह मान लेना आसान है कि, अलर्ट सेट करते समय, अलर्ट प्रत्येक संभावित "_tab_" के लिए अलग से मौजूद होगा।

अलर्ट +1 . में टेम्प्लेट का समर्थन करने की प्रतीक्षा कर रहा है

लाइब्रेटो के पिछले उपयोगकर्ता के रूप में जहां अलर्ट करना आंशिक रूप से इस टेम्प्लेटिंग में सक्षम था, मैं समान रूप से आंशिक समाधान के साथ झंकार करना चाहता हूं। लाइब्रेटो में प्रत्येक मीट्रिक एक 'स्रोत' चर के साथ आता है, और ग्राफ़ पर अलर्ट स्वचालित रूप से प्रति स्रोत होंगे।

मुझे लगता है कि एक समान समाधान यहां उठाई गई जरूरतों को पूरा करेगा। अलर्ट बनाते समय आपको 'स्रोत' के रूप में एकल टेम्प्लेट मान चुनने में सक्षम होना चाहिए और इस स्रोत का उल्लेख अलर्ट में किया गया है, अन्य सभी को 'सभी' पर सेट किया जा रहा है। यह समाधान कम से कम कॉम्बिनेटरिक्स समस्या से बचा जाता है यदि आप कई टेम्पलेट चर के उपयोग की अनुमति देते हैं।

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

नमस्ते, मैं निश्चित रूप से इस सुविधा की तलाश कर रहा हूं, क्योंकि पहले के अधिकांश मामलों में, मेरे सभी डैशबोर्ड एकाधिक परिवेशों (कम से कम) का समर्थन करने के लिए टेम्प्लेट की गई क्वेरी का उपयोग कर रहे हैं।

क्या कोई जगह है जहां ग्राफाना के रोडमैप को ट्रैक किया जा रहा है? या किसी भी तरह से हम देख सकते हैं कि क्या भविष्य में सुविधाओं (जैसे यह एक) को जीथब पर मैनटेनर्स को पोक किए बिना भविष्य में (निकट या इतना निकट नहीं) लागू किया जाएगा? :)

अद्भुत वास्तव में इसका बेसब्री से इंतजार है

+1

+1

हमें अभी भी यकीन नहीं है कि यह कैसे करना है।

मुझे लगता है कि चेतावनी के लिए चयनित टेम्पलेट चर का पुन: उपयोग करना खतरनाक होगा क्योंकि लोग केवल एक विकल्प देखना चुन सकते हैं और फिर वापस All या कुछ व्यापक में बदलना भूल सकते हैं। मैं इस तरह के व्यवहार से सुरक्षित महसूस नहीं करूंगा। अलर्ट नियमों को समझना और तर्क करना बेहद आसान होना चाहिए। स्पष्ट नियम > जादू के नियम।

इस समस्या का एक समाधान यह होगा कि प्रत्येक टेम्पलेट चर के लिए दो मान हों। एक डैशबोर्ड में विज़ुअलाइज़ेशन के लिए और दूसरा अलर्ट करने के लिए। इससे अलर्ट में हमेशा व्यापक विकल्प होना संभव होगा और फिर भी ग्राफ़ में कुछ ही विकल्पों का चयन करना संभव होगा। उन मानों को जोड़ना संभव होना चाहिए लेकिन डिफ़ॉल्ट व्यवहार नहीं।

वह समाधान कैसे हर एक काफी बड़ी और जटिल विशेषता होगी।

मेरे पास समाधान के लिए दो प्रस्ताव हैं।

1. एक अल्पकालिक प्रस्ताव एक चेतावनी विकल्प जोड़ना है ताकि रेंडर किए गए गारफ (ईमेल द्वारा भेजा जा रहा है) में केवल मेट्रिक्स जो अलर्ट कर रहे हैं प्रदर्शित किए जा रहे हैं। यह उस अव्यवस्था को हल करेगा जब अलर्टिंग ग्राफ़ में दर्जनों मीट्रिक शामिल हों।

2. एक दीर्घकालिक समाधान यह होगा कि ट्रफ टेम्प्लेट वेरिएबल को पुनरावृत्त किया जाए, ताकि आपके पास प्रत्येक टेम्प्लेट मान संयोजन के लिए एक अलग अलर्ट हो।

जैसा कि मैंने नवंबर में वापस उल्लेख किया था। प्रोमेथियस उपयोगकर्ताओं के लिए केवल 'ऑल' को वैरिएबल वैल्यू के रूप में उपयोग करना पर्याप्त है यदि प्रश्न ठीक से लिखे गए हैं ( some.metric{hostname=~"$Hostname"} )।

शायद लागू करना भी बहुत आसान होना चाहिए।

@bergquist मुझे लगता है कि विकल्प 2 सही दिशा में जा रहा है (जो मैंने https://github.com/grafana/grafana/issues/6557#issuecomment-272588490 में सुझाया है उसका आंशिक कार्यान्वयन), यह बहुत जटिल नहीं लगता है, चूंकि टेम्प्लेट वर चयन को संभालने के लिए कोड डैशबोर्ड के लिए पहले से मौजूद है, और var कॉन्फ़िगरेशन को डुप्लिकेट करने की कोई आवश्यकता नहीं है, बस चयन। मुझे नहीं लगता कि मैं इस सुविधा के पहले पास में डैशबोर्ड चयन को अलर्ट करने के लिए कनेक्ट करने की जहमत उठाऊंगा।

मैंने इसे केवल अलर्ट के लिए एक नई मीट्रिक क्वेरी बनाकर हल किया, टेम्पलेट चर के बिना और इसे अक्षम कर दिया (इसे ग्राफ से बाहर करने के लिए) Grafana संस्करण v4.1.1.1 पर।

अलर्ट में टेम्प्लेट किए गए वर्रों को लागू करने के लिए +1

अलर्ट में टेम्प्लेट किए गए वर्रों को लागू करने के लिए +1

क्या यह ग्राफाना के _all_ संस्करणों को प्रभावित करता है? या यह एक ऐसी सुविधा थी जो पहले उपलब्ध थी? यह मेरे लिए एक तरह का डील ब्रेकर है और पिछले संस्करण को स्थापित करने में कोई आपत्ति नहीं होगी।

@alejandroandreu अलर्टिंग को संस्करण 4 में जोड़ा गया था, इसने कभी भी टेम्प्लेटिंग के साथ काम नहीं किया है।

अलर्ट में टेम्प्लेट किए गए वर्रों को लागू करने के लिए +1

मैं उन संयोजनों को चुनने / दर्ज करने में सक्षम होना चाहता हूं जिनका अलर्ट मूल्यांकन करना चाहिए, क्योंकि मेरे द्वारा चलाए जाने वाले कुछ वातावरण उत्पादन वातावरण नहीं हैं, इसे लागू करने के दो तरीके हैं, पहला अधिक स्पष्ट है, दूसरा है कॉन्फ़िगर करना आसान है।

सभी वांछित संयोजनों को मैन्युअल रूप से दर्ज करें

• यह कॉन्फ़िगरेशन अलर्ट कॉन्फ़िगरेशन पैनल में दिखाया जाना चाहिए

उदाहरण के लिए, यदि मेरे पास 3 टेम्पलेट चर हैं: cloud , region और type , तो मैं इस तरह दिखने वाली एक तालिका भरूंगा:

| बादल | क्षेत्र | टाइप |
|-----------|------------|------|
| एडब्ल्यूएस | यूएस-ईस्ट-1 | उत्पाद |
| एडब्ल्यूएस | यूएस-वेस्ट-1 | उत्पाद |
| नीला | सेंट्रल यूएस | उत्पाद |

तालिका में प्रत्येक पंक्ति के लिए नई पंक्तियाँ और डिलीट बटन डालने के लिए अतिरिक्त पंक्ति होनी चाहिए।

संभावित मान दर्ज करें और ग्राफाना कार्टेशियन उत्पाद की गणना करेगा

• नोट: इस कॉन्फ़िगरेशन को टेम्प्लेट वैरिएबल कॉन्फ़िगरेशन पैनल में दर्ज किया जा सकता है

| बादल | क्षेत्र | टाइप |
|-----------|------------|------|
| एडब्ल्यूएस | यूएस-ईस्ट-1 | उत्पाद |
| नीला | यूएस-वेस्ट-1 | |
| | सेंट्रल यूएस | |

इस इनपुट के लिए जो संयोजन बनाए जाएंगे वे हैं:

• aws us-east-1 prod
• aws us-west-1 prod
• aws Central US prod
• azure us-east-1 prod
• azure us-west-1 prod
• azure Central US prod

लेकिन Grafana पहले चर ( cloud ) को "प्रविष्ट" करके और फिर दूसरे चर ( region ) से उपलब्ध मानों को तब तक फ़िल्टर करके इस स्थिति को संभाल सकता है जब तक कि उसे सभी संभावित संयोजन नहीं मिल जाते (नोट - इसे सभी चरों के लिए पुनरावृत्त रूप से किया जाना चाहिए)। यह तब संभव है जब लोग इस तरह के टैग में प्रश्नों का उपयोग करते हैं:

SHOW TAG VALUES WITH KEY = "REGION" WHERE "CLOUD" =~ /$CLOUD/   

और इस मामले में, उत्पादित संयोजन ठीक होंगे (जो पहले विकल्प में तालिका के समान है):

• aws us-east-1 prod
• aws us-west-1 prod
• azure Central US prod

मुझे उम्मीद है कि मेरे सुझाव मददगार होंगे।

हमारे पास यह मुद्दा (ओपनटीएसडीबी डेटा स्रोत) थोड़ा अलग संदर्भ में है - यदि आप मीट्रिक में डाउनसैंपल अंतराल का चयन करने के लिए टेम्पलेट संस्करण का उपयोग करते हैं, तो अलर्ट क्वेरी त्रुटि 400 के साथ विफल हो जाती है। मैं एक सामान्य समाधान को लागू करने में कठिनाइयों को समझता हूं लेकिन हम हैं अलर्ट को सक्षम करने के लिए विभिन्न मौजूदा डैशबोर्ड को फिर से इंजीनियर करना होगा।

@dbcook एक अलग समस्या की तरह लगता है जिसके लिए आपको शायद एक अलग समस्या दर्ज करनी चाहिए।

टेम्प्लेटिंग वास्तव में एक शानदार विशेषता है, और इसलिए यह सतर्क भी है। बेहतर होगा कि हम उन्हें किसी भी अजीब समाधान के बजाय एक साथ सुचारू रूप से काम करें।

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

क्या आप कृपया ऐसा करने के लिए चरणों का वर्णन करने में सक्षम होंगे? आपकी मदद की बहुत सराहना की जाएगी!

धन्यवाद

@ माथुरज यह नेटवर्क है -> एक्सएचआर टैब। क्या यह अब मदद करता है?

फिर "रेंडर" अनुरोध पर क्लिक करें।

धन्यवाद @tomekit मैं अब इस पृष्ठ को देख सकता हूं हालांकि मुझे "रेंडर" नामक कोई अनुरोध नहीं दिखाई दे रहा है। हालांकि उस क्वेरी के बारे में एक और अनुरोध है जिसे मैं निष्पादित कर रहा हूं, लेकिन इसमें कोई "लक्ष्य" पैरामीटर नहीं है।

कैसे "रेंडर" अनुरोध के बारे में जाने के बारे में कोई सुराग?

@mathurj मुझे "रेंडर" अनुरोध मिलता है, एक बार मेरे डैशबोर्ड पर एक ग्राफ को देखकर और रीफ्रेश (शीर्ष दाएं कोने) पर क्लिक करने के बाद।

कोशिश की, अभी भी मेरे लिए कोई " रेंडर " अनुरोध नहीं है :( यह। @bergquist @torkelo ?

ठीक है साथ काम कर रहा हूँ
some.metric{hostname=\~"$Hostname"}
क्वेरी में ही ठीक है,
लेकिन यह मेरा डेटा स्रोत है जो यहां टेम्पलेट है ...

पर्यावरण=\~"$पर्यावरण"
काम नहीं कर रहा... इसके काम करने का कोई तरीका क्या मुझे कुछ याद आया? या मुझे टेम्पलेट से छुटकारा पाना चाहिए: निराश:

+2

डेटा स्रोत के रूप में प्रोमेथियस का उपयोग करते समय यह सुविधा विशेष रूप से उपयोगी है!

ऊपर बताए गए समान कारणों से मुझे भी इसकी आवश्यकता है। मैं उम्मीद करता हूं कि यह टेम्पलेट परिभाषित पूरे संग्रह पर प्रत्येक लूप के लिए काम करे।

हमें इसकी आवश्यकता है!!! :)

मैं व्यक्तिगत रूप से भी इस सुविधा के समर्थन में हूं। हम लोड परीक्षणों के एक सेट के साथ एक से अधिक सिस्टम का परीक्षण कर रहे हैं जो विलंब मीट्रिक उत्पन्न करते हैं। एक डैशबोर्ड होने के बजाय हम विभिन्न प्रणालियों के लिए डेटा रखने वाले डेटा स्रोतों के बीच स्विच करने के लिए एक चर का उपयोग कर रहे हैं ताकि केवल एक बोर्ड बनाए रखा जा सके और उन्हें स्क्रिप्ट न किया जा सके।
इसलिए अलर्ट में टेम्प्लेट के लिए समर्थन की अत्यधिक सराहना की जाएगी।

+1
हमें इसकी भी जरूरत है

+1
हमें इसकी भी जरूरत है

+1
हमें इसकी भी जरूरत है

क्या मैं पूछ सकता हूं कि इतने सारे लोग +1 उत्तरों को "अंगूठे नीचे" क्यों कर रहे हैं ??

@skygragon यह अनिवार्य रूप से बेकार स्पैम है जब मूल पोस्ट को +1 करने का विकल्प मौजूद है। पहली पोस्ट में बस थम्स-अप आइकन पर क्लिक करें।

टेम्प्लेट वैरिएबल और अलर्टिंग ग्राफाना की सबसे अच्छी विशेषताओं में से 2 हैं।
हालांकि यह देखकर दुख होता है कि वे परस्पर अनन्य हैं......

+1

@bergquist क्या आपकी टीम इस पर फिर से चर्चा कर सकती है और उम्मीद है कि इस पर एक मील का पत्थर रखेगी? यह लगभग 2 वर्षों के लिए सबसे अधिक अनुरोधित विशेषता है और मैं शर्त लगाता हूं कि कुछ उपयोगकर्ता इस सुविधा को पाकर खुश होंगे।

अभी तक कोई अच्छा समाधान प्रस्तावित नहीं किया गया है और हमें अभी भी पूरा यकीन है कि यह एक बुरा विचार है क्योंकि यह दो विशेषताओं को मिला रहा है जो विभिन्न उद्देश्यों की पूर्ति करते हैं। टेंपलेटिंग वेरिएबल का उपयोग डायनेमिक डैशबोर्ड और एक्सप्लोरेशन के लिए किया जाता है। रेगेक्स/वाइल्डकार्ड प्रश्नों के साथ गतिशील होने के लिए अलर्ट नियम पहले से ही बनाए जा सकते हैं। इन दोनों को मिलाना एक भयानक विचार की तरह लगता है, कम से कम इस तरह से जो समझ में आता है और अनुमान लगाया जा सकता है।

हालांकि कुछ सीमित तरीके से इसका समर्थन करने के कुछ अच्छे कारण हैं, लेकिन यह सुनिश्चित नहीं है कि यह अत्यधिक जटिलता और विकास लागत के लायक होने जा रहा है। लेकिन हम विचारों, सुझावों और पीआर के लिए खुले हैं।

मुद्दा यह है कि मेरे पास कुछ सर्वर हैं जिनकी मैं निगरानी करता हूं और वे अमेज़ॅन के माध्यम से गतिशील रूप से बनाए गए हैं, इसलिए एक निश्चित समय में मुझे नहीं पता कि कितने सर्वर ऊपर हैं।

मेरे पास एक टेम्प्लेटेड ग्राफ है जो प्रत्येक सर्वर (उदाहरण के लिए) के लिए सीपीयू दिखाता है, इसलिए मैं वहां भी अलर्ट करना चाहूंगा।

लेकिन आप कह रहे हैं कि मैं वाइल्डकार्ड का उपयोग करके इसे हासिल कर सकता हूं?

@ Yesman85 बेशक, आपके टाइम सीरीज़ स्टोर पर निर्भर करता है। लेकिन अधिकांश नामकरण पैटर्न का पालन करने वाले एकाधिक मीट्रिक को लक्षित करने के लिए ग्लोब/रेगेक्स क्वेरी सिंटैक्स के किसी न किसी रूप का समर्थन करते हैं।

@torkelo मेरा मानना ​​​​है कि यह पहली बार है जब इस स्थिति को सार्वजनिक रूप से बताया गया है। मुझे लगता है कि शायद यहां कुछ गलतफहमी है - मुझे विश्वास नहीं है कि उपयोगकर्ता डैशबोर्ड आउटपुट के लिए चुने गए टेम्पलेट मानों को अलर्टिंग को प्रभावित करने के लिए चाहते हैं, लेकिन इसके बजाय अलर्ट कॉन्फ़िगर करते समय समान टेम्पलेट चयन उपलब्ध हैं।

इस धागे से प्रासंगिक कार्यान्वयन सुझाव:
https://github.com/grafana/grafana/issues/6557#issuecomment -272588490
https://github.com/grafana/grafana/issues/6557#issuecomment -281049641 (विकल्प 2)

साथ ही, संबंधित मुद्दे:
https://github.com/grafana/grafana/issues/6041
https://github.com/grafana/grafana/issues/6553
https://github.com/grafana/grafana/issues/6983
https://github.com/grafana/grafana/issues/7252

इन सीमाओं ने हमें गुस्से में सतर्क करने के लिए ग्राफाना का उपयोग करने में सक्षम होने से रोक दिया है, क्योंकि ऐसा करने का एकमात्र तरीका वर्तमान में या तो अलर्ट के लिए अलग-अलग छिपे हुए प्रश्नों का एक गुच्छा जोड़ना है, या अलर्ट बनाम डिस्प्ले के लिए अलग डैशबोर्ड बनाना है। . दोनों विकल्प एक रखरखाव दुःस्वप्न हैं, और उपयोगकर्ताओं द्वारा आसान निगरानी विन्यास और व्याख्या के लिए ग्राफाना की महान क्षमता को सीमित करते हैं।

मुझे लगता है कि लिब्रेटोस स्रोत-आधारित अलर्टिंग से प्रेरित मेरा सुझाव एक सीमित, समझने योग्य और पूर्वानुमेय समाधान देता है जो उपर्युक्त सभी समस्याओं को कवर करता प्रतीत होता है।

ग्राफाना में यह अलर्ट के लिए एक और केवल एक टेम्प्लेट वेरिएबल का उपयोग करने में सक्षम होने के लिए अनुवाद करेगा और उस वेरिएबल में प्रत्येक मान अपना स्वयं का अलर्ट उत्पन्न करेगा। आप जिन पर अलर्ट बनाना चाहते हैं, उन्हें फ़िल्टर करने के लिए आप उस पर एक रेगेक्स भी जोड़ सकते हैं।

@pdf मैं सहमत हूं कि https://github.com/grafana/grafana/issues/6041 एक बड़ी सीमा है, जिसे हम निश्चित रूप से ठीक करना चाहते हैं लेकिन इस मुद्दे से असंबंधित है। यह बुरा है कि हमने इसे अभी तक ठीक नहीं किया है, मैं सहमत हूं, पिछले कुछ महीनों में हम सतर्क पक्ष पर थोड़े कम कर्मचारी थे, लेकिन यह जल्द ही बदल जाएगा!

@danhallin जो समान नहीं है, ऐसा लगता है कि यह Grafana में एक क्वेरी में अनुवाद करेगा जो आपकी क्वेरी में वाइल्डकार्ड या ग्लोब एक्सप्रेशन का उपयोग करके कई श्रृंखलाओं को लक्षित करता है या केवल टैग के सीमित सेट पर फ़िल्टर करता है? लाइब्रेटो अलर्ट नियमों को डैशबोर्ड से अलग से परिभाषित किया गया है, क्या ऐसा नहीं है कि यह डैशबोर्ड वाइड डेटा फ़िल्टरिंग सुविधा में कैसे अनुवाद कर सकता है?

ऐसा करने का तरीका है कि वर्तमान में काम करने के लिए अलर्ट के लिए अलग-अलग छिपे हुए प्रश्नों का एक समूह जोड़ना है, जो एक रखरखाव दुःस्वप्न है

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

मान लें कि एक क्वेरी में 2 टेम्प्लेट वैरिएबल, $A और $B का उपयोग किया जाता है, जिनमें से प्रत्येक में 50 मान होते हैं। क्या इससे अलर्ट नियम का 2500 बार मूल्यांकन होगा? मेरा मतलब है कि यदि चर "एकल मान" हैं, यानी प्रश्न केवल काम करने के लिए बनाए गए हैं यदि $ ए और $ बी का एक ही मूल्य है तो हमें ऐसा करना होगा। शो स्टॉपर नहीं हो सकता है, हमें यह समझाना होगा कि केवल बहु मूल्य चर समर्थित हैं। संभवतः कई और सीमाएँ और समस्याग्रस्त विवरण हैं जो इस सुविधा को लागू करने और उपयोग करने और समझने में बहुत कठिन बना देंगे

लेकिन मैं इसके खिलाफ 100% नहीं हूं, लगता है कि इसे सीमित तरीके से करने का कोई तरीका हो सकता है (जैसे केवल एक का समर्थन करना
बहु मूल्यवान चर)। कई डेटा स्रोत होने और आपके अलर्ट नियम में डेटा स्रोत चर को लक्षित करने में सक्षम होने का उपयोग मामला भी है ताकि कई डेटा केंद्रों/वातावरणों (जिसमें अलग TSDB है) में उन अलर्ट नियमों का पुन: उपयोग किया जा सके, जिनका उपयोग केस को हल करना होगा। वाइल्डकार्ड के साथ एक मीट्रिक क्वेरी के रूप में डेटा स्रोत टेम्प्लेट वैरिएबल का उपयोग करने से इसे हल नहीं किया जा सकता है।

लेकिन क्या आप ऐसे डैशबोर्ड और ग्राफ़ नहीं बना सकते जो अलर्ट करने पर केंद्रित हों? और अन्वेषण और समस्या निवारण के लिए डैशबोर्ड को कई टेम्पलेट चर के साथ छोड़ दें? मुझे पता है कि शायद ऐसे कई मामले हैं जहां वे समान होंगे इसलिए डुप्लिकेट किए गए काम की तरह लगता है :(

मैंने वास्तव में इस विकल्प को संदर्भित करने के लिए अपनी टिप्पणी संपादित की थी (और कुछ अन्य अलर्ट-संबंधित दर्द-बिंदु मुद्दों को जोड़ें)। जैसा कि आपने पहचाना है, इसका अर्थ है डैशबोर्ड/पैनल निर्माण (और रखरखाव, यदि उन सभी प्रश्नों को अपडेट की आवश्यकता है) को उन टेम्प्लेट विविधताओं की संख्या से गुणा करना, जिन पर आप अलर्ट करना चाहते हैं, और अलर्ट एनोटेशन को उस स्थान से अलग भी कर सकते हैं जहां वे हो सकते हैं में सबसे उपयोगी - अलर्ट एनोटेशन के साथ एक टेम्प्लेटेड डैशबोर्ड सहसंबंध बनाने के लिए बहुत उपयोगी हो सकता है, लेकिन इतना अधिक नहीं यदि आपको कई ब्राउज़र टैब में प्रयास करना और एक्सप्लोर करना है और चीजों को लाइन अप करने का प्रयास करना है।

मान लें कि एक क्वेरी में 2 टेम्प्लेट वैरिएबल, $A और $B का उपयोग किया जाता है, जिनमें से प्रत्येक में 50 मान होते हैं। क्या इससे अलर्ट नियम का 2500 बार मूल्यांकन होगा? मेरा मतलब है कि यदि चर "एकल मान" हैं, यानी प्रश्न केवल काम करने के लिए बनाए गए हैं यदि $ ए और $ बी का एक ही मूल्य है तो हमें ऐसा करना होगा। शो स्टॉपर नहीं हो सकता है, हमें यह समझाना होगा कि केवल बहु मूल्य चर समर्थित हैं। संभवतः कई और सीमाएँ और समस्याग्रस्त विवरण हैं जो इस सुविधा को लागू करने और उपयोग करने और समझने में बहुत कठिन बना देंगे

मुझे लगता है कि यहां दो अलग-अलग मुद्दे हैं। एक _is_ (मेरा मानना ​​है) #6041 से निकटता से संबंधित है, इसमें प्रति श्रृंखला/टेम्पलेट मानों के लिए व्यक्तिगत रूप से अलर्ट स्थितियों का मूल्यांकन करने की इच्छा हो सकती है (कुल टॉगल जिसका मैंने पहले की टिप्पणी में उल्लेख किया था)। अगर हम इसे अभी के लिए अलग रखते हैं, तो मेरा मानना ​​​​है कि इस मुद्दे के बड़े हिस्से को हल करने का आदर्श तरीका प्रति पैनल एकाधिक अलर्ट कॉन्फ़िगरेशन की अनुमति देना है, और डैशबोर्ड आउटपुट के समान ही वैरिएबल इंटरपोलेशन करना है: उपयोगकर्ताओं को सिंगल- या चेतावनी प्रश्नों को कॉन्फ़िगर करते समय बहु-मान टेम्पलेट मान; प्रश्नों को एक बार प्रति अलर्ट कॉन्फिगरेशन में निष्पादित किया जाएगा, जिसमें चयनित मान आबाद होंगे; और परिणामों की ठीक उसी तरह व्याख्या की जाएगी जैसे वे वर्तमान में हैं। जब तक मैं किसी चीज़ को पूरी तरह से गलत नहीं समझ रहा हूँ, मैं इसे जटिलता में उल्लेखनीय वृद्धि के रूप में नहीं देखता, और यह काफी उपयोगकर्ता के अनुकूल होना चाहिए।

केवल अलर्टिंग स्कोप को सीमित करने के लिए टेम्प्लेट मानों का चयन करने की क्षमता अभी भी कई अलर्टिंग कॉन्फिग के बिना उपयोगी होगी (यदि यह उस क्रम में इस कार्यक्षमता को विकसित करने में मदद करती है), लेकिन कई कॉन्फिग के साथ तेजी से अधिक मूल्यवान होगी।

कई डेटा स्रोत होने और आपके अलर्ट नियम में डेटा स्रोत चर को लक्षित करने में सक्षम होने का उपयोग मामला भी है ताकि कई डेटा केंद्रों/वातावरणों (जिसमें अलग TSDB है) में उन अलर्ट नियमों का पुन: उपयोग किया जा सके, जिनका उपयोग केस को हल करना होगा। वाइल्डकार्ड के साथ एक मीट्रिक क्वेरी के रूप में डेटा स्रोत टेम्प्लेट वैरिएबल का उपयोग करने से इसे हल नहीं किया जा सकता है।

प्रति पैनल एकाधिक अलर्ट कॉन्फ़िगरेशन/क्वेरी एकाधिक टीएसडीबी से निपटने के लिए एक विधि प्रदान करेगी, और एक विकल्प समूह चेतावनी प्रश्नों की अनुमति देना हो सकता है, ताकि समूह में सभी प्रश्नों के परिणाम के आधार पर राज्य संक्रमण हो (इसी तरह चीजें वर्तमान में कैसे काम करती हैं) श्रृंखला के लिए)। बहुत जटिल नहीं लगता।

यह निश्चित रूप से एक लोकप्रिय आवश्यकता है.. अब अलर्टिंग प्राप्त करने के लिए हमें आगे बढ़ना पड़ा
ग्रेफाना से दूर और ग्रेफाइट के रेंडर का उपयोग करके हमारा कस्टम समाधान बनाएं
एपीआई कच्चे डेटा .. मुझे नहीं लगता कि गतिशील/टेम्पलेट में अलर्ट का समर्थन करना
डेटा कम से कम ग्रेफाइट का उपयोग कर कोई जटिल है ..

एक और विचार है,. ग्राफ़ाना में अलर्ट अनुभाग क्यों डैशबोर्ड का हिस्सा है
config अगर इसे जटिल माना जाता है। आप इसे अलग करने के लिए दूर ले जा सकते हैं
चेतावनी दृश्य जहां उपयोगकर्ता अपनी गतिशील क्वेरी को इनपुट/कॉन्फ़िगर कर सकते हैं,
अंतराल, मूल्यांकन की स्थिति वहाँ पर .. हो सकता है कि इसका मतलब हम हो
डुप्लीकेट डैशबोर्ड नहीं है.. समझ में आता है?

बीआर,
विश्व ..

23-अगस्त-2017 को सुबह 8:01 बजे, "पीटर फ़र्न" नोटिफिकेशन @github.com ने लिखा:

लेकिन क्या आप ऐसे डैशबोर्ड और ग्राफ़ नहीं बना सकते जो अलर्ट करने पर केंद्रित हों?
और खोज के लिए डैशबोर्ड को कई टेम्पलेट चर के साथ छोड़ दें और
समस्या निवारण? मुझे पता है कि शायद ऐसे कई मामले हैं जहां वे होंगे
ऐसा ही डुप्लिकेट काम की तरह लगता है :(

मैंने वास्तव में इस विकल्प को संदर्भित करने के लिए अपनी टिप्पणी संपादित की थी (और एक जोड़े को जोड़ें
अन्य चेतावनी-संबंधी दर्द-बिंदु मुद्दों के बारे में)। जैसा कि आपने हालांकि पहचान लिया है,
इसका मतलब है कि डैशबोर्ड/पैनल निर्माण को गुणा करना (और रखरखाव, यदि सभी हो)
उन प्रश्नों को अपडेट करने की आवश्यकता है) आपके इच्छित टेम्प्लेट विविधताओं की संख्या के अनुसार
अलर्ट करने के लिए, और स्थान से अलर्ट एनोटेशन को भी अलग करता है
वे सबसे उपयोगी हो सकते हैं - अलर्ट एनोटेशन के साथ एक टेम्प्लेटेड डैशबोर्ड
सहसंबंध बनाने के लिए बहुत उपयोगी हो सकता है, लेकिन इतना नहीं अगर आपको करना है
कई ब्राउज़र टैब में कोशिश करें और एक्सप्लोर करें और चीजों को लाइन अप करने का प्रयास करें।

मान लें कि एक क्वेरी में 2 टेम्प्लेट वैरिएबल, $A और $B का उपयोग किया जाता है, जिनमें से प्रत्येक में 50 . होते हैं
मूल्य। क्या इससे अलर्ट नियम का 2500 बार मूल्यांकन होगा? मेरा मतलब
यदि चर "एकल मान" हैं, यानी प्रश्न केवल काम करने के लिए बनाए गए हैं
यदि $A और $B का एक ही मान है तो हमें वह करना होगा। शो नहीं
स्टॉपर हो सकता है, हमें केवल मल्टी वैल्यू वेरिएबल्स की व्याख्या करनी होगी
का समर्थन किया। शायद कई और सीमाएँ और समस्याग्रस्त विवरण हैं
जो इस सुविधा को लागू करने और उपयोग करने और समझने में बहुत कठिन बना देगा

मुझे लगता है कि यहां दो अलग-अलग मुद्दे हैं। एक है (मेरा मानना ​​है) बारीकी से
#6041 से संबंधित https://github.com/grafana/grafana/issues/6041 , in
कि व्यक्तिगत रूप से अलर्ट स्थितियों का मूल्यांकन करने की इच्छा हो सकती है
श्रृंखला/टेम्पलेट मान (कुल टॉगल जिसका मैंने पहले उल्लेख किया था
टिप्पणी)। अगर हम इसे अभी के लिए अलग रख दें, तो मुझे लगता है कि इसे हल करने का आदर्श तरीका है
इस मुद्दे का बड़ा हिस्सा प्रति पैनल एकाधिक अलर्ट कॉन्फ़िगरेशन की अनुमति देना है, और
वेरिएबल इंटरपोलेशन ठीक उसी तरह करें जैसे डैशबोर्ड के लिए करते हैं
आउटपुट - उपयोगकर्ताओं को सिंगल- या मल्टी-वैल्यू टेम्प्लेट मानों का चयन करने की अनुमति देता है जब
अलर्ट प्रश्नों को कॉन्फ़िगर करना; प्रश्नों को प्रति अलर्ट एक बार निष्पादित किया जाएगा
config, चयनित मूल्यों के साथ आबादी; और परिणाम होगा
ठीक उसी तरह से व्याख्या की गई है जैसे वे वर्तमान में हैं। जब तक मैं स्थूल रूप से नहीं हूँ
कुछ गलत समझ रहे हैं, मैं इसे इसमें उल्लेखनीय वृद्धि के रूप में नहीं देखता
जटिलता, और काफी उपयोगकर्ता के अनुकूल होना चाहिए।

केवल चेतावनी के दायरे को सीमित करने के लिए टेम्पलेट मानों का चयन करने की क्षमता होगी
अभी भी कई अलर्टिंग कॉन्फिग के बिना उपयोगी हो (यदि यह विकसित करने में मदद करता है
यह कार्यक्षमता उस क्रम में), लेकिन तेजी से अधिक मूल्यवान होगी
एकाधिक कॉन्फ़िगरेशन के साथ।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/grafana/grafana/issues/6557#issuecomment-324363795 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAz1sbIwOT7Xb1MwoDYgZCPz182h2ENxks5sbD62gaJpZM4Kwf5K
.

@danhallin जो समान नहीं है, ऐसा लगता है कि यह Grafana में एक क्वेरी में अनुवाद करेगा जो आपकी क्वेरी में वाइल्डकार्ड या ग्लोब एक्सप्रेशन का उपयोग करके कई श्रृंखलाओं को लक्षित करता है या केवल टैग के सीमित सेट पर फ़िल्टर करता है? लाइब्रेटो अलर्ट नियमों को डैशबोर्ड से अलग से परिभाषित किया गया है, क्या ऐसा नहीं है कि यह डैशबोर्ड वाइड डेटा फ़िल्टरिंग सुविधा में कैसे अनुवाद कर सकता है?

अब मैं देख रहा हूं कि मैं जो चर्चा कर रहा हूं वह मूल रूप से इसकी एक प्रति है: https://github.com/grafana/grafana/issues/6041

मैं इस फीचर अनुरोध के समर्थन में हूं।

हम सर्वर को नियमित रूप से स्पिन करते हैं और हमारे पास टेम्प्लेटेड डैशबोर्ड हैं जो सभी होस्ट (मेम, एचडी, सीपीयू, आदि) में सामान्य चीजों को मापते हैं। प्रत्येक संभावित संयोजन के लिए ग्राफ़ वाले "अलर्ट" डैशबोर्ड बनाना बहुत कठिन है, कई वांछित अलर्ट सभी मेजबानों में सामान्यीकृत किए जा सकते हैं। AFAIKT यह मुद्दा इस उपयोग के मामले को संभव बनाने का तरीका मांग रहा है और इसे #6041 में हल नहीं किया जाएगा। जब तक मुझे कुछ याद नहीं आ रहा है।

प्रत्येक संयोजन के लिए ग्राफ़ और अलर्ट बनाना हम प्रस्तावित नहीं कर रहे हैं, बस आप अलर्ट क्वेरी वाइल्डकार्ड या रेगेक्स का उपयोग करती है ताकि यह सभी होस्ट आदि को कवर कर सके। फिर आपके पास एक अलर्ट और ग्राफ़ है जिसे अलर्ट करने के लिए ट्यून किया जा सकता है और इसके साथ प्रतिस्पर्धा नहीं की जा सकती है समस्या निवारण और गतिशील फ़िल्टरिंग के लिए आवश्यकताएं।

हमारे उपयोगकेस के लिए हमारे पास घटनाओं की रीयलटाइम प्रोसेसिंग प्रदान करने वाले कई (संभावित) क्षणिक उदाहरण हैं - यदि कुछ एप्लिकेशन जेनरेट मेट्रिक्स 0 पर गिर जाते हैं तो हमें सतर्क रहने की आवश्यकता होगी। हालांकि, अगर इंस्टेंस हटा दिए जाते हैं या रुक जाते हैं तो उनके पास अभी भी नामित मीट्रिक होगा उनके साथ जुड़ा हुआ है जो सीधे वाइल्डकार्ड खोज में दिखाई देता है जिससे झूठे अलर्ट उत्पन्न होते हैं।

"सिंपल JSON डेटासोर्स" से उत्पन्न एक टेम्प्लेटेड, मल्टी-वैल्यू वेरिएबल (सभी पर सेट) का उपयोग करके इसे प्राप्त किया है, जिसमें सत्य का एक स्रोत है कि कौन से इंस्टेंसेस चल रहे हैं - सभी पूरी तरह से काम कर रहे हैं। काश, जैसे ही मैंने अलर्ट को सक्षम करने का प्रयास किया, मुझे इस सुविधा अनुरोध का नेतृत्व किया गया :)

सुनिश्चित नहीं है कि हमारा विशेष उपयोग-मामला कितना अनूठा है, लेकिन मैं टेम्पलेट के उपयोग के बिना इस पर सतर्क करने के किसी अन्य तरीके के बारे में निश्चित नहीं हूं - अभी के लिए, हमें ग्राफाना के बाहर इन मुद्दों के लिए सतर्क रहना जारी रखना होगा (जो शर्म की बात है) - हम बहुत भारी Grafana उपयोगकर्ता हैं!)

+1

तो एक मामला जहां हमारे पास इनमें से कोई भी समस्या नहीं है, जहां टेम्पलेट चर एक स्थिर प्रकार है। उदाहरण के लिए, हमारे पास उस डैशबोर्ड पर डेटा को किसी विशेष संसाधन तक सीमित करने के लिए एक स्थिर चर पर निर्भर कई डैशबोर्ड हैं (इसका कारण यह है कि हमने एक बहु-मूल्य चर का उपयोग नहीं किया है क्योंकि प्रत्येक डैशबोर्ड अलग-अलग सेटअप को सही ठहराने के लिए पर्याप्त है लेकिन काफी करीब है एक "टेम्पलेट" डैशबोर्ड को सही ठहराने के लिए)। कम से कम इस मामले में (निरंतर चर) वर्तमान चेतावनी व्यवहार के बारे में कुछ भी बदलने की जरूरत नहीं है।

इस विषय के बारे में कोई खबर?

नमस्ते,

क्या यह सुविधा मिलने की कोई उम्मीद है? मुझे आश्चर्य है कि अन्य प्रणालियों में यह सुविधाएं कैसे हैं क्योंकि वे भी टेम्पलेटिंग का उपयोग कर रहे होंगे क्योंकि जब हम एजेंट स्थापित करते हैं तो यह स्वचालित रूप से पोर्टल पर दिखाई देता है और इसके लिए अलर्टिंग भी सेट की जा सकती है। (यह न्यू रेलिक के साथ मेरा अनुभव है)।

@ विश्वनाथ मुझे अलर्ट करने के लिए अलग सेक्शन रखने का दृष्टिकोण पसंद आया (यदि इसे ग्राफ पैनल में रखना जटिल है) जहां हम अपने प्रश्नों को केवल अलर्ट करने के लिए रख सकते हैं। इस तरह हमारे उपयोगकर्ता प्लेसहोल्डर पैनल (चेतावनी के लिए प्रयुक्त) नहीं देखेंगे।

अतिरिक्त शोर के लिए क्षमा करें, लेकिन यह वास्तव में ग्रैफाना में एक बहुत अच्छी विशेषता होगी।

+1, बहुत ही महत्वपूर्ण विशेषता!

इसके अलावा, अगर मुझे टेम्प्लेट वैरिएबल को हटाने के लिए प्रोमेथियस मेट्रिक क्वेरी एक्सप्रेशन को संशोधित करने की अनुमति देता है, तो यह बिल्कुल भी संभव नहीं है। इसलिए, मुझे लगता है कि प्रोमेथियस + ग्राफाना के उत्पादन पर उतरने के लिए यह सुविधा सबसे महत्वपूर्ण है!

वैसे भी, कृपया टीम प्राथमिकता पर विचार कर सकती है, धन्यवाद!

5.0 जल्द ही दरवाजे से बाहर निकलने के साथ, मुझे अगली रिलीज श्रृंखला के दौरान कुछ महत्वपूर्ण ध्यान दिए जाने पर ध्यान देना अच्छा लगेगा। जीथब प्रतिक्रियाओं को देखते हुए, चेतावनी-संबंधी कमियों को उपयोगकर्ताओं से सबसे अधिक रुचि दूर-दूर तक दिखाई देती है।

मुझे पता है कि यूआई/यूएक्स जटिलता चिंताओं के कारण इन चीजों से निपटने में कुछ अनिच्छा हुई है, हालांकि मुझे विश्वास नहीं है कि ये चिंताएं जरूरी हैं। क्या ऐसा कुछ है जो हम उपयोगकर्ता के रूप में कर सकते हैं जो वास्तविक कोड के साथ पुल-अनुरोधों से कम, इन मुद्दों को आगे बढ़ाने या योजना बनाने/डिजाइन करने में मदद कर सकता है?

@torkelo इसने मुझे टैग का उपयोग करके अपने सभी मेजबानों के लिए अलर्ट सेट करने में मदद की है और अब मेरे प्रत्येक अलर्टिंग ग्राफ में टैग के संयोजन द्वारा बनाई गई कई श्रृंखलाएं हैं। सब कुछ ठीक काम कर रहा लग रहा था। लेकिन डॉक्स और अन्य मुद्दों के माध्यम से जाने पर मैंने महसूस किया कि यदि ग्राफ के भीतर की किसी भी श्रृंखला ने पहले से ही सतर्क स्थिति ले ली है तो अन्य श्रृंखलाओं के लिए अलर्ट ट्रिगर नहीं होंगे यदि वे भी सीमा पार करते हैं।

वह फिर से सीमाएं हैं।

धन्यवाद।

इस सुविधा के बारे में कोई खबर?

इस सुविधा को जोड़ने के लिए नए योगदानकर्ता के लिए क्या प्रयास हैं?

+1

कृपया चेतावनी सूचनाओं के लिए टेम्प्लेट चरों का उपयोग करने की अनुमति दें।
+1

+1

हम हल होने की उम्मीद करते हैं।

+1

मैं यहां एक मरे हुए घोड़े को नहीं मारना चाहता, लेकिन हमारे पास एक ही समस्या है, और मैं कुछ संदर्भ देना चाहता हूं कि मौजूदा प्रस्ताव सभी परिस्थितियों में क्यों काम नहीं करते हैं। मेरे पास वर्कअराउंड के लिए कुछ विचार भी हैं, लेकिन वर्कअराउंड को पर्याप्त बनाने में मदद करने के लिए हमें _some features_ की आवश्यकता क्यों है।

नीचे दिए गए सभी परिदृश्यों के लिए, हम एक टेम्पलेट वाले चर का उपयोग कर रहे हैं: $env

"क्यों न केवल अलर्ट करने वाले डैशबोर्ड बनाएं?"

हम सिर्फ उत्पादन ही नहीं, बल्कि दो अलग-अलग वातावरणों के बारे में सचेत करना चाहते हैं। इसलिए अब हमें _कम से कम_ 3 अलग-अलग स्थानों में एक ही मीट्रिक की आवश्यकता होगी (सभी मीट्रिक के साथ समस्या निवारण डैशबोर्ड, न कि केवल वह मीट्रिक जिसके लिए हम अलर्ट करते हैं; उत्पाद अलर्ट डैशबोर्ड; एकीकरण अलर्ट डैशबोर्ड)। यह बहुत जल्दी हाथ से निकल सकता है, और उपयोगकर्ता त्रुटि के लिए प्रवण होता है।

उतना ही महत्वपूर्ण, यह अलर्ट से स्वचालित एनोटेशन से होने वाले अधिकांश लाभ को समाप्त कर देता है। अगर मुझे अपने खोजपूर्ण डैशबोर्ड से अपने अलर्ट डैशबोर्ड पर आगे और पीछे जाना है, तो यह देखने के लिए कि कोई ईवेंट कब शुरू हुआ और कब समाप्त हुआ, यह बहुत थकाऊ होने वाला है।

प्रयास किया समाधान

इससे निजात पाने के लिए हमने जो किया है, वह यह है कि हमने अपने डैशबोर्ड में डुप्लिकेट मेट्रिक्स _विशेष रूप से अलर्ट करने के लिए_ जोड़ दिए हैं। इसलिए यदि कोई मीट्रिक है जिस पर हम अलर्ट करना चाहते हैं, तो हम पैनल पर जाते हैं और उन अलर्ट के लिए स्पष्ट मीट्रिक जोड़ते हैं (और उन्हें छिपाते हैं)।

किसी दिए गए पैनल के लिए हमारी श्रृंखला सूची जिसे सतर्क करने की आवश्यकता है, वह निम्न की तर्ज पर दिखेगी:

गैर-टेम्पलेट श्रृंखला के साथ छुपा के रूप में चिह्नित किया गया। फिर अलर्टिंग टैब में, हम _these_ सीरीज के लिए थ्रेसहोल्ड सेट करते हैं, न कि वेरिएबल सीरीज के लिए।

इस समाधान के साथ समस्याएं

हालांकि यह बहुत अच्छा काम नहीं करता है। उदाहरण के लिए:

जैसा कि आप देख सकते हैं, अलर्ट पैनल हमें यह निर्दिष्ट करने की अनुमति नहीं देता है कि _कौन सा वातावरण_ अलर्ट कर रहा है - इसलिए हमें यह पता लगाने के लिए अलर्ट में ड्रिल करना होगा कि इस समय कौन सा वातावरण बोर हो गया है। हालाँकि, इसके लिए एक आसान समाधान केवल विवरण को अलर्ट हिस्ट्री पैनल के रूप में वर्बोज़ होने की अनुमति देना हो सकता है जो राज्य संक्रमण दिखाता है:

यह कम से कम कुछ हद तक मददगार है, लेकिन इस पैनल में भी इस बात का कोई संकेत नहीं है कि कौन सा अलर्ट Healthy पर वापस चला गया है (उपरोक्त स्क्रीनशॉट का विवरण हमारे द्वारा श्रृंखला पर सेट किए गए उपनाम से लिया गया था यदि कोई सोच रहा है कि कैसे कम से कम दिखाने के लिए इतना कुछ पाने के लिए)।

चीजें जो इस विशिष्ट टिकट का समाधान होने तक मदद करेंगी

• अलर्ट के लिए टाइप किए गए विवरण के बजाय श्रृंखला उपनाम प्रदर्शित करने के विकल्प की अनुमति दें (इस तरह उपनाम कम से कम $variable निर्दिष्ट कर सकता है जिसके लिए यह चेतावनी दे रहा है)
• राज्य के संक्रमण को वापस स्वस्थ होने दें ताकि श्रृंखला का उपनाम भी दिखाया जा सके (उपरोक्त इतिहास स्क्रीनशॉट में)
• किसी दिए गए पैनल के लिए सक्रिय अलर्ट (श्रृंखला उपनाम का उपयोग करके) के लिए एक किंवदंती मान की अनुमति दें

चीजें मुझे यकीन नहीं है कि कैसे ठीक किया जाए

ग्राफ़ पर एनोटेशन जिनमें एकाधिक परिवेशों/चरों के लिए अलर्ट कॉन्फ़िगर किए गए हैं:

इससे हम पैनल में जाए बिना वास्तव में यह नहीं बता सकते कि कौन सा अलर्ट फायरिंग कर रहा है। किंवदंती सुझाव इसे स्पष्ट करने में मदद कर सकता है, लेकिन एनोटेशन के लिए बहुत कुछ नहीं करता है यदि सही $env का चयन नहीं किया गया है (उपरोक्त चित्र में, int सतर्क है, लेकिन prod डैशबोर्ड पर चयनित चर है, इसलिए हम prod का उपयोग करके ग्राफ़ के शीर्ष पर int अलर्ट से एनोटेशन प्रदर्शित कर रहे हैं।

+1

मैं भी सहमत हूं :)

कृपया इस मुद्दे को +1 करना बंद करें। यह अनावश्यक स्पैम ईमेल उत्पन्न करता है। जीथब मुद्दे पर प्रतिक्रिया जोड़ने की क्षमता कुछ समय के लिए मौजूद है, और 429 से अधिक लोगों ने यह पता लगाया है कि सदस्यता लेने वाले सभी को स्पैम करने के बजाय प्रारंभिक टिप्पणी को कैसे पसंद किया जाए।

कृपया हमें वास्तव में इस सुविधा की आवश्यकता है, हम टेम्प्लेटिंग का उपयोग करना चाहेंगे, लेकिन हमारे मामले में एक स्पष्ट चेतावनी प्रणाली होना सबसे महत्वपूर्ण है। इसलिए इसे हल करने के लिए हम अपने डैशबोर्ड में टेम्प्लेट करने से बच रहे हैं... यह एक गड़बड़ है।

मैं सहमत हूँ और यह सुविधा हमें बहुत मदद करेगी !!!!

+1 कृपया

हमें इसकी आवश्यकता है

+1 कृपया। इसकी वास्तव में जरूरत है।

@bergquist @torkelo क्या हम +1 स्पैम को रोकने के लिए कृपया इस मुद्दे को लॉक कर सकते हैं?