Grafana: [फ़ीचर अनुरोध] प्रति ग्राफ़ एकाधिक अलर्ट

ठोस उपयोग का मामला: मैंने अपने ऐप को प्रत्येक प्रमुख कार्य के लिए प्रोमेथियस में हिस्टोग्राम रिकॉर्ड करने के लिए यंत्रित किया है (उदाहरण के लिए जहां बाहरी HTTP कॉल या डिस्क I/O होता है) और इनमें से कोई भी धीमा होने पर अलर्ट करना चाहता हूं।

वर्तमान में मुझे इसके लिए डमी ग्राफ को परिभाषित करना है क्योंकि ग्राफ और अलर्ट के बीच 1: 1 संबंध है। अलर्ट को ग्राफ़ के समान ही परिभाषित रखना कहीं अधिक तार्किक होगा।

और आप इसे एक प्रश्न में परिभाषित नहीं कर सकते हैं?

नहीं; OR शर्तों की एक श्रृंखला अपरिष्कृत है, और अलर्ट का एकल नाम स्पष्ट रूप से अलर्ट के सटीक कारण की पहचान नहीं कर सकता है। मैं निश्चित रूप से Some part of service X is failing की तर्ज पर अलर्ट नहीं भेजना चाहता - कॉल पर इंजीनियर मेरे दोस्त नहीं होंगे ...

तो अलर्ट के लिए अलग-अलग पैनल रखना अधिक समझ में आता है, यदि आप अलग अलर्ट नियम का नाम और संदेश इत्यादि चाहते हैं।

हां ठीक यही मैं इस समय कर रहा हूं। क्या निकट भविष्य में प्रति ग्राफ एकाधिक अलर्ट लागू करने की कोई संभावना है ताकि मैं इस समाधान से दूर जा सकूं?

यह बहुत कम संभावना है

शायद अगर इसकी भारी मांग हो :)

हाहा ठीक है - मैं देखूंगा कि क्या मैं गुस्से में भीड़ को सरसराहट कर सकता हूं;) गंभीरता से ', ईमानदारी के लिए धन्यवाद।

ठीक है हमारे पास दो की भीड़ है :-) मैं कई टैंकों में ईंधन के स्तर का रेखांकन कर रहा हूं और प्रत्येक टैंक के लिए कम ईंधन अलर्ट सेट करना चाहता हूं।

और प्रत्येक टैंक में अलग-अलग सीमाएँ या सूचनाएं होती हैं?

बिल्कुल। एक 285 गैल हीटिंग तेल टैंक है। जब वह टैंक 70gals से नीचे चला जाता है, तो मैं "हीटिंग ऑयल लो" अलर्ट सेट करना चाहता था। दूसरा 500 गैल प्रोपेन टैंक है, इसके लिए मैं "प्रोपेन लो" अलर्ट चाहता था जब यह 100 गैल से कम हो। मैंने प्रत्येक के लिए सिंगलस्टैट्स की स्थापना की लेकिन अलर्ट सिंगलस्टैट में उपलब्ध नहीं हैं।

मेरे पास माध्यिका और 90वें शतमक मीट्रिक वाला ग्राफ़ है। मैं प्रत्येक पर अलर्ट प्राप्त करना चाहता/चाहती हूं। ऐसा करने के लिए, मुझे प्रत्येक के लिए एक ग्राफ बनाना होगा। फिर, अगर मुझे प्रत्येक के लिए चेतावनियां और महत्वपूर्ण अलर्ट चाहिए, तो मुझे प्रत्येक के लिए दूसरा ग्राफ बनाना होगा।

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

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

हाय टोरकेलो!

मुझे इस सुविधा के लिए कई "पसंद" मिले! क्या हम अगले रियासत में प्रवेश करेंगे =) ?

@rmsys शायद किसी बिंदु पर, इसे यूएक्स परिप्रेक्ष्य और कोड जटिलता (और यूएक्स जटिलता) परिप्रेक्ष्य से हल करने में समय लगेगा, यह अभी तक किसी रोडमैप पर नहीं है, लेकिन हो सकता है कि अगले साल अलर्टिंग इंजन अधिक परिपक्व हो और इसके लिए एक यूएक्स डिज़ाइन काम किया गया हो बाहर

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

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

साथ ही, अलर्ट के अलग-अलग राज्यों को ट्रैक करना हमेशा पसंद नहीं किया जाता है (क्योंकि अंतिम उपयोगकर्ता को अलग-अलग राज्यों के पीछे विवरण जानने की आवश्यकता होगी) बनाम केवल यह जानना कि अलर्ट ट्रिगर किया गया है या नहीं।

मुझे यकीन नहीं है कि मैं समझता हूं कि आपका क्या मतलब है। क्या आप विस्तार से समझा सकते हैं?

क्या आप बता सकते हैं कि प्रति ग्राफ़ कितने अलर्ट काम करेगा और कैसे दिखेगा? एनोटेशन क्या कहेंगे, और पैनल शीर्षक शो के बगल में हरा/लाल दिल (यदि 2/5 चेतावनी नियम जहां फायरिंग कहते हैं)?

क्या आप अलर्ट नियमों के बीच कुछ साझा करना चाहते हैं या क्या वे पूरी तरह से अलग-थलग होंगे (एक ही ग्राफ़ पैनल में रहने और संभवतः समान प्रश्नों का संदर्भ देने के अलावा)।

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

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

सिंगलस्टैट पैनल में अलर्ट नियमों के लिए @rssalerno का समर्थन इस मुद्दे से असंबंधित लगता है।

@ एलेक्स-फिलिप्स आपको लगता है कि व्यक्तिगत अलर्ट नियमों को और अधिक लचीला बनाकर इसे हल किया जा सकता है।

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

क्या आप बता सकते हैं कि प्रति ग्राफ़ कितने अलर्ट काम करेगा और कैसे दिखेगा? एनोटेशन क्या कहेंगे, और पैनल शीर्षक शो के बगल में हरा/लाल दिल (यदि 2/5 चेतावनी नियम जहां फायरिंग कहते हैं)?

मुझे लगता है कि एकाधिक अलर्ट नियमों को व्यक्तिगत रूप से एनोटेट किया जाएगा। दिल रंग-कोडित हो सकते हैं। अलर्ट/पैनल में अंतर के लिए नियमों को नाम देना होगा।

क्या आप अलर्ट नियमों के बीच कुछ साझा करना चाहते हैं या क्या वे पूरी तरह से अलग-थलग होंगे (एक ही ग्राफ़ पैनल में रहने और संभवतः समान प्रश्नों का संदर्भ देने के अलावा)।

