課程概要
在當下，雲原生的火爆不容小覷。隨著虛擬化技術的成熟和分散式框架的普及，在容器技術、可持續交付、編排系統等開源社群的推動下，以及微服務等開發理念的帶動下，應用上雲已經是不可逆轉的趨勢，雲原生（Cloud Native）的概念也應運而生，更是火得一塌糊塗。Cloud表示應用程式位於雲中，而不是傳統的資料中心；Native表示應用程式從設計之初即考慮到雲的環境，原生為雲而設計，在雲上以最佳姿勢執行，充分利用和發揮雲平臺的彈性+分散式優勢。而作為雲原生的基石之一，監控和日誌的重要性自是不言而喻。

監控（Monitoring）和日誌（Logging），是大型分散式系統中最關鍵的基礎設施之一。因為沒有監控，就沒辦法知曉服務的執行情況，也沒辦法知道叢集中有沒有Down機、機器的CPU使用率和負載是否正常、網站的Traffic是否正常，以及服務的出錯率是不是在可容忍範圍之內。簡而言之，監控使得我們可以實時瞭解網站的運營情況和可用性情況。

監控通常是從整體上了解網站的情況，需要具備實時性，而日誌則是詳盡地記錄著系統執行情況，每一次Service的呼叫，每一次資料庫的訪問，都應該寫進日誌，特別是當系統出現問題時，我們希望日誌系統能提供完整的錯誤堆疊和儘可能完備的上下文，從而為系統維護提供支援。

為了幫助開發者對雲原生監控和日誌解決方案等概念有個系統的瞭解和應用，4月1日，京東雲與AI事業部雲產品研發部架構師高雲川老師，在《六週玩轉雲原生》系列技術公開課《第四講：走近監控與日誌，雲原生基石探秘》中，和與會者們共同討論了在記錄和監控雲原生應用時各種值得借鑑和遵循的優秀實踐與標準，並透過精彩的案例解析分享京東智聯雲在雲原生監控&日誌的落地實踐。

同時，透過邀請開發者們動手實踐，深入參與並體驗雲原生監控體驗，參加課程的同學紛紛表示收穫頗豐。那麼，高雲川老師究竟分享了哪些乾貨？雲原生下的可觀測性是什麼？Prometheus監控方案和EFK的日誌方案究竟如何實踐？下面讓我們一起來回顧下精華內容吧！

六週玩轉雲原生

走近監控與日誌，雲原生基石探秘

— 京東雲與AI產品研發部架構師高雲川 —

雲原生下的可觀測性

在雲原生中，典型的代表技術包括容器（我們通常理解為Docker）、服務網格、服務治理、微服務、微服務框架、還有不可變基礎設施等。這裡面就涉及到OS層相關的探索以及宣告式API，這是它的典型特徵之一。因此，構建雲原生應用的目標之一就是構建容錯性好、便於管理和便於觀測的松耦合系統，這裡面的觀測就是我們今天要講的可觀測性。利用綜合可靠的自動化手段，雲原生技術使工程能夠輕鬆的應對大規模伸縮和頻繁持續的交付。目前我們講的雲原生基本都是講K8S，所以基本上也可以叫它Kubernetes native。

雲原生的可觀測性是指提供對系統行為的高度細緻的見解以及豐富的上下文，非常適合除錯目的。正如下圖所示，2017年的一篇文章提出了這一概念。作者認為：可觀測性其實是監控系統，就是這個圓圈的Monitoring部分。可觀測性不僅僅包含監控系統，也包含了相關的以除錯（包括測試、做負載壓測等）為目的的方式。

我們通常所說的監控系統是最適合報告系統整體執行狀況的，目標是保證我們的監控系統它自身的簡單、高效和穩定。通俗的理解一下，可觀測性就是透過技術手段描繪系統的更全面的狀態，對我們自己的整體系統有一個非常全面的認知，以一個非常低的門檻且形象的方式讓使用者具象化的感受到自己對業務的假設是否符合預期，以其獲得對業務更深的insight。

下面我們說一下這個監控的意義。我們通常會遇到一些問題，比如：“這個服務我感覺它好像不太正常，但是我也不知道系統到底是不是有問題？”“這個問題我修了很長時間，但是還沒有修復，壓力山大怎麼辦呢？”“好不容易看到異常資訊，但是一堆資訊，我無從查詢，怎麼辦？”“我部署了一個微服務應用，可能七八十個子系統的管理員，線上出問題了，我要去排查它的時候，我無從入手，怎麼辦呢？”......這裡面就引出了監控的意義：線上的異常通常會導致不穩定性，不穩定性會帶來損失，所以說我們監控系統最主要的目標就是縮短異常的平均修復時間MTTR。異常的修復過程我們可以總結為三個步驟：see-know-act。這是一個迴圈的過程，提出一個核心的要求，就要足夠快速地採集線上的資料，透過快速觀察、假設、分析結果從而快速找到規律、發現異常，快速行動止損——我們平均修復時間越短，受到的經濟損失就會降得越低。

