Prometheus: रिमोट स्टोरेज

क्या कोई इस पर काम करने की योजना बना रहा है? क्या opentsdb-एकीकरण शाखा में किया गया कार्य अभी भी मान्य है या शेष कोड-आधार उससे आगे बढ़ गया है?

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

स्पष्ट होने के लिए, पुराना "ओपन्सडीबी-एकीकरण" केवल के लिए था
प्रूफ-ऑफ-कॉन्सेप्ट _read-back_ समर्थन (प्रोमेथियस के माध्यम से OpenTSDB से पूछताछ)।

OpenTSDB में _Writing_ को मास्टर में प्रयोगात्मक रूप से समर्थित होना चाहिए, लेकिन
पिछली बार हमने इसे एक साल पहले सिंगल-नोड ओपनटीएसडीबी पर आजमाया था।

आपने शुरू में https://github.com/prometheus/prometheus/issues/10 पर पूछा था:

"मैंने store.remote.url कमांड लाइन फ्लैग जोड़ा है, लेकिन जहां तक ​​मैं बता सकता हूं
प्रोमेथियस वहां किसी भी मेट्रिक्स को स्टोर करने का प्रयास नहीं करता है।"

कुछ प्रश्न:

• क्या आपने OpenTSDB विकल्प "tsd.core.auto_create_metrics" को सक्षम किया है?
  अन्यथा OpenTSDB आपके लिए स्वचालित रूप से मेट्रिक्स नहीं बनाएगा, क्योंकि विकल्प है
  डिफ़ॉल्ट रूप से गलत। देखो
  http://opentsdb.net/docs/build/html/user_guide/configuration.html
• यदि आप प्रोमेथियस को -logtostderr के साथ चलाते हैं, तो क्या आपको कोई प्रासंगिक लॉग दिखाई देता है?
  आउटपुट? यदि TSDB को नमूने भेजने में कोई त्रुटि है, तो उसे लॉग किया जाना चाहिए
  (glog.Warningf ("TSDB को %d नमूने भेजने में त्रुटि: %s", लेन(s), त्रुटि))
• प्रोमेथियस ओपनटीएसडीबी को भेजने के बारे में मेट्रिक्स भी निर्यात करता है। पर
  /आपके प्रोमेथियस सर्वर के मेट्रिक्स, आपको काउंटर मेट्रिक्स मिलनी चाहिए
  "prometheus_remote_storage_sent_errors_total" और
  "prometheus_remote_storage_sent_samples_total"। ये क्या कहते हैं?

चीयर्स,
जूलियस

गुरु, 5 फरवरी, 2015 को सुबह 9:22 बजे, ब्योर्न रैबेनस्टीन नोटिफिकेशन @github.com
लिखा था:

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

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/prometheus/prometheus/issues/10#issuecomment -73010313
.

मैं इसे पर्याप्त +1 नहीं कर सकता

क्या किसी भी तरह से कार्ड पर InfluxDB है? :)

रेडियो येरेवन: "सिद्धांत रूप में हाँ।" (कृपया उस पूर्वी यूरोपीय विषयांतर को क्षमा करें...;)

: डी वह मेरे समय से थोड़ा पहले था;)

यह भी देखें: https://twitter.com/juliusvolz/status/569509228462931968

हम बस इन्फ्लक्सडीबी 0.9.0 की प्रतीक्षा कर रहे हैं, जिसमें एक नया डेटा मॉडल है जो
प्रोमेथियस के साथ अधिक संगत होना चाहिए।

गुरु, 5 मार्च, 2015 पूर्वाह्न 10:31 बजे, मिशल विटकोस्की नोटिफिकेशन @github.com
लिखा था:

: डी वह मेरे समय से थोड़ा पहले था;)

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/prometheus/prometheus/issues/10#issuecomment -77332742
.

हम बस इन्फ्लक्सडीबी 0.9.0 की प्रतीक्षा कर रहे हैं, जिसमें एक नया डेटा मॉडल है जो
प्रोमेथियस के साथ अधिक संगत होना चाहिए।

क्या मैं एक से अधिक बार कमाल कह सकता हूँ? विस्मयकारी!

दुर्भाग्य से, @juliusv ने 0.9 के साथ कुछ परीक्षण किए और InfluxDB ने Prometheus की तुलना में 14x अधिक संग्रहण की खपत की।

इससे पहले यह 11x का ओवरहेड था, लेकिन प्रोमेथियस तब से भंडारण के आकार को काफी कम कर सकता था - इसलिए वास्तव में InfluxDB ने उस संबंध में स्पष्ट रूप से सुधार किया है।
बहरहाल, लंबी अवधि के भंडारण के लिए InfluxDB अंतिम उत्तर नहीं निकला, फिर भी।

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

@ beorn7 यह बहुत अच्छा है। टीबीएच मैं डिस्क स्थान के बारे में चिंतित नहीं हूं, यह क्लाउड पर सबसे सस्ता संसाधन है। उल्लेख नहीं है, मैं बहुत छोटे टीटीएल, यानी कुछ हफ्तों के साथ डेटा रखने की उम्मीद कर रहा हूं।

@pires उस स्थिति में, क्यों न केवल दो समान रूप से कॉन्फ़िगर किए गए Prometheis को एक बड़ी डिस्क के साथ चलाएं?
प्रोमेथियस के लिए अवधारण समय के रूप में कुछ सप्ताह या महीने आमतौर पर ठीक होते हैं। (किसी कारण से डिफ़ॉल्ट 15d है... :) एकमात्र समस्या यह है कि यदि आपकी डिस्क टूट जाती है, तो आपका डेटा चला जाता है, लेकिन उसके लिए, आपके पास दूसरा सर्वर होता है।

@pires क्या आपके पास उस समय के लिए किसी अन्य डेटाबेस में डेटा रखने का कोई विशेष कारण है? ऐसा लगता है कि "कुछ सप्ताह" के लिए दीर्घकालिक भंडारण समाधान की आवश्यकता नहीं है। प्रोमेथियस का डिफ़ॉल्ट अवधारण समय 15 दिन है - इसे बढ़ाकर 30 या 60 दिन भी करना कोई समस्या नहीं होनी चाहिए।

@beorn7 @fabxc मैं वर्तमान में एक मालिकाना और बहुत विशिष्ट समाधान का उपयोग कर रहा हूं जो इन्फ्लक्सडीबी में मॉनिटरिंग मेट्रिक्स लिखता है। इसे अंततः प्रोमेथियस से बदला जा सकता है।

बात यह है कि मेरे पास कुछ अनुरूप ऐप्स हैं जो प्रतिक्रियात्मक रूप से ऊपर/नीचे स्केल करने के लिए InfluxDB से मीट्रिक पढ़ते हैं, जिन्हें इसके बजाय प्रोमेथियस से पढ़ने के लिए फिर से लिखना होगा। साथ ही, मैं continuous queries उपयोग करता हूं। क्या प्रोमेथियस ऐसी सुविधा प्रदान करता है?

http://prometheus.io/docs/querying/rules/#recording -rules InfluxDB के निरंतर प्रश्नों के बराबर हैं।

+1

:+1:

वर्तमान में कार्यान्वित रिमोट स्टोरेज प्रोमडैश या ग्राफाना के साथ कैसे इंटरैक्ट करता है?

मेरे पास एक उपयोग का मामला है जहां मैं प्रोमेथियस को 'हेरोकू-जैसी' वातावरण में चलाने के लिए चाहता हूं, जहां उदाहरण किसी भी समय दूर हो सकते हैं।

फिर मैं डेटा स्टोर करने के लिए एक दूरस्थ, पारंपरिक इनफ्लक्सडीबी क्लस्टर को कॉन्फ़िगर करूंगा।

क्या यह कॉन्फ़िगरेशन सामान्य रूप से कार्य कर सकता है?

यह "सामान्य रूप से" की आपकी परिभाषा पर निर्भर करता है, लेकिन अधिकतर, नहीं।

रिमोट स्टोरेज के रूप में यह केवल लिखने के लिए है; प्रोमेथियस से आपको वही मिलेगा जो उसके पास स्थानीय स्तर पर है।

पुराने डेटा प्राप्त करने के लिए, आपको OpenTSDB या InfluxDB को सीधे उनके स्वयं के इंटरफेस और क्वेरी भाषाओं का उपयोग करके क्वेरी करने की आवश्यकता है। PromDash के साथ आप उस संबंध में भाग्य से बाहर हैं; AFAIK Grafana उन सभी को जानता है।

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

यह भी ध्यान दें कि InfluxDB और OpenTSDB दोनों ही समर्थन कुछ हद तक प्रयोगात्मक हैं, हमारी तरफ से कम अभ्यास किया गया है, और प्रवाह में है।

हम एक फ्लैट फ़ाइल निर्यातक के विचार के आसपास लात मार रहे हैं, इस प्रकार हम दीर्घकालिक डेटा संग्रहीत करना शुरू कर सकते हैं और फिर एक बार थोक आयात समस्या हो जाने के बाद हम उस https://github.com/prometheus/prometheus/issues/535 का उपयोग कर सकते हैं

#535 के लिए मेरी पुरानी शाखा import-api पर एक नज़र डालें, जहां मैंने एक बार प्रूफ-ऑफ-कॉन्सेप्ट के रूप में एक आयात एपीआई जोड़ा था: https://github.com/prometheus/prometheus/commits/import-api . यह मार्च से है, इसलिए यह अब मास्टर पर लागू नहीं होता है, लेकिन यह सिर्फ यह दर्शाता है कि सैद्धांतिक रूप से मौजूदा स्थानांतरण प्रारूपों का उपयोग करके ऐसे एपीआई को जोड़ना तुच्छ होगा। हमें केवल इस बात से सहमत होने की आवश्यकता है कि हम इसे चाहते हैं (यह एक विवादास्पद मुद्दा है, /cc @brian-brazil) और क्या इसे उसी नमूना स्थानांतरण प्रारूप का उपयोग करना चाहिए जिसका उपयोग हम स्क्रैपिंग के लिए करते हैं। इस स्थानांतरण प्रारूप के साथ समस्या यह है कि यह कई-श्रृंखला-एक-नमूना (स्क्रैप) मामले के लिए अनुकूलित है, जबकि बैच आयात के साथ आप अक्सर एक श्रृंखला के सभी नमूनों को एक बार में आयात करने के बारे में अधिक परवाह करते हैं, बिना मीट्रिक नाम को दोहराए और प्रत्येक नमूने के लिए लेबल (बड़े पैमाने पर उपरि)। लेकिन शायद हम (दुर्लभ?) थोक आयात मामले में दक्षता की परवाह नहीं करते हैं, इसलिए मौजूदा प्रारूप ठीक हो सकता है।

