அளவீடுகள், கண்காணிப்பிகள், எச்சரிக்கைகள்

உள்ளடக்கம்:

சுருக்கம்
விவரங்கள்
தொடர்புடையவை
குறிப்புகள்

சுருக்கம்

சிக்கல்

நாங்கள் அளவீடுகள், கண்காணிப்பிகள், எச்சரிக்கைகளைப் பயன்படுத்த விரும்புகிறோம், ஏனெனில் எங்கள் பயன்பாடுகள் எவ்வளவு நன்றாக வேலை செய்கின்றன, எப்போது சிக்கல் உள்ளது என்பதை அறிய விரும்புகிறோம்.

முடிவு

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 ஐ விரும்புகிறேன். உங்களிடம் நிறைய தரவு இருந்தால் சேவைகள் அச்சமூட்டும் அளவுக்கு விலை உயர்ந்ததாக இருக்கலாம், சில சமயங்களில் நிகழ்வுகள் இயங்குநிலையாக இருக்கும்போது ஒவ்வொரு நிகழ்வுக்கும் கட்டணம் வசூலிப்பது போன்ற கிளவுட்-நட்பற்ற விலை மாதிரிகளைக் கொண்டுள்ளன. ஒவ்வொரு கோரிக்கையும் பணம் செலுத்தும் பயனரிடமிருந்து வரும் சேவைகளுக்கும் விளம்பரம் தொடர்பானவற்றுக்கும் இடையிலும் வேறுபாடு உள்ளது, எனவே கோரிக்கைகளில் ஒரு சிறிய சதவீதம் மட்டுமே உங்களுக்குப் பணம் ஈட்டித் தருகிறது. உங்களிடம் நிறைய தரவும் அவ்வளவு வரவுசெலவு இல்லாமலும் இருக்கலாம்.

நாளொன்றுக்கு 1B கோரிக்கைகளைப் பெறும் சில சேவைகளில் நான் பணியாற்றுகிறேன், எனவே எங்கள் சொந்தக் கண்காணிப்பையும் பதிவையும் ஹோஸ்ட் செய்வது அர்த்தமுள்ளது. உங்கள் அளவுகள் குறைவாக இருந்தால், ஹோஸ்ட் செய்யப்பட்ட சேவைகள் எளிதானவை.

AWS சேவைகள் கலவையானவை

AWS சேவைகளுடனான என் அனுபவம் கலவையானது. அவர்களின் Elasticsearch சேவை நிலையற்றதாக இருந்தது, எனவே அதற்கு நாங்கள் எங்கள் சொந்த நிகழ்வுகளை இயக்குகிறோம். CloudWatch அளவீடுகள் விலை உயர்ந்தவை, எனவே நாங்கள் பொதுவாக அவற்றைப் பயன்பாட்டுக்கு அல்ல, "உள்கட்டமைப்பு" நிலை அளவீடுகளுக்கு மட்டுமே பயன்படுத்துகிறோம், அதாவது நிகழ்வில் இயங்கும் மென்பொருளை விட AWS க்கு என்ன நடக்கிறது என்பது சிறப்பாகத் தெரியக்கூடிய ஆரோக்கியம் தொடர்பான அளவீடுகள். CloudWatch Logs புதுப்பிக்க மெதுவாக இருக்கலாம், அவ்வளவு மெட்டாடேட்டா இல்லை. ELK ஐ இயக்குவது அதற்கு உதவுகிறது. எனக்கு உண்மையிலேயே நிகழ்நேரத் தரவு வேண்டுமானால், பதிவுகளுக்கான போக்குவரத்தாக Kafka ஐப் பயன்படுத்துவது சிறந்தது. Logstash அதை நன்றாக ஆதரிக்கிறது. ஒரு Kafka கொத்தை நிர்வகிப்பது மென்மனம் கொண்டவர்களுக்கானது அல்ல, இருப்பினும், நிறைய வெளிப்படையான குழாய்வேலை உள்ளது.

Kafka

கருத்து: Kafka சில நேரங்களில் மிகவும் தந்திரமானதாக இருக்கலாம், அல்லது Kafka பாறையைப் போல உறுதியாக இருக்கலாம், அது அங்கே எல்லாவற்றையும் இணைத்துக்கொண்டிருப்பதை நீங்கள் கிட்டத்தட்ட மறந்துவிடுவீர்கள்.

