為什么陌生應用排障這么讓人崩潰我以前遇到一些項目發(fā)現(xiàn)他們遇到對自己的應用了解很少點開服務器一看進程名看不懂目錄結構亂七八糟日志文件幾十個不知道該看哪個。然后是亂。上來就 tail -f 各種日志grep 一堆關鍵字越查越焦慮恨不得把整個 /var/log 翻個底朝天。最后是放棄。折騰半天找不到根因開始到處問人“這個服務誰寫的”“以前出過類似問題嗎”“有文檔嗎”但你發(fā)現(xiàn)沒這樣做的結果往往是 —— 故障時間越拖越長最后要么草草重啟了事治標不治本要么領導親自下場盯著你查壓力直接拉滿。后來我才想明白一個道理排障不是靠經驗碾壓是靠套路。經驗只能讓你排查得快一點但真正讓你在陌生系統(tǒng)面前不慌的是一套可以復用的方法論。今天我就把這套東西掏出來給你。排障的核心心法先摸家底再動手很多人一上來就埋頭看日志這是大忌。你連這個服務是干嘛的、用什么語言寫的、部署在哪兒、依賴了誰都不知道就去翻日志那不叫排障那叫算命。第一步永遠是摸家底。怎么摸通過幾個問題快速建立認知框架這個服務是誰部署的、用什么語言Java、Go、Python、Node 還是 PHP是單實例還是集群部署跑在物理機、虛擬機還是容器里了解這些不是為了裝專家是為了知道接下來該用什么工具去查。比如 Java 應用你得會看 jstack、jmapGo 應用你得會看 pprofPython 應用你得知道常見的框架日志格式。舉個最真實的例子有一次我接手一個 Python 寫的定時任務服務告警說任務卡住了不跑。新人上去就 grep “error”翻了半小時日志一無所獲。我過去一看先問了一句這個服務用的是什么調度框架答案是 Celery。然后我直接去看 Redis 里的任務隊列Celery 默認用 Redis 做 broker發(fā)現(xiàn)任務確實堆在隊列里沒被消費。接著看 worker 進程日志發(fā)現(xiàn)是連接數(shù)據庫超時。整個過程不到 5 分鐘。你看不了解這個服務的家底你根本不知道該看哪里。所以面對陌生應用我一般會先做這幾件事看部署方式systemd 管理看/etc/systemd/system/下的 unit 文件里面有啟動命令、工作目錄、環(huán)境變量。容器跑的看docker inspect或者kubectl describe deployment里面能拿到鏡像、掛載、環(huán)境變量、命令行參數(shù)。進程直接拉的看ps aux | grep對應的進程重點看啟動命令那一串?？催M程信息ps -ef能告訴你進程 PID、啟動時間、啟動命令。pstree能看到這個進程有沒有 fork 子進程子進程在干嘛。lsof -p PID是神器能看到這個進程打開了哪些文件、監(jiān)聽了哪些端口、連接了哪些遠端 —— 這一條命令能告訴你 80% 的關鍵信息。看資源占用top或者htop看 CPU、內存占用有沒有進程在瘋狂吃資源。iostat、vmstat、netstat或者現(xiàn)在更推薦用ss -s能看網絡連接狀態(tài)、磁盤 IO。這幾個工具一組合起來這個服務的大致畫像就有了跑在哪兒、用什么語言、連了哪些外部服務、最近有沒有重啟過。找入口摸清請求從哪里進、數(shù)據往哪里去摸完家底下一步是搞清楚請求的流轉路徑。任何線上應用本質上都是一個數(shù)據流轉系統(tǒng)流量從某個入口進來經過一系列處理可能調數(shù)據庫、調緩存、調下游服務、調消息隊列最后返回結果或者寫出去。排障的本質就是找到哪一環(huán)斷了。所以你得先找到入口。對于 HTTP 服務入口就是監(jiān)聽端口。看ss -tlnp或者netstat -tlnp找到進程監(jiān)聽的端口然后順著端口找進程順著進程找配置。拿到端口和 IP 之后自己寫個簡單的 curl 模擬請求看返回curl -v http://127.0.0.1:8080/health curl -v -X POST http://127.0.0.1:8080/api/xxx -d {key:value}curl -v非常關鍵它會顯示完整的請求和響應頭有時候問題就藏在 header 里比如跨域、Content-Type 不對、認證失敗。對于定時任務入口就是調度器?？?crontab、看調度框架的配置Celery beat、Airflow、xxl-job 這些找到任務的執(zhí)行命令和觸發(fā)周期。然后手動觸發(fā)一次任務如果框架支持的話看任務能不能正常跑起來。對于消費 MQ 的服務入口就是消息隊列?？催B接的是哪個 MQKafka、RabbitMQ、RocketMQ用什么 consumer group消費的是哪個 topic/queue。用對應的客戶端工具kafka-console-consumer、rabbitmqctl 等看看隊列里有沒有積壓的消息。找到入口之后下一步是追調用鏈。這個調用鏈可能是代碼層面的你得會看代碼至少能看懂流程也可能是通過網絡層面去追蹤。如果你公司接入了分布式追蹤系統(tǒng)Jaeger、Zipkin、SkyWalking 這些那就太幸福了。直接去 Tracing 系統(tǒng)里搜這個服務的 traceID能看到完整的調用鏈路、每個環(huán)節(jié)的耗時、哪一步報錯。如果沒接那就要靠網絡包分析了。tcpdump抓包是個辦法但生產環(huán)境用要謹慎。更好的方式是看應用自己打印的日志找到請求的 traceID 或者 requestID然后 grep 這個 ID 把所有相關日志撈出來。grep traceIDabc123 /var/log/app/*.log這一招極其好用。哪怕你完全不懂這個應用的代碼也能通過日志把整個請求的足跡串起來。找日志排障的主戰(zhàn)場好重點來了 ——怎么找日志。這是我今天最想跟你嘮的。很多新手找日志的方式是cd /var/log然后ls看到一個文件就tail -f看完沒東西再換下一個。這種方式效率極低而且經常錯過關鍵信息。找日志的套路是先定位范圍再深入細節(jié)。第一步日志在哪里不同部署方式日志位置不一樣systemd 管理的服務看 unit 文件里的StandardOutputjournal還是StandardErrorjournal如果是 journal 就要用journalctl -u 服務名來看如果重定向到了文件就在 unit 文件里找路徑。容器跑的看docker logs container_id或者kubectl logs pod_name。如果用了 sidecar 日志收集那日志可能不在容器本地而是被收集到了 ELK、Loki 這些系統(tǒng)里。進程直接拉的找啟動腳本一般在 /opt、/home、/srv 這些目錄下腳本里通常會有日志路徑的硬編碼?；蛘咧苯觢sof -p PID | grep log能看到進程當前打開的日志文件。還有一招特別管用ls -l /proc/PID/fd。這個命令會列出進程打開的所有文件描述符里面一眼就能看到日志文件在哪個路徑。第二步日志格式是什么樣的找到日志文件之后先別急著 grep。先花兩分鐘看幾條日志了解它的格式。日志格式一般包含這些要素時間戳日志級別INFO、WARN、ERROR、FATAL線程名 / 協(xié)程名類名 / 函數(shù)名 / 代碼行號業(yè)務相關字段訂單號、用戶ID、traceID 等日志內容為什么要先看格式因為你要知道這個應用用什么字段做唯一標識。找到了這個標識你就能精準撈出某一次請求的所有日志。舉幾個常見場景Java 應用Log4j/Logback一般會有%X{traceId}這種 MDC 字段。Go 應用zap/logrus通常會有request_id或者trace_id這種字段。Python 應用logging格式比較自由但一般也會有自定義的 request_id。Nginxaccess.log 和 error.log 是分開的兩份access.log 里能看到 status、upstream_addr、request_time 這些關鍵信息。第三步按需撈日志格式搞清楚之后就可以精準撈日志了。幾個高頻命令你一定要熟# 實時跟蹤某個服務的日志 tail -f /var/log/app/service.log # 看最近 1000 行日志比 tail 更靈活 tail -n 1000 /var/log/app/service.log | less # 按時間范圍撈這個真救命 sed -n /2024-01-15 14:00:00/,/2024-01-15 14:30:00/p /var/log/app/service.log # 按關鍵字撈上下文-A 后幾行 -B 前幾行 -C 前后各幾行 grep -A 20 -B 5 OutOfMemoryError /var/log/app/service.log # 多個關鍵字或關系 grep -E ERROR|Exception /var/log/app/service.log # 排除干擾信息 grep -v 健康檢查 /var/log/app/service.log | grep ERROR # 按業(yè)務字段撈比如撈某個訂單的所有日志 grep order_id123456 /var/log/app/service.log # 統(tǒng)計某個錯誤出現(xiàn)的次數(shù) grep -c NullPointerException /var/log/app/service.log如果你公司有 ELK、Loki、Graylog 這種集中式日志平臺那上面的命令可以換成 Kibana 里的 KQL 語法或者 LogQL思路完全一樣。第四步注意日志的坑找日志不是一帆風順的我踩過太多坑了給你提幾個醒日志被截斷或者丟失。有些應用沒有正確處理日志的 rotation老日志被覆蓋有些容器日志沒配持久化容器一重啟就全沒了還有些應用為了性能把 ERROR 以上的日志直接吞了。多實例日志分散在不同的機器上。集群部署的服務每個實例的日志都在不同的服務器上。排查時要把所有實例的日志都撈出來對比因為問題可能只出在某一個實例上比如某個實例的 JVM 內存泄漏。日志時間和系統(tǒng)時間對不上。容器里時區(qū)沒配、服務器時間漂移、跨時區(qū)部署這些都會導致日志時間錯位?？慈罩厩跋萪ate一下服務器時間確保時區(qū)一致。敏感信息被脫敏了。有些應用為了合規(guī)會把日志里的手機號、身份證號、銀行卡號這些敏感字段脫敏成***。如果你排查的是業(yè)務問題這種脫敏反而會給你帶來麻煩 —— 看不到完整數(shù)據。日志量太大機器卡死。一個高 QPS 的服務一天能產生幾十 G 日志。直接cat整個文件可能會把服務器 IO 打爆。這種情況下要用less、head、tail這種流式工具或者直接到日志平臺搜。真實案例我怎么用這套方法論搞定那次陌生故障講理論講了這么多給你講個真實案例你感受下。場景某天上午 10 點業(yè)務反饋用戶支付后狀態(tài)一直不更新訂單服務群里炸了。第一步看監(jiān)控先看監(jiān)控大盤Grafana發(fā)現(xiàn)退款回調服務的 HTTP 5xx 錯誤率從 0.1% 飆升到 8%但 CPU、內存、網絡都沒異常機器沒崩。第二步摸家底服務器上ps -ef | grep refund發(fā)現(xiàn)這個服務是用 Java 寫的跑在 K8s 上2 個副本。kubectl describe pod refund-callback-xxx看到鏡像名是refund-callback:v3.2.1啟動命令里帶了-Xmx2g有個環(huán)境變量PAYMENT_GATEWAY_URLhttps://pay.xxx.com。第三步找入口kubectl port-forward轉發(fā)端口本地curl -v測了一下能通但返回 500?？吹椒祷貎热菔莡pstream timeout。第四步看日志kubectl logs refund-callback-xxx --tail200看到大量這樣的日志[ERROR] 2024-01-15 10:05:23 [http-nio-8080-exec-12] c.b.r.c.PaymentClient - 調用支付通道失敗: SSLHandshakeException: PKIX path building failed第五步定位根因SSLHandshakeException、PKIX path building failed看到這兩個關鍵字我就知道是證書問題。接著看日志里具體的異常信息unable to find valid certification path to requested target這是典型的 Java SSL 證書信任問題。繼續(xù)往下翻日志發(fā)現(xiàn)第一次出現(xiàn)這個錯誤的時間是 09:58跟監(jiān)控大盤上錯誤率飆升的時間點完全吻合。第六步驗證猜想openssl s_client -connect pay.xxx.com:443 -showcerts手動去拉支付通道的證書發(fā)現(xiàn)證書鏈里缺了中間證書只有葉子證書沒有 CA 證書。這十有八九是支付通道那邊運維換證書的時候配置出問題了。第七步臨時止血 根治臨時方案在 Java 應用的信任庫里手動補上缺失的中間證書重啟服務恢復正常。根治方案聯(lián)系支付通道的運維讓他們補全證書鏈。整個過程10 分鐘搞定。復盤一下我做了什么監(jiān)控發(fā)現(xiàn)異?，F(xiàn)象摸清服務家底語言、部署方式、配置找到入口并模擬請求精準定位日志從日志中提取關鍵異常信息用工具驗證猜想臨時止血 根治這就是方法論的力量。你不用懂這個服務的代碼不用認識寫這個服務的人不用看過任何文檔照樣能定位到根因。排障前的救命清單建議你收藏我再給你總結一份排障前的 checklist下次遇到陌生應用按這個清單一步步走摸家底階段服務部署在物理機/虛擬機/容器什么語言寫的什么框架進程名是什么PID 是多少啟動命令和配置文件在哪監(jiān)聽了哪些端口連接了哪些外部服務找入口階段HTTP 服務監(jiān)聽端口 域名定時任務調度器配置 執(zhí)行周期MQ 消費topic/queue consumer groupRPC 服務注冊中心 服務名看日志階段日志文件路徑在哪日志格式是什么用什么字段做唯一標識有沒有集中式日志平臺ERROR 級別的日志說了什么異常堆棧的第一行最關鍵的異常出現(xiàn)的時間點異常和監(jiān)控告警的時間點是否吻合深入排查階段是資源問題CPU/內存/磁盤/網絡是依賴問題下游服務/數(shù)據庫/緩存/消息隊列是配置問題環(huán)境變量/配置文件/證書是代碼問題看異常堆棧和代碼行號是數(shù)據問題臟數(shù)據/并發(fā)競爭/邊界值復盤階段根因是什么為什么之前沒發(fā)現(xiàn)監(jiān)控/告警是否合理如何避免下次再出工具和命令速查表最后再給你列一份我常用的工具清單建議保存系統(tǒng)層面ps、top、htop、iostat、vmstat、ss、netstat、lsof、strace、tcpdump進程層面Javajps、jstack、jmap、jstat、arthas強烈推薦線上排障神器Gopprof、go tool tracePythonpy-spy、pyflame日志層面tail、grep、less、awk、sed、journalctl網絡層面curl、telnet、nc、dig、nslookup、openssl s_client、mtrK8s 層面kubectl get/describe/logs/exec、kubectl port-forward集中式日志ELKElasticsearch Logstash KibanaLoki GrafanaGraylog阿里云/騰訊云的日志服務SLS/CLSAPM 和 TracingSkyWalkingJaegerZipkin阿里云 ARMS、騰訊云 CAT寫在最后說到底陌生應用排障這件事拼的不是你會不會寫代碼也不是你經驗有多豐富。拼的是你面對未知時的拆解能力和套路儲備。把一個陌生的系統(tǒng)一層層剝開來看 —— 它怎么部署的、入口在哪、數(shù)據怎么流、依賴了誰、日志在哪 —— 這些問題回答完了根因就呼之欲出了。這套方法論我用了好幾年不管是接手新業(yè)務、臨時救場、還是面試的時候被問到你排查過最難的問題是什么我都能很自信地說出整個流程。因為我知道故障是排不完的但方法論可以復用一輩子。希望今天這篇能幫到你。如果你身邊有剛入行的運維兄弟把這篇文章轉給他能少走很多彎路。