Architecture Decision Record
← निर्णय नोंद उदाहरणे

मेट्रिक्स, मॉनिटर, अलर्ट्स

सामग्री:

सारांश

समस्या

आम्हाला मेट्रिक्स, मॉनिटर आणि अलर्ट्स वापरायचे आहेत, कारण आमचे अनुप्रयोग किती चांगले काम करत आहेत, आणि समस्या केव्हा आहे हे आम्हाला जाणून घ्यायचे आहे.

निर्णय

WIP.

स्थिती

माहिती गोळा करत आहोत. आम्ही स्पेक्ट्रमच्या संभाव्य टोकांपासून सुरुवात करत आहोत: सर्वाधिक शिफारस केलेले जुने मोफत साधन (Nagios) आणि सर्वाधिक शिफारस केलेले नवे सशुल्क साधन (New Relic).

तपशील

गृहीतके

आम्हाला आधुनिक, जलद, विश्वासार्ह, प्रतिसादशील इत्यादी वेब अनुप्रयोग बनवायचे आहेत.

आम्हाला बनवण्याऐवजी विकत घ्यायचे आहे.

मर्यादा

आमच्या devops पाइपलाइन आणि आमच्या डिप्लॉयमेंट क्लाउडसह चांगले काम करणारी साधने आम्हाला हवी आहेत.

मते

आम्ही सध्या मतांचे संशोधन करत आहोत.

  • AlertManager

  • AppDynamics

  • AppOptics

  • Azure Monitor/Analytics/Insights/Dashboards

  • Bosun

  • Checkly

  • Circonus

  • Cloudwatch

  • EFK

  • ELK

  • Grafana

  • Grafana

  • Graphite

  • Graylog

  • Healthchecks.io

  • Heroku

  • icinga2

  • InfluxDB

  • Instana

  • Kafka

  • Logagent

  • Logz.io

  • Loki

  • Monitis

  • Nagios

  • Nagios

  • Nagiosgraph

  • NewRelic

  • OpsGenie

  • Outlyer

  • PagerDuty

  • Pagerduty

  • PagerDuty

  • Papertrail

  • Prometheus

  • Rollbar

  • Scalyr

  • Sematext Metrics, Logs, Experience, Tracing

  • Sensu

  • SignalFX

  • Slack

  • Splunk

  • Stackdriver

  • Stackstorm

  • Telegraf

  • Telegraf

  • Thanos

  • VictorOps

  • Wavefront

  • Zabbix

युक्तिवाद

आतापर्यंत, Nagios आणि New Relic हे स्पेक्ट्रमची टोके आहेत. Nagios हे सर्वात जुने, सर्वात साधे, मोफत, शक्य साधन आहे. New Relic हे सर्वात नवीन वैशिष्ट्ये असलेले, सर्वात पूर्ण, सशुल्क, शक्य साधन आहे. आम्ही मूल्यमापन यांपासून सुरू करू. गरज पडल्यास, आम्ही स्पेक्ट्रमच्या आत जाऊ.

आतापर्यंत, Zabbix कडे सर्वोत्तम शिफारशी आहेत, आणि सर्वात पूर्ण क्षमताही आहेत.

आतापर्यंत, ELK कडे सर्वोत्तम ओपन-सोर्स बनवा-की-विकत-घ्या लोकप्रियता आहे.

आतापर्यंत, Prometheus + Graphana कडे सर्वोत्तम लोकप्रियता आहे.

परिणाम

TODO.

संबंधित

संबंधित निर्णय

निवडींचा परिणाम चाचणीक्षमता, टेलिमेट्री, आणि शक्यतो ग्राहक सेवा, साइट विश्वासार्हता अभियांत्रिकी इत्यादी इतर प्रणालींवर होईल.

संबंधित आवश्यकता

TODO.

संबंधित आर्टिफॅक्ट्स

TODO.

संबंधित तत्त्वे

सहज पलटवता येण्याजोगे.

गतीची गरज.

टिपा

एक बऱ्यापैकी चांगला ओपन सोर्स स्टॅक असा आहे:

  • मेट्रिक्स आणि मेट्रिक्सवर आधारित अलर्टिंगसाठी Prometheus

  • मेट्रिक्स दाखवण्यासाठी Grafana

  • लॉग आणि संरचित इव्हेंटसाठी Elasticsearch/Logstash/Kibana (ELK)

  • मोबाइल सूचनांसाठी Pushover

मुक्त मजकूर संदेश विरुद्ध संरचित इव्हेंट संदेश