दूरस्थ भंडारण भाग के लिए, यह चर्चा थी
https://groups.google.com/forum/#!searchin/prometheus -developers/json/prometheus-developers/QsjXwQDLHxI/Cw0YWmevAgAJ रिमोट स्टोरेज को कुछ सामान्य तरीके से अलग करने के बारे में, लेकिन कुछ विवरण अभी तक हल नहीं किए गए हैं। मूल विचार यह था कि प्रोमेथियस सभी नमूनों को कुछ अच्छी तरह से परिभाषित प्रारूप (JSON, प्रोटोबफ, या जो कुछ भी) में एक उपयोगकर्ता-निर्दिष्ट समापन बिंदु पर भेज सकता है, जो तब इसके साथ कुछ भी कर सकता है (इसे एक फ़ाइल में लिखें, इसे दूसरे को भेजें प्रणाली, आदि)।

इसलिए एक फ्लैट फ़ाइल निर्यातक को रिमोट स्टोरेज बैकएंड के रूप में सीधे प्रोमेथियस में जोड़ना ठीक हो सकता है, या उस चर्चा को ऊपर हल करना और अच्छी तरह से परिभाषित स्थानांतरण प्रारूप और बाहरी डेमॉन का उपयोग करना ठीक हो सकता है।

मुझे लगता है कि फ्लैट फ़ाइल के लिए हम बाहरी डेमॉन की बात कर रहे होंगे, क्योंकि यह ऐसा कुछ नहीं है जिसे हम कभी भी वापस पढ़ सकें।

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

उस उपयोग के मामले में हम आम तौर पर कई समान प्रोमेथियस सर्वर चलाने की सलाह देते हैं। रिमोट स्टोरेज लंबी अवधि के डेटा के बारे में है, रिडंडेंसी या स्केलिंग के बारे में नहीं।

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

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

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

रिमोट स्टोरेज अभी भी उतना उपयोगी नहीं है क्योंकि इसे पूछने का कोई तरीका नहीं है। ऐसा लगता है कि यदि आप नोड्स को प्रारंभिक बैकफिल करने में सक्षम होने की अनुमति देते हैं तो आप मौजूदा प्राइमेटिव के साथ एक बहुत तेज़ दीर्घकालिक भंडारण समाधान बना सकते हैं।

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

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

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

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

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

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

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

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

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

कुछ स्थितियों में बैकफ़िलिंग डेटा (जैसे विलंबित Hadoop ईवेंट लॉग प्रोसेसिंग से उत्पन्न मीट्रिक के बैच आयात करना जिसे आप अन्य मीट्रिक के साथ सहसंबंधित करना चाहते हैं)।

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

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

क्या यह वास्तव में आपके /संघीय समापन बिंदु से बहुत अधिक अवधारणात्मक रूप से भिन्न है? जो डाउनस्ट्रीम सिस्टम को इसे परिमार्जन करने की अनुमति देता है। मैं बस सोच रहा हूं कि हम कुछ पेजिंग के साथ पूरी टाइमरीज को उजागर कर सकते हैं।

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

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

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

@ ब्रायन-ब्राज़ील क्या आप डाउनसैंपलिंग की तरह सोच रहे हैं या समय में पीछे की ओर एकत्रीकरण पसंद कर रहे हैं

एकत्रीकरण/नियम समय पर वापस। डाउनसैंपलिंग एक स्पष्ट गैर-लक्ष्य है, हम मानते हैं कि यह दीर्घकालिक भंडारण में है।

https://github.com/prometheus/prometheus/issues/10#issuecomment -90591577 @fabxc में कहा गया है:

0.9 के साथ कुछ परीक्षण चलाए और InfluxDB ने Prometheus की तुलना में 14x अधिक संग्रहण की खपत की।

मैं बस यह कहना चाहता था कि नवीनतम InfluxDB 0.10 GA ने अपने स्टोरेज इंजन में आक्रामक रूप से सुधार किया है। उनके ब्लॉग पोस्ट में कहा गया है:

प्रति सेकंड सैकड़ों हज़ारों राइट्स और 98% बेहतर संपीड़न के लिए समर्थन

फिर से देखने लायक हो सकता है।

https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/ के साथ InfluxDB अब टेबल पर नहीं है।

क्या ब्लूफ्लड का संगत डेटा मॉडल है?

तालिका से InfluxDB के साथ, यह Cassandra द्वारा समर्थित सबसे आशाजनक ओपन सोर्स TSDB प्रतीत होता है।

चीजों को खुला रखने के लिए रैकस्पेस की काफी अच्छी प्रतिष्ठा है।

http://blueflood.io/

ऐसा लगता है कि ब्लूफ्लड में मिलीसेकंड टाइमस्टैम्प हैं, यह स्पष्ट नहीं है कि यह डेटा प्रकार के रूप में फ्लोट64 का समर्थन करता है (मुझे लगता है कि यह करता है) लेकिन इसमें लेबल की कोई धारणा नहीं है। ऐसा लगता है कि वास्तुशिल्प रूप से सही विचार है, लेकिन यह बिल्कुल फिट नहीं है।

न्यूट्स एक और कैसेंड्रा समर्थित विकल्प है।

डेटा मॉडल का वर्णन https://github.com/OpenNMS/newts/wiki/DataModel पर किया गया है, जो लेबल का समर्थन करता है।

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

न्यूट्स में वास्तव में लेबल की धारणा नहीं है, और मुझे नहीं लगता कि यह कैसेंड्रा स्कीमा हमारे द्वारा काम कर रहे डेटा की मात्रा के लिए अच्छी तरह से स्केल करेगा।

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

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

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

उस सब के बारे में बात करना आसान है - यह कार्यान्वयन के बिना ज्यादा मूल्यवान नहीं है, जिसमें निश्चित रूप से कुछ समय लगेगा :)

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

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

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

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

मुझे पता है कि इसके चुनौतीपूर्ण निहितार्थ हैं। लेकिन TSDB की प्रतीक्षा करने वाले जो बिना किसी सीमा के हमारे मॉडल के अनुकूल हैं, वे बदतर हैं। मौजूदा अनुपयुक्त प्रतीत होते हैं। और मुझे इस बात की जानकारी नहीं है कि कोई ऐसा काम कर रहा है जो होगा।

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

मौजूदा और स्थिर वाले अनुपयुक्त प्रतीत होते हैं।

कुछ करीब हैं।

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

और मुझे इस बात की जानकारी नहीं है कि कोई ऐसा काम कर रहा है जो होगा।

:मुस्कुराओ:

सवाल यह निकलता है कि आप इसे कैसे हल करते हैं, लेकिन आपका बजट कितना अधिक है।

OpenTSDB के साथ वास्तव में 8 टैग की तुलना में अधिक समस्याएं हैं

यह अब कोई मुद्दा नहीं है।

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

सीमाएं बहुत बड़ी हैं (16M) और आप उन्हें और भी बड़ा बना सकते हैं।

मैं एक OpenTSDB कमिटर हूं, मुझे रोडमैप को समन्वयित करने में खुशी होगी
यदि संभव हो तो अपनी आवश्यकताओं को पूरा करें।

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

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

- जोनाथन
30 मार्च 2016 को सुबह 7:42 बजे, "इवान बबरू" नोटिफिकेशन @github.com ने लिखा:

OpenTSDB के साथ वास्तव में 8 टैग की तुलना में अधिक समस्याएं हैं

यह अब कोई मुद्दा नहीं है।

एक लेबल के मूल्यों की संख्या की भी सीमा होती है, इसलिए हम नहीं कर सकते हैं
यहां तक ​​कि वास्तव में इसे भंडारण के रूप में उपयोग करते हैं - हालांकि हमारे पास कई उपयोगकर्ता योजना बना रहे हैं
वहां अपना डेटा डाल रहे हैं।

सीमाएं बहुत बड़ी हैं (16M) और आप उन्हें और भी बड़ा बना सकते हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/prometheus/prometheus/issues/10#issuecomment -203414217

अतिरिक्त आइटम जिनका मुझे उल्लेख करना चाहिए, मैंने प्रति 10 मिलियन राइट्स को कायम रखा है
OpenTSDB के बाद दूसरा, और दोहराया कि दूसरे सेटअप पर एक अलग
कंपनी। HBase इसके लिए वास्तव में अच्छा है।

2.3.0 शाखा, जिसमें किसी भी दिन RC1 होना चाहिए, अब अभिव्यक्ति है
समर्थन, सम (), टाइमशिफ्ट (), आदि जैसी चीजें। इन्हें लिखना चाहिए
आपकी क्वेरी का समर्थन आसान है।

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

इन नई सुविधाओं और OpenTSDB को स्केल करने के मेरे अनुभव को बनाने में मदद करनी चाहिए
मेरी राय में, एक आदर्श दीर्घकालिक भंडारण समाधान।
30 मार्च 2016 को सुबह 8:47 बजे "जोनाथन क्रीसी" [email protected] ने लिखा:

मैं एक OpenTSDB कमिटर हूं, मुझे रोडमैप को समन्वयित करने में खुशी होगी
यदि संभव हो तो अपनी आवश्यकताओं को पूरा करें।

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

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

- जोनाथन
30 मार्च 2016 को सुबह 7:42 बजे, "इवान बबरू" नोटिफिकेशन @github.com ने लिखा:

OpenTSDB के साथ वास्तव में 8 टैग की तुलना में अधिक समस्याएं हैं

यह अब कोई मुद्दा नहीं है।

एक लेबल के मूल्यों की संख्या की भी सीमा होती है, इसलिए हम नहीं कर सकते हैं
यहां तक ​​कि वास्तव में इसे भंडारण के रूप में उपयोग करते हैं - हालांकि हमारे पास कई उपयोगकर्ता योजना बना रहे हैं
वहां अपना डेटा डाल रहे हैं।

सीमाएं बहुत बड़ी हैं (16M) और आप उन्हें और भी बड़ा बना सकते हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/prometheus/prometheus/issues/10#issuecomment -203414217

यह अब कोई मुद्दा नहीं है।

यह जानना अच्छा है, अब यह कितने टैग का समर्थन करता है?

सीमाएं बहुत बड़ी हैं (16M) और आप उन्हें और भी बड़ा बना सकते हैं।

मैं कल्पना कर सकता हूं कि उपयोगकर्ता इसे मार रहे हैं, ज्यादातर दुर्घटना से।

आपके पास एक टीएसडी स्टार्टअप हो सकता है और प्रोमेथियस से इसकी कॉन्फ़िगरेशन प्राप्त कर सकते हैं।

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

OpenTSDB में रीयलटाइम प्रकाशन प्लगइन OpenTSDB में डेटा स्वीकार करने और प्रकाशित करने के लिए
प्रोमेथियस के अतिरिक्त।

