Lab 7: Monitoring, Observability & Cost

Pehle Lab 1 wale role ko CloudWatch agent chalane ki permission do:

aws iam attach-role-policy --role-name deepdive-ec2-role \
  --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

Phir EC2 console mein Launch instance dabao. Naam deepdive-monitor rakho, Amazon Linux 2023 aur free-tier instance type chuno, key pair mat chuno, default VPC mein public IP chalu rakho, security group mein Lab 2 wala deepdive-web-sg chuno (jisme HTTP 80 khula hai), IAM profile mein deepdive-ec2-role chuno, aur user data mein Lab 2 wali userdata.sh (nginx wali script) daalo. Project=deepdive tag lagao aur Launch karo. Uske baad instance ka ID aur public IP variables mein rakho aur page check karo:

IID=<instance-id>
IP=<public-ip>
curl -s http://$IP | head -3

Agar tumne Lab 2 ka security group delete kar diya tha, toh ek naya security group banao jisme HTTP 80 har jagah se allowed ho.

• curl se DEEPDIVE ka page aa raha hai.
• deepdive-ec2-role pe ab teen managed policies lagi hain: S3ReadOnly, SSMManagedInstanceCore aur CloudWatchAgentServerPolicy.

1. EC2 console mein apna instance kholo aur uska Monitoring tab dekho. Wahan CPU utilization, network in/out, status check failed aur EBS read/write jaise metrics dikhenge.
2. CloudWatch mein Metrics → All metrics → EC2 → Per-Instance Metrics kholo, apna instance dhoondho aur CPUUtilization chuno. Graphed metrics tab mein Statistic (jaise Average, Maximum ya p99) aur Period badal ke dekho ki graph kaise badalta hai.

Yahi data CLI se bhi nikaala ja sakta hai. Neeche wali command pichhle ek ghante ka CPU data 5 minute ke hisson mein laati hai:

# macOS date syntax; Linux pe: --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ)
aws cloudwatch get-metric-statistics --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=$IID \
  --start-time $(date -u -v-1H +%Y-%m-%dT%H:%M:%SZ) --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --period 300 --statistics Average Maximum --output table

• CLI se CPU ke data points ki table aa gayi.
• Tum samjha sakte ho ki memory ka metric default roop se kyun nahi milta.

PL-065 course se — asli console reference

CloudWatch metrics browse karna aur EC2 ke default CPU/network graphs dekhna.

Session Manager se deepdive-monitor ke andar jao aur agent install karo. Phir ek config file banao jo agent ko batati hai ki memory aur disk ke metrics bhejne hain aur nginx ke dono log files CloudWatch Logs mein bhejne hain. Aakhir mein agent ko is config ke saath chalu karo:

sudo dnf install -y amazon-cloudwatch-agent

sudo tee /opt/aws/amazon-cloudwatch-agent/etc/deepdive-agent.json > /dev/null <<'EOF'
{
  "agent": { "metrics_collection_interval": 60, "run_as_user": "root" },
  "metrics": {
    "namespace": "DeepDive/EC2",
    "append_dimensions": { "InstanceId": "${aws:InstanceId}" },
    "metrics_collected": {
      "mem":  { "measurement": ["mem_used_percent"] },
      "disk": { "measurement": ["used_percent"], "resources": ["/"], "drop_device": true }
    }
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          { "file_path": "/var/log/nginx/access.log", "log_group_name": "/deepdive/nginx/access",
            "log_stream_name": "{instance_id}", "retention_in_days": 7 },
          { "file_path": "/var/log/nginx/error.log",  "log_group_name": "/deepdive/nginx/error",
            "log_stream_name": "{instance_id}", "retention_in_days": 7 }
        ]
      }
    }
  }
}
EOF

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/etc/deepdive-agent.json
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a status

Heredoc mein 'EOF' ko quotes mein isliye likha gaya hai taaki shell ${aws:InstanceId} ko apna variable samajh ke khaali na kar de; is value ko agent khud instance ID se badalta hai. Agar kuch gadbad ho, toh agent ka log sudo tail -50 /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log se dekho.

• Agent ka status "status": "running" dikha raha hai.

Apne laptop se server pe kuch traffic bhejo, jisme normal pages bhi hon aur aise pages bhi jo maujood nahi hain (taaki 404 errors banein):

