Alarm, Composite Alarm, Recovery আর Synthetics

এই লেসন শেষে তুমি পারবে

• CloudWatch alarm কী, বুঝিয়ে বলতে: একটা metric, একটা metric math expression বা একটা anomaly detection band-এর ওপর বসানো একটা নিয়ম, যার তিনটা state (OK, ALARM, INSUFFICIENT_DATA), আর প্রতিটা state বদলের সময় চলা action।
• Period, evaluation periods আর datapoints to alarm (M out of N) ঠিক করতে, missing data কীভাবে ধরা হবে বাছতে, আর কয়েকটা datapoint দেখে alarm-এর state কী হবে আগেই বলে দিতে।
• Static threshold alarm, anomaly detection alarm আর composite alarm-এর মধ্যে ঠিকটা বাছতে, আর composite rule ও action suppression দিয়ে alarm-এর হট্টগোল কমাতে।
• আজকের দিনে একটা alarm কী কী action নিতে পারে (SNS, Lambda, EC2 stop, terminate, reboot আর recover, Auto Scaling, Systems Manager-এর item আর incident, investigation) আর তার কোনগুলো composite alarm নিতে পারে, বলতে।
• System status check-এর ওপর recover action দিয়ে একটা একলা EC2 instance-কে বাঁচাতে, recovery কী রাখে আর কী হারায় বলতে, আর কখন simplified automatic recovery বা Auto Scaling group বেশি ভালো উত্তর, বুঝতে।
• CloudWatch Synthetics canary দিয়ে বাইরে থেকে একটা application পরীক্ষা করতে, Network Synthetic Monitor দিয়ে hybrid network-এর পথ মাপতে, আর Internet Monitor কোথায় বসে, জানতে।

#Alarm কেন: রাত ৩টায় কেউ graph দেখে না

লেসন ১৯.১-এ দেখেছি CloudWatch কীভাবে metric জোগাড় করে, আর লেসন ১৯.২-এ দেখেছি কীভাবে log রাখে। কিন্তু সমস্যা ধরতে যদি কাউকে dashboard-এর দিকে তাকিয়ে বসে থাকতে হয়, তাহলে রাত ৩টায় এর কোনোটাই কাজে আসে না। CloudWatch alarm হলো সেই অংশ, যে তোমার হয়ে নজর রাখে আর কোনো সংখ্যা গোলমাল করলে কিছু একটা করে: message পাঠায়, function চালায়, group বড় করে, বা instance সারিয়ে তোলে।

#সমস্যাটা কী

bKash-এর মতো একটা mobile wallet ঈদের আগের দিন সকাল ১০টায় বেতন দেয়। কয়েক মিনিটের মধ্যে লাখ লাখ মানুষ app খোলে। API-র সবচেয়ে ধীর এক শতাংশ request-এর সময় (p99 latency) যদি এক সেকেন্ড ছাড়িয়ে যায়, মানুষ বারবার চেষ্টা করতে থাকে, সেই বাড়তি চেষ্টা load আরও বাড়ায়, আর দশ মিনিটের মধ্যে app বসে যায়। Operations team-এর এটা জানা দরকার দ্বিতীয় মিনিটেই, দশম মিনিটে না; আবার প্রতিবার কোনো একটা মিনিট একটু ধীর হলেই তারা ঘুম থেকে উঠতে চায় না।

#Alarm জিনিসটা কী

CloudWatch alarm নজর রাখে একটা metric, একটা metric math expression (যেমন দুটো metric থেকে হিসাব করা error rate) বা একটা anomaly detection band-এর ওপর; প্রতিটা datapoint-কে একটা threshold-এর সাথে মেলায় আর একটা state ঠিক করে:

প্রতিবার state বদলালে alarm action চালাতে পারে: SNS topic-কে জানানো, Lambda function চালানো, EC2 instance থামানো বা recover করা, Auto Scaling group বড় করা, আরও অনেক কিছু (পুরো তালিকা নিচে)। প্রতিটা alarm regional: সে একটা Region-এ থাকে আর সেই Region-এর metric দেখে (লেসন ১৯.১-এর cross-account observability থাকলে একটা monitoring account তার source account-গুলোর metric-এর ওপরও alarm বসাতে পারে)।

#একটা alarm কীভাবে সিদ্ধান্ত নেয়

#Alarm কী কী দেখতে পারে

