Container, Lambda, Contributor আর Application Insights

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

• বোঝাতে, container, Lambda function, ঝামেলা-করা client বা enterprise application-এর সমস্যা খুঁজতে একটা service-এর সাধারণ CloudWatch metric কেন যথেষ্ট না, আর চারটা Insights ফিচার বাড়তি কী দেয়।
• ECS, EKS আর EC2-র ওপর Kubernetes-এ (EC2 আর Fargate দুটোতেই) Container Insights চালু করতে, আর enhanced observability-সহ pod, task আর container-এর metric পড়তে।
• একটা function-এ layer হিসেবে Lambda Insights যোগ করতে, আর তা দিয়ে cold start, memory, CPU time আর network মাপতে।
• এমন একটা Contributor Insights rule লিখতে যেটা একটা log group-এর top-N contributor সাজায়, তার ওপর alarm বসাতে, আর DynamoDB-র built-in rule ব্যবহার করতে।
• একটা application-কে Application Insights-এ যোগ করতে, আর ধরা পড়া একটা problem-কে EventBridge আর Systems Manager OpsCenter পর্যন্ত অনুসরণ করতে।
• Scenario-র শব্দ দেখে ঠিক tool বাছতে, আর চারটা Insights-কে Logs Insights, CloudTrail Insights, Application Signals আর X-Ray থেকে আলাদা করতে।

#Insights পরিবার: system-এর একটা অংশকে কাছ থেকে দেখা

#সাধারণ metric কেন যথেষ্ট না

লেসন ১৯.১-এ আমরা দেখেছি প্রতিটা AWS service নিজে থেকে কোন metric পাঠায়, আর ১৯.২-এ দেখেছি কোন log জোগাড় করা যায়। এরা বলে দেয় “কিছু একটা গোলমাল আছে”। কিন্তু “ঠিক কোথায়?”, এই প্রশ্নের উত্তর প্রায়ই দিতে পারে না:

• একটা EKS node-এর memory ৫৮%, অথচ তার ভেতরের একটা pod কয়েক মিনিট পরপর মারা যাচ্ছে, কারণ সে নিজের memory limit ছুঁয়ে ফেলছে। Node-এর metric এটা লুকিয়ে রাখে।
• একটা Lambda function-এর সাধারণ metric হলো invocation, duration, error আর throttle। কতটা memory লাগল, কতটা CPU time গেল, cold start-এ কতক্ষণ লাগল, এসব সেখানে নেই।
• Web server-এর CPU ৯৫%। CPU-র graph বলে server ব্যস্ত, কিন্তু কে তাকে ব্যস্ত রাখছে তা বলে না।
• IIS-এর ওপর একটা .NET application error দিচ্ছে, ওদিকে SQL Server-এর log-এ deadlock। দুই team দুটো আলাদা alarm পায়, কেউ খেয়াল করে না যে এটা আসলে একটাই সমস্যা।

CloudWatch Insights পরিবার হলো চারটা ফিচার, প্রতিটা system-এর একটা করে অংশের আরও গভীরে যায়। এরা metric, log আর alarm-এর জায়গা নেয় না: এদের ওপরেই বানানো। প্রত্যেকে বাড়তি data জোগাড় করে (বা তুমি আগে থেকে যা পাঠাচ্ছ তা-ই পড়ে), নিজের প্রশ্নের জন্য metric আর dashboard বানায়, আর ফলের ওপর alarm বসাতে দেয়।

#চারটা ফিচার, চারটা প্রশ্ন

#Container Insights

#কী কী জোগাড় করে

Container Insights container থেকে metric আর log জোগাড় করে, জমায় আর সারসংক্ষেপ বানায়: CPU, memory, disk আর network, সঙ্গে container restart failure-এর মতো রোগ-নির্ণয়ের তথ্য। এটা পাওয়া যায়:

• Amazon ECS-এ, EC2 আর Fargate দুটোতেই;
• Amazon EKS-এ, EC2 node আর Fargate দুটোতেই;
• EC2-র ওপর তোমার নিজের চালানো Kubernetes platform-এ।

Data যায় embedded metric format-এ (সাজানো JSON, লেসন ১৯.১) performance log event হিসেবে, এমন একটা log group-এ যেটা Container Insights নিজেই বানিয়ে নেয়, যেমন /aws/ecs/containerinsights/<cluster>/performance বা /aws/containerinsights/<cluster>/performance। এই event থেকে CloudWatch cluster, node, service, task আর pod পর্যায়ের জমানো metric বানায় (enhanced observability-তে container পর্যায়েরও), ContainerInsights namespace-এ (ECS-এর জন্য ECS/ContainerInsights), আর automatic dashboard ভরে দেয়। খরচ কম রাখতে CloudWatch সম্ভাব্য প্রতিটা field-কে metric বানায় না; বাকিটা performance event-এই থাকে, যেখানে Logs Insights দিয়ে query করা যায়।