for i in $(seq 1 60); do
  curl -s -o /dev/null http://$IP/
  curl -s -o /dev/null http://$IP/missing-page-$((i % 5))
done

1. 2–3 minute baad CloudWatch mein Metrics kholo, Custom namespaces mein DeepDive/EC2 chuno, aur mem_used_percent aur disk_used_percent dekho.
2. CloudWatch mein Logs → Log groups kholo, /deepdive/nginx/access chuno, instance ID wali stream kholo aur nginx ki log lines dekho.

• DeepDive/EC2 namespace mein memory aur disk ke metrics aa gaye.
• Log group mein 200 aur 404, dono tarah ki lines dikh rahi hain.

CloudWatch mein Logs Insights kholo, log group /deepdive/nginx/access chuno, samay pichhla 1 ghanta rakho, aur yeh query chalao. Yeh har status code ki ginti batati hai:

parse @message '* - * [*] "* * *" * * "*" "*"' as ip, user, ts, method, path, proto, status, bytes, referer, agent
| stats count(*) as hits by status
| sort hits desc

Phir yeh query chalao, jo batati hai ki kaunse paths pe sabse zyada 404 aaye:

parse @message '* - * [*] "* * *" * * "*" "*"' as ip, user, ts, method, path, proto, status, bytes, referer, agent
| filter status = "404"
| stats count(*) as misses by path
| sort misses desc
| limit 10

parse command ek glob pattern ki madad se nginx ki "combined" format wali har log line ko tukdon mein todta hai, aur har tukde ko ek naam wala field bana deta hai. Real incidents mein sabse pehle yahi sawal poochhe jaate hain: kitne errors aaye, kab se aa rahe hain, kis endpoint pe aur kis IP se. Yeh queries bilkul inhi sawalon ka jawab deti hain.

• Pehli query mein 200 aur 404, dono ki ginti lagbhag 60-60 aayi.
• Doosri query mein /missing-page-0 se /missing-page-4 tak ke paths unki ginti ke saath aaye.

Logs pe seedha alarm nahi lagaya ja sakta. Pehle logs mein kisi pattern ko ek metric mein badla jaata hai, aur phir us metric pe alarm lagaya jaata hai. "5 minute mein 10 se zyada 404 ya 500 errors" jaise alerts isi tareeke se bante hain.

1. Log group /deepdive/nginx/access kholo, Actions mein Create metric filter chuno.
2. Filter pattern mein neeche wala pattern daalo. Yeh space se alag kiye gaye fields ko pehchanta hai, aur [] ya "" ke andar ke poore hisse ko ek hi field maanta hai:

[ip, ident, user, timestamp, request, status_code=404, bytes, referer, agent]

3. "Test pattern" se sample logs pe check karo ki sirf 404 wali lines match ho rahi hain, phir Next dabao. Filter ka naam nginx-404, metric namespace DeepDive/Nginx, metric ka naam NotFoundCount, metric value 1 aur default value 0 rakho, aur Create karo.
4. B2 wala traffic loop dobara chalao, kyunki metric filter sirf naye logs pe kaam karta hai, purane logs pe nahi.

• Test pattern ne sirf 404 wali lines ko match kiya.
• 2–3 minute baad DeepDive/Nginx ke NotFoundCount metric mein data points aa gaye.

Pehle alerts ke liye ek SNS topic banao aur usme apna email subscribe karo; email aane pe subscription confirm kar dena. Phir do alarms banao: ek jo CPU 70% se upar jaane pe bajta hai, aur ek jo 5 minute mein 20 se zyada 404 aane pe bajta hai:

TOPIC=$(aws sns create-topic --name deepdive-ops-alerts --query TopicArn --output text)
aws sns subscribe --topic-arn $TOPIC --protocol email --notification-endpoint you@example.com
# email confirm karo

aws cloudwatch put-metric-alarm --alarm-name deepdive-high-cpu \
  --namespace AWS/EC2 --metric-name CPUUtilization --dimensions Name=InstanceId,Value=$IID \
  --statistic Average --period 300 --evaluation-periods 1 --threshold 70 \
  --comparison-operator GreaterThanThreshold --treat-missing-data notBreaching \
  --alarm-actions $TOPIC --ok-actions $TOPIC

aws cloudwatch put-metric-alarm --alarm-name deepdive-many-404s \
  --namespace DeepDive/Nginx --metric-name NotFoundCount \
  --statistic Sum --period 300 --evaluation-periods 1 --threshold 20 \
  --comparison-operator GreaterThanThreshold --treat-missing-data notBreaching \
  --alarm-actions $TOPIC

• Dono alarms ban gaye; CPU wala alarm OK ya Insufficient data state mein hai.

PL-065 course se — asli console reference

Alarm create karna — metric, threshold, aur SNS topic notification ka wahi 3-step flow.

Session Manager ke shell mein neeche wali command chalao. Yeh har CPU core pe ek busy process chalati hai jo suraksha ke liye 15 minute baad khud band ho jaata hai:

for i in $(seq $(nproc)); do timeout 900 yes > /dev/null & done
top -b -n 1 | head -12        # yes processes ~100% CPU

Lagbhag 5–10 minute mein alarm ALARM state mein chala jaayega aur tumhe email aayega. Load khatam hone ke baad (ya pkill yes chalane ke baad) agle 5–10 minute mein alarm wapas OK ho jaayega aur doosra email aayega. Alarm ke History tab mein uski saari state changes dekho.

Ek baat yaad rakho: t2 aur t3 jaise burstable instances CPU credits pe chalte hain. 15 minute ke load ka free tier pe koi asar nahi padega, lekin ise ghanton tak mat chalana.

Isi beech B2 wala 404 loop do baar chalao; deepdive-many-404s alarm bhi ALARM mein jaayega aur email bhejega.

• "ALARM: deepdive-high-cpu" wala email aaya, aur baad mein "OK" wala email aaya.
• 404 wala alarm bhi baja.

PL-065 course se — asli console reference

Alarm actions mein Lambda/Auto Scaling/EC2 actions bhi milte hain.

Socho CPU bilkul theek chal raha hai, lekin orders zero aa rahe hain. Aise mein system ko "healthy" nahi kaha ja sakta. Isliye asli observability mein business metrics, jaise har minute ke orders, naye signups ya fail hue payments, sabse zaroori maane jaate hain. Inhe app khud PutMetricData se bhejta hai, ya logs mein Embedded Metric Format mein likhta hai.

Neeche wala loop paanch minute tak har 30 second mein ek random "orders" ki ginti bhejta hai:

for i in $(seq 1 10); do
  aws cloudwatch put-metric-data --namespace DeepDive/App --metric-name OrdersPlaced \
    --dimensions Env=dev --value $((RANDOM % 20)) --unit Count
  sleep 30
done

CloudWatch Metrics mein DeepDive/App → Env → OrdersPlaced kholo aur statistic Sum aur period 1 minute rakho. Custom metrics ka ek chhota monthly charge hota hai (free tier mein 10 custom metrics muft hain). Lab ke baad inka data 15 mahine mein apne aap khatam ho jaata hai; inhe delete karne ka koi option nahi hota.

• OrdersPlaced ke graph mein lagbhag 10 data points dikh rahe hain.

1. Billing and Cost Management mein Cost Explorer kholo. Agar tum ise pehli baar chalu kar rahe ho, toh data aane mein lagbhag 24 ghante lag sakte hain.
2. Date range mein is mahine ko chuno, granularity Daily rakho aur Service ke hisaab se group karo. Dekho ki kaunsi service sabse upar hai. Agar tumne Lab 4 kiya hai, toh shayad "EC2-Other" upar hoga, kyunki NAT Gateway aur EBS ka kharcha isi mein aata hai.
3. Ab Usage type ke hisaab se group karke dekho; wahan NatGateway-Hours aur PublicIPv4:InUseAddress jaise exact items dikhenge.
4. Forecast bhi dekho, jo mahine ke end tak ke kharche ka andaaza batata hai.

Agar tum Free plan ya credits pe ho, toh Billing mein Credits page pe bache hue credits dekho. Purane free-tier accounts ke liye Billing ka Free Tier page batata hai ki kaunsi service apni muft seema ke kitne paas hai.

• Tum un teen services ke naam bata sakte ho jinhone is mahine sabse zyada kharcha kiya.

PL-065 course se — asli console reference

Billing and Cost Management console — yahin se Cost Explorer khulta hai.

Socho ek company mein 50 teams ek hi account istemaal karti hain. "Kis project ne kitna kharcha kiya?" is sawal ka jawab tags se milta hai. Lekin koi tag billing reports mein tabhi dikhta hai jab use cost allocation tag ke roop mein activate kiya jaaye.