• একটা metric, সাথে একটা statistic: Average, Sum, Minimum, Maximum, SampleCount বা p99-এর মতো কোনো percentile (লেসন ১৯.১)। Dimension দিয়ে ঠিক কোন metric, সেটা বাছা হয়: একটা instance-এর CPU (InstanceId), বা পুরো একটা Auto Scaling group-এর (AutoScalingGroupName)।
• একটা metric math expression, যেটা কয়েকটা metric মিলিয়ে হিসাব করে, যেমন error rate-এর জন্য 100 * errors / requests; তাহলে দুটো কাঁচা সংখ্যার বদলে একটা alarm একটা অনুপাত দেখে।
• একটা metric বা expression-এর চারপাশে একটা anomaly detection band (নিচে “তিন রকম alarm” অংশে দেখো)।
• Metric filter দিয়ে log থেকে বানানো একটা metric (লেসন ১৯.২), যাতে log line থেকেও alarm বাজে।
• পাশের কথা: একটা alarm একটা Metrics Insights query-ও (SQL-এর মতো) চালাতে পারে, যেটা একসাথে অনেক resource ধরে, যেমন সব DynamoDB table, আর প্রতিটাকে আলাদা contributor হিসেবে দেখে; আর নতুন alarm mute rule নির্ধারিত maintenance-এর সময়টায় action চুপ করিয়ে রাখে। পরীক্ষার alarm সেই পুরোনো, একটা metric-এর ওপর বসানো alarm।

#Period, evaluation periods আর datapoints to alarm

তিনটা setting সংখ্যার একটা স্রোতকে একটা সিদ্ধান্তে বদলায়:

• Period: কত সেকেন্ডের সময়কে বাছাই করা statistic দিয়ে গুটিয়ে একটা datapoint বানানো হবে। সাধারণত ৬০ সেকেন্ড বা তার বেশি; high-resolution custom metric-এর জন্য ১০, ২০ বা ৩০ সেকেন্ড-ও চলে (high-resolution alarm-এর দাম বেশি)।
• Evaluation periods (N): সবচেয়ে সাম্প্রতিক কয়টা datapoint alarm দেখবে।
• Datapoints to alarm (M): সেই N-টার মধ্যে কয়টা সীমা পার হলে ALARM হবে। এগুলো পরপর হতে হবে না। M = N মানে “শেষ N-টার প্রতিটাই”; M যদি N-এর চেয়ে ছোট হয়, সেটা M out of N alarm, যে খারাপের সারিতে মাঝেমধ্যে একটা ভালো datapoint এলে তা সহ্য করে।

এক মিনিট বা তার বেশি period-এর alarm একটা sliding window ধরে প্রতি মিনিটে evaluate হয়; ১০, ২০ বা ৩০ সেকেন্ডের alarm evaluate হয় প্রতি ১০ সেকেন্ডে। N × period এক দিনের চেয়ে বেশি হলে alarm evaluate হয় ঘণ্টায় একবার।

Wallet-এর জন্য একটা হিসাব করে দেখি: period ৬০ সেকেন্ড, statistic p99, threshold ১ সেকেন্ডের বেশি, ৩টার মধ্যে ৩টা। Latency খারাপ হওয়ার পরে তৃতীয় খারাপ মিনিটটা লেখা হলে তবেই alarm ALARM-এ যেতে পারে, অর্থাৎ মোটামুটি তিন মিনিট পরে। ৫টার মধ্যে ৩টা দিলে latency ওঠানামা করলেও (খারাপ, ভালো, খারাপ, ভালো, খারাপ) alarm বাজবে, যেটা কড়া ৩টার মধ্যে ৩টা কখনো ধরত না। Period ৫ মিনিট আর ৩টায় ২টা হলে লাগবে ৫ মিনিটের দুটো খারাপ datapoint: কমপক্ষে ১০ মিনিট।

দুটো চলতি নিয়ম মনে রাখো:

• Metric যত সময় পরপর আসে, period তার চেয়ে ছোট হওয়া চলবে না। Basic monitoring-এ EC2 metric পাঠায় ৫ মিনিট পরপর; তখন ১ মিনিটের period-ওয়ালা alarm প্রতি পাঁচটা period-এর চারটাই খালি দেখে। হয় ৫ মিনিটের period দাও, নয়তো detailed monitoring চালু করো (১ মিনিটের, টাকা লাগে, লেসন ১৯.১)।
• Action চলে state বদলালে, সারাক্ষণ না। Alarm ALARM-এ ঢোকার সময় SNS message যায় একবার; সে লাল থাকলেও প্রতি মিনিটে আবার যায় না। একমাত্র ব্যতিক্রম: Auto Scaling-এর action alarm ALARM-এ থাকা পর্যন্ত বারবার চলে।

#Datapoint হারিয়ে গেলে

Datapoint হারায় যখন server বন্ধ হয়, agent crash করে, network link ভাঙে, অথবা স্রেফ এই কারণে যে কিছু metric শুধু কোনো ঘটনা ঘটলেই আসে (DynamoDB ThrottledRequests পাঠায় শুধু তখন, যখন কোনো request throttle হয়)। প্রতিটা alarm-এ বলে দিতে হয় হারানো datapoint-কে কী ধরা হবে:

CloudWatch এটা কীভাবে খাটায়: সে N-এর চেয়ে কয়েকটা বেশি datapoint আনে (একে বলে evaluation range)। অন্তত N-টা আসল datapoint পেলে সে সবচেয়ে সাম্প্রতিক N-টা আসল datapoint দিয়েই সিদ্ধান্ত নেয়, আর missing-data setting-এর দিকে তাকায়ই না। আসল datapoint N-এর কম হলে তবেই ফাঁকাগুলো তোমার setting দিয়ে ভরায়, তাও যতটা পারে কম। Documentation-এর দুটো বিশেষ কথা: DynamoDB metric-এর alarm default-এ missing data ignore করে; আর যে alarm EC2 instance stop, terminate, reboot বা recover করে, তার জন্য AWS missing রাখতে বলে (আর action শুধু ALARM-এ), যাতে খবর আসায় সামান্য ফাঁক পড়লে কোনো সুস্থ instance থেমে না যায়।

চেনা ফাঁদটা হলো: এমন একটা alarm, যার action শুধু ALARM-এ, আর যে metric দেখে সেটা আসা বন্ধ হয়ে গেছে। Default setting-এ alarm যায় INSUFFICIENT_DATA-তে, ALARM-এ না, আর কেউ কিছু জানতে পারে না। হয় missing data-কে breaching ধরো, নয়তো INSUFFICIENT_DATA-তেও একটা action দাও।

নিজে চালিয়ে দেখো: মিনিটগুলো, M, N আর missing-data treatment ঠিক করো, তারপর Evaluate চাপো।

#তিন রকম alarm

#Static threshold alarm

সাধারণ alarm (note-এ বলা হয়েছে standard alarm; AWS বলে metric alarm): একটা metric বা expression, একটা স্থির threshold, আর একটা তুলনা (বেশি, বেশি বা সমান, কম, কম বা সমান)। “CPU ৮০%-এর বেশি”, “p99 ১ সেকেন্ডের বেশি”, “free storage 10 GB-র কম”, “পাঁচ মিনিট ধরে queue-তে ১০,০০০-এর বেশি message”। সহজ আর আগে থেকে বোঝা যায়; কোন সংখ্যা মানে বিপদ, তা জানা থাকলে এটাই ঠিক।

#Anomaly detection alarm

কিছু metric-এর কোনো একটা নির্দিষ্ট “খারাপ” সংখ্যা নেই। মিনিট-প্রতি request রাতে কম, প্রতি সন্ধ্যায় বেশি, আর ঈদের বেতনের দিনে বিশাল। স্থির threshold হয় প্রতিটা স্বাভাবিক peak-এ বাজে (আর কিছুদিনেই কেউ পাত্তা দেয় না), নয়তো এত উঁচুতে বসানো হয় যে চুপচাপ ঘটে যাওয়া বিপদ ধরতেই পারে না।

Anomaly detection metric-এর ইতিহাসের ওপর machine learning খাটিয়ে প্রত্যাশিত মানের একটা band বানায়, যেটা ঘণ্টা, দিন আর সপ্তাহের নকশা মেনে চলে। যা জানতে হবে:

• ঠিকঠাক শিখতে model-এর দুই সপ্তাহ পর্যন্ত ডেটা লাগে (নতুন model-এর band মোটামুটি তিন ঘণ্টার মধ্যে দেখা যায়)।
• Anomaly detection alarm-এর threshold হলো band-এর চওড়া, standard deviation-এ মাপা (সাধারণত ২): সংখ্যা যত বড়, band তত চওড়া, alarm তত কম।
• Alarm বাজে metric band-এর ওপরে গেলে, নিচে গেলে, বা যেকোনো দিকে গেলে। “নিচে” দিয়ে সেই বিপদ ধরা যায় যেটা নীরবতার মতো দেখায়: login page ভাঙলে request কমে যায়।
• অস্বাভাবিক সময় (কোনো outage, কোনো ছুটি) training থেকে বাদ দেওয়া যায়, আর metric math expression-এর ওপরও এটা চলে।

#Composite alarm

Composite alarm metric দেখে না, দেখে অন্য alarm-গুলোর state। তার rule সেগুলোকে AND, OR আর NOT দিয়ে জোড়ে, function হিসেবে থাকে ALARM("name"), OK("name"), INSUFFICIENT_DATA("name"), আর দুটো ধ্রুবক TRUE ও FALSE:

ALARM("cpu-high") AND ALARM("disk-reads-high")
(ALARM("cpu-high") OR ALARM("disk-reads-high")) AND NOT ALARM("deploy-running")

