用Nagios監(jiān)控一臺(tái)服務(wù)器很簡單，直到基礎(chǔ)設(shè)施開始膨脹。Platform.sh（現(xiàn)Upsun）的工程師團(tuán)隊(duì)在過去幾年里三次推倒重來，才摸清大規(guī)模監(jiān)控的真正痛點(diǎn)。

第一次遷移：從單機(jī)腳本到分布式采集。早期用Nagios寫死配置，每臺(tái)新機(jī)器都要手動(dòng)加監(jiān)控項(xiàng)。VM數(shù)量過百后，配置管理成了噩夢。團(tuán)隊(duì)改用配置模板化，把"這臺(tái)機(jī)器跑什么服務(wù)"的定義從監(jiān)控系統(tǒng)中抽離，讓自動(dòng)擴(kuò)縮容時(shí)的監(jiān)控跟隨業(yè)務(wù)自動(dòng)生效。

第二次遷移：指標(biāo)與日志分家后的統(tǒng)一難題。Prometheus負(fù)責(zé)指標(biāo)，ELK堆棧管日志，Jaeger追鏈路——三套系統(tǒng)三個(gè)查詢語法，故障排查時(shí)要在三個(gè)界面來回跳轉(zhuǎn)。工程師的挫敗感直接體現(xiàn)在平均恢復(fù)時(shí)間（MTTR）上。這次重建的核心是把"可觀測性三支柱"塞進(jìn)同一個(gè)查詢層，用統(tǒng)一標(biāo)簽體系打通數(shù)據(jù)孤島。

第三次遷移：成本與精度的博弈。數(shù)千VM產(chǎn)生的數(shù)據(jù)量讓存儲(chǔ)成本指數(shù)級上漲。團(tuán)隊(duì)發(fā)現(xiàn)80%的指標(biāo)從未被查詢過，卻按同樣的精度保留90天。解決方案是分層采樣：核心服務(wù)秒級精度長期保留，邊緣服務(wù)分鐘級精度短期保留，查詢時(shí)再按需降采樣聚合。

三個(gè)反復(fù)出現(xiàn)的模式：一是配置即代碼，所有監(jiān)控規(guī)則進(jìn)Git，變更可審計(jì)可回滾；二是標(biāo)簽標(biāo)準(zhǔn)化，服務(wù)名、環(huán)境、版本號強(qiáng)制統(tǒng)一，否則跨系統(tǒng)關(guān)聯(lián)時(shí)字段對不上；三是漸進(jìn)式切換，新老體系并行跑兩周，指標(biāo)差異報(bào)警后再切流量，避免"大爆炸"遷移的凌晨驚魂。

最反直覺的教訓(xùn)：監(jiān)控系統(tǒng)的可靠性不能依賴被監(jiān)控的基礎(chǔ)設(shè)施。團(tuán)隊(duì)曾把監(jiān)控?cái)?shù)據(jù)庫放在業(yè)務(wù)K8s集群里，集群故障時(shí)監(jiān)控也跟著失聯(lián)——相當(dāng)于火災(zāi)時(shí)消防電話占線。第三次重建時(shí)，監(jiān)控棧獨(dú)立部署在隔離的故障域，甚至用了不同的云提供商。

從單臺(tái)Nagios到統(tǒng)一可觀測平臺(tái)，沒有銀彈。每次遷移的驅(qū)動(dòng)力都不是技術(shù)時(shí)髦，而是特定規(guī)模下的特定痛苦：配置爆炸、數(shù)據(jù)孤島、成本失控。下一次重建會(huì)是什么觸發(fā)？可能是AI生成的異常檢測規(guī)則，也可能是邊緣計(jì)算場景下的輕量級代理——但前提是真到了那個(gè)規(guī)模，真有那個(gè)痛點(diǎn)。