সাধারণ metric: Kubernetes-এ pod_cpu_utilization, pod_memory_utilization, pod_number_of_container_restarts, node_cpu_utilization, cluster_failed_node_count; ECS-এ CpuUtilized, MemoryUtilized, RunningTaskCount। এরা অন্য যেকোনো metric-এর মতোই: graph আঁকো, alarm বসাও (লেসন ১৯.৩), এদের দেখে scale করো। লেসন ১৪.৩-এ একটা নির্ভরতা দেখেছিলাম: প্রতি task-এ queue backlog দেখে scale করা ECS service-এর RunningTaskCount লাগে, আর সেটা থাকে শুধু Container Insights চালু থাকলে।

Log-এর জন্য, EKS আর Kubernetes-এ add-on Fluent Bit চালায়, যেটা container-গুলো stdout আর stderr-এ যা লেখে তা /aws/containerinsights/<cluster>/application-এর মতো log group-এ পাঠায়, সঙ্গে host আর data-plane-এর log। Log group-এ তুমি একটা KMS key বসালে Container Insights তার জোগাড় করা data সেই key দিয়ে encrypt করে (শুধু symmetric key)।

#চালু করা

ECS: একটা cluster setting, কোনো agent না। ECS agent (EC2-তে) আর Fargate আগে থেকেই task-এর data পাঠায়। তুমি প্রতিটা cluster-এ Container Insights চালু করো, বা নতুন cluster-এর জন্য account-এর default বানিয়ে দাও:

• enabled: আসল Container Insights (cluster, service আর task-এর metric);
• enhanced: Container Insights with enhanced observability (ECS-এ এসেছে ২০২৪-এর শেষে): আরও dimension, container পর্যায়ের metric, আর cluster থেকে container পর্যন্ত নামার মতো সাজানো dashboard। AWS আসলটার বদলে এটাই ব্যবহার করতে বলে।

EKS আর EC2-র ওপর Kubernetes: container-এ চলা CloudWatch agent। Kubernetes-এ Container Insights প্রতিটা চলমান container খুঁজে পেতে CloudWatch agent-এর একটা container সংস্করণ ব্যবহার করে। EKS-এ তুমি Amazon CloudWatch Observability add-on (amazon-cloudwatch-observability) install করো, যেটা CloudWatch agent আর Fluent Bit-কে DaemonSet হিসেবে চালায়, প্রতিটা node-এ একটা করে কপি। Data পাঠাতে agent-এর permission লাগে: node role-এ CloudWatchAgentServerPolicy managed policy লাগাও, অথবা EKS Pod Identity (বা IAM roles for service accounts) দিয়ে agent-কে আলাদা role দাও। EC2-র ওপর নিজে চালানো Kubernetes cluster-এ একই agent তুমি নিজে বসাও।

EKS on Fargate: কোনো DaemonSet না। Fargate প্রতিটা pod-কে আলাদা একটা পরিবেশ দেয়, তোমার সামলানো কোনো node নেই, তাই DaemonSet সেখানে চলতে পারে না। সমর্থিত পথ হলো একটা AWS Distro for OpenTelemetry (ADOT) collector, যেটা kubelet থেকে পড়ে pod-এর ছোট একটা metric-এর সেট পাঠায় (CPU, memory, network)। Fargate-এ enhanced observability পাওয়া যায় না।

#Enhanced observability আর OpenTelemetry pipeline

EKS-এর enhanced observability (২০২৩) container পর্যন্ত বিস্তারিত metric, control plane-এর metric, সাজানো health dashboard আর বিশেষ hardware-এর (GPU আর Neuron chip) metric যোগ করে, আর এর দাম ধরা হয় প্রতি observation হিসেবে, প্রতিটা জমানো custom metric আর প্রতি GB log হিসেবে না। আসল Container Insights-এর দাম ধরা হয় custom metric আর log ingestion হিসেবে।

#Lambda Insights

#সাধারণ metric কী মিস করে

প্রতিটা Lambda function বিনা পয়সায় Invocations, Duration, Errors, Throttles আর concurrency-র metric পাঠায় (লেসন ১৫.১)। তার log-এর REPORT লাইনে ব্যবহার করা memory আর, cold start হলে, init duration-ও লেখা থাকে, কিন্তু শুধু লাইন ধরে ধরে; হাজার হাজার invocation জুড়ে graph আঁকার মতো metric হিসেবে কখনো না।