आम तौर पर मुझे नहीं लगता, हालांकि मुझे संदेह है कि समूहों को एक साझा सीमा की आवश्यकता होगी, और नाम अगर वे लागू किए गए थे (प्रति https://github.com/grafana/grafana/issues/6557#issuecomment-324363795)।

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

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

सिंगलस्टैट पैनल में अलर्ट नियमों के लिए @rssalerno का समर्थन इस मुद्दे से असंबंधित लगता है।

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

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

मुख्य रूप से, मैं चाहता हूं कि यह #6557 और #6553 का समर्थन करे, और @alex-phillips के समान कई थ्रेसहोल्ड के लिए। उदाहरण के लिए, हमारे पास #6557 के लिए एक उपयोग-मामला अलग-अलग परिवेशों ( production , beta , dev , आदि) के लिए अलग-अलग अलर्ट करना है, जो कई थ्रेसहोल्ड के साथ संयुक्त है हमारी अधिकांश समस्याओं का समाधान। यदि कई नियमों के बिना ऐसा करने का कोई बेहतर तरीका है, तो यह मेरे लिए स्पष्ट नहीं है।

@torkelo

क्या आप बता सकते हैं कि प्रति ग्राफ़ कितने अलर्ट काम करेगा और कैसे दिखेगा? एनोटेशन क्या कहेंगे, और पैनल शीर्षक शो के बगल में हरा/लाल दिल (यदि 2/5 चेतावनी नियम जहां फायरिंग कहते हैं)?

मुझे @pdf . द्वारा सुझाया गया तरीका पसंद है

इसके अलावा, एनोटेशन दिखाने का तरीका मौजूदा मामले जैसा ही होगा, जहां आपके पास > 1 शर्तों के साथ अलर्ट नियम है (प्रत्येक की एक अलग सीमा है)। और पैनल शीर्षक के बगल में हरे/लाल दिल को लाल रंग के रूप में दिखाया जाएगा (यदि कम से कम एक चेतावनी है जो फायरिंग कर रही है), वर्तमान परिदृश्य के समान जहां अलर्ट नियम की कम से कम एक शर्त सत्य का मूल्यांकन करती है)। और शायद शीर्षक में लाल दिल के साथ संख्या (2/5) भी दिखाएं।

क्या आप अलर्ट नियमों के बीच कुछ साझा करना चाहते हैं या क्या वे पूरी तरह से अलग-थलग होंगे (एक ही ग्राफ़ पैनल में रहने और संभवतः समान प्रश्नों का संदर्भ देने के अलावा)।

हमारे अधिकांश उपयोग के मामलों में, ये नियम उनके बीच कुछ भी साझा नहीं करेंगे और प्रश्न भी अलग हैं

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

वे अलर्ट पेज में अलग नियमों के रूप में दिखाई देंगे। अलर्ट टैब में संभवत: परिभाषित अलर्ट की एक सूची होगी। ठीक है, हमें इस टैब पर विशिष्ट अलर्ट नियम को हाइलाइट/विस्तारित करने की आवश्यकता होगी, जब अलर्ट नियम url (अलर्ट आईडी या इंडेक्स को कैप्चर करना चाहिए) को अधिसूचना से एक्सेस किया जाता है। ऐसा लगता है कि आसानी से हल किया जा सकता है।

अलर्ट सूची पैनल में कोई बदलाव नहीं होगा। यह उन सभी को अलग-अलग दिखाता है। अर्थात्, प्रत्येक अलर्ट अलग है। बस इतना ही कि इसे इसी पैनल में रखा गया है.

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

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

स्प्लंक में हमारे पास उच्च/निम्न अलर्ट होते हैं। यदि ग्राफाना में कई अलर्ट उपलब्ध हैं, तो हम बस एक ही खोज का उपयोग करेंगे, वे एक ही खोज के लिए अलग-अलग सीमाएँ हैं।

इस सुविधा के लिए +1।

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

इस सुविधा के लिए +1।

श्रेणियों और गंभीरता से संबंधित कुछ अन्य मुद्दों को पढ़ते हुए यहां आया हूं। मैं सहमत हूं कि सभी अलर्ट कार्रवाई योग्य होने चाहिए। लेकिन "सुबह में इस पहली चीज़ को ठीक करें" अलर्ट और "$400/घंटे सलाहकार ASAP को कॉल आउट करें" अलर्ट के बीच एक अंतर है।

जैसा कि कई लोगों ने उल्लेख किया है, यह चेतावनी और गंभीर थ्रेसहोल्ड द्वारा हल किया जाने वाला सबसे आम है।

तकनीकी रूप से इसे कई तरीकों से लागू किया जा सकता है, लेबल, प्रति पैनल कई अलर्ट, प्रति अलर्ट कई थ्रेशोल्ड आदि।

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

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

मुझे लगता है कि अधिकांश उपयोगकर्ता हालांकि काफी सरल चेतावनी/क्रिट अलगाव से संतुष्ट होंगे।

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

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

इसके अलावा हम बाएं और दाएं y अक्ष पर दो मेट्रिक्स ओवरले (वॉल्यूम और सकल मार्जिन) के साथ प्रत्येक चयनित उत्पाद के लिए एक ग्राफ दोहराने के लिए टेम्पलेटिंग वर्र्स का उपयोग कर रहे हैं। यह अलर्ट का उपयोग करने के किसी भी अवसर को समाप्त कर देता है क्योंकि अलर्ट क्वेरी हमारे IN ($sku) के लिए $sku सूची चर नहीं उठा रही है।

इसके आसपास काम करने के लिए मैंने एक और क्वेरी B करने की कोशिश की है, जो हमारी रुचि रखने वाले सभी स्कस को देखने के लिए सिर्फ टेम्प्लेट क्वेरी चलाता है और उसे सीधे अलर्ट क्वेरी में डालता है IN (SELECT skus from interested_product_table) । हालाँकि यह हमें प्रत्येक ग्राफ़ में सभी मीट्रिक के लिए प्रत्येक ग्राफ़ के लिए अलर्ट भेजना शुरू कर देता है जिसका अर्थ है कि हमें मिलता है:

Email Alert 1 - metric1,metric2,metric3
Email Alert 2 - metric1,metric2,metric3
Email Alert 3 - metric1,metric2,metric3
Email Alert 4 - metric1,metric2,metric3

Email Alert 5 - metric4
Email Alert 6 - metric4
Email Alert 7 - metric4
Email Alert 8 - metric4

उदाहरण के लिए जो काफी स्पैमी है।

पूर्ण सहमत हैं कि यह सुविधा आवश्यक है और पूरी तरह से असहमत है कि सभी सूचनाएं कार्रवाई योग्य होनी चाहिए।

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

मेरे दो सेंट में फेंकना - मुझे यह सुविधा प्राप्त करना अच्छा लगेगा।

मुझे अलग-अलग दिल या अलग-अलग रंग के दिलों की भी आवश्यकता नहीं है (ग्राफ पर किसी भी अलर्ट के लिए लाल ठीक है), यह ईमेल सूचनाएं हैं जिनके लिए मुझे अलग-अलग नाम चाहिए।