मुक्त मजकूर संदेश: उदाहरणार्थ, /var/log/messages मध्ये सापडणाऱ्या प्रकारचा यादृच्छिक मजकूर, आणि अनुप्रयोगाने जाणूनबुजून तयार केलेला. हे संदेश बॉक्सवर घडणाऱ्या इतर गोष्टी, जसे की मेमरी संपणे किंवा हार्डवेअर त्रुटी, ओळखण्यासाठी उपयुक्त असतात, पण त्यात खूप कचरा असतो.

संरचित इव्हेंट संदेश: अनुप्रयोगाने तयार केलेले, गुणधर्मांच्या निश्चित किंवा गतिशील संचासह, उदा. HTTP विनंती लॉग, लेखा लॉग, वापरकर्ता लॉगिन.

सर्वसाधारणपणे, प्रत्येक विनंतीचे तपशील असे लॉग करणे चांगले असते की तुम्ही गुणधर्मांच्या आधारे खोलात जाऊ शकाल. म्हणून प्रत्येक गोष्टीला उदा. userid किंवा sessionid जोडल्याने तुम्हाला मागोवा घेता येतो. अर्थातच स्पष्ट ट्रेसिंगही चांगले आहे. यासाठी ELK वापरणे म्हणजे https://www.honeycomb.io/ चे गरिबांचे रूप आहे

Graylog सोपे आहे

माझ्या अनुभवात Graylog सुरू करणे अधिक सोपे आहे.

Prometheus ला थोडे ट्यूनिंग लागते

मी सर्वसाधारणपणे मेट्रिक्ससाठी Prometheus वर खूश आहे. अलर्टिंगला थोडे ट्यूनिंग लागते, पण ते बरेच चांगले आहे. ते तुमच्या अनुप्रयोगावर अवलंबून आहे. मला वाटते की मूळ कारणांवर नव्हे तर अंतिम-वापरकर्त्याला दिसणाऱ्या परिस्थितींवर अलर्ट करणे सर्वोत्तम आहे. उदाहरणार्थ, पान लोड होण्याचा वेळ चांगला आहे, प्रति सेकंद विनंत्यांची संख्या नाही. तरीही प्रति सेकंद शून्य विनंत्या काहीतरी चुकीचे असल्याचे दर्शवतात.

सेवेचा फायदा हा आहे की त्या तयार स्थितीत अतिरिक्त बुद्धिमत्ता देतात. मला सर्वसाधारणपणे Datadog आवडते. तुमच्याकडे भरपूर डेटा असेल तर सेवा भीतीदायक रीतीने महाग असू शकतात, आणि कधीकधी त्यांचे किंमत मॉडेल क्लाउड-अनुकूल नसतात, उदा. प्रति इन्स्टन्स शुल्क आकारणे, जेव्हा इन्स्टन्स गतिशील असतात. प्रत्येक विनंती पैसे देणाऱ्या वापरकर्त्याची असलेल्या सेवा आणि जाहिरातींशी संबंधित सेवा यांच्यातही फरक आहे, ज्यात विनंत्यांपैकी फक्त काही छोटी टक्केवारी तुम्हाला पैसे मिळवून देते. तुमच्याकडे भरपूर डेटा आणि फारसे अंदाजपत्रक नसू शकते.

मी काही सेवांवर काम करतो ज्यांना दिवसाला १B विनंत्या येतात, त्यामुळे आमचे स्वतःचे निरीक्षण आणि लॉगिंग होस्ट करणे अर्थपूर्ण आहे. तुमचे प्रमाण कमी असेल तर होस्ट केलेल्या सेवा सोप्या असतात.

AWS सेवा संमिश्र आहेत

AWS सेवांसोबतचा माझा अनुभव संमिश्र राहिला आहे. त्यांची Elasticsearch सेवा अस्थिर राहिली आहे, म्हणून आम्ही त्यासाठी स्वतःचे इन्स्टन्स चालवतो. CloudWatch मेट्रिक्स महाग आहेत, म्हणून आम्ही सामान्यतः त्यांचा वापर अनुप्रयोगासाठी नव्हे तर फक्त "पायाभूत सुविधा" स्तरावरील मेट्रिक्ससाठी करतो, म्हणजे आरोग्याशी संबंधित मेट्रिक्स जिथे इन्स्टन्सवर चालणाऱ्या सॉफ्टवेअरपेक्षा AWS ला काय चालले आहे हे चांगले माहीत असू शकते. CloudWatch Logs अद्ययावत होण्यास संथ असू शकतात आणि त्यात फारसा मेटाडेटा नसतो. ELK चालवल्याने त्यात मदत होते. मला खरोखर रिअल टाइम डेटा हवा असेल, तर लॉगसाठी वाहतूक म्हणून Kafka वापरणे चांगले. Logstash द्वारे त्याला चांगले समर्थन आहे. Kafka क्लस्टर व्यवस्थापित करणे दुबळ्या मनाच्यांसाठी नाही, तथापि, भरपूर उघडी प्लंबिंग आहे.

