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 + Grafana-র জনপ্রিয়তা সবচেয়ে ভালো।

প্রভাব

করণীয় (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 পছন্দ করি। আপনার প্রচুর ডেটা থাকলে সেবাগুলো ভীতিকরভাবে ব্যয়বহুল হতে পারে, এবং কখনো কখনো এমন মূল্য নির্ধারণ মডেল থাকে যা ক্লাউড-বান্ধব নয়, যেমন ইনস্ট্যান্স গতিশীল হওয়া সত্ত্বেও ইনস্ট্যান্স প্রতি চার্জ করা। যেসব সেবায় প্রতিটি অনুরোধ অর্থ প্রদানকারী ব্যবহারকারীর কাছ থেকে আসে এবং যেগুলো বিজ্ঞাপন-সংক্রান্ত, ফলে অনুরোধের কেবল সামান্য শতাংশ আপনাকে আয় দেয়, তাদের মধ্যেও পার্থক্য আছে। আপনার প্রচুর ডেটা হতে পারে, কিন্তু বাজেট তেমন নয়।

আমি এমন কিছু সেবায় কাজ করি যেগুলোতে দিনে ১ বিলিয়ন অনুরোধ আসে, তাই আমাদের নিজেদের মনিটরিং ও লগিং হোস্ট করা অর্থবহ। আপনার আয়তন কম হলে হোস্টেড সেবা সহজতর।

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 সমস্যায় পড়লে Kibana-তে ইন্টারঅ্যাকটিভ কাজ করতে চাওয়া ব্যবহারকারীরা যেভাবে প্রভাবিত হতেন, Kafka ওভারলোড হলে তারা সেভাবে প্রভাবিত হন না।

মন্তব্য: স্ট্রিম প্রক্রিয়াকরণ বেশিরভাগ ক্ষেত্রে অপব্যবহার খোঁজে, যেমন পুরো ক্লাস্টার জুড়ে একটিমাত্র IP থেকে অতিরিক্ত ট্রাফিক, এবং তারপর পুরো ক্লাস্টারে সেই অবরোধ শেয়ার করে।

মন্তব্য: logstash-output-kafka প্লাগইন অবশ্য এই মুহূর্তে বেশ অনির্ভরযোগ্য। এর GitHub ইস্যু পৃষ্ঠার বেশ কয়েকটি সমস্যায় আমি আক্রান্ত হয়েছি, যেগুলো কখনো ঠিক হয় না বলে মনে হয়। আমি এটি ব্যবহার থেকে সরে এসে আমাদের অ্যাপ থেকে সরাসরি Kafka-তে পাঠাতে চাই।

মন্তব্য: আমরা এখন অ্যাপ থেকে সরাসরি Kafka-তে কাঠামোবদ্ধ ইভেন্ট পাঠাচ্ছি। প্রধান প্রেরণা ছিল লগ ডেটা কম বার স্পর্শ করা এবং ডিস্ক একাধিকবার পড়া ও লেখা এড়ানো। উচ্চ-আয়তনের সিস্টেমে লগিংয়ে অ্যাপের চেয়েও বেশি কাজ লাগতে পারে। আমি journald-কেও একটি C প্রোগ্রাম থেকে সরাসরি লগ পাঠাতে দেওয়ার কথা ভাবছি।

Loki

Loki-র দিকে কাছ থেকে নজর রাখুন। এটি এখনও প্রস্তুত নয়, কিন্তু প্রস্তুত হলে আমি আশা করি এই স্ট্যাকে এটি আরও ভালো মানাবে। Loki হলো grafana labs-এর তৈরি একটি লগ অ্যাগ্রিগেটর, যা Prometheus-এর মতো একই ধরনের স্ক্র্যাপিং ও ট্যাগ সিনট্যাক্স ব্যবহার করে।

Prometheus + alertmanager + Rollbar + Graylog + Grafana

মেট্রিকের জন্য Prometheus + alertmanager। Prometheus আমার প্রিয়।

লগিং/ত্রুটি রিপোর্টিংয়ের জন্য Rollbar/Graylog (এখানে কিছু ওভারল্যাপ আছে; ছোট সেবায় সম্ভবত দুটিই লাগে না)।

বর্তমানে সতর্কবার্তাগুলো শুধু কয়েকটি Slack চ্যানেলের একটিতে যায়, যেখানে আগ্রহী পক্ষগুলো বিজ্ঞপ্তি চালু রেখেছে। আমরা অন-কল নিয়ে আরও গুরুতর হলে এগুলো PagerDuty/VictorOps/ইত্যাদিতে যেত।

গ্রাফ ও ড্যাশবোর্ডের জন্য Grafana। তাদের আসন্ন লগিং সুবিধা Graylog-কে অপ্রয়োজনীয় করে দেবে কি না তা দেখার জন্যও আগ্রহের সঙ্গে অপেক্ষা করছি।

Thanos

আমরা আমাদের HA সেটআপের ফ্রন্ট-এন্ড হিসেবে Thanos ব্যবহার করি। এটি জানে HA জোড়া থেকে কীভাবে পুনরাবৃত্তি বাদ দিতে হয়।

আমরা বর্তমানে ৬ মাসের স্থানীয় Prometheus ডেটা রাখছি। এটি আমাদের জন্য যুক্তিসঙ্গতভাবে ভালো কাজ করছে। কিন্তু আমি এখন আমাদের Thanos সেটআপে দীর্ঘমেয়াদি ডেটা সংরক্ষণের জন্য বাকেট স্টোরেজ চালু করার মাঝামাঝি আছি। তত্ত্বগতভাবে GCS স্টোরেজ আমরা এখন যে GCE স্ট্যান্ডার্ড পারসিস্টেন্ট ডিস্ক ব্যবহার করি তার চেয়ে প্রায় ৩০% সস্তা হবে।

আমরা এখন Prometheus ডেটার ব্যাকআপ নিই না। সতর্কবার্তার জন্য যথেষ্ট থাকা ছাড়া ডেটা আমাদের কাছে আসলে গুরুত্বপূর্ণ নয়। আমাদের সামগ্রিক ফ্লিট ডিপ্লয়মেন্ট বছর বছর এত বদলায় যে কয়েক মাসের চেয়ে পুরোনো ঐতিহাসিক ডেটা তেমন আকর্ষণীয় নয়। বছর-বছর কিছু মূল পরিসংখ্যান থাকা আকর্ষণীয় হতে পারে; আমি হয়তো একটি মূল-পরিসংখ্যান রেকর্ডিং নিয়ম সেট তৈরি করে ফেডারেশনের মাধ্যমে সেগুলো সংরক্ষণ করব, অথবা 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 ব্যবহার করা হয়।

এই সেটআপ আমাদের পরিবেশে কী ঘটছে সে সম্পর্কে আমাদের ব্যাপকভাবে অবহিত রাখতে অত্যন্ত কার্যকর হয়েছে। আমরা প্রায় ১১০টি মিশন-ক্রিটিক্যাল সার্ভার এবং প্রায় ৭৬০টি ডেটা পয়েন্ট চালাই ও পর্যবেক্ষণ করি, এবং সাত বছরেরও বেশি সময় ধরে এই সকালের ব্যবস্থা চালু রেখেছি।

আমি কোনো এক সময় Graylog বা ELK দিয়ে লগ একত্রিতও করতে চাই।

Prometheus + Grafana + AlertManager

চমৎকার Prometheus Operator helm chart-এর মাধ্যমে Prometheus + Grafana + AlertManager। লগ এখনও LogDNA birch পরিকল্পনায় যায়, কারণ আমরা লক্ষ্য করেছি GKE-তে আমাদের বিনীত ন্যূনতম ৩ সর্বোচ্চ ৫ নোডের জন্য 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 rules) নমনীয়তার কারণে ডেভেলপাররা কেবল সেই সেবাগুলোই দেখতে পান, যেগুলোর জন্য তাঁরা বিজ্ঞপ্তি পান।