Lambda Insights হলো Lambda-র ওপর চলা serverless application-এর monitoring আর troubleshooting-এর সমাধান। এটা জোগাড় করে, জমায় আর সারসংক্ষেপ বানায়:

• System পর্যায়ের metric: CPU time (cpu_total_time), memory (memory_utilization, মানে বসানো memory-র কত শতাংশ; used_memory_max, total_memory), network (rx_bytes, tx_bytes, total_network) আর disk (/tmp-এর জন্য tmp_used, tmp_free);
• রোগ-নির্ণয়ের তথ্য: cold start (init_duration, মানে init ধাপে কাটানো সময়) আর Lambda worker shutdown।

জমানো metric থাকে LambdaInsights namespace-এ, dimension function_name (আর version); আরও কয়েকটা মান (thread, file descriptor, agent-এর নিজের memory) log event-এই থাকে, Logs Insights query-র জন্য। CloudWatch এগুলো দিয়ে একটা অনেক-function-এর overview আর একটা একক-function-এর view বানায়।

#কীভাবে কাজ করে

Lambda Insights আসে একটা Lambda extension হিসেবে, Lambda layer-এ মুড়ে। Layer-টা (LambdaInsightsExtension, প্রতিটা Region-এ AWS publish করে) যোগ করলে execution environment-এর সাথে extension-ও চালু হয়, প্রতিটা invocation মাপে, আর প্রতিটা invocation-এর জন্য embedded metric format-এ একটা করে performance log event লেখে /aws/lambda-insights log group-এ। CloudWatch সেই event থেকে metric বের করে।

চালু করার ধাপ:

1. Function-এর execution role-এ CloudWatchLambdaInsightsExecutionRolePolicy managed policy দাও (log group-এ লেখার permission)।
2. Layer যোগ করো: Lambda console-এ এক click (“Enhanced monitoring”), aws lambda update-function-configuration --layers …, অথবা SAM / CloudFormation-এ একটা property।
3. NAT gateway ছাড়া private subnet-এ থাকা function-এর জন্য CloudWatch Logs-এর একটা interface VPC endpoint যোগ করো, নইলে extension-এর event পাঠানোর কোনো জায়গা থাকে না (লেসন ১৫.৩)।

Container image হিসেবে বানানো function layer ব্যবহার করতে পারে না: সেখানে extension-টা image-এর ভেতরে copy করে দাও। Lambda Insights Amazon Linux 2 আর Amazon Linux 2023-এর runtime সমর্থন করে। এটা যে metric আর log বানায় তার দাম দাও, আর extension-এর চলার সময়ের দাম 1 ms-এর ধাপে (এটা তোমার function-এর billed duration-এর ভেতরেই চলে)।

#Contributor Insights

#তোমার log থেকে top-N

Contributor Insights log data বিশ্লেষণ করে contributor data-র time series বানায়: top-N contributor, আলাদা contributor-এর মোট সংখ্যা, আর প্রত্যেকে কতটা দিচ্ছে। এটা top talker খুঁজে বের করে, আর দেখায় কে বা কী performance-এর ওপর প্রভাব ফেলছে: খারাপ host, network-এর সবচেয়ে ভারী ব্যবহারকারী, সবচেয়ে বেশি error তৈরি করা URL, সবচেয়ে দামি call করা customer।

এটা কাজ করে CloudWatch Logs-এর যেকোনো log group-এ, যার event JSON বা Common Log Format (CLF)-এ, আর এতে বেশিরভাগ AWS-এর বানানো log পড়ে যায়: VPC Flow Logs, Route 53 resolver query log, API Gateway access log, CloudTrail, তোমার পাঠানো ALB-ধাঁচের access log, আর তোমার নিজের application log। Rule শূন্য থেকে বানাতে পারো, অথবা console-এ AWS-এর sample rule দিয়ে শুরু করতে পারো।

#Rule

একটা rule হলো ছোট একটা JSON document:

• Log group: নাম (শেষে * দিলে prefix মেলে), অথবা cross-account monitoring account-এ source account-গুলোর log group ARN (লেসন ১৯.১-এ cross-account observability বোঝানো আছে)।
• Log format: JSON বা CLF। CLF আর অন্য space দিয়ে ভাগ করা log-এ Fields দিয়ে অবস্থানের নাম দাও (field 4 = srcAddr)।
• Contribution key: চারটা পর্যন্ত field, যেগুলো মিলে একজন contributor ঠিক হয়। দুটো key (source আর destination address) দিলে প্রতিটা জোড়া একজন contributor।
• Filter: চারটা পর্যন্ত, AND দিয়ে জোড়া (In, NotIn, StartsWith, GreaterThan, LessThan, EqualTo, NotEqualTo, IsPresent), যেমন শুধু ACCEPT flow record, বা শুধু ৫০০ আর তার ওপরের status code।
• Aggregate on: Count (log event-এর সংখ্যা) বা ValueOf-এ বলা একটা সংখ্যার field-এর Sum (byte, duration)।

বাস্তবে আর পরীক্ষায় দুটো আচরণ খুব জরুরি:

• Rule আসতে থাকা data real time-এ বিশ্লেষণ করে। একটা rule শুধু সেই log event দেখে যা তার জন্মের পরে আসে; পুরোনো event-এ কখনো পেছনে ফিরে যায় না। “গত বৃহস্পতিবার কে এটা করেছিল?” প্রশ্নের জন্য জমানো log-এ Logs Insights দিয়ে query চালাও।
• সে জানায়; কিছু করে না। Contributor Insights কাউকে আটকায় না। ঝামেলা-করা একটা address থামাতে network ACL-এ একটা deny rule বা একটা WAF rule যোগ করো (লেসন ২১.৬ আর ২৪.৩)।

INSIGHT_RULE_METRIC metric math function দিয়ে একটা rule-এর ওপর alarm বসানো যায়, যেমন UniqueContributors-এর ওপর (হঠাৎ লাফ মানে হতে পারে botnet) বা MaxContributorValue-এর ওপর (একজন contributor অনেক বড় হয়ে গেছে)। দামের দুটো অংশ: প্রতিটা rule-এর জন্য মাসিক একটা চার্জ, আর rule-এর সাথে মেলা প্রতি ১০ লাখ log event-এর জন্য চার্জ, তাই ভুল করেও সব log group-এর দিকে * wildcard তাক কোরো না।

#Built-in rule: DynamoDB আর PrivateLink

কিছু service-এর সাথে built-in rule আসে, যেখানে তোমাকে শুধু ফিচারটা চালু করতে হয়:

• Contributor Insights for DynamoDB: একটা table বা global secondary index-এ চালু করো, DynamoDB নিজেই rule বানিয়ে নেয়: সবচেয়ে বেশি ব্যবহার হওয়া key (খরচ হওয়া throughput দিয়ে মাপা) আর সবচেয়ে বেশি throttle হওয়া key, partition key-র জন্য, আর sort key থাকলে partition যোগ sort key-র জন্যও। একটা hot partition (লেসন ১৫.৪) সাথে সাথে চোখে পড়ে। এখন দুটো mode আছে: accessed and throttled keys (প্রতিটা read আর write একটা event) আর শুধু throttled keys, যেটা শুধু কোনো request throttle হলে event তৈরি করে, আর এত সস্তা যে সবসময় চালু রাখা যায়। Table-এর ওপর এটা কোনো বাড়তি চাপ দেয় না।
• AWS PrivateLink: VPC endpoint service-এর built-in rule দেখায় কোন endpoint আর কোন consumer সবচেয়ে বেশি traffic পাঠাচ্ছে।

#Application Insights

#কী করে

CloudWatch Application Insights একটা application আর তার নিচের AWS resource-এর জন্য monitoring বসায়, তারপর সমস্যার জন্য নজর রাখে। এর লক্ষ্য হলো পরিচিত technology দিয়ে বানানো EC2-র ওপরের enterprise application:

• Front end: Microsoft IIS web server।
• Worker আর application tier: .NET Framework আর .NET Core, Java (Java-র metric পড়তে Systems Manager দিয়ে একটা Prometheus exporter বসিয়ে নেয়)।
• Directory আর collaboration: Active Directory, SharePoint।
• Database: SQL Server (EC2 বা RDS-এ, high-availability setup-সহ), MySQL, PostgreSQL, Oracle, DynamoDB, সঙ্গে কয়েকটা বড় ERP suite।
• সাথের AWS resource: EBS, RDS, Elastic Load Balancing, Auto Scaling group, Lambda, SQS, SNS, S3 bucket, Step Functions, API Gateway REST stage, ECS আর EKS।

কীভাবে কাজ করে:

1. একটা resource group বেছে তুমি একটা application যোগ করো (tag থেকে বা একটা CloudFormation stack থেকে)। একটা resource group = একটা application।
2. সে resource-গুলো ঘেঁটে দেখে আর component চিনে নেয় (একটা SQL Server database, একটা IIS web tier, worker-দের একটা Auto Scaling group)।
3. প্রতিটা technology-র জন্য ঠিক metric আর log প্রস্তাব করে আর বসায় (Windows event log, IIS log, SQL Server error log, প্রতি সেকেন্ডে deadlock-এর মতো counter), Systems Manager দিয়ে CloudWatch agent install আর configure করে (agent-এর configuration থাকে Parameter Store-এ)।
4. Dynamic alarm বানায়, যাদের threshold আগের দুই সপ্তাহের data-র anomaly detection দেখে ঠিক হয়।
5. সারাক্ষণ metric আর log বিশ্লেষণ করতে থাকে। প্রতিটা anomaly বা log error একটা observation; সম্পর্কিত observation-গুলো জুড়ে একটা problem হয়, সঙ্গে নিজে থেকে বানানো dashboard, আর .NET ও SQL Server-এর পরিচিত সমস্যার বেলায় একটা insight যেটা সম্ভাব্য মূল কারণ আর সমাধানের ধাপ দেখায়।
6. Problem-গুলো যায় EventBridge-এ event হিসেবে (rule সেগুলো SNS-এ পাঠাতে বা Lambda function চালাতে পারে, লেসন ১৯.৫), সরাসরি SNS notification দিতে পারে, আর Systems Manager OpsCenter-এ OpsItem খোলে, যেখানে সমাধানের জন্য একটা Automation runbook চালানো যায় (লেসন ২৫.৩)।

AWS-এর ভাষায় এটা SageMaker আর অন্য AWS technology দিয়ে চালিত। ফিচারটা নিজে বিনা পয়সার; সে যে CloudWatch metric, log আর alarm বসায় তার দাম দাও (বিলের বেশিরভাগই সাধারণত alarm), আর OpsItem-এর দাম।

যে technology সে চেনে না, সেখানে একটা component-কে Custom রাখা যায়: metric আর log file তুমি বেছে দাও, কিন্তু technology-নির্দিষ্ট insight পাও না।

#চারটার বাইরে: trace আর APM

চারটা Insights resource আর log দেখে। একটা request-কে অনেকগুলো service জুড়ে অনুসরণ করতে trace লাগে। সম্পর্কিত তিনটা service, প্রত্যেকটার এক লাইন পরীক্ষার জ্ঞান:

• AWS X-Ray distributed trace রাখে: একটা request-কে API Gateway, Lambda, container আর DynamoDB পার হতে দেখা যায়, প্রতিটা ধাপ সময়সহ একটা segment, আর X-Ray একটা service map আঁকে, প্রতিটা সংযোগে latency আর error-সহ। “কোন microservice ধীর?”, “শুরু থেকে শেষ পর্যন্ত request trace করো” → X-Ray। Instrumentation এখন OpenTelemetry-র দিকে যাচ্ছে: X-Ray SDK আর daemon ২৫ ফেব্রুয়ারি ২০২৬ থেকে maintenance mode-এ (support শেষ ২৫ ফেব্রুয়ারি ২০২৭); trace পাঠাতে AWS AWS Distro for OpenTelemetry (ADOT) বা CloudWatch agent ব্যবহার করতে বলে। X-Ray নিজে, তার console আর trace, কিছুই বদলায়নি।
• CloudWatch Application Signals (২০২৪) হলো AWS-এর APM: EKS, ECS, EC2 আর Lambda-তে চলা Java, Python, Node.js আর .NET application নিজে থেকে instrument করে, প্রতিটা service আর operation-এর call volume, availability, latency, fault আর error দেখায়, একটা application map আঁকে, আর service level objective (SLO) ঠিক করতে দেয়। এটা X-Ray trace-এর ওপর বানানো, আর Synthetics canary (লেসন ১৯.৩) আর web page-এর আসল user-দের monitoring করা CloudWatch-এর ফিচারের সাথে মিলে কাজ করে।
• Amazon Managed Service for Prometheus Prometheus server না চালিয়েই Prometheus metric (Kubernetes-এ খুব চলে) রাখে, আর Amazon Managed Grafana CloudWatch, Prometheus, X-Ray আর অন্য source-এর ওপর managed Grafana dashboard দেয়। “আমরা Prometheus আর Grafana ব্যবহার করি, এগুলো রাখব কিন্তু server চালানো বন্ধ করব” → এই দুটো।

#ঠিক tool বাছাই

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