यह प्रोमेथियस आर्किटेक्चर नहीं है, प्रोमेथियस डेटा एकत्र करेगा और इसे ओपनटीएसडीबी को भी भेजेगा।

यदि हम डेटा को दूसरी दिशा में खींचना चाहते हैं तो हम एक OpenTSDB निर्यातक लिखेंगे, जैसे कि InfluxDB निर्यातक कैसे काम करता है।

अतिरिक्त आइटम जिनका मुझे उल्लेख करना चाहिए, मैंने प्रति 10 मिलियन राइट्स को कायम रखा है
OpenTSDB के बाद दूसरा, और दोहराया कि दूसरे सेटअप पर एक अलग
कंपनी। HBase इसके लिए वास्तव में अच्छा है।

क्या आप इसमें शामिल हार्डवेयर का अंदाजा लगा सकते हैं?

इनसे आपके क्वेरी समर्थन को लिखना आसान हो जाना चाहिए।

हमें जिस न्यूनतम समर्थन की आवश्यकता है, वह है {__name__="up",job="myjob",somelabel!="foo",otherlabel~="a|b"} जैसे वेक्टर चयनकर्ता को निर्दिष्ट करने की क्षमता और किसी निश्चित समयावधि के लिए सभी मिलान समय-श्रृंखलाओं के लिए सभी डेटा कुशलता से वापस प्राप्त करना। प्रश्नों में एक नाम शामिल नहीं हो सकता है (हालांकि आमतौर पर होना चाहिए), और यह सवाल से बाहर नहीं है कि एक ही नाम के लिए हर समय लाखों टाइम्सरी हों और हजारों की संख्या असामान्य न हो।

मैं एक OpenTSDB कमिटर हूं, मुझे रोडमैप को समन्वयित करने में खुशी होगी
यदि संभव हो तो अपनी आवश्यकताओं को पूरा करें।

हमारे लिए फुल फ्लोट64 को स्टोर करना महत्वपूर्ण है। यह देखते हुए कि आप 64 बिट पूर्णांकों का समर्थन करते हैं, क्या हम उन्हें उसी रूप में भेज सकते हैं या पूर्ण समर्थन एक विकल्प है?

टैग मानों में पूर्ण utf-8 समर्थन भी उपयोगी होगा, हालांकि हम पहले ही इस पर काम कर चुके हैं।

@bobrik @johann8384 उन

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

इसलिए यदि आप उपरोक्त प्राप्त करना चाहते हैं तो फ्लोट64 मूल्य समर्थन महत्वपूर्ण है, लेकिन ओपनटीएसडीबी दस्तावेज़ वास्तव में उल्लेख करते हैं कि यह रोडमैप पर है, इसलिए यह अच्छा है: http://opentsdb.net/docs/build/html/user_guide/writing .html#floating -point-values

क्या OpenTSDB कभी प्रोमेथियस की सभी क्वेरी भाषा सुविधाओं को संगत रूप से निष्पादित करने में सक्षम होगा, यह एक और प्रश्न है।

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

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

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

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

सीमाएं बहुत बड़ी हैं (16M) और आप उन्हें और भी बड़ा बना सकते हैं।

मैं कल्पना कर सकता हूं कि उपयोगकर्ता इसे मार रहे हैं, ज्यादातर दुर्घटना से।

मैं उस सीमा के साथ जीने को तैयार हूं।

छोटे या खिलौनों के उपयोग के मामलों से ज्यादा कुछ के लिए, हमें क्वेरी गणना को दीर्घकालिक भंडारण में स्थानांतरित करने की आवश्यकता होगी

क्या ओपन TSDB आखिरकार उपयुक्त होना चाहिए, मुझे संदेह है कि हम क्वेरी फीचर समता प्राप्त कर सकते हैं। यदि हम करते हैं, तो यह हमेशा एक सीमित कारक होगा जब हम अपने PromQL का विस्तार करना चाहते हैं।
"जेनेरिक" पढ़ने/लिखने के पथ के साथ यह वैसे भी एक पुल का उपयोग करेगा। वितरित मूल्यांकन की देखभाल के लिए इसे बढ़ाया जा सकता है।

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

(स्पष्टीकरण के लिए उपरोक्त टिप्पणी संपादित, केवल ईमेल पढ़ने वाले लोगों के लिए)

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

बुधवार, 30 मार्च, 2016 को सुबह 9:39 बजे, ब्रायन ब्राजील सूचनाएं @github.com
लिखा था:

यह अब कोई मुद्दा नहीं है।

यह जानना अच्छा है, अब यह कितने टैग का समर्थन करता है?

टैग सीमा पहले एक हार्ड कोडित स्थिरांक था, मैं आमतौर पर हमेशा
इसे मेरे सेटअप में 16 पर सेट करें। यह a के बजाय कॉन्फ़िगरेशन मान नहीं है
कोड में स्थिर।

सीमाएं बहुत बड़ी हैं (16M) और आप उन्हें और भी बड़ा बना सकते हैं।

मैं कल्पना कर सकता हूं कि उपयोगकर्ता इसे मार रहे हैं, ज्यादातर दुर्घटना से।

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

आपके पास एक टीएसडी स्टार्टअप हो सकता है और प्रोमेथियस से इसकी कॉन्फ़िगरेशन प्राप्त कर सकते हैं।

यह मेरे लिए कोई मतलब नहीं है, मैं उम्मीद करता हूं कि प्रोमेथियस को कॉन्फ़िगर किया जाएगा
किसी दिए गए OpenTSB समापन बिंदु पर जानकारी भेजें और वह संपूर्ण होगा
लेखन पक्ष पर आवश्यक विन्यास।

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

OpenTSDB में रीयलटाइम प्रकाशन प्लगइन OpenTSDB में डेटा स्वीकार करने के लिए और
प्रकाशित करना
प्रोमेथियस के अतिरिक्त।

यह प्रोमेथियस आर्किटेक्चर नहीं है, प्रोमेथियस डेटा एकत्र कर रहा होगा
और इसे OpenTSDB पर भी भेज रहा है।

यदि हम डेटा को दूसरी दिशा में खींचना चाहते हैं तो हम एक OpenTSDB लिखेंगे
निर्यातक, इन्फ्लक्सडीबी निर्यातक के काम करने के तरीके के समान।

अतिरिक्त आइटम जिनका मुझे उल्लेख करना चाहिए, मैंने प्रति 10 मिलियन राइट्स को कायम रखा है
OpenTSDB के बाद दूसरा, और दोहराया कि दूसरे सेटअप पर एक अलग
कंपनी। HBase इसके लिए वास्तव में अच्छा है।

क्या आप इसमें शामिल हार्डवेयर का अंदाजा लगा सकते हैं?

मेरा मानना ​​है कि मूल क्लस्टर 24 Dell R710 मशीनें थीं, शायद 64GB ram, I
अन्य विशिष्टताओं के बारे में ज्यादा याद नहीं है। टर्न पर क्लस्टर 36 नोड्स, 24 . है
कोर, 128GB रैम, 8 डिस्क।

इनसे आपके क्वेरी समर्थन को लिखना आसान हो जाना चाहिए।

हमें जो न्यूनतम समर्थन चाहिए वह है वेक्टर चयनकर्ता को निर्दिष्ट करने की क्षमता
जैसे { नाम = "ऊपर", नौकरी = "माईजॉब", कुछ लेबल! = "फू", अन्य लेबल ~ = "ए | बी"} और
एक निश्चित समय अवधि के लिए सभी मिलान समय श्रृंखला के लिए सभी डेटा वापस प्राप्त करें
कुशलता से। प्रश्नों में एक नाम शामिल नहीं हो सकता है (हालांकि आमतौर पर होना चाहिए), और
एक ही नाम के लाखों होने का सवाल ही नहीं है
हर समय और हजारों की प्रवृत्ति असामान्य नहीं होगी।

मैं एक OpenTSDB कमिटर हूं, मुझे रोडमैप को समन्वयित करने में खुशी होगी
यदि संभव हो तो अपनी आवश्यकताओं को पूरा करें।

हमारे लिए फुल फ्लोट64 को स्टोर करना महत्वपूर्ण है। यह देखते हुए कि आप 64 बिट का समर्थन करते हैं
पूर्णांक, क्या हम उन्हें उसी रूप में भेज सकते हैं या पूर्ण समर्थन एक विकल्प है?

टैग मानों में पूर्ण utf-8 समर्थन भी उपयोगी होगा, हालांकि हमने
इसके आसपास पहले से ही काम किया है।

जहां तक ​​मेरी जानकारी है, कुछ भी गलत नहीं है, आइए मिलकर काम करें
उस पर अमल करो।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/prometheus/prometheus/issues/10#issuecomment -203463519

मुझे यकीन है कि मुझे प्रोमेथियस क्वेरी संरचना के बारे में और जानने की जरूरत है, लेकिन
OpenTSDB (ऐसा लगता है) के भीतर श्रृंखला भर में एकत्रीकरण में बहुत अच्छा है
एक ही मीट्रिक नाम। नए एग्रीगेटर, एग्रीगेटर फ़िल्टर और . भी हैं
बेशक अभिव्यक्ति का समर्थन।

मैं अनुशंसा करता हूं कि हम प्री-एग्रीगेटिंग का समर्थन करने का एक तरीका खोजें और
डेटा को डाउनसैंपलिंग करते हुए हम इसे OpenTSDB में संग्रहीत करते हैं। तो उदाहरण के लिए, हम कर सकते हैं
लिखते समय पट्टी करने के लिए टैग की एक सूची प्रदान करें। एक और विचार लिखना है
${metric}.1m-avg, ${metric}.5m-avg और स्वचालित रूप से उनको चुनें
बड़ी समय सीमाओं को पढ़ते समय एक्सटेंशन। यह एक RRD . के तरीके की नकल करेगा
भंडारण प्रणाली काम कर सकती है। तो क्वेरी के हाल के भाग के लिए हम पूरा खींचते हैं
संकल्प लेकिन जैसे-जैसे हम आगे बढ़ते हैं, हम 1m-औसत से खींच सकते हैं, और
5 मीटर-औसत श्रृंखला।

बिल्कुल विचार बस।

बुधवार, 30 मार्च, 2016 को सुबह 10:39 बजे, जूलियस वोल्ज़ नोटिफिकेशन @github.com
लिखा था:

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/prometheus/prometheus/issues/10#issuecomment -203494343

मैं अनुशंसा करता हूं कि हम प्री-एग्रीगेटिंग का समर्थन करने का एक तरीका खोजें और
डेटा को डाउनसैंपलिंग करते हुए हम इसे OpenTSDB में संग्रहीत करते हैं।