監控手段可以分成三大支柱：

- Metrics：以時序監控指標為代表的監控指標系列

時序資料就是一堆離散的點，每個點包含一個時間標識time，一個value標識，這個就是最基本的時序指標。

- Logging：日誌系列

日誌部分大家應該接觸得比較多，應用系統裡面通常都會打日誌，為了在除錯時更方便地看到系統在這個時刻的執行狀態是什麼樣的。日誌一般會分為兩種型別：一種是非結構化的日誌資料，一種是對日誌資料做結構化，做結構化的那個日誌資料其實會有更多的分析優勢。

- Tracing系統：分散式跟蹤系統

Tracing系統就是分散式鏈路跟蹤，透過給請求一個唯一標識，那麼它經過的每一個服務都記錄下它的呼叫路徑，並且記錄下它在該服務的處理時間、異常日誌各種資訊和相關事件資訊，我們可以得到全鏈路的鏈路圖，以便進一步瞭解系統、追蹤問題。

目前業界採用最廣泛的是Metrics系統，它的資料時效性是最強、最有效的，能夠讓你最快發現系統的異常。而Logging日誌系統主要是用於分析的場景，時效性比較中等，一般當發生告警、異常的時候，透過Metrics已經觀察不出來可能的問題或是隻能限定問題範圍，就需要日誌來進行進一步的分析。

基於Prometheus的監控方案

監控系統其實就是個資料處理系統，包含資料的抽象、採集、儲存、計算和資料的使用，下面我們就來介紹下監控方案Prometheus。Prometheus是CNCF下最早期畢業的專案之一，現在是時序監控領域、雲原生領域的事實監控標準，整體架構設計非常優雅。

中間這一部分 Prometheus Server是一個單體應用，可以獨立啟動。我們可以針對其配置採集任務。不同的元件PaaS產品基本都有通用開源的Exporter，透過這種方式可以很好地利用開源，便捷的採集各類產品的監控資料。採集管理之後就是儲存，Prometheus內含了一個TSDB。可以針對時序指標資料做儲存及計算。儲存完資料之後需要暴露給使用者使用，它透過一個Restful的API來實現。透過外層使用Prometheus的原生UI，我們可以呼叫它的介面來獲取相關的資料，進行相關的實時分析，也可以採用Grafana這個觀測性領域最為廣泛應用的工具來檢視。

藍色框裡的是 Prometheus跟K8S的結合，為什麼說Prometheus是雲原生的事實監控標準呢？它跟K8S是無縫整合的，只要使用者在K8S裡面宣告瞭一個service或是一個註解，那麼Prometheus就會自動做服務發現，把相關例項的監控資訊自動抓取出來，完全實現對應用和監控的分離。

最後我們介紹一下 Alertmanager，它是Prometheus裡面第二個二進位制檔案，實現了對告警的處理。Prometheus可以設定規則觸發告警，但是Prometheus本身不負責發出告警，這時候就需要把Alertevents push到Alertmanager。Alertmanager負責報警的傳送、收斂、沉默相關的功能。

下面透過Prometheus介紹一下 Prometheus對資料的抽象，以便我們對監控系統整體的資料抽象有個大概的瞭解。什麼是時序資料呢？我們前面講到過，其實就是由一個時間time和一個value構成的一個影響的序列，那麼在Prometheus裡面，它除了有time和value以外，還有一個metric name，如記憶體指標，CPU空閒、記憶體用量，都透過metric name標識。目前主流的TSDB系統基本都支援時間達到秒級或者毫秒級精度為主。取樣頻率一般推薦週期型的取樣，比如一臺雲主機可能每5秒鐘暴露一個監控資料點，把相關所有的監控資料指標暴露一次，Prometheus來定實抓取一次，這樣就可以形成長期的時序曲線。還有另外一種更偏重業務場景的離散型，比如當某個使用者訪問時，我在這一分鐘內把這個使用者訪問記錄、請求數量標記下，如果他在下一分鐘不訪問了就不標記，這種取樣方式可以顯著降低監控量。

