可觀測性通過Metrics、Logs和Traces三者結(jié)合全面了解系統(tǒng)運(yùn)行狀況。 1. Metrics提供量化數(shù)據(jù)快照，如CPU使用率，適合實(shí)時(shí)監(jiān)控但無法定位具體問題；2. Logs記錄詳細(xì)事件信息，適合排查具體錯(cuò)誤但數(shù)據(jù)量大；3. Traces追蹤請求鏈路，定位性能瓶頸，需唯一標(biāo)識(shí)和上下文傳遞。它們分別從整體狀態(tài)、具體細(xì)節(jié)和流程路徑三個(gè)層面保障系統(tǒng)透明度。

監(jiān)控系統(tǒng)的“可觀測性”聽起來挺技術(shù)，其實(shí)說白了就是我們想搞清楚系統(tǒng)到底在幹什麼。它有三個(gè)核心支柱：Metrics（指標(biāo)）、Logs（日誌）和Traces（追蹤）。這三者各有側(cè)重，合在一起就能讓我們對(duì)系統(tǒng)運(yùn)行狀況有更全面的了解。

Metrics 是數(shù)據(jù)的“快照”

Metrics 本質(zhì)上是一些可以被量化、並隨著時(shí)間變化的數(shù)據(jù)點(diǎn)。比如CPU 使用率、內(nèi)存佔(zhàn)用、請求成功率等。它們通常是聚合後的數(shù)據(jù)，能讓你快速看到系統(tǒng)整體狀態(tài)。

• 優(yōu)點(diǎn)：輕量、實(shí)時(shí)性強(qiáng)，適合做告警和看趨勢。
• 局限：太泛，只告訴你“有問題”，但不告訴你“哪裡有問題”。

舉個(gè)例子，你發(fā)現(xiàn)服務(wù)器的CPU 突然飆到90% 以上，這時(shí)候你就知道出問題了，但具體是哪個(gè)服務(wù)或者請求導(dǎo)致的？ Metrics 自己回答不了這個(gè)問題。

常見做法：

• 按時(shí)間序列記錄
• 使用Prometheus、Grafana 這類工具展示
• 設(shè)置閾值做自動(dòng)報(bào)警

Logs 是細(xì)節(jié)的“記錄員”

Logs 就是我們常說的日誌，記錄的是系統(tǒng)中發(fā)生的每一件事，比如錯(cuò)誤信息、用戶操作、API 請求詳情等。它比Metrics 更具體，能看到實(shí)際發(fā)生了什麼。

• 優(yōu)點(diǎn)：信息豐富，適合排查具體問題。
• 局限：數(shù)據(jù)量大，檢索成本高，不適合實(shí)時(shí)監(jiān)控。

比如說，你看到一個(gè)接口返回了500 錯(cuò)誤，這時(shí)候你可以去查對(duì)應(yīng)的日誌，看看是不是某個(gè)數(shù)據(jù)庫連接失敗，或者參數(shù)解析出了問題。

使用建議：

• 結(jié)構(gòu)化日誌更好處理，比如JSON 格式
• 配合ELK（Elasticsearch、Logstash、Kibana）或Loki 做集中管理
• 不要輸出太多無用信息，避免日誌爆炸

Traces 是調(diào)用鏈的“地圖”

Traces 關(guān)注的是一個(gè)請求在整個(gè)系統(tǒng)中的流轉(zhuǎn)路徑。尤其在微服務(wù)架構(gòu)下，一次請求可能涉及多個(gè)服務(wù)之間的調(diào)用，Traces 能幫你清晰地看到這個(gè)過程，找出性能瓶頸或故障源頭。

• 優(yōu)點(diǎn)：幫助理解請求流程，定位慢服務(wù)或失敗環(huán)節(jié)
• 局限：實(shí)現(xiàn)起來稍微複雜，需要上下文傳播機(jī)制

比如你調(diào)用了一個(gè)API，結(jié)果響應(yīng)特別慢。通過Trace 工具（比如Jaeger 或OpenTelemetry），你能看到整個(gè)請求鏈路，發(fā)現(xiàn)原來是某一個(gè)下游服務(wù)花了大量時(shí)間處理數(shù)據(jù)。

關(guān)鍵點(diǎn)：

• 每個(gè)請求要有唯一標(biāo)識(shí)（trace ID）
• 各個(gè)服務(wù)之間傳遞上下文信息
• 支持採樣控制，避免全量收集帶來的壓力

這三個(gè)東西結(jié)合起來，就像給系統(tǒng)裝上了“眼睛”、“耳朵”和“大腦”。 Metrics 告訴你係統(tǒng)有沒有問題，Logs 幫你查清問題出在哪，而Traces 則告訴你問題是怎麼發(fā)生的。

基本上就這些。

以上是可觀察性的三個(gè)支柱（指標(biāo)，日誌，痕跡）是什麼？的詳細(xì)內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！