మెట్రిక్స్, మానిటర్లు, హెచ్చరికలు

విషయసూచిక:

సారాంశం
వివరాలు
సంబంధితాలు
గమనికలు

సారాంశం

సమస్య

మా అప్లికేషన్లు ఎంత బాగా పనిచేస్తున్నాయో, ఎప్పుడు సమస్య ఉందో తెలుసుకోవాలనుకుంటున్నాం కాబట్టి మేము మెట్రిక్స్, మానిటర్లు, హెచ్చరికలను వాడాలనుకుంటున్నాం.

నిర్ణయం

WIP.

స్థితి

సమాచారాన్ని సేకరిస్తున్నాం. సాధ్యమైన స్పెక్ట్రమ్ రెండు చివరల నుండి ప్రారంభిస్తున్నాం: అత్యధికంగా సిఫార్సు చేసిన పాత ఉచిత సాధనం (Nagios), అత్యధికంగా సిఫార్సు చేసిన కొత్త చెల్లింపు సాధనం (New Relic).

వివరాలు

ఊహలు

ఆధునికమైన, వేగవంతమైన, నమ్మదగిన, స్పందించే వెబ్ యాప్లను సృష్టించాలని మేము కోరుకుంటున్నాం.

నిర్మించడం కంటే కొనాలని మేము కోరుకుంటున్నాం.

పరిమితులు

మా డెవ్ఆప్స్ పైప్లైన్తో, మా డిప్లాయ్మెంట్ క్లౌడ్లతో బాగా పనిచేసే సాధనాలు మాకు కావాలి.

వైఖరులు

ప్రస్తుతం వైఖరులను పరిశోధిస్తున్నాం.

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 దృఢంగా ఉంది, కానీ దాన్ని ప్రారంభించడానికి ఆశ్చర్యకరమైన మొత్తంలో పని పట్టింది. నేను దాన్ని రిలేషనల్ డేటాబేస్ లాగా భావిస్తాను కానీ మీరు కేవలం "భౌతిక" పొరలో, ఉదా. టేబుల్స్పేస్లు, ఫైళ్లు, పార్టిషన్లలో పని చేస్తున్నారు. ప్రారంభంలో కొన్నిసార్లు నిర్వహణ యుటిలిటీలు లోపించాయి, ఉదా. కన్స్యూమర్ గ్రూప్ను రీసెట్ చేయడానికి మేము ప్రోగ్రామ్లు రాయాల్సి వచ్చింది. http://howfuckedismydatabase.com/nosql/

వ్యాఖ్య: మేము Kafkaను లాగ్ సందేశాలకు "బఫర్"గా, అనేక సర్వర్ల నుండి వచ్చే డేటాపై రియల్ టైమ్ స్ట్రీమ్ ప్రాసెసింగ్ చేయగల చోటుగా వాడతాం. మాకు DDOS దాడి వస్తే, అనేక ఇన్స్టెన్స్ల అంతటా డేటాను విశ్లేషించడానికి మార్గం కావాలి. మనం సర్వర్ల నుండి నేరుగా ELKకి లాగ్ చేస్తే, లోడ్ Elasticsearch క్లస్టర్ను పేల్చేయగలదు.

వ్యాఖ్య: Kafka మాకు మంచిది ఎందుకంటే మాకు DDOS దాడి వస్తే, అనేక ఇన్స్టెన్స్ల అంతటా డేటాను విశ్లేషించడానికి మార్గం కావాలి. మనం సర్వర్ల నుండి నేరుగా ELKకి లాగ్ చేస్తే, లోడ్ Elasticsearch క్లస్టర్ను పేల్చేయగలదు.

వ్యాఖ్య: Kafka తక్కువ పని చేస్తుంది, మరింత సమర్థవంతం, కాబట్టి లోడ్ను బాగా నిర్వహించగలదు. మేము Kafka పనిని క్యూలో పెట్టి మళ్లీ ప్రయత్నిస్తాం. Elasticsearch ఇబ్బంది పడుతున్నప్పుడు జరిగేలా కాకుండా, Kafka ఓవర్లోడ్ కావడం Kibanaతో ఇంటరాక్టివ్ పని చేయడానికి ప్రయత్నిస్తున్న వినియోగదారులను ప్రభావితం చేయదు.

వ్యాఖ్య: స్ట్రీమ్ ప్రాసెసింగ్ ఎక్కువగా దుర్వినియోగాన్ని వెతుకుతుంది, ఉదా. మొత్తం క్లస్టర్ అంతటా ఒకే IP నుండి చాలా ట్రాఫిక్, ఆపై బ్లాక్ను మొత్తం క్లస్టర్ అంతటా పంచుకోవడం.

వ్యాఖ్య: logstash-output-kafka ప్లగిన్ ప్రస్తుతం చాలా నమ్మదగనిది. దాని GitHub ఇష్యూల పేజీలోని అనేక సమస్యలు నన్ను కాటేశాయి, అవి ఎప్పటికీ సరిచేయబడేలా కనిపించవు. దాన్ని వాడటం మానేసి, మా యాప్ల నుండి నేరుగా 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 జతలను డీడూప్లికేట్ చేయడం దానికి తెలుసు.

మేము ప్రస్తుతం 6 నెలల స్థానిక Prometheus డేటాను ఉంచుతున్నాం. ఇది మాకు సహేతుకంగా బాగా పనిచేస్తుంది. కానీ దీర్ఘకాలిక డేటా నిల్వ కోసం మా Thanos సెటప్కు బకెట్ స్టోరేజ్ను విడుదల చేసే మధ్యలో ఉన్నాను. సిద్ధాంతంలో, GCS స్టోరేజ్ మేము ప్రస్తుతం వాడుతున్న GCE ప్రామాణిక శాశ్వత డిస్క్ కంటే దాదాపు 30% చౌకగా ఉంటుంది.

మేము ప్రస్తుతం Prometheus డేటాను బ్యాకప్ చేయడం లేదు. హెచ్చరిక కోసం తగినంత ఉండటం మించి ఆ డేటా మాకు నిజంగా ముఖ్యం కాదు. మా మొత్తం ఫ్లీట్ డిప్లాయ్మెంట్ సంవత్సరానికి సంవత్సరం చాలా మారుతుంది కాబట్టి కొన్ని నెలల కంటే పాత చారిత్రక డేటా నిజంగా ఆసక్తికరం కాదు. సంవత్సరం-వారీగా కొన్ని ప్రధాన గణాంకాలు ఆసక్తికరంగా ఉండవచ్చు, నేను ప్రధాన-గణాంకాల రికార్డింగ్ నియమాల సమితిని ఏర్పాటు చేసి వాటిని Federationతో నిల్వ చేయవచ్చు లేదా Thanosను చూసుకోనివ్వవచ్చు.

సవరణ: చిన్న నిరాకరణ, నేను Prometheus డెవలపర్ను.

Prometheus HA

Prometheusలో HA అనేది పునరావృతం ద్వారా చేయబడుతుంది, మీరు బహుళ పాపర్లను నడుపుతారు, బహుళ వాటిని పోల్ చేసి డేటాను డీడూప్లికేట్ చేయడానికి మార్గాలు ఉన్నాయి

విస్తరణ అనేది నెట్వర్క్ను నిర్ణయించడం, నెట్వర్క్లోని వేర్వేరు భాగాలను వేర్వేరు Prometheus పోల్ చేయడం ద్వారా జరుగుతుంది

దీర్ఘకాలిక నిల్వ Prometheus బలమైన అంశం కాదు కానీ 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 హెల్మ్ చార్ట్ ద్వారా Prometheus + Grafana + AlertManager. GKEలో మా వినయపూర్వక కనిష్ఠ 3 గరిష్ఠ 5 నోడ్లకు ELK చాలా బరువుగా ఉందని గమనించినందున లాగ్ ఇప్పటికీ LogDNA birch ప్లాన్కు వెళ్తుంది.

DataDog + Sentry + PagerDuty.

నేను Nagios, Icinga, Zabbix, ELK, Greylog2, Influx, ఇంకా అనేక ఇతర సాధనాలతో సహా అన్ని రకాల సాఫ్ట్వేర్ను వాడి నా స్వంత పర్యవేక్షణ పరిష్కారాలన్నీ నడిపేవాడిని, కానీ నిజం ఏమిటంటే మీ స్వంత పర్యవేక్షణ ఇన్ఫ్రాస్ట్రక్చర్ను నడపడంలో చాలా శ్రమ ఉంది, ముఖ్యంగా మరొకరు మీ కోసం చేయడానికి మీరు వారికి అంత తక్కువ రేట్లు చెల్లించగలిగినప్పుడు!

పర్యవేక్షణ ఇన్ఫ్రాను నడపడానికి ఇతరులకు చెల్లించడం నా క్లయింట్లను పర్యవేక్షణను పర్యవేక్షించడానికి బదులు తమ ప్లాట్ఫారమ్లను నడపడంపై దృష్టి పెట్టడానికి విముక్తి చేస్తుంది, అంటే వారి ప్లాట్ఫారమ్ స్థిరత్వం నుండి వారు పొందే విలువ పర్యవేక్షణ-సేవగా అయ్యే ఏ ఖర్చుల కంటే చాలా ఎక్కువ.

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

NewRelic లేదా icinga2 నుండి ప్రేరేపించబడే హెచ్చరికలో Slack/ఇమెయిల్ భాగం

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 స్క్రేప్ చేసే హెల్త్ చెక్లను మేము మా అప్లికేషన్లో కోడ్ చేస్తాం.

టైమ్-సిరీస్ నిల్వ కోసం 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

బ్యాచ్/క్రాన్జాబ్ల కోసం 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 మద్దతు బృందం చాలా స్నేహపూర్వకంగా, వెంటనే స్పందించేదిగా ఉన్నప్పటికీ నేను 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 నుండి మనం హెచ్చరికను అంగీకరించవచ్చు, లేదా పరిష్కరించవచ్చు.

తర్వాత మా వద్ద చాలా site24x7 ఆటోమేషన్లు ఉన్నాయి, అవి మేము 'BedOps' అని పిలిచే దాని కోసం commando.ioకి కనెక్ట్ అవుతాయి - హెచ్చరిక ప్రేరేపించబడినప్పుడు, పరిస్థితిని సరిచేసే ప్రయత్నంగా మేము కొన్ని స్క్రిప్ట్లను లేదా ఆటోమేషన్లను ప్రారంభిస్తాం (99% సమయం ఆటోమేషన్ + మా స్క్రిప్ట్లు మమ్మల్ని ఇబ్బంది నుండి దూరంగా ఉంచుతాయి)

ఆటోమేటాన్లు విఫలమైనప్పుడు లేదా పరిధికి వెలుపల సరిచేయాల్సిన ఏదైనా ఉన్నప్పుడు మా KBలో అంతర్గత రన్బుక్లు ఉన్నాయి.

Prometheus + AlertManager + Grafana + Stackdriver

మా GKE క్లస్టర్లు, VMలలో మెట్రిక్స్ కోసం Prometheus (Operator) / AlertManager / Grafana.

లాగ్ల కోసం Google Stackdriver (ఇది చేర్చబడి, డిఫాల్ట్గా క్రియాశీలంగా ఉంది, ప్రస్తుతం మా అవసరాలకు సరిపోతుంది కాబట్టి).

Zabbix

అన్నింటికీ Zabbix. అదనపు సాఫ్ట్వేర్ అవసరం లేదు.