Grafana & Friends Taipei #2：從 TSMC 800 人的 war room，到每月 6 歐元的 homelab

中 #observability#grafana#kubernetes#community#taipei

在台北 5倍學院 舉辦的聚會。三場演講有一條共同的線索：收集 metrics 是容易的部分；難的是——你在失去訊號的當下，能不能發現自己失去了訊號。

TSMC：一場沒有任何告警看到的事故

Chuck(TSMC)講了「FAB99 X System Service Down」這個案例：同一天發生兩次中斷(08:30 與 15:30)，每次都超過 10 分鐘，war room 一度聚集了 約 800 人——這是該服務有史以來紀錄過的最高人數。

有趣的地方在於結局。Network、K8s、Infra 各自檢查了自己的 dashboard，什麼都沒找到(「不是我的問題」)。最終的 root cause 是：應用團隊的一個指標，根本沒有設定 alert rule。這個問題對所有人來說都是隱形的，因為它從來沒有出現在告警的雷達上。

他們自己總結出的教訓是：告警機制對已經設定好的部分確實有效，跨團隊的應變速度也很快，但噪音太多，而且系統之間完全沒有互相關聯——每個團隊都只盯著自己的 dashboard，沒有交叉比對資訊。

他們修復這個問題的路線圖，從自建一套採用 OTel Semantic Conventions 的觀測性 SDK 開始，一路到把 metrics、logs、traces 統一存進 ClickHouse 這個單一儲存後端，並在 Grafana 裡加入一個 AI agent，用來做自然語言搜尋、異常偵測(這原本就能抓到那個沒有告警的指標)，以及透過 trace_id 交叉比對訊號來做 root cause analysis。

一個因為 Java 技術棧而讓我特別在意的技術細節：在 Java 裡，OTel Agent 會透過 bytecode injection 自動做 instrumentation(JDBC、Redis、HTTP client 全部「免費」拿到);但 Go 沒有這種東西——每個 client 都得手動明確加上 instrumentation。

Edward Oo：CPU 用量 66%……但 steal 就佔了 62%

第二場演講是一個 homelab 的除錯案例，但適用於任何雲端 VM。CPU 告警觸發：使用率 66%。但拆解之後：steal 佔 62%，user 只佔 12%。這台 VM 根本沒拿到真正的 CPU 週期，因為 hypervisor 把週期都分給了另一台 VM(也就是所謂的 noisy neighbor)——kubectl top 只顯示 10% 的使用率，真正的健康狀況藏在 node_cpu_seconds_total{mode='steal'} 裡。

這場連鎖反應的惡毒之處相當「優雅」：PostgreSQL 剛好住在有 steal 問題的節點上，SSO 伺服器(authentik)則在另一個節點，每一次呼叫資料庫都得穿過帶 mTLS 的 overlay network，最後死在 timeout 上。結果：12 小時內重啟了 33 次，而且 Exit Code: 0——這些根本不是 crash，而是 liveness probe 因為資料庫沒有及時回應，直接把 pod 殺掉。修法：加一個 nodeSelector，把資料庫跟伺服器放在同一個節點上。之後重啟次數歸零。

他歸納的 5 條教訓，適用於任何虛擬化環境：

  1. CPU Usage ≠ CPU Steal——kubectl top 不會顯示 steal
  2. ExitCode 0 代表 probe 把它殺了，不是 app 自己 crash
  3. 把有狀態的 workload 放在同一個節點——Helm chart 預設不會幫你加 nodeSelector
  4. Cloudflare Proxy 不是萬用的——machine-to-machine 的流量不需要 CDN(這件事讓他花了 4 週才找出 remote_write 上一直默默出現的 403)
  5. 資料遺失不代表它真的消失了——vmctl backfill 從 Prometheus 本地的 TSDB 裡，在 15 分鐘內救回了 3.36 億筆 samples

他的技術棧是一個支持在小規模場景下選 VictoriaMetrics、而不是 Thanos/Mimir 的有力論證：單一 binary、記憶體用量不到 500MB、100% 相容 PromQL、原生支援 backfill。而整個可觀測性層都跑在另一台獨立的 VPS 上，每月成本約 6 歐元——就算 cluster 出了大問題，dashboard 依然能正常運作。

Blueswen：老鼠會咬線的 SRE 現場

Blueswen(Grafana Champion)以自己兩年在美國速食店 edge device 上做 SRE 的經驗作為壓軸——每間餐廳都有一台 edge server，透過 camera AI 把得來速(Drive Thru)轉換成 metrics。這種 edge「活在現場，不是活在機房」：用的是客戶端借來的網路、會停電、環境很熱，而且真的會有老鼠咬線。

我帶走的三個模式：

  • 網路斷線後的 backfill：agent 會先把資料緩衝到硬碟，等網路恢復後再重新傳送——但送過來的時間戳記是舊的(out-of-order)。如果 storage 沒有設定 out_of_order_time_window，這些指標會被默默丟棄。
  • 雙路徑的離線偵測：以 remote write 作為主要訊號，加上一個寫到 S3、用 Athena 查詢的 heartbeat 作為備援，兩者在同一條 alert rule 裡用 Grafana 11 的 SQL Expression 交叉比對。只有當兩條路徑都沒有訊號時，才會判定為離線——從此跟客戶端防火牆造成的 false positive 說再見。
  • Node Exporter 的 Textfile Collector，用來處理沒有 exporter 的指標：一個 cron + script，把資料寫成 Prometheus 格式的檔案，「順手」被收集起來，完全不動到既有的資料流。

聚會結尾的那句話總結了一切：在現場，難的從來不是收集 metrics，而是在失去訊號的當下，知道自己失去了訊號。