ऐसा कुछ नहीं है जो हम उपयोगकर्ता इनपुट के बिना लगभग हर मीट्रिक के लिए कर सकते हैं, क्योंकि हम नहीं जानते कि कौन से लेबल निकालना ठीक है। यह उपयोगकर्ता प्रश्नों को भी तोड़ देगा क्योंकि यह अब वही समय-सारिणी नहीं है।

हां, पूर्व-एकत्रीकरण मुश्किल होगा।

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

मैं समझता हूं कि अच्छे कारणों से InfluxDB को समीकरण से बाहर कर दिया गया है, लेकिन मेरा यह भी मानना ​​है कि जब तैनाती की बात आती है तो OpenTSDB एक राक्षस है; 10 कर्मचारियों के तहत कोई भी कंपनी HBase के साथ पूरी तरह से विकसित Hadoop नहीं चलाना चाहती है और मुझे लगता है कि Hadoop + HBase नहीं चलाने वाले छोटे संगठनों के लिए भी दीर्घकालिक भंडारण एक व्यवहार्य विकल्प होना चाहिए। मुझे आशा है कि "लॉन्ग स्टोरेज" समाधान, जो कुछ भी हो, एक ऐसा समाधान है जिसे आसानी से तैनात किया जा सकता है। Hadoop के साथ और उसके बिना दोनों कंपनियां दीर्घकालिक भंडारण चाहती हैं। वे मेरे दो सेंट थे ...

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

स्टैंडअलोन में रनिंग hbase इसके वितरित होने के बिंदु को हरा देता है;) प्रोमेथियस का पहले से ही अपना स्टोर है। ईमानदारी से मैं उम्मीद कर रहा हूँ कि यह OpenTSDB की ओर नहीं जाएगा। हम एक 50 नोड क्लस्टर चलाते थे और यह क्लस्टर का प्रबंधन करने का एक पूर्णकालिक काम था।

हाँ, OpenTSDB का संचालन के लिए जटिल होना एक आम शिकायत है और मुझे इसके बारे में भी बहुत सावधान करता है। बेशक, आपको अभी भी किसी भी अन्य व्यवहार्य विकल्प की संभावना के खिलाफ वजन करना होगा ...

क्या इस समय वास्तव में कोई इस पर काम कर रहा है?

@ johann8384 वर्तमान में कोई भी पूरी तरह से नई वितरित भंडारण प्रणाली पर काम नहीं कर रहा है, नहीं। लेकिन जेनेरिक रिमोट राइट एपीआई (https://github.com/prometheus/prometheus/pull/1487) के आसपास कुछ संबंधित कार्य और चर्चा है, लेकिन अभी तक रीड-बैक के बारे में कुछ भी ठोस नहीं है।

बस ऊपर के अन्य लोगों की भावना को दोहराना चाहता था... भले ही हम एक उचित आकार की टीम हैं, हम HBase का संचालन नहीं करना चाहते हैं। OpenTSDB इस कारण से हमारी छोटी सूची में भी नहीं है।

अस्वीकरण: हम इस समय तकनीकी रूप से प्रोमेथियस उपयोगकर्ता नहीं हैं, लेकिन हमें अगले कुछ हफ्तों में होना चाहिए :)।

स्टैंडअलोन में रनिंग hbase इसे वितरित किए जाने के बिंदु को हरा देता है;)

@mattkanwisher सच है।

प्रोमेथियस का पहले से ही अपना स्टोर है।

सत्य। हालाँकि, AFAIK प्रोमेथियस स्टोरेज डाउनसैंपलिंग का समर्थन नहीं करता है। AFAIK, OpenTSDB नहीं करता है। यह ओपनटीएसडीबी (या कुछ और) गैर-वितरित चलाने की इच्छा रखने का एक कारण हो सकता है।

क्या इस समय वास्तव में कोई इस पर काम कर रहा है?

अच्छा प्रश्न। मुझे यह सुनकर आश्चर्य नहीं होगा कि कोई इस पर काम कर रहा है क्योंकि यह मुद्दा बड़ा है और अच्छी तरह से परिभाषित नहीं है। जैसा कि मैंने इसे देखा, वास्तव में कई उप-विषयक हैं:

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

कुछ कमी?

अस्वीकरण @jkinred की तरह, मैं प्रोमेथियस उपयोगकर्ता नहीं हूं। हालाँकि, मैं इसमें वापस आता रहता हूँ ...

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

स्ट्रीम लोड करके BigQuery निर्यातक के बारे में क्या? बोर्गमोन के समान विकल्प होना चाहिए -> tsdb?

कॉलमर डेटा मॉडल के कारण मुझे यहां BigQuery का समझदारी से उपयोग करने का कोई तरीका नहीं दिख रहा है, जब तक कि आप डेटा को बहुत ही कम क्वेरी कर रहे हों।

https://github.com/hawkular/hawkular-metrics के बारे में क्या?
हॉक्युलर मेट्रिक्स हॉक्युलर प्रोजेक्ट के लिए मीट्रिक डेटा स्टोर है। इसे स्वतंत्र रूप से भी इस्तेमाल किया जा सकता है।

यह भी देखें https://github.com/kubernetes/heapster/blob/master/docs/storage-schema.md#hawkular

प्रोमेथियस एंडपॉइंट्स से मेट्रिक्स एकत्रित करना: http://www.hawkular.org/blog/2016/04/22/collecting-metrics-from-prometheus-endpoints.html
एजेंट के पास अब प्रोमेथियस एंडपॉइंट्स की निगरानी करने और उनके मेट्रिक्स को हॉक्युलर मेट्रिक्स में स्टोर करने की क्षमता है। इसका मतलब है कि कोई भी घटक जो प्रोमेथियस बाइनरी या टेक्स्ट प्रारूपों के माध्यम से प्रोमेथियस मीट्रिक डेटा निर्यात करता है, उसके पास एजेंट द्वारा एकत्र किया गया मीट्रिक डेटा हो सकता है और हॉक्युलर मेट्रिक्स में धकेल दिया जा सकता है।

प्रोमेथियस मेट्रिक्स स्क्रैपर: https://github.com/hawkular/hawkular-agent/tree/master/prometheus-scraper

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

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

देखो :