• একটা rule-এ ১০০টা পর্যন্ত child alarm-এর নাম থাকতে পারে: metric alarm, বা অন্য composite alarm।
• কেন: alarm-এর হট্টগোল (alarm fatigue) কমাতে। Child-দের সাধারণত কোনো action থাকে না; খবর দেয় শুধু composite, তাই একটা আসল সমস্যায় একটাই ডাক যায়।
• Action suppression: একটা alarm-কে actions suppressor বানাও (যেমন এমন একটা alarm যেটা deployment বা maintenance-এর সময় ALARM-এ থাকে)। সে ALARM-এ থাকা পর্যন্ত composite-এর action আটকে থাকে; wait period আর extension period তাকে চালু হওয়ার আর পরে থিতু হওয়ার সময় দেয়।
• কী পারে: SNS-কে জানানো, Lambda চালানো, Systems Manager-এ একটা OpsItem বা incident বানানো, investigation শুরু করা। যা পারে না: EC2 action (stop, terminate, reboot, recover) বা Auto Scaling action; ওগুলো বসাও metric alarm-এ।
• Composite alarm INSUFFICIENT_DATA-তে থাকে শুধু তৈরি হওয়ার ঠিক পরপর।

#Alarm কী করতে পারে: action

প্রতিটা state-এর (OK, ALARM, INSUFFICIENT_DATA) নিজস্ব action-এর তালিকা থাকে, প্রতিটায় পাঁচটা পর্যন্ত; তাই একটা alarm ALARM-এ ডাক দিতে পারে আর OK-তে “ঠিক হয়ে গেছে” message পাঠাতে পারে। প্রতিটা state বদল একটা event হয়ে EventBridge-এও যায় (লেসন ১৯.৫), যেখানে একটা rule Step Functions চালাতে, কোনো API call করতে বা অন্য account-এ পাঠাতে পারে।

একটা CloudWatch alarm একটা Route 53 health check-এর ভিত্তিও হতে পারে; private resource এভাবেই DNS failover-এ অংশ নেয় (লেসন ৮.৪)।

#Log ডেটার ওপর alarm

Alarm log-এর লেখা পড়তে পারে না। Note-এর এই শিকলটা পরীক্ষায় খুব আসে:

Log group → metric filter → CloudWatch metric → CloudWatch alarm → SNS

Metric filter (লেসন ১৯.২) প্রতিটা মিলে যাওয়া line-কে (ধরো PAYMENT_FAILED) একটা গণনায় বদলায়; alarm সেই গণনাকে অন্য যেকোনো metric-এর মতোই দেখে। মনে রাখো, metric filter শুধু তৈরি হওয়ার পরে আসা event গোনে, তাই এর ওপর বসানো alarm আগের ব্যর্থতা কখনো দেখে না। এমন শুধু-error-এ-আসা metric-এ missing data-কে notBreaching ধরাই সাধারণত ঠিক।

#set-alarm-state দিয়ে alarm পরীক্ষা

Production না ভেঙে কীভাবে প্রমাণ করবে যে pager কাজ করে? State জোর করে বসিয়ে দাও:

aws cloudwatch set-alarm-state --alarm-name wallet-p99-high \
  --state-value ALARM --state-reason "testing the on-call SMS"

Alarm ALARM-এ যায় আর ঠিক আসল বিপদের মতোই ALARM-এর action চালায়; পরের evaluation-এ তার আসল ডেটা যে state বলে, সেখানে ফিরে যায়। বড় দিনের আগে SNS subscription, Lambda-র permission আর runbook পরীক্ষা করতে এটা ব্যবহার করো।

#EC2 Instance recovery

#তিনটা status check

EC2 প্রতি মিনিটে স্বয়ংক্রিয় status check চালায় আর ফল CloudWatch metric হিসেবে পাঠায় (মান 0 = পাশ, 1 = ফেল):

StatusCheckFailed (কোনো লেজ ছাড়া) যেকোনো একটা check ফেল করলেই 1 হয়। Status check machine পরীক্ষা করে, তোমার application না: OS সুস্থ কিন্তু web server crash করেছে, এমন instance দুটো check-ই পাশ করে (এটা ধরার জন্যই load balancer-এর health check)।

#Recover action

StatusCheckFailed_System-এর ওপর একটা alarm বানাও (ধরো ২ মিনিটের ২টাতেই maximum ≥ 1), action দাও EC2 recover, সাধারণত সাথে একটা SNS notification। Host নষ্ট হলে EC2 instance-টাকে সুস্থ hardware-এ সরিয়ে নেয়। Operating system-এর কাছে এটা একটা অপ্রত্যাশিত reboot-এর মতো লাগে।

Recover হওয়া instance আগেরটার হুবহু এক, শুধু অস্থায়ী জায়গায় যা ছিল তা বাদে:

শর্ত আর সীমা (এগুলো বদলায়, তাই চলতি তালিকা দেখে নিও): শুধু সমর্থিত instance type (বেশিরভাগ চলতি general purpose, compute আর memory optimised family, metal size-সহ), shared বা Dedicated Instance tenancy, আর instance চলমান থাকতে হবে। সমর্থিত না: Auto Scaling group-এর instance, Dedicated Host-এর instance (ওদের নিজস্ব host recovery আছে), Elastic Fabric Adapter-ওয়ালা instance, বা scheduled maintenance event চলছে এমন instance। Launch-এর সময় instance store volume লাগানো থাকলে মাত্র কয়েকটা পুরোনো family সমর্থিত, আর তাদের ডেটা তো হারাবেই। বাড়তি capacity না থাকলে বা AWS-এর বড় কোনো ঘটনার সময় recovery ব্যর্থও হতে পারে; তখন instance নিজে stop আর start করো (stop আর start-এ Elastic IP থাকে, কিন্তু public IPv4 address নতুন হয়)।

Instance status check ফেল করলে recovery কোনো কাজে আসে না: নষ্ট operating system নতুন hardware-এ নিলেও নষ্টই থাকে। এর জন্য StatusCheckFailed_Instance-এর ওপর দ্বিতীয় একটা alarm দাও, action reboot।

#Simplified automatic recovery

২০২২ থেকে সমর্থিত instance-এ simplified automatic recovery default-এ চালু: system status check ফেল করলে EC2 কোনো alarm ছাড়াই একই রকম সরানোর চেষ্টা করে, বাড়তি খরচ ছাড়া, আর AWS Health Dashboard-এ একটা event দেয়। তবুও CloudWatch recover action-এর কিছু সুবিধা আছে: আরও দ্রুত, মিনিটের হিসাবে সাড়া, তোমার নিজের SNS notification, আর metal size ও কিছু instance store type-এ সমর্থন। প্রতি instance-এ simplified recovery বন্ধও করা যায়।

পরীক্ষায় “নিচের hardware নষ্ট হলে নিজে নিজে recover করো আর IP address একই রাখো” প্রশ্নের উত্তর এখনো StatusCheckFailed_System-এর ওপর CloudWatch alarm, সাথে EC2 recover action। Load balancer-এর পেছনে একটা fleet হলে ভালো নকশা হলো Auto Scaling group, যেটা অসুস্থ instance recover না করে বদলে নেয় (নতুন ID, নতুন IP)।

#Synthetic monitoring: গ্রাহকের আগে গোলমাল খুঁজে বের করো

Metric আর log বলে আসল traffic কী করেছে। রাত ৩টায় হয়তো কোনো আসল traffic-ই নেই, তাই প্রথম গ্রাহক ধাক্কা না খাওয়া পর্যন্ত ভাঙা payment page-এর খবর কিছুই দেয় না। Synthetic monitoring traffic-টা নিজেই বানায়।

#CloudWatch Synthetics canary

Canary হলো একটা configure-করা script, যেটা একটা schedule ধরে চলে আর গ্রাহকের মতোই একই পথে একই কাজ করে: home page খোলা, login, cart-এ যোগ, টাকা দেওয়া। নামটা এসেছে কয়লাখনির শ্রমিকদের কাছ থেকে, যারা আগাম সতর্ক হওয়ার জন্য সাথে canary পাখি নিয়ে নামত।

• ভাষা আর runtime: Puppeteer বা Playwright-সহ Node.js, Selenium-সহ Python (headless Chrome, কিছু runtime-এ Firefox-ও), আর browser ছাড়া check-এর জন্য Java। প্রতিটা canary তোমার account-এ একটা Lambda function হিসেবে চলে, একটা Synthetics layer নিয়ে।
• Schedule: একবার চালাও, অথবা rate বা cron schedule-এ, সর্বোচ্চ প্রতি মিনিটে একবার, দিনরাত (note-এর “২০/৭” আসলে টাইপো, হবে ২৪/৭)।
• Blueprint: heartbeat (একটা URL খোলে, screenshot আর একটা HTTP archive file রাখে), API canary (header আর body-সহ REST call, API Gateway-এর সাথে জোড়া), broken link checker (page-এর link-গুলোতে গিয়ে 404 আর timeout জানায়), visual monitoring (screenshot-কে একটা baseline-এর সাথে মেলায়, পার্থক্য threshold-এর বেশি হলে ফেল), canary recorder (একটা Chrome extension, যেটা তোমার click রেকর্ড করে script বানায়), GUI workflow builder (click, type, লেখা যাচাই), আর multi checks (একটা JSON configuration থেকে ১০টা পর্যন্ত HTTP, DNS, SSL আর TCP check)।
• ফলাফল: screenshot, HTTP archive file আর log যায় একটা S3 bucket-এ; SuccessPercent আর Duration-এর মতো metric যায় CloudWatch-এ (namespace CloudWatchSynthetics, dimension CanaryName, আর ধাপের জন্য StepName), তাই canary metric-এর ওপর alarm team-কে ডাকে।
• Private endpoint: ভেতরের page পরীক্ষা করতে canary VPC-র ভেতরে চলতে পারে; তখন S3 আর CloudWatch পর্যন্ত পৌঁছাতে NAT gateway বা VPC endpoint লাগে।
• এটা প্রতিটা ধাপের latency-ও দেখে, আর অপ্রত্যাশিত কোনো বদল (যেমন page-এ কেউ script ঢুকিয়ে দিলে) ধরতে পারে।