Kafka

टिप्पणी: Kafka कधीकधी अत्यंत अवघड असू शकते, किंवा Kafka खडकासारखे भक्कम असू शकते आणि सर्व काही जोडून तिथे असल्याचे तुम्ही जवळजवळ विसरून जाता.

टिप्पणी: Kafka भक्कम राहिले आहे, पण ते सुरू करण्यासाठी आश्चर्यकारक प्रमाणात काम लागले. मी त्याकडे रिलेशनल डेटाबेससारखे पाहतो पण तुम्ही फक्त "भौतिक" स्तरावर काम करत आहात, उदा. टेबलस्पेस, फाईली आणि पार्टिशन. सुरुवातीला काही वेळा व्यवस्थापन उपयुक्तता कमी होत्या, आणि आम्हाला उदा. कन्झ्युमर ग्रुप रीसेट करण्यासाठी प्रोग्राम लिहावे लागले. http://howfuckedismydatabase.com/nosql/

टिप्पणी: आम्ही Kafka चा वापर लॉग संदेशांसाठी "बफर" म्हणून आणि अनेक सर्व्हरवरून येणाऱ्या डेटावर रिअल टाइम स्ट्रीम प्रोसेसिंग करता येईल अशी जागा म्हणून करतो. आम्हाला DDOS हल्ला झाल्यास, आम्हाला अनेक इन्स्टन्समध्ये डेटाचे विश्लेषण करण्याचा मार्ग हवा. आम्ही सर्व्हरवरून थेट ELK मध्ये लॉग केल्यास, भार Elasticsearch क्लस्टर उडवू शकतो.

टिप्पणी: Kafka आमच्यासाठी चांगले आहे कारण आम्हाला DDOS हल्ला झाल्यास, आम्हाला अनेक इन्स्टन्समध्ये डेटाचे विश्लेषण करण्याचा मार्ग हवा. आम्ही सर्व्हरवरून थेट ELK मध्ये लॉग केल्यास, भार Elasticsearch क्लस्टर उडवू शकतो.

टिप्पणी: Kafka कमी काम करते आणि अधिक कार्यक्षम आहे, त्यामुळे ते भार चांगल्या प्रकारे हाताळू शकते. आणि आम्ही Kafka चे काम रांगेत ठेवतो आणि पुन्हा प्रयत्न करतो. आणि Elasticsearch संघर्ष करत असल्यास जसे होईल तसे, Kafka वर भार असल्याने Kibana सह संवादी काम करण्याचा प्रयत्न करणाऱ्या वापरकर्त्यांवर परिणाम होत नाही.

टिप्पणी: स्ट्रीम प्रोसेसिंग मुख्यतः गैरवापर शोधते, उदा. संपूर्ण क्लस्टरमध्ये एकाच IP कडून जास्त रहदारी, आणि मग तो ब्लॉक संपूर्ण क्लस्टरमध्ये वाटते.

टिप्पणी: logstash-output-kafka प्लगइन सध्या बरेच अविश्वसनीय आहे. त्याच्या GitHub issues पानावरील अनेक समस्यांनी मला चावा घेतला आहे, ज्या कधीच दुरुस्त होत नाहीत असे वाटते. मला ते वापरणे सोडून आमच्या अॅप्सवरून थेट Kafka ला पाठवायचे आहे.

टिप्पणी: आम्ही आता संरचित इव्हेंट थेट अॅपवरून Kafka ला पाठवत आहोत. मुख्य प्रेरणा लॉग डेटाला कमी वेळा स्पर्श करणे आणि डिस्क अनेकदा वाचणे-लिहिणे टाळणे ही होती. उच्च-प्रमाणाच्या प्रणालींमध्ये, लॉगिंग अॅपपेक्षाही जास्त काम घेऊ शकते. मी journald लाही C प्रोग्राममधून थेट लॉग पाठवायला लावण्याचा विचार करत आहे.

Loki

Loki वर बारकाईने लक्ष ठेवा. ते अजून तयार नाही पण तयार झाल्यावर मला अपेक्षा आहे की ते या स्टॅकमध्ये अधिक चांगले बसेल. Loki हे grafana labs ने बनवलेले लॉग एकत्रक आहे, ते Prometheus सारखीच स्क्रेपिंग आणि टॅग वाक्यरचना वापरते.

Prometheus + alertmanager + Rollbar + Graylog + Grafana

मेट्रिक्ससाठी Prometheus + alertmanager. <3 Prometheus.

लॉगिंग/त्रुटी अहवालासाठी Rollbar/Graylog (येथे थोडे ओव्हरलॅप आहे; लहान सेवेला कदाचित दोन्हींची गरज नाही).

सध्या, अलर्ट फक्त काही Slack चॅनेलपैकी एकाकडे जातात ज्यावर इच्छुक पक्षांनी सूचना चालू केल्या आहेत. आम्ही ऑन-कॉलबद्दल अधिक गंभीर असतो तर ते PagerDuty/VictorOps/इत्यादींकडे गेले असते.

आलेख आणि डॅशबोर्डिंगसाठी Grafana. त्यांच्या येणाऱ्या लॉगिंग सुविधा Graylog ची गरज दूर करतील की नाही हे पाहण्यासही उत्सुकतेने वाट पाहत आहे.

Thanos

आम्ही आमच्या HA सेटअपचा फ्रंट-एंड म्हणून Thanos वापरतो. त्याला HA जोड्यांचे डी-डुप्लिकेशन कसे करायचे हे माहीत आहे.

आम्ही सध्या ६ महिन्यांचा स्थानिक Prometheus डेटा ठेवतो. हे आमच्यासाठी बऱ्यापैकी चांगले काम करते. पण मी आत्ता दीर्घकालीन डेटा साठवणुकीसाठी आमच्या Thanos सेटअपमध्ये बकेट स्टोरेज आणण्याच्या मध्यभागी आहे. सिद्धांतानुसार, आम्ही आत्ता वापरत असलेल्या GCE मानक पर्सिस्टंट डिस्कपेक्षा GCS स्टोरेज सुमारे ३०% स्वस्त असेल.

आम्ही सध्या Prometheus डेटाचा बॅकअप घेत नाही. डेटा आमच्यासाठी अलर्टिंगसाठी पुरेसा असण्यापलीकडे खरोखर महत्त्वाचा नाही. आमची एकूण फ्लीट डिप्लॉयमेंट वर्षानुवर्षे इतकी बदलते की काही महिन्यांपेक्षा जुना ऐतिहासिक डेटा खरोखर रसपूर्ण नाही. वर्ष-दर-वर्ष काही मुख्य आकडेवारी असणे रसपूर्ण असू शकते, मी मुख्य-आकडेवारी रेकॉर्डिंग नियमांचा संच सेट करून त्यांना Federation सह साठवू शकतो किंवा फक्त Thanos ला त्याची काळजी घेऊ देऊ शकतो.

EDIT: लहान घोषणा, मी Prometheus विकासक आहे.

Prometheus HA

Prometheus मध्ये HA प्रतिकृतीद्वारे केले जाते, तुम्ही अनेक पॉपर चालवता, अनेकांना पोल करण्याचे आणि डेटाचे डी-डुप्लिकेशन करण्याचे मार्ग आहेत

प्रमाण वाढवणे नेटवर्क ठरवून आणि वेगवेगळ्या Prometheus ना नेटवर्कचे वेगवेगळे भाग पोल करायला लावून होते

दीर्घकालीन साठवण हा prom चा मजबूत मुद्दा नाही पण तो influx किंवा timescaledb सारख्या गोष्टींवर उतरवला जातो (जे तांत्रिकदृष्ट्या HA चा खानाही टिक करते) मी वाचलेला लेख https://blog.timescale.com/prometheus-ha-postgresql-8de68d19b6f5?gi=7df160f10e07

दीर्घकालीन गोष्ट अजून वापरून पाहिली नाही कारण मी अजून फक्त प्रयोग करत आहे आणि अल्पकालीन आलेखांसाठी वापरत आहे तर librenms दीर्घकालीन मदतीसाठी माझ्या नेटवर्कचे निरीक्षण करते

Datadog + PagerDuty + Threat Stack

आम्ही Datadog (PagerDuty सह) आणि Threat Stack वापरतो आणि यापेक्षा अधिक खूश असू शकत नाही. DD बद्दल माझी एकमेव तक्रार म्हणजे मेट्रिक साठवणुकीचा तुलनेने उच्च खर्च.

Zabbix

जवळजवळ सर्व काही निरीक्षण करण्यासाठी सानुकूल स्क्रिप्टसह Zabbix. जादूसारखे काम करते.

Outlyer

मी Outlyer वापरतो आहे, पण मला जाहीर करावे लागेल की मी येथे काम करतो, आणि स्वतःचे अन्न स्वतः खाणे अनिवार्य आहे.

सुधारण्यासाठी अजूनही Graylog, Sentry आणि Statuscake ची गरज आहे.

पक्षपाती वाटते, पण Nagios आणि इतर निरीक्षण प्रणाली अंतर्गत आनंदाने चालवल्यानंतर, मी कोणत्याही नव्या कामात होस्ट केलेला उपाय खरेदी करीन आणि ती वेदना सोपवून देईन.