এবং 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-এ সরে যাব।

দাবিত্যাগ: আমি একজন 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

ব্যাচ/cronjob-এর জন্য 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 ডেটাবেস যদি খারাপ অবস্থায় পড়ে (যা দুর্ভাগ্যবশত আমাদের ২-৩ মাস অন্তর ঘটে), আমরা HA নিয়ে মাথা ঘামাই না, বরং ডেটা ফেলে দিয়ে জীবনে এগিয়ে যাই। আপনার একান্ত HA বা দীর্ঘমেয়াদি ধারণ দরকার হলে, শুভকামনা।

Datadog + Prometheus + Grafana

আমি মাস-থেকে-মাস ভিত্তিতে Datadog সেট আপ করেছি, কারণ আমি যখন এখানে এলাম তখন কোনো পর্যবেক্ষণ ও সতর্কবার্তা ছিল না। আমাদের মাত্র কয়েকটি সাইট প্রাপ্যতার জন্য প্রতি ৫ মিনিটে পর্যবেক্ষণ করা হচ্ছিল। Datadog নিঃসন্দেহে সেট আপ করা সবচেয়ে সহজ। অন্য সব সমস্যা মেটানো শেষ হলে আমি Prometheus+Grafana-তে বদলাব। লগ ব্যবস্থাপনা নিয়ে এখনও ১০০% নিশ্চিত নই।

Nagios + ELK

আমরা ১০০+ পণ্য সমর্থন করি।

অন-প্রেম (on-prem) এর জন্য বেশিরভাগই Nagios ও ELK। ক্লাউডের জন্য আমরা DataDog থেকে NewRelic-এ স্থানান্তরিত হচ্ছি।

Datadog বনাম 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) অভ্যন্তরীণ রানবুক আছে।

Prometheus + AlertManager + Grafana + Stackdriver

আমাদের GKE ক্লাস্টার ও VM-এর মেট্রিকের জন্য Prometheus (Operator) / AlertManager / Grafana।

লগের জন্য Google Stackdriver (কারণ এটি অন্তর্ভুক্ত ও ডিফল্টভাবে সক্রিয় এবং বর্তমানে আমাদের প্রয়োজনের জন্য যথেষ্ট)।

Zabbix

সবকিছুর জন্য Zabbix। কোনো বাড়তি সফটওয়্যার লাগে না।