#Network Synthetic Monitor

Network Synthetic Monitor (চালু হয়েছিল CloudWatch Network Monitor নামে; note-এ পুরোনো নামটাই আছে) মাপে তোমার AWS workload আর on-premises network-এর মাঝের পথ, Direct Connect বা Site-to-Site VPN দিয়ে (লেসন ২২.৪ আর ২২.৫)। দুটোই “synthetic” হলেও এটা Synthetics canary থেকে আলাদা একটা feature।

• তুমি একটা source বাছো (তোমার VPC-র একটা subnet) আর destination (on-premises IP address, protocol, port, packet-এর মাপ)। Probe AWS নিজেই বানায় আর সামলায়: VPC-তেও কোনো agent নেই, on-premises-এও না।
• Probe ব্যবহার করে ICMP (echo request আর reply) বা TCP (একটা port-এ SYN আর SYN-ACK)। IPv4 আর IPv6 দুই ধরনের destination-ই চলে, তবে আলাদা monitor-এ (slide-এর “IPv4/IPv4” মানে আসলে IPv4/IPv6)।
• এটা round-trip time আর packet loss প্রতি ৩০ বা ৬০ সেকেন্ডে (aggregation interval) CloudWatch-এ পাঠায়, তাই graph আঁকা যায়, static বা anomaly detection alarm বসানো যায়, আর কয়েক মিনিটের মধ্যে অবনতি চোখে পড়ে।
• Network health indicator metric (0 বা 100) বলে দেয় অবনতিটা পথের AWS-এর নিয়ন্ত্রণে থাকা অংশে কি না (Direct Connect location পর্যন্ত, বা Region থেকে Region-এর পথ)। 0 মানে নিজের দিক বা নিজের provider দেখো; 100 মানে AWS।
• এটা traffic failover করে না; সেটা করে routing (BGP, একটা backup VPN)। প্রতিটা probe-এর জন্য টাকা লাগে।

#কোথায় কোথায় গোলমাল হয়

• মরা metric-এ চুপ থাকা alarm: metric আসা বন্ধ, alarm যায় INSUFFICIENT_DATA-তে, আর তার action শুধু ALARM-এ। Heartbeat-এ missing data-কে breaching ধরো, বা INSUFFICIENT_DATA-তে একটা action দাও।
• শুধু-error-এ-আসা metric-এ লাফালাফি করা alarm: throttle বা error শুধু ঘটনা ঘটলেই আসে, তাই দুই ঘটনার মাঝে alarm INSUFFICIENT_DATA-তে লাফায়। Missing data-কে notBreaching ধরো।
• Metric-এর interval-এর চেয়ে ছোট period: EC2 basic monitoring-এর (৫ মিনিটের ডেটা) ওপর ১ মিনিটের alarm। ৫ মিনিটের period দাও, বা detailed monitoring চালু করো।
• অতিরিক্ত সংবেদনশীল: হট্টগোলে ভরা metric-এ ১টার মধ্যে ১টা দিলে প্রতিটা ছোট ঝাঁকুনিতে মানুষকে ডাকা হয়; একসময় সবাই উপেক্ষা করতে শেখে। M out of N, লম্বা period, percentile বা anomaly detection ব্যবহার করো।
• অতিরিক্ত ধীর: ৫ মিনিটের period আর ৫টায় ৫টা দিলে বাজতে ২৫ মিনিট লাগে। কত তাড়াতাড়ি সাড়া দিতে হবে, N × period সেই মাপে রাখো।
• Alarm-এর ঝড়: একটা মূল কারণে ৩০টা alarm লাল। Composite alarm ব্যবহার করো, আর deployment-এর সময় action চেপে রাখো।
• SNS subscription কখনো confirm হয়নি: email subscription confirm করতে হয়, তাই alarm বাজলেও কেউ পায় না। set-alarm-state দিয়ে পরীক্ষা করো।
• Lambda action ব্যর্থ: function-এ এমন কোনো resource-based policy নেই, যেটা CloudWatch alarm-কে তাকে চালানোর অনুমতি দেয়।
• Recover action দেখা যায় না বা কাজ করে না: alarm কোনো নির্দিষ্ট instance-এর EC2 metric-এর ওপর না, instance type সমর্থিত না, instance একটা Auto Scaling group-এ, বা capacity কম। Fleet-এর জন্য উত্তর হলো ASG-র নিজস্ব health check।
• Recover দিয়ে আটকে যাওয়া OS সারানোর আশা: recovery সাড়া দেয় শুধু system status check-এ; instance status check-এর ওপর reboot action দাও।
• ঘটনার পরে বানানো metric filter: সে শুধু নতুন log event গোনে, তাই যে error খুঁজছ তার জন্য alarm কিছুই দেখায় না।
• ভুল কারণে canary ফেল: NAT বা VPC endpoint ছাড়া private subnet-এ, বা test account-এর password-এর মেয়াদ শেষ; site ঠিক থাকলেও alarm বাজে।
• Composite rule কখনো সত্য হয় না: কোনো child alarm-এর নাম বদলানো বা মোছা হয়েছে, বা দুটো composite একে অন্যকে ঘুরে ঘুরে ধরে আছে, যাতে দুটোর evaluation-ই থেমে যায় (একটার rule FALSE করে চক্রটা ভাঙো)।