कृपया इस सुविधा को जोड़ें। इस तरह के उपयोग के मामले के लिए,
एक ही ग्राफ से
अगर मूल्य> एक्स -> सुस्त
अगर मूल्य> एक्स + वाई -> पीडी

हमारे यहां कार्रवाई योग्य अलर्ट की एक नीति है, जहां अलर्ट को यदि संभव हो तो कार्रवाई निर्दिष्ट करनी चाहिए। मेट्रिक के बहुत कम या बहुत ज़्यादा होने के आधार पर हमें अलग-अलग कार्रवाइयां करनी होती हैं.

उदाहरण के लिए: आरडीएस सीपीयू बहुत कम है? व्यवहार के लिए यहां अन्य ढेर की जांच करें। बहुत ऊँचा? उदाहरण को स्केल करें।

अन्य लोगों की तरह, हम भी अलग-अलग सीमा पर विभिन्न प्रकार के अलर्ट करना पसंद करते हैं।

@jdblack के समान मैं एक उच्च जल चेतावनी स्तर और एक उच्च जल आपातकालीन स्तर चाहता हूं। मुझे पता है कि मैं इसे दो प्रश्नों के साथ कर सकता हूं लेकिन यह उतना सहज या चालाक नहीं है।

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

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

मैं सेंसर नेटवर्क के लिए Grafana + Influx का उपयोग करने का प्रयास कर रहा हूं। अलर्ट को छोड़कर, डैशबोर्ड बहुत अच्छा काम करता है। जब सेंसर123 एक निश्चित सीमा से अधिक हो जाता है तो मुझे सतर्क रहने की आवश्यकता होती है। इसके लिए मुझे किसी चार्ट की जरूरत नहीं है, बस एक अलर्ट की जरूरत है। इसके अलावा, मुझे संभावित रूप से हजारों सेंसर रखने की आवश्यकता है। यदि "कोई" सेंसर थ्रेशोल्ड से अधिक है तो मैं अलर्ट सेट कर सकता हूं लेकिन मुझे यह जानने की जरूरत है कि कौन सा अलर्ट कर रहा है। मेरे पास एक विशिष्ट सेंसर को देखने के लिए टेम्प्लेट वैरिएबल के साथ डैशबोर्ड सेटअप है, लेकिन मैं टेम्प्लेट वैरिएबल के लिए अलर्ट नहीं जोड़ सकता। परीक्षण के लिए, मैं बस एक अतिरिक्त डैशबोर्ड में मुट्ठी भर सेंसर के लिए कुछ अलर्ट सेट करता हूं, जिसे कोई नहीं देखता है, लेकिन आगे बढ़ने पर मुझे अलर्ट के लिए एक अलग समाधान की आवश्यकता होती है।

@torkelo , इस पर किसी भी आधिकारिक टिप्पणी के एक साल बाद - बस सोच रहा था कि क्या कोई अपडेट है जिसे अब साझा किया जा सकता है कि चेतावनी प्रणाली कुछ समय के लिए जंगली में है?

@MakoSDV आपको उस उपयोग के मामले के लिए संधारित्र का उपयोग करने पर विचार करना चाहिए।

इस सुविधा के लिए +1; यह वास्तव में दो-स्तरीय अलर्टिंग के लिए भी उपयोगी होगा (उदाहरण: कुछ> एक्स = पीला अलर्ट, कुछ> वाई = रेड अलर्ट)

अलर्ट को अधिक लचीला बनाने के लिए +1

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

यह शर्म की बात है कि यह मुद्दा छोड़ दिया गया प्रतीत होता है। क्या किसी को पता है कि हम इस पर डेवलपर का ध्यान कैसे आकर्षित कर सकते हैं?

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

@ गैभने ने लिखा:

क्या किसी को पता है कि हम इस पर डेवलपर का ध्यान कैसे आकर्षित कर सकते हैं?

शायद समर्थन के लिए भुगतान करें? ऐसा लगता है कि किसी भी गंभीर चेतावनी-संबंधी कमियों के लिए कोई संसाधन उपलब्ध नहीं हैं, हालांकि वे वर्षों से उच्चतम जीथब उपयोगकर्ता-रेटेड मुद्दे बने हुए हैं।

इस अनुरोध के लिए +1।

जब हम किसी बाहरी सेवा के लिए अनुरोध करते हैं तो हम अपने ऐप में एक काउंटर सेट अप करते हैं, हम समय के साथ एकीकृत करते हैं कि हमने ग्राफाना में एक ग्राफ बनाया है।

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

इसके लिए भी +1।

वर्तमान में ग्राफ़ के लिए दो अलग-अलग अलर्ट सेट करने का प्रयास कर रहा है:

1. _चेतावनी_ स्तर तक पहुंचने वाले डेटा के लिए सुस्त संदेश
2. _महत्वपूर्ण_ स्तर तक पहुंचने वाले डेटा के लिए पेजर ड्यूटी अलर्ट

वर्तमान में मेरी समझ में, इसे पूरा करने के लिए मुझे एक ही डेटा के दो अलग-अलग ग्राफ़ बनाने होंगे। मेरे लिए एक ही ग्राफ़ पर कई अलग-अलग अलर्ट कार्य करना अधिक समझ में आता है।

@torkelo क्या 2019 में इसके लिए योजनाओं के बारे में कोई अपडेट है?

+1

हमारे पास ऐसे डैशबोर्ड हैं जो प्रदर्शित वातावरण के बीच स्विच करने के लिए एक चर का उपयोग करके एकाधिक क्लाइंट/वातावरण के लिए एक ही माइक्रोसर्विसेज की निगरानी करते हैं।

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

यह बहुत अच्छा होगा, भले ही प्रत्येक अलर्ट के लिए एक अलग क्वेरी का उपयोग करने की आवश्यकता हो, और केवल क्वेरी को ग्राफ़ पर दिखाई न देने के लिए सेट करना आवश्यक हो।

आप जो वर्णन कर रहे हैं @itonlytakeswon वह भी https://github.com/grafana/grafana/issues/6557 से संबंधित प्रतीत होता है, इसलिए आप उसे भी ट्रैक करना चाहेंगे :)

यह कैसे पहले से ही एक विशेषता नहीं है?

@jsterling7 हमारे वांछित उपयोग के मामले का पूरी तरह से वर्णन करता है।

@torkelo कोई भी फीचर रिलीज

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

ऐसा लगता है कि इसकी उच्च मांग है, मैं उनमें से एक हूं जिसे इस प्रकार की सुविधा की आवश्यकता है। मुझे ग्राफाना लगभग पसंद है फिर अचानक यह सीमा मुझे बंद कर देती है।

मेरा उपयोग मामला यहां संदर्भित और #6557 अंक के समान है। हमारे पास एक ही टेम्प्लेट डैशबोर्ड में कई इलास्टिक्स खोज क्लस्टर हैं। मैं व्यक्तिगत रूप से उनके लिए अलर्ट ट्रिगर करना चाहता हूं और जैसा कि अब है, मैं केवल हार्डकोड किए गए प्रश्नों के साथ एक ग्राफ नहीं बना सकता, लेकिन इस अलर्ट को काम करने के लिए प्रत्येक क्लस्टर के लिए एक ग्राफ बनाना होगा ...

+1, इससे हमारे पर्यावरण को बहुत मदद मिलेगी! यहां तक ​​​​कि प्रति ग्राफ़ सेटअप में केवल एक पीला/लाल 'दिल' दो-अलर्ट, जहां यदि लाल ट्रिगर होता है, तो यह पीले रंग को ओवरराइड करता है।

+1 यह बहुत अच्छा होगा, यह सोचकर कि प्रत्येक शर्त को वैकल्पिक कॉन्फ़िगर करने योग्य अलर्ट अधिसूचना की अनुमति देना कितना छोटा होगा और यदि किसी विशिष्ट स्थिति के लिए नहीं तो यह एक डिफ़ॉल्ट अधिसूचना संदेश पर वापस आ सकता है ... इसे बनाने का सबसे तेज़ तरीका मुझे लगता है ?

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

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

+1 मुझसे भी - आश्चर्य है कि यह पहले से मौजूद नहीं है!

+1

मुझे लगता है कि यह सुविधा टेम्प्लेट क्वेरी समर्थन की सीमा के साथ-साथ चलती है।

मैंने प्रश्नों के साथ कुछ प्रोमेथियस फेड ग्राफ स्थापित किए हैं जिनमें उदाहरण के लिए टेम्पलेट हैं, और लेबल टाइप करें। मैं टेम्पलेट मानों के लिए अदृश्य प्रश्न बनाकर टेम्पलेट समस्या को हल करता हूं।

मैं प्रत्येक टेम्पलेट मान के लिए अलग अलर्ट चाहता हूं, लेकिन मैं एक सामान्य एक-आकार-फिट-सभी क्रिया + संदेश के साथ एक अलर्ट तक सीमित हूं। मैं अपने सभी प्रश्नों पर सतर्क करने के लिए एक लंबी या सूची का उपयोग कर सकता हूं लेकिन यह कच्चा लगता है।

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

एकाधिक अलर्ट के लिए समर्थन जोड़ने से ऐसा लगता है कि यह संभावित रूप से टेम्प्लेट क्वेरी अलर्ट का समर्थन करने वाला पहला कदम हो सकता है।

+1। इसका होना आवश्यक है!

+1 यह अत्यंत उपयोगी है

@torkelo "तो अलर्ट के लिए अलग पैनल रखना अधिक समझ में आता है, यदि आप अलग अलर्ट नियम नाम और संदेश इत्यादि चाहते हैं।"

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

@torkelo "तो अलर्ट के लिए अलग पैनल रखना अधिक समझ में आता है, यदि आप अलग अलर्ट नियम नाम और संदेश इत्यादि चाहते हैं।"

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

बिल्कुल। प्रति पैनल एकाधिक अलर्ट के लिए +1

हमारी स्थिति में, हम बैटरी में सेल वोल्टेज (प्रति बैटरी 16 सेल) माप रहे हैं। हम तुलना के लिए एक पैनल पर 16 श्रृंखला का ग्राफ बनाते हैं और प्रत्येक बैटरी के लिए एक अलग पैनल रखते हैं।

पैनल (ग्राफ) के लिए एक भी अलर्ट बहुत मददगार नहीं है। हमें वास्तव में प्रति सेल कम से कम एक अलर्ट सेट करने की क्षमता की आवश्यकता है ताकि अलर्ट ई-मेल इंगित करे कि कौन सा सेल वोल्टेज के मामले में सीमा से बाहर है।

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

फिलहाल हमें सेल सीरीज़ के लिए 16 x या स्टेटमेंट्स प्रोग्राम करने हैं, और (पुनः) - इस प्रक्रिया में प्रत्येक सेल के लिए सीमाओं को परिभाषित करें - सेट अप करने के लिए दर्दनाक और संशोधित करने के लिए एक रखरखाव दुःस्वप्न।

आदर्श रूप से हमें ग्राफ़ पैनल पर प्रत्येक कक्ष के लिए चेतावनी और महत्वपूर्ण घटनाओं की प्रोग्रामिंग भी करनी चाहिए।

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

इस पर किसी भी अद्यतन? मुझे लगता है कि यह सुविधा बड़ी तैनाती के लिए जरूरी है। खासकर जब से हम भंडारण उपयोग दिखाने के लिए एक एकल ग्राफ रखना चाहते हैं, हम 70%, 80% आदि के लिए अलर्ट चाहते हैं, जिसमें बड़ी मात्रा में ग्राफ नहीं होना चाहिए।

मैंने अभी इस पर ठोकर खाई है और मुझे आश्चर्य है कि ऐसा करने का कोई तरीका नहीं है डी:

मैं यहां देख रहा हूं https://github.com/grafana/grafana/pull/20822#issuecomment -561047900 कि इसे भविष्य में लागू नहीं किया जाएगा और ऐसा लगता है कि अलर्ट पूरी तरह से डैशबोर्ड से हट जाएंगे।

यह डैशबोर्ड जेसन मॉडल को कैसे प्रभावित करेगा? क्या कोई इस बारे में बात कर सकता है कि इस बारे में और खबरें कब आएंगी?

यह एक बहुत ही आवश्यक विशेषता थी। आगामी स्थिति पर अभी तक कोई अपडेट?

प्रति पैनल एकाधिक अलर्ट के लिए +1

इस सुविधा के लिए +1।

यह एक बहुत ही आवश्यक विशेषता थी। आगामी स्थिति पर अभी तक कोई अपडेट?

इस सुविधा की जरूरत है।

3 साल बाद.. कोई हमें बता सकता है कि इसे लागू क्यों नहीं किया गया (अनुरोधों की संख्या के बावजूद)?
यह इसे लागू करने के लिए एक तकनीकी बाधा के कारण है? इसे खारिज कर दिया गया है? यह काम में है?
जैसा कि पहले कहते हैं, एक 'बुनियादी विशेषता' लगता है।
उदाहरण: मेरे पास 200 सर्वरों वाला एक डैशबोर्ड और एक श्रृंखला है, यदि मैं एक अलर्ट जोड़ता हूं:
200 सर्वरों में से एक मर चुका है: अच्छा मुझे नाम के साथ अलर्ट प्राप्त होता है
ओह, एक नया सर्वर समाप्त हो गया है: कोई अलर्ट नहीं (या डैशबोर्ड को रीफ्रेश करने या 24 घंटे के बाद रिमाइंडर की प्रतीक्षा करने की आवश्यकता है..)
चेक करने के लिए चेकबॉक्स की तरह जोड़ना संभव नहीं है ताकि हमें सीरी में पंक्ति द्वारा सतर्क किया जा सके (बजाय 'पूर्ण' सेरी द्वारा)?
अगर कोई देव, ग्राफाना टीम प्रतिक्रिया के लिए जवाब दे सकती है ...