1. Billing mein Cost allocation tags kholo, User-defined tab mein Project tag select karo aur Activate dabao. Tag ko is list mein aane mein 24 ghante tak lag sakte hain; agar abhi na dikhe, toh kal kar lena.
2. Activate hone ke lagbhag 24 ghante baad Cost Explorer mein Tag: Project ke hisaab se group karke dekho.

• Project tag Active status mein hai, ya tumne ise kal karne ke liye note kar liya hai.

1. Budgets mein Lab 1 wala deepdive-monthly-5usd budget kholo aur uske alerts dekho. Agar usme sirf actual kharche ka alert hai, toh Edit karke ek naya alert jodo: Forecasted kharcha 100% se zyada hone pe email.
2. Optional ke taur pe ek naya budget banao: Customize → Cost budget mein $2 ka budget rakho aur Filters mein Tag Project = deepdive lagao (tag active hone ke baad). Isse sirf is course ka kharcha track hoga.

• Budget mein forecasted kharche wala alert maujood hai.

Kharcha kam karne ke do bade tareeke hain. Pehla hai right-sizing, yaani agar instance zaroorat se bada hai toh use chhota karna. Doosra hai commitment discounts, yaani Savings Plans ya Reserved Instances, jinme ek ya teen saal ke commitment pe lagbhag 30–70% ki chhoot milti hai. In dono ke liye AWS tumhare asli istemaal ke aadhar pe khud sujhaav deta hai.

Compute Optimizer ko chalu karo (yeh muft hai) aur uska status dekho. Sujhaav aane ke liye lagbhag 30 ghante ka data chahiye, isliye aakhri command kal chalana:

aws compute-optimizer update-enrollment-status --status Active       # free opt-in
aws compute-optimizer get-enrollment-status

# ~30 ghante ke metrics ke baad (kal dekhna):
aws compute-optimizer get-ec2-instance-recommendations \
  --query 'instanceRecommendations[].[instanceArn,finding,currentInstanceType,recommendationOptions[0].instanceType]' --output table

1. Billing and Cost Management mein Savings Plans → Recommendations kholo. Compute Savings Plans, 1 saal, No upfront aur pichhle 30 din ka lookback chuno, aur "estimated savings" padho.
2. Cost Explorer mein Reservations → Recommendations bhi dekho, jahan RDS aur ElastiCache ke liye Reserved Instances ke sujhaav hote hain.

• Compute Optimizer ka enrollment Active hai.
• Tumne Savings Plans ke sujhaav wala page dekha aur samjha ki woh kis istemaal pe aadharit hai.

Is step mein tum ek aisa budget banaoge jo seema paar hone pe, tumhari approval ke baad, ek test role pe "EC2 launch band karo" wali policy laga deta hai.

Pehle woh policy banao jo lagayi jaayegi, aur ek role banao jise Budgets service is kaam ke liye use karegi:

cat > deny-launch.json <<'EOF'
{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":["ec2:RunInstances","rds:CreateDBInstance"],"Resource":"*"}]}
EOF
aws iam create-policy --policy-name DeepdiveBudgetFreeze --policy-document file://deny-launch.json

cat > budgets-trust.json <<'EOF'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"budgets.amazonaws.com"},"Action":"sts:AssumeRole"}]}
EOF
aws iam create-role --role-name deepdive-budgets-action-role --assume-role-policy-document file://budgets-trust.json
aws iam attach-role-policy --role-name deepdive-budgets-action-role \
  --policy-arn arn:aws:iam::aws:policy/AWSBudgetsActionsWithAWSResourceControlAccess

1. Budgets mein Create budget → Customize → Cost budget chuno. Naam deepdive-freeze-test rakho, period Monthly aur fixed amount $0.01 rakho, aur Next dabao.
2. Alert threshold mein 100% of budgeted, Actual chuno aur email daalo, phir Next dabao. Attach actions mein IAM role deepdive-budgets-action-role chuno, action type Apply IAM policy chuno, policy DeepdiveBudgetFreeze chuno, target role mein Lab 1 wala test role deepdive-s3-reader chuno, Requires approval chuno aur Create karo.
3. Agar is mahine thoda bhi kharcha hua hai, toh kuch ghanton mein yeh budget paar ho jaayega, kyunki Budgets din mein kuch baar hisaab lagata hai. Tab budget ke Alerts mein action Pending dikhega. Run action dabao aur IAM mein check karo ki deepdive-s3-reader pe DeepdiveBudgetFreeze lag gayi. Phir Reverse action dabake use hata do.

