1. 從零搭建 Elasticsearch 監(jiān)控體系為什么裸奔的集群遲早要出事剛接手一個(gè)搜索集群的時(shí)候我最怕看到的不是報(bào)錯(cuò)日志而是一切正常這四個(gè)字。因?yàn)?Elasticsearch 這東西它不像傳統(tǒng)數(shù)據(jù)庫(kù)那樣CPU 打滿了會(huì)立刻告警、連接數(shù)爆了會(huì)直接拒絕服務(wù)。它更像一個(gè)慢性病患者——今天寫(xiě)入慢一點(diǎn)明天查詢抖一下你覺(jué)得還能用等到某天早上打開(kāi) Kibana 發(fā)現(xiàn)索引變紅、分片分配失敗、節(jié)點(diǎn)掉出集群那基本就是 ICU 搶救的節(jié)奏了。elasticsearch-monitor這個(gè)項(xiàng)目說(shuō)白了就是給 ES 集群裝上一套體檢監(jiān)護(hù)系統(tǒng)。它要解決的核心問(wèn)題有三個(gè)第一讓你在集群還沒(méi)掛之前就知道它快撐不住了第二出問(wèn)題的時(shí)候能快速定位是哪個(gè)節(jié)點(diǎn)、哪個(gè)索引、哪類操作在搗鬼第三把歷史數(shù)據(jù)留下來(lái)方便做容量規(guī)劃和性能趨勢(shì)分析。適合誰(shuí)來(lái)參考如果你手頭維護(hù)著至少一個(gè) ES 集群不管是三節(jié)點(diǎn)的測(cè)試環(huán)境還是幾十個(gè)節(jié)點(diǎn)的大集群只要你不希望半夜被電話叫醒這套東西就值得花時(shí)間搭起來(lái)。我見(jiàn)過(guò)太多團(tuán)隊(duì)的做法是ES 部署完Kibana 能打開(kāi)就覺(jué)得監(jiān)控已經(jīng)有了。實(shí)際上 Kibana 自帶的 Monitoring 面板只能算體溫計(jì)它能告訴你發(fā)燒了但不會(huì)告訴你為什么發(fā)燒、該吃什么藥。真正要做的監(jiān)控體系得覆蓋指標(biāo)采集、日志聚合、告警規(guī)則、可視化看板、以及事后排查的完整鏈路。下面我就按自己實(shí)際搭建和踩坑的順序把整套東西拆開(kāi)講清楚。2. 監(jiān)控指標(biāo)到底該盯哪些別被幾百個(gè) metrics 晃花了眼2.1 集群級(jí)指標(biāo)先看大局有沒(méi)有崩ES 通過(guò)_cluster/health和_cluster/stats暴露的指標(biāo)有上百個(gè)但真正需要設(shè)置告警的我認(rèn)為不超過(guò)十五個(gè)。集群健康狀態(tài)status是最粗粒度的信號(hào)green/yellow/red 三檔但這里有個(gè)坑yellow 在很多單副本場(chǎng)景下是常態(tài)如果你把 yellow 直接設(shè)成告警運(yùn)維群會(huì)被轟炸到麻木。我的做法是yellow 持續(xù)超過(guò) 10 分鐘才觸發(fā)低優(yōu)先級(jí)通知red 則立即電話告警。分片相關(guān)指標(biāo)里unassigned_shards是最關(guān)鍵的。它一旦大于 0 且持續(xù)增長(zhǎng)說(shuō)明有分片分配不出去常見(jiàn)原因是磁盤(pán)水位線觸發(fā)、節(jié)點(diǎn)掉線、或者分片分配規(guī)則配置沖突。另一個(gè)容易被忽略的是initializing_shards和relocating_shards短時(shí)間有值是正常的但如果某個(gè)分片長(zhǎng)時(shí)間處于 initializing 狀態(tài)大概率是恢復(fù)過(guò)程卡住了需要人工介入。節(jié)點(diǎn)數(shù)量number_of_nodes和數(shù)據(jù)節(jié)點(diǎn)數(shù)量number_of_data_nodes要對(duì)比著看。如果兩者差值突然變大說(shuō)明有數(shù)據(jù)節(jié)點(diǎn)掉線但主節(jié)點(diǎn)還在這時(shí)候集群可能還能響應(yīng)但數(shù)據(jù)完整性已經(jīng)受威脅了。2.2 節(jié)點(diǎn)級(jí)指標(biāo)找出拖后腿的那一臺(tái)節(jié)點(diǎn)級(jí)指標(biāo)我重點(diǎn)關(guān)注四類JVM、磁盤(pán)、線程池、以及網(wǎng)絡(luò)。JVM 這塊heap_used_percent超過(guò) 75% 就要警惕超過(guò) 85% 基本離 OOM 不遠(yuǎn)了。但光看堆使用率不夠還要看 GC 情況。老年代 GC 頻率和耗時(shí)是更靈敏的指標(biāo)——如果 full GC 每分鐘超過(guò)一次或者單次耗時(shí)超過(guò) 1 秒說(shuō)明堆內(nèi)存已經(jīng)嚴(yán)重不足這時(shí)候調(diào)大堆或者優(yōu)化查詢才是正事重啟只能續(xù)命幾個(gè)小時(shí)。磁盤(pán)方面ES 默認(rèn)的低水位線是 85%高水位線是 90%。一旦某個(gè)節(jié)點(diǎn)磁盤(pán)使用率超過(guò) 85%ES 就不會(huì)再往這個(gè)節(jié)點(diǎn)分配新分片了超過(guò) 90%它會(huì)嘗試把現(xiàn)有分片遷走。所以磁盤(pán)告警閾值我一般設(shè)在 80%留出緩沖時(shí)間。這里有個(gè)經(jīng)驗(yàn)磁盤(pán)使用率的增長(zhǎng)往往不是線性的日志類索引在業(yè)務(wù)高峰期可能一天漲 10%所以容量規(guī)劃要按峰值算不能按平均值。線程池指標(biāo)里write和search兩個(gè)隊(duì)列的 rejected 數(shù)量是核心。rejected 大于 0 說(shuō)明線程池滿了請(qǐng)求被拒絕用戶側(cè)會(huì)直接感知到失敗。search隊(duì)列的 rejected 通常意味著查詢太慢或者并發(fā)太高write隊(duì)列的 rejected 則可能是批量寫(xiě)入過(guò)大或者磁盤(pán) IO 跟不上。2.3 索引級(jí)指標(biāo)定位到具體的問(wèn)題索引集群和節(jié)點(diǎn)都正常但業(yè)務(wù)方反饋搜索變慢了這時(shí)候就得下鉆到索引級(jí)別。我重點(diǎn)看三個(gè)指標(biāo)索引的search.query_total和search.query_time_in_millis的比值平均查詢耗時(shí)、indexing.index_total和indexing.index_time_in_millis的比值平均寫(xiě)入耗時(shí)、以及segments.count和segments.memory_in_bytes。平均查詢耗時(shí)突然飆升常見(jiàn)原因有某個(gè)大查詢打滿了緩存、分片數(shù)過(guò)多導(dǎo)致協(xié)調(diào)節(jié)點(diǎn)壓力大、或者有慢查詢?cè)谕虾笸?。平均?xiě)入耗時(shí)變長(zhǎng)可能是 refresh 頻率太高、translog 刷盤(pán)慢、或者 merge 壓力大。segments 數(shù)量過(guò)多單分片超過(guò) 50 個(gè)會(huì)導(dǎo)致查詢變慢因?yàn)槊總€(gè) segment 都要單獨(dú)搜索再合并結(jié)果。下面這張表是我在實(shí)際運(yùn)維中總結(jié)的指標(biāo)-閾值-動(dòng)作對(duì)照表可以直接拿去配告警指標(biāo)警告閾值嚴(yán)重閾值建議動(dòng)作cluster.statusyellow 持續(xù) 10minred檢查分片分配、節(jié)點(diǎn)狀態(tài)unassigned_shards 0 持續(xù) 5min 10檢查磁盤(pán)水位、分配規(guī)則heap_used_percent 75% 85%排查大查詢、考慮擴(kuò)容disk_used_percent 80% 85%清理舊索引、擴(kuò)容磁盤(pán)thread_pool.search.rejected 0 100/min優(yōu)化查詢、增加節(jié)點(diǎn)thread_pool.write.rejected 0 100/min降低批量大小、檢查磁盤(pán)index.search.avg_time 100ms 500ms分析慢查詢、優(yōu)化映射3. 采集方案選型Exporter、API 輪詢還是 Agent 直采3.1 三種采集方式的本質(zhì)區(qū)別給 ES 做監(jiān)控采集方式無(wú)非三種用現(xiàn)成的 exporter 拉指標(biāo)、自己寫(xiě)腳本輪詢 REST API、或者在每個(gè)節(jié)點(diǎn)上部署 agent 直接讀本地指標(biāo)。Exporter 方案最省事社區(qū)有成熟的 elasticsearch_exporter它通過(guò)調(diào)用 ES 的_nodes/stats、_cluster/health、_cluster/stats等接口把指標(biāo)轉(zhuǎn)成 Prometheus 格式暴露出來(lái)。優(yōu)點(diǎn)是開(kāi)箱即用指標(biāo)覆蓋全和 Prometheus 生態(tài)無(wú)縫集成。缺點(diǎn)是它只能看到 ES 主動(dòng)暴露的指標(biāo)像操作系統(tǒng)層面的 CPU、內(nèi)存、磁盤(pán) IO 這些拿不到而且如果 ES 集群本身響應(yīng)慢exporter 的采集也會(huì)超時(shí)。自己寫(xiě)腳本輪詢的好處是靈活你想采什么就采什么想怎么聚合就怎么聚合。比如你可以寫(xiě)個(gè) Python 腳本每 30 秒調(diào)一次_cat/indices把每個(gè)索引的文檔數(shù)、存儲(chǔ)大小、健康狀態(tài)存到自己的監(jiān)控庫(kù)里。但缺點(diǎn)是維護(hù)成本高ES 版本升級(jí)接口變了你得跟著改而且輪詢頻率高了會(huì)給集群增加額外負(fù)擔(dān)。Agent 直采適合對(duì)指標(biāo)精度要求高的場(chǎng)景。在每個(gè) ES 節(jié)點(diǎn)上跑一個(gè)輕量 agent直接讀/proc下的系統(tǒng)指標(biāo)同時(shí)通過(guò)本地回環(huán)調(diào)用 ES 的 API。這樣既能拿到系統(tǒng)層指標(biāo)又能避免網(wǎng)絡(luò)開(kāi)銷(xiāo)。但部署和升級(jí)麻煩節(jié)點(diǎn)多了之后 agent 的生命周期管理是個(gè)問(wèn)題。3.2 我為什么最終選了 Exporter 自定義腳本的組合純 exporter 方案有個(gè)硬傷它拿不到操作系統(tǒng)的磁盤(pán) IO 和網(wǎng)絡(luò)指標(biāo)而這兩個(gè)恰恰是排查 ES 性能問(wèn)題的重要線索。比如你發(fā)現(xiàn)寫(xiě)入變慢了如果只看 ES 的 indexing 指標(biāo)你只能知道慢了但不知道是磁盤(pán) IO 飽和了還是網(wǎng)絡(luò)帶寬打滿了。所以我的做法是用 exporter 采集 ES 自身的指標(biāo)用 node_exporter 采集系統(tǒng)指標(biāo)再寫(xiě)一個(gè)輕量腳本采集一些 exporter 不提供的業(yè)務(wù)指標(biāo)比如特定索引的文檔增長(zhǎng)速率。這里有個(gè)細(xì)節(jié)要注意exporter 的采集頻率不要設(shè)得太高。我見(jiàn)過(guò)有人設(shè)成 5 秒一次結(jié)果 exporter 自己成了集群的負(fù)載來(lái)源。ES 的_nodes/stats接口在節(jié)點(diǎn)多的時(shí)候響應(yīng)很慢頻繁調(diào)用會(huì)占用大量協(xié)調(diào)節(jié)點(diǎn)資源。我的經(jīng)驗(yàn)值是 30 秒一次對(duì)于大多數(shù)場(chǎng)景足夠了。如果確實(shí)需要更高精度可以針對(duì)關(guān)鍵指標(biāo)單獨(dú)提高頻率而不是全量拉取。3.3 采集端的資源隔離不管用哪種采集方式都要記住一個(gè)原則監(jiān)控系統(tǒng)本身不能成為被監(jiān)控系統(tǒng)的負(fù)擔(dān)。我一般會(huì)把 exporter 部署在獨(dú)立的監(jiān)控節(jié)點(diǎn)上不要和 ES 數(shù)據(jù)節(jié)點(diǎn)混部。如果資源實(shí)在緊張至少要給 exporter 設(shè)置 CPU 和內(nèi)存限制防止它失控。另外采集超時(shí)時(shí)間要設(shè)置合理。ES 集群在壓力大的時(shí)候API 響應(yīng)可能從幾十毫秒變成幾秒。如果 exporter 的超時(shí)設(shè)得太短會(huì)頻繁采集失敗導(dǎo)致監(jiān)控?cái)?shù)據(jù)出現(xiàn)空洞設(shè)得太長(zhǎng)又會(huì)拖慢整個(gè)采集周期。我的建議是超時(shí)時(shí)間設(shè)為采集間隔的三分之一左右比如 30 秒采集一次超時(shí)設(shè) 10 秒。4. 告警規(guī)則設(shè)計(jì)怎么做到既不漏報(bào)又不騷擾4.1 告警分級(jí)的核心邏輯告警設(shè)計(jì)最怕兩種極端一種是狼來(lái)了天天報(bào)警但都是誤報(bào)最后大家都不看了另一種是沉默的羔羊出大事了卻一聲不吭。要避免這兩種情況核心是做好分級(jí)。我把告警分成三級(jí)P0 是必須立即處理的比如集群 red、所有數(shù)據(jù)節(jié)點(diǎn)掉線、磁盤(pán)使用率超過(guò) 95%P1 是需要在工作時(shí)間內(nèi)處理的比如 yellow 持續(xù)超過(guò) 30 分鐘、堆使用率超過(guò) 85%、查詢拒絕率超過(guò) 1%P2 是記錄備查的比如單次查詢超時(shí)、segment 數(shù)量偏多。P0 走電話短信P1 走即時(shí)通訊工具P2 只寫(xiě)日志和看板。分級(jí)的關(guān)鍵在于持續(xù)時(shí)間這個(gè)維度。瞬時(shí)尖峰大多數(shù)時(shí)候是正常的比如業(yè)務(wù)高峰期查詢量突增導(dǎo)致隊(duì)列短暫排隊(duì)這不需要告警。但如果某個(gè)指標(biāo)持續(xù)超過(guò)閾值一段時(shí)間那就說(shuō)明系統(tǒng)真的有問(wèn)題了。我一般給 P0 設(shè)置 1 分鐘的持續(xù)時(shí)間P1 設(shè)置 5 分鐘P2 設(shè)置 15 分鐘。4.2 那些年我踩過(guò)的告警坑第一個(gè)坑是磁盤(pán)使用率告警風(fēng)暴。有段時(shí)間我們集群每天凌晨都會(huì)收到一堆磁盤(pán)告警查了半天發(fā)現(xiàn)是日志索引的定時(shí)滾動(dòng)任務(wù)在凌晨執(zhí)行滾動(dòng)瞬間會(huì)創(chuàng)建新索引導(dǎo)致磁盤(pán)使用率短暫上升。后來(lái)我把磁盤(pán)告警改成了預(yù)測(cè) 4 小時(shí)后會(huì)超過(guò)閾值才觸發(fā)而不是看當(dāng)前值。這個(gè)用 Prometheus 的predict_linear函數(shù)就能實(shí)現(xiàn)效果立竿見(jiàn)影。第二個(gè)坑是JVM 堆告警誤報(bào)。ES 的堆使用率是波動(dòng)的GC 之后會(huì)降下來(lái)GC 之前會(huì)升上去。如果只看瞬時(shí)值你會(huì)收到大量無(wú)意義的告警。正確的做法是看GC 后堆使用率或者看一段時(shí)間內(nèi)的平均值。Prometheus 里可以用avg_over_time來(lái)做平滑。第三個(gè)坑是分片告警漏報(bào)。我們?cè)?jīng)遇到過(guò)某個(gè)索引的主分片分配失敗但集群狀態(tài)還是 yellow因?yàn)楦北痉制钦５?。如果只監(jiān)控集群 status這個(gè)情況就漏掉了。后來(lái)我加了一條規(guī)則監(jiān)控unassigned_shards的變化率如果 5 分鐘內(nèi)從 0 變成大于 0就觸發(fā)告警不管集群狀態(tài)是什么顏色。4.3 告警收斂與靜默策略節(jié)點(diǎn)批量重啟或者滾動(dòng)升級(jí)的時(shí)候告警會(huì)集中爆發(fā)。這時(shí)候需要做告警收斂把同一時(shí)間窗口內(nèi)的同類告警合并成一條。Prometheus 的 Alertmanager 支持分組group_by和抑制inhibit規(guī)則可以把集群 red和節(jié)點(diǎn)掉線這兩類告警關(guān)聯(lián)起來(lái)只發(fā)一條根因告警。靜默策略也很重要。計(jì)劃內(nèi)的維護(hù)操作提前設(shè)置靜默窗口避免誤報(bào)。但靜默時(shí)間不要太長(zhǎng)我一般設(shè) 2 小時(shí)到期自動(dòng)恢復(fù)。如果維護(hù)沒(méi)做完手動(dòng)續(xù)期這樣能防止靜默了但忘了取消導(dǎo)致真正的問(wèn)題被掩蓋。5. 可視化看板讓數(shù)據(jù)自己說(shuō)話5.1 看板分層設(shè)計(jì)我習(xí)慣把 ES 監(jiān)控看板分成三層全局概覽、節(jié)點(diǎn)詳情、索引詳情。全局概覽放在最上面一屏之內(nèi)要能看到集群健康狀態(tài)、節(jié)點(diǎn)數(shù)量、分片總數(shù)、總文檔數(shù)、總存儲(chǔ)大小、當(dāng)前寫(xiě)入和查詢 QPS、以及最近 24 小時(shí)的告警數(shù)量。這一層是給值班人員看的目的是一眼判斷有沒(méi)有問(wèn)題。節(jié)點(diǎn)詳情層展示每個(gè)節(jié)點(diǎn)的 CPU、內(nèi)存、磁盤(pán)、JVM 堆、GC 次數(shù)、線程池隊(duì)列長(zhǎng)度。這一層是給運(yùn)維人員排查用的目的是定位到具體哪臺(tái)機(jī)器有問(wèn)題。索引詳情層展示每個(gè)索引的文檔數(shù)、存儲(chǔ)大小、查詢耗時(shí)、寫(xiě)入耗時(shí)、segment 數(shù)量。這一層是給開(kāi)發(fā)人員優(yōu)化用的目的是找到哪個(gè)索引拖慢了整體性能。5.2 那些容易被忽略但很有用的圖表除了常規(guī)的折線圖我強(qiáng)烈建議加幾個(gè)非典型圖表。第一個(gè)是分片分布熱力圖。用表格形式展示每個(gè)節(jié)點(diǎn)上的分片數(shù)量顏色越深表示分片越多。這個(gè)圖能快速發(fā)現(xiàn)分片分布不均的問(wèn)題。我曾經(jīng)遇到過(guò)一個(gè)節(jié)點(diǎn)上分了 200 多個(gè)分片而其他節(jié)點(diǎn)只有幾十個(gè)導(dǎo)致那個(gè)節(jié)點(diǎn)查詢特別慢。熱力圖一眼就能看出來(lái)。第二個(gè)是查詢耗時(shí) P99 曲線。平均值會(huì)騙人P99 才能反映真實(shí)用戶體驗(yàn)。如果 P99 突然飆升但平均值沒(méi)變說(shuō)明有少量請(qǐng)求遇到了嚴(yán)重延遲這往往是慢查詢或者 GC 導(dǎo)致的。第三個(gè)是索引增長(zhǎng)趨勢(shì)圖。把每天的索引存儲(chǔ)大小畫(huà)成曲線再疊加一條線性預(yù)測(cè)線能直觀看到什么時(shí)候會(huì)觸發(fā)磁盤(pán)水位線。這個(gè)圖對(duì)于容量規(guī)劃特別有用比看當(dāng)前使用率有價(jià)值得多。5.3 看板的性能優(yōu)化看板本身也會(huì)消耗資源。如果看板查詢的數(shù)據(jù)量太大每次刷新都會(huì)給 ES 造成壓力。我的做法是對(duì)于時(shí)間范圍超過(guò) 7 天的圖表使用預(yù)聚合數(shù)據(jù)比如 Prometheus 的 recording rules而不是直接查原始指標(biāo)。另外看板的自動(dòng)刷新間隔不要設(shè)得太短30 秒足夠了設(shè)成 5 秒除了讓屏幕閃得更快之外沒(méi)有任何實(shí)際意義。6. 從告警到定位一次真實(shí)的排查過(guò)程復(fù)盤(pán)6.1 問(wèn)題現(xiàn)象某天下午告警群收到一條 P1 告警集群查詢拒絕率超過(guò) 1%持續(xù) 5 分鐘。同時(shí)業(yè)務(wù)方反饋搜索接口偶爾超時(shí)。登錄看板一看thread_pool.search.rejected在幾分鐘內(nèi)從 0 漲到了 300 多search隊(duì)列長(zhǎng)度也滿了。6.2 排查鏈路第一步看集群和節(jié)點(diǎn)狀態(tài)。集群是 green所有節(jié)點(diǎn)都在線磁盤(pán)和 JVM 都正常。這說(shuō)明不是資源耗盡導(dǎo)致的。第二步看索引級(jí)別的查詢指標(biāo)。發(fā)現(xiàn)有一個(gè)索引的平均查詢耗時(shí)從平時(shí)的 20ms 漲到了 800msP99 更是超過(guò)了 5 秒。問(wèn)題定位到這個(gè)索引上。第三步看這個(gè)索引的 segment 數(shù)量。發(fā)現(xiàn)單分片的 segment 數(shù)量達(dá)到了 120 多個(gè)遠(yuǎn)超正常水平。segment 太多會(huì)導(dǎo)致查詢時(shí)需要遍歷大量小文件性能急劇下降。第四步查為什么 segment 沒(méi)有合并?？?merge 線程池的指標(biāo)發(fā)現(xiàn)thread_pool.force_merge隊(duì)列里有大量任務(wù)積壓。再查操作記錄發(fā)現(xiàn)前一天有人手動(dòng)觸發(fā)了一次全量 force merge但沒(méi)等它完成就下班了導(dǎo)致 merge 任務(wù)一直排隊(duì)新的寫(xiě)入又不斷產(chǎn)生新 segment形成了惡性循環(huán)。6.3 解決方案與后續(xù)預(yù)防當(dāng)時(shí)的緊急處理是先取消積壓的 force merge 任務(wù)讓 ES 自己按默認(rèn)策略做后臺(tái) merge。然后對(duì)那個(gè)索引做了一次滾動(dòng)重啟rollover把寫(xiě)入切到新索引舊索引不再寫(xiě)入后 segment 數(shù)量自然穩(wěn)定下來(lái)。最后對(duì)舊索引做了一次 force merge 到 1 個(gè) segment查詢耗時(shí)恢復(fù)到 15ms。后續(xù)預(yù)防措施有三條第一force merge 操作必須走審批流程且只能在業(yè)務(wù)低峰期執(zhí)行第二給 force merge 線程池的隊(duì)列長(zhǎng)度設(shè)置告警超過(guò) 10 就通知第三把 segment 數(shù)量納入日常巡檢指標(biāo)單分片超過(guò) 50 個(gè)就預(yù)警。這個(gè)案例告訴我們監(jiān)控不只是看有沒(méi)有掛更要看有沒(méi)有在變壞。很多故障不是突然發(fā)生的而是有一個(gè)漸進(jìn)的過(guò)程只是我們沒(méi)有在早期發(fā)現(xiàn)而已。7. 監(jiān)控系統(tǒng)自身的維護(hù)別讓保安先倒下監(jiān)控系統(tǒng)跑起來(lái)之后它自己也需要被監(jiān)控。我見(jiàn)過(guò)不止一次因?yàn)?exporter 掛了或者 Prometheus 磁盤(pán)滿了導(dǎo)致整個(gè)監(jiān)控體系失效而運(yùn)維人員渾然不知。最基本的要給監(jiān)控組件本身加上存活檢測(cè)。exporter 的/metrics接口如果連續(xù) 3 次采集失敗就觸發(fā)告警。Prometheus 的磁盤(pán)使用率也要監(jiān)控因?yàn)樗臄?shù)據(jù)是只增不減的默認(rèn)保留 15 天如果磁盤(pán)規(guī)劃不足很容易寫(xiě)滿。另外監(jiān)控?cái)?shù)據(jù)的保留策略要合理。ES 的指標(biāo)數(shù)據(jù)量很大如果全量保留一年存儲(chǔ)成本會(huì)很高。我的做法是原始指標(biāo)保留 15 天5 分鐘粒度的降采樣數(shù)據(jù)保留 90 天1 小時(shí)粒度的降采樣數(shù)據(jù)保留 1 年。這樣既能滿足短期排查需求又能支持長(zhǎng)期的趨勢(shì)分析。還有一個(gè)容易被忽略的點(diǎn)監(jiān)控配置的版本管理。告警規(guī)則、看板配置、采集配置這些都應(yīng)該納入版本控制。每次修改都要有記錄出問(wèn)題的時(shí)候可以快速回滾。我見(jiàn)過(guò)有人直接在 Grafana 界面上改看板改錯(cuò)了想恢復(fù)都找不到之前的版本只能憑記憶重建。最后分享一個(gè)我自己的小習(xí)慣每個(gè)月做一次監(jiān)控盲區(qū)檢查。具體做法是隨機(jī)挑一個(gè)歷史故障案例假設(shè)它現(xiàn)在重新發(fā)生看看現(xiàn)有的監(jiān)控體系能不能在 5 分鐘內(nèi)發(fā)現(xiàn)并定位。如果發(fā)現(xiàn)某個(gè)環(huán)節(jié)缺失就補(bǔ)上對(duì)應(yīng)的指標(biāo)或告警。這個(gè)習(xí)慣幫我堵住了不少漏洞推薦你也試試。