ਮੈਟ੍ਰਿਕਸ, ਮਾਨੀਟਰ, ਅਲਰਟ

ਸਮੱਗਰੀ:

ਸਾਰ
ਵੇਰਵੇ
ਸੰਬੰਧਿਤ
ਨੋਟ

ਸਾਰ

ਮੁੱਦਾ

ਅਸੀਂ ਮੈਟ੍ਰਿਕਸ, ਮਾਨੀਟਰ ਅਤੇ ਅਲਰਟ ਵਰਤਣਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਅਸੀਂ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਸਾਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਕਿੰਨੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰ ਰਹੀਆਂ ਹਨ, ਅਤੇ ਇਹ ਵੀ ਕਿ ਕਦੋਂ ਕੋਈ ਸਮੱਸਿਆ ਹੈ।

ਫੈਸਲਾ

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 ਦੇ ਓਵਰਲੋਡ ਹੋਣ ਦਾ ਉਨ੍ਹਾਂ ਵਰਤੋਂਕਾਰਾਂ ਉੱਤੇ ਅਸਰ ਨਹੀਂ ਪੈਂਦਾ ਜੋ Kibana ਨਾਲ ਪਰਸਪਰ ਕਿਰਿਆਸ਼ੀਲ ਕੰਮ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਜੇ Elasticsearch ਜੂਝ ਰਿਹਾ ਹੋਵੇ ਤਾਂ ਪੈਂਦਾ।

ਟਿੱਪਣੀ: ਸਟ੍ਰੀਮ ਪ੍ਰੋਸੈਸਿੰਗ ਜ਼ਿਆਦਾਤਰ ਦੁਰਵਰਤੋਂ ਦੀ ਭਾਲ ਕਰਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਪੂਰੇ ਕਲੱਸਟਰ ਵਿੱਚ ਇੱਕ ਇਕੱਲੇ 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 ਜੋੜਿਆਂ ਦੀ ਦੁਹਰਾਈ ਹਟਾਉਣਾ ਜਾਣਦਾ ਹੈ।

ਅਸੀਂ ਫਿਲਹਾਲ ਸਥਾਨਕ Prometheus ਡਾਟਾ ਦੇ 6 ਮਹੀਨੇ ਰੱਖ ਰਹੇ ਹਾਂ। ਇਹ ਸਾਡੇ ਲਈ ਵਾਜਬ ਢੰਗ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਪਰ ਮੈਂ ਹੁਣੇ ਲੰਬੇ ਸਮੇਂ ਦੇ ਡਾਟਾ ਸਟੋਰੇਜ ਲਈ ਆਪਣੇ Thanos ਸੈੱਟਅੱਪ ਵਿੱਚ ਬਕਟ ਸਟੋਰੇਜ ਲਾਗੂ ਕਰਨ ਦੇ ਵਿਚਕਾਰ ਹਾਂ। ਸਿਧਾਂਤ ਵਿੱਚ, GCS ਸਟੋਰੇਜ ਉਸ GCE ਸਟੈਂਡਰਡ ਪਰਸਿਸਟੈਂਟ ਡਿਸਕ ਨਾਲੋਂ ਲਗਭਗ 30% ਸਸਤੀ ਹੋਵੇਗੀ ਜੋ ਅਸੀਂ ਹੁਣ ਵਰਤਦੇ ਹਾਂ।

ਅਸੀਂ ਫਿਲਹਾਲ Prometheus ਡਾਟਾ ਦਾ ਬੈਕਅੱਪ ਨਹੀਂ ਲੈਂਦੇ। ਅਲਰਟਿੰਗ ਲਈ ਕਾਫ਼ੀ ਹੋਣ ਤੋਂ ਇਲਾਵਾ ਡਾਟਾ ਸਾਡੇ ਲਈ ਸੱਚਮੁੱਚ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ। ਸਾਡੀ ਸਮੁੱਚੀ ਫਲੀਟ ਡਿਪਲਾਇਮੈਂਟ ਸਾਲ ਦਰ ਸਾਲ ਇੰਨੀ ਬਦਲਦੀ ਹੈ ਕਿ ਕੁਝ ਮਹੀਨਿਆਂ ਤੋਂ ਪੁਰਾਣਾ ਇਤਿਹਾਸਕ ਡਾਟਾ ਬਸ ਬਹੁਤਾ ਦਿਲਚਸਪ ਨਹੀਂ ਹੈ। ਸਾਲ-ਦਰ-ਸਾਲ ਕੁਝ ਮੁੱਖ ਅੰਕੜੇ ਰੱਖਣਾ ਦਿਲਚਸਪ ਹੋ ਸਕਦਾ ਹੈ, ਮੈਂ ਮੁੱਖ-ਅੰਕੜਿਆਂ ਦੇ ਰਿਕਾਰਡਿੰਗ ਨਿਯਮਾਂ ਦਾ ਸਮੂਹ ਸੈੱਟਅੱਪ ਕਰ ਸਕਦਾ ਹਾਂ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ Federation ਨਾਲ ਸਟੋਰ ਕਰ ਸਕਦਾ ਹਾਂ ਜਾਂ ਬਸ Thanos ਨੂੰ ਇਸ ਦਾ ਧਿਆਨ ਰੱਖਣ ਦੇ ਸਕਦਾ ਹਾਂ।

ਸੋਧ: ਮਾਮੂਲੀ ਅਸਵੀਕਰਨ, ਮੈਂ Prometheus ਡਿਵੈਲਪਰ ਹਾਂ।

Prometheus HA

Prometheus ਵਿੱਚ HA ਦੁਹਰਾਈ ਨਾਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤੁਸੀਂ ਕਈ poppers ਚਲਾਉਂਦੇ ਹੋ, ਕਈਆਂ ਨੂੰ ਪੋਲ ਕਰਨ ਅਤੇ ਡਾਟਾ ਦੀ ਦੁਹਰਾਈ ਹਟਾਉਣ ਦੇ ਤਰੀਕੇ ਹਨ

ਵਧਣਾ ਨੈੱਟਵਰਕ ਨੂੰ ਵੰਡਣ ਅਤੇ ਵੱਖ-ਵੱਖ Prometheus ਨੂੰ ਨੈੱਟਵਰਕ ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸੇ ਪੋਲ ਕਰਵਾਉਣ ਦਾ ਫੈਸਲਾ ਕਰਕੇ ਹੁੰਦਾ ਹੈ

ਲੰਬੇ ਸਮੇਂ ਦੀ ਸਟੋਰੇਜ prom ਦੀ ਮਜ਼ਬੂਤ ਗੱਲ ਨਹੀਂ ਹੈ ਪਰ ਇਸ ਨੂੰ 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। ਲੌਗ ਅਜੇ ਵੀ LogDNA birch ਪਲਾਨ ਨੂੰ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਅਸੀਂ ਵੇਖਿਆ ਕਿ GKE ਉੱਤੇ ਸਾਡੇ ਨਿਮਾਣੇ ਘੱਟੋ-ਘੱਟ 3 ਵੱਧ ਤੋਂ ਵੱਧ 5 ਨੋਡਾਂ ਲਈ ELK ਬਹੁਤ ਭਾਰੀ ਹੈ।

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

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 ਸਕ੍ਰੇਪ ਕਰਦਾ ਹੈ।

ਸਮਾਂ-ਲੜੀ ਸਟੋਰੇਜ ਲਈ 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 ਦੀ ਥਾਂ ELK ਵਰਤ ਸਕਦੇ ਹੋ, ਜਦੋਂ ਤੱਕ ਤੁਹਾਡੀ ਸੁਰੱਖਿਆ ਟੀਮ Splunk ਨੂੰ ਤਰਜੀਹ ਨਾ ਦੇਵੇ।

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 ਇੰਸਟੈਂਸ ਤੋਂ ਦੂਜੀ ਤੱਕ ਮੈਟ੍ਰਿਕਸ "ਧੱਕਣ/ਅੱਗੇ ਭੇਜਣ" ਲਈ 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 ਵਿੱਚ ਅਲਰਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਸੀਂ logz.io ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਪਰਤ ਤੋਂ ਗਲਤੀ ਪੱਧਰ ਦੇ ਲੌਗਾਂ ਦੀ ਇੱਕ ਖਾਸ ਮਾਤਰਾ ਉੱਤੇ slack ਵਿੱਚ ਅਲਰਟ ਕਰਨ ਲਈ ਸੰਰਚਿਤ ਕੀਤਾ ਹੈ।

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 ਕਰ ਸਕਦੇ ਹਾਂ, ਜਾਂ ਉਪਾਅ ਕਰ ਸਕਦੇ ਹਾਂ।

ਫਿਰ ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ site24x7 ਸਵੈਚਾਲਨ ਹਨ ਜੋ ਫਿਰ 'BedOps' ਲਈ commando.io ਨਾਲ ਜੁੜਦੇ ਹਨ, ਜਿਵੇਂ ਅਸੀਂ ਇਸ ਨੂੰ ਕਹਿੰਦੇ ਹਾਂ - ਜਿੱਥੇ ਕੋਈ ਅਲਰਟ ਚਾਲੂ ਹੁੰਦਾ ਹੈ, ਅਸੀਂ ਸਥਿਤੀ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਵਜੋਂ ਕੁਝ ਸਕ੍ਰਿਪਟਾਂ ਜਾਂ ਸਵੈਚਾਲਨ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ (99% ਸਮੇਂ ਸਵੈਚਾਲਨ + ਸਾਡੀਆਂ ਸਕ੍ਰਿਪਟਾਂ ਸਾਨੂੰ ਮੁਸ਼ਕਲ ਤੋਂ ਬਾਹਰ ਰੱਖਦੀਆਂ ਹਨ)।

ਸਾਡੇ ਕੋਲ ਆਪਣੇ KB ਵਿੱਚ ਅੰਦਰੂਨੀ ਰਨਬੁੱਕ ਹਨ ਜਦੋਂ ਸਵੈਚਾਲਨ ਫੇਲ੍ਹ ਹੋ ਜਾਣ ਜਾਂ ਜੇ ਕੋਈ ਅਜਿਹੀ ਚੀਜ਼ ਹੈ ਜੋ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹੈ ਅਤੇ ਠੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

Prometheus + AlertManager + Grafana + Stackdriver

ਸਾਡੇ GKE ਕਲੱਸਟਰਾਂ ਅਤੇ VM ਵਿੱਚ ਮੈਟ੍ਰਿਕਸ ਲਈ Prometheus (Operator) / AlertManager / Grafana।

ਲੌਗਾਂ ਲਈ Google Stackdriver (ਕਿਉਂਕਿ ਇਹ ਸ਼ਾਮਲ ਅਤੇ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਰਗਰਮ ਹੈ ਅਤੇ ਫਿਲਹਾਲ ਸਾਡੀਆਂ ਲੋੜਾਂ ਲਈ ਕਾਫ਼ੀ ਹੈ)।

Zabbix

ਹਰ ਚੀਜ਼ ਲਈ Zabbix। ਕਿਸੇ ਵਾਧੂ ਸਾਫਟਵੇਅਰ ਦੀ ਲੋੜ ਨਹੀਂ।