微服務(wù)架構(gòu)解決了單體應(yīng)用擴(kuò)展難的問題卻把排障難度轉(zhuǎn)移到了日志和鏈路追蹤上。一次用戶請(qǐng)求跨越多個(gè)服務(wù)、多個(gè)數(shù)據(jù)庫、多個(gè)中間件任何一個(gè)環(huán)節(jié)超時(shí)或報(bào)錯(cuò)都需要從分散日志中還原現(xiàn)場。如果日志體系沒有設(shè)計(jì)好排障就變成低效的人工 grep。微服務(wù)日志體系不是簡單地接一個(gè)采集工具而是一套覆蓋日志產(chǎn)生、規(guī)范、采集、傳輸、存儲(chǔ)、檢索、告警和治理的完整鏈路。這里會(huì)先講清楚排障難點(diǎn)再逐步展開一套可落地的生產(chǎn)級(jí)日志體系設(shè)計(jì)。1. 為什么微服務(wù)排障難日志體系要解決什么問題1.1 微服務(wù)排障的三類典型困境第一類困境是日志分散。單體應(yīng)用時(shí)代一個(gè)請(qǐng)求的完整執(zhí)行過程基本都在同一個(gè)進(jìn)程里日志文件也相對(duì)集中。微服務(wù)化之后一個(gè)請(qǐng)求可能要經(jīng)過網(wǎng)關(guān)、用戶服務(wù)、訂單服務(wù)、支付服務(wù)、消息消費(fèi)者每個(gè)服務(wù)可能還有多個(gè)實(shí)例。日志散落在不同機(jī)器、不同容器、不同目錄里沒有統(tǒng)一線索時(shí)很難把一次請(qǐng)求串起來。第二類困境是格式不統(tǒng)一。不同團(tuán)隊(duì)寫的服務(wù)可能有的用 logback有的用 log4j2有的直接System.out.println。日志時(shí)間有的用本地時(shí)間有的用 UTC有的沒有毫秒。字段命名也各不相同userId和user_id同時(shí)存在。排障時(shí)每次都要先理解日志格式再去過濾效率很低。第三類困境是日志量大。微服務(wù)實(shí)例一多日志量會(huì)快速膨脹。如果直接全文檢索查詢會(huì)越來越慢如果不做索引生命周期管理磁盤遲早被寫滿。到了大促或故障高峰期日志系統(tǒng)本身也可能成為瓶頸反而拖慢業(yè)務(wù)恢復(fù)。1.2 生產(chǎn)級(jí)日志體系的目標(biāo)所謂生產(chǎn)級(jí)不是日志采集工具能跑起來就行而是必須滿足幾個(gè)基本要求。請(qǐng)求有鏈路標(biāo)識(shí)。入口生成 traceId下游服務(wù)通過調(diào)用鏈透傳日志中能根據(jù) traceId 查到一個(gè)請(qǐng)求的完整路徑。日志格式可解析。日志輸出為結(jié)構(gòu)化字段而不是只有一段模糊的文本。至少包含時(shí)間、級(jí)別、服務(wù)名、實(shí)例、traceId、業(yè)務(wù)消息和異常信息。日志延遲可控。從業(yè)務(wù)寫日志到 Elasticsearch 可檢索延遲需要在一定范圍比如分鐘級(jí)以內(nèi)。不能經(jīng)常出現(xiàn)日志丟失或幾個(gè)小時(shí)后才看到日志。日志有生命周期。熱數(shù)據(jù)保留幾天冷數(shù)據(jù)保留更長時(shí)間超過保留周期的數(shù)據(jù)要自動(dòng)刪除或歸檔而不是等磁盤告警后手工清理。日志系統(tǒng)本身不能影響業(yè)務(wù)。應(yīng)用寫日志是異步的采集鏈路故障時(shí)不能阻塞業(yè)務(wù)線程。生產(chǎn)級(jí)體系還要關(guān)注采集組件狀態(tài)、Kafka 消費(fèi)堆積和 ES 磁盤水位。2. 設(shè)計(jì)日志體系前先把日志規(guī)范定下來日志規(guī)范是整套體系的地基。如果每個(gè)服務(wù)輸出的字段都不一樣后面接 Filebeat、Kafka、Logstash、Elasticsearch 都會(huì)很被動(dòng)。排障效率提升的第一步不是工具而是標(biāo)準(zhǔn)。2.1 統(tǒng)一日志字段讓檢索有依據(jù)建議服務(wù)端日志統(tǒng)一輸出為 JSON 格式。每條日志的頂層字段盡量固定下面是一組常見字段。字段類型含義示例timestampstring日志產(chǎn)生時(shí)間2026-06-01T10:00:00.123Zlevelstring日志級(jí)別ERRORservicestring服務(wù)名order-serviceinstancestring實(shí)例標(biāo)識(shí)10.0.0.1:8080traceIdstring鏈路ID8f3a1b2c...methodstring請(qǐng)求方法POSTuristring請(qǐng)求路徑/api/orderstatusintHTTP 狀態(tài)碼500costMsint接口耗時(shí)毫秒128userIdstring用戶標(biāo)識(shí)u_10001messagestring業(yè)務(wù)消息訂單創(chuàng)建失敗exceptionstring異常棧原文java.lang.NullPointerException...字段不是越多越好但上面這些基礎(chǔ)字段能覆蓋大部分排障場景。service用于區(qū)分系統(tǒng)instance用于還原具體實(shí)例traceId用于串聯(lián)調(diào)用鏈costMs用于定位性能問題exception用于快速搜索異常棧。實(shí)際項(xiàng)目里團(tuán)隊(duì)可以先定一個(gè)最小字段集發(fā)布到協(xié)作文檔或代碼倉庫的模板中。新服務(wù)開發(fā)時(shí)必須按這套字段輸出老服務(wù)逐步遷移。不要指望所有服務(wù)一天改完但至少要有一個(gè)明確的規(guī)范版本。2.2 日志級(jí)別怎么定避免日志噪音日志級(jí)別是排障時(shí)最重要的過濾維度之一。級(jí)別定得不好會(huì)帶來兩種典型問題把 ERROR 當(dāng)普通日志打告警全是噪音或者把 DEBUG 打到生產(chǎn)日志量爆炸真正有用的 ERROR 被淹沒。級(jí)別使用場景生產(chǎn)預(yù)期ERROR業(yè)務(wù)失敗、異常導(dǎo)致流程中斷需要人工介入保留并告警WARN可以恢復(fù)但不正常比如緩存穿透、重試成功保留不直接告警INFO關(guān)鍵流程節(jié)點(diǎn)比如訂單創(chuàng)建、支付回調(diào)保留但要控制頻率DEBUG排查細(xì)節(jié)數(shù)據(jù)默認(rèn)關(guān)閉按需開啟TRACE內(nèi)部調(diào)用鏈細(xì)節(jié)很少開啟一個(gè)簡單判斷標(biāo)準(zhǔn)如果某條日志打出來之后值班同學(xué)不用看那它就不該是 ERROR。ERROR 應(yīng)該對(duì)應(yīng)一個(gè)需要關(guān)注的失敗事實(shí)而不是每次 catch 異常都打 ERROR。2.3 TraceID 貫穿始終從一次請(qǐng)求還原完整路徑TraceID 是微服務(wù)日志體系里最重要的字段。它的作用很簡單一次外部請(qǐng)求進(jìn)入系統(tǒng)時(shí)生成一個(gè)唯一 ID之后所有服務(wù)在處理這個(gè)請(qǐng)求時(shí)都攜帶這個(gè) ID并寫入各自日志。排障時(shí)只要搜索這個(gè) ID就能得到完整請(qǐng)求鏈路。常見做法是在網(wǎng)關(guān)或入口 Filter 中生成 TraceID并通過 HTTP Header 向下游傳遞。比如統(tǒng)一使用X-Trace-Id作為透傳 Header。以 Servlet 場景為例可以用一個(gè) Filter 在入口生成并寫入 MDC。public class TraceIdFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { String traceId ((HttpServletRequest) request).getHeader(X-Trace-Id); if (traceId null || traceId.isEmpty()) { traceId UUID.randomUUID().toString().replace(-, ); } MDC.put(traceId, traceId); try { ((HttpServletResponse) response).setHeader(X-Trace-Id, traceId); chain.doFilter(request, response); } finally { MDC.remove(traceId); } } }MDC.remove很重要。線程池中的線程會(huì)被復(fù)用如果不清理下一條請(qǐng)求可能拿到上一個(gè)請(qǐng)求的 traceId導(dǎo)致日志串鏈路。下游服務(wù)在發(fā)起遠(yuǎn)程調(diào)用時(shí)要把 traceId 繼續(xù)傳遞下去。HttpHeaders headers new HttpHeaders(); if (MDC.get(traceId) ! null) { headers.set(X-Trace-Id, MDC.get(traceId)); }使用異步線程池時(shí)MDC 不會(huì)自動(dòng)傳遞。如果是 SpringThreadPoolTaskExecutor可以通過TaskDecorator在提交任務(wù)時(shí)拷貝 MDC執(zhí)行完后恢復(fù)如果只是在代碼里手動(dòng)new Thread則需要手工 put 和 remove。日志框架側(cè)也要把 traceId 輸出到結(jié)構(gòu)化字段中。使用logstash-logback-encoder時(shí)encoder 會(huì)自動(dòng)包含 MDC 中的字段。以 logback 為例一個(gè)最小 JSON 輸出配置如下。configuration appender nameJSON_FILE classch.qos.logback.core.rolling.RollingFileAppender file/data/logs/order-service/app.log/file rollingPolicy classch.qos.logback.core.rolling.TimeBasedRollingPolicy fileNamePattern/data/logs/order-service/app.%d{yyyy-MM-dd}.log/fileNamePattern maxHistory7/maxHistory /rollingPolicy encoder classnet.logstash.logback.encoder.LogstashEncoder includeMdctrue/includeMdc customFields{service:order-service,env:prod}/customFields /encoder /appender root levelINFO appender-ref refJSON_FILE/ /root /configuration這里把service和env固定寫進(jìn)了應(yīng)用日志配置避免了每個(gè)服務(wù)在業(yè)務(wù)代碼里重復(fù)拼接。不同版本 encoder 的配置略有差異落地前先確認(rèn)依賴版本。3. 日志采集層從服務(wù)本地日志到統(tǒng)一通道日志規(guī)范定好后下一個(gè)問題是日志怎么從應(yīng)用進(jìn)程到達(dá)統(tǒng)一的日志中心。生產(chǎn)環(huán)境常見的方案是應(yīng)用寫本地文件Filebeat 采集文件輸出到 Kafka。3.1 本地文件采集和直接上報(bào)怎么選有些新項(xiàng)目會(huì)直接在應(yīng)用里用 HTTP 或 SDK 把日志發(fā)送到 Logstash 或 Kafka。這種方式接入快但客戶端邏輯重還要處理發(fā)送失敗、緩沖區(qū)溢出、網(wǎng)絡(luò)抖動(dòng)等問題。應(yīng)用本身已經(jīng)有業(yè)務(wù)邏輯再承擔(dān)完整的日志傳輸職責(zé)容易引入不穩(wěn)定因素。更穩(wěn)妥的組合是應(yīng)用只負(fù)責(zé)把結(jié)構(gòu)化日志寫到本地磁盤采集器負(fù)責(zé)讀文件和傳輸。Filebeat 是常用選擇它輕量、內(nèi)存開銷小、支持?jǐn)帱c(diǎn)續(xù)采適合部署在應(yīng)用實(shí)例旁邊。采集端故障時(shí)應(yīng)用日志仍然寫在本地文件不會(huì)立刻丟失。這相當(dāng)于給日志多了一層本地緩沖。學(xué)習(xí)環(huán)境可以直接看控制臺(tái)或tail -f日志文件生產(chǎn)環(huán)境建議走文件采集。直接上報(bào)適合日志量不大、團(tuán)隊(duì)能接受客戶端 SDK 維護(hù)成本的場景但不是默認(rèn)首選。3.2 Filebeat 采集配置示例Filebeat 配置由 input 和 output 兩部分組成。下面是一個(gè)把訂單服務(wù)日志采集到 Kafka 的示例。filebeat.inputs: - type: filestream id: order-service-app enabled: true paths: - /data/logs/order-service/*.log fields: service: order-service env: prod fields_under_root: true processors: - add_host_metadata: ~ output.kafka: hosts: [kafka01:9092, kafka02:9092, kafka03:9092] topic: app-log partition: round_robin: reachable_only: true required_acks: 1 compression: gzip max_message_bytes: 1048576paths指定日志文件位置推薦一個(gè) input 只匹配一個(gè)服務(wù)的日志。fields用于給日志打上服務(wù)名和環(huán)境標(biāo)簽fields_under_root: true讓這些字段出現(xiàn)在日志頂層。add_host_metadata會(huì)把主機(jī)名和 IP 加進(jìn)來方便按實(shí)例過濾。output.kafka中的required_acks: 1表示 Kafka leader 寫入成功即可返回性能和可靠性比較均衡。compression: gzip可以降低網(wǎng)絡(luò)帶寬但會(huì)增加一點(diǎn) CPU 開銷。日志量很大時(shí)這個(gè)權(quán)衡通常值得。如果 Filebeat 版本較舊可能沒有filestream需要使用loginput。接入前先確認(rèn)版本不同版本的配置語法有差異。3.3 采集層最容易踩的坑第一個(gè)坑是多個(gè)服務(wù)共享同一個(gè)日志目錄。比如把所有服務(wù)的日志都寫到/data/logs/app.logFilebeat 采集后只能打同一個(gè)service標(biāo)簽無法區(qū)分來源。推薦按服務(wù)隔離目錄比如/data/logs/{service}/app.log。第二個(gè)坑是 Filebeat 重復(fù)采集滾動(dòng)日志。應(yīng)用日志按天滾動(dòng)后舊文件可能被改名成app.2026-06-01.log。如果 Filebeat 的 path 使用*.log可能把滾動(dòng)文件和新文件同時(shí)采集產(chǎn)生重復(fù)。建議嚴(yán)格約定文件名規(guī)則并在采集配置里避免把歸檔目錄包含進(jìn)來。第三個(gè)坑是采集延遲的假象。業(yè)務(wù)日志已經(jīng)寫到文件但 Filebeat 的ignore_older或close_inactive配置過大導(dǎo)致新日志不能及時(shí)讀取。排查時(shí)不要只看應(yīng)用日志有沒有寫還要看 Filebeat 是否處于運(yùn)行狀態(tài)、是否報(bào)權(quán)限錯(cuò)誤。4. 日志傳輸管道如何保證日志不丟不堵日志量是有峰值的。大促、秒殺、定時(shí)任務(wù)集中執(zhí)行時(shí)日志寫入速率可能瞬間翻幾倍。如果所有采集器直接把日志寫到 ElasticsearchES 寫入壓力會(huì)很大。引入 Kafka 作為緩沖是生產(chǎn)級(jí)日志體系里常見的解耦手段。4.1 Kafka 緩沖的作用和關(guān)鍵參數(shù)Kafka 在日志鏈路中負(fù)責(zé)削峰填谷。Filebeat 寫入 Kafka 后下游 Logstash 或消費(fèi)程序可以按照自己的節(jié)奏消費(fèi)不會(huì)因?yàn)闃I(yè)務(wù)流量突增而丟日志。Topic 設(shè)計(jì)時(shí)可以只建一個(gè)app-log主題通過日志中的service字段區(qū)分服務(wù)。也可以按環(huán)境分主題比如app-log-prod和app-log-test。分區(qū)數(shù)要結(jié)合下游消費(fèi)并發(fā)決定。單個(gè)分區(qū)只能被同一個(gè)消費(fèi)組里的一個(gè)線程消費(fèi)分區(qū)太少消費(fèi)并發(fā)上不去分區(qū)太多Kafka 元數(shù)據(jù)開銷也會(huì)變大。副本數(shù)建議生產(chǎn)環(huán)境至少 3并配置min.insync.replicas防止部分節(jié)點(diǎn)故障時(shí)寫入丟失。retention.ms可以設(shè)置日志在 Kafka 中的保留時(shí)間給下游鏈路故障留出恢復(fù)窗口。常見設(shè)置是保留 24 到 72 小時(shí)具體要看磁盤成本和團(tuán)隊(duì)對(duì)日志完整性的要求。分區(qū) key 的選擇也要考慮。如果希望同一實(shí)例的日志順序保持有序可以使用instance作為 key如果只關(guān)心吞吐可以使用輪詢策略。跨服務(wù)按 traceId 聚合到同一分區(qū)意義不大因?yàn)椴樵冸A段已經(jīng)在 ES 中完成聚合不需要在消息隊(duì)列里強(qiáng)制同分區(qū)。4.2 Logstash 消費(fèi)和寫入 ElasticsearchLogstash 在整個(gè)鏈路里負(fù)責(zé)消費(fèi) Kafka 消息、解析字段、補(bǔ)充信息再批量寫入 Elasticsearch。由于應(yīng)用側(cè)已經(jīng)輸出 JSON 日志Logstash 的 filter 可以保持很輕不需要用復(fù)雜的 grok 正則去切文本。一個(gè)最小 pipeline 配置如下。input { kafka { bootstrap_servers kafka01:9092,kafka02:9092 topics [app-log] group_id logstash-app-log codec json consumer_threads 6 } } filter { date { match [timestamp, ISO8601] target timestamp } if [exception] { mutate { add_field { error_flag true } } } } output { elasticsearch { hosts [http://es-data01:9200, http://es-data02:9200] index app-log-%{YYYY.MM.dd} } }codec json表示消息體本身就是 JSON。datefilter 把日志里的timestamp解析成 ES 使用的timestamp字段。error_flag是為了后續(xù)檢索時(shí)快速過濾異常日志。如果應(yīng)用日志里混入非 JSON 行比如System.out.println或啟動(dòng) Bannercodec json會(huì)導(dǎo)致解析失敗。這個(gè)問題最好在應(yīng)用層解決統(tǒng)一使用 logger 輸出不要混用標(biāo)準(zhǔn)輸出。如果無法避免可以改用純文本采集或獨(dú)立 topic再用 grok 解析。4.3 消費(fèi)堆積和背壓處理Kafka 消費(fèi)堆積是日志鏈路最常見的故障。現(xiàn)象是 Kibana 里最新日志遲遲不出現(xiàn)kafka-consumer-groups顯示的LAG持續(xù)增長。處理順序不要亂。先確認(rèn)是上游寫入變快還是下游消費(fèi)變慢。如果只是瞬時(shí)峰值可以等待消費(fèi)追平如果持續(xù)堆積優(yōu)先擴(kuò)容 Logstash 消費(fèi)吞吐也就是增加分區(qū)數(shù)和consumer_threads。但不要無限增加線程因?yàn)樽罱K瓶頸可能在 ES 寫入。ES 寫入壓力大時(shí)會(huì)表現(xiàn)為拒絕寫入或?qū)懭牒臅r(shí)上升。這時(shí)要檢查 ES 集群的寫入隊(duì)列、磁盤水位和 bulk 大小。生產(chǎn)環(huán)境建議將 ES 節(jié)點(diǎn)角色拆分?jǐn)?shù)據(jù)節(jié)點(diǎn)和協(xié)調(diào)節(jié)點(diǎn)分離避免高負(fù)載互相影響。還要給 ES 設(shè)置合理的索引分片數(shù)分片過少無法充分利用多節(jié)點(diǎn)過多會(huì)帶來資源浪費(fèi)。注意Kafka 消費(fèi)堆積本身不一定是故障如果業(yè)務(wù)日志量確實(shí)超過正常水位優(yōu)先擴(kuò)容而不是清空堆積。清空堆積會(huì)丟掉排障現(xiàn)場這是最不建議的做法。5. 日志存儲(chǔ)與檢索ES 索引設(shè)計(jì)決定查詢速度日志進(jìn)入 Elasticsearch 之后能不能快速查出來取決于索引設(shè)計(jì)和字段映射。生產(chǎn)環(huán)境見過太多“索引大了查不動(dòng)”的問題根源往往是最初沒有做索引規(guī)劃。5.1 按時(shí)間分索引避免單索引無限增長日志天然是和時(shí)間強(qiáng)相關(guān)的數(shù)據(jù)。按天建立索引比如app-log-2026.06.01是最常見的做法。好處很明顯查詢最近一天的數(shù)據(jù)只需要掃描當(dāng)天索引刪除過期數(shù)據(jù)只需刪除舊索引不用在單個(gè)大索引里做復(fù)雜清理。索引別名也可以配合使用。比如查詢最近 7 天日志時(shí)可以搜索app-log-*寫入側(cè)使用app-log-write別名由 ILM 管理實(shí)際索引。這樣可以保持查詢和寫入的穩(wěn)定。索引分片數(shù)要根據(jù)數(shù)據(jù)量和節(jié)點(diǎn)數(shù)預(yù)估。一個(gè)分片通常建議控制在 30GB 到 50GB 以內(nèi)。按天索引時(shí)如果每天日志量很大可以按天索引并配置多分片如果每天只有幾百 MB一個(gè)分片或少量分片就夠了。5.2 字段映射決定你是過濾還是全文搜索ES 中的字段類型直接影響查詢方式。精確匹配和聚合統(tǒng)計(jì)要使用keyword類型模糊匹配和關(guān)鍵詞搜索要使用text類型。排障中常用的service、level、traceId、instance、status都應(yīng)該設(shè)計(jì)為keyword或數(shù)值類型。一個(gè)參考 mapping 如下。{ mappings: { properties: { timestamp: { type: date }, level: { type: keyword }, service: { type: keyword }, instance: { type: keyword }, traceId: { type: keyword }, method: { type: keyword }, uri: { type: keyword }, status: { type: integer }, costMs: { type: long }, message: { type: text, fields: { keyword: { type: keyword, ignore_above: 256 } } }, exception: { type: text } } } }message使用text是為了支持關(guān)鍵詞搜索同時(shí)加了一個(gè)keyword子字段方便對(duì)短消息做精確過濾。exception使用text但要注意異常棧內(nèi)容很長不建議在 ES 中對(duì)全文做復(fù)雜聚合。如果日志字段不固定建議關(guān)閉動(dòng)態(tài) mapping 或使用 dynamic template 白名單。大量動(dòng)態(tài)字段會(huì)導(dǎo)致索引 mapping 膨脹嚴(yán)重時(shí)甚至讓集群停止寫入。統(tǒng)一日志字段規(guī)范也是保護(hù) ES 的一個(gè)手段。5.3 索引生命周期管理避免磁盤被打滿索引生命周期管理ILM是生產(chǎn)級(jí)日志存儲(chǔ)的必需環(huán)節(jié)。通過 ILM可以讓索引從熱階段滾動(dòng)到暖階段再按策略刪除。下面是一個(gè)簡單的 ILM 策略索引達(dá)到 50GB 或 7 天時(shí)滾動(dòng)超過 30 天的索引自動(dòng)刪除。PUT _ilm/policy/app-log-policy { policy: { phases: { hot: { min_age: 0ms, actions: { rollover: { max_size: 50gb, max_age: 7d } } }, delete: { min_age: 30d, actions: { delete: {} } } } } }ILM 需要配合索引模板使用把策略綁定到對(duì)應(yīng)索引模式上。PUT _index_template/app-log-template { index_patterns: [app-log-*], template: { settings: { number_of_shards: 3, number_of_replicas: 1, index.lifecycle.name: app-log-policy, index.lifecycle.rollover_alias: app-log-write } } }如果使用 ILM 的 Rollover寫入側(cè)應(yīng)使用別名app-log-write查詢則使用app-log-*。日志保留周期的選擇要結(jié)合業(yè)務(wù)需求ERROR 日志可以保留更久普通 INFO 日志保留 7 到 15 天通常就夠。注意不要只設(shè)置 ILM 而忽略磁盤容量評(píng)估。保留 30 天日志至少要把每天日志量乘以 30 乘以副本數(shù)再算上 ES 索引膨脹和 overhead才能確認(rèn)集群容量是否夠用。6. 排障實(shí)戰(zhàn)從一條報(bào)警到根因定位的完整鏈路日志體系設(shè)計(jì)得再好最終還是要回歸到排障場景。用一個(gè)常見例子說明凌晨收到告警訂單服務(wù) ERROR 增多接口 P99 升高。這時(shí)候應(yīng)該怎么查。6.1 先用時(shí)間和級(jí)別縮小范圍不要盲目搜全文排障第一步不是搜具體異常棧而是確定影響范圍。在 Kibana 中使用時(shí)間范圍過濾最近 15 分鐘再疊加服務(wù)名和級(jí)別。service:order-service AND level:ERROR AND timestamp now-15m如果日志量仍然很大可以加上uri或status進(jìn)一步縮小范圍。比如只查看POST /api/order的錯(cuò)誤日志。service:order-service AND level:ERROR AND uri:/api/order AND timestamp now-15m排序按timestamp升序先看最早的異常因?yàn)榈谝粋€(gè)異常往往是后續(xù)大量錯(cuò)誤的源頭。如果看到Connection timed out或Read timed out要意識(shí)到這可能是下游依賴導(dǎo)致的連鎖反應(yīng)先找出被調(diào)用方是否也有異常。6.2 用 TraceID 串聯(lián)完整調(diào)用鏈確定一條典型錯(cuò)誤日志后復(fù)制其中的traceId在 Kibana 中搜索。traceId:8f3a1b2c3d4e5f6a7b8c搜索時(shí)不限制服務(wù)名。只要 TraceID 在所有服務(wù)間透傳正確就能查到這個(gè)請(qǐng)求經(jīng)過的所有服務(wù)、所有實(shí)例的日志。按時(shí)間順序排列后可以看到請(qǐng)求從網(wǎng)關(guān)進(jìn)入訂單服務(wù)然后調(diào)用支付服務(wù)最后在哪里耗時(shí)最長。日志中會(huì)看到類似這樣的關(guān)鍵點(diǎn)訂單服務(wù)日志顯示調(diào)用支付服務(wù)開始和結(jié)束。支付服務(wù)日志顯示處理耗時(shí)超過 3 秒。支付服務(wù)之后出現(xiàn)數(shù)據(jù)庫超時(shí)或連接池等待。這一步的核心是確認(rèn)異常發(fā)生位置而不是只看最外層報(bào)錯(cuò)。外層的RestClientException可能只是下游超時(shí)的表象根因在支付服務(wù)的數(shù)據(jù)庫連接或 SQL 執(zhí)行上。6.3 從異常日志特征定位根因類型不同錯(cuò)誤特征對(duì)應(yīng)不同排查方向整理成速查表會(huì)很有用。日志特征可能根因下一步檢查status500 大量異常棧服務(wù)內(nèi)部異?？串惓?、線程池、連接池Connection timed out網(wǎng)絡(luò)不通或連接池耗盡檢查目標(biāo)服務(wù)、端口、連接池配置Read timed out下游處理慢查看下游服務(wù)耗時(shí)、GC、慢 SQLlock wait timeout exceeded數(shù)據(jù)庫鎖競爭查數(shù)據(jù)庫事務(wù)、慢 SQL、死鎖日志OutOfMemoryError內(nèi)存不足或泄漏查看對(duì)堆配置、GC 日志和