கருத்து: Kafka உறுதியாக இருந்தது, ஆனால் அதை இயக்குவதற்கு ஆச்சரியப்படத்தக்க அளவு வேலை ஆனது. நான் அதை ஒரு தொடர்புடைய தரவுத்தளம் போல நினைக்கிறேன் ஆனால் நீங்கள் "இயற்பியல்" அடுக்கில் மட்டுமே வேலை செய்கிறீர்கள், எ.கா. tablespaces, கோப்புகள், பகிர்வுகள். ஆரம்பத்தில் மேலாண்மைப் பயன்பாடுகள் குறைவாக இருந்த சில நேரங்கள் இருந்தன, நாங்கள் எ.கா. ஒரு நுகர்வோர் குழுவை மீட்டமைக்கப் நிரல்களை எழுத வேண்டியிருந்தது. 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 ஐப் போன்ற scraping மற்றும் tag தொடரியலைப் பயன்படுத்துகிறது.

Prometheus + alertmanager + Rollbar + Graylog + Grafana

அளவீடுகளுக்கு Prometheus + alertmanager. <3 Prometheus.

பதிவு/பிழை அறிக்கையிடலுக்கு Rollbar/Graylog (இங்கே சில ஒன்றிணைவு உள்ளது; ஒரு சிறிய சேவைக்கு இரண்டும் தேவைப்படாமல் இருக்கலாம்).

தற்போது, எச்சரிக்கைகள் ஆர்வமுள்ள தரப்பினர் அறிவிப்புகளை இயக்கியுள்ள சில Slack சேனல்களில் ஒன்றுக்குச் செல்கின்றன. நாங்கள் அழைப்பில்-இருப்பது பற்றி மிகவும் தீவிரமாக இருந்தால் அவை PagerDuty/VictorOps/போன்றவற்றுக்குச் செல்லும்.

வரைபடங்கள் மற்றும் டாஷ்போர்டிங்குக்கு Grafana. அவர்களின் வரவிருக்கும் பதிவு வசதிகள் Graylog இன் தேவையை நீக்குமா என்பதைக் காணவும் ஆவலுடன் எதிர்பார்க்கிறேன்.

Thanos

எங்கள் HA அமைவின் முன்-முனையாக Thanos ஐப் பயன்படுத்துகிறோம். HA இணைகளை நகலகற்றுவது எப்படி என்பது அதற்குத் தெரியும்.

நாங்கள் தற்போது 6 மாத உள்ளூர் Prometheus தரவை வைத்திருக்கிறோம். இது எங்களுக்கு நியாயமாக நன்றாக வேலை செய்கிறது. ஆனால் நீண்டகாலத் தரவுச் சேமிப்புக்காக எங்கள் Thanos அமைவில் bucket சேமிப்பை வெளியிடும் நடுவில் இருக்கிறேன். கோட்பாட்டில், நாங்கள் இப்போது பயன்படுத்தும் GCE நிலையான நிலையான வட்டை விட GCS சேமிப்பு சுமார் 30% மலிவாக இருக்கும்.

Prometheus தரவை நாங்கள் தற்போது காப்புப் பிரதி எடுப்பதில்லை. எச்சரிக்கைக்குப் போதுமான அளவு இருப்பதற்கு அப்பால் தரவு எங்களுக்கு உண்மையில் முக்கியமல்ல. எங்கள் ஒட்டுமொத்தப் படை வரிசைப்படுத்தல் ஆண்டுக்கு ஆண்டு மிகவும் மாறுகிறது, சில மாதங்களுக்கு மேற்பட்ட வரலாற்றுத் தரவு உண்மையில் சுவாரஸ்யமானதல்ல. ஆண்டுக்கு-ஆண்டு சில முக்கிய புள்ளிவிவரங்கள் இருப்பது சுவாரஸ்யமாக இருக்கலாம், நான் முக்கிய-புள்ளிவிவரப் பதிவு விதிகளின் தொகுப்பை அமைத்து அவற்றை Federation உடன் சேமிக்கலாம் அல்லது Thanos அதைக் கவனித்துக்கொள்ளட்டும்.