下面我們介紹下 Prometheus的資料查詢語言PromQL。需要指控一個監控指標的名稱、聚合維度以及需要指定一個計算因子，我們叫它“運算元”。下面介紹一個使用者場景：使用者A擁有1萬臺雲主機，雲主機的監控資料粒度為5秒一個點，如何做到秒出一個月CPU使用率趨勢圖資料呢？使用者在控制檯裡面不可能等待很長時間，這個時候大概有50億的資料需要在該次請求裡面被訪問，這時該怎麼做？我們目前採用的方案也是業界通常採用的方案，就是採用降取樣+預聚合的方式，將預算前置，大幅度降低資料規模，確保查詢的實時性。我們提前把資料規模降下來，比如原來有50億個原始資料點，透過降取樣和預聚合可能只有1萬個點了，這時候我們做一個API查詢查詢出這1萬個點，就可以實時反饋給使用者系統。

降取樣和預聚合是監控資料處理領域最主要的兩種計算方式。降取樣是指在時間維度上，把細粒度的資料聚合成一個時間粒度更粗的形式。在上面的第一幅圖中，原來資料有3個點，每個點5秒鐘上報一次，那麼這時對這個原始點做一個降取樣處理，把3個點透過某種運算元聚合成一個點，那麼給使用者展示的資料粒度其實會變成15秒一個點，資料粒度變得寬泛了，但是返回的資料規模其實降低了3倍，這就是降取樣的過程。

跟降取樣對比的話，欲聚合是在時間軸上做聚合運算，把資料規模降低，而預聚合是在Y軸value相關的維度上做運算，以此來降低資料規模。假設按照上面來說，使用者有1萬臺雲主機，雲主機監控資料上面標註了使用者的user資訊以及雲主機的ID資訊，這時就需要對每一個時間點做一個預聚合，跨維度預算只保留使用者的user資訊，把雲主機的ID忽略掉，這時候就可以把1萬個點透過某種運算元聚合成1個點，以此降掉的資料規模達到1萬倍。

基於EFK的日誌方案

當購買了一臺雲主機，應用產生了自己的業務應用日誌，如何把它採集到服務端並進行統一的展示呢？

我們介紹一個最簡單的方案，就是EFK。

在日誌方案上，EFK（Elasticsearch、Fluentd、Kibana）是雲原生領域最為主流的日誌管理方案。Fluentd是CNCF裡面畢業較晚的一些專案，它可以把各種資料來源的日誌進行統一化的採集，利用內建的Pipeline實現採集、處理之後投遞的功能。

我們簡單介紹一下Fluentd的工作流程。上圖是一個典型的Fluentd的配置，主要分為三個block：第一個是source部分，source就是指定採集的日誌源，可能是一個檔案、一個HTTP介面、也可能是一個TCP。透過定義採集資料來源，把資料抓到本地程式裡。抓過來之後需要對相關資料做一個匹配處理操作。Fluentd是一個開源專案，支援獨立部署，在跟K8S整合的過程中往往需要把它的container資訊、workload相關資訊都附加過來，這時就需要利用到它的filter功能，為它附加workload上的相關標籤，以此達到每一條日誌都可以知道它是哪一個workload產生的、哪個APP產生的目的。資料採集和處理完之後，這時就需要把它發到服務端。我們可以在這指定一個type elasticsearch，直接把它投遞到ES裡邊，做一個日誌的索引，到時就可以進行相關的檢索了。

京東目前的整體方案原理上和這個類似，只不過做了些企業級的支援。我們的採集端做了Fluentd開源適配，會把資料傳輸到Kafka裡做資料的中繼，中繼下面對接實時分析系統、索引系統等相關係統。

這裡展示了資料被採集投遞到ES之後，我們用KIbana進行檢索的一個事例。左側我們可以看到容器的ID、name，相關的label也可以採集到，假如我們在自己的工作負載上打一些標籤，那麼採過來的日誌會自動打上這個標籤，告訴你這個是應用A還是應用B產生的日誌。另外一個是中介軟體MySQL產生的日誌，有了這些標籤，它就可以按照業務進行相關檢索分析，也可以做相關的資料檢視。右邊是做資料檢視的一個事例，在這展示了不同POD的日誌資料量比例，可以看到大概佔75%。

京東智聯雲在雲原生監控&日誌的落地實踐

京東智聯雲定製了一套監控的標準，分為四層監控：

首先是基礎監控，主要是指機器資源、物理機的一些監控，面向K8S叢集運維、物理資源相關運維等內容。

其次是存活監控，也叫健康檢查，透過簡單的手段對應用進行定時探測，每1分鐘過來探測一下這個應用是不是健康的。我們可以使用的方式就是程式、埠監控，進行簡單的語義監控。

第三部分是應用效能監控。在監控領域，業界通常採用的是谷歌提出的四大黃金指標：流量、資料的錯誤率、平均延遲以及容量。大家對容量關注的不多，但是PV、平響、錯誤碼這三個指標是衡量一個系統健康與否、是否符合預期的重要依據。