क्या आप चेतावनी देने के लिए प्रोमेथियस और डैशबोर्ड करने के लिए ग्राफाना छोड़ देना चाहेंगे?

@beasta अगर आपको ग्राफाना को काम करने के लिए सिर्फ एक और टूल सेट करना है, तो ग्राफाना का उपयोग करने का कोई मतलब नहीं है। हम डेटाडॉग में जा रहे हैं क्योंकि यह कार्यक्षमता वहां मौजूद है और यह केवल एक उपकरण है।

@ ऐनी-नेल्सन आपको मेट्रिक्स गैदरर, मेट्रिक्स स्टोरेज सेट करना होगा और उचित सेटअप के लिए ग्राफाना काम करने के लिए इसके चारों ओर एचए के साथ एक नाटक है, है ना?
डेटाडॉग सिर्फ एक उपकरण नहीं है, यह सिर्फ इसे आपसे छुपाता है और एक अच्छा काम करता है, आप अभी भी डेटाडॉग के साथ ग्राफाना का उपयोग कर सकते हैं: https://grafana.com/grafana/plugins/grafana-datadog-datasource

@beasta मुझे यकीन नहीं है कि वे उपकरण क्या हैं, इसलिए मुझे नहीं लगता कि हम उनका उपयोग कर रहे हैं। हमारे मेट्रिक्स Influx को भेजे जाते हैं, हम उन्हें Grafana के बजाय Datadog पर भेजने जा रहे हैं। जब मैं उन्हें सीधे भेज सकता हूं तो मैं ग्रेफाना के माध्यम से डेटाडॉग को चीजें क्यों भेजूंगा? मैं कम से कम संभव उपकरणों का उपयोग करना चाहता हूं।

@ ऐनी-नेल्सन आप अपने ऐप में मेट्रिक्स पुश को लागू कर सकते हैं, लेकिन कभी-कभी यह बहुत उपयोगी होता है कि कुछ सिस्टम मेट्रिक्स को भी धक्का दिया जाए ताकि आप जान सकें कि आपके डिस्क और अन्य स्टफ के साथ क्या हो रहा है। मेट्रिक्स संग्रहकर्ता, कुछ स्थानीय डिमन जो इस तरह की चीजें कर रहे हैं, जैसे टेलीग्राफ, एकत्रित या धाराप्रवाह से मेरा यही मतलब है।
आपके सेटअप में इनफ्लक्स - एक ऐसी चीज है जो मेट्रिक्स को स्टोर करती है और कच्चे डेटा के लिए वेब यूआई फ्रंटएंड के रूप में ग्राफाना के माध्यम से खोज करने की एक समृद्ध क्षमता प्रदान करती है जो आपको अपने डेटा में हेरफेर करने के लिए कुछ आंतरिक प्रवाह क्वेरी भाषा का उपयोग करके एक मौका देती है।
Influx की जगह Datadog होने की स्थिति में ये ठीक उसी तरह काम करता है. यहां ग्राफाना - डेटा तक पहुंच के लिए एक यूआई है। एक सामान्य सेटअप में। तो यह आपके डेटा के साथ कुछ नहीं करता है, यह सिर्फ इसे ग्राफ़ में प्रस्तुत करता है। तो आप वैसे भी उन्हें सीधे भेजें।
जैसा कि आपने वर्णन किया है कि आप इनलक्स के साथ काम कर रहे हैं, आपके द्वारा वर्णित समस्या को हल करने के लिए आपको कैपेसिटर या फ्लक्स का उपयोग करने पर विचार क्यों नहीं किया जाता है क्योंकि उन्होंने बहुत अधिक पहुंच क्षमताएं प्रदान की हैं तो ग्राफाना आपको कभी भी पेशकश कर सकता है और वे अभी भी उसी विक्रेता से हैं और जैसे एक ही वातावरण। फ्लक्स भी इनफ्लक्स शिपमेंट पैकेज का एक हिस्सा है।

यह वास्तव में मददगार होगा।

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

बीटीडब्ल्यू, पंक्ति द्वारा अलर्ट रखने के लिए इस चेकबॉक्स को जोड़ने से क्या रोका जा सकता है? शायद एक स्पष्टीकरण समझने में मदद कर सकता है।

@beasta यह वास्तव में अजीब लगता है कि आप किसी को ग्राफाना का उपयोग न करने के लिए मनाने की कोशिश कर रहे हैं।

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

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

@beastea मैं आपकी रक्षात्मकता के कारण मानूंगा कि आपने ग्राफाना के लिए काम किया है। यह सुविधा बहुत से लोगों के लिए प्रासंगिक है, और सुविधा अनुरोध पर वैकल्पिक उत्पादों का सुझाव देना अनुपयोगी है और इस चर्चा को पटरी से उतार रहा है। यह स्टैक ओवरफ्लो नहीं है।

क्या हर कोई इसे बंद कर सकता है? आप संभावित रूप से सैकड़ों लोगों को स्पैमिंग कर रहे हैं, यह उत्पादक नहीं है।

अतिरिक्त शोर सभी के लिए खेद है।

@torkelo क्या आप हमें इस सुविधा अनुरोध पर एक अपडेट देने में बहुत बुरा मानेंगे? यह विषय कई वर्षों से खुला है और जैसा कि आप देख सकते हैं, इसमें अभी भी रुचि है। कम से कम यह इस विषय पर मनमुटाव और अनावश्यक बकबक को कम करने में मदद कर सकता है ताकि किसी प्रकार का "आधिकारिक" उत्तर प्राप्त किया जा सके कि यह वर्तमान रोड-मैप में शामिल है या नहीं। चीयर्स।

यह एक और #6041 जो समान है पूरी तरह से अनदेखा कर दिया गया है। मुझे आश्चर्य है क्योंकि।

हमारे लिए यह समझ में आता है, क्योंकि हमारी ऑप्स टीम हमारे प्लेटफॉर्म में नए एकीकरण दर्ज करती है। हम स्वचालित रूप से ग्रेफाइट को मेट्रिक्स भेजना शुरू करते हैं। और ग्राफाना में केवल एक पैनल यह सब देखता है।

जब कई सिस्टम डाउन हो जाते हैं, तो हमें केवल पहले वाले के लिए अलर्ट मिलता है। और बहुत व्याख्यात्मक भी नहीं।

जब एक नीचे होता है, और दूसरा भी बाहर जाता है, तो अलर्ट फिर से सक्रिय नहीं होता है।

इसके लिए मेरे पास उपयोग का मामला प्रोमेथियस और ग्राफाना के माध्यम से मल्टी विंडो मल्टी बर्न रेट अलर्ट को परिभाषित करने के लिए है। https://landing.google.com/sre/workbook/chapters/alerting-on-slos/ पर Google SRE हैंडबुक में परिभाषित एसएलओ की निगरानी के लिए इस प्रकार के अलर्ट रखने का यह एक मानक अभ्यास है।

