CloudWatch Metric আর Metric Stream

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

• এই অধ্যায়ের পরীক্ষার মূল সুরে CloudWatch, CloudTrail, Config আর EventBridge-কে যার যার জায়গায় বসাতে, আর কোনটা কোন প্রশ্নের উত্তর দেয় বলতে।
• একটা CloudWatch metric পড়তে: namespace, metric-এর নাম, dimension, timestamp, unit, আর একটা period ধরে হিসাব করা statistic (Average, Sum, Minimum, Maximum, SampleCount, p99-এর মতো percentile)।
• EC2-এর basic monitoring (৫ মিনিট, ফ্রি) আর detailed monitoring (১ মিনিট, টাকা লাগে)-এর পার্থক্য বোঝাতে; memory আর disk-এর ব্যবহৃত জায়গা কেন নেই, আর কীভাবে আনতে হয়, বলতে।
• PutMetricData দিয়ে custom metric পাঠাতে, standard resolution (১ মিনিট) বা high resolution (১ সেকেন্ড পর্যন্ত)-এ, আর namespace, dimension আর timestamp-এর নিয়ম জানতে।
• Retention-এর ধাপগুলো ঠিকঠাক বলতে (৬০ সেকেন্ডের কম ৩ ঘণ্টা, ১ মিনিট ১৫ দিন, ৫ মিনিট ৬৩ দিন, ১ ঘণ্টা ৪৫৫ দিন), আর একটা নির্দিষ্ট বয়সের ডেটায় কতটা খুঁটিনাটি বাকি থাকে আগে থেকে বলতে।
• Dashboard, metric math, anomaly detection আর cross-account observability ব্যবহার করতে, আর GetMetricData বারবার poll না করে Amazon Data Firehose দিয়ে Metric Stream-এ metric বাইরে পাঠাতে।

#Metric কেন: সিস্টেম এই মুহূর্তে ভালো আছে তো?

অধ্যায় ১৯ চারটা service নিয়ে, যারা তোমার AWS account-এর ওপর নজর রাখে। পরীক্ষায় এগুলো কীভাবে configure করতে হয়, তা খুব কমই জিজ্ঞেস করে; জিজ্ঞেস করে scenario-র শব্দ পড়ে ঠিক service-টা বেছে নিতে:

চারটার পাশাপাশি পুরো তুলনা আছে লেসন ১৯.৭-এ। এই লেসন শুরু হচ্ছে CloudWatch-এর সেই অংশ দিয়ে, যার ওপর বাকি সব দাঁড়িয়ে: metric। Log হলো লেসন ১৯.২, alarm ১৯.৩, আর Insights-এর ফিচারগুলো ১৯.৪।

#সমস্যাটা কী

bKash-এর মতো একটা mobile wallet ঈদের আগের দিন বেতন পাঠায়। রাত ৮টায় মিনিটে transfer ৩০০ থেকে লাফিয়ে ৬,০০০ হয়ে যায়। On-call engineer-এর উত্তর লাগবে কয়েক সেকেন্ডে, হাজারটা log line পড়ার পরে না: API server-এর CPU কি বেশি? Transfer কি ধীর হয়ে যাচ্ছে? সবচেয়ে ধীর transfer-গুলো কতটা ধীর? গত ঈদের চেয়ে খারাপ কি না?

প্রতিটা প্রশ্নই আসলে সময়ের সাথে বদলানো একটা সংখ্যা। এমন সংখ্যা নিয়মিত তালে জোগাড় করো, জমিয়ে রাখো, graph-এ আঁকো, তুলনা করো, আর একটা সীমা পেরোলে alarm বাজাও: এটাই monitoring। AWS-এ এর নাম CloudWatch Metrics।

#Metric জিনিসটা কী

একটা metric হলো একটা জিনিস নিয়ে সময়ের ক্রমে সাজানো কতগুলো data point: একটা EC2 instance-এর CPU-র ব্যবহার, একটা S3 bucket-এর আকার, একটা SQS queue-তে কয়টা message। একে নজরে রাখার মতো একটা চলক ভাবো, আর প্রতিটা data point হলো কোনো এক মুহূর্তে তার মান।

• AWS service-গুলো তোমার হয়ে metric পাঠায়, বিনা পয়সায়, প্রায় সব resource-এর জন্য: EC2, EBS, RDS, ELB, Lambda, DynamoDB, SQS, S3, আরও অনেক। চালু করতে তোমার কিছু করতে হয় না।
• নিজের metric-ও পাঠাতে পারো (custom metric): মিনিটে কতগুলো order, payment-এর latency, কতজন user সক্রিয়, কতটা memory ব্যবহার হচ্ছে।
• Metric regional: যে Region-এ তৈরি হয়েছে, metric সেখানেই থাকে।
• Metric delete করা যায় না। ১৫ মাস ধরে নতুন ডেটা না এলে নিজে থেকেই মেয়াদ শেষ হয়ে যায়।

#একটা metric-এর গঠন

#Namespace, নাম আর dimension: পরিচয়

Namespace + metric-এর নাম + dimension, তিনটা মিলেই একটা metric। Dimension-এর মানের প্রতিটা আলাদা জোড়া একটা আলাদা metric, নাম এক হলেও। Service=transfer, Env=prod-ওয়ালা Latency আর Service=transfer, Env=staging-ওয়ালা Latency দুটো আলাদা metric। তুমি শুধু সেই জোড়াগুলোই ফেরত পড়তে পারবে, যেগুলো আসলে পাঠিয়েছ; custom metric-এর বেলায় CloudWatch নিজে থেকে dimension পেরিয়ে যোগ করে দেয় না (AWS/EC2-এর মতো কিছু AWS namespace-এ অবশ্য আগে থেকে জোড়া দেওয়া রূপ থাকে, যেমন সব instance মিলিয়ে, বা Auto Scaling group ধরে)। একসাথে অনেক metric আনতে চাইলে metric math-এর SEARCH expression ব্যবহার করো।

#Timestamp, মান আর unit: data point

• Timestamp: মানটা কখন মাপা হয়েছে, পারলে UTC-তে। না দিলে CloudWatch যে সময়ে point-টা পেল সেই সময় বসিয়ে দেয়। একটা custom data point-এর timestamp হতে পারে দুই সপ্তাহ আগে পর্যন্ত আর দুই ঘণ্টা পরে পর্যন্ত; এর বাইরে হলে বাতিল।
• মান: একটা সংখ্যা (লেখা না, সংখ্যা-নয় এমন মান বা অসীমও না)।
• Unit: Percent, Count, Bytes, Seconds, Milliseconds, Count/Second ইত্যাদি। না দিলেও চলে (তখন None), কিন্তু আলাদা unit-এর point আলাদা করে হিসাব হয়, তাই একটাই unit রাখো।

#Statistic আর period: কীভাবে পড়ো

কাঁচা point তুমি খুব কমই পড়ো। তুমি চাও একটা period ধরে একটা statistic:

• Period: প্রতিটা সময়ের ঝুড়ির দৈর্ঘ্য, সেকেন্ডে: ১, ৫, ১০, ৩০, বা ৬০-এর যেকোনো গুণিতক। Default ৬০। ১ মিনিটের কম period শুধু high-resolution metric-এর বেলায় অর্থবহ।
• Statistic: SampleCount (কয়টা point), Sum, Average (Sum ভাগ SampleCount), Minimum, Maximum, আর p50, p90, p99-এর মতো percentile (p99 মানে এমন একটা মান, যার নিচে ৯৯% point থাকে)। CloudWatch trimmed mean আর এ রকম আরও কিছু statistic দেয়, যেগুলো দুই প্রান্তের চরম মান বাদ দিয়ে হিসাব করে।

Percentile কেন জরুরি: রাত ৮টা ৫-এ wallet-এর গড় transfer latency 180 ms, দেখতে শান্ত; কিন্তু p99 হলো 2.4 সেকেন্ড: প্রতি ১০০ জন customer-এর একজন দুই সেকেন্ডের বেশি অপেক্ষা করছে, আর ঈদের রাতে সেটা হাজার হাজার মানুষ। Average ধীর লেজটা লুকিয়ে ফেলে; percentile সেটা দেখায়। Percentile-এর জন্য কাঁচা মান লাগে (অথবা Values আর Counts array); শুধু আগে থেকে সংক্ষেপ করা একটা statistic set (Sum, SampleCount, Minimum, Maximum) পাঠালে তার percentile পাওয়া যায় না।

#Metric আসে কোথা থেকে

#AWS service-এর metric, আর EC2-এর basic বনাম detailed monitoring

বেশিরভাগ AWS service নিজের metric পাঠায় প্রতি মিনিটে, বিনা পয়সায়। EC2 হলো চেনা ব্যতিক্রম:

পরীক্ষায় দুটো ফল খুব আসে। যে Auto Scaling group-কে এক-দুই মিনিটের মধ্যে সাড়া দিতে হবে, তার detailed monitoring লাগবে, কারণ ৫ মিনিটের metric প্রতিটা সিদ্ধান্তকে দেরি করিয়ে দেয় (লেসন ৬.৫)। আর basic monitoring-এর metric-এর ওপর ৬০ সেকেন্ডের period-এর alarm-এর হাতে প্রতি পাঁচ মিনিটের চার মিনিটই কিছু মাপার থাকে না; period কমপক্ষে ৩০০ সেকেন্ড রাখো, নয়তো detailed monitoring চালু করো (alarm হলো লেসন ১৯.৩)।

#EC2 যা দেখতে পায় না: memory আর disk-এর জায়গা

EC2-এর ফ্রি metric মাপে hypervisor, তোমার operating system-এর বাইরে থেকে:

• থাকে: CPUUtilization; NetworkIn, NetworkOut, NetworkPacketsIn, NetworkPacketsOut; DiskReadOps, DiskWriteOps, DiskReadBytes, DiskWriteBytes (instance store volume-এর জন্য); status check (StatusCheckFailed, StatusCheckFailed_System, StatusCheckFailed_Instance, StatusCheckFailed_AttachedEBS); burstable T instance-এর CPU credit-এর metric; আর Nitro-ভিত্তিক instance-এ EBS volume-এর metric।
• থাকে না: memory (RAM) কতটা ব্যবহার হচ্ছে, swap, file system-এ disk-এর কতটা জায়গা ভরা বা ফাঁকা, কয়টা process চলছে, application-এর ভেতরের সংখ্যা। এগুলো guest OS-এর ভেতরে, যেখানে hypervisor তাকাতে পারে না।

এগুলো পেতে হলে instance-এর ভেতরে এমন কিছু চালাতে হবে যেটা এগুলোকে custom metric হিসেবে পাঠাবে: unified CloudWatch agent (memory, disk, swap, netstat, process ধরে metric, সাথে log file-ও; Linux আর Windows-এ, EC2 আর on-premises দুই জায়গাতেই; বিস্তারিত লেসন ১৯.২-এ), অথবা তোমার নিজের একটা script, যেটা PutMetricData call করে। Notes-এ একে বলা হয়েছে “custom agent”; আসল product-এর নাম CloudWatch agent।

#PutMetricData দিয়ে custom metric

নিজের সংখ্যা পাঠানো হয় PutMetricData API দিয়ে (CLI, যেকোনো SDK, CloudWatch agent, বা অন্য tool থেকে):

• প্রথম data point-ই metric তৈরি করে। আগে থেকে কিছু বানাতে হয় না। নতুন একটা metric list-metrics-এ দেখা দিতে ১৫ মিনিট পর্যন্ত লাগতে পারে।
• Namespace: যা খুশি নাম, ২৫৫ অক্ষর পর্যন্ত, তবে AWS/ দিয়ে শুরু কোরো না (ওই prefix AWS service-গুলোর)।
• Standard resolution (default): ১ মিনিটের দানা। High resolution: StorageResolution-কে 1 করো, তাহলে CloudWatch ১ সেকেন্ডের দানা রাখে, পড়া যায় ১, ৫, ১০ বা ৩০ সেকেন্ডে, বা ৬০-এর যেকোনো গুণিতকে। High-resolution metric-এর ওপর alarm ১০ বা ৩০ সেকেন্ডের period নিতে পারে, alarm-এর দাম তখন বেশি।
• এক call-এ অনেক point: এক request-এ ১,০০০টা পর্যন্ত metric, আর Values আর Counts array দিয়ে প্রতিটা metric-এ ১৫০টা পর্যন্ত মান; statistic set দিলে তার বদলে আগে থেকে হিসাব করা Sum, SampleCount, Minimum আর Maximum যায় (সস্তা, কিন্তু percentile মেলে না)।
• Timestamp: দুই সপ্তাহ পুরোনো পর্যন্ত, বা দুই ঘণ্টা সামনে পর্যন্ত। ৩ থেকে ২৪ ঘণ্টা আগের timestamp-ওয়ালা point query-তে দেখা দিতে ২ ঘণ্টা পর্যন্ত নিতে পারে, আর এক দিন বা তার বেশি পুরোনো point অন্তত ৪৮ ঘণ্টা।
• খরচ: প্রতিটা custom metric (namespace, নাম আর dimension-এর প্রতিটা আলাদা জোড়া) মাস ধরে bill হয় (us-east-1-এ প্রথম ১০,০০০টার প্রতিটা ০.৩০ USD, তার বেশি হলে সস্তা), আর PutMetricData call-গুলো API request হিসেবে bill হয়। Free tier-এ মাসে ১০টা custom বা detailed monitoring-এর metric আর ১০ লাখ API request থাকে।

