ಮೆಟ್ರಿಕ್, ಮಾನಿಟರ್, ಎಚ್ಚರಿಕೆಗಳು

ವಿಷಯಗಳು:

ಸಾರಾಂಶ
ವಿವರಗಳು
ಸಂಬಂಧಿತ
ಟಿಪ್ಪಣಿಗಳು

ಸಾರಾಂಶ

ಸಮಸ್ಯೆ

ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಎಷ್ಟು ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿವೆ ಮತ್ತು ಸಮಸ್ಯೆ ಯಾವಾಗ ಇದೆ ಎಂದು ತಿಳಿಯಲು ನಾವು ಬಯಸುವುದರಿಂದ, ಮೆಟ್ರಿಕ್‌ಗಳು, ಮಾನಿಟರ್‌ಗಳು ಮತ್ತು ಎಚ್ಚರಿಕೆಗಳನ್ನು ಬಳಸಲು ನಾವು ಬಯಸುತ್ತೇವೆ.

ನಿರ್ಧಾರ

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 ಗಟ್ಟಿಯಾಗಿತ್ತು, ಆದರೆ ಅದನ್ನು ಚಾಲನೆಗೆ ತರಲು ಆಶ್ಚರ್ಯಕರ ಪ್ರಮಾಣದ ಕೆಲಸ ಬೇಕಾಯಿತು. ನಾನು ಅದನ್ನು ರಿಲೇಶನಲ್ ಡೇಟಾಬೇಸ್‌ನಂತೆ ಭಾವಿಸುತ್ತೇನೆ ಆದರೆ ನೀವು ಕೇವಲ "ಭೌತಿಕ" ಪದರದಲ್ಲಿ, ಉದಾ. ಟೇಬಲ್‌ಸ್ಪೇಸ್‌ಗಳು, ಕಡತಗಳು ಮತ್ತು ವಿಭಜನೆಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೀರಿ. ಆರಂಭದಲ್ಲಿ ನಿರ್ವಹಣಾ ಉಪಯುಕ್ತತೆಗಳ ಕೊರತೆಯಿದ್ದ ಕೆಲವು ಸಮಯಗಳಿದ್ದವು, ಮತ್ತು ಉದಾ. ಕನ್ಸ್ಯೂಮರ್ ಗುಂಪನ್ನು ಮರುಹೊಂದಿಸಲು ನಾವು ಪ್ರೋಗ್ರಾಂಗಳನ್ನು ಬರೆಯಬೇಕಾಯಿತು. http://howfuckedismydatabase.com/nosql/

ಕಾಮೆಂಟ್: ಲಾಗ್ ಸಂದೇಶಗಳಿಗೆ "ಬಫರ್" ಆಗಿ, ಮತ್ತು ಅನೇಕ ಸರ್ವರ್‌ಗಳಿಂದ ಬರುವ ಡೇಟಾದ ಮೇಲೆ ನೈಜ-ಸಮಯದ ಸ್ಟ್ರೀಮ್ ಸಂಸ್ಕರಣೆ ಮಾಡಬಹುದಾದ ಸ್ಥಳವಾಗಿ ನಾವು Kafka ಬಳಸುತ್ತೇವೆ. ನಮಗೆ DDOS ದಾಳಿ ಬಂದರೆ, ಅನೇಕ ನಿದರ್ಶನಗಳಾದ್ಯಂತ ಡೇಟಾವನ್ನು ವಿಶ್ಲೇಷಿಸಲು ನಮಗೆ ಮಾರ್ಗ ಬೇಕು. ನಾವು ಸರ್ವರ್‌ಗಳಿಂದ ನೇರವಾಗಿ ELK ಗೆ ಲಾಗ್ ಮಾಡುತ್ತಿದ್ದರೆ, ಲೋಡ್ Elasticsearch ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸ್ಫೋಟಿಸಬಹುದು.

ಕಾಮೆಂಟ್: Kafka ನಮಗೆ ಒಳ್ಳೆಯದು ಏಕೆಂದರೆ ನಮಗೆ DDOS ದಾಳಿ ಬಂದರೆ, ಅನೇಕ ನಿದರ್ಶನಗಳಾದ್ಯಂತ ಡೇಟಾವನ್ನು ವಿಶ್ಲೇಷಿಸಲು ನಮಗೆ ಮಾರ್ಗ ಬೇಕು. ನಾವು ಸರ್ವರ್‌ಗಳಿಂದ ನೇರವಾಗಿ ELK ಗೆ ಲಾಗ್ ಮಾಡುತ್ತಿದ್ದರೆ, ಲೋಡ್ Elasticsearch ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸ್ಫೋಟಿಸಬಹುದು.

ಕಾಮೆಂಟ್: Kafka ಕಡಿಮೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಹೆಚ್ಚು ದಕ್ಷ, ಆದ್ದರಿಂದ ಅದು ಲೋಡ್ ಅನ್ನು ಉತ್ತಮವಾಗಿ ನಿಭಾಯಿಸಬಲ್ಲದು. ಮತ್ತು ನಾವು Kafka ಕೆಲಸವನ್ನು ಸರದಿಯಲ್ಲಿಟ್ಟು ಮರುಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ಮತ್ತು Kafka ಓವರ್‌ಲೋಡ್ ಆಗುವುದು, Elasticsearch ಹೆಣಗಾಡುತ್ತಿದ್ದರೆ ಆಗುವಂತೆ, 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 ಸೆಟಪ್‌ಗೆ ಬಕೆಟ್ ಸಂಗ್ರಹಣೆಯನ್ನು ಹೊರತರುವ ನಡುವೆ ನಾನು ಇದ್ದೇನೆ. ಸಿದ್ಧಾಂತದಲ್ಲಿ, ನಾವು ಈಗ ಬಳಸುತ್ತಿರುವ GCE ಪ್ರಮಾಣಿತ ಶಾಶ್ವತ ಡಿಸ್ಕ್‌ಗಿಂತ GCS ಸಂಗ್ರಹಣೆ ಸುಮಾರು 30% ಅಗ್ಗವಾಗಿರುತ್ತದೆ.