Nagios + Nagiosgraph

आम्ही सर्व निरीक्षण आणि अलर्टिंगसाठी Nagios चालवतो. अलर्ट ईमेल (इशारे आणि गंभीर सूचना) आणि ऐकू येणाऱ्या अॅप सूचनांद्वारे (गंभीर अलर्टसाठी) होतात.

Nagiosgraph चा वापर दृश्यांसाठी केला जातो.

आमच्या वातावरणात काय चालले आहे याबद्दल आम्हाला व्यापकपणे माहिती देण्यात हा सेटअप खूप प्रभावी ठरला आहे. आम्ही सुमारे ११० मिशन-क्रिटिकल सर्व्हर आणि सुमारे ७६० डेटा पॉइंट चालवतो आणि त्यावर लक्ष ठेवतो, आणि सात वर्षांपेक्षा जास्त काळ आमच्याकडे ही सकाळची प्रणाली आहे.

मला कधीतरी Graylog किंवा ELk सह लॉग एकत्रितही करायचे आहेत.

Prometheus + Grafana + AlertManager

अद्भुत Prometheus Operator helm chart द्वारे Prometheus + Grafana + AlertManager. लॉग अजूनही LogDNA birch योजनेकडे जातात कारण आमच्या GKE वरील विनम्र min 3 max 5 नोड्ससाठी ELK खूप जड आहे हे आमच्या लक्षात आले.

DataDog + Sentry + PagerDuty.

मी माझे सर्व निरीक्षण उपाय स्वतः चालवत असे, Nagios, Icinga, Zabbix, ELK, Greylog2, Influx आणि इतर अनेक साधनांसह सर्व प्रकारचे सॉफ्टवेअर वापरून, पण सत्य हे आहे की तुमच्या स्वतःच्या निरीक्षण पायाभूत सुविधा चालवण्यात खूप जास्त प्रयत्न लागतात, विशेषतः जेव्हा तेच काम दुसऱ्याकडून करून घेण्यासाठी तुम्ही इतके कमी दर देऊ शकता!

निरीक्षण पायाभूत सुविधा चालवण्यासाठी इतरांना पैसे दिल्याने माझे ग्राहक निरीक्षणाचे निरीक्षण करण्याऐवजी त्यांचे प्लॅटफॉर्म चालवण्यावर लक्ष केंद्रित करू शकतात, म्हणजे त्यांच्या प्लॅटफॉर्मच्या स्थिरतेतून त्यांना मिळणारे मूल्य Monitoring as a Service च्या कोणत्याही खर्चापेक्षा खूप जास्त आहे.

Sensu + Graphite + ELK

माझी कंपनी स्वयं-होस्ट केलेल्या गोष्टींवर खूप भर देते.

Sensu -> PagerDuty

Graphite/Grafana

ELK (Elasticsearch, Logstash, Kibana)

Prometheus + Alertmanager

अलर्टिंगसाठी Prometheus + Alertmanager, माझ्या संघाचा विश्वास आहे की साधे निरीक्षण म्हणजे चांगले निरीक्षण.

लॉगिंग आणि ट्रेसिंग यांसारख्या इतर प्रणाली ऑन-कॉलला अलर्ट मिळतो तेव्हा निदानासाठी समृद्ध संदर्भ पुरवतील, पण आम्ही त्यांवर कधीही अलर्टिंग बनवत नाही.

Sensu + Grafana + Graylog + Kibana + NewRelic.

Sensu, grafana, graylog, kibana, newrelic.

Prometheus + Circonus

Prometheus-इन्स्ट्रुमेंटेड सेवा => Circonus विश्लेषण आणि व्हिज्युअलायझेशन

icinga2 + VictorOps + NewRelic + Sentry + Slack

आम्ही खालील सेवा वापरत आहोत:

निरीक्षणासाठी icinga2 आणि अलर्टिंगसाठी VictorOps

सेवेच्या तपशीलवार निरीक्षणासाठी NewRelic

सेवेतील त्रुटी ट्रॅकिंगसाठी Sentry

Slack/ईमेल हा अलर्टिंगचा भाग आहे जो NewRelic किंवा icinga2 मधून ट्रिगर होतो

AppDynamics + Papertrail + PagerDuty + Healthchecks.io + Stackdriver

AppDynamics

Papertrail

PagerDuty

Healthchecks.io

Stackdriver

icinga2 + elasticsearch

विश्लेषणासाठी elasticsearch एकत्रीकरण आणि आलेखांसाठी graphite+grafana एकत्रीकरणासह icinga2.

icinga2 मधील apply नियमांच्या लवचिकतेमुळे, विकासकांना फक्त त्याच सेवा दिसतात ज्यांच्या सूचना त्यांना मिळतात.