যেহেতু dimension-এর প্রতিটা মান একটা আলাদা, আলাদা bill-ওয়ালা metric, তাই user ID, order ID বা request ID-র মতো অগণিত মানের জিনিস কখনো dimension-এ রেখো না: ১০ লাখ user মানে ১০ লাখ metric। এমন খুঁটিনাটি রাখো log-এ।

#Resolution আর retention: বয়স বাড়লে কী টিকে থাকে

CloudWatch সূক্ষ্ম খুঁটিনাটি রাখে শুধু যতক্ষণ ডেটা নতুন। Point-গুলো পুরোনো হতে থাকলে সেগুলোকে মিলিয়ে মোটা দাগের point বানানো হয় (roll-up; Sum, SampleCount, Minimum আর Maximum রেখে দেওয়া হয়, তাই average ঠিকই থাকে), আর ১৫ মাস পরে মেয়াদ শেষ:

এটাকে একটা সিঁড়ির মতো পড়ো: ১ মিনিটের ডেটা ১৫ দিন ১ মিনিটেই থাকে; তারপরও পড়া যায়, কিন্তু শুধু ৫ মিনিটের ধাপে; ৬৩ দিন পরে শুধু ঘণ্টা ধরে; ৪৫৫ দিন পরে আর নেই। আর সিঁড়ি শুধু নিচের দিকেই নামে: যে ডেটা কখনো ১ মিনিটে নেওয়াই হয়নি (EC2 basic monitoring), তার কোনোদিনই ১ মিনিটের ধাপ ছিল না।

আরও দুটো কথা:

• দুই সপ্তাহ ধরে নতুন ডেটা না আসা metric console আর list-metrics থেকে উধাও হয়ে যায়, কিন্তু মেয়াদ শেষ হওয়া পর্যন্ত তার ডেটা get-metric-data বা get-metric-statistics দিয়ে পড়া যায়।
• কয়েক বছর metric রাখতে হলে (একটা bank-এর audit, ৭ বছর রাখার নিয়ম), CloudWatch সেই archive না। সেগুলো বাইরে কপি করো: S3-এ metric stream (নিচে আছে), বা নিয়মিত চলা একটা job দিয়ে।

নিজে চেষ্টা করো: একটা metric কীভাবে পাঠানো হয়েছিল আর ডেটা কত পুরোনো বেছে নাও, আর দেখো কী বাকি আছে।

#Metric দেখা: graph, math, anomaly band আর dashboard

#Metric math, search আর Metrics Insights

• Metric math কয়েকটা metric মিলিয়ে expression দিয়ে নতুন একটা time series বানায়: error rate = 100 * errors / requests, কয়েকটা instance-এর যোগফল, বদলের হার। Alarm একটা metric math expression-এর ওপরও নজর রাখতে পারে (লেসন ১৯.৩)।
• SEARCH expression মিলে যাওয়া সব metric একসাথে আনে, যেমন একটা Auto Scaling group-এর সব CPUUtilization metric, তাই নতুন instance এলে graph নিজে থেকেই তাকে ধরে নেয়।
• Metrics Insights হলো metric-এর ওপর SQL-এর মতো একটা query language (SELECT AVG(CPUUtilization) FROM SCHEMA("AWS/EC2", InstanceId) GROUP BY InstanceId ORDER BY AVG() DESC LIMIT 10): এক query-তে সবচেয়ে ব্যস্ত ১০টা instance।

