今天要來聊聊一個超經典的狀況。你的監控儀表板上面一片綠燈，看起來歲月靜好，但客服電話跟客訴信件快被打爆了，使用者一直說他們看到 502 錯誤頁面。真的，這種鳥事比系統直接掛掉還讓人頭痛。
如果你的監控跟你說「一切正常」，但使用者跟你說「完全不能用」，那你該相信誰？
重點一句話
你的監控系統可能在說謊。它沒看到問題，不代表問題不存在，很可能只是你看的頻率太慢，完美錯過了所有「案發現場」。
一個快把開發團隊逼瘋的故事
我最近就碰到一個幾乎一模一樣的案例。一個客戶的網站，架構很單純，Node.js 寫的後端、配個資料庫、前面用 Nginx擋著，全部跑在雲端主機上。沒什麼特別的，就是成千上萬公司都在用的標準組合。
但他們就是會隨機出現「502 Bad Gateway」或「503 Service Unavailable」的錯誤。很隨機，你完全抓不到規律。有時候是早上、有時候是半夜，沒有任何操作能保證重現這個問題。開發團隊查了 log，空的；看了 CPU、記憶體，全都正常得跟什麼一樣。真的快瘋了。
管理層的第一反應當然是：「你們的 code 是不是有 bug？」維運團隊也說：「應用程式問題，快修。」幾乎所有人都把矛頭指向開發者。
但我自己是覺得，當所有指標都「太完美」的時候，通常就代表有鬼。這就像你每個小時才檢查一次引擎溫度，你當然會錯過它在整點之間那短短五分鐘的過熱，然後又冷卻下來的過程。你的紀錄會顯示「一切正常」，但引擎其實已經在死亡邊緣走一遭了。
所以，問題到底在哪？那個兇手是誰？
我仔細去看那些 502 錯誤發生的時間點，發現它們雖然看似隨機，但好像都跟著流量有那麼一點點關係。不是那種流量高峰喔，那太明顯了，反而是那種流量稍微有點起伏、但圖表上根本看不出來的「小波浪」。
這時候我注意到一個關鍵：他們用的那套叫 Watchdog 的監控系統，抽樣頻率（sampling frequency）是...呃，每 5 分鐘一次。如果拉長看一整天的報表，頻率還會更低。
這問題就很大了。想像一下，你看一場電影，但每五分鐘才讓你瞥一眼畫面。你可能會看到主角一開始好好的，結尾也好好的，但中間那段超精彩的打鬥戲？你全部錯過了。
他們的監控就是這樣，只看得到風平浪靜的時刻，完全沒錄到中間那段「翻車」的過程。
用更高密度的監控抓出「快閃兇手」
我說服他們，讓我並行安裝另一套監控工具。這時候就要請出大神了，就是那個開源的 Prometheus。很多人可能不知道，在國外 SRE (網站可靠性工程師) 的世界裡，這幾乎是標配了。雖然我曉得台灣有些團隊可能還習慣用 Zabbix 或甚至自己寫的監控腳本，但碰到這種秒級的快閃問題，Prometheus 這種高頻率採樣的工具真的沒話說。
我把 Prometheus 的抽樣頻率設為每 15 秒一次，而不是原本的 5 分鐘。然後就放著讓它跑。
結果，不到三小時，真相大白。
實際發生的情況是這樣的：
- 流量只要稍微增加一點點，主機的可用記憶體就會在幾秒內瞬間被吃光。
- 記憶體用量會從平常的 40% 左右，直接飆到 95% 以上。
- 在這個狀態下，大概會持續 90 秒，主機根本無法處理新的連線請求，所以用戶就看到 502 錯誤。
- 然後，記憶體又突然被釋放，一切恢復正常。
整個災難從發生到結束，不到三分鐘。那個舊的、五分鐘才看一次的監控系統，當然每一次都完美錯過。
這下子，連應用程式日誌（application logs）為什麼都乾乾淨淨的，也有了解釋。因為請求根本就沒進到應用程式那一層！當伺服器因為沒記憶體而拒絕連線時，它在門口就把客人擋掉了，你的應用程式 code 連執行的機會都沒有，log 裡當然什麼都看不到。這就像一家餐廳客滿了，你連門都進不去，自然也沒辦法抱怨菜色難吃。
兩種監控思維，看到的世界完全不同
說真的，這就是思維上的差異，不只是工具設定而已。我整理了一下，讓你看懂這中間的差別有多大。
| 比較項目 | 傳統監控 (每 5 分鐘一次) | 高密度監控 (每 15 秒一次) |
|---|---|---|
| 看到的畫面 | 風平浪靜的平均值，看起來一切安好。是個「總結報告」。 | 充滿尖刺和波動的真實世界。是個「現場直播」。 |
| 能抓到的問題 | 那種持續好幾個小時的慢性病，比如記憶體緩慢洩漏。 | 幾十秒就結束的「快閃兇殺案」，像這次的記憶體暴增。 |
| 背後邏輯 | 「別佔用太多儲存空間」、「節省成本」，是以前伺服器很貴時的思維。 | 「我寧願多花點錢存 log，也不想漏掉任何一個錯誤」，這是現代雲端架構的思維。 |
| 造成的誤判 | 「儀表板是綠的，肯定是 code 有問題！」然後就開始究責大會... | 「看，就是這個 spike！問題在基礎設施層，跟應用程式無關。」可以快速定位。 |
| 給人的感覺 | 讓你覺得一切都在掌控中，但其實是個美麗的謊言。 | 可能會讓你有點焦慮，因為問題都被看到了，但至少這是真相。 |
怎麼做：一個超簡單的修正
tur一旦我們看清楚了問題的全貌，解決方法就簡單到有點好笑。
我們設定了「自動擴展 (auto-scaling)」。但關鍵是觸發條件。以前的設定是等到 CPU 或記憶體平均使用率超過 85% 才開始增加新的主機，但那時候早就來不及了。
新的設定是：只要偵測到記憶體用量碰到 70%，就立刻、馬上、毫不猶豫地增加新主機。我們還讓它增加主機的反應更積極一點。
結果？24 小時內，502 錯誤完全消失。開發團隊從背鍋俠變成了英雄。說真的，他們本來就沒錯，code 一直都是好的。
常見錯誤與誤解釐清
這個故事其實點出很多團隊都會犯的錯，不只是技術選擇而已，更多是心態上的問題。
- 誤解一：「儀表板一片綠燈就代表沒事。」 錯。綠燈只代表「在你檢查的那一秒」沒事。它完全沒告訴你兩次檢查之間發生了什麼。千萬要記得，使用者回報的問題，比你的儀表板更接近真相。
- 誤解二：「為了省錢，監控數據存粗一點、久一點就好。」 錯。在現代這種快速變動的雲端架構下，短時間的故障才是最常見、也最致命的。省那點硬碟或監控服務的錢，結果賠上好幾個禮拜的商譽和工程師時間，這帳怎麼算都不對。NIST (美國國家標準暨技術研究院) 就有報告提過，軟體錯誤造成的經濟損失是天文數字，提早發現絕對划算。
- 誤解三：「問題一定是應用程式的 bug。」 這大概是最大的誤解。就像這個例子，問題根本出在基礎設施層。一個好的 SRE 或 DevOps 文化，會從最底層（網路、硬體）一路往上查到最上層（使用者體驗），而不是預設就是誰的錯。
所以，你該怎麼檢查自家的監控？
如果你覺得這個故事聽起來有點熟悉，可以從幾個地方快速檢查一下，看看你家是不是也有「監控盲點」。
- 檢查你的抽樣頻率：這是最重要的。去看一下你監控系統的核心設定。你的 CPU、記憶體多久抓一次數據？一分鐘？五分鐘？如果是，那你就有很高的風險錯過問題。現在業界比較好的實踐，關鍵指標（像 application response time、error rates）至少要做到 15 秒甚至 10 秒以內。
- 警報設定看的是不是「平均值」：只在「過去一小時平均 CPU > 80%」時才告警，是個超級大的陷阱。你需要的是針對「P99 延遲」或「短時間錯誤率飆升」這類更敏感的指標來設定告警。也就是說，不要只關心平均表現，要去關心那些最慘的 1% 用戶碰到了什麼。
- 做個「消防演習」：在你的測試環境裡，故意寫個腳本讓記憶體或 CPU 瞬間飆高 30 秒，然後恢復正常。看看你的監控系統和告警能不能抓到它。如果抓不到，恭喜你，你找到了你的盲點，現在你知道該修哪裡了。
說到底，這整件事的核心就只有一個詞：可見性 (Visibility)。
你看不到問題，就不可能修好問題。這跟戴著眼罩修車沒兩樣。投資在好的、高密度的監控工具上，花的錢絕對比你花大把時間跟同事吵架、猜問題、安撫客戶來得值得。真的。
你碰過最扯的「儀表板說謊」事件是什麼？底下留言分享一下吧，讓大家知道自己不孤單，順便也讓我們學學你最後是怎麼抓到兇手的。