ನಾವು ಈಗ Prometheus ಡೇಟಾವನ್ನು ಬ್ಯಾಕಪ್ ಮಾಡುವುದಿಲ್ಲ. ಎಚ್ಚರಿಕೆಗೆ ಸಾಕಷ್ಟು ಇರುವುದನ್ನು ಹೊರತುಪಡಿಸಿ ಡೇಟಾ ನಮಗೆ ನಿಜವಾಗಿಯೂ ಮುಖ್ಯವಲ್ಲ. ನಮ್ಮ ಒಟ್ಟಾರೆ ಫ್ಲೀಟ್ ನಿಯೋಜನೆ ವರ್ಷದಿಂದ ವರ್ಷಕ್ಕೆ ಎಷ್ಟು ಬದಲಾಗುತ್ತದೆಂದರೆ ಕೆಲವು ತಿಂಗಳುಗಳಿಗಿಂತ ಹಳೆಯ ಐತಿಹಾಸಿಕ ಡೇಟಾ ಅಷ್ಟೊಂದು ಆಸಕ್ತಿದಾಯಕವಲ್ಲ. ವರ್ಷದಿಂದ ವರ್ಷಕ್ಕೆ ಕೆಲವು ಮೂಲ ಅಂಕಿಅಂಶಗಳನ್ನು ಹೊಂದಿರುವುದು ಆಸಕ್ತಿದಾಯಕವಾಗಿರಬಹುದು, ನಾನು ಮೂಲ-ಅಂಕಿಅಂಶಗಳ ರೆಕಾರ್ಡಿಂಗ್ ನಿಯಮಗಳ ಸಮೂಹವನ್ನು ಹೊಂದಿಸಿ ಅವನ್ನು Federation ನೊಂದಿಗೆ ಸಂಗ್ರಹಿಸಬಹುದು ಅಥವಾ Thanos ಅದನ್ನು ನೋಡಿಕೊಳ್ಳಲು ಬಿಡಬಹುದು.

ಸಂಪಾದನೆ: ಸಣ್ಣ ಹಕ್ಕುತ್ಯಾಗ, ನಾನು Prometheus ಡೆವಲಪರ್.

Prometheus HA

Prometheus ನಲ್ಲಿ HA ಅನ್ನು ನಕಲು ಮಾಡುವ ಮೂಲಕ ಮಾಡಲಾಗುತ್ತದೆ, ನೀವು ಅನೇಕ poppers ಚಲಾಯಿಸುತ್ತೀರಿ, ಅನೇಕವನ್ನು ಪೋಲ್ ಮಾಡಿ ಡೇಟಾವನ್ನು ಡಿಡೂಪ್ಲಿಕೇಟ್ ಮಾಡಲು ಮಾರ್ಗಗಳಿವೆ

ನೆಟ್‌ವರ್ಕ್ ನಿರ್ಧರಿಸಿ ವಿಭಿನ್ನ Prometheus ಗಳು ನೆಟ್‌ವರ್ಕ್‌ನ ವಿಭಿನ್ನ ಭಾಗಗಳನ್ನು ಪೋಲ್ ಮಾಡುವುದರಿಂದ ವಿಸ್ತರಣೆ ಸಾಧ್ಯ

ದೀರ್ಘಕಾಲೀನ ಸಂಗ್ರಹಣೆ proms ನ ಬಲವಾದ ಅಂಶವಲ್ಲ ಆದರೆ ಅದನ್ನು influxes ಅಥವಾ 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 ಚಾರ್ಟ್ ಮೂಲಕ 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 ಗೆ ಬದಲಾಯಿಸುತ್ತೇವೆ.

ಹಕ್ಕುತ್ಯಾಗ: ನಾನು Sematextan.

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

ಬ್ಯಾಚ್/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 ನ ಬೆಂಬಲ ತಂಡ ಅತಿ ಸ್ನೇಹಪರ ಮತ್ತು ಸ್ಪಂದನಶೀಲವಾಗಿದ್ದರೂ ನಾನು SignalFX ನ ದೊಡ್ಡ ಅಭಿಮಾನಿಯಲ್ಲ. ನನಗೆ Splunk (ನೀವು ಪಾವತಿಸಲು ಸಾಧ್ಯವಾದರೆ ಯೋಗ್ಯ), PagerDuty ಮತ್ತು Slack ಇಷ್ಟ.

C ಹೆಚ್ಚಾಗಿ G ಆಗಿದ್ದ, ಅಂದರೆ Grafana, TICK ಸ್ಟ್ಯಾಕ್ ಅನ್ನು ನಾನು ಬಳಸುತ್ತಿದ್ದೆ, ಆದರೂ 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 ವರ್ಸಸ್ 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. ಹೆಚ್ಚುವರಿ ತಂತ್ರಾಂಶದ ಅಗತ್ಯವಿಲ್ಲ.