引言

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

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

我們開(kāi)始了。

開(kāi)始

1. 什么是可觀測(cè)性？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

工具：

? Prometheus Alertmanager：與 Prometheus 配合，自動(dòng)發(fā)送報(bào)警通知。

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

? PagerDuty：一個(gè)用于接收和管理報(bào)警的自動(dòng)化系統(tǒng)，能幫助及時(shí)響應(yīng)和解決問(wèn)題。

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

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

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

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

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

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

9. 你如何確保報(bào)警不會(huì)產(chǎn)生過(guò)多的噪聲？

過(guò)多的噪聲報(bào)警會(huì)導(dǎo)致警報(bào)疲勞，影響響應(yīng)效率?？梢圆扇∫韵麓胧?/p>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

13.你用過(guò)哪些可觀測(cè)性工具？舉例說(shuō)明它們的適用場(chǎng)景

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

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

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

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

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

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

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

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

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

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

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

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

16.如何排查一個(gè) API 的高延遲問(wèn)題？

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

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

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

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

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

? 生命周期策略：自動(dòng)刪除過(guò)期日志（如保留 7 天）。

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

組件：

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

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

19.什么是 Exemplars？它們?cè)诳捎^測(cè)性中的作用是什么？

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

? 快速?gòu)闹笜?biāo)跳轉(zhuǎn)到具體請(qǐng)求的追蹤詳情。

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

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

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

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

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

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

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

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

案例背景：

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

解決方案：

我們決定使用 可觀測(cè)性工具 來(lái)全面診斷和排查問(wèn)題，以下是具體步驟：

1. 集成分布式追蹤

? 我們首先使用了 Jaeger，一個(gè)開(kāi)源的分布式追蹤工具，來(lái)追蹤跨服務(wù)的請(qǐng)求流動(dòng)。

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

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

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

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

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

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

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

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

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

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

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

5. 日志分析

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

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

結(jié)果

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

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

結(jié)語(yǔ)

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