#System design-এ alarm

• ব্যবহারকারী আগে যা টের পায়, তার ওপর alarm দাও: p99 latency, error rate (metric math), canary-র সফলতা, queue-র বয়স। Resource alarm (CPU, memory) এদের সাহায্য করে, কিন্তু একা একা খুব কমই কাউকে ডাকা উচিত।
• প্রতিটা alarm-এর সাথে একটা action আর একটা runbook: alarm-এর description-এ runbook-এর link রাখা যায়; একটা OpsItem বা Lambda function প্রথম ধাপগুলো নিজে নিজে শুরু করে দিতে পারে।
• নিজে নিজে সেরে ওঠা: alarm → Auto Scaling policy (capacity), alarm → EC2 reboot বা recover (একলা instance), alarm → Lambda বা EventBridge → Systems Manager Automation (একটা service restart, disk পরিষ্কার)।
• একটা আসল সমস্যায় একটাই ডাক: action ছাড়া অনেক metric alarm, প্রতি service-এ action-ওয়ালা composite alarm, deployment-এর সময় suppression।
• Hybrid আর বাইরে থেকে দেখা: গ্রাহকের পথ আর public API-র জন্য canary, Direct Connect আর VPN-এর পথের জন্য Network Synthetic Monitor, DNS failover-এর জন্য Route 53 health check।
• এক জায়গায় সব: cross-account observability (লেসন ১৯.১) থাকলে একটা monitoring account সব workload account-এর alarm ধরে রাখে।

#নিজে করে দেখো

এই command-গুলো ap-southeast-1-এ AWS CLI v2 দিয়ে চলে। Alarm, canary আর probe-এর মাসে অল্প কিছু খরচ আছে; কাজ শেষে মুছে দিও।

# 1. An SNS topic for the on-call team (confirm the email subscription in your inbox)
aws sns create-topic --name oncall-alerts
aws sns subscribe --topic-arn arn:aws:sns:ap-southeast-1:111122223333:oncall-alerts \
  --protocol email --notification-endpoint oncall@example.com

# 2. A static threshold alarm: p99 latency of an ALB above 1 s for 3 of 5 minutes
aws cloudwatch put-metric-alarm --alarm-name wallet-p99-high \
  --namespace AWS/ApplicationELB --metric-name TargetResponseTime \
  --dimensions Name=LoadBalancer,Value=app/wallet-alb/50dc6c495c0c9188 \
  --extended-statistic p99 --period 60 --evaluation-periods 5 --datapoints-to-alarm 3 \
  --threshold 1 --comparison-operator GreaterThanThreshold \
  --treat-missing-data notBreaching \
  --alarm-actions arn:aws:sns:ap-southeast-1:111122223333:oncall-alerts \
  --ok-actions arn:aws:sns:ap-southeast-1:111122223333:oncall-alerts

# 3. Recover an instance when the host fails, and reboot it when the OS hangs
aws cloudwatch put-metric-alarm --alarm-name results-recover \
  --namespace AWS/EC2 --metric-name StatusCheckFailed_System \
  --dimensions Name=InstanceId,Value=i-0a1b2c3d4e5f60718 \
  --statistic Maximum --period 60 --evaluation-periods 2 \
  --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:automate:ap-southeast-1:ec2:recover \
                  arn:aws:sns:ap-southeast-1:111122223333:oncall-alerts
aws cloudwatch put-metric-alarm --alarm-name results-reboot \
  --namespace AWS/EC2 --metric-name StatusCheckFailed_Instance \
  --dimensions Name=InstanceId,Value=i-0a1b2c3d4e5f60718 \
  --statistic Maximum --period 60 --evaluation-periods 3 \
  --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:automate:ap-southeast-1:ec2:reboot

# 4. A composite alarm that stays quiet during deployments
aws cloudwatch put-composite-alarm --alarm-name orders-really-broken \
  --alarm-rule 'ALARM("orders-cpu-high") AND ALARM("orders-disk-reads-high")' \
  --actions-suppressor deploy-running \
  --actions-suppressor-wait-period 120 --actions-suppressor-extension-period 300 \
  --alarm-actions arn:aws:sns:ap-southeast-1:111122223333:oncall-alerts

