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