#Anomaly detection

Anomaly detection একটা metric-এর ইতিহাস (দিন আর সপ্তাহের ছন্দসহ) থেকে একটা machine-learning model শেখে, আর একটা প্রত্যাশিত band আঁকে। সপ্তাহের দিনে রাত ৮টায় যে traffic স্বাভাবিক, ভোর ৪টায় সেটাই অস্বাভাবিক হতে পারে। একটা নির্দিষ্ট সংখ্যা পেরোনোর বদলে metric band থেকে বেরিয়ে গেলে alarm বাজতে পারে; এই ধরনের alarm লেসন ১৯.৩-এ।

#Dashboard

একটা CloudWatch dashboard হলো graph, সংখ্যা, alarm-এর অবস্থা, log query-র ফল আর লেখা দিয়ে সাজানো একটা পাতা:

• Dashboard global: একটা dashboard-এ কয়েকটা Region-এর widget রাখা যায়, আর cross-account access থাকলে (নিচে আছে) কয়েকটা account-এরও।
• প্রতিটা service-এর automatic dashboard ফ্রি। নিজের বানানোগুলোর বেলায়: মাসে ৩টা dashboard, প্রতিটায় ৫০টা পর্যন্ত metric ফ্রি; তার বেশি হলে প্রতিটা dashboard মাসে প্রায় ৩ USD।
• যাদের AWS account নেই, তাদের সাথেও dashboard ভাগ করা যায় (public link দিয়ে, email address দিয়ে, বা single sign-on দিয়ে); নিজে নিজে refresh হয়, আর সময়ের পরিসর আর time zone ঠিক করে দেওয়া যায়।

#Cross-account observability

বড় কোম্পানি প্রতিটা team বা application-এর জন্য আলাদা AWS account চালায় (লেসন ২০.১)। সবগুলো একসাথে দেখতে CloudWatch cross-account observability সেগুলোকে জুড়ে দেয়:

• একটা monitoring account একটা sink বানায় (প্রতি Region-এ একটা), সাথে একটা policy, কে link করতে পারবে তা বলে। প্রতিটা source account সেই sink-এ একটা link বানায় আর বেছে নেয় কী ভাগ করবে: metric (সব বা কিছু namespace), log group, X-Ray trace, Application Signals, Application Insights-এর application আর Internet Monitor-এর monitor।
• এরপর monitoring account source account-এর ডেটার ওপর graph আঁকে, খোঁজে, alarm বসায় আর dashboard বানায়, কোনো কপি ছাড়াই; metric আর log-এর জন্য বাড়তি খরচ নেই।
• একটা monitoring account-এর সাথে ১,০০,০০০টা পর্যন্ত source account থাকতে পারে; একটা source account সর্বোচ্চ ৫টা monitoring account-এর সাথে ভাগ করতে পারে। AWS Organizations থাকলে নতুন account আপনা থেকে link হয়ে যায়। এর পেছনের API হলো Observability Access Manager (OAM)।
• এটা কাজ করে Region ধরে। পুরোনো cross-account cross-Region dashboard ফিচারটা (IAM role দিয়ে ভাগ করা) এখনো আছে, Region পেরিয়ে dashboard দেখার জন্য।

#Metric Stream: metric বাইরে ঠেলে পাঠানো

অনেক team আগে থেকেই একটা third-party monitoring tool ব্যবহার করে (Datadog, Dynatrace, New Relic, Splunk, Sumo Logic, Elastic), অথবা সব metric একটা data lake-এ চায়। পুরোনো উপায় ছিল polling: একটা collector কয়েক মিনিট পরপর হাজার হাজার metric-এর জন্য GetMetricData call করে। এটা ধীর (ডেটা সবসময় এক polling interval পিছিয়ে), চাওয়া প্রতিটা metric-এর জন্য টাকা লাগে (GetMetricData ফ্রি API-র হিসাবে পড়ে না), আর API throttle-এ আটকে যায়।

CloudWatch Metric Streams পুরো ব্যাপারটা উল্টে দেয়: CloudWatch নিজেই metric-এর হালনাগাদ অনবরত একটা গন্তব্যে ঠেলে পাঠায়, প্রায় real time-এ, কম latency-তে:

• Stream যায় একটা Amazon Data Firehose stream-এ (আগের নাম Kinesis Data Firehose; লেসন ১৩.৬), আর Firehose পৌঁছে দেয় S3-এ, Redshift-এ (S3 হয়ে), OpenSearch-এ, যেকোনো HTTP endpoint-এ, বা একটা partner-এর কাছে। S3 আর partner-দের জন্য quick setup সবকিছু বানিয়ে দেয় (তুমি শুধু endpoint URL আর API key দাও)।
• Output format: JSON, OpenTelemetry 1.0.0 বা OpenTelemetry 0.7.0। Firehose আরও বদলে দিতে পারে, যেমন Athena-র জন্য Parquet-এ (লেসন ১৭.১)।
• Filter: সব stream করো, অথবা ১,০০০টা পর্যন্ত filter দিয়ে namespace বা আলাদা metric include বা exclude করো। একটা stream হয় শুধু include filter নেয়, নয় শুধু exclude filter, দুটো একসাথে না। পরে মিলে যাওয়া নতুন metric আপনা থেকে যোগ হয়।
• Statistic: Minimum, Maximum, SampleCount আর Sum সবসময় থাকে; p99-এর মতো বাড়তি statistic বাড়তি দামে যোগ করা যায়।
• একটা monitoring account-এর stream link করা source account-গুলোর metric-ও নিতে পারে।
• দাম: প্রতি ১,০০০টা metric update ধরে (us-east-1-এ ০.০০৩ USD), সাথে Firehose-এর খরচ। কয়টা stream বানানো যাবে, তার কোনো সীমা নেই।

#কোথায় কোথায় ভুল হয়

• Memory বা disk-এর metric নেই: এটা EC2-এর default metric না। Publish করার অনুমতিওয়ালা instance role-সহ CloudWatch agent বসাও (লেসন ১৯.২)।
• একটা spike চোখে পড়ছে না: ৫ মিনিটের basic metric বা ৫ মিনিটের average সেটা গিলে ফেলেছে। Detailed monitoring, high resolution, Maximum বা p99 ব্যবহার করো।
• একটা alarm INSUFFICIENT_DATA-তে আটকে আছে: ৫ মিনিটের metric-এ ৬০ সেকেন্ডের period, বা ভুল time zone-এর timestamp দিয়ে পাঠানো custom ডেটা (CloudWatch alarm UTC ধরে চলে)।
• Custom metric-এর graph ফাঁকা: ভুল Region, কখনো পাঠানো হয়নি এমন dimension-এর জোড়া, আলাদা unit, বা একদম নতুন metric যেটা এখনো দেখা দেয়নি (১৫ মিনিট পর্যন্ত)।
• PutMetricData বাতিল: timestamp দুই সপ্তাহের বেশি পুরোনো বা দুই ঘণ্টার বেশি সামনে, AWS/ দিয়ে শুরু namespace, ৩০টার বেশি dimension, বা সংখ্যা-নয় এমন একটা মান।
• Bill লাফিয়ে বেড়েছে: অগণিত মানের একটা dimension (user ID, request ID) লাখ লাখ metric বানিয়ে ফেলেছে; বা একটা tool প্রতি মিনিটে সবকিছুর জন্য GetMetricData poll করছে।
• পুরোনো খুঁটিনাটি নেই: ১৫ দিনের বেশি পুরোনো ১ মিনিটের ডেটা শুধু ৫ মিনিটে পাওয়া যায়; S3-এ stream না করলে ৪৫৫ দিনের পরে কিছুই থাকে না।
• Partner-এর tool-এ কিছু metric আসছে না: stream-এর include filter-এ namespace-টা নেই, বা Firehose-এর পৌঁছে দেওয়া ব্যর্থ হচ্ছে (তার backup bucket আর stream-এর নিজের metric দেখো)।
• Monitoring account-এর dashboard-এ একটা metric নেই: source account ওই namespace ভাগ করেনি, link অন্য Region-এ, বা link হওয়ার পরে metric-টা কোনো নতুন point পাঠায়নি।

#System design-এ metric

চেনা কয়েকটা ধরন:

• User-এর কাছে যা জরুরি তা দিয়ে scale করো: queue-তে প্রতি instance-এ কতগুলো কাজ জমে আছে, বা কতগুলো session চালু, এমন একটা custom metric পাঠাও, আর CPU-র বদলে সেটাকে target tracking policy-তে ব্যবহার করো (লেসন ৬.৫ আর লেসন ১৩.১)।
• Percentile দিয়ে service level objective দেখো: প্রতিটা API-র p99 latency আর error rate, average না।
• Technical সংখ্যার পাশে ব্যবসার সংখ্যা: মিনিটে কতগুলো order আর কতগুলো payment সফল, CPU আর 5xx-এর সাথে একই dashboard-এ, যাতে সব server সুস্থ দেখালেও বিক্রি কমে গেলে চোখে পড়ে।
• অনেক account-এর জন্য একটা কেন্দ্রীয় monitoring account, cross-account observability দিয়ে।
• দীর্ঘমেয়াদি বিশ্লেষণ: S3-এ metric stream, Athena দিয়ে query, খরচের ডেটার সাথে মিলিয়ে।
• Metric থেকে alarm (১৯.৩), আর alarm থেকে Auto Scaling, SNS, Lambda আর EC2-এর action। AWS-এ প্রায় প্রতিটা স্বয়ংক্রিয় সাড়ার শুরু একটা metric থেকে।

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

এই command-গুলো AWS CLI v2-এর। Custom metric আর detailed monitoring-এ কয়েক cent খরচ হয়; শেষে stream মুছে ফেলো।

# ১. একটা EC2 instance-এর metric-গুলোর তালিকা (AWS/EC2 namespace, InstanceId dimension)
aws cloudwatch list-metrics --namespace AWS/EC2 \
  --dimensions Name=InstanceId,Value=i-0a1b2c3d4e5f60789 --query 'Metrics[].MetricName'
# [ "CPUUtilization", "NetworkIn", "NetworkOut", "NetworkPacketsIn", "StatusCheckFailed", ... ]
# (memory-র metric নেই: ওটার জন্য CloudWatch agent লাগে)

# ২. Detailed monitoring চালু করো (১ মিনিটের metric, টাকা লাগে)
aws ec2 monitor-instances --instance-ids i-0a1b2c3d4e5f60789
# { "InstanceMonitorings": [ { "InstanceId": "i-0a1b2c3d4e5f60789", "Monitoring": { "State": "pending" } } ] }

# ৩. শেষ এক ঘণ্টার গড় আর সর্বোচ্চ CPU, ৫ মিনিটের period-এ
aws cloudwatch get-metric-statistics --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0a1b2c3d4e5f60789 \
  --start-time 2026-11-01T09:00:00Z --end-time 2026-11-01T10:00:00Z \
  --period 300 --statistics Average Maximum
# { "Label": "CPUUtilization", "Datapoints": [
#     { "Timestamp": "2026-11-01T09:05:00Z", "Average": 41.2, "Maximum": 63.8, "Unit": "Percent" }, ... ] }

# ৪. একটা high-resolution custom metric পাঠাও (storage resolution ১ সেকেন্ড)
aws cloudwatch put-metric-data --namespace Wallet/Payments --metric-data \
  'MetricName=Latency,Dimensions=[{Name=Service,Value=transfer},{Name=Env,Value=prod}],Value=184,Unit=Milliseconds,StorageResolution=1'
# (সফল হলে কোনো output নেই; প্রথম point-ই metric তৈরি করে)

# ৫. get-metric-data দিয়ে percentile-সহ ফেরত পড়ো
aws cloudwatch get-metric-data --start-time 2026-11-01T09:50:00Z --end-time 2026-11-01T10:00:00Z \
  --metric-data-queries '[{"Id":"p99","MetricStat":{"Metric":{"Namespace":"Wallet/Payments","MetricName":"Latency","Dimensions":[{"Name":"Service","Value":"transfer"},{"Name":"Env","Value":"prod"}]},"Period":60,"Stat":"p99"}}]'
# { "MetricDataResults": [ { "Id": "p99", "Label": "Latency", "Timestamps": [ "2026-11-01T09:59:00Z", ... ],
#     "Values": [ 2400.0, ... ], "StatusCode": "Complete" } ] }

