引言

我們將會學(xué)習(xí)關(guān)于可觀測性的一些知識，坐好，心沉淀下來。

本篇將會分享超過 20 個常見的關(guān)于可觀測性的常見問題，你準(zhǔn)備好了嗎？

我們開始了。

開始

1. 什么是可觀測性？

可觀測性是指能夠通過系統(tǒng)的外部輸出（如日志、指標(biāo)、追蹤）推斷出系統(tǒng)內(nèi)部狀態(tài)的能力。它幫助工程師理解系統(tǒng)的行為，快速定位故障并進(jìn)行調(diào)優(yōu)?？捎^測性通常包括以下三個主要方面：

• 日志（Logging）：記錄事件和系統(tǒng)狀態(tài)信息，用于調(diào)試和排查問題。
• 指標(biāo)（Metrics）：定期收集的系統(tǒng)運(yùn)行數(shù)據(jù)，用于分析性能、負(fù)載和資源使用情況。
• 追蹤（Tracing）：跟蹤請求或事務(wù)在系統(tǒng)中的流動，幫助分析性能瓶頸和系統(tǒng)間的依賴關(guān)系。

2. 日志、指標(biāo)和追蹤的區(qū)別是什么？

? 日志：記錄系統(tǒng)事件的詳細(xì)信息，通常是文本格式，包含錯誤、警告、信息等類型。適合用來進(jìn)行故障排查和事件審計。

? 指標(biāo)：定期收集的數(shù)字?jǐn)?shù)據(jù)，通常以時間序列的方式呈現(xiàn)，用于分析系統(tǒng)健康和性能，像是 CPU 使用率、內(nèi)存使用情況等。

? 追蹤：通過在請求或事務(wù)流中插入追蹤信息來監(jiān)控它們的路徑，幫助理解服務(wù)間的依賴關(guān)系、延遲和性能瓶頸。

3. 什么是日志聚合工具，舉例說明？

日志聚合工具用于收集和集中存儲來自不同服務(wù)或組件的日志，幫助用戶進(jìn)行統(tǒng)一管理和分析。常見的日志聚合工具有：

• ELK Stack（Elasticsearch, Logstash, Kibana）：Logstash 用于收集和解析日志，Elasticsearch 用于存儲和查詢，Kibana 用于可視化。
• Fluentd：一個用于收集和轉(zhuǎn)發(fā)日志的開源工具，通常與 Elasticsearch 和其他存儲工具結(jié)合使用。
• Graylog：一個開源日志管理平臺，支持日志聚合、存儲、搜索和可視化。

4. 你如何監(jiān)控和收集指標(biāo)？

通常使用以下工具來監(jiān)控和收集系統(tǒng)的指標(biāo)：

• Prometheus：一個開源的監(jiān)控和報警系統(tǒng)，專注于時序數(shù)據(jù)的收集和查詢。Prometheus 通過抓取配置好的目標(biāo)的暴露的指標(biāo)端點(diǎn)來收集數(shù)據(jù)。
• Grafana：與 Prometheus 或其他監(jiān)控系統(tǒng)結(jié)合使用，用于可視化監(jiān)控數(shù)據(jù)，展示圖表和儀表盤。
• CloudWatch（AWS）：AWS 提供的云原生監(jiān)控服務(wù)，用于收集、監(jiān)控和可視化 AWS 資源及應(yīng)用程序指標(biāo)。

5. 你如何實(shí)現(xiàn)分布式追蹤？

分布式追蹤用于跟蹤跨多個微服務(wù)的請求流動，幫助我們理解請求的延遲和依賴關(guān)系。常見的實(shí)現(xiàn)分布式追蹤的工具有：

• Jaeger：一個開源的分布式追蹤系統(tǒng)，可以追蹤請求在不同服務(wù)中的路徑，并提供相關(guān)的性能數(shù)據(jù)。
• Zipkin：另一個開源的分布式追蹤系統(tǒng)，提供端到端的請求追蹤，幫助識別瓶頸。
• OpenTelemetry：一個開源的可觀測性框架，提供多種 API 和 SDK 用于收集日志、指標(biāo)和追蹤數(shù)據(jù)，支持與多個后端集成。

6. 如何處理和響應(yīng)系統(tǒng)報警？

報警是可觀測性的一個重要組成部分，能夠及時提醒運(yùn)維人員或開發(fā)者關(guān)注系統(tǒng)異常。報警可以基于以下內(nèi)容設(shè)置：

• 閾值報警：當(dāng)某個指標(biāo)超過預(yù)定義的閾值時觸發(fā)報警（如 CPU 使用率超過 80%）。
• 異常檢測：基于機(jī)器學(xué)習(xí)和歷史數(shù)據(jù)，自動檢測異常行為并觸發(fā)報警。
• 智能報警：結(jié)合不同的系統(tǒng)狀態(tài)（如日志、指標(biāo)、追蹤）和上下文，制定更智能的報警規(guī)則，避免噪聲報警。