• Budget action ban gaya hai aur uska status Standby ya Pending hai.
• Jab action trigger hua, toh Run action se policy lag gayi aur Reverse se hat gayi.

1. CloudTrail mein Event history kholo, lookup attribute mein Event name chuno aur RunInstances likho. Is lab mein launch kiya gaya instance dhoondho aur uska event kholo.
2. Event ka JSON dhyan se padho. userIdentity batata hai ki kaam kisne kiya (deepdive-admin, ya role ke case mein AssumedRole). eventTime batata hai kab kiya, sourceIPAddress batata hai kahan se kiya, aur userAgent batata hai kis tool se kiya (console, aws-cli ya boto3). requestParameters mein woh hota hai jo maanga gaya, responseElements mein AWS ka jawab, aur errorCode tab hota hai jab request fail hui ho.

CLI se bhi events dhoondhe ja sakte hain. Neeche ki pehli command haal hi mein bane alarms dikhati hai, aur doosri dikhati hai ki pichhle labs ke cleanup mein kisne kaunse buckets delete kiye:

aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=PutMetricAlarm \
  --max-results 5 --query 'Events[].[EventTime,Username,EventName]' --output table

# Kisne kya delete kiya (pichhle labs ka cleanup)?
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=DeleteBucket \
  --max-results 10 --query 'Events[].[EventTime,Username,Resources[0].ResourceName]' --output table

Console ke clicks aur CLI ki commands, dono ek jaise API events ki tarah record hote hain; Lab 1 ke step C2 mein kahi gayi baat yahan saabit hoti hai. Event history muft hai, lekin isme sirf pichhle 90 din ke aur sirf management events hote hain.

• Tumne RunInstances event mein userIdentity, sourceIPAddress aur userAgent pehchaane.
• CLI lookup ne alarms ke events dikhaye.

PL-065 course se — asli console reference

CloudTrail dashboard aur Event history — wahi console jahan tum investigation karoge.

ISO, SOC2 ya RBI guidelines jaise compliance niyamon ke liye audit logs ko saalon tak rakhna padta hai, aur unhe aisa hona chahiye ki koi unhe chupke se badal na sake. Ek trail events ko S3 mein likhta hai, aur chaaho toh CloudWatch Logs mein bhi, jahan unpe alarms lagaye ja sakte hain. Management events ki pehli copy muft hoti hai; sirf S3 storage ka thoda sa charge lagta hai.

1. CloudTrail mein Trails → Create trail kholo. Naam deepdive-trail rakho aur Create new S3 bucket chuno (default naam theek hai). Log file SSE-KMS encryption ka tick hata do, taaki KMS key ka monthly charge na lage; S3 ka default encryption phir bhi lagega. Log file validation ko Enabled rakho, CloudWatch Logs band rakho aur Next dabao.
2. Events mein sirf Management events chuno, Read aur Write dono rakho, Next dabao aur Create karo.
3. 5–15 minute baad bucket mein AWSLogs/<account>/CloudTrail/us-east-1/YYYY/MM/DD/*.json.gz jaise path pe files aane lagengi.

Neeche ke commands sabse nayi log file dhoondh ke download karte hain aur usme se har event ka samay, service aur naam print karte hain:

TRAIL_BUCKET=<trail bucket name>
KEY=$(aws s3api list-objects-v2 --bucket $TRAIL_BUCKET --prefix AWSLogs/$ACCOUNT_ID/CloudTrail/us-east-1/ \
  --query 'reverse(sort_by(Contents,&LastModified))[0].Key' --output text)
aws s3 cp s3://$TRAIL_BUCKET/$KEY - | gunzip | python3 -c \
  "import json,sys; [print(r['eventTime'], r['eventSource'], r['eventName']) for r in json.load(sys.stdin)['Records']]" | head -20

• Trail pe "Logging: On" dikh raha hai.
• S3 se download ki gayi log file se events print hue.

1. EC2 console mein deepdive-web-sg ke Inbound rules mein ek rule jodo: Custom TCP 3306 from 0.0.0.0/0, aur Save karo. Yeh ek galat kaam hai jo tum jaan-boojh ke kar rahe ho.
2. Ab ek detective ki tarah 2–5 minute baad neeche wali command chalao. Yeh security group mein rules jodne wale events dhoondh ke unka samay, karne wale ka ARN, IP aur request ki details dikhati hai:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AuthorizeSecurityGroupIngress \
  --max-results 3 --query 'Events[].CloudTrailEvent' --output json | python3 -c "
import json, sys
for raw in json.load(sys.stdin):
    e = json.loads(raw)
    print(e['eventTime'], e['userIdentity'].get('arn'), e['sourceIPAddress'])
    print(json.dumps(e['requestParameters'], indent=1)[:600])"

3. Ab woh rule wapas hata do. Isse bhi ek RevokeSecurityGroupIngress event banega; use bhi dhoondh ke dekho.

• Tumne pata laga liya ki kisne, kab, kis IP se, aur kaunsa port kiske liye khola.

PL-065 course se — asli console reference

Event ka poora JSON record aur lookup-attribute filter — 'kisne kya kiya' yahin milta hai.

1. CloudWatch mein Dashboards → Create dashboard kholo aur naam deepdive-ops rakho.
2. Ek Line widget jodo jisme AWS/EC2 ka CPUUtilization (deepdive-monitor ka) aur DeepDive/EC2 ka mem_used_percent, dono ek hi graph mein hon.
3. Ek Number widget jodo jo DeepDive/Nginx ka NotFoundCount (Sum, 5 minute) dikhaye.
4. Ek Alarm status widget jodo jisme deepdive-high-cpu, deepdive-many-404s aur deepdive-billing-over-5usd hon.
5. Ek Logs table widget jodo: Logs Insights mein C1 wali "status count" query chalao aur "Add to dashboard" dabao.
6. Ek Number widget jodo jo Billing ka Total Estimated Charge (USD) dikhaye. Dashboard us-east-1 mein hai, isliye yeh metric seedha mil jaayega.
7. Ek aur Line widget jodo jisme DeepDive/App ka OrdersPlaced ho, aur dashboard ko Save karo.

Dashboard mein Actions → View/edit source kholo; tumhe dikhega ki poora dashboard ek JSON hai. Is JSON ko Git mein rakh ke CloudFormation ya CDK se deploy kiya ja sakta hai, jise "dashboards-as-code" kehte hain. Teen dashboards tak muft hain.

• Ek hi screen pe infrastructure (CPU aur memory), app (404s aur orders), alarms, logs aur kharcha, sab dikh raha hai.

Tumhare ab tak ke saare alarms server ke andar ke metrics dekhte hain. Agar nginx band ho jaaye ya security group galat ho jaaye, toh CPU normal rahega aur koi alarm nahi bajega, jabki users ke liye site down ho chuki hogi. Synthetic monitoring is kami ko poora karti hai: ek script har minute bahar se site ko ek headless browser mein kholti hai, uska screenshot leti hai, aur fail hone pe alarm bajati hai. Iska kharcha lagbhag $0.0012 per run hai.

1. CloudWatch mein Application Signals → Synthetics Canaries → Create canary kholo aur Use a blueprint → Heartbeat monitoring chuno.
2. Naam deepdive-heartbeat rakho, Application endpoint mein http://<deepdive-monitor public IP>/ daalo, aur schedule mein Run continuously, every 1 minute chuno.
3. Data storage ke liye S3 bucket apne aap banne do, Access mein Create a new role chuno, aur CloudWatch alarms → Add new alarm mein ek alarm jodo jo SuccessPercent 90 se kam hone pe (5 minute ke 1 mein se 1 data point) SNS topic deepdive-ops-alerts pe bheje. Phir Create canary dabao.
4. 2–3 minute baad canary ke runs green dikhne lagenge; har run ka screenshot aur HAR file dekho.
5. Ab Session Manager se sudo systemctl stop nginx chalao. Agle runs red ho jaayenge ("net::ERR_CONNECTION_REFUSED"), aur lagbhag 5 minute mein alarm bajega aur email aayega. Phir sudo systemctl start nginx chalao aur runs dobara green hote dekho.

• Canary ke runs Passed hain aur screenshot mein DEEPDIVE ka page dikh raha hai.
• nginx band karne pe canary Failed hua aur alarm ka email aaya, aur nginx chalu karne pe sab wapas theek ho gaya.
• Tum samjha sakte ho ki CPU wala alarm is outage ko kyun nahi pakadta.