Logs: The Program's 'Dashcam'
After launch you won't keep staring at the screen, but the program runs through the night all the same. Logs are the program's dashcam: as it works, it records "at this time I did this, and whether anything went wrong." When something happens, you replay the record to know what happened.
Logs usually come in levels: info (normal flow), warn (something's a bit off but it still runs), error (something went wrong). When there's a failure, the first thing to look for is error.
2026-06-20 03:14:07 INFO 用户下单成功 order=8821
2026-06-20 03:14:09 WARN 调用支付接口较慢 1200ms
2026-06-20 03:14:10 ERROR 调用支付接口失败：连接超时error is useless; include which step, what parameters, what went wrong.Alerts: Don't Wait for User Complaints to Learn It's Down
Logs alone aren't enough—logs are passive, you only see them when you remember to go look. Alerts are active: you set a rule, like "message me whenever an error appears," and the program proactively pokes you the moment something goes wrong.
The first alert a beginner should set is simple: whenever production logs an error, push it to me. Far earlier than a user complaining "your site won't open."
A Few Key Metrics + What to Check First When It Breaks
Don't watch dozens of metrics from the start—watch three first: error rate (how many of a hundred requests fail), response time (how long a user waits after clicking), and whether it's still alive (is the service online). When these three go abnormal, something's basically wrong.
When a failure comes, don't guess wildly—follow a basic order: first confirm it's still alive → check the recent error logs → see whether it was just changed/just deployed → then see when the key metrics started going bad.
自测 · 学完检查一下
想真正动手做题、记进度、攒连胜？到互动课里练。
Judge: after an app launches, the most reliable approach is for the programmer to keep staring at the screen to watch for errors.
答案：False
No one can stare at the screen forever. Production relies on logs (recording what happened) and alerts (proactively notifying on incidents), not human staring.
Which log entry helps you most when troubleshooting "why did the payment fail" after the fact?
答案：ERROR Payment API call failed: connection timeout order=8821
A useful log includes which step, which object, and what went wrong. Just writing "something went wrong" records nothing and leaves no clue.
What's the most fundamental difference between logs and alerts?
答案：Logs are passive and you have to go look; alerts are active and come notify you
Logs are like footage (replay after the fact); alerts are like a smoke detector (sounds the instant there's trouble). Alerts turn "you have to remember to look" into "it pokes you."
Judge: for a beginner, the first alert to set up is "whenever production logs an error, proactively push me a message."
答案：True
Notifying on error lets you find problems earlier than a user complaint—the highest-value first alert.
Production suddenly slows down and errors out; following the basic order in this lesson, which step should you confirm first?
答案：First confirm whether the service is still alive, then check the recent error logs
The troubleshooting order is: still alive? → check error logs → was it just changed/deployed → see when the metrics started going bad. Locate first, act after.
The most valuable follow-up question when troubleshooting is "did we just ____ something," because most production failures happen right after a deploy or change. (Fill in.)
答案：change
The vast majority of failures follow right after a change/deploy. Asking "what did we just touch" often pins down the cause in one step.