திருத்தம்: சிறிய மறுப்பு, நான் ஒரு Prometheus உருவாக்குநர்.

Prometheus HA

Prometheus இல் HA நகலெடுப்பு மூலம் செய்யப்படுகிறது, நீங்கள் பல poppers ஐ இயக்குகிறீர்கள், பலவற்றை வாக்கெடுத்து தரவை நகலகற்ற வழிகள் உள்ளன

வலையமைப்பை முடிவு செய்து வெவ்வேறு 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 காட்சிப்படுத்தல்களுக்குப் பயன்படுத்தப்படுகிறது.

இந்த அமைவு எங்கள் சூழலில் என்ன நடக்கிறது என்பது குறித்து எங்களை விரிவாகத் தெரிவிப்பதில் மிகவும் திறம்பட்டதாக இருந்துள்ளது. நாங்கள் சுமார் 110 பணி-முக்கிய சேவையகங்களையும் சுமார் 760 தரவுப் புள்ளிகளையும் இயக்கிக் கண்காணிக்கிறோம், ஏழு ஆண்டுகளுக்கு மேலாக இந்தக் காலை அமைப்பை வைத்திருக்கிறோம்.

ஏதாவது ஒரு கட்டத்தில் Graylog அல்லது ELk உடன் பதிவுகளைத் திரட்டவும் விரும்புகிறேன்.

Prometheus + Grafana + AlertManager

அருமையான Prometheus Operator helm chart வழியாக Prometheus + Grafana + AlertManager. எங்கள் எளிய min 3 max 5 GKE கணுக்களுக்கு ELK மிகவும் கனமானது என்பதை நாங்கள் கவனித்ததால் பதிவு இன்னும் LogDNA birch திட்டத்துக்குச் செல்கிறது.

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 மூலம், நிரலாளர்கள் எளிதாகத் தங்கள் சொந்தச் சரிபார்ப்புகளை (அவர்கள் ஒவ்வொரு சில நாட்களுக்கும் செய்கிறார்கள் - 100 சரிபார்ப்புகள் வெளியே செல்கின்றன, 100 பிற சரிபார்ப்புகள் உள்ளே வருகின்றன) பெரிய அளவில் பூஜ்ஜியத் தொல்லையுடன் வரையறுக்க முடியும்.

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 scrape செய்யும் ஆரோக்கியச் சரிபார்ப்புகளை எங்கள் பயன்பாட்டில் குறியீடாக்குகிறோம்.

நேரத்தொடர் சேமிப்புக்கு 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/cronjobs க்கு 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 கண்காணிப்பையும் தள பரிவர்த்தனைக் கண்காணிப்பையும் செய்கிறோம்.

API இடத்தில் செயலில் / செயற்கைக் கண்காணிப்பு சற்று வரையறுக்கப்பட்டதாகவும் (விலை உயர்ந்ததாகவும்) இருந்ததால் Checkly ஐத் தொடங்கினேன். உலாவி-அடிப்படையிலான / ஸ்கிரிப்ட் செய்யப்பட்ட கண்காணிப்பு இன்னும் தனியுரிமை, விலை உயர்ந்தது. நாங்கள் 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 தரவுத்தளம் குழப்பத்தில் மாட்டினால் (இது துரதிர்ஷ்டவசமாக எங்களுக்கு ஒவ்வொரு 2-3 மாதங்களுக்கும் நடக்கிறது) நாங்கள் HA பற்றி கவலைப்படுவதில்லை, அதற்குப் பதிலாக தரவை அகற்றிவிட்டு வாழ்க்கையைத் தொடர்கிறோம். உங்களுக்கு HA அல்லது நீண்டகாலத் தக்கவைப்பு கண்டிப்பாகத் தேவையென்றால், வாழ்த்துகள்.

Datadog + Prometheus + Grafana

நான் இங்கு வந்தபோது கண்காணிப்பும் எச்சரிக்கையும் இல்லாததால் Datadog ஐ மாதாந்திர அடிப்படையில் அமைத்தேன். எங்கள் தளங்களில் சில மட்டுமே இயக்க நேரத்துக்காக ஒவ்வொரு 5 நிமிடத்துக்கும் கண்காணிக்கப்பட்டன. Datadog நிச்சயமாக அமைக்க எளிதானது. நான் மற்ற எல்லாச் சிக்கல்களையும் தீர்த்து முடிக்கும்போது, Prometheus+Grafana வுக்கு மாறுவேன். பதிவு மேலாண்மை குறித்து இன்னும் 100% முடிவு செய்யவில்லை.

Nagios + ELK

நாங்கள் ஆதரிக்கும் 100+ க்கும் மேற்பட்ட தயாரிப்புகள் எங்களிடம் உள்ளன.

உள்வளாகத்துக்கு, பெரும்பாலும் Nagios மற்றும் ELK. கிளவுடுக்கு, DataDog இலிருந்து NewRelic க்கு இடம்பெயர்கிறோம்.

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

நாங்கள் datadog ஐப் பயன்படுத்தி வந்தோம் ஆனால் எங்கள் தேவைகளுக்கு அது மிகவும் விலை உயர்ந்தது எனக் கண்டோம். தவறாக எண்ணாதீர்கள் அது அருமை, ஆனால் அதற்குப் பெரிய செலவு உள்ளது. DD செலவில் சுமார் 2-3 மாதங்களுக்குச் சமமான ஆண்டு சந்தாவுடன் site24x7.com ஐ எங்களால் அமைக்க முடிந்தது.

எங்கள் கண்காணிப்புத் தொகுப்பு:

Site24x7 - APM, வெளிப்புற URL கண்காணிப்பு, SMTP அஞ்சல் ஓட்டக் கண்காணிப்பு, ssl காலாவதிகள் மற்றும் செயல்முறைக் கண்காணிப்பு.

StatusCake - URL கண்காணிப்பு மற்றும் உறுதிப்படுத்தலுக்கு - site24x7 ஏதாவது தவறவிட்டால் அது எங்கள் காப்பு (அது தவறவிடுவதில்லை) ஆனால் எங்கள் தேவைகளுக்கு வெளிப்புற போர்ட் மற்றும் சேவைக் கண்காணிப்புக்கு SC அதிக நெகிழ்வானது.

இரண்டு கருவிகளும் PagerDuty க்கு உயர்த்துகின்றன, பின்னர் slack இல் எங்கள் உயர்த்தல்களைப் பெறுகிறோம்.

SumoLogic - பதிவுக் கண்காணிப்புக்கு (இது அருமையான கருவி ஆனால் எங்கள் தேவைகளுக்குச் சற்றுச் சிக்கலானது)

slack இலிருந்து எச்சரிக்கையை ack செய்யலாம் அல்லது தீர்க்கலாம்.

பின்னர் எங்களிடம் 'BedOps' க்கு commando.io உடன் இணையும் பல site24x7 தானியக்கங்கள் உள்ளன நாங்கள் அதை அழைப்பது போல - எச்சரிக்கை தூண்டப்படும் இடத்தில், நிலைமையைச் சரிசெய்யும் முயற்சியாக சில ஸ்கிரிப்ட்கள் அல்லது தானியக்கங்களைத் தொடங்குகிறோம் (99% நேரம் தானியக்கமும் எங்கள் ஸ்கிரிப்ட்களும் எங்களைச் சிக்கலிலிருந்து தள்ளி வைத்திருக்கின்றன)

தானியக்கம் தோல்வியடையும்போது அல்லது சரிசெய்யப்பட வேண்டிய நோக்கத்துக்கு வெளியே ஏதாவது இருக்கும்போது எங்கள் KB இல் உள் runbook கள் உள்ளன.

Prometheus + AlertManager + Grafana + Stackdriver

எங்கள் GKE கொத்துகள் மற்றும் VM களில் அளவீடுகளுக்கு Prometheus (Operator) / AlertManager / Grafana.

பதிவுகளுக்கு Google Stackdriver (ஏனெனில் இது சேர்க்கப்பட்டுள்ளது, இயல்பாகச் செயலில் உள்ளது, தற்போது எங்கள் தேவைகளுக்குப் போதுமானது).

Zabbix

அனைத்துக்கும் Zabbix. கூடுதல் மென்பொருள் தேவையில்லை.