• EKS-এ Container Insights কোনো data দেখায় না: CloudWatch agent-এর permission নেই। Node role-এ CloudWatchAgentServerPolicy লাগাও, বা EKS Pod Identity দিয়ে agent-কে একটা role দাও; agent-এর নিজের log-এ AccessDenied দেখা যায়।
• প্রতি task-এ backlog দেখে ECS scaling কখনো scale করে না: cluster-এ Container Insights বন্ধ, তাই RunningTaskCount নেই-ই (লেসন ১৪.৩)।
• EKS-এর Fargate pod-এর কোনো Container Insights metric নেই: Fargate-এ DaemonSet চলে না। ADOT collector ব্যবহার করো, আর মেনে নাও metric কম, enhanced observability নেই।
• Node-এর graph ঠিক, কিন্তু একটা service বারবার fail করছে: তুমি এক ধাপ ওপর থেকে দেখছ। Pod আর container-এর metric আর restart-এর সংখ্যা দেখো; container মারা যায় তার নিজের limit-এ, node-এর limit-এ না।
• Container Insights-এর বিল হঠাৎ লাফ দিল: আসল mode প্রতিটা metric-কে custom metric হিসেবে আর প্রতি GB log-এর দাম ধরে; অনেক pod-ওয়ালা বড় cluster অনেক metric বানায়। Enhanced observability-র প্রতি observation-এর দামের সাথে তুলনা করো, আর performance log group-এ retention বসাও।
• Lambda Insights-এর page খালি থাকে: layer নেই, execution role-এ CloudWatchLambdaInsightsExecutionRolePolicy নেই, অথবা function এমন private subnet-এ চলে যেখানে CloudWatch Logs endpoint বা NAT নেই।
• Container image function-এ Lambda Insights কাজ করে না: সেখানে layer চলে না; extension-টা image-এ যোগ করো।
• Contributor Insights rule গত সপ্তাহের কিছুই দেখায় না: rule শুধু তার জন্মের পরে আসা event দেখে। অতীতের জন্য Logs Insights।
• Contributor Insights rule কিছুই দেখায় না: ভুল log format (JSON বনাম CLF), ভুল field নাম (মেলানো case-sensitive), বা এমন filter যেটা কোনো event-এর সাথে মেলে না।
• “Contributor Insights আক্রমণকারীকে খুঁজে পেল, তবু আক্রমণ চলছে কেন?”: সে শুধু জানায়। Network ACL বা WAF-এ আটকাও।
• DynamoDB Contributor Insights-এ খরচ বেশি: accessed-and-throttled mode প্রতিটা read আর write হওয়া item গোনে (sort key থাকলে দুবার)। সবসময় চালু রাখতে শুধু throttled-keys mode-এ যাও।
• Application Insights কোনো tier খুঁজে পেল না: resource-গুলো resource group-এ নেই (tag নেই), অথবা technology-টা সমর্থিত না; একটা Custom component রাখো, আর request পর্যায়ের দৃষ্টির জন্য Application Signals।
• Application Insights একটা problem তুলল, কেউ দেখল না: কেউ শুনছে না। একটা EventBridge rule বা SNS notification যোগ করো, আর OpsCenter দেখার দায়িত্ব কাউকে দাও।

#System design-এ Insights

• Observability স্তরে স্তরে সাজাও। ভিত্তি হলো service metric, retention-সহ log, আর alarm (লেসন ১৯.১–১৯.৩)। তার ওপর প্রতিটা platform-এর সাথে মেলে এমন Insights ফিচার যোগ করো: প্রতিটা cluster-এ Container Insights, গুরুত্বপূর্ণ function-এ Lambda Insights, enterprise stack-এ Application Insights, আর যেসব log-এ “কে?” প্রশ্নটা প্রায়ই আসে সেখানে কয়েকটা Contributor Insights rule।
• চক্রটা পূর্ণ করো। প্রতিটা Insights ফিচার metric বা event বানায়, তাই সেটা দিয়ে একটা alarm (১৯.৩) বা একটা EventBridge rule (১৯.৫) চালানো যায়, যা কাউকে ডাকে, service scale করে বা runbook চালায়।
• খরচ সামলাও। Insights ফিচার metric, log event আর alarm বানায়। Cluster ধরে বা function ধরে চালু করো, log retention বসাও, DynamoDB-র throttled-keys mode ব্যবহার করো, আর Contributor Insights rule-কে *-এর দিকে তাক কোরো না।
• অনেক account। CloudWatch cross-account observability দিয়ে একটা কেন্দ্রীয় monitoring account source account-গুলোর Container Insights আর Lambda Insights-এর data দেখতে পারে, source log group-এর ওপর Contributor Insights rule চালাতে পারে, আর Application Insights-ও এটা সমর্থন করে।
• নিরাপত্তা। Data-তে key আর IP থাকতে পারে: DynamoDB Contributor Insights key-র মান CloudWatch-এ publish করে, তাই যে table-এর key-তে এমন স্পর্শকাতর তথ্য আছে যা fine-grained access control দিয়ে লুকানোর কথা, সেখানে এটা চালু কোরো না।

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

