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