एक परम आवश्यक, कृपया इस पर अनुवर्ती कार्रवाई करें ..

मैं प्रोमेथियस अलर्टिंग से ग्रेफाना अलर्टिंग में भी चला गया हूं और मैं इसके लिए पूरी तरह से उत्सुक हूं!

क्या कोई व्यक्ति जिसने ग्राफाना पर काम किया है, उसे संबोधित करने के लिए ज्ञात चुनौतियों की सूची बना सकता है?

अरे @torkelo , शायद आप हमें इस मामले में जानकारी दे सकते हैं!

यह देखकर निराशा हुई कि 7.x में अलर्ट करने में कोई सुधार नहीं हुआ - पिछला सुझाव कि अलर्टिंग को पूरी तरह से हटा दिया जाना था, मुझे आशा से नहीं भरता है, लेकिन अगर ऐसा होता तो निश्चित रूप से इसे 7.x में हटा दिया जाता तार्किक सुधार के पैमाने को देखते हुए?

इसे लागू करना इतना कठिन क्यों है, इस बारे में किसी प्रकार का अपडेट प्राप्त करना बहुत अच्छा होगा, बस हम यह समझ सकें कि _why_ यह मुद्दा इतने लंबे समय से खुला है।

@torkelo नमस्ते।
मुझे एक ही जरूरत है - एक ही ग्राफ पर एक मीट्रिक के लिए एकाधिक अलर्ट लेकिन एकाधिक सर्वरों पर नजर रखी जा रही है।
मेरे पास '/' विभाजन पर खाली स्थान के परिभाषित मीट्रिक के साथ ~ 100 सर्वर हैं (उदाहरण के लिए - जैसा कि मेरे पास ऐसे दसियों मीट्रिक हैं)। और यदि '/' पर खाली स्थान 20% से कम हो जाता है, तो मुझे प्रत्येक सर्वर पर एकल अद्वितीय अलर्ट सूचना प्राप्त करने की आवश्यकता है।
वर्तमान में ऐसा नहीं होगा, अगर, उदाहरण के लिए सर्वर 2 अलर्ट फेंक देगा, और जब लोग समस्या को हल करने पर काम कर रहे हैं, तो सर्वर 4 एक ही अलर्ट फेंक देगा - हमें अधिसूचित नहीं किया जाएगा। या क्या मुझे कुछ कार्यक्षमता याद आ रही है?

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

मैं उन सभी को धन्यवाद और सराहना करता हूं जो सलाह या मदद कर सकते हैं।

@torkelo नमस्ते।
मुझे एक ही जरूरत है - एक ही ग्राफ पर एक मीट्रिक के लिए एकाधिक अलर्ट लेकिन एकाधिक सर्वरों पर नजर रखी जा रही है।
मेरे पास '/' विभाजन पर खाली स्थान के परिभाषित मीट्रिक के साथ ~ 100 सर्वर हैं (उदाहरण के लिए - जैसा कि मेरे पास ऐसे दसियों मीट्रिक हैं)। और यदि '/' पर खाली स्थान 20% से कम हो जाता है, तो मुझे प्रत्येक सर्वर पर एकल अद्वितीय अलर्ट सूचना प्राप्त करने की आवश्यकता है।
वर्तमान में ऐसा नहीं होगा, अगर, उदाहरण के लिए सर्वर 2 अलर्ट फेंक देगा, और जब लोग समस्या को हल करने पर काम कर रहे हैं, तो सर्वर 4 एक ही अलर्ट फेंक देगा - हमें अधिसूचित नहीं किया जाएगा। या क्या मुझे कुछ कार्यक्षमता याद आ रही है?

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

मैं उन सभी को धन्यवाद और सराहना करता हूं जो सलाह या मदद कर सकते हैं।

यह मुद्दा 2017 के बाद से खोला गया है (और @torkelo का उत्तर है "यह अलर्ट के लिए अलग पैनल रखने के लिए अधिक समझ में आता है" (जब हमारे पास 600 सर्वर होते हैं तो सर्वर/अलर्ट द्वारा पैनल बनाना बहुत अच्छा होता है) )।

ऐसा लगता है कि ग्राफाना से दूसरे समाधान में माइग्रेट करना या बनाए रखने के लिए कई उपकरणों के साथ एक गज़ फ़ैक्टरी बनाना ही एकमात्र तरीका है।

@anthosz - बहुत बहुत धन्यवाद। मुद्दा यह है कि पर्यावरण हमारा नहीं बल्कि ग्राहकों का है, इसलिए मेरे लिए यह एक बहुत ही आसान काम होगा कि मैं अपने नेतृत्व के लिए इस पर जोर दूं और आगे उसके लिए ग्राहकों को "इसके लिए भुगतान नहीं करूंगा" .
हालांकि, कम से कम मेरे पास कुछ तथ्य हैं जो कहते हैं कि 'ऐसे ट्रिगर्स/अलार्म को व्यवस्थित करने की कोई संभावना नहीं है - इस तरह'।

एक बार फिर धन्यवाद।

_जॉइन (आवाज, गाना बजानेवालों)_
मेरे पास एक सर्किट पर एक एयर पंप की निगरानी करने वाला एक करंट सेंसर है, 1.5 एम्प्स नॉमिनल और एक एफ्लुएंट पंप 10 एएमपीएस नॉमिनल है। एयर पंप 24/7 चलता है, एफ्लुएंट पंप टैंक के स्तर के आधार पर मांग पर चलता है। जब सब कुछ ठीक होता है तो धारा (I) या तो 1.5A होती है जब बहिःस्राव पंप बंद होता है या 11.5A जब बहिःस्राव पंप चालू होता है।

पहली आम विफलता है वायु पंप का जलना जो (Imax <0.5A या Iavg 9A से 11A के बीच) द्वारा सतर्क किया जाता है जो वायु पंप के मरने पर या तो कोई करंट या बहिर्वाह पंप के चलने का पता लगाता है। सिस्टम की विफलता से बचने के लिए इसे 48 घंटों के भीतर संबोधित किया जाना चाहिए। डेटा प्रति मिनट 1 अंक है, 90 मिनट के बाद अलर्ट।

उसी ग्राफ पर दूसरा वांछित अलर्ट है (Imax> 14A या Iavg 2A से 9A के बीच) जो यह इंगित करता है कि पंप कब बंद हो गया है या हवा-इन-लाइन है जब इसे पंप किया जाना चाहिए। यह एक बहुत अधिक जरूरी अलर्ट है जिसे 3 घंटे के भीतर संबोधित करने की आवश्यकता हो सकती है इसलिए 5 मिनट के बाद अलर्ट आदर्श होगा।

