在線公開課 | 監控與日誌的黃金法則

時間 2020-04-24

標籤在線開課監控日誌黃金法則简体版

原文原文鏈接

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

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

監控一般是從總體上了解網站的狀況，須要具有實時性，而日誌則是詳盡地記錄着系統運行狀況，每一次Service的調用，每一次數據庫的訪問，都應該寫進日誌，特別是當系統出現問題時，咱們但願日誌系統能提供完整的錯誤堆棧和儘量完備的上下文，從而爲系統維護提供支持。數據庫

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

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

六週玩轉雲原生

走近監控與日誌，雲原生基石探祕網絡

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

雲原生下的可觀測性

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

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

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

下面咱們說一下這個監控的意義。咱們一般會遇到一些問題，好比：「這個服務我感受它好像不太正常，可是我也不知道系統究竟是不是有問題？」「這個問題我修了很長時間，可是尚未修復，壓力山大怎麼辦呢？」「好不容易看到異常信息，可是一堆信息，我無從查找，怎麼辦？」「我部署了一個微服務應用，可能七八十個子系統的管理員，線上出問題了，我要去排查它的時候，我無從入手，怎麼辦呢？」......這裏面就引出了監控的意義：線上的異常一般會致使不穩定性，不穩定性會帶來損失，因此說咱們監控系統最主要的目標就是縮短異常的平均修復時間MTTR。異常的修復過程咱們能夠總結爲三個步驟：see-know-act。這是一個循環的過程，提出一個核心的要求，就要足夠快速地採集線上的數據，經過快速觀察、假設、分析結果從而快速找到規律、發現異常，快速行動止損——咱們平均修復時間越短，受到的經濟損失就會降得越低。elasticsearch

監控手段能夠分紅三大支柱：

- 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產生一系列事件時，咱們的雲事件服務會通知用戶作一些相關的告警以及自動化操做——這就是咱們的運維和監控體系。