最上面一層是業務監控。有時候我們也從使用者的視角進行相關的探測，比如開啟京東APP的時候，從一個終端使用者來看，APP首頁的資訊介面是不是足夠健康、足夠快速呢？這時候我們就需要做一些外部的探測。

我們在K8S的監控方案大致如此。雲K8S裡面我們部署了各種的exporter，比如MySQL服務、ES等，包括使用者自定義的應用、自己的監控介面等。

我們同樣使用原生的Prometheus對資料進行抓取，整體流程和上面介紹的Prometheus方案是一樣的，唯一做的改造不是用本地儲存，而是用Remote write的方式，透過京東智聯雲的openAPI把資料推送到了雲監控。雲監控資料過來之後，首先做個資料中繼推到MQ裡，把資料雙寫到tsdb cache 和tsdb storage裡邊，再對其中相關的計算任務進行剛才預聚合任務、抽樣任務。

這裡再詳細說一下TSDB。TSDB是我們自研的一款時序資料庫，之所以自研就是因為市面上的TSDB不能滿足企業級的需要。很多企業都選擇了自研。我們剛才介紹到Prometheus是單層應用，它能支撐的量是有限的。當資料規模達到一定程度時，Prometheus就會成為瓶頸，所以不能直接採用Prometheus，必須有一套自己驗證大資料量的TSDB解決方案。

我們的TSDB相較於傳統的TSDB有以下幾個特徵：

- 資料壓縮：採用gorilla的壓縮演算法，資料量大幅壓縮。資料如果太臃腫的話，記憶體會消耗大量資源，而透過資料壓縮之後，資料體量是極小的，可以加速我們的查詢支援。

- 快取層：記憶體快取近28小時的資料，使得查詢效能成倍提升，提高了系統的可靠性，目前可以達到幾十萬的QPS。

- 抽樣+路由：靈活的抽樣規則，自適應路由，按需使用抽樣資料，提高效能。當使用者來查詢時，28小時之內的資料會讓他路由到tsdb cache進行實時的記憶體查詢；如果時間很長，比如使用者要查詢1個月的資料，那麼我們會把它路由到tsdb storage來進行一個全量的查詢。

- 預聚合：分散式實時計算框架，熱點自發現、自修復。

- 儲存與計算分離：計算能力按需伸縮，降低資源成本。tsdb架構採用儲存與計算分離的架構，資料可以長期儲存，成本極其便宜。

- 全面相容prometheus介面及語法規範：其實我們現在相容兩種協議：Prometheus和openTSDB，我們雲上K8S的對接方案完全就是按照Prometheus的格式進行對接的。

我們的內部監控系統構建依然是圍繞著See-konw-act流程的，所以也圍繞See-konw-act做了些相關的工作。

如何讓使用者發現問題呢？如果只能靠使用者提前設定指標的話，那麼使用者的覆蓋程度可能會有遺漏，所以系統會自動幫使用者做多維度的聚合運算，做相關時序指標的異常檢測，比如恆定閾值、突升突降、同環比、3-sigma等方式，看是不是符合動態分佈的資料。當我們檢測到一條時序不符合的時候會自動觸發告警，幫使用者更快發現系統的異常。

那如何讓使用者更快地診斷異常、定位問題所在呢？我們提供相關實時大規模跨維度分析計算能力，也提供異常診斷，即根因定位。我們提供了複雜查詢的分析手段，在不影響線上服務穩定性的情況下，允許使用者線上上直接做相關請求的抽樣，以此來獲取更多線上資料資訊，來診斷問題、定位問題。

問題被定位之後，該如何執行呢？告警是最簡單的，但是我們要保證告警資訊的觸達能力。假如DNS出了問題，那麼整個網路就癱瘓了，但是監控系統是不能癱瘓的，所以我們也做了相關的穩定性保障：當網路癱瘓的時候，我們的告警依然能夠觸發出來。另外，告警的分組、收斂、分級、升級以及遮蔽都是企業級需要的功能。

京東智聯云云原生監控實踐

上一期我們講了京東智聯雲的DevOps，DevOps最終應用釋出之後就到了運維和監控環節。線上應用釋出之後，我們需要觀測它的執行指標，當線上出現異常時，我們觀測它的日誌以便我們定位問題。我們還可以從外部進行判測，比如我可以從廣州電信、河南聯通分別探測服務是不是可以正常訪問，這就是我們京東智聯雲的雲撥測服務；當雲主機重啟、K8S產生一系列事件時，我們的雲事件服務會通知使用者做一些相關的告警以及自動化操作——這就是我們的運維和監控體系。