दोनों अलर्ट लोरा पर डेटा भेजने वाले एक ही रिमोट करंट सेंसर से हैं। एकाधिक अलर्ट मुझे एक ही सेंसर के लिए डैशबोर्ड क्वेरी की नकल करने से रोकने में आसान बना देंगे।

@torkelo एकाधिक ग्राफ़ कई उपयोगकर्ताओं के लिए स्केलेबल नहीं है। यह जोड़ने के लिए इतनी सरल बात लगती है और मैं उत्सुक हूं कि आप लोग इस पर विचार क्यों नहीं कर रहे हैं?

शायद अगर इसकी भारी मांग हो :)

अरे @torkelo , आप क्या बड़ी मांग मानते हैं? आपकी टिप्पणी में 96 टिप्पणियाँ और 250 "लाइक" बहुत बड़ी हैं? यह 8वां सबसे अधिक टिप्पणी की गई खुली सुविधा अनुरोध है और केवल एक बंद सुविधा अनुरोध में इससे अधिक टिप्पणियां हैं। यह अधिक :+1: प्रतिक्रियाओं के साथ तीसरा खुला सुविधा अनुरोध भी है। रोडमैप दर्ज करने के लिए क्या आवश्यक है?

@torkelo मुझे एक बहुत ही सरल केस परिदृश्य मिला है।

जब मूल्य एक (अलग) सीमा से अधिक हो जाता है, तो अलर्ट की तुलना में, यदि मान थ्रेशोल्ड से नीचे चला जाता है, तो मुझे एक अलग अलर्ट की आवश्यकता होती है।

यहाँ एक अलग परिदृश्य है। जब मैं स्वस्थ सर्वर गिनती की निगरानी करता हूं, तो मुझे अलग-अलग अलर्ट की आवश्यकता होती है जब मैं 1 सर्वर खो देता हूं (वैध पुनरारंभ जो कोई समस्या नहीं है जब तक कि इसमें 10 मिनट से अधिक समय न हो), बनाम 5 सर्वर खोना।

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

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

बस मेरे 2 सेंट।

नमस्कार!

यहां झंकार करना चाहता था हमें (Spotify) इसकी भी जरूरत है।

वर्तमान में हम अपने स्वयं के अलर्टिंग इंजन को ग्रैफ़ाना से सोर्सिंग अलर्ट, और अलर्ट प्रति-टाइम्सरीज चलाते हैं। वर्तमान में हम प्रति टाइमसीरीज अलर्ट एनोटेशन को वापस ग्राफाना में धकेलते हैं।

तो, यूआई के संदर्भ में, अलर्ट करने के लिए पहली बार पैनल/अलर्ट को "अलर्टिंग" स्थिति में जाने का कारण बनता है, और प्रत्येक बाद की चेतावनी बस ढेर हो जाती है (राज्य इतिहास कई अपडेट "अलर्टिंग" को दिखाएगा, और इसी तरह, एकाधिक परिवर्तन वापस "ठीक है")

हमें इसकी "ज़रूरत" है क्योंकि इस तरह हमने हमेशा अलर्ट किया है, इसलिए प्रति-समय अलर्ट से दूर जाना ~ 10K अलर्ट के लिए एक बड़ा सामाजिक परिवर्तन होगा। हम ग्रैफ़ाना नेटिव अलर्टिंग का उपयोग करना और उसे अपनाना चाहते हैं और इसका समर्थन करने के लिए अपने डेटा स्रोत को अपडेट करना चाहते हैं।

यहां झंकार करना चाहता था हमें (Spotify) इसकी भी जरूरत है।

क्या आपने ग्राफाना एंटरप्राइज का भी इस्तेमाल किया? शायद डेवलपर्स को मदद/प्रेरित कर सकते हैं =)

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

वर्तमान में हम अपने स्वयं के अलर्टिंग इंजन को ग्रैफ़ाना से सोर्सिंग अलर्ट, और अलर्ट प्रति-टाइम्सरीज चलाते हैं। वर्तमान में हम प्रति टाइमसीरीज अलर्ट एनोटेशन को वापस ग्राफाना में धकेलते हैं।

@sjoeboo यहां थोड़ा सा विषय है लेकिन क्या सार्वजनिक रूप से कुछ भी उपलब्ध है?

@vbichov अभी तक नहीं , हम अलर्टिंग इंजन को ओपनसोर्स करना चाहते हैं, हालांकि समय सीमा प्रवाह में है। मुझे यकीन है कि मैं एनोटेशन के माध्यम से अलर्ट की प्रति-टाइम्सरी ट्रैकिंग सक्षम करने के लिए हमारे (शायद ही आदर्श) आंतरिक कांटे पर एक पैच साझा कर सकता हूं।