# 5. Test the notification path, then read what happened
aws cloudwatch set-alarm-state --alarm-name wallet-p99-high \
  --state-value ALARM --state-reason "testing the on-call SMS"
aws cloudwatch describe-alarm-history --alarm-name wallet-p99-high \
  --history-item-type StateUpdate --max-items 2 \
  --query 'AlarmHistoryItems[].[Timestamp,HistorySummary]' --output text
# 2026-11-01T04:12:31.204Z  Alarm updated from ALARM to OK
# 2026-11-01T04:11:58.871Z  Alarm updated from OK to ALARM

# 6. Let an alarm invoke Lambda directly (the function needs this permission)
aws lambda add-permission --function-name post-to-chat --statement-id cw-alarms \
  --action lambda:InvokeFunction --principal lambda.alarms.cloudwatch.amazonaws.com \
  --source-arn arn:aws:cloudwatch:ap-southeast-1:111122223333:alarm:wallet-p99-high

# 7. A heartbeat canary every minute (script zipped in S3, results to another bucket)
aws synthetics create-canary --name shop-checkout \
  --code S3Bucket=canary-code-example,S3Key=checkout.zip,Handler=checkout.handler \
  --artifact-s3-location s3://canary-results-example/shop-checkout/ \
  --execution-role-arn arn:aws:iam::111122223333:role/CanaryRole \
  --schedule Expression="rate(1 minute)" \
  --runtime-version syn-nodejs-puppeteer-9.1
aws synthetics start-canary --name shop-checkout

Console-এও করে দেখো: Alarms → Create alarm খোলো, একটা metric বাছো, Anomaly detection বেছে preview-এর band দেখো; তারপর দুটো alarm বেছে Create composite alarm চাপো। Application Signals → Synthetics canaries-এ Heartbeat monitoring blueprint থেকে একটা canary বানাও, আর তার প্রথম কয়েকটা run-এর screenshot দেখো।

#সারসংক্ষেপ

মূল কথাগুলো

• CloudWatch alarm দেখে একটা metric, একটা metric math expression বা একটা anomaly detection band। State: OK, ALARM, INSUFFICIENT_DATA। Action চলে state বদলালে (শুধু Auto Scaling-এর action বারবার চলে)।
• Period (৬০ সেকেন্ড বা বেশি; high-resolution metric-এ ১০, ২০ বা ৩০ সেকেন্ড), evaluation periods (N) আর datapoints to alarm (M): M out of N হট্টগোল সহ্য করে আর ওঠানামাও ধরে। Period metric-এর interval-এর চেয়ে ছোট হবে না (EC2 basic monitoring = ৫ মিনিট)।
• Missing data: missing (default, সব ফাঁকা → INSUFFICIENT_DATA), notBreaching (শুধু error-এ আসা metric), breaching (heartbeat), ignore (state ধরে রাখো)। কাজে লাগে শুধু তখন, যখন আসল datapoint N-এর কম।
• জানা সীমার জন্য static threshold, দিন আর সপ্তাহের নকশাওয়ালা metric-এর জন্য anomaly detection, alarm-এর হট্টগোল কমাতে composite alarm (অন্য alarm-এর ওপর AND, OR, NOT, ১০০টা পর্যন্ত child, actions suppressor)। Composite EC2 বা Auto Scaling-এর action নিতে পারে না।
• Action: SNS (তারপর যা খুশি), Lambda, EC2 stop / terminate / reboot / recover, Auto Scaling policy, Systems Manager-এর Ops Center item আর incident, investigation। প্রতিটা state বদল একটা EventBridge event-ও। পরীক্ষা করো set-alarm-state দিয়ে।
• Log-এর লেখায় alert-এর জন্য log → metric filter → metric → alarm → SNS।
• EC2 recovery: StatusCheckFailed_System-এর ওপর alarm + recover → একই instance ID, private / public / Elastic IP, metadata, placement group, EBS; RAM আর instance store হারায়। Instance status check ফেল → reboot। Auto Scaling group-এর instance-এ চলে না। Simplified automatic recovery default-এ চালু, কিন্তু পরীক্ষার উত্তর alarm।
• Synthetics canary: schedule ধরে চলা script (Node.js, Python, Java), সর্বোচ্চ প্রতি মিনিটে, ২৪/৭; UI flow, API, link আর চেহারার বদল পরীক্ষা করে, ফল রাখে S3-এ, metric দেয় alarm-এর জন্য।
• Network Synthetic Monitor: VPC subnet থেকে Direct Connect বা VPN দিয়ে on-premises IP পর্যন্ত agent ছাড়া probe, round-trip time আর packet loss, network health indicator। Internet Monitor দেখে end user পর্যন্ত internet-এর পথ।

নিজেকে যাচাই করো: CloudWatch alarm৩০টি প্রশ্ন