🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

📈 धडा 11 — Monitoring आणि troubleshooting: दोन status checks, दोन उपाय

📍 तुम्ही इथे आहात: 12 पैकी धडा 11 · मागील: lesson-10-load-balancing · पुढील: lesson-12-lifecycle

📦 या ब्रँचमध्ये काय आहे

धडे 01–10, आणि समस्या कोणाची आहे हे कसे ओळखायचे: system status check (AWS ची बाजू) विरुद्ध instance status check (तुमची बाजू), फुकट मिळणारे metrics विरुद्ध फक्त CloudWatch agent लाच दिसणारे metrics, ec2/fleet.py मधील fleet.credits() वरून बनवलेला CPUCreditBalance वरचा एक alarm, आणि "माझ्या डेस्कपर्यंत पोहोचता येत नाही" साठी troubleshooting चा छोटा नकाशा.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

प्रत्येक डेस्क दर मिनिटाला दोन वेगवेगळे निरीक्षक तपासतात.

इमारत निरीक्षक 🏗️ (system status check) डेस्कच्या खाली काय आहे ते पाहतो: फरशी, वीजेचा socket, network cable — कंपनीच्या मालकीच्या गोष्टी. ते नापास झाले तर डेस्कवर बसून तुम्ही काहीच दुरुस्त करू शकत नाही. तुम्ही डेस्क दुसऱ्या जागी हलवता (stop, मग start — डेस्क निरोगी hardware वर परत येतो).

डेस्क निरीक्षक 🔍 (instance status check) तुमचा डेस्क पाहतो: कोणी उत्तर देतेय का, ड्रॉवर इतका भरलाय का की काहीच उघडत नाही, कोणी settings बिघडवल्या का? हे दुरुस्त करणे तुमचे काम: restart करा, सुरू होताना डेस्कने काय छापले ते वाचा (console log), दुरुस्त करा.

आणि काही गोष्टी कोणत्याच निरीक्षकाला बाहेरून दिसत नाहीत — तुमचा ड्रॉवर किती भरलाय, तुमचे programs किती memory वापरतात. त्यांच्यासाठी तुम्ही डेस्कवर एक छोटा reporter ठेवता (CloudWatch agent) जो ते लिहून पाठवतो.

🗺️ आकृती

flowchart LR
    sys["❌ system status check<br/>AWS hardware, power, network under the desk"]
    inst["❌ instance status check<br/>your OS: full disk, bad config, kernel, memory"]
    fix1["⏹️ stop + start → new host<br/>or automatic recovery"]
    fix2["🔁 reboot · read the console log · fix the OS"]
    sys -->|"1 AWS's side"| fix1
    inst -->|"2 your side"| fix2
    free["📊 free every 5 min: CPU, network, disk I/O, CPUCreditBalance"]
    agent["🧾 CloudWatch agent: memory, disk space used, logs"]
    alarm["🔔 alarm: CPUCreditBalance below 50<br/>fires an hour before the throttle"]
    free -->|"3"| alarm
    agent -.->|"4 what the hypervisor cannot see"| alarm

🗺️ काढलेली आकृती + एक lab: https://school-edh.pages.dev/ec2/lesson-diagrams.html#l11

❓ काय

Status checks — दर मिनिटाला चालतात, प्रत्येक पास किंवा नापास होतो:
- System status check — instance ज्यावर चालतो ती AWS ची infrastructure (host hardware, वीज, network reachability). उपाय: stop आणि start (EBS-backed instances नव्या host वर जातात), किंवा automatic recovery / recover action असलेल्या CloudWatch alarm ला ते करू द्या.
- Instance status check — तुमची operating system आणि configuration (boot अयशस्वी, disk भरलेला, memory संपलेली, बिघडलेला network config). उपाय: reboot, मग get-console-output किंवा console screenshot वाचा, किंवा EC2 Serial Console वापरा (धडा 06).
- नवे instances त्यांना जोडलेल्या volumes साठी attached EBS status check देखील कळवतात.
CloudWatch metrics — CPUUtilization, network, disk I/O, StatusCheckFailed* आणि burstable types साठी CPUCreditBalance / CPUCreditUsage: दर 5 मिनिटांनी फुकट (basic monitoring) किंवा detailed monitoring (सशुल्क) सह दर 1 मिनिटाने.
Hypervisor ला काय दिसत नाही — memory वापर आणि वापरलेली disk space तुमच्या OS च्या आत असतात. CloudWatch agent install करा (तो log files सुद्धा पाठवू शकतो).
Alarms — एक metric, एक threshold, periods ची संख्या, आणि एक action (SNS notification, Auto Scaling policy, किंवा recover/reboot सारखा EC2 action). ज्यावर माणसाला कृती करावी लागते त्यावरच alarm लावा, कृती करता येईल इतक्या लवकर.
"पोहोचता येत नाही" नकाशा — timeout → SG, NACL, route table, public IP (धडा 05); connection refused → packet पोहोचला, पण कोणी ऐकत नाही (service बंद आहे किंवा दुसऱ्या port वर आहे); Permission denied (publickey) → चुकीचा user किंवा key (धडा 06); status checks नापास → हा धडा.
Scheduled events — AWS host retirement आणि maintenance ची आधीच घोषणा करतो; describe-instance-status त्यांची यादी देतो. त्या तारखेआधी stop/start केल्यास तुम्ही तुमच्या सोयीच्या वेळी हलता.