आणि icinga2 director द्वारे, प्रोग्रामर्स सहजपणे स्वतःच्या तपासण्या मोठ्या प्रमाणावर शून्य त्रासाने परिभाषित करू शकतात (जे ते दर काही दिवसांनी करतात - १०० तपासण्या बाहेर जातात, १०० इतर तपासण्या आत येतात).

DataDog + New Relic + ELK + EFK + Sentry + Alertmanager + VictorOps

आत्ता आमच्याकडे काय आहे:

मेट्रिक्ससाठी DataDog

अनुप्रयोग निरीक्षणासाठी New Relic

लॉगसाठी ELK (Elastic Search + Logstash + Kibana)

अपवाद लॉग करण्यासाठी Sentry (स्वयं-होस्ट केलेले)

अलर्टिंगसाठी ईमेल + Slack + VictorOps (तीव्रतेनुसार)

आम्हाला काय हवे आहे:

मेट्रिक्ससाठी Prometheus (व्हिज्युअलायझेशनसाठी Grafana)

अनुप्रयोग निरीक्षणासाठी New Relic (कदाचित Elastic Search APM)

लॉगिंगसाठी EFK (elastic search + fluentd + kibana). कदाचित, आम्ही तिथे पोहोचेपर्यंत Grafana चे Loki उत्पादन-सज्ज होईल

अपवादांसाठी Sentry

अलर्टसाठी Alertmanager + ईमेल + VictorOps

Wavefront + Scalyr + PagerDuty + Stackstorm + Slack

Wavefront + Scalyr + PagerDuty + Stackstorm + Slack (घोषणा: VMware मध्ये काम करतो)

Telegraf + Prometheus + InfluxDB + Grafana

CPU, डिस्क, मेमरी आणि नेटवर्क यांसारख्या सर्व्हर मेट्रिक्ससाठी Telegraf. आम्ही आमच्या नेटवर्क उपकरणांच्या SNMP निरीक्षणासाठीही Telegraf वापरतो.

अनुप्रयोग मेट्रिक्ससाठी Prometheus. आम्ही आमच्या अनुप्रयोगात आरोग्य तपासण्या कोड करतो ज्या Prometheus स्क्रेप करते.

टाइम-सिरीज साठवणुकीसाठी InfluxDB. येथे आमचा Telegraf डेटा पाठवला जातो.

डॅशबोर्ड आणि अलर्टसाठी Grafana. अलर्टिंग इंजिन फारसे मजबूत नाही, पण काम भागवते. आम्ही अलर्ट Slack मध्येही पाठवतो.

सध्या माझ्याकडे जे नाही ते केंद्रीकृत लॉगिंग उपाय आहे. ELK शक्तिशाली आहे पण सेट अप आणि व्यवस्थापित करणे कठीण आहे, आणि पाहण्यासारखे पुरेसे जवळचे कोणतेही मोफत पर्याय मला माहीत नाहीत.

Sematext + Logagent + Experience

मेट्रिक्स, लॉग, ट्रेस साठी Sematext, लवकरच रिअल युजर मॉनिटरिंगसाठीही. माझ्या मते N वेगवेगळी साधने/सेवा वापरण्यापेक्षा सोपे/स्वस्त.

लॉग पाठवण्यासाठी आम्ही rsyslog वापरायचो आणि मग Logagent वर गेलो.

फ्रंटएंड क्रॅश रिपोर्टिंगसाठी आम्ही Sentry वापरतो, पण आम्ही लवकरच Experience वर जाऊ.

घोषणा: मी Sematext चा कर्मचारी आहे.

Azure Monitor/Analytics + OpsGenie

Log Analytics चा इंटरफेस अधिक चांगला असता तर बरे झाले असते. आम्ही splunk पासून दूर जात आहोत, ज्यात फिरणे खूप सोपे होते.

Prometheus + Alertmanager + Grafana + Splunk + PagerDuty

Prometheus, Alertmanager, Grafana, Splunk, PagerDuty

तुम्हाला खरोखर तुमची स्वतःची सूचना प्रणाली चालवायची नसते. तुमच्या सुरक्षा संघाने Splunk ला पसंती दिली नाही तर तुम्ही Splunk च्या जागी ELK वापरू शकता.

Telegraf + Prometheus + Grafana + Alertmanager

संग्राहक म्हणून Telegraf, निरीक्षण आणि अलर्टिंगसाठी Prometheus + Alertmanager, slack चॅनेल आणि गंभीर अलर्टसाठी pagerduty सह एकत्रित. होस्ट मेट्रिक्सच्या व्हिज्युअलायझेशनसाठी Grafana.

Prometheus + Grafana + Cloudwatch + sentry + kibana + elasticsearch

