一 、簡介
保障服務(wù)的高可用，必不可少的措施，就是需要對服務(wù)資源使用度量情況、運行異常、邏輯錯誤、請求鏈路、等各項度量指標、日志和鏈路了如指掌，并且通過對服務(wù)的實時監(jiān)控和分析，配置指標預(yù)警值，對異常進行告警，通知到相關(guān)負責(zé)人，通過可觀測性的提升，預(yù)防和及時發(fā)現(xiàn)問題，保障服務(wù)的可用性。
在可觀測性的內(nèi)容中，可以抽象出三大元素：日志（Logs） 、跟蹤（Traces） 、指標（Metrics） ，這三大元素就是可觀測性的三大支柱。
日志收集、鏈路追蹤和度量指標都是遙測體系的重要組成部分，它們一起構(gòu)成了觀測系統(tǒng)運行狀態(tài)和性能的關(guān)鍵數(shù)據(jù)基礎(chǔ)。
下面梳理在從業(yè)過程中對于可觀測性的相關(guān)架構(gòu)和開源工具的實現(xiàn)原理的理解，這里點到為止，主要讓大家了解有哪些技術(shù)點，想要了解更具體的內(nèi)容，可以到搜索中查詢，有很多好的詳細的文章。
二、日志（Logs）
記錄并匯集系統(tǒng)運行時產(chǎn)生的日志，包括但不限于錯誤信息、警告、調(diào)試信息以及應(yīng)用行為細節(jié)，這些信息有助于進行問題排查、性能分析和系統(tǒng)審計。
2.1 日志應(yīng)用
- nginx-err：nginx-log + logstash + es + kibana
- go-error：log-center + kafka + logstash + es +kibana
其中用到的工具：
ELK
Elasticsearch： 分布式搜索與分析引擎（存儲日志數(shù)據(jù)）。
Logstash： 數(shù)據(jù)收集、過濾與轉(zhuǎn)發(fā)工具（Elastic Stack 一部分）。
Kibana： 數(shù)據(jù)可視化平臺（Elastic Stack 一部分）
log-center： 自研 UDP 日志服務(wù)
2.2 日志架構(gòu)
2.2.1 UDP 日志服務(wù)日志收集架構(gòu)
Log-center 是自研的 upd 日志服務(wù)，應(yīng)用服務(wù)將日志上報到日志服務(wù)，日志服務(wù)將日志寫入到 kafka，然后再通過 logstash 從 kafka 同步到 ES，研發(fā)人員通過 kibana 查詢 ES 日志。
kibana 功能還是很強大，除了日志查詢，還支持 Visualize 統(tǒng)計圖表，Dashboards 儀表板 添加 Panels 等等，具體可以搜索了解相關(guān)介紹。
2.2.2 Nginx 日志文件 收集架構(gòu)
通過 logstash 將 nginx 日志采集上報到 ES，其他和上面一樣。
三、跟蹤（Traces）
在分布式系統(tǒng)中，尤其是微服部署，服務(wù)之間的鏈路調(diào)用錯綜復(fù)雜。鏈路追蹤用于追蹤一個請求在整個系統(tǒng)中的傳遞過程，記錄每個服務(wù)調(diào)用的詳細信息，如調(diào)用順序、耗時、狀態(tài)等，這對于解決分布式系統(tǒng)中的復(fù)雜問題和優(yōu)化系統(tǒng)性能至關(guān)重要。
3.1 鏈路追蹤應(yīng)用
- php apm
- go jeager trace
- kiali istio mesh
其中用到的工具：
Jaeger： 分布式追蹤系統(tǒng)，用于微服務(wù)和云原生應(yīng)用的性能監(jiān)控與故障排查。
Kiali： 服務(wù)網(wǎng)格可視化與管理工具（Istio）。
3.2 關(guān)于 jeager
jeager 分布式追蹤，鏈路組成：Span，Trace。
一個 Span 表示 Jaeger 的邏輯工作單元，Span 具有操作名稱，操作的開始時間，和持續(xù)時間。Span 可以嵌套并排序以建立因果關(guān)系模型。
一個 Trace 是通過系統(tǒng)的數(shù)據(jù)/執(zhí)行路徑，Trace 可被認為是由一組 Span 定義的有向無環(huán)圖。
3.2.1 jeager 鏈路邏輯圖
3.2.2 jeager 架構(gòu)圖
收集器直接寫入存儲
收集器寫入 Kafka 作為中間緩沖
3.2.3 jeager 組件說明
- Jaeger Client 為不同語言實現(xiàn)了符合 OpenTracing 標準的 SDK。應(yīng)用程序通過 API 寫入數(shù)據(jù)，client library 把 trace 信息按照應(yīng)用程序指定的采樣策略傳遞給 jaeger-agent。
- Agent 它是一個監(jiān)聽在 UDP 端口上接收 span 數(shù)據(jù)的網(wǎng)絡(luò)守護進程，它會將數(shù)據(jù)批量發(fā)送給 collector。它被設(shè)計成一個基礎(chǔ)組件，部署到所有的宿主機上。Agent 將 client library 和 collector 解耦，為 client library 屏蔽了路由和發(fā)現(xiàn) collector 的細節(jié)。
- Collector 接收 jaeger-agent 發(fā)送來的數(shù)據(jù)，然后將數(shù)據(jù)寫入后端存儲。Collector 被設(shè)計成無狀態(tài)的組件，因此您可以同時運行任意數(shù)量的 jaeger-collector。
- Data Store 后端存儲被設(shè)計成一個可插拔的組件，支持將數(shù)據(jù)寫入 cassandra、elastic search。
- Query 接收查詢請求，然后從后端存儲系統(tǒng)中檢索 trace 并通過 UI 進行展示。
3.2.4 jeager 代碼入侵
將微服務(wù)中的 gRPC 和 HTTP 代碼中嵌入追蹤相關(guān)的代碼
- 在 HTTP 服務(wù)中集成 Jaeger，早期的做法可能需要在每個請求處理器中顯式創(chuàng)建一個新的 Span，并設(shè)置父 Span（如果存在）。例如，在 Node.js 中，使用
opentracing庫和jaeger-client時，需要在中間件中注入追蹤邏輯，初始化 Span 并將其綁定到請求上下文中。 - 在 gRPC 服務(wù)中，同樣需要在每個服務(wù)方法的前后創(chuàng)建 Span，通常也需要設(shè)置相應(yīng)的父 Span。gRPC 社區(qū)為此提供了攔截器（Interceptor）機制，可以避免直接在業(yè)務(wù)邏輯中添加追蹤代碼。通過編寫一個 gRPC 攔截器，可以在不修改原有業(yè)務(wù)邏輯代碼的情況下注入 Jaeger 的追蹤行為。
存儲 mysql ，中間件 redis、kafka ，相關(guān)的 client 包也都支持添加追蹤的相關(guān)攔截的代碼。
這樣整個鏈路追蹤就可以貫穿應(yīng)用的各個關(guān)系層級，在 jeager ui 中就可以看到從請求發(fā)起到服務(wù)調(diào)用，以及存儲操作，中間件操作的整個鏈路的調(diào)用關(guān)系。
四、指標（Metrics）
度量是系統(tǒng)運行時統(tǒng)計的各種量化數(shù)據(jù)，如 CPU 使用率、內(nèi)存使用量、網(wǎng)絡(luò)帶寬、請求處理速率、錯誤率等，這些數(shù)據(jù)可用于實時監(jiān)控系統(tǒng)性能、預(yù)測潛在問題、制定容量規(guī)劃、掌握服務(wù)水平。
4.1 度量指標應(yīng)用
- k8s：k8s-ServiceMonitor + promethus + grafana
- Kafka：kafka-exporter + promethus + grafana
- esc： ecs-exporter + promethus + grafana
- mysql：mysql-exporter + promethus + grafana
- redis：redis-exporter + promethus + grafana
- ...
其中用到的工具：
Grafana：多數(shù)據(jù)源的監(jiān)控儀表板與分析工具。
Prometheus： 監(jiān)控與警報工具，主要用于度量收集與分析
4.2 關(guān)于 Prometheus
它針對大規(guī)模的集群環(huán)境設(shè)計了拉取式的數(shù)據(jù)采集方式，你只需要在你的應(yīng)用里面實現(xiàn)一個metrics接口，然后把這個接口告訴Prometheus就可以完成數(shù)據(jù)采集了。而且還內(nèi)置了報警功能。
[圖片上傳失敗...(image-f190fa-1718456055078)] ### 服務(wù)高可用秘籍：高性能 - 葵花寶典
4.2.2 Prometheus 組件簡要
- Prometheus Server： 存儲和檢索時序數(shù)據(jù)的核心，定期從配置的監(jiān)控目標拉取指標。
- Exporter： 各種第三方工具，負責(zé)將不同服務(wù)和系統(tǒng)的度量數(shù)據(jù)暴露給 Prometheus，轉(zhuǎn)換成 Prometheus 可讀格式。
- Pushgateway（可選）： 中間代理，允許短期任務(wù)或其他非長駐服務(wù)將指標推送到 Prometheus，因為 Prometheus 通常采用的是 Pull 模型。
- PromQL： 專為 Prometheus 設(shè)計的時間序列查詢語言，用于分析和聚合監(jiān)控數(shù)據(jù)。
- Alertmanager： 警報處理組件，對 Prometheus 產(chǎn)生的警報進行管理和通知，包括靜默、分組及路由至適當(dāng)?shù)慕邮照摺?/li>
- Web UI ： 內(nèi)置圖形界面，用于查詢、可視化和瀏覽 Prometheus 數(shù)據(jù)以及查看報警狀態(tài)。
- Client Libraries： 提供給應(yīng)用開發(fā)者直接在代碼中集成 Prometheus 監(jiān)控的庫，以便更方便地暴露應(yīng)用內(nèi)部的度量指標。
以上各組件共同構(gòu)成了完整的 Prometheus 監(jiān)控體系結(jié)構(gòu)，能夠?qū)崿F(xiàn)高效地數(shù)據(jù)采集、存儲、分析和報警功能。
4.2.3 Prometheus 中四種度量
- Counter： 計數(shù)器類型，用于表示只增不減的累計值，如請求總數(shù)、錯誤次數(shù)等。即使服務(wù)重啟，計數(shù)器也會在下次收集時保留上次的值。它的特點是不能減少，只能增加或重置為零。
- Gauge： 表盤類型，表示任意時刻可增可減的瞬時值，如內(nèi)存使用量、在線用戶數(shù)、請求處理速率等。Gauge 可以上升、下降或保持不變，可以用來表示任意變量的狀態(tài)。
- Histogram ： 直方圖類型，用于測量觀測值的分布情況，例如請求響應(yīng)時間。它可以自動對觀測值進行桶劃分，提供觀測值落在各個桶內(nèi)的數(shù)量以及總和、平均值等統(tǒng)計信息。
- Summary： 概要統(tǒng)計類型，也用于衡量觀測值的分布，但它允許自定義計算百分位數(shù)（如 p50, p90, p99），并且可以提供觀測值的總次數(shù)、總和以及自定義的百分位數(shù)數(shù)據(jù)。與 Histogram 類似，但提供了更多的靈活性和計算精度。
4.2.4 Prometheus 應(yīng)用
業(yè)務(wù)指標： 將業(yè)務(wù)中的一些核心指標、隊列長度、異常情況、等業(yè)務(wù)度量輸出，然后通過 grafana 配置面板進行展示和預(yù)警， grafana 的使用具體后面會介紹到。
業(yè)務(wù)應(yīng)用服務(wù)的指標上報，基本都是使用 pull metric 的方式，通過應(yīng)用服務(wù)項目代碼接入 prometheus client ，應(yīng)用服務(wù)啟動后會同時起一個用于拉取指標的 http 服務(wù)，然后在內(nèi)網(wǎng)中暴露訪問端口，prometheus config 來配置抓取應(yīng)用暴露的指標端點。
資源監(jiān)控： 通過 exporter 將服務(wù)架構(gòu)中使用到的 esc 、k8s node pod container 、mysql 、redis 、kafka 等，服務(wù)器資源，核心功能指標進行上報，同樣使用 grafana 展示和預(yù)警。
4.3 關(guān)于 Grafana
Grafana 是一個監(jiān)控儀表系統(tǒng)，它可以大大幫助我們簡化監(jiān)控的復(fù)雜度，我們只需要提供需要監(jiān)控的數(shù)據(jù)，它就可以幫助生成各種可視化儀表，同時它還有報警功能，可以在系統(tǒng)出現(xiàn)問題時發(fā)出通知。
Grafana 支持許多不同的數(shù)據(jù)源，每個數(shù)據(jù)源都有一個特定的查詢編輯器，每個數(shù)據(jù)源的查詢語言和能力都是不同的，我們可以把來自多個數(shù)據(jù)源的數(shù)據(jù)組合到一個儀表板，但每一個面板被綁定到一個特定的數(shù)據(jù)源。
具體的 Web UI 的使用 AlertManager 告警的配置，這里就不介紹，想要了解的可以搜索，總結(jié)就是很強大。
4.3.1 Grafana 應(yīng)用
我們將日志 ES、指標的 Promethues 加入到 grafana 數(shù)據(jù)源，然后增加 panel 可視化圖表，通過 AlertManager 設(shè)置預(yù)警值，通過釘釘群通知進行告警通知，整體搭配起來使用是真的香。
ES 日志：可以對日志進行查詢可視化展示和監(jiān)控，比如：請求 qps、異常 5xx 數(shù)量、 程序 error 數(shù)量、 msyql 慢日志、等請求和程序異常情況的預(yù)警。
Promethues 度量： 對上報的業(yè)務(wù)指標度量進行監(jiān)控和異常告警，如：隊列消費異常、核心功能異常、服務(wù)資源、等。
五、未來展望
當(dāng)前接入多個可觀測性的工具系統(tǒng)，各系統(tǒng)自相對獨立，排查問題只能通過唯一標識 uid 等信息，通過人工的串聯(lián)信息，如果我們能夠在多個系統(tǒng)中進行觀測信息的串聯(lián)，那就可以減去人工匹配的過程，達到事半功倍的效果。如：用戶反饋問題或者異常告警，通過從請求異常/請求日志中獲得鏈路的 trace-id，然后在鏈路追蹤中查看用戶當(dāng)前這個請求的鏈路情況，以及可以查詢當(dāng)前請求所在時刻的服務(wù)器節(jié)點、 pod、container 資源情況，串聯(lián)后可以提升人員對問題排查、性能優(yōu)化分析的效率。
六、持續(xù)更新
如何保障服務(wù)的高可用系列
- 如何保障服務(wù)的高可用：提升可觀測性（當(dāng)前）
- 如何保障服務(wù)的高可用：提升服務(wù)性能（預(yù)告）
- 如何保障服務(wù)的高可用：提升可靠性（預(yù)告）
- 如何保障服務(wù)的高可用：提升告警應(yīng)急能力（預(yù)告）
預(yù)告的文章待后續(xù)持續(xù)輸出，有喜歡的朋友雙擊 點贊 收藏 ?? + 666??
系列收錄在 Github《大話 WEB 開發(fā)》