工具：

? Prometheus Alertmanager：與 Prometheus 配合，自動發(fā)送報警通知。

? CloudWatch Alarms：AWS 的報警系統(tǒng)，根據(jù) CloudWatch 中的指標(biāo)設(shè)置報警。

? PagerDuty：一個用于接收和管理報警的自動化系統(tǒng)，能幫助及時響應(yīng)和解決問題。

7. 什么是“服務(wù)級別指標(biāo)”（SLI）和“服務(wù)級別目標(biāo)”（SLO）？

? SLI（Service Level Indicator，服務(wù)級別指標(biāo)）：衡量服務(wù)性能的關(guān)鍵指標(biāo)，如請求成功率、響應(yīng)時間等。SLI 是對服務(wù)質(zhì)量的定量衡量。

? SLO（Service Level Objective，服務(wù)級別目標(biāo)）：定義服務(wù)期望達(dá)到的水平或目標(biāo)。例如，要求 99.9% 的請求在 1 秒內(nèi)完成處理，SLO 是對 SLI 的目標(biāo)值設(shè)定。

8. 在微服務(wù)架構(gòu)中，如何實(shí)現(xiàn)有效的可觀測性？

在微服務(wù)架構(gòu)中，由于服務(wù)之間的高度耦合和分布式部署，實(shí)施可觀測性非常重要。實(shí)現(xiàn)有效的可觀測性包括：

• 集中化日志管理：使用日志聚合工具（如 ELK Stack 或 Fluentd）收集和分析各微服務(wù)的日志，便于排查問題。
• 統(tǒng)一的指標(biāo)監(jiān)控：使用 Prometheus 或類似工具來收集所有服務(wù)的指標(biāo)，進(jìn)行資源監(jiān)控和性能分析。
• 分布式追蹤：集成 Jaeger 或 Zipkin 等工具，跟蹤跨服務(wù)的請求流，分析延遲、瓶頸及依賴關(guān)系。
• 報警與自動化：設(shè)置合適的報警閾值，結(jié)合自動化工具來處理報警，確保及時響應(yīng)和解決問題。

9. 你如何確保報警不會產(chǎn)生過多的噪聲？

過多的噪聲報警會導(dǎo)致警報疲勞，影響響應(yīng)效率。可以采取以下措施：

• 避免冗余報警：配置報警規(guī)則時，避免重復(fù)觸發(fā)同一個問題，利用合并和去重功能減少不必要的報警。
• 基于業(yè)務(wù)和關(guān)鍵指標(biāo)的報警：將報警焦點(diǎn)放在對業(yè)務(wù)最重要的指標(biāo)上，而不是所有可能出現(xiàn)的異常。
• 報警抑制和智能報警：根據(jù)歷史數(shù)據(jù)和系統(tǒng)狀態(tài)，利用機(jī)器學(xué)習(xí)算法檢測異常而非每次波動都報警。

10. 什么是指標(biāo)的“高水位”和“低水位”？它們?nèi)绾斡绊憟缶?guī)則？

高水位和低水位通常用于設(shè)置報警閾值。

• 高水位：指標(biāo)值超過此閾值時觸發(fā)報警。例如，CPU 使用率超過 90%。
• 低水位：指標(biāo)值低于此閾值時觸發(fā)報警。例如，服務(wù)請求數(shù)低于預(yù)期的最低值，表示可能存在服務(wù)故障。

使用高水位和低水位可以幫助確定系統(tǒng)資源瓶頸和服務(wù)故障，同時避免過度的報警和無意義的警告。

11. 什么是可觀測性（Observability）？與監(jiān)控（Monitoring）有何區(qū)別？

可觀測性是通過系統(tǒng)的輸出來推斷其內(nèi)部狀態(tài)的能力，核心目標(biāo)是理解復(fù)雜系統(tǒng)的未知問題。它依賴三大支柱：日志（Logs）、指標(biāo)（Metrics）和追蹤（Traces）。

與監(jiān)控的區(qū)別：

? 監(jiān)控：聚焦于已知問題（如預(yù)設(shè)閾值告警）。

? 可觀測性：用于診斷未知問題，提供上下文（如為什么 CPU 使用率高）。

12.解釋可觀測性的三大支柱（Logs, Metrics, Traces）及其作用

? 日志（Logs）：離散事件記錄，用于記錄系統(tǒng)行為的原始信息（如錯誤堆棧）。

? 指標(biāo)（Metrics）：聚合的時間序列數(shù)據(jù)，反映系統(tǒng)狀態(tài)（如請求速率、錯誤率）。