🤔 का

कारण incident चे पहिले मिनिट समस्या कोणाची आहे हे ठरवण्यात जाते — आणि तुम्ही terminal उघडण्याआधीच दोन status checks त्याचे उत्तर देतात. आणि कारण जे graphs तुम्ही गोळा केले नाहीत तेच तुम्हाला हवे असतात: memory आणि disk space ही आजारी डेस्कची दोन सर्वात सामान्य कारणे आहेत, आणि default ने यातले काहीच गोळा होत नाही.

🔧 कसे (या repo मध्ये)

ec2/demo.py मधील monitoring() दोन checks त्यांच्या उपायांसह छापते, काय फुकट गोळा होते आणि काय नाही ते सांगते, आणि मग धडा 02 मधला busy t3.micro run (fleet.credits(3)) पुन्हा वापरून CPUCreditBalance < 20 वरचा alarm कोणत्या तासाला वाजेल ते शोधते. खालचा snippet threshold 50 वर नेतो आणि पूर्ण भरलेल्या टाकीपासून सुरू करतो, म्हणजे throttle आधीच इशारा देणारा alarm दिसतो.

🧪 करून पाहा

python3 ec2/demo.py monitoring
python3 - <<'EOF'
import sys; sys.path.insert(0, "ec2"); import fleet
# a t3.micro at 40% on both vCPUs, starting with a full tank (288). When does CPUCreditBalance < 50 fire?
for h, bal, got in fleet.credits(9, busy_pct=40, start_balance=288):
    print(f"hour {h}: {bal:>5} credits · CPU {got}%{'  🔔 ALARM: CPUCreditBalance < 50' if bal < 50 else ''}")
EOF

खऱ्या account वर (AWS credentials लागतात; alarms साठी दर महिन्याला थोडा खर्च येतो — तुमचा स्वतःचा instance ID आणि SNS topic वापरा):

aws ec2 describe-instance-status --instance-ids i-0123456789abcdef0 --include-all-instances
aws ec2 get-console-output --instance-id i-0123456789abcdef0 --latest --output text
aws cloudwatch put-metric-alarm --alarm-name web-a-credits-low \
    --namespace AWS/EC2 --metric-name CPUCreditBalance \
    --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
    --statistic Average --period 300 --evaluation-periods 2 \
    --threshold 50 --comparison-operator LessThanThreshold \
    --alarm-actions arn:aws:sns:us-east-1:123456789012:school-oncall
aws cloudwatch put-metric-alarm --alarm-name web-a-system-check \
    --namespace AWS/EC2 --metric-name StatusCheckFailed_System \
    --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
    --statistic Maximum --period 60 --evaluation-periods 2 \
    --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
    --alarm-actions arn:aws:automate:us-east-1:ec2:recover

✅ तपासा — तुम्हाला काय दिसायला हवे

monitoring छापते ❌ system status check → AWS's hardware or network under your desk → stop + start (moves to a new host), ❌ instance status check → YOUR operating system (full disk, bad config, kernel) → reboot, read the console log, fix, memory आणि disk-space-used साठी CloudWatch agent लागतो ही सूचना, आणि 🔔 alarm idea: CPUCreditBalance < 20 → in the busy run above it fires from hour 2. तुमचा snippet दर तासाला 36 credits संपवतो — 252.0, 216.0, … — तास 7 ला 🔔 ALARM वाजतो (36.0 credits · CPU 40%), आणि फक्त तास 8 ला CPU 10% पर्यंत घसरतो (0.6 credits). Alarm ने तुम्हाला एक तास मिळवून दिला.

🏁 तुम्ही आत्ताच काय सिद्ध केले

AWS ची समस्या आणि तुमची समस्या तुम्ही एका नजरेत ओळखू शकता, कोणते आकडे फुकट मिळतात आणि कोणत्यांसाठी agent लागतो हे तुम्हाला माहीत आहे, आणि कृती करायला अजून वेळ असतानाच वाजणारा alarm तुम्ही लावला.

⚠️ नेहमीच्या चुका

system check नापास झाल्यावर reboot करणे — reboot त्याच host वर राहतो; त्याऐवजी stop आणि start करा
instance store वर data असलेला instance "दुरुस्त" करण्यासाठी stop करणे — खरडवही पुसली जाते (धडा 04)
disk भरण्याच्या दिवसापर्यंत memory किंवा disk-space metrics नसणे
प्रत्येक गोष्टीवर alarms, त्यामुळे कोणीच ते वाचत नाही — किंवा कशावरच नाही, त्यामुळे outage users कळवतात
instance तुमच्यासाठी stop होईपर्यंत scheduled retirement events कडे दुर्लक्ष करणे

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: एका सामान्य EC2 dashboard वर status checks, CPU, burstable types साठी credit balance, agent कडून memory आणि disk, आणि load balancer चा healthy-host count व 5xx rate असतात — ज्याला माणूस लागतो त्यावर page करणारे आणि ज्याला लागत नाही ते आपोआप recover करणारे alarms सह.

⏭️ पुढे

शेवटचा धडा: रात्रीची photocopy, सोनेरी साचा, आणि stop, hibernate आणि terminate खरोखर काय ठेवतात. Backup, patching आणि lifecycle.

git checkout lesson-12-lifecycle

📈 Lesson 11 — Monitoring & troubleshooting: two status checks, two fixes

📍 You are here: Lesson 11 of 12 · Previous: lesson-10-load-balancing · Next: lesson-12-lifecycle

📦 What's in this branch

Lessons 01–10, plus how to tell whose problem it is: the system status check (AWS's side) vs the instance status check (your side), the free metrics vs the ones only the CloudWatch agent can see, an alarm on CPUCreditBalance built from fleet.credits() in ec2/fleet.py, and a short troubleshooting map for "I cannot reach my desk".

🧒 Explain like I'm 5

Every desk is checked every minute by two different inspectors.

The building inspector 🏗️ (the system status check) looks at what is under the desk: the floor, the power socket, the network cable — things the company owns. If that fails, there is nothing you can fix on the desk. You move to a different desk spot (stop, then start — the desk comes back on healthy hardware).

The desk inspector 🔍 (the instance status check) looks at your desk: is anyone answering, is the drawer so full nothing opens, did someone break the settings? That one is yours to fix: restart, read what the desk printed while starting up (the console log), repair.

And some things neither inspector can see from outside — how full your drawer is, how much memory your programs use. For those, you put a small reporter on the desk (the CloudWatch agent) that writes them down.

🗺️ Diagram

flowchart LR
    sys["❌ system status check<br/>AWS hardware, power, network under the desk"]
    inst["❌ instance status check<br/>your OS: full disk, bad config, kernel, memory"]
    fix1["⏹️ stop + start → new host<br/>or automatic recovery"]
    fix2["🔁 reboot · read the console log · fix the OS"]
    sys -->|"1 AWS's side"| fix1
    inst -->|"2 your side"| fix2
    free["📊 free every 5 min: CPU, network, disk I/O, CPUCreditBalance"]
    agent["🧾 CloudWatch agent: memory, disk space used, logs"]
    alarm["🔔 alarm: CPUCreditBalance below 50<br/>fires an hour before the throttle"]
    free -->|"3"| alarm
    agent -.->|"4 what the hypervisor cannot see"| alarm

🗺️ Drawn version + a lab: https://school-edh.pages.dev/ec2/lesson-diagrams.html#l11

❓ What

Status checks — run every minute, each passing or failing:
- System status check — the AWS infrastructure the instance runs on (host hardware, power, network reachability). Fix: stop and start (EBS-backed instances move to a new host), or let automatic recovery / a CloudWatch alarm with the recover action do it.
- Instance status check — your operating system and configuration (failed boot, full disk, exhausted memory, broken network config). Fix: reboot, then read get-console-output or a console screenshot, or use the EC2 Serial Console (lesson 06).
- Newer instances also report an attached EBS status check for the volumes attached to them.
CloudWatch metrics — CPUUtilization, network, disk I/O, StatusCheckFailed* and, for burstable types, CPUCreditBalance / CPUCreditUsage: free every 5 minutes (basic monitoring) or every 1 minute with detailed monitoring (paid).
What the hypervisor cannot see — memory use and disk space used live inside your OS. Install the CloudWatch agent (it can also ship log files).
Alarms — a metric, a threshold, a number of periods, and an action (SNS notification, an Auto Scaling policy, or an EC2 action like recover/reboot). Alarm on what a human must act on, early enough to act.
"I cannot reach it" map — a timeout → SG, NACL, route table, public IP (lesson 05); connection refused → the packet arrived, nothing listening (the service is down or on another port); Permission denied (publickey) → wrong user or key (lesson 06); status checks failing → this lesson.
Scheduled events — AWS announces host retirement and maintenance ahead of time; describe-instance-status lists them. A stop/start before the date moves you on your own schedule.

🤔 Why

Because the first minute of an incident is spent deciding whose problem it is — and the two status checks answer that before you open a terminal. And because the graphs you did not collect are the ones you need: memory and disk space are the two most common causes of a sick desk, and neither is collected by default.

🔧 How (in this repo)

monitoring() in ec2/demo.py prints the two checks with their fixes, what is and is not collected for free, and then reuses the busy t3.micro run from lesson 02 (fleet.credits(3)) to find the hour an alarm on CPUCreditBalance < 20 would fire. The snippet below moves the threshold to 50 and starts from a full tank, to show an alarm that gives you warning before the throttle.

🧪 Try it

python3 ec2/demo.py monitoring
python3 - <<'EOF'
import sys; sys.path.insert(0, "ec2"); import fleet
# a t3.micro at 40% on both vCPUs, starting with a full tank (288). When does CPUCreditBalance < 50 fire?
for h, bal, got in fleet.credits(9, busy_pct=40, start_balance=288):
    print(f"hour {h}: {bal:>5} credits · CPU {got}%{'  🔔 ALARM: CPUCreditBalance < 50' if bal < 50 else ''}")
EOF

On a real account (needs AWS credentials; alarms cost a little each month — use your own instance ID and SNS topic):

aws ec2 describe-instance-status --instance-ids i-0123456789abcdef0 --include-all-instances
aws ec2 get-console-output --instance-id i-0123456789abcdef0 --latest --output text
aws cloudwatch put-metric-alarm --alarm-name web-a-credits-low \
    --namespace AWS/EC2 --metric-name CPUCreditBalance \
    --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
    --statistic Average --period 300 --evaluation-periods 2 \
    --threshold 50 --comparison-operator LessThanThreshold \
    --alarm-actions arn:aws:sns:us-east-1:123456789012:school-oncall
aws cloudwatch put-metric-alarm --alarm-name web-a-system-check \
    --namespace AWS/EC2 --metric-name StatusCheckFailed_System \
    --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
    --statistic Maximum --period 60 --evaluation-periods 2 \
    --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
    --alarm-actions arn:aws:automate:us-east-1:ec2:recover

✅ Verify — what you should see

monitoring prints ❌ system status check → AWS's hardware or network under your desk → stop + start (moves to a new host), ❌ instance status check → YOUR operating system (full disk, bad config, kernel) → reboot, read the console log, fix, the note that memory and disk-space-used need the CloudWatch agent, and 🔔 alarm idea: CPUCreditBalance < 20 → in the busy run above it fires from hour 2. Your snippet drains 36 credits an hour — 252.0, 216.0, … — fires 🔔 ALARM at hour 7 (36.0 credits · CPU 40%), and only at hour 8 does the CPU fall to 10% (0.6 credits). The alarm bought you an hour.

🏁 What you just proved

You can tell AWS's problem from yours in one glance, you know which numbers you get for free and which need an agent, and you set an alarm that fires while there is still time to act.

⚠️ Common mistakes

rebooting for a failed system check — a reboot stays on the same host; stop and start instead
stopping an instance with data on instance store to "fix" it — the scratch pad is wiped (lesson 04)
no memory or disk-space metrics until the day the disk fills
alarms on everything, so nobody reads them — or on nothing, so users report the outage
ignoring scheduled retirement events until the instance is stopped for you

🏭 Why this matters in production: a standard EC2 dashboard has status checks, CPU, credit balance for burstable types, memory and disk from the agent, and the load balancer's healthy-host count and 5xx rate — with alarms that page on what needs a human and auto-recover what does not.

⏭️ Next

Last lesson: the nightly photocopy, the golden template, and what stop, hibernate and terminate really keep. Backup, patching and lifecycle.

git checkout lesson-12-lifecycle

← Previousload balancing Next →lifecycle

This page is the lesson's README from the lesson-11-monitoring branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.