一篇帶給你k8s的可觀測性
概念
“可觀測性”這個名詞其實是最近幾年才從控制理論中借用的舶來概念,不過實際上,計算機科學中關(guān)于可觀測性的研究內(nèi)容已經(jīng)有了很多年的實踐積累。通常,人們會把可觀測性分解為三個更具體的方向進行研究,分別是:日志收集、鏈路追蹤和聚合度量。
在 2017 年的分布式追蹤峰會(2017 Distributed Tracing Summit)結(jié)束后,彼得 · 波本(Peter Bourgon)撰寫了總結(jié)文章《Metrics, Tracing, and Logging》,就系統(tǒng)地闡述了這三者的定義、特征,以及它們之間的關(guān)系與差異,受到了業(yè)界的廣泛認可。
結(jié)合k8s可觀測性
度量(Metrics)
度量的主要目的是監(jiān)控(Monitoring)和預警(Alert)。比如說,當某些度量指標達到了風險閾值時就觸發(fā)事件,以便自動處理或者提醒管理員介入。監(jiān)控數(shù)據(jù)格式標準化,做關(guān)聯(lián)指標聚合,方便快速定位故障。
基礎(chǔ)層:監(jiān)控主機和底層資源,比如:CPU、內(nèi)存、網(wǎng)絡(luò)吞吐、硬盤 I/O、硬盤使用等。通信情況:這里是指主機與主機之間的網(wǎng)絡(luò)情況。通信是互聯(lián)網(wǎng)中最重要的基石之一,如果兩臺主機之間出現(xiàn)如網(wǎng)絡(luò)延遲時間大、丟包率高這樣的網(wǎng)絡(luò)問題,會導致業(yè)務(wù)受阻。
中間層:VM 指標監(jiān)控,指的是 JVM 監(jiān)控,比如 GC 時間、線程數(shù)、FGC/YGC 耗時等信息。當然,其他語言也有其獨特的統(tǒng)計指標信息。就是中間件層的監(jiān)控,比如:Nginx、Redis、ActiveMQ、Kafka、MySQL、Tomcat 的資源消耗。
應(yīng)用層:HTTP 訪問的吞吐量、響應(yīng)時間、返回碼、性能瓶頸,還包括用戶端的監(jiān)控。
統(tǒng)一的監(jiān)控告警平臺:Prometheus+grafana
日志(Logging)
日志的職責是記錄離散事件,通過這些記錄事后分析出程序的行為,比如曾經(jīng)調(diào)用過什么方法、曾經(jīng)操作過哪些數(shù)據(jù),等等。通常,打印日志被認為是程序中最簡單的工作之一,你在調(diào)試問題的時候,可能也經(jīng)歷過這樣的情景“當初這里記得打點日志就好了”,可見這就是一項舉手之勞的任務(wù)。
當然,也有一部分系統(tǒng)是利用日志可追溯、結(jié)構(gòu)化的特點,來實現(xiàn)相關(guān)功能的,比如我們最常見的 WAL(Write-Ahead Logging)。WAL 就是在操作之前先進行日志寫入,再執(zhí)行操作;如果沒有執(zhí)行操作,那么在下次啟動時就可以通過日志中結(jié)構(gòu)化的,有時間標記的信息恢復操作,其中最典型的就是 MySQL 中的 Redo log。
統(tǒng)一的日志數(shù)據(jù)化:在特定時間發(fā)生的事件,被以結(jié)構(gòu)化的形式記錄并產(chǎn)生的文本數(shù)據(jù)。
統(tǒng)一的日志分析:elk或者loki+grafana
鏈路追蹤(Tracing)
在單體系統(tǒng)時代,追蹤的范疇基本只局限于棧追蹤(Stack Tracing)。比如說,你在調(diào)試程序的時候,在 IDE 打個斷點,看到的 Call Stack 視圖上的內(nèi)容便是跟蹤;在編寫代碼時,處理異常調(diào)用了 Exception::printStackTrace() 方法,它輸出的堆棧信息也是追蹤。
而在微服務(wù)時代,追蹤就不只局限于調(diào)用棧了,一個外部請求需要內(nèi)部若干服務(wù)的聯(lián)動響應(yīng),這時候完整的調(diào)用軌跡就會跨越多個服務(wù),會同時包括服務(wù)間的網(wǎng)絡(luò)傳輸信息與各個服務(wù)內(nèi)部的調(diào)用堆棧信息。因此,分布式系統(tǒng)中的追蹤在國內(nèi)通常被稱為“全鏈路追蹤”(后面我就直接稱“鏈路追蹤”了),許多資料中也把它叫做是“分布式追蹤”(Distributed Tracing)。服務(wù)調(diào)用鏈跟蹤。這個監(jiān)控系統(tǒng)應(yīng)該從對外的 API 開始,然后將后臺的實際服務(wù)給關(guān)聯(lián)起來,然后再進一步將這個服務(wù)的依賴服務(wù)關(guān)聯(lián)起來,直到最后一個服務(wù)(如 MySQL 或 Redis),這樣就可以把整個系統(tǒng)的服務(wù)全部都串連起來了。
最近幾年,各種鏈路追蹤產(chǎn)品層出不窮,市面上主流的工具,既有像 Datadog 這樣的一攬子商業(yè)方案,也有像 AWS X-Ray 和 Google Stackdriver Trace 這樣的云計算廠商產(chǎn)品,還有像 SkyWalking、Zipkin、Jaeger 這樣來自開源社區(qū)的優(yōu)秀產(chǎn)品。
鏈路追蹤+統(tǒng)計指標(Request-scoped metrics)請求級別的統(tǒng)計:在鏈路追蹤的基礎(chǔ)上,與相關(guān)的統(tǒng)計數(shù)據(jù)結(jié)合,從而得知數(shù)據(jù)與數(shù)據(jù)、應(yīng)用與應(yīng)用之間的關(guān)系。
鏈路追蹤+日志(Request-scoped events)請求級別的事件:這是鏈路中一個比較常見的組合模式。日志本身是每一條單獨存在的,將鏈路追蹤收集到的信息集成在日志中,可以讓日志之間具備關(guān)聯(lián)性,使其具有除了事件維度以外的另一個新的維度,上下文信息。
日志+統(tǒng)計指標(Aggregatable events)聚合級別的事件:這是在日志中的比較常見的組合。通過解析這部分具有統(tǒng)計指標的信息,我們可以獲取相關(guān)的指標數(shù)據(jù)。
三者結(jié)合(Request-scoped,aggregatable events)三者結(jié)合可以理解為請求級別+聚合級別的事件,由此就形成了一個豐富的、全局的觀測體系。
總結(jié)
1.事件日志的職責是記錄離散事件,通過這些記錄事后分析出程序的行為;
2.追蹤的主要目的是排查故障,比如分析調(diào)用鏈的哪一部分、哪個方法出現(xiàn)錯誤或阻塞,輸入輸出是否符合預期;
3.度量是指對系統(tǒng)中某一類信息的統(tǒng)計聚合,主要目的是監(jiān)控和預警,當某些度量指標達到風險閾值時就觸發(fā)事件,以便自動處理或者提醒管理員介入。