मेट्रिक्स + अलर्टसाठी Prometheus

Prometheus डॅशबोर्डसाठी Grafana

Prometheus इन्स्टन्सचे निरीक्षण करणारे Cloudwatch

अपवाद ट्रॅकिंगसाठी sentry

kibana + elasticsearch

graylog

batch/cronjob साठी prometheus Push Gateway

एका Prometheus इन्स्टन्समधून दुसऱ्यात मेट्रिक्स „push/forward“ करण्यासाठी SOP https://github.com/rapidloop/sop

क्लायंट एकतर Prometheus क्लायंट वापरतात. आम्ही क्लायंट बाजूला opencensus.io वापरण्याचा प्रयत्न करतो

PagerDuty + Monitis

PagerDuty + Monitis. तसेच काही सेवांच्या आरोग्याच्या चाचणीसाठी काही खास Azure Functions.

यावर्षी Prometheus आणि Grafana आणण्याचा विचार करत आहोत

Prometheus + Grafana + Bosun

टाइम सिरीज डेटा साठवण्यासाठी Prometheus. व्हिज्युअलायझेशनसाठी Grafana. अलर्ट व्यवस्थापनासाठी Bosun.

Azure Monitor/Analytics/Insights/Dashboards

फक्त Azure दुकान, Azure Monitor, Log Analytics, App Insights, Azure Dashboards + Pager Duty

Grafana + Monitis + OpsGenie + Slack

Prometheus द्वारे Kubernetes मधील कंटेनर सेवांच्या निरीक्षणासाठी Grafana

प्रामुख्याने वेब API आणि वेब अनुप्रयोगांसाठी एंड-टू-एंड सेवा निरीक्षणासाठी Monitis

अलर्ट व्यवस्थापनासाठी OpsGenie

आमच्या प्रणालींकडून स्थिती माहिती मिळवण्यासाठी Slack

Checkly + AppOptics + Cloudwatch + Heroku + Pagerduty + Papertrail

येथे दीर्घकाळाचा (dev)ops अभियंता. Nagios वर मोठा झालो. माझ्या बूटस्ट्रॅप्ड SaaS https://checklyhq.com वर मते मिळवायला आवडतील. आम्ही बऱ्यापैकी सखोल अलर्टिंगसह API निरीक्षण आणि साइट व्यवहार निरीक्षण करतो.

मी Checkly सुरू केले कारण API क्षेत्रात सक्रिय / कृत्रिम निरीक्षण थोडे मर्यादित (आणि महाग) होते. ब्राउझर-आधारित / स्क्रिप्टेड निरीक्षण तर अधिक मालकी हक्काचे आणि महाग आहे. आम्ही Puppeteer वापरतो आणि किंमती शक्य तितक्या कमी ठेवतो.

आमचा निरीक्षण स्टॅक:

Checkly (स्वतःचे अन्न स्वतः खाणे...)

AppOptics (सानुकूल आलेख)

SMS संदेशांसाठी AWS Cloudwatch & SNS.

अंगभूत Heroku अलर्टिंग.

Pagerduty

Papertrail

Instana + Logz.io + slack

Instana आम्हाला पायाभूत सुविधा समस्या किंवा कामगिरी घसरणीबद्दल slack मध्ये सतर्क करते, आणि अनुप्रयोग स्तरावरील त्रुटी-स्तरीय लॉगच्या विशिष्ट प्रमाणावर slack मध्ये अलर्ट करण्यासाठी आम्ही logz.io कॉन्फिगर केले आहे.

SignalFX + Splunk + PagerDuty + Slack

सध्या वापरत आहे: SignalFX, Splunk, PagerDuty आणि Slack. त्यांचा सहाय्य संघ अतिशय मैत्रीपूर्ण आणि प्रतिसादशील असला तरी मी SignalFX चा मोठा चाहता नाही. मला Splunk (परवडत असल्यास योग्य), PagerDuty आणि Slack आवडतात.

मी TICK स्टॅक वापरायचो जिथे बहुतेक C प्रत्यक्षात G होता, म्हणजे Grafana जरी मी Chronograf थोडे वापरले. ते अद्भुत होते पण व्यवस्थापित करणे त्रासदायक होते. SaaS विरुद्ध स्वयं-होस्टिंग ही क्लासिक कोंडी.

मी DataDog, New Relic, Graylog, ELK आणि BugSnag वापरले आहेत. मला DataDog आणि New Relic खूप आवडतात, Graylog बऱ्यापैकी चांगले आहे. मी ELK चा मोठा चाहता नाही. BugSnag छान आहे, मला खरोखर वाटते की त्रुटी/अपवाद ट्रॅक करणे हे अनेक प्रसंगी पूर्ण लॉग निरीक्षणाचा बऱ्यापैकी चांगला पर्याय आहे.