• टैग और लेबल आधारित खोज (https://github.com/openshift/origin-metrics/issues/34)
• टैग के आधार पर क्वेरी करना (https://github.com/openshift/origin-metrics/blob/master/docs/hawkular_metrics.adoc#querying-based-on-tag)

इसके अलावा, कैसेंड्रा 3.4 ने एसएएसआई कस्टम इंडेक्स के लिए समर्थन जोड़ा:

• एसएएसआईइंडेक्स (https://github.com/apache/cassandra/blob/trunk/doc/SASI.md)
• कैसेंड्रा के लिए नई क्वेरी क्षमताओं (या, स्कोपिंग) के साथ बेहतर माध्यमिक अनुक्रमण (https://github.com/xedin/sasi)
• एसएएसआई सशक्त माध्यमिक सूचकांक (http://www.planetcassandra.org/blog/sasi-empowering-secondary-indexes/)
• SSTable संलग्न द्वितीयक अनुक्रमणिका (SASI) के साथ अनुक्रमण (https://docs.datastax.com/en/cql/3.3/cql/cql_using/useSASIIndexConcept.html)
• एसएएसआई: कैसेंड्रा के साथ रीयल-टाइम सर्च एंड एनालिटिक्स (http://www.meetup.com/fr-FR/DataStax-Cassandra-South-Bay-Users/events/229467895/?eventId=229467895)

एसएएसआई उपयोग का मामला: स्ट्रिंग मीट्रिक प्रकार लागू करें (https://issues.jboss.org/browse/HWKMETRICS-384)

मैंने "Hawkular metrics as the long-term storage backend for the prometheus.io" इश्यू बनाया (https://issues.jboss.org/browse/HWKMETRICS-400)

मुझे लगता है कि प्रोमेथियस द्वारा उत्पादित डेटा वॉल्यूम के लिए इसे काम करने के लिए हॉक्युलर का एक बड़ा नया स्वरूप लेना होगा। उदाहरण के लिए एक एकल लेबल मिलानकर्ता जैसे job=node एक बड़े सेटअप पर लाखों टाइम सीरीज़ का आसानी से मिलान कर सकता है। यह metrics_tags_idx. लिए C* में 4GB पंक्ति आकार सीमा को समाप्त करने जा रहा है

हॉक्युलर भी प्रतिकृति से पहले प्रति नमूना कम से कम 32 बाइट्स का उपयोग करता प्रतीत होता है।

मैं C* में 4GB पंक्ति आकार सीमा नहीं जानता
कैसेंड्रा में 2 बिलियन कॉलम की सीमा है (https://github.com/kairosdb/kairosdb/issues/224)
सीक्यूएल सीमाएं (https://docs.datastax.com/en/cql/3.1/cql/cql_reference/refLimits.html)

पीआर "जेनेरिक राइट #1487" (https://github.com/prometheus/prometheus/pull/1487) से क्या संबंध है?

मुझे लगता है कि प्रोमेथियस द्वारा उत्पादित डेटा वॉल्यूम के लिए इसे काम करने के लिए हॉक्युलर का एक बड़ा नया स्वरूप लेना होगा। उदाहरण के लिए एक एकल लेबल मैचर जैसे कि जॉब = नोड एक बड़े सेटअप पर दसियों लाख टाइम सीरीज़ का आसानी से मिलान कर सकता है। इससे metrics_tags_idx के लिए C* में 4GB पंक्ति आकार सीमा समाप्त हो जाएगी।

आप सही हैं कि ऐसी संभावना है कि हम metrics_tags_idx में बहुत विस्तृत पंक्तियों के साथ समाप्त हो सकते हैं। यह कोई चिंता की बात नहीं है क्योंकि हम डेटा सेट के साथ इतना बड़ा व्यवहार नहीं कर रहे हैं कि बदलाव की आवश्यकता हो।

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

हॉक्युलर भी प्रतिकृति से पहले प्रति नमूना कम से कम 32 बाइट्स का उपयोग करता प्रतीत होता है।

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

बस यह सुनिश्चित करना चाहते हैं कि मैं वृद्धि के इस क्षेत्र की स्थिति को समझता हूं ... क्या रिमोट प्रदाता / स्टोरेज / रिमोट में अब समर्थित हैं? यदि हां, तो यहां क्या पूरा किया जाना शेष है?

वे प्रभावी रूप से बहिष्कृत हैं। एक बार हमारे पास प्रोमेथियस (उदाहरण #1487) में किसी प्रकार का सामान्य लेखन हो जाने पर उन्हें हटा दिया जाएगा।

हाय सब, मैं एक भंडारण परत के लिए एक और संभावना लाना चाहता था: Apache Kudu (इनक्यूबेटिंग) । कुडू खुद को Hadoop पारिस्थितिकी तंत्र के लिए एक विश्लेषिकी भंडारण परत के रूप में बिल करता है, और जबकि यह है, यह समय-सारणी मेट्रिक्स डेटा संग्रहीत करने के लिए एक उत्कृष्ट मंच भी है। कुडू तालिका में कुछ दिलचस्प विशेषताएं लाता है:

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

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

जहां तक ​​कुडू की परिपक्वता की बात है, हम इस गर्मी के अंत में 1.0 उत्पादन के लिए तैयार रिलीज की योजना बना रहे हैं। यह परियोजना तीन साल से अधिक समय से विकास के अधीन है, और हमारे पास पहले से ही कुछ बहुत बड़े उत्पादन प्रतिष्ठान हैं (75 नोड्स, 250K रिकॉर्ड/सेकंड लगातार अंतर्ग्रहण), और नियमित रूप से 200+ नोड क्लस्टर पर परीक्षण करते हैं।

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

75 नोड्स, 250K रिकॉर्ड/सेकंड लगातार निगलना

एक एकल प्रोमेथियस सर्वर उस लोड से तीन गुना अधिक उत्पन्न कर सकता है।

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

एक एकल प्रोमेथियस सर्वर उस लोड से तीन गुना अधिक उत्पन्न कर सकता है।

हाँ, यह शायद एक बुरा उदाहरण है, कि उपयोगकेस मेट्रिक्स संग्रह नहीं है और मेरा मानना ​​​​है कि रिकॉर्ड आकार तुलनात्मक रूप से काफी बड़े हैं। मैं अपने लैपटॉप पर एक पसीने को तोड़ने के बिना ~ 200K मेट्रिक्स डेटापॉइंट लिखने/सेकंड में एक एकल नोड कुडु सेटअप को अधिकतम करने में सक्षम था (यह HTTP प्रॉक्सी परत में बाधा थी)। हालाँकि, मैंने वास्तव में खुदाई नहीं की है और ठोस संख्याएँ प्राप्त की हैं। निश्चित रूप से मेरी TODO सूची में।

विशेष रूप से - Kudu डेटा को प्राथमिक कुंजी इंडेक्स द्वारा क्रमबद्ध रखता है, इसलिए किसी विशेष मीट्रिक और समय सीमा के लिए स्कैन करने के लिए केवल आवश्यक डेटा पढ़ने की आवश्यकता होती है। परिणामस्वरूप, समय-श्रृंखला स्कैन में <10ms विलंबताएं हो सकती हैं।

अगर मेरे पास 1 बिलियन मेट्रिक्स वाला TSDB होता, और आपको एक वर्ष में उनमें से 100 से मेल खाने वाला एक एक्सप्रेशन देता, तो यह कैसे काम करता?

मेरे द्वारा पहले लिंक किए गए प्रायोगिक प्रोजेक्ट के साथ, यह (tag key, tag value) -> [series id] साइड टेबल में एक सेकेंडरी इंडेक्स रखता है, और फिर स्कैन करने के लिए परिणामी आईडी का उपयोग करता है। इसलिए यदि आपके पास एक बिलियन पॉइंट डेटासेट है, लेकिन आपकी क्वेरी मेट्रिक नाम, टैगसेट और समय के आधार पर केवल 100 पॉइंट्स से मेल खाती है, तो यह केवल उन 100 पॉइंट्स के लिए डेटा टेबल को स्कैन करेगा। OpenTSDB HBase का उपयोग कैसे करता है, लेकिन कुछ महत्वपूर्ण अंतरों के साथ इसका मॉडल तैयार किया गया है। इसके बारे में यहां कुछ और जानकारी है । पंक्ति के बजाय स्तंभ प्रारूप होने का एक बड़ा लाभ यह है कि इस तरह की एक प्रणाली को किसी बाहरी संघनन/डेटापॉइंट पुनर्लेखन की आवश्यकता नहीं होती है, जैसे OpenTSDB को HBase के लिए करना पड़ता है। कॉलमर एन्कोडिंग और कम्प्रेशन विकल्प पहले से ही निर्मित हैं और OpenTSDB जो कुछ भी करेगा उससे बेहतर है।

यह सिर्फ एक विशेष उदाहरण है कि कुडू के साथ टाइमसीरीज का भंडारण कैसे किया जा सकता है। यदि डेटा मॉडल OpenTSDB-शैली मीट्रिक/टैगसेट/टाइमस्टैम्प/मान की तरह नहीं दिखता है, तो इसे अलग तरीके से किया जा सकता है।

उन टैग मैचों में से एक (जिनमें से 2-4 होने की संभावना है) आसानी से 10M समय श्रृंखला के लिए हो सकता है। 5 मी रेजोल्यूशन के साथ एक वर्ष में 100 बार श्रृंखला के लिए, यह लगभग 10 बिलियन अंक है।

क्षमा करें, मैं अनुसरण नहीं करता। तो जैसे क्वेरी के लिए

SELECT * WHERE
   metric = some_metric AND
   timestamp >= 2015-01-01T00:00:00 AND
   timestamp < 2016-01-01T00:00:00 AND
   tag_a = "val_a" AND
   tag_b = "val_b" AND
   tag_c = "val_c";

यह समय-सारिणी का सेट ढूंढता है जहां tag_a = "val_a" , वह सेट जहां tag_b = "val_b" और वह सेट जहां tag_c = "val_c" । यह इन तीन सेटों को लेता है, चौराहे को ढूंढता है (श्रृंखला को खोजने के लिए जो तीनों विधेय से मेल खाता है), और फिर प्रत्येक के लिए समानांतर में एक स्कैन जारी करता है। इनमें से प्रत्येक स्कैन केवल आवश्यक डेटा को वापस पढ़ सकता है (हालाँकि डेटा कई विभाजनों में फैला हो सकता है)। स्कीमा वास्तव में उस मामले के लिए डिज़ाइन नहीं किया गया था जहां एक व्यक्तिगत (tag_key, tag_value) जोड़ी में लाखों मिलान श्रृंखलाएं हो सकती हैं, इसलिए संभवतः उस बाधा को ध्यान में रखते हुए इसे करने का एक अधिक कुशल तरीका है।

हां, job=node जैसे लेबल में आसानी से करोड़ों मेल खाने वाले मेट्रिक हो सकते हैं।

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

@ ब्रायन-ब्राज़ील अधिक आम तौर पर, ऐसा लगता है कि बाहरी स्टोरेज सिस्टम में आप जो खोज रहे हैं उसका एक अच्छा विचार है। क्या यह कहीं लिखा हुआ है, या आप स्पष्ट कर सकते हैं?

नमस्ते,

यह एक दिलचस्प धागा है, और हाँ, मैं भी पूछने वाला था कि क्या दीर्घकालिक भंडारण के बारे में कहीं कोई प्रस्ताव था। यह हमारे लिए संदर्भ प्राप्त करना और यह समझना आसान बना देगा कि क्या यह एक ऐसा कार्य है जिसे हम उठा सकते हैं और प्रयोग कर सकते हैं।

धन्यवाद,
गौतम।

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

वास्तविक रूप से उन आवश्यकताओं को संभालने में सक्षम होने वाला एक सूचकांक होगा a
वास्तविक नमूना डेटा संग्रहीत करने से अलग समस्या।
हो सकता है कि यह उस परत द्वारा प्रदान की गई कुछ लुकअप क्षमता का लाभ उठा सके।

थू, जून 9, 2016 को दोपहर 12:51 बजे ब्रायन ब्राजील के नोटिफिकेशन @github.com
लिखा था:

#1487 के पीछे का विचार https://github.com/prometheus/prometheus/pull/1487
उपयोगकर्ताओं को समाधानों के साथ प्रयोग करने की अनुमति देने के लिए एक इंटरफ़ेस को उजागर करना है।
पूर्ण-समाधान काफी कठिन है, हालांकि इसके अधिक विवश रूप हैं
समस्या (जैसे अनुक्रमण की आवश्यकता नहीं) अधिक सुगम हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/prometheus/prometheus/issues/10#issuecomment -224754971,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe/AEuA8ic17IjFeYvqWQSZvGBp35BcK4tHks5qJ0dmgaJpZM4AV6IB
.

नमस्ते,

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

धन्यवाद,
गुस्तावो

कोई निर्धारित समयरेखा नहीं है, हालांकि मुझे उस समय तक कुछ संभव होने की उम्मीद है। #1487 हमें रास्ते पर ले जाने का एक प्रस्ताव है, और वीव के पास एक प्रस्ताव भी था जिसमें पढ़ने और लिखने दोनों पहलुओं को शामिल किया गया था।

एक युगल प्रश्न:

1. क्या आपने हाल ही में InfluxDB देखा है? जबकि क्लस्टरिंग अब उपलब्ध नहीं है (और चूसा हुआ IMHO), एक ओपन-सोर्स प्रोजेक्ट है जिसे influxdb-relay कहा जाता है जो कई InfluxDB नोड्स के बीच प्रतिकृति और लोड-बैलेंसिंग को संभालता है। https://github.com/influxdata/influxdb-relay/blob/master/README.md
2. क्या आपने रियाक टीएस पर विचार किया है? मैंने किसी को इसका जिक्र करते नहीं देखा, इसलिए मुझे लगा कि मैं पूछूंगा। http://basho.com/products/riak-ts/

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

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

बस सोच रहा था कि क्या आप लोगों के पास Amazon EMR के शीर्ष पर बने OpenTSDB स्टोरेज के साथ Prometheus का उपयोग करने के बारे में कोई विचार है? ऐसा लगता है कि इससे क्लस्टर रखरखाव का बोझ कम हो सकता है, क्या आप इससे सहमत हैं और यदि ऐसा है तो क्या OpenTSDB निर्यात एक बेहतर विकल्प होगा?

कोई भी समाधान समय-समय पर काम करने योग्य होना चाहिए, जिसका अर्थ है कि हम Hadoop को क्लाउड पर नहीं सौंप सकते (और आखिरी बार मैंने जाँच की, EMR वैसे भी पूरी तरह से प्रबंधित समाधान नहीं है)।

Elasticsearch 5 (वर्तमान में Alpha5 पर) के बारे में क्या? उन्होंने घोषणा की कि नया संस्करण ल्यूसीन 6 का उपयोग करेगा, जिसमें विशेष रूप से संख्यात्मक डेटा अनुक्रमण के लिए बहुत सारे अनुकूलन हैं।

लोचदार ब्लॉग से:

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

मुझे नहीं लगता कि ES प्राथमिक डेटा स्टोर के लिए एक उपयुक्त समाधान है, और डेटा का प्रकार और मात्रा वास्तव में इसका मतलब नहीं है।

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

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

@sybrandy बिल्कुल मेरी बात थी, आज के लिए इलास्टिक स्टैक निगरानी पर अधिक केंद्रित है। उदाहरण के लिए, beats उपकरण प्रोमेथियस में exporters उद्देश्य के समान हैं। और आउटपुट ES में चला जाता है।

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

ES आमतौर पर लॉग के लिए उपयोग किया जाता है, मेट्रिक्स एक बहुत ही अलग उपयोग के मामले हैं। उदाहरण के लिए लुसीन अप्रासंगिक है।

साथ ही, मुझे नहीं लगता कि अगर इसे ठीक से सेट किया गया है तो वॉल्यूम एक चिंता का विषय होगा।

मैं ES को पेटाबाइट स्केल डेटा सेट के साथ नहीं जोड़ूंगा, जिन्हें वर्षों तक सुरक्षित रूप से संग्रहीत करने की आवश्यकता होती है, जिसके बारे में हम यहां बात कर रहे हैं। यह एक टेक्स्ट सर्च इंजन है, बल्क डेटा स्टोर नहीं।

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

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

इसे अज्ञेयवादी दृष्टिकोण से देखना समझदारी भरा लग रहा था। यदि प्रोमेथियस से डेटा प्राप्त करने का एक अच्छी तरह से प्रलेखित तरीका है तो हम परीक्षण के लिए इसके खिलाफ समाधान तैयार कर सकते हैं।

DalmatinerDB को समय श्रृंखला डेटा के लिए डिज़ाइन किया गया था और यह Riak Core (KV नहीं) पर आधारित है और इसमें एक Postgres अनुक्रमणिका है जिसे विशेष रूप से आयामी समय श्रृंखला प्रश्नों को तेज़ बनाने के लिए डिज़ाइन किया गया है। हम 62 बिट सटीक भंडारण को 64 बिट या उससे अधिक तक बढ़ाने के लिए कुछ अतिरिक्त काम कर सकते हैं। वर्तमान में हम क्वेरी भाषा सुविधा को तुलनीय बनाने की दिशा में काम कर रहे हैं।

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

इस पर कुछ हलचल देखना अच्छा होगा क्योंकि ऐसा प्रतीत होता है कि यह अब कुछ वर्षों से चल रहा है। मुझे लगता है कि कोर प्रोमेथियस प्रोजेक्ट टीम के बाहर बहुत सारे काम किए जा सकते हैं और बनाए रखा जा सकता है यदि इंटरफ़ेस को केवल परिभाषित, जारी और पुनरावृत्त किया गया था।

मुझे लगता है कि कोर प्रोमेथियस प्रोजेक्ट टीम के बाहर बहुत सारे काम किए जा सकते हैं और बनाए रखा जा सकता है यदि इंटरफ़ेस को केवल परिभाषित, जारी और पुनरावृत्त किया गया था।

मेरा भी यही मत है। #1487 इसका एक तरीका है।

मुझे लगता है कि इंटरफ़ेस के लिए अन्य स्वामित्व के रूप में बहुत से लोग बोर्ड में हैं
डीबी का भी उपयोग किया जा सकता है (जो वर्तमान सुविधा के साथ इनलाइन नहीं हो सकता है
कल्पना)
गुरु, 11 अगस्त 2016 को पूर्वाह्न 7:12 बजे ब्रायन ब्राजील सूचनाएं @github.com
लिखा था:

मुझे लगता है कि बहुत सारे काम किए जा सकते हैं और बाहर रखा जा सकता है
कोर प्रोमेथियस प्रोजेक्ट टीम अगर इंटरफ़ेस को अभी परिभाषित किया गया था, तो जारी किया गया
और पर पुनरावृति।

मेरा भी यही मत है। #1487
https://github.com/prometheus/prometheus/pull/1487 एक दृष्टिकोण है
यह।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/prometheus/prometheus/issues/10#issuecomment -239006063,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AA-K-9aHZrtjg3cWCVWml-ajEKoRyu3Oks5qej7CgaJpZM4AV6IB
.

मैं ES को पेटाबाइट स्केल डेटा सेट के साथ नहीं जोड़ूंगा, जिन्हें वर्षों तक सुरक्षित रूप से संग्रहीत करने की आवश्यकता होती है, जिसके बारे में हम यहां बात कर रहे हैं। यह एक टेक्स्ट सर्च इंजन है, बल्क डेटा स्टोर नहीं।

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

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

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

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

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

इस पीआर का विषय दीर्घकालिक भंडारण है। प्रोमेथियस पहले से ही अल्पकालिक भंडारण को संभालता है।

आह, क्षमा करें। बहुत समय हो गया है जब मैंने शीर्ष पढ़ा था, मैं भूल गया था।

मैंने समय श्रृंखला डेटाबेस की तुलना करने वाली एक स्प्रेडशीट शुरू की है जो शायद इस टिकट के लिए काफी प्रासंगिक है।

https://docs.google.com/spreadsheets/d/1sMQe9oOKhMhIVw9WmuCEWdPtAoccJ4a-IuZv4fXDHxM/edit#gid =0

अगर कोई बदलाव करने के अधिकार संपादित करना चाहता है तो मुझे बताएं और मैं एक आमंत्रण भेजूंगा।

इसके साथ जाने के लिए एक संबंधित ब्लॉग है, लेकिन यह वास्तव में इस धागे में भावना को बताता है, इसलिए शायद यह सब उपयोगी नहीं है।

https://blog.dataloop.io/top11-open-source-time-series-databases

हम एक ऐसे राज्य की ओर बढ़ रहे हैं जहां DalmatinerDB लंबी अवधि के भंडारण के रूप में Prometheus के साथ अच्छी तरह से काम करेगा। यह लिखने में बहुत तेज़ है इसलिए डेटा के लायक कई प्रोमेथियस सर्वरों को आसानी से संभाल सकता है। यहां कुछ जॉयंट वीएम पर प्रति सेकंड 3 मिलियन लिखने वाला एक प्रतिलिपि प्रस्तुत करने योग्य बेंचमार्क दिखाया गया है:

https://gist.github.com/sacreman/b77eb561270e19ca973dd5055270fb28

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

https://gist.github.com/sacreman/9015bf466b4fa2a654486cd79b777e64

केवल नकारात्मक मूल्य परिशुद्धता है। मैंने एक टिकट उठाया है ताकि हम जांच कर सकें:

https://github.com/dalmatinerdb/dalmatinerdb/issues/77

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

@sacreman धन्यवाद, महान तुलना। खुशी है कि प्रोमेथियस ने केवल 5/5 अंकों के साथ क्वेरी भाषा प्रतियोगिता जीती :) मैं प्रोमेथियस में सामान्य समय-श्रृंखला गणनाओं के लिए SQL बोलियों पर PromQL पसंद करता हूं ...

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

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

@juliusv यह बहुत अच्छी खबर है! अब जब मैं भविष्य के ब्लॉग को शीर्ष 10 में सभी ओपन सोर्स मॉनिटरिंग टूल्स की रैंकिंग करता हूं तो मैं प्रोमेथियस/ग्राफाना/डेलमैटिनरडीबी को नंबर 1 के रूप में रैंक कर सकता हूं :)

पहले संस्करण पर नजर रखेंगे और फिर खेलना शुरू करेंगे।

@sacreman हमारे द्वारा लिए गए नोट्स भी देखें (हमने पहले एक सामान्य रोडमैप चर्चा की, फिर सामान्य रिमोट एपीआई): https://docs.google.com/document/d/1Qj_m-lbatySAU0vsVfAPG7mduN1-nevrpD85uQhi4sY/edit#heading =h.6xcexetco4g

@juliusv कि सब अच्छा लग रहा है। DalmatinerDB में एक मेट्रिक्स प्रॉक्सी है जिसे हम पढ़ने और लिखने दोनों के लिए अपडेट करेंगे।

https://github.com/dalmatinerdb/ddb_proxy

हम इसे ऐसा कर सकते हैं:

@sacreman अच्छा लगता है!

इसके लायक क्या है, हम ताना 10 (www.warp10.io) को दीर्घकालिक भंडारण के लिए एक व्यवहार्य समाधान बनाने के लिए प्रोमेथियस समुदाय के साथ काम करने को तैयार हैं।

Borgmon/promql की दी गई विशेषताओं को शायद WarpScript द्वारा पूरी तरह से कवर किया जा सकता है, यह मेरी (पक्षपाती) राय पर विचार करने के लिए एक बहुत ही लचीला समाधान बनाता है।

@ एचबीएस कूल। योजना अभी भी https://github.com/prometheus/prometheus/issues/10#issuecomment -242937078 में उल्लिखित है, इसलिए हमारे पास प्रोमेथियस में ही कोई विशिष्ट एकीकरण नहीं होगा, केवल सामान्य एक, और फिर लोग निर्माण कर सकते हैं वे इसके साथ जो कुछ भी चाहते हैं। मुझे Warp 10 एकीकरण देखकर खुशी होगी।

My $dayjob की आवश्यकताएं हैं जो हमें कुछ मेट्रिक्स के दीर्घकालिक (>5 वर्ष) भंडारण की ओर धकेलने वाली हैं, या कम से कम एक या अधिक मीट्रिक पर अधिक लंबे अंतराल पर डेटा डाउनसैंपलिंग का प्रदर्शन कर रही हैं। प्रोमेथियस में यह एक "पारदर्शी" सुविधा होना बहुत सुविधाजनक होगा, जहां डेटा लंबी अवधि के स्टोर में स्थानांतरित हो जाएगा और लंबे समय तक चलने वाले प्रश्नों पर फिर से आयात किया जाएगा, भले ही पुराने डेटा को देखने के कारण एक्सेस करने में धीमा हो डिस्क विलंबता, कैश न किए गए अंक, एपीआई देरी आदि। मैं एक उद्देश्यपूर्ण अस्पष्ट शब्द के रूप में "महत्वपूर्ण" छोड़ देता हूं। मैं उम्मीद कर रहा हूं कि हमें आवश्यक सुविधाओं को प्राप्त करने के लिए डेटा को दो सिलोस में विभाजित करने से बचने की उम्मीद है, और मेरे विचार/ग्राफ़/आदि को फिर से लिखना होगा। कि मेरे पास ग्रेफाना के साथ प्रोमेथियस के शीर्ष पर रखा गया है। हम शायद इस क्षमता के विकास के लिए कुछ डॉलर/यूरो लगाने को भी तैयार हैं क्योंकि यह कई मुद्दों को हल करेगा और हमारे पक्ष में कुछ समय बचाएगा। मुझे पिछले तीन वर्षों में विचारों के लिए इस धागे को पढ़ने के लिए प्रोत्साहित किया गया है, और मैं उम्मीद कर रहा हूं कि हाल की गतिविधि कोड चलाने के लिए अच्छा है। वैकल्पिक रूप से, डेटा डाउनसैंपलिंग क्षमता होने से हमारी विशेष जरूरतों को हल करने में काफी मदद मिल सकती है।

v1.4.1 प्रोमेथियस बाइनरी में चेक किया गया, वे "-storage.remote.influxdb. " और "-storage.remote.opentsdb " पैरामीटर अभी भी मौजूद हैं, क्या उन्हें हटा दिया जाना चाहिए?

$ prometheus --help
usage: prometheus [<args>]
...
   -storage.remote.graphite-address
      The host:port of the remote Graphite server to send samples to.  None, if empty.

   -storage.remote.graphite-prefix
      The prefix to prepend to all metrics exported to Graphite. None, if empty.

   -storage.remote.graphite-transport "tcp"
      Transport protocol to use to communicate with Graphite. 'tcp', if empty.

   -storage.remote.influxdb-url
      The URL of the remote InfluxDB server to send samples to. None, if empty.

   -storage.remote.influxdb.database "prometheus"
      The name of the database to use for storing samples in InfluxDB.

   -storage.remote.influxdb.retention-policy "default"
      The InfluxDB retention policy to use.

   -storage.remote.influxdb.username
      The username to use when sending samples to InfluxDB. The corresponding password must be provided via the INFLUXDB_PW environment variable.

   -storage.remote.opentsdb-url
      The URL of the remote OpenTSDB server to send samples to. None, if empty.
...

@linfan उन्हें किसी बिंदु पर हटा दिया जाएगा, लेकिन यह अभी तक तय नहीं किया गया है। कम से कम प्रोमेथियस 2.0 के साथ, मुझे लगता है, अगर उससे पहले ठीक नहीं है।

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

OpenTSDB को चलाना बहुत कठिन नहीं है, खासकर यदि आप DB को Google या आंतरिक हाओप टीम में लोड कर सकते हैं (हालाँकि यह वास्तव में MapReduce क्लस्टर के साथ सह-स्थित नहीं होना चाहिए, एक छोटे से समर्पित पर सबसे अच्छा करता है)। आपके पास जितने क्षेत्र सर्वर होंगे, उसकी चौड़ाई के साथ नमकीन बनाना सक्षम करें, अधिकतम 12. लगभग एक ही नॉब जिसके बारे में आपको चिंता करने की आवश्यकता है, क्योंकि यह तालिका निर्माण को प्रभावित करता है।

प्रारंभिक सेटअप पर ट्यूनिंग करने के लिए HBase बहुत कठिन है। यदि आपके पास मुट्ठी भर से अधिक सर्वर हैं, तो अधिकतम क्षेत्र आकार को 300 या 400GB तक क्रैंक करें। सुनिश्चित करें कि आप HBase 1.2+ का उपयोग कर रहे हैं ताकि छोटे क्षेत्रों को फैलने से रोकने के लिए क्षेत्र नॉर्मलाइज़र चल सके। मैंने इस पर अन्य सलाह देखी है, लेकिन यह बहुत से क्षेत्रों का ट्रैक रखने के लिए क्षेत्रीय सर्वर और टीएसडी के भीतर संसाधनों का एक टन उपयोग करता है। बहुत से क्षेत्रों ने कोल्ड स्टार्ट प्रदर्शन और नोड डीकॉम/रिबैलेंस को भी नुकसान पहुंचाया है। आप बहुत बड़े डेटासेट के लिए केवल कुछ सौ से कुछ हज़ार चाहते हैं। कुल मिलाकर लगभग 40 नॉब हैं जिन्हें आपको क्रैंक करना है, एक विशाल जेवीएम हीप (या मध्यम आकार के ढेर और ऑफहीप एल 2 कैश) और जी 1 कचरा संग्रहकर्ता के साथ जोड़ा गया है ताकि सबसे खराब स्थिति को लगभग 100 एमएमएस तक रखा जा सके। उचित सेटअप के बाद, यह काफी हद तक बंद है। आप तेजी से नोड्स जोड़ और हटा सकते हैं, और रैखिक मापनीयता के करीब पहुंच सकते हैं। मुझे इससे तब तक नफरत थी जब तक हमने जादू HBase ट्यूनिंग का पता नहीं लगा लिया, और अब यह बहुत अच्छा और कम रखरखाव है।

FYI करें: हम Prometheus (https://github.com/criteo/biggraphite/issues/95) के लिए रिमोट स्टोरेज के रूप में प्रयोग करने योग्य बनाने के लिए BigGraphite में लेबल के लिए समर्थन जोड़ेंगे।

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

एपीआई वह है जो यह है, किसी भी बैचिंग या लोड संतुलन को आपके अंत में करने की आवश्यकता है।

मेरी चिंता यह है कि मुझे यकीन नहीं है कि वर्तमान एपीआई बहुत अधिक डुप्लिकेट किए गए काम के बिना कुछ विश्वसनीय बनाना आसान बनाता है।

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

रीड पाथ पर, बेसिक राउंड रॉबिन लोड बैलेंसिंग + सर्विस डिस्कवरी की शायद जरूरत होगी।

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

ठीक है, बफरिंग/बैचिंग के लिए सहमत हूं। कम से कम पहले कदम के रूप में।

दूसरा बिंदु रिमोट स्टोरेज के लिए सर्विस डिस्कवरी था, आप क्या सोचते हैं? (आईएमएचओ यह अलर्टमैनेजर के लिए कुछ हद तक समान तर्क है: यदि आप नेटवर्क परत पर इसके आसपास हैक नहीं करना चाहते हैं तो आपको इसकी आवश्यकता है)

इसके लिए एसडी निश्चित है। लोड संतुलन निर्धारित नहीं है, मुझे विश्वास नहीं है कि प्रोमेथियस में है।

वर्तमान स्थिति क्या है?
अगर कुछ अन्य लोग प्लग करने योग्य एपीआई स्टोरेज प्राप्त करने में मदद कर सकते हैं?

@ डैनी-एम यहाँ कई भाग हैं:

• लेखन पथ: यह मौजूद है और आज इसका उपयोग किया जा सकता है। देखें https://prometheus.io/docs/operating/configuration/#

• रीड पाथ, प्रोमेथियस रिमोट स्टोरेज से वापस पढ़ रहा है। यह अभी तक अस्तित्व में नहीं है, लेकिन मुझे उम्मीद है कि अगले एक या दो महीनों में इसका प्रारंभिक संस्करण तैयार हो जाएगा।

• रिमोट स्टोरेज ही: उपर्युक्त जेनेरिक रीड/राइट इंटरफेस का उपयोग करके कोई भी रिमोट स्टोरेज कार्यान्वयन बना सकता है (ठीक है, फिलहाल, केवल लिखने वाला ही मौजूद है)। दो बहुत अलग वास्तविक दुनिया के उदाहरण पहले से मौजूद हैं (https://github.com/weaveworks/cortex और https://github.com/ChronixDB/chronix.ingester)। कई कार्यान्वयन होने की संभावना है, क्योंकि अलग-अलग लोगों को अलग-अलग चीजों की आवश्यकता होती है। लेकिन हो सकता है कि कोई ऐसा हो जो इतनी अच्छी तरह से किया गया हो, चलाने में आसान हो, और सामान्य रूप से उपयोगी हो कि वह "डिफ़ॉल्ट" बन जाए जिसकी हम अनुशंसा करते हैं। यह वास्तव में अभी तक स्पष्ट नहीं है, मैं लोगों को कम से कम लेखन पथ के साथ प्रयोग शुरू करने के लिए प्रोत्साहित करता हूं।

https://github.com/digitalocean/vulcan को न भूलें

मैं अभी रिमोट रीड पर काम कर रहा हूं।

@brian-brazil et के लिए कुछ प्रश्न/अंक। अल.:

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

ठंडा ! आप जिस एपीआई की योजना बना रहे हैं उसे देखना दिलचस्प होगा। आपने वर्तमान में जो कहा वह अच्छा लग रहा है।

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

@iksaif

आप जिस एपीआई की योजना बना रहे हैं उसे देखना दिलचस्प होगा।

यह मूल रूप से कॉर्टेक्स के आंतरिक क्वेरी अनुरोध / प्रतिक्रिया की तरह दिखेगा: https://github.com/weaveworks/cortex/blob/master/cortex.proto#L24 -L28
https://github.com/weaveworks/cortex/blob/master/cortex.proto#L24 -L32

हालांकि, हम इसे सादे HTTP पर भेजेंगे, जीआरपीसी पर नहीं।

हो सकता है कि भविष्य में स्थानीय भंडारण की प्रारंभिक सीमा (जब आवश्यक हो) तक दूरस्थ भंडारण को क्वेरी करने का विकल्प होना दिलचस्प होगा।

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

मुझे लगता है कि आप अभी के लिए हर बार रिमोट स्टोरेज को क्वेरी करने की योजना बना रहे हैं और हम बाद में देखेंगे कि एक प्रकार का कैशिंग (डिस्क और/या मेमोरी) है या नहीं?

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

मैं कई रिमोट रीड एंडपॉइंट्स (पुनः लोड करने योग्य कॉन्फ़िगरेशन के माध्यम से) के लिए जा रहा हूं, जैसे कि हमारे पास कई रिमोट लेखक हैं। इसके खिलाफ कुछ बोल रहे हैं? मैं पहले पास में एसडी समर्थन की योजना नहीं बना रहा हूं, बस एक स्थिर यूआरएल।

ये आवश्यक हैं, लेकिन v1 में होना आवश्यक नहीं है।

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

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

V1 के लिए, मैं हमेशा सबकुछ पूछता हूं।

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

क्या रिमोट रीड में रिलेबलिंग भी होनी चाहिए? हालांकि मैं शायद इसे पहले छोड़ दूंगा।

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

हमें बाहरी लेबलों को सीधे पास करने की भी आवश्यकता हो सकती है, लेकिन आइए थोड़ा प्रतीक्षा करें और देखें कि क्या इसकी आवश्यकता है क्योंकि मुझे आशा है कि यह नहीं होगा।

यह मूल रूप से कॉर्टेक्स के आंतरिक क्वेरी अनुरोध/प्रतिक्रिया की तरह दिखेगा

एलजीटीएम

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

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

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

@iksaif ठीक है हाँ, तो आप अवधारण समय के बारे में बात नहीं कर रहे हैं, लेकिन प्रोमेथियस के वर्तमान डेटाबेस में सबसे पुराना नमूना टाइमस्टैम्प। हम वर्तमान में उस पर नज़र नहीं रखते हैं, लेकिन यह आम तौर पर अधिक समझ में आता है, हाँ।

प्रश्न यह है कि क्या हम v1 में प्रति-क्वेरी/नियम एलटीएस निर्धारण चाहते हैं। यह डिजाइन को थोड़ा प्रभावित कर सकता है, इसलिए मैं इसके बारे में कम से कम सोचूंगा।

यह v1 नहीं है, लेकिन यह कुछ ऐसा है जो हमारे पास उत्पादन के उपयोग में आने से पहले होना चाहिए क्योंकि यह विश्वसनीयता के लिए महत्वपूर्ण है।

@ ब्रायन-ब्राज़ील निश्चित रूप से!

दूसरी बात पर विचार करना है कि एपीआई कई वेक्टर चयनकर्ताओं के लिए अनुमति देता है (प्रत्येक offset कारण अपने स्वयं के टाइमस्टैम्प के साथ), ताकि एलटीएस अनुकूलित कर सकें और बेहतर थ्रॉटलिंग/दुरुपयोग प्रबंधन कर सकें।

@ ब्रायन-ब्राज़ील ओह हाँ, मेरे पास कई वेक्टर चयनकर्ता सेट हैं, लेकिन विभिन्न ऑफ़सेट के बारे में बहुत अच्छी बात है!

एक साधारण स्थिर अवधि पर्याप्त नहीं है, क्योंकि रिमोट स्टोरेज को अभी तक पकड़ा नहीं जा सकता है या प्रोमेथियस के पास और पीछे जाने की अवधारण हो सकती है। मुझे लगता है कि यह कुछ ऐसा है जिसे हमें समझना होगा

मुझे नहीं लगता कि प्रोमेथियस का प्रतिधारण आगे पीछे जाना वास्तव में यहाँ एक मुद्दा है, जब तक कि रिमोट (पहले से ही) डेटा प्रदान कर सकता है। सबसे खराब स्थिति डाउनसैंपलिंग के साथ है कि आप ग्रैन्युलैरिटी खो देते हैं।

@pilhuhn मेरा मतलब यह दूसरे तरीके से था: यदि आपके पास 15d का प्रोमेथियस प्रतिधारण है और आप रिमोट स्टोरेज से केवल 15d से पुराने डेटा को क्वेरी करते हैं, तो इसका मतलब यह नहीं है कि प्रोमेथियस के पास पहले से ही 15d से कम का सभी डेटा होगा (के कारण) भंडारण पोंछ या जो कुछ भी)।

ठीक है, पहले पुनरावृत्ति के लिए हम हर जगह से सभी समय श्रेणियों को क्वेरी करने जा रहे हैं।

यहां रिमोट रीड इंटीग्रेशन के लिए एक डब्ल्यूआईपी पीआर है जो किसी के लिए भी जल्दी देखना चाहता है: https://github.com/prometheus/prometheus/pull/2499

मैं प्रोमेथियस से opentsdb में मेट्रिक्स भेजने के लिए Remote_storage_adapter का उपयोग करने का प्रयास कर रहा हूं। लेकिन मुझे लॉग में ये त्रुटियां मिल रही हैं:

WARN[0065] cannot send value NaN to OpenTSDB, skipping sample &model.Sample{Metric:model.Metric{"instance":"localhost:9090", "job":"prometheus", "monitor":"codelab-monitor", "location":"archived", "quantile":"0.5", "__name__":"prometheus_local_storage_maintain_series_duration_seconds"}, Value:NaN, Timestamp:1492267735191}  source=client.go:78

WARN[0065] Error sending samples to remote storage       err=invalid character 'p' after top-level value num_samples=100 source=main.go:281 storage=opentsdb

मैंने समान परिणामों के साथ opentsdb के बजाय influxdb का उपयोग करने का भी प्रयास किया है:

EBU[0001] cannot send value NaN to InfluxDB, skipping sample &model.Sample{Metric:model.Metric{"job":"prometheus", "instance":"localhost:9090", "scrape_job":"ns1-web-pinger", "quantile":"0.99", "__name__":"prometheus_target_sync_length_seconds", "monitor":"codelab-monitor"}, Value:NaN, Timestamp:1492268550191}  source=client.go:76

यहां बताया गया है कि मैं कैसे Remote_storage_adapter प्रारंभ कर रहा हूं:

# this is just for influxdb, i make the appropriate changes if trying to use opentsdb
./remote_storage_adapter -influxdb-url=http://138.197.107.211:8086 -influxdb.database=prometheus -influxdb.retention-policy=autogen -log.level debug

यहाँ प्रोमेथियस विन्यास है:

global:
  scrape_interval:     15s # By default, scrape targets every 15 seconds.

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
    monitor: 'codelab-monitor'

remote_write:
  url: "http://localhost:9201/write"

क्या रिमोट_स्टोरेज_एडाप्टर को कॉन्फ़िगर करने के तरीके के बारे में मुझे कुछ गलत समझ रहा है?

@tjboring न तो OpenTSDB और न ही InfluxDB फ्लोट64 NaN (संख्या नहीं) मानों का समर्थन करता है, इसलिए नमूने भेजते समय इन नमूनों को छोड़ दिया जाता है। हमने InfluxDB को इस समस्या का उल्लेख किया है, और यदि हम भाग्यशाली हैं, तो वे भविष्य में कभी-कभी NaN मूल्यों का समर्थन करेंगे, या शायद हम एक और समाधान ढूंढ सकते हैं।

ओपनटीएसडीबी मुद्दा: https://github.com/OpenTSDB/opentsdb/issues/183
InfluxDB मुद्दा: https://github.com/influxdata/influxdb/issues/4089

मुझे यकीन नहीं है कि invalid character 'p' after top-level value त्रुटि कहां से आती है।

@juliusv opentsdb/influxdb मुद्दों के संकेत के लिए धन्यवाद। मैं केवल कंसोल पर त्रुटि संदेश देख रहा था और सोचा कि कुछ भी नहीं लिखा जा रहा था, यह महसूस नहीं कर रहा था कि वे केवल नमूने हैं जिन्हें छोड़ दिया जा रहा है। मैंने तब से पुष्टि की है कि नमूने वास्तव में इसे रिमोट स्टोरेज डीबी में बना रहे हैं। :)

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

https://prometheus.io/docs/operating/configuration/#
https://prometheus.io/docs/operating/configuration/#

किसी भी शरीर ने कंटेनर के साथ कोशिश की? कृपया डॉकरफाइल पेस्ट करें

क्योंकि मैं docker "prom/prometheus" संस्करण 1.6 में "remote_storage_adapter" निष्पादन योग्य फ़ाइल नहीं ढूंढ पा रहा हूं

/prometheus # find / -name remote_storage_adapter
/prometheus #

कृपया

@prasenforu मैंने वर्तमान मास्टर कोड से Remote_storage_adapter के साथ एक डॉकर छवि बनाई है: gra2f/remote_storage_adapter, इसका उपयोग करने में संकोच न करें।

@juliusv मुझे @tjboring वाले

time="2017-04-21T17:45:00Z" स्तर = चेतावनी संदेश = "ग्रेफाइट को मान NaN नहीं भेज सकता, नमूना और मॉडल को छोड़ देता है। नमूना { मीट्रिक: मॉडल। मीट्रिक {\"__name__\":\"prometheus_target_sync_length_seconds\", \"मॉनिटर\":\"कोडलैब-मॉनिटर\", \"job\":\"prometheus\", \"instance\":\" localhost:9090\ ", \"scrape_job\":\"prometheus\ ", \"मात्रा\":\"0.9\"}, मान:NaN , टाइमस्टैम्प:1492796695772 }" स्रोत = "क्लाइंट.गो: 90"

लेकिन मैं ग्रेफाइट का उपयोग कर रहा हूँ। यह ठीक है क्या?

@ दुःखरहित

क्या आप ग्रेफाइट में अन्य मेट्रिक्स देखते हैं जो आप जानते हैं कि प्रोमेथियस से आए हैं?

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

@tjboring हाँ, मैं ग्रेफाइट में कुछ मीट्रिक देख सकता हूं और मेरे लिए और अधिक अजीब बात यह है कि मैं समझ नहीं पा रहा हूं कि कुछ वहां क्यों हैं और कुछ नहीं हैं। उदाहरण के लिए, sy और us प्रति CPU ग्रेफाइट में संग्रहीत है लेकिन लोड औसत नहीं है।

@ दुःखरहित

छवि खोजने में सक्षम नहीं, क्या आप कृपया यूआरएल साझा कर सकते हैं।

अग्रिम में धन्यवाद।

@prasenforu बस भागो
$ docker pull gra2f/remote_storage_adapter
आपकी कमांड लाइन में, आपको बस इतना ही चाहिए

@ दुःखरहित

धन्यवाद।

@mattbostock जैसा आपने सुझाव दिया, मैं इस मुद्दे को बंद कर रहा हूं। हमें भविष्य में और अधिक विशिष्ट रिमोट-स्टोरेज संबंधी मुद्दों को खोलना चाहिए।

हमारी मेलिंग सूचियों या आईआरसी (https://prometheus.io/community/) पर आगे के उपयोग के प्रश्न सबसे अच्छे तरीके से पूछे जाते हैं।

@ दुःखरहित

मैं छवियों को देख रहा था, मैंने देखा कि फ़ाइल Remote_storage_adapter /usr/bin . में थी

लेकिन बाकी प्रोमेथियस फ़ाइल और वॉल्यूम नहीं है,

~ # find / -name remote_storage_adapter
/usr/bin/remote_storage_adapter
~ # find / -name prometheus.yml
~ # find / -name prometheus

वैसे भी क्या आप मुझे "gra2f/remote_storage_adapter" का डॉकरफाइल भेज सकते हैं

@prasenforu
रिमोट स्टोरेज एडेप्टर का उपयोग करने के लिए आपको मुख्य प्रोमेथियस निष्पादन योग्य की आवश्यकता नहीं है। उसके लिए प्रोम/प्रोमेथियस छवि का प्रयोग करें।
Dockerfile के लिए क्या संबंधित है - यह बस इतना कर रहा है कि इसमें प्रीबिल्ट रिमोट_स्टोरेज_एडाप्टर कॉपी करें और इसे चलाएं, बस।

अगर कोई इसका परीक्षण करना चाहता है (जैसे मुझे इसकी आवश्यकता है), मैंने इसे स्थानीय रूप से चलाने और चलाने के लिए एक छोटा डॉकर-कंपोज़ आधारित सेटअप लिखा - https://github.com/gdmello/prometheus-remote-storage।

इस थ्रेड को स्वचालित रूप से लॉक कर दिया गया है क्योंकि इसे बंद करने के बाद हाल ही में कोई गतिविधि नहीं हुई है। कृपया संबंधित बग के लिए एक नया मुद्दा खोलें।