एक नोट, अलर्टिंग इंजन, अभी हमारे TSDB के लिए विशिष्ट है (https://github.com/spotify/heroic)

इस सुविधा के लिए +1। यह चेतावनी/महत्वपूर्ण जैसा कुछ है। जीवन के बदतर होने से पहले हम एक चेतावनी प्राप्त करना चाहते हैं। फिर हमें तत्काल कार्रवाई करने के लिए महत्वपूर्ण अलर्ट मिलना चाहिए।

मुझे आश्चर्य है कि उपयोगकर्ताओं द्वारा 3 साल के अनुरोध के बाद भी इसे लागू नहीं किया गया है।

एकाधिक पैनल (प्रत्येक अलर्ट के लिए एक) बनाने के बाद एक डैशबोर्ड बंद हो जाता है और नए अलर्ट जोड़ना जितना जटिल होना चाहिए उससे कहीं अधिक जटिल बना देता है

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

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

क्या यह किया गया है?
ग्राफाना संस्करण = 4.x

अब Grafana संस्करण 7.x पर चला जाता है और मैंने यह सुविधा नहीं देखी

क्या यह किया गया है?
ग्राफाना संस्करण = 4.x

अब Grafana संस्करण 7.x पर चला जाता है और मैंने यह सुविधा नहीं देखी

इतना भोला

इस सुविधा के लिए +1।
एक ही मीट्रिक पर मैं चाहूंगा

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

इस समूह द्वारा कई सरल सुविधाओं को लगातार अस्वीकार किया जाता है, कई अन्य सुविधा अनुरोधों की जांच करें..यह कुछ बुनियादी लगता है।

मैं एक और उदाहरण दूंगा।

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

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

इसे डिस्क स्थान के उपयोग जैसी सरल चीज़ पर भी लागू किया जा सकता है।
यदि डिस्क का उपयोग 80% तक पहुँच जाता है, और डिस्क उपयोग 90% तक पहुँच जाता है, तो मैं एक चेतावनी भेजना चाहता हूँ। मेरे प्रत्येक डिस्क के लिए एकाधिक ग्राफ़ करना उचित नहीं है।

और मैं इस टिप्पणी को नहीं समझता कि UI में यह मुश्किल है। आपके पास पहले से ही कुछ ऐसा ही है जो डैशबोर्ड की एक सूची है। जब आप अलर्ट टैब पर क्लिक करते हैं, तो इसे नीचे "नया अलर्ट बनाएं" बटन के साथ नाम से अलर्ट नियमों की एक सूची दिखानी चाहिए। प्रत्येक अलर्ट नियम के दाईं ओर एक "संपादित करें", "अक्षम करें" या "हटाएं" विकल्प होना चाहिए। अलर्ट पर क्लिक करके, या संपादन बटन पर, यह आपको मौजूदा संपादन पृष्ठ पर ले जाएगा जो कि उस विशिष्ट चेतावनी नियम के लिए दिखाया गया है।

मेरे प्रत्येक डिस्क के लिए एकाधिक ग्राफ़ करना उचित नहीं है।

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

अविश्वसनीय है कि यह सुविधा अभी तक लागू नहीं की गई है, इस मुद्दे की भारी प्रतिक्रिया के साथ।

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

डमी प्लॉट बनाना एक समाधान है, समाधान नहीं। यह बुनियादी लगता है!

+1 आवश्यक विशेषता

+1

ठीक यही स्थिति ओपी की है। बुनियादी सुविधा जिसे पहले ही लागू किया जाना चाहिए था।

क्या लोग इस थ्रेड के मुद्दे को बिना किसी मूल्य के स्पैमिंग करना बंद कर सकते हैं?

रुचि का संकेत देने के लिए मुद्दे के शीर्ष पर प्रतिक्रियाओं का उपयोग करें।

https://github.com/grafana/grafana/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc एक अनुरक्षक के लिए असीम रूप से अधिक उपयोगी है जो यह दावा करता है कि कौन से मुद्दे स्पैमिंग करने वाले लोगों की तुलना में "लोकप्रिय" हैं हर कोई इनबॉक्स और जीथब सूचनाओं के साथ ई-मेल करता है जो केवल समस्या विवरण को देखकर पहले से ही स्पष्ट है।

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

@thomasf "क्या लोग कुछ भी मूल्य जोड़े बिना इस थ्रेड मुद्दे को स्पैम करना बंद कर सकते हैं?" - जैसा तुमने किया था?

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

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

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

इसे प्राप्त करने का सबसे अच्छा तरीका योगदान करना है (या शायद ग्राफाना एंटरप्राइज के लिए भुगतान करना)

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

इल गियोर्नो मेर 14 ओटी 2020 एली अयस्क 15:35 थॉमस फ्रोसमैन <
नोटिफिकेशन@github.com> हा स्क्रिटो:

क्या लोग इस थ्रेड के मुद्दे को बिना कुछ जोड़े स्पैम करना बंद कर सकते हैं
मूल्य?।

रुचि का संकेत देने के लिए मुद्दे के शीर्ष पर प्रतिक्रियाओं का उपयोग करें।

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

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

मैं जितनी राशि _any_ सॉफ़्टवेयर पर खर्च करने को तैयार हूं, वह ग्राहक सेवा के उस स्तर के समानुपाती है जिसका मैं अनुमान लगा सकता हूं कि मुझे मेरे निवेश के लिए प्रदान किया जाएगा। चाहे वह एक ओपन सोर्स उत्पाद हो जो "पेड सपोर्ट" या वाणिज्यिक उत्पाद पेश करता हो, यह वास्तव में मायने नहीं रखता।

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

पुल अनुरोध करें या अपना स्वयं का कांटा बनाए रखें

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

अंत में, जब तक धागा बंद/बंद नहीं होता है, मुझे अपने मन की बात न कहने का कोई कारण नहीं दिखता। यदि आपको यह पसंद नहीं है तो आपको सदस्यता समाप्त करने की अनुमति है। मुझे वास्तव में इस की सापेक्ष गैरबराबरी के बारे में विलाप करने वाले लोगों को पढ़ने में मज़ा आता है। मैं

चेतावनी एनजी (नेक्स्टजेन) 8 के लिए नियोजित चेतावनी एकल अलर्ट परिभाषा से कई अलर्ट उदाहरणों का समर्थन करेगी। तो, प्रोमेथियस जैसे सिस्टम के साथ host=* जैसा कुछ प्रति होस्ट अलर्ट बनाएगा।

https://github.com/grafana/grafana/issues/6983#issuecomment -712915673 में जोड़े गए एकल आँकड़ों के संदर्भ में इसके बारे में कुछ सामान्य जानकारी

हम अभी भी डिजाइन और प्रोटोटाइप कर रहे हैं, लेकिन चीजों पर कुछ शुरुआती विचारों का जवाब देने के लिए:

प्रति ग्राफ एकाधिक अलर्ट

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

साथ ही, अलर्ट के अलग-अलग राज्यों को ट्रैक करना हमेशा पसंद नहीं किया जाता है (क्योंकि अंतिम उपयोगकर्ता को अलग-अलग राज्यों के पीछे विवरण जानने की आवश्यकता होगी) बनाम केवल यह जानना कि अलर्ट ट्रिगर किया गया है या नहीं।

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

1. एक आईआरएम जैसे पेजरड्यूटी या अलर्टमैनेजर के साथ अलर्टिंग एनजी का उपयोग करें जो अलर्ट इंस्टेंस के समूह को संभाल सकता है।
2. अपनी क्वेरी को बड़े स्कोपिंग आयाम द्वारा समूह में बदलें। तो उदाहरण के लिए, यदि क्वेरी cluster=* के बजाय host=*,cluster=* (या डेटा स्रोतों की तरह एसक्यूएल के लिए समूह)। वैकल्पिक रूप से, यदि डेटा स्रोत ऐसा नहीं करता है, तो मैं समूह/पिवट संचालन के लिए अनुमति देने के लिए सर्वर साइड एक्सप्रेशन (अलर्टिंग एनजी के साथ आ रहा है) में कार्यक्षमता जोड़ने का इरादा रखता हूं। ऐसा तब होगा जब आईआरएम का उपयोग न करें और सीधे ईमेल/स्लैक जैसी सेवाओं को भेजें।

चेतावनी/महत्वपूर्ण

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

यह कठिन है, क्योंकि कई मामलों में, यह बहुत उपयोगी है:

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

तो उन्हें न रखने का फैसला क्यों करें? यह काफी गैर-स्पष्ट जटिलता जोड़ता है:

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

(कम से कम एक अलर्ट परिभाषा के लिए, शायद अलर्ट परिभाषा को डुप्लिकेट करने, इसे बदलने, और कुछ इसे गंभीरता से लेबल/टैग करने का एक तरीका होगा

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

फिर उन्हें कैसे समूहीकृत किया जाना चाहिए यह एक मुद्दा बन जाता है (जैसा कि कई अलर्ट प्राप्त कर सकते हैं)

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

उम्मीद है कि यह खतरनाक डिजाइन को सरल करता है क्योंकि आपको समूहीकरण के बारे में चिंता नहीं करनी चाहिए। यह उपयोगकर्ता को संभालने के लिए है।