ELK + Prometheus + Grafana

इतरांप्रमाणेच, आम्ही लॉगसाठी ELK आणि बाकी सर्वांसाठी Prometheus+Grafana वापरतो.

तुम्ही स्वतःला अधूनमधून डेटा गमावण्याची परवानगी दिलीत तर हा सेटअप सांभाळणे सोपे आहे. उदाहरणार्थ, आमचा ElasticSearch डेटाबेस गोंधळात पडला (जे दुर्दैवाने आमच्यासोबत दर २-३ महिन्यांनी होते) तर आम्ही HA ची फिकीर करत नाही आणि त्याऐवजी डेटा टाकून देऊन पुढे जातो. तुम्हाला निश्चितपणे HA किंवा दीर्घकालीन धारण हवे असेल, तर शुभेच्छा.

Datadog + Prometheus + Grafana

मी Datadog महिना-ते-महिना सेट केले कारण मी येथे आलो तेव्हा कोणतेही निरीक्षण आणि कोणतेही अलर्टिंग नव्हते. आमच्या फक्त काही साइट्सवर अपटाइमसाठी दर ५ मिनिटांनी निरीक्षण होत होते. Datadog निःसंशयपणे सेट करण्यास सर्वात सोपे आहे. मी इतर सर्व समस्या सोडवल्यावर, मी Prometheus+Grafana वर जाईन. लॉग व्यवस्थापनावर अजून १००% निर्णय झालेला नाही.

Nagios + ELK

आम्ही समर्थन देत असलेली आमच्याकडे १००+ पेक्षा जास्त उत्पादने आहेत.

ऑन-प्रिमसाठी, मुख्यतः Nagios आणि ELK. क्लाउडसाठी, आम्ही DataDog वरून NewRelic कडे स्थलांतर करत आहोत.

Datadog vs. Site24x7 + StatusCake + PagerDuty + SumoLogic + Slack

आम्ही datadog वापरत असू पण आमच्या गरजांसाठी ते खूपच महाग असल्याचे आढळले. गैरसमज करून घेऊ नका ते अद्भुत आहे, पण त्याचा प्रचंड खर्च आहे. आम्ही DD च्या खर्चाच्या सुमारे २-३ महिन्यांच्या वार्षिक सबस्क्रिप्शनसह site24x7.com सेट करू शकलो.

आमचा निरीक्षण स्टॅक:

Site24x7 - APM, बाह्य URL निरीक्षण, SMTP मेलफ्लो निरीक्षण, ssl मुदतसंपणे आणि प्रक्रिया निरीक्षण.

StatusCake - URL निरीक्षण आणि पुष्टीकरणासाठी - site24x7 ने काही चुकवले (ते चुकवत नाही) तर हा आमचा बॅकअप आहे पण आमच्या गरजांसाठी बाह्य पोर्ट आणि सेवा निरीक्षणासाठी SC अधिक लवचिक आहे.

दोन्ही साधने PagerDuty कडे वाढवतात, आणि मग आम्हाला आमचे वाढवलेले slack मध्ये मिळतात.

SumoLogic - लॉग निरीक्षणासाठी (ते उत्तम साधन आहे पण आमच्या गरजांसाठी थोडे गुंतागुंतीचे)

slack मधून आम्ही अलर्ट ack किंवा निवारण करू शकतो.

मग आमच्याकडे अनेक site24x7 स्वयंचलने आहेत जी 'BedOps' साठी commando.io शी जोडली जातात, जसे आम्ही त्याला म्हणतो - जिथे अलर्ट ट्रिगर होतो, आम्ही परिस्थिती सुधारण्याचा प्रयत्न म्हणून काही स्क्रिप्ट किंवा स्वयंचलने सुरू करतो (९९% वेळा स्वयंचलन + आमच्या स्क्रिप्ट आम्हाला अडचणीतून दूर ठेवतात)

स्वयंचलन अयशस्वी झाल्यास किंवा व्याप्तीबाहेरील काहीतरी दुरुस्त करायचे असल्यास आमच्या KB मध्ये अंतर्गत runbook आहेत.

Prometheus + AlertManager + Grafana + Stackdriver

आमच्या GKE क्लस्टर आणि VM मधील मेट्रिक्ससाठी Prometheus (Operator) / AlertManager / Grafana.

लॉगसाठी Google Stackdriver (कारण ते समाविष्ट आहे आणि डीफॉल्टनुसार सक्रिय आहे आणि सध्या आमच्या गरजांसाठी पुरेसे आहे).

Zabbix

सर्वांसाठी Zabbix. कोणत्याही अतिरिक्त सॉफ्टवेअरची गरज नाही.