এই command-গুলো ap-south-1 (মুম্বাই)-এ AWS CLI v2 ব্যবহার করে। Cluster, function, table আর account-এর নাম (111122223333) কাল্পনিক। এখানকার প্রতিটা ফিচারের দাম CloudWatch metric, log বা alarm হিসেবে ধরা হয়, তাই শেষ হলে বন্ধ করে দিও।

# ১. ECS: একটা cluster-এ enhanced observability-সহ Container Insights চালু করো
aws ecs update-cluster-settings --cluster shop-prod \
  --settings name=containerInsights,value=enhanced \
  --query 'cluster.settings'
# [ { "name": "containerInsights", "value": "enhanced" } ]

# ২. EKS: node role-কে permission দাও, তারপর observability add-on install করো
aws iam attach-role-policy --role-name shop-eks-node-role \
  --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
aws eks create-addon --cluster-name shop-eks \
  --addon-name amazon-cloudwatch-observability \
  --query 'addon.[addonName,status]' --output text
# amazon-cloudwatch-observability  CREATING

# ৩. কোন pod restart হচ্ছে? (agent চালু হওয়ার কয়েক মিনিট পরে metric আসে)
aws cloudwatch list-metrics --namespace ContainerInsights \
  --metric-name pod_number_of_container_restarts \
  --dimensions Name=ClusterName,Value=shop-eks \
  --query 'Metrics[].Dimensions[?Name==`PodName`].Value' --output text
# cart  search  checkout

# ৪. Lambda Insights: permission + layer (তোমার Region-এর বর্তমান layer version দেখে নিও)
aws iam attach-role-policy --role-name payout-fn-role \
  --policy-arn arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy
aws lambda update-function-configuration --function-name payout \
  --layers arn:aws:lambda:ap-south-1:580247275435:layer:LambdaInsightsExtension:56 \
  --query 'Layers[].Arn'

# ৫. শেষ এক ঘণ্টার cold start, Lambda Insights-এর performance event থেকে
aws logs start-query --log-group-name /aws/lambda-insights \
  --start-time $(date -d '-1 hour' +%s) --end-time $(date +%s) \
  --query-string 'filter function_name = "payout" and ispresent(init_duration)
    | stats count(*) as coldStarts, avg(init_duration) as avgInitMs, max(memory_utilization) as maxMemPct'
# { "queryId": "a1b2c3d4-5678-90ab-cdef-111122223333" }
aws logs get-query-results --query-id a1b2c3d4-5678-90ab-cdef-111122223333
# coldStarts 214   avgInitMs 1847.6   maxMemPct 61.3

# ৬. Contributor Insights: VPC Flow Logs-এর top source address (শুধু accepted traffic)
cat > top-talkers.json <<'EOF'
{
  "Schema": { "Name": "CloudWatchLogRule", "Version": 1 },
  "LogGroupNames": [ "/vpc/news-portal-flow-logs" ],
  "LogFormat": "CLF",
  "Fields": { "4": "srcAddr", "13": "action" },
  "Contribution": {
    "Keys": [ "srcAddr" ],
    "Filters": [ { "Match": "action", "In": [ "ACCEPT" ] } ]
  },
  "AggregateOn": "Count"
}
EOF
aws cloudwatch put-insight-rule --rule-name news-top-talkers \
  --rule-state ENABLED --rule-definition file://top-talkers.json

# ৭. শেষ ৫ মিনিটের top 3 contributor পড়ো
aws cloudwatch get-insight-rule-report --rule-name news-top-talkers \
  --start-time $(date -u -d '-5 min' +%FT%TZ) --end-time $(date -u +%FT%TZ) \
  --period 300 --max-contributor-count 3 \
  --query 'Contributors[].[Keys[0],ApproximateAggregateValue]' --output text
# 203.0.113.66    92400.0
# 198.51.100.23   4350.0
# 203.0.113.9     4020.0

# ৮. ৫ মিনিটে একটা address ২০,০০০-এর বেশি accepted record পাঠালে alarm
aws cloudwatch put-metric-alarm --alarm-name news-one-ip-dominates \
  --metrics '[{"Id":"m1","Expression":"INSIGHT_RULE_METRIC(\"news-top-talkers\", \"MaxContributorValue\")","Period":300,"ReturnData":true}]' \
  --comparison-operator GreaterThanThreshold --threshold 20000 --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:ap-south-1:111122223333:oncall

# ৯. DynamoDB-র built-in Contributor Insights, শুধু throttled key (সবসময় চালু রাখতে সস্তা)
aws dynamodb update-contributor-insights --table-name Orders \
  --contributor-insights-action ENABLE --contributor-insights-mode THROTTLED_KEYS
aws dynamodb describe-contributor-insights --table-name Orders \
  --query '[ContributorInsightsStatus,ContributorInsightsMode]'
# [ "ENABLED", "THROTTLED_KEYS" ]

# ১০. Application Insights: একটা resource group যোগ করো আর ধরা পড়া problem দেখো
aws application-insights create-application --resource-group-name loans-app \
  --auto-config-enabled --ops-center-enabled \
  --ops-item-sns-topic-arn arn:aws:sns:ap-south-1:111122223333:oncall
aws application-insights list-problems --resource-group-name loans-app \
  --query 'ProblemList[].[Title,SeverityLevel,Status]' --output text
# SQL Server deadlocks causing web tier errors   High   PENDING

# ১১. পরিষ্কার করো
aws cloudwatch delete-insight-rules --rule-names news-top-talkers
aws cloudwatch delete-alarms --alarm-names news-one-ip-dominates
aws dynamodb update-contributor-insights --table-name Orders --contributor-insights-action DISABLE
aws ecs update-cluster-settings --cluster shop-prod --settings name=containerInsights,value=disabled

Console-এ CloudWatch → Insights খোলো: Container Insights দেখায় cluster-এর একটা map, সবচেয়ে ব্যস্ত pod-সহ; Lambda Insights অনেক function-এর একটা table, cold start দিয়ে সাজানো; Contributor Insights rule-গুলো আর তাদের top-N graph; Application Insights application-গুলো আর তাদের problem।

#সারসংক্ষেপ

মূল কথা

• CloudWatch Insights পরিবার সাধারণ metric-এর চেয়ে গভীরে যায়, প্রতিটা system-এর একটা করে অংশে, আর CloudWatch-এর metric, log আর alarm-এর ওপরেই বানানো।
• Container Insights: ECS, EKS, EC2-র ওপর Kubernetes আর Fargate (ECS আর EKS)-এর container থেকে metric আর log, cluster, node, service, task, pod আর container পর্যায়ে, restart-সহ। ECS: একটা cluster setting (enabled বা enhanced), কোনো agent না। EKS / Kubernetes: container-এ চলা CloudWatch agent (EKS add-on, DaemonSet) আর Fluent Bit; IAM permission লাগে। EKS on Fargate: ADOT, metric কম, enhanced observability নেই। EKS-এ enhanced observability-র দাম প্রতি observation।
• Lambda Insights: Lambda layer হিসেবে আসা একটা extension; প্রতি invocation-এ একটা performance event যায় /aws/lambda-insights-এ; CPU time, memory, network, /tmp, cold start (init_duration) আর worker shutdown। Managed execution-role policy লাগে, আর private subnet থেকে Logs endpoint বা NAT।
• Contributor Insights: CloudWatch Logs (JSON বা CLF)-এর ওপর একটা rule top-N contributor সাজায় আর আলাদা contributor গোনে, real time-এ, জন্মের পর থেকে (অতীতের জন্য Logs Insights)। চারটা পর্যন্ত key আর চারটা filter, Count বা Sum। INSIGHT_RULE_METRIC দিয়ে alarm। DynamoDB-তে built in (সবচেয়ে বেশি ব্যবহার হওয়া / throttle হওয়া key, hot partition), PrivateLink-এও। সে জানায়; আটকায় NACL আর WAF।
• Application Insights: একটা resource group দেখিয়ে দাও; সে EC2-র ওপর .NET, IIS, SQL Server, Java, Active Directory আর আরও কিছু চিনে নেয়, Systems Manager দিয়ে metric, log আর dynamic alarm বসায়, observation জুড়ে সম্ভাব্য মূল কারণসহ problem বানায়, আর পাঠায় EventBridge আর OpsCenter-এ।
• কাছাকাছি-দেখতে: Logs Insights (জমা log-এ query), CloudTrail Insights (অস্বাভাবিক API কাজকর্ম), X-Ray (trace, service map; SDK ফেব্রুয়ারি ২০২৬ থেকে maintenance-এ, OpenTelemetry ব্যবহার করো), Application Signals (APM, SLO), Managed Prometheus / Grafana, আর EC2-র memory ও disk-এর জন্য unified agent।

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