# ৬. EC2, ALB আর wallet-এর metric আগে থেকে থাকা একটা Firehose stream-এ পাঠাও, OpenTelemetry 1.0 format-এ
aws cloudwatch put-metric-stream --name wallet-to-partner \
  --firehose-arn arn:aws:firehose:ap-southeast-1:111122223333:deliverystream/metrics-to-partner \
  --role-arn arn:aws:iam::111122223333:role/MetricStreamToFirehose \
  --output-format opentelemetry1.0 \
  --include-filters Namespace=AWS/EC2 Namespace=AWS/ApplicationELB Namespace=Wallet/Payments
# { "Arn": "arn:aws:cloudwatch:ap-southeast-1:111122223333:metric-stream/wallet-to-partner" }
aws cloudwatch get-metric-stream --name wallet-to-partner --query '[State,OutputFormat]'
# [ "running", "opentelemetry1.0" ]

# ৭. গুছিয়ে ফেলো
aws cloudwatch delete-metric-stream --name wallet-to-partner
aws ec2 unmonitor-instances --instance-ids i-0a1b2c3d4e5f60789

Console-এও চেষ্টা করো: All metrics খোলো, একটা instance-এর CPUUtilization-এর graph আঁকো প্রথমে Average, তারপর Maximum statistic দিয়ে, period ৫ মিনিট থেকে ১ ঘণ্টা করো, আর graph-টা নতুন একটা dashboard-এ যোগ করো। তারপর Metrics, Streams খুলে quick partner setup-এর তালিকাটা দেখো।

#সারসংক্ষেপ

মূল কথাগুলো

• অধ্যায়ের সুর: performance আর log → CloudWatch, ঘটনায় সাড়া → EventBridge, কে কোন API call করেছে → CloudTrail, resource দেখতে কেমন ছিল আর নিয়ম মানছে কি না → Config।
• একটা metric = namespace + metric-এর নাম + dimension (৩০টা পর্যন্ত); dimension-এর প্রতিটা নতুন জোড়া একটা আলাদা metric। Data point-এ থাকে timestamp, মান আর unit। Metric regional, আর ডেটা না এলে ১৫ মাস পরে মেয়াদ শেষ।
• Metric পড়ো একটা period ধরে statistic হিসেবে: SampleCount, Sum, Average, Minimum, Maximum, percentile (p99)। Average ধীর লেজটা লুকায়।
• EC2 basic monitoring = ৫ মিনিট, ফ্রি; detailed = ১ মিনিট, টাকা লাগে। বাকি বেশিরভাগ service পাঠায় প্রতি মিনিটে।
• EC2-এর default metric-এ (CPU, network, instance store-এর disk operation, status check) memory, swap বা disk-এর ব্যবহৃত জায়গা নেই → unified CloudWatch agent বা PutMetricData।
• PutMetricData দিয়ে custom metric: standard resolution ১ মিনিট, high resolution ১ সেকেন্ড (StorageResolution=1); timestamp ২ সপ্তাহ পেছনে, ২ ঘণ্টা সামনে পর্যন্ত; অগণিত মানের dimension এড়াও। EMF log line থেকে metric বানায়।
• Retention: ৬০ সেকেন্ডের কম ৩ ঘণ্টা, ১ মিনিট ১৫ দিন, ৫ মিনিট ৬৩ দিন, ১ ঘণ্টা ৪৫৫ দিন (১৫ মাস)। পুরোনো ডেটা মিলিয়ে মোটা করা হয়, কখনো সূক্ষ্ম করা হয় না।
• Metric math, search expression, Metrics Insights, anomaly detection band; dashboard global (অনেক Region, অনেক account), ৩টা ফ্রি।
• Cross-account observability (OAM): sink-ওয়ালা একটা monitoring account, link-ওয়ালা source account; metric আর log বাড়তি খরচ ছাড়া ভাগ হয়, Region ধরে।
• Metric Streams: push, প্রায় real time, Amazon Data Firehose দিয়ে S3-এ, partner-এর কাছে (Datadog, Dynatrace, Elastic, New Relic, Splunk, Sumo Logic) বা যেকোনো HTTP endpoint-এ; JSON বা OpenTelemetry; include বা exclude filter। GetMetricData poll করার চেয়ে ভালো।

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