服務器凌晨2點40分告警群突然彈出一條消息某業(yè)務節(jié)點load average連續(xù)15分鐘超過8。大半夜爬起來看監(jiān)控面板CPU使用率明明只有60%內存也沒滿磁盤I/O看著還正常但load就是降不下來。這種場景干過運維的都懂——監(jiān)控指標永遠不是缺數(shù)據(jù)而是數(shù)據(jù)太多了關鍵是你得知道哪些數(shù)據(jù)能信、哪些數(shù)據(jù)該怎么組合著看。這篇東西就是把我在Linux系統(tǒng)指標監(jiān)控這條路上踩過的坑、總結過的判斷邏輯、沉淀下來的排查套路一次性梳理清楚。適合剛接手Linux運維的初學者也適合那些已經(jīng)有兩年左右經(jīng)驗、但每次出問題還是靠猜的同行?？赐昴隳芨忝靼兹轮笜吮澈蟮降资鞘裁?、哪些指標組合起來才能還原真實故障、以及遇到異常時用什么順序去查才不白忙活。1. 監(jiān)控的本質讀懂內核給你留下的“體檢報告”很多人用top看CPU、用free看內存用壞了也沒想過一個問題這些數(shù)字到底從哪來的搞懂這一點后面所有的排查思路都會順很多。1.1 一切指標都來自兩個虛擬文件系統(tǒng)Linux里有個說法叫“一切皆文件”系統(tǒng)指標也一樣。你敲top看到的那些數(shù)據(jù)本質上都是內核實時把系統(tǒng)狀態(tài)寫入/proc和/sys這兩個虛擬文件系統(tǒng)里然后再由工具去讀取、計算、格式化展示給你。舉幾個最常用的/proc/statCPU總使用率、各核使用率、上下文切換次數(shù)、開機時間全在這里。/proc/meminfo內存總量、空閑量、緩存量、Swap用量free命令顯示的原始數(shù)據(jù)源。/proc/loadavg1分鐘、5分鐘、15分鐘的負載均值load average三兄弟的老家。/proc/pid/status某個進程的內存占用、線程數(shù)、狀態(tài)排查單進程問題時首查。/proc/diskstats每塊磁盤的讀寫次數(shù)、讀寫扇區(qū)數(shù)、I/O耗時iostat的底層數(shù)據(jù)源。/sys/block/設備/stat新一代磁盤I/O統(tǒng)計接口很多新工具基于它。所以當監(jiān)控數(shù)據(jù)出現(xiàn)異常時第一步永遠不是懷疑工具而是直接看原始文件。比如top顯示的CPU使用率和你預期不符那就cat /proc/stat算一遍比如內存明明顯示還有幾個G卻觸發(fā)OOM那就看/proc/meminfo里available和free的差值。技巧養(yǎng)成直接讀/proc的習慣。監(jiān)控工具可能因為采樣間隔、計算方式、版本差異給你不同的數(shù)字但內核不會騙人。排查到后期所有爭論最后都要回到原始文件上裁決。1.2 指標監(jiān)控的正確打開方式看趨勢別盯瞬時值我剛做運維那會兒服務器一告警就沖上去跑top盯著刷新那個瞬間的數(shù)字猜問題。后來被師傅罵了一頓才明白瞬時值只能告訴你“現(xiàn)在有異?！钡嬖V不了你“異常是從什么時候開始的”“持續(xù)了多久”“是在變好還是惡化”。而這些才是定位問題的關鍵線索。量化地說一次合格的故障排查至少要還原出異常前15分鐘到異常出現(xiàn)后30分鐘的指標曲線。沒有歷史數(shù)據(jù)的情況下你只能靠猜有趨勢數(shù)據(jù)你可以直接看拐點。拐點對應的往往就是變更操作比如發(fā)布、擴容、配置修改。所以無論用商業(yè)監(jiān)控平臺、開源監(jiān)控系統(tǒng)還是命令行工具一定要讓數(shù)據(jù)有“時間維度”。單看top那一刻的值意義非常有限。2. CPU指標拆解load average與CPU使用率兩個最容易混淆的指標CPU這塊是運維面試和實操中最愛考、也最容易出誤會的地方。核心就三個概念load average、CPU使用率、上下文切換。把它們徹底分開看CPU問題就解決了一半。2.1 load average到底算的是什么很多人把load average當成CPU使用率看這是最大的誤區(qū)。load average在Linux里表示的是系統(tǒng)中處于可運行狀態(tài)和不可中斷睡眠狀態(tài)的進程平均數(shù)。直白點說它不僅統(tǒng)計了正在用CPU的進程還把等待I/O的進程也算了進去。這就是為什么磁盤卡住、網(wǎng)絡文件系統(tǒng)掛起時哪怕CPU閑著load也能飆升到幾十。/proc/loadavg里的三個數(shù)字分別代表1分鐘、5分鐘、15分鐘的平均負載。判斷系統(tǒng)是否過載不能只看1分鐘值要看15分鐘值是否在持續(xù)上升以及三個值的相對關系1分鐘 5分鐘 15分鐘負載正在上升需要關注。1分鐘 5分鐘 15分鐘負載正在下降說明之前的壓力已經(jīng)在緩解。三個值都比較高且接近系統(tǒng)已經(jīng)持續(xù)高負載運行屬于穩(wěn)態(tài)過載。至于多高算高不是拍腦袋定閾值而是拿CPU核數(shù)做參考load高于核數(shù)說明有進程在排隊低于核數(shù)說明CPU資源尚有富余。一臺4核機器load到8那排隊情況已經(jīng)很嚴重了一臺64核機器load到8可能還在健康區(qū)間。2.2 從/proc/stat理解CPU時間片CPU使用率的計算邏輯比很多人想象中復雜因為Linux的CPU是分時復用的每個核在一秒內會交替執(zhí)行用戶態(tài)代碼、內核態(tài)代碼、處理中斷、進入IO等待剩下的時間才閑著。看/proc/stat的前幾行CPU那一行的數(shù)字從左到右分別對應user用戶態(tài)時間、nice低優(yōu)先級用戶態(tài)時間、system內核態(tài)時間、idle空閑時間、iowaitIO等待時間、irq硬中斷時間、softirq軟中斷時間、steal被虛擬機管理程序搶占的時間。top里的us、sy、wa、st就是這么來的us高用戶態(tài)程序在密集計算比如Java應用跑滿GC、Python腳本死循環(huán)、大量正則匹配。sy高內核態(tài)時間占比大多半是系統(tǒng)調用頻繁常見于大量文件讀寫、網(wǎng)絡收發(fā)、或進程頻繁創(chuàng)建銷毀。wa高CPU在等磁盤I/O返回這是磁盤性能瓶頸的典型信號但SSD時代要結合await細節(jié)看后面會單獨說。st高虛擬化場景下宿主機在搶CPU資源云服務器上出現(xiàn)st走高往往是鄰居VM在拼命。注意如果你用云服務器看到CPU使用率不高但業(yè)務很卡先查st。很多云廠商的監(jiān)控面板看不到steal值得上機器敲top按數(shù)字1展開每個核的狀態(tài)。2.3 上下文切換被忽視的CPU隱性殺手上下文切換cs可以理解為CPU在多個進程/線程之間來回切換的開銷。切換本身不干任何實際工作純粹是“換人的成本”。排查這個問題的完整鏈路是這樣的先用top看整體cs值如果常年每秒幾十萬次一定有問題。用vmstat 1觀察cs列同時看r運行隊列和b阻塞進程判斷切換是不是因為線程太多導致的。用pidstat -w 1定位到具體進程看哪個進程的cswch自愿上下文切換和nvcswch非自愿上下文切換在飆升。如果是nvcswch高說明進程在等待時間片CPU不夠用如果是cswch高且伴隨大量線程創(chuàng)建多半是編程層面的問題比如線程池無腦開線程、協(xié)程調度異常。我處理過最典型的一個案例某Java服務的線程數(shù)從200慢慢漲到8000上下文切換每秒上百萬次但每個核的CPU使用率都不高。業(yè)務表現(xiàn)為接口響應越來越慢排查了半天根因是消息隊列消費邏輯里一個鎖等待導致線程大量阻塞阻塞線程又不斷重試把CPU時間全耗在線程切換上了。3. 內存、磁盤與網(wǎng)絡三個容易被誤讀的指標CPU只是性能問題的冰山一角。內存、磁盤、網(wǎng)絡這三個模塊的指標讀法坑更多。3.1 free命令的正確用法available才是真正能用的內存看內存第一反應用free -h這一步?jīng)]錯但錯就錯在很多人盯著free這一列看。free列顯示的是“完全空閑的物理內存”而Linux對內存的使用策略是“能用就絕不閑著”——空閑內存會被用來做文件緩存buff/cache下次讀文件直接命中緩存能快好幾個數(shù)量級。真正需要關注的是available這一列。它表示“在不觸發(fā)Swap的情況下還能分配給新進程的內存量”包含了可回收的緩存部分。free低不是問題available長期為0才是問題。跟內存相關的常見誤判有幾個只看free不看available一臺free只有200M但available還有8G的機器運行狀態(tài)可能是完全健康的。Swap一用就慌Swap并非洪水猛獸少量使用說明內存吃緊但還能扛。真正要警惕的是Swap持續(xù)走高且伴隨頻繁的swap in/out用vmstat 1看si、so列這代表物理內存已經(jīng)耗盡系統(tǒng)在靠磁盤硬撐性能會斷崖式下跌。忽略內存的分配趨勢用/proc/meminfo里的MemAvailable字段畫趨勢線比看任何監(jiān)控面板的瞬時值都有用。排查內存問題還有一個利器ps aux --sort-rss | head -20按物理內存占用排序一分鐘內就能找到內存大戶。再進一步用pmap -x 進程號看某個進程內部各段內存的分布能定位到是堆內存還是棧內存還是映射文件撐爆的。3.2 磁盤I/OSSD時代iowait還可靠嗎以前機械硬盤時代磁盤慢CPU等磁盤導致wa飆升這個指針很好用?，F(xiàn)在SSD普及了磁盤快了很多iowait作為瓶頸信號的靈敏度也下降了——因為磁盤響應已經(jīng)快到CPU基本等不到它。判斷磁盤是不是瓶頸我現(xiàn)在的完整套路是三步iostat -x 1看每塊盤的%util。這個值的含義是磁盤設備忙的時間占比理論上100%就是極限但注意SSD有并行處理能力util到100%不代表性能到頂要看實際的IOPS和帶寬是否達到硬盤規(guī)格上限?？碼wait平均I/O響應時間。機械盤await明顯超過20ms就有問題了SSD應該穩(wěn)定在個位數(shù)毫秒。如果await高但util不高說明單個I/O處理慢可能是磁盤硬件開始老化或隊列配置不當。用iotop看具體是哪些進程在產(chǎn)生I/O。很多時候磁盤慢不是磁盤本身的問題而是某個進程在做全表掃描、日志瘋狂輸出或者備份任務在搶占帶寬。這里有一個近些年SSD時代很值得注意的現(xiàn)象util和await都說正常但業(yè)務還是慢。這時候要看的是I/O的“并發(fā)度”也就是隊列深度iostat -x里的avgqu-sz。低并發(fā)下延遲正常、高并發(fā)下延遲飆升這種情況通常要檢查文件系統(tǒng)掛載參數(shù)、塊設備調度算法比如mq-deadline和none的選擇而不是一味加硬件。3.3 網(wǎng)絡指標丟包、重傳率與軟中斷網(wǎng)絡層面的監(jiān)控容易被兩個盲區(qū)坑到。第一個盲區(qū)是只盯帶寬使用率不看丟包和重傳。帶寬跑滿說明吞吐需求大但丟包率上升往往是網(wǎng)卡緩沖區(qū)不夠或者防火墻規(guī)則攔截TCP重傳率上升則直接意味著網(wǎng)絡質量在變差響應會莫名變慢。排查鏈路是ifconfig或ip -s link看每個網(wǎng)卡的RX/TX drop和error計數(shù)這兩個值持續(xù)增長說明底層有丟包。netstat -s或ss -s看TCP層的重傳、亂序、超時計數(shù)。抓包工具tcpdump對比抓一下重點看是否有大量重傳包集中在某個連接上。第二個盲區(qū)是網(wǎng)絡軟中斷。高流量場景下網(wǎng)卡收包會觸發(fā)軟中斷softirq如果軟中斷都擠在某個CPU核上處理會出現(xiàn)“一個核跑滿、其他核閑著”的奇葩景象。排查命令是top里按1看每個核的使用率再用cat /proc/interrupts看中斷在各個核上的分布。發(fā)現(xiàn)問題后用irqbalance服務或者手動設置中斷親和性echo二進制掩碼到/smp_affinity把中斷分散到多個核上。順帶說一個運維里很容易被忽略的小點多塊網(wǎng)卡綁定時如果驅動不帶RSSReceive Side Scaling多隊列功能單隊列網(wǎng)卡在高PPS場景下天然會軟中斷集中。這是硬件選型問題監(jiān)控指標只能暴露改不了。4. 一次完整故障排查從收到告警到定位根因的實操鏈路光講指標不串一遍實戰(zhàn)等于紙上談兵。我拿最近處理的一個案例走一遍完整的排查流程這個案例很有代表性——初步看起來像CPU問題實際根子在磁盤而且中間還踩了個監(jiān)控數(shù)據(jù)滯后的坑。4.1 告警與第一波基礎檢查某天下午3點監(jiān)控提示一臺數(shù)據(jù)庫從庫負載異常load average 15分鐘值從0.5漲到6而且還在緩步上升。CPU使用率只有40%內存正常。我第一反應是查最近的變更記錄——結果沒有發(fā)布、沒有配置變更、沒有備份任務在跑。這本身就說明了問題一個沒有變更的系統(tǒng)突然負載升高說明外部流量變了或者內部某個隱藏任務被觸發(fā)了?；A排查命令走一遍uptime # 確認負載趨勢 top # 看CPU/內存瞬時狀態(tài)按1看每核 vmstat 1 5 # 看r、b、cs、si、so、wa的變化趨勢 iostat -x 1 5 # 看磁盤util、await、avgqu-sz free -h # 看內存水位結果有個發(fā)現(xiàn)很關鍵iostat里sda這塊盤的util只有15%看起來完全正常但avgqu-sz達到了12——隊列深度非常高說明有大量請求在排隊只是盤本身處理能力還在。這就是典型的“util正常、隊列異?！彼矔r數(shù)據(jù)差點把我?guī)?.2 用歷史數(shù)據(jù)還原拐點這就是為什么我在第1節(jié)強調趨勢數(shù)據(jù)的重要性。我直接調出sysstat采集的歷史數(shù)據(jù)sar命令看前一個小時的數(shù)據(jù)sar -q -f /var/log/sa/sa$(date %d) | head -50 # 歷史負載 sar -b -f /var/log/sa/sa$(date %d) | head -50 # 歷史磁盤隊列 sar -d -f /var/log/sa/sa$(date %d) | head -50 # 歷史磁盤塊設備數(shù)據(jù)出來之后真相就清楚了磁盤隊列從下午2點40分開始異常而load是在2點50分開始爬升的——隊列異常比負載異常提前了10分鐘。這說明問題源頭是I/O不是CPU。至于15:00的告警那已經(jīng)是整個鏈條走完后的結果了。經(jīng)驗監(jiān)控系統(tǒng)的告警永遠滯后于問題的真正起點。所以排查時一定要回看歷史數(shù)據(jù)找“最早偏離正常值的那個時間點”而不是從告警時間開始查。告警時間只是閾值被擊穿的時間。4.3 定位到具體進程與內核行為確認是磁盤隊列問題后接下來就得找誰在發(fā)I/O。iotop排第一的是一個之前沒見過的進程PID是23085I/O讀寫一直在百分之三四十徘徊。ps一看是某個數(shù)據(jù)分析團隊臨時跑的一個Python腳本在持續(xù)掃一張大表并寫臨時文件。按理說下一步是直接kill掉并找團隊負責人確認。但為了定位更徹底我用pidstat看了下這個進程的行為細節(jié)pidstat -d 1 5 -p 23085 # 按進程看I/O統(tǒng)計 pidstat -w 1 5 -p 23085 # 看這個進程的上下文切換結果發(fā)現(xiàn)這個進程不光在做I/O還在頻繁創(chuàng)建臨時文件——讀一大塊、寫一個臨時文件、再刪掉循環(huán)往復。這帶來的后果是文件系統(tǒng)元數(shù)據(jù)操作暴增元數(shù)據(jù)操作又要反復讀寫日志塊設備最終把整個塊設備的請求隊列給擠滿了。這也是為什么有時候單看某個進程的I/O量不大但整個系統(tǒng)卻I/O擁塞——因為元數(shù)據(jù)操作的開銷是隱性的不體現(xiàn)在按字節(jié)計量的I/O吞吐里卻實打實占用了隊列深度。4.4 處理與復盤清單處理方式不復雜和團隊確認腳本不是線上任務后kill掉進程觀察10分鐘負載回落到0.3隊列恢復正常。這個案子的復盤清單值得記錄下來監(jiān)控告警閾值只能作為觸發(fā)條件不能作為故障起點的依據(jù)。util指標正常不代表磁盤健康必須結合隊列深度、await和進程級I/O行為綜合判斷。臨時任務一定要納入進程管理不能直接在業(yè)務機器上裸跑腳本。系統(tǒng)的變化有三個來源變更、流量、隱藏任務。排查時按這個順序排除能少走很多彎路。5. 從命令到監(jiān)控體系手工排查之外的工具鏈搭建手工排查能力是基本功但生產(chǎn)環(huán)境不可能靠人肉盯top。這套監(jiān)控體系怎么搭、工具怎么選決定了你的運維是“救火型”還是“預防型”。5.1 采集層sysstat是永遠逃不開的基礎無論用不用開源監(jiān)控系統(tǒng)每臺Linux機器都應該裝sysstat。它就是sar、iostat、mpstat、pidstat這些命令的集合包而且自帶cron定時采集把歷史數(shù)據(jù)落到/var/log/sa/目錄默認保留一個月。裝好sysstat之后有件事必須做確認采集周期。默認配置是每10分鐘采一次這個粒度對故障復盤來說太稀了。我習慣把周期調到每2分鐘一次歷史保留60天。做法是改/etc/cron.d/sysstat里的調用參數(shù)以及/etc/sysstat/sysstat中的HISTORY變量。有歷史數(shù)據(jù)之后日常運維就有了“先問過去再看現(xiàn)在”的底氣。半夜被叫起來的時候第一件事永遠是跑sar -q -f /var/log/sa/sa昨天的日期看昨天的指標是否已經(jīng)出現(xiàn)偏離經(jīng)常能省下大把時間。5.2 實時層atop和htop兩個值得常駐的工具實時排查場景我推薦兩個比top好用得多的工具atop和htop各自有獨特的優(yōu)勢。atop最厲害的地方是全量采樣——它記錄每秒鐘每個進程的CPU、內存、磁盤、網(wǎng)絡數(shù)據(jù)并且可以按時間軸回放。相當于系統(tǒng)自帶了一個“行車記錄儀”故障發(fā)生后還能倒回去看故障期間每個進程到底干了什么。這個能力在追查那種“幽靈負載”問題時價值極高。htop強在交互體驗和多核展示。按F5能看到進程樹按H能看到線程按M按內存排序、按P按CPU排序比top原生體驗好太多。作為日常巡檢的第一落點htop能讓你用最短時間建立起對系統(tǒng)整體狀態(tài)的感知。5.3 開源監(jiān)控系統(tǒng)選型核心是采集口徑與告警能力監(jiān)控系統(tǒng)的選型比較說到底不是比功能列表長短而是比三個維度采集口徑是否靈活、告警規(guī)則是否能自定義復雜邏輯、故障發(fā)生時能否快速定位指標曲線。維度Prometheus GrafanaZabbix云廠商自帶監(jiān)控采集方式拉模式客戶端暴露指標接口推模式agent主動上報agent上報指標靈活度高可自定義Exporter采集任何數(shù)據(jù)中模板為主低預設指標項告警能力基于PromQL的復雜告警規(guī)則觸發(fā)器表達式強大簡單閾值適合基礎場景歷史數(shù)據(jù)默認本地存儲可對接遠端存儲數(shù)據(jù)庫存儲清理麻煩一般保留數(shù)天到數(shù)十天上手成本中高需要理解指標模型低模板一鍵導入零成本以我在生產(chǎn)環(huán)境的經(jīng)驗來看Prometheus陣營目前是主流方向核心原因是它的指標模型和Kubernetes天然契合Exporter生態(tài)也很豐富——node_exporter就能覆蓋絕大多數(shù)系統(tǒng)指標Redis、MySQL、Nginx這些中間件也都有對應的Exporter。但有一個坑必須提醒任何監(jiān)控系統(tǒng)都要先驗證采集數(shù)據(jù)的準確性。我踩過的例子是node_exporter的磁盤指標和iostat的數(shù)值大概率存在偏差因為兩者對I/O統(tǒng)計的口徑不完全一致如果告警規(guī)則直接基于Prometheus的數(shù)值設置可能出現(xiàn)磁盤明明已經(jīng)很慢了但告警沒觸發(fā)的情況。實踐中的做法是雙軌驗證新裝監(jiān)控系統(tǒng)后手動用iostat、free、top對比連續(xù)采樣一周確認數(shù)據(jù)一致性然后再設置告警閾值。這一步不能省。5.4 告警設計不是越靈敏越好而是要減少“無意義告警”告警這塊我見過的極端案例是有人把告警閾值設置得極其激進結果一天收幾百條通知最后團隊集體屏蔽告警群——這比沒有監(jiān)控還危險。合理的告警設計原則有三條告警要反映業(yè)務風險而非指標波動。CPU偶爾飆到90%只要1分鐘就回落不值得打擾人持續(xù)15分鐘高于80%才需要關注。所以告警規(guī)則必須有持續(xù)時間條件不能只看瞬時值。告警必須附帶上下文信息。一條合格的告警應該包含異常指標當前值、正常基線的參考值、異常開始時間、相關進程或設備的定位信息。沒有上下文的告警收到的人也不知道該干什么。告警要有分層和升級機制。P0級核心業(yè)務不可用直接打電話P1級資源逼近瓶頸發(fā)即時消息P2級趨勢性風險進日報匯總。該用電話通知的不要用群消息該用日報沉淀的不要半夜震鈴。6. 長期維護中的經(jīng)驗補遺時間同步、日志關聯(lián)與自省講完主線的監(jiān)控方法還有幾個邊角料環(huán)節(jié)看著小實際在生產(chǎn)環(huán)境里經(jīng)常絆人一跤。6.1 時間同步所有監(jiān)控數(shù)據(jù)的“隱形地基”監(jiān)控系統(tǒng)里所有數(shù)據(jù)都帶時間戳故障復盤更是依賴時間軸對齊。如果服務器時間不準輕則日志和監(jiān)控對不上號重則分布式環(huán)境下事件順序完全錯亂。所以時間同步這件事應該被當作監(jiān)控體系的一部分來維護。檢查方法很簡單timedatectl status # 查看時間同步狀態(tài) chronyc sources -v # chrony環(huán)境下查看同步源狀態(tài) ntpq -p # 老版ntp環(huán)境下查看同步源狀態(tài)注意用ntpdate做一次性校時的服務器時間會跳變跳變期間如果正好在發(fā)日志和監(jiān)控數(shù)據(jù)時間戳會對不齊。推薦用chrony做漸進式校時通過調整時鐘頻率讓時間慢慢對齊而不是瞬間跳變。生產(chǎn)服務器全部配置好ntp并且開啟定期校驗這個動作要寫進服務器初始化清單里不能靠人肉一臺一臺檢查。6.2 日志指標聯(lián)動監(jiān)控數(shù)字背后是具體事件指標監(jiān)控只能告訴你“系統(tǒng)變成了什么樣”日志分析才能告訴你“為什么變成這樣”。實戰(zhàn)中最高效的配合方式就是指標異常時立即把對應時間窗的日志拉出來關聯(lián)。系統(tǒng)日志方面關注/var/log/messages下是否有內核報錯、OOM記錄、磁盤I/O錯誤應用日志方面用journalctl --since和--until按時間窗過濾重點看錯誤堆棧點和指標拐點的對應關系。日常大家可以有意識地訓練這個習慣每次處理完一個故障反問自己如果下次只看指標曲線能不能猜出問題類型逐步做到看到磁盤util上升就自動聯(lián)想到去看哪幾個日志文件形成肌肉記憶效率會高很多。6.3 監(jiān)控自身的成本與盲區(qū)監(jiān)控也要有成本意識。我在生產(chǎn)環(huán)境見過node_exporter部署過量導致指標采集本身消耗了可觀I/O的情況也見過把日志采集到Elasticsearch再查監(jiān)控指標這種重方案把運維復雜度推高數(shù)倍的配置。指標采集密度不是越密越好2秒一個點對絕大多數(shù)場景都夠用默認配置往往才是性價比最優(yōu)解。還有一個盲區(qū)是很多監(jiān)控系統(tǒng)默認不覆蓋的指標比如進程級別的線程數(shù)、文件描述符數(shù)量fd、TCP連接狀態(tài)分布。這些指標對排查實際問題非常關鍵卻經(jīng)常在監(jiān)控面板上看不到。建議至少在每臺機器上配好ss -s的定期采樣、進程fd數(shù)的監(jiān)控告警。別小看fd數(shù)——很多“連接數(shù)過多”“莫名無法創(chuàng)建新連接”的故障根因都是某個進程把文件描述符耗盡。最后再分享一點監(jiān)控這套東西工具永遠在演進今天講的具體命令和參數(shù)可能過兩年就有替代品但底層思維不會變先理解內核暴露了哪些數(shù)據(jù)再想清楚這些數(shù)據(jù)組合起來能說明什么問題最后形成自己的排查路徑。如果你剛入行在把監(jiān)控平臺建好之前先把20個最常用的指標命令敲熟能解釋清楚每個字段的含義和數(shù)據(jù)來源。有了這個基礎后面不管接觸什么監(jiān)控系統(tǒng)、什么新工具都能很快看穿它背后的邏輯。我個人習慣是每隔一段時間就會翻一翻手頭機器的/proc/stat和/proc/meminfo對照監(jiān)控面板驗證數(shù)字是否一致。這么做看起來有點笨但恰恰是這種“笨功夫”幫我在多次故障中第一個發(fā)現(xiàn)問題所在。監(jiān)控能力沒有捷徑把基本功練扎實比安裝再多花哨的工具都管用。