🐈 💒 🎣 सेंसु - निगरानी ढांचा 🛵 🙇🏽 👩🏾‍🤝‍👩🏻

थोड़ा इतिहास

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

असंतोष की इस लहर का परिणाम संवेदना और रीमैन जैसी दिलचस्प उपयोगिताओं की समस्याओं और ध्यान आकर्षित करने की एक विशाल चर्चा थी।

2013 में, समुदाय में हैशटैग बदल गया है - अब यह #monitoringlove है । यह ओपनसोर्स मॉनिटरिंग यूटिलिटीज के विकास के कारण हुआ।

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

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

Sensu के बारे में मुख्य तथ्य:

* रूबी में लिखा, EventMachine का उपयोग करता है (मैं अजगर पसंद करेंगे, लेकिन ठीक है)।
* JSON में पुष्टि करता है
* Nagios से प्लगइन्स का उपयोग कर सकते हैं।
* RabbitMQ के माध्यम से, PUSH मोड में काम करता है, जब क्लाइंट खुद सर्वर को भेजते हैं
उपलब्ध होते ही परीक्षा परिणाम।
* DEB, RPM और यहां तक कि MSI पैकेज भी हैं।
* बावर्ची के लिए कठपुतली और रसोई की किताब के लिए मॉड्यूल हैं।

नीचे दी गई छवि सेंसू के संचालन को दिखाती है। मेरी राय में, सब कुछ बहुत तार्किक है, और इस तरह की कार्य योजना "बॉक्स से बाहर" स्केलिंग और गलती सहनशीलता देती है।

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

मूल अवधारणाएँ

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

हमारे पास निम्नलिखित संस्थाएँ हैं:

ग्राहक (क्लाइंट)

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

आत्म-पहचान के लिए, उसे एक कॉन्फ़िगरेशन की आवश्यकता होती है जो कुछ इस तरह दिखता है (प्रलेखन से लिया गया):

{ "client": { "name": "i-424242", "address": "127.0.0.1", "subscriptions": [ "production", "webserver", "mysql" ] } }

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

सत्यापन (चेक)

चेक ग्राहकों और उनके मापदंडों पर चलने वाली कमांड का निर्धारण करते हैं। पूरी तरह से Nagios प्लगइन्स के साथ संगत, अर्थात्। चेक की सफलता के लिए एक मानदंड के रूप में निकास कोड का उपयोग करें, और डेटा स्रोत के रूप में STDOUT या STDERR। चेकों को सेंसु-सर्वर कॉन्फ़िगरेशन में कॉन्फ़िगर किया गया है, एक विशिष्ट चेक इस तरह दिखता है (उदाहरण प्रलेखन से):

 { "checks": { "chef_client": { "command": "check-chef-client.rb", "subscribers": [ "production" ], "interval": 60 "handlers": [ "pagerduty", "irc" ] } } }

यहां ब्याज की फिर से सदस्यता और संचालकों हैं। सदस्यता निर्धारित करती है कि यह कमांड किस क्लाइंट पर चलेगी।

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

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

हैंडलर (हैंडलर)

हैंडलर उन कमांड को निर्धारित करते हैं जो चेक सर्वर से डेटा आने और उनके मापदंडों पर निगरानी सर्वर पर चलाया जाएगा। उदाहरण के लिए, यह हैंडलर, जब किसी भी चेक से गैर-शून्य निकास कोड प्राप्त करता है, तो कमांड mail -s 'sensu event' email@address.com (प्रलेखन से उदाहरण) निष्पादित करेगा:

 { "handlers": { "mail": { "type": "pipe", "command": "mail -s 'sensu event' email@address.com" } } }

यहां सब कुछ स्पष्ट है, प्लगइन रिपॉजिटरी में बहुत सारे हैंडलर हैं। आप पेजरडूट में भेज सकते हैं, और पत्र भेज सकते हैं, और ग्रेग्लॉ 2 में gelf में भेज सकते हैं। प्रलेखन में विवरण।

उपरोक्त सभी कार्य प्रणाली बनाने के लिए पहले से ही पर्याप्त हैं। म्यूटेटर, एक्सटेंशन और एपीआई भी हैं, लेकिन यह अब हमारे लिए महत्वपूर्ण नहीं है।

मज़ा भाग के लिए हो रही है

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

आइए कुछ उपयोगी करने की कोशिश करें। आइए एक सरल कार्य करें - समस्याओं के मामले में ग्राहकों को रेडिस के खिलाफ चेक करने के लिए, डैशिंग पैनल पर अलर्ट प्रदर्शित करें, और इतिहास के लिए admin@example.com पर भी ग्रेग्लोग 2 को संदेश भेजें और ईमेल करें। और रेडिस से मैट्रिक्स भी लेते हैं और उन्हें भंडारण के लिए ग्रेफाइट में भेजते हैं, और फिर कुंजियों के एकत्रित मूल्यों पर भी जांच करते हैं।

ग्राहकों के पते 192.168.1.2N हैं, ग्रेफाइट 192.168.1.80:8082, रैबिटएमक्यू और रेडिस 192.168.1.80 पर तैनात हैं। ग्रेलॉग 2 192.168.1.81 पर सुनता है, डैशिंग को भी वहां तैनात किया जाता है।

विन्यास

ग्राहक कॉन्फ़िगरेशन के साथ शुरू करते हैं।

मान लीजिए कि हमारे पास रेडिस की भूमिका में एन सर्वर हैं।

क्लाइंट कॉन्फ़िगरेशन इस तरह दिखता है:

/etc/sensu/config.json

 { "client": { "graphite_server": "192.168.1.80:8082", "address": "192.168.1.2N", "name": "clientN", "subscriptions": [ "redis" ] } "rabbitmq": { "vhost": "/sensu", "host": "192.168.1.80", "password": "password", "port": 5672, "user": "sensu" } }

और प्रत्येक N क्लाइंट पर होस्ट किया गया है।

अन्य सभी कॉन्फ़िगरेशन फ़ाइलें केवल Sensu सर्वर पर हैं।

मूल सेटिंग्स:

/etc/sensu/conf.d/settings.json

 { "api": { "host": "192.168.1.80", "port": 4567 }, "redis": { "host": "192.168.1.80", "port": 6379 }, "rabbitmq": { "vhost": "/sensu", "host": "192.168.1.80", "password": "password", "port": 5672, "user": "sensu" }, "mailer": { "mail_from": "sensu@example.com", "smtp_port": "25", "mail_to": "admin@example.com", "smtp_address": "localhost" }, "dashing": { "auth_token": "YOUR_AUTH_TOKEN", "host": "http://192.168.1.81:8088" }, "gelf": { "server": "192.168.1.81" "port": "12201", } }

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

अब हम इन हैंडलर को स्वयं परिभाषित करते हैं:

/etc/sensu/conf.d/handlers.json

 { "handlers": { "default": { "type": "set", "handlers": [ "mailer", "dashing", "gelf" ] }, "gelf": { "type": "pipe", "command": "/etc/sensu/handlers/gelf.rb" }, "mailer": { "type": "pipe", "command": "/etc/sensu/handlers/mailer.rb" }, "dashing": { "type": "pipe", "command": "/etc/sensu/handlers/dashing.rb" }, "graphite": { "mutator": "only_check_output", "type": "amqp", "exchange": { "durable": true, "type": "topic", "name": "metrics" } } } }

यहां सब कुछ सरल है। ध्यान दें कि ग्रेफाइट में हम AMQP के माध्यम से हेलमेट का डाटा देते हैं। संचालकों को मॉनिटरिंग सर्वर पर / etc / sensu / हैंडलर में विघटित होना चाहिए।

अब क्लाइंट पर किए जाने वाले चेक कॉन्फ़िगर करें:

/etc/sensu/conf.d/checks.json

 { "checks": { "redis_processes": { "interval": 60, "command": "/etc/sensu/plugins/processes/check-procs.rb -p redis -c 8 -C 0 -w 7 -W 1", "subscribers": [ "redis", ], "handlers": [ "default" ] }, "redis_memory": { "dependencies": [ "redis_processes" ], "command": "/etc/sensu/plugins/redis/check-redis-memory.rb -c 204800 -w 51200", "interval": 60, "subscribers": [ "redis", ], "handlers": [ "default" ] }, "redis_metric": { "handlers": [ "graphite" ], "interval": 60, "dependencies": [ "redis_processes" ], "command": "/etc/sensu/plugins/redis/redis-graphite.rb --scheme stats.:::name:::.redis", "subscribers": [ "redis", ], "type": "metric" }, "redis_keys_from_graphite": { "interval": 60, "command": "/etc/sensu/plugins/graphite/check-data.rb -s :::graphite_server::: -t stats.:::name:::.redis.db0.keys -w 500 -c 900 -a 120", "subscribers": [ "redis" ], "dependencies": [ "redis_processes" ], "handlers": [ "default" ] } } }

चेकों को सेंसु प्लगइन्स द्वारा किया जाता है, जिसे ग्राहकों को / etc / sensu / plugins में विघटित होना चाहिए। जो लोग नागियोस से परिचित हैं, उनके लिए यहां कुछ नया नहीं है, केवल redis_metric मीट्रिक दिलचस्प है, जिसमें से हम डेटा को ग्रेफाइट में डालते हैं, और फिर redis_keys_from_graphite चेक में हम प्राप्त करते हैं और पिछले 10 मिनट के लिए डेटा की जांच करते हैं। सामान्य तौर पर, लगभग हर प्लगइन में --help स्विच होता है, जो उपयोग के लिए पूरी तरह से सन्दर्भ देता है।

वह संपूर्ण विन्यास है। सब कुछ स्पष्ट है, सब कुछ भंडार में संग्रहीत किया जा सकता है, और यह अद्भुत है।

बेशक, डैशिंग और ग्रेफाइट को कॉन्फ़िगर करने की आवश्यकता है, लेकिन मैं इसे लेख के दायरे से बाहर छोड़ दूंगा। Sensu + ग्रेफाइट की स्थापना के निर्देश यहां मिल सकते हैं , लेकिन डैशिंग के साथ सब कुछ स्पष्ट है।

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

निष्कर्ष

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

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

अंत में, मैं सेंसु (सभी IMHO) के पेशेवरों और विपक्षों को इंगित करना चाहता हूं:

विपक्ष सेंसु

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

पेशेवरों सेंसु

कॉन्फ़िगर को git में संग्रहीत किया जा सकता है, Chef / Puppet के साथ सब कुछ निर्धारित किया गया है।
अनुमापकता।
दोष सहिष्णुता।
स्टोरेज सिस्टम चुनने में लचीलापन।
Nagios प्लगइन्स के लिए समर्थन।
ऑटो-कनेक्ट क्लाइंट।
सदस्यता तंत्र।
डेटा ग्राहकों द्वारा प्रकाशित किया जाता है क्योंकि वे उत्पन्न होते हैं।
परीक्षण के परिणाम लचीले ढंग से विभिन्न हैंडलर को भेजे जा सकते हैं।

सेंसु - निगरानी ढांचा