佇列一旦超過 LANZ 門檻，留給處理的時間只剩毫秒等級。實測兩條接近線速的多播擠一個 10G 出口，約 2 ms 就碰到上限；總量只略超過 10G 的兩條廣播，也只要約 16 ms。這麼短的時間，值班人員來不及反應，每分鐘輪詢一次的監控也抓不到當下，microburst 告警只能拿來事後追查原因。門檻照這個用途分三級，只有丟包或頂到上限才即時通報；處置則是找出擠在哪個出口、是哪些群組，再決定要不要分流。

過門檻到丟包的時間

多播的 2 ms 是從 LANZ 的 U 紀錄讀的，每 80 µs 一筆，過門檻後 1.7～2.1 ms 就長到上限；廣播的 16 ms 是 E 那行記的最長佇列出現時間，它長得慢，過門檻 2 ms 時才到約 1170 segments。兩組差在超出出口的量，超出越多，佇列長得越快，留給處理的時間就越短。

門檻以下的 burst 不會留下紀錄，500 個的廣播 burst、每條 100 個的多播都是這樣。

門檻要從現場的基線來

實驗室量到的是測試流量在 LANZ 上的樣子，行情平常會堆多深要看現場，門檻得用現場的基線訂。每個出口每天記四個數：

開盤那幾分鐘跟盤中要分開算。 開盤的尖峰混進整天的數字，盤中的門檻會被拉高，盤中真正異常的 burst 就抓不到。

LANZ 的紀錄存在所有 port 共用的循環緩衝區，每個 port 至少保留 500 筆，舊的會被新的蓋掉，所以要持續收走。收法有兩種：定期匯出 CSV，或開 LANZ streaming 讓收集端透過 TCP 持續接收，這台兩種都支援。

告警分級

告警依影響程度分三級：

P1 只在交易時段即時通報，盤後同樣條件降為 P2，其他等級都留到上班時間，避免告警疲勞。

LANZ 也能送 syslog：queue-monitor length log <秒數> 開啟後，佇列過門檻就送一則，同一個 port 至少間隔設定的秒數才會再送，一次擁塞不會洗出一大串。判斷有沒有碰到上限，還是要看 LANZ 紀錄的最長佇列或 discards。

想看更小的 burst，可以調低接訂閱主機那個出口的門檻（queue-monitor length thresholds <high> <low>，預設 512／256）。代價是紀錄變多、循環緩衝區洗得更快，碰到上限的那筆可能先被蓋掉，收集頻率也要跟著提高。

P1 告警的處理流程

1. 確認影響範圍：從告警取得出口、時間點跟丟包數，比對同一時段的行情流量與應用端回報的資料缺口，確認受影響的群組跟下游系統。
2. 根因分析：LANZ 紀錄有 port、時間、佇列深度跟擁塞持續時間，但看不出是哪些群組在擠，得看封包。告警後才開 port mirror 只抓得到下一次，關鍵出口最好平時就常駐擷取。同時檢查那台主機的訂閱表跟 querier，querier 消失時，沒訂的群組也會灌進來。
3. 處置：同一個出口反覆丟包，把群組分散到不同的 port 或主機，或升級出口頻寬；偶發一次、延遲仍在預算內，就記入基線、不做變更。
4. 驗證與結案：處置後跟同時段基線比，擁塞次數跟最長佇列確實下降才結案，事件跟處置一起記錄，作為之後調整基線的依據。

明天看錯誤計數器的門檻怎麼從基線推出來。