? 追蹤（Traces）：記錄請求在分布式系統(tǒng)中的端到端路徑，幫助定位延遲或故障點(diǎn)。

13.你用過哪些可觀測性工具？舉例說明它們的適用場景

? Prometheus：適合指標(biāo)收集與告警（如監(jiān)控 Kubernetes 集群資源）。

? Grafana：可視化工具，可聚合多數(shù)據(jù)源（如展示 Prometheus + Loki 的儀表盤）。

? ELK Stack（Elasticsearch, Logstash, Kibana）：日志管理與分析（如排查服務(wù)錯誤日志）。

? Jaeger/Zipkin：分布式追蹤（如分析微服務(wù)鏈路延遲）。

? OpenTelemetry：統(tǒng)一的觀測數(shù)據(jù)采集標(biāo)準(zhǔn)（跨語言、跨工具集成）。

14.如何在微服務(wù)架構(gòu)中實(shí)現(xiàn)分布式追蹤？

• 注入上下文：通過唯一 Trace ID 和 Span ID 標(biāo)記請求。
• 傳播上下文：在 HTTP Headers 或消息隊(duì)列中傳遞 ID（如使用 W3C Trace Context）。
• 工具集成：使用 Jaeger、Zipkin 或 OpenTelemetry 收集和關(guān)聯(lián)數(shù)據(jù)。
• 可視化分析：通過工具查看鏈路耗時、錯誤和依賴關(guān)系。

15.如何設(shè)計有效的告警策略？

? 分層告警：按嚴(yán)重性分級（如 P0-P3），避免告警疲勞。

? 基于 SLO 告警：圍繞服務(wù)目標(biāo)（如 99.9% 可用性）觸發(fā)告警。

? 動態(tài)閾值：使用機(jī)器學(xué)習(xí)（如 Prometheus 的 holt_winters）適應(yīng)流量波動。

? 告警靜默：在已知維護(hù)時段靜默非關(guān)鍵告警。

16.如何排查一個 API 的高延遲問題？

• 檢查指標(biāo)：查看請求延遲分位數(shù)（如 p99）、CPU/內(nèi)存使用率。
• 追蹤分析：找到鏈路中最慢的 Span（如數(shù)據(jù)庫查詢或外部 API 調(diào)用）。
• 日志關(guān)聯(lián)：通過 Trace ID 過濾相關(guān)日志，定位錯誤或慢查詢。
• 資源瓶頸：檢查是否達(dá)到資源限制（如連接池耗盡、磁盤 IO 高）。

17.日志量過大導(dǎo)致存儲成本高，如何優(yōu)化？

? 采樣（Sampling）：對低優(yōu)先級日志按比例采樣（如僅 10% 的 DEBUG 日志）。

? 分級存儲：熱數(shù)據(jù)存 SSD，冷數(shù)據(jù)轉(zhuǎn)存對象存儲（如 S3）。

? 結(jié)構(gòu)化日志：使用 JSON 格式，便于過濾和壓縮。

? 生命周期策略：自動刪除過期日志（如保留 7 天）。

18.解釋 OpenTelemetry 的核心組件及其優(yōu)勢

組件：

• API：提供語言無關(guān)的觀測數(shù)據(jù)生成接口。
• SDK：實(shí)現(xiàn) API，處理數(shù)據(jù)采樣、導(dǎo)出等邏輯。
• Collector：統(tǒng)一接收、處理和導(dǎo)出數(shù)據(jù)（如轉(zhuǎn)存到 Prometheus/Jaeger）。

優(yōu)勢： 標(biāo)準(zhǔn)化觀測數(shù)據(jù)格式，避免廠商鎖定；支持多語言和工具集成。

19.什么是 Exemplars？它們在可觀測性中的作用是什么？

Exemplars 是關(guān)聯(lián)指標(biāo)與追蹤的元數(shù)據(jù)（如將高延遲指標(biāo)關(guān)聯(lián)到具體的 Trace ID）。作用：

? 快速從指標(biāo)跳轉(zhuǎn)到具體請求的追蹤詳情。

? 適用于 Prometheus 等支持 Exemplars 的工具。

20.如何設(shè)計一個高可用的可觀測性系統(tǒng)？

• 數(shù)據(jù)冗余：多副本存儲（如 Elasticsearch 集群）。
• 負(fù)載均衡：通過 Collector 橫向擴(kuò)展處理流量。
• 降級策略：在數(shù)據(jù)洪峰時丟棄低優(yōu)先級數(shù)據(jù)（如非生產(chǎn)環(huán)境日志）。
• 去中心化：避免單點(diǎn)故障（如 Prometheus 的聯(lián)邦集群）。

21. 如果團(tuán)隊(duì)不重視可觀測性，你會如何推動改進(jìn)？

? 量化價值：展示故障排查時間減少、MTTR 降低的數(shù)據(jù)。

? 低成本試點(diǎn)：從小規(guī)模集成（如關(guān)鍵服務(wù)加 Tracing）。

? 培訓(xùn)與文檔：分享案例和最佳實(shí)踐，提升團(tuán)隊(duì)認(rèn)知。

22.舉一個你通過可觀測性工具解決復(fù)雜問題的案例（這邊隨便給大家一個例子）

案例背景：

我曾在一個微服務(wù)架構(gòu)中工作，系統(tǒng)中有多個服務(wù)與數(shù)據(jù)庫交互，提供實(shí)時數(shù)據(jù)處理。隨著流量的增加，用戶開始報告應(yīng)用出現(xiàn)延遲，某些請求的響應(yīng)時間較長，甚至有時會出現(xiàn)超時錯誤。團(tuán)隊(duì)試圖定位問題，但由于微服務(wù)架構(gòu)的復(fù)雜性，難以通過傳統(tǒng)的日志或監(jiān)控手段迅速找出根本原因。

解決方案：

我們決定使用 可觀測性工具 來全面診斷和排查問題，以下是具體步驟：

1. 集成分布式追蹤

? 我們首先使用了 Jaeger，一個開源的分布式追蹤工具，來追蹤跨服務(wù)的請求流動。

? 在所有微服務(wù)中集成了 Jaeger 客戶端，并確保所有的請求（特別是慢請求）都能夠記錄追蹤信息。這包括了每個服務(wù)的入口、處理邏輯和調(diào)用的下游服務(wù)。

目標(biāo)：我們想通過追蹤信息找出在哪個服務(wù)或調(diào)用鏈中發(fā)生了延遲。

2. 設(shè)置并查看服務(wù)依賴圖

? 利用 Jaeger 收集的數(shù)據(jù)，我們可以生成服務(wù)間的依賴圖。這幫助我們直觀地看到服務(wù)之間的調(diào)用鏈條，識別瓶頸或異常的調(diào)用模式。

? 在查看依賴圖后，我們發(fā)現(xiàn)某些服務(wù)的響應(yīng)時間異常長，尤其是與數(shù)據(jù)庫交互的服務(wù)請求。

3. 結(jié)合指標(biāo)監(jiān)控分析性能

? 同時，我們使用 Prometheus 收集系統(tǒng)的實(shí)時指標(biāo)，特別是 CPU 使用率、內(nèi)存使用情況、數(shù)據(jù)庫連接池的大小、服務(wù)的請求數(shù)和延遲等。

? 我們通過 Grafana 將這些指標(biāo)可視化，并設(shè)定了針對關(guān)鍵指標(biāo)的閾值報警。通過監(jiān)控儀表盤，我們發(fā)現(xiàn)某個特定的數(shù)據(jù)庫服務(wù)在高流量時出現(xiàn)了 連接池滿 的現(xiàn)象，導(dǎo)致新的請求被阻塞。

4. 深入排查數(shù)據(jù)庫瓶頸

? 根據(jù)追蹤和指標(biāo)，我們鎖定了數(shù)據(jù)庫連接池的問題。由于數(shù)據(jù)庫的連接數(shù)設(shè)置不合理，流量激增時，服務(wù)的請求無法及時獲得數(shù)據(jù)庫連接，從而導(dǎo)致了請求的延遲。

? 通過增加數(shù)據(jù)庫連接池的大小，并優(yōu)化數(shù)據(jù)庫查詢性能，解決了瓶頸。

5. 日志分析

? 在此過程中，我們還利用了 ELK Stack（Elasticsearch、Logstash 和 Kibana）對相關(guān)服務(wù)的日志進(jìn)行分析。

? 日志幫助我們進(jìn)一步確認(rèn)了數(shù)據(jù)庫請求的失敗模式，并找到了錯誤的具體原因和堆棧信息。

結(jié)果

通過集成 Jaeger 進(jìn)行分布式追蹤，我們能夠快速識別請求延遲的根源，并結(jié)合 Prometheus 和 Grafana 的監(jiān)控指標(biāo)確定了數(shù)據(jù)庫連接池問題。最后，通過優(yōu)化數(shù)據(jù)庫配置，延遲問題得到了解決。

總結(jié)： 使用可觀測性工具（Jaeger、Prometheus、Grafana 和 ELK Stack）幫助我們?nèi)媪私饬讼到y(tǒng)的運(yùn)行狀態(tài)和服務(wù)之間的交互，從而定位了復(fù)雜問題的根本原因。通過這種方式，我們提高了系統(tǒng)的可觀察性，并能夠及時響應(yīng)和解決潛在的瓶頸問題。

結(jié)語

經(jīng)過上面的一番折騰，對于面試這種情況，可觀測性領(lǐng)域你算是明白了，但是這只是個開始，Kepp Going