服务器状态查询工具使用方法及常见问题解决
凌晨三點，機房警報突然狂響。螢幕上十幾個節點閃著刺眼的紅，客戶的罵聲已經灌爆客服系統。我灌下第三杯黑咖啡，手指在鍵盤上飛舞，幾行命令砸進終端機，三秒後鎖定問題根源——又是邊緣節點被流量灌爆。這種生死時速的場面，服務器狀態查詢工具就是我的氧氣面罩。
這行幹了八年，見過太多人抱著監控平台當佛拜。其實那些花花綠綠的儀表板只是冰山尖，真正救命的往往是命令行裡老掉牙的工具。上個月某雲廠商大當機，全球儀表板全綠，反倒是工程師用 mtr 追出骨幹路由黑洞，比官方通告早兩小時示警。
▍骨灰級工具實戰手冊
當服務器抽風時，別急著重啟。先甩出 ping -t 連轟目標IP，看到底是斷氣還是喘不過來。要是回覆時間飆破500ms還瘋狂掉包，八成是線路擁塞或DDoS開打。某次幫電商查促銷日卡頓，ping 顯示正常，但用戶就是刷不出商品圖——原來是CDN節點的 TCP Window Size 被調殘了，這種陰險問題得祭出 tcptraceroute 才揪得出來。
▍進階玩家必殺技
遇到靈異斷線？mtr --report-wide 才是真神器。去年跨年夜，某直播平台崩潰，儀表板顯示全綠。我用 mtr 跑出亞太節點到美西的跳點，發現在LAX路由器瘋狂丟包。截圖扔給線路供應商，對方才承認海底光纜被漁船勾傷。更狠的招是 curl -vILk --path-as-is 暴力拆解HTTP狀態，有回客戶的API瘋狂回傳403，用這串指令才發現反向代理規則把 /v1/user/ 誤判成惡意路徑。
▍企業級血淚診斷術
跨國企業最怕BGP劫持。上週某銀行分行連不上總部，traceroute 顯示流量竟繞道俄羅斯。立刻啟動 bgp.he.net 查路由表，果然是ISP誤發佈路由宣告。還有DNS污染這毒瘤，用 dig +trace 逐層追查，曾抓出過內鬼在權威DNS偷加CNAME紀錄，把用戶導到釣魚網站。
▍死亡紅燈急救錦囊
工具再強也得懂底層邏輯。某次客戶的ELB持續503，儀表板顯示健康檢查全過，最後用 tcpdump 抓包才發現，健康檢查路徑的 /health 被WAF規則誤殺。這行玩久了，連HTTP狀態碼都能聞出火藥味——突然暴增的499絕對比500更致命，那是用戶等不及直接關頁面的死亡訊號。
評論: