站点运营里有一類問题最难處理：你發現站点打不開，不是從监控，而是從訪客留言或客服轉達。等有人来告诉你，故障已经持續了一段時間。可用性监控和告警的意义，就是把這個“發現”的動作從人換成机器，让問题在被更多人碰到之前先被记錄下来。
先确定要监控哪些地址
只监控首頁，只能說明服務器還在，不能說明站点可用。真正值得盯的是用戶和蜘蛛都會经過的那几條路径。
- 首頁，以及導航或投放中最重要的落地頁。
- 主要栏目列表頁，以及詳情頁模板各挑一個代表 URL。
- 登入、提交表單、站内搜尋等有交互的入口，至少驗證返回狀態和關键文本。
- robots.txt 與 XML 站点地图地址，它們出错會直接影响抓取。
挑選时尽量避開每次都會變化的内容頁，選相對稳定的地址。否則监控结果里會混進正常的 404，判断故障时反而更費劲。
從站外探测，而不是只看本机
在本机跑一個脚本去請求本机，服務器一宕机，脚本也跟着停了，你收不到任何消息。监控节点至少要放在站点之外，最好有两三個不同位置，避免單個探测点的網絡抖動被当成站点故障。
探测内容也不只是狀態碼。可以顺带检查頁面里是否出現预期的标题或某段關键文本，防止出現“返回 200 但内容其實是错誤頁”的情况。响應時間也值得记錄，它能帮你在頁面變慢但還没出错时提前發現压力。
告警怎么設定才不吵
告警太频繁，值班的人會開始忽略它，這比没有告警更糟。
- 設定连續失敗阈值，比如连續三次探测失敗再通知，過滤掉偶發抖動。
- 区分級別：宕机走电话或即时消息，响應變慢走邮件或工作群。
- 通知渠道要有人真正在看，不要發到一個没人回复的群。
- 同一問题在恢复前不要反复轰炸，做告警合並。
5xx 與抓取的關系
蜘蛛来訪时遇到 5xx，通常不會立刻把頁面從索引里删掉，但如果同一批地址持續返回错誤，抓取频率會下降，新内容被發現的時間也會往後拖。反過来，如果只是個別頁面报错，影响通常有限。所以监控里最好把 5xx 單獨統計出来，看它是集中在一段時間，還是零星分布。
要注意的是，不要為了“让蜘蛛看到正常頁面”而把错誤頁也返回 200。狀態碼必须和實际情况一致，否則後面排查問题會更难。
一份可执行的自查清單
- 列出五到十個监控地址，覆盖首頁、栏目、詳情、静態资源和 robots.txt。
- 確認探测点在站点外部，且不止一個位置。
- 检查告警通知的接收人，確認有人在值班时段能响應。
- 設定连續失敗阈值和静默期，避免單次抖動触發。
- 寫下收到告警後的處理步骤：先看什么、联系谁、要不要回滚。
- 每月回顾一次告警记錄，删掉長期誤报的規則，补上漏掉的地址。
常见誤区
只监控首頁、只用 ping 判断可用性、告警發出去没人認领，是三個最常见的坑。ping 通不代表 HTTP 正常，HTTP 200 也不代表頁面内容正确。另外，监控本身也會带来請求，如果地址選得太多、频率太高，反而會给服務器增加不必要的负担，選關键路径、拉開間隔就够了。
把它變成例行工作
可用性监控不需要一開始就很完整。先把首頁和两三個關键頁面接進来，跑上一两周，看告警是否准确，再逐步补充。真正有用的监控，是出問题时你能收到、收到後知道该做什么的那種，而不是仪表盘上好看的一排绿点。