01. 運(yùn)維挑戰(zhàn)加劇

新時代技術(shù)背景下，運(yùn)維面臨的挑戰(zhàn)加?。?/span>

1）業(yè)務(wù)數(shù)量日益增加、業(yè)務(wù)規(guī)模日益龐大

隨著科技發(fā)展進(jìn)步、民眾生活富足，線下業(yè)務(wù)線上化、線上業(yè)務(wù)復(fù)雜化趨勢愈演愈烈，各行各業(yè)投入巨大人力物力財力進(jìn)行企業(yè)IT建設(shè)。隨之而來的是線上業(yè)務(wù)數(shù)量的爆炸式增加與業(yè)務(wù)規(guī)模的劇烈擴(kuò)張，這對企業(yè)IT運(yùn)維人員提出了全局把控能力的重大挑戰(zhàn)。

2）云原生、微服務(wù)技術(shù)應(yīng)用

伴隨著業(yè)務(wù)增長，IT架構(gòu)領(lǐng)域提出了云原生、微服務(wù)的構(gòu)建理念，將傳統(tǒng)的大體量、高耦合應(yīng)用系統(tǒng)拆分為微型化、可拆卸的分布式模塊。這種高可用性、高靈活度的部署架構(gòu)使得運(yùn)維人員更難了解系統(tǒng)全貌，在日常監(jiān)控和故障現(xiàn)場還原時難度極大。

3）容器技術(shù)的大規(guī)模實踐落地

與此同時，在資源調(diào)度層面，為應(yīng)對上述現(xiàn)狀帶來的業(yè)務(wù)快速迭代、運(yùn)行保障維穩(wěn)需求，容器技術(shù)在各企業(yè)內(nèi)部快速落地推廣。容器對基礎(chǔ)資源的弱依賴、Pod/Container頻繁起滅的特性都給運(yùn)維工作帶來了難以估量的復(fù)雜度提升，人力沒有算力快的“弱勢”日益凸顯。

綜上所述，在當(dāng)今企業(yè)內(nèi)部，運(yùn)維工作越來越需要工具的協(xié)助，傳統(tǒng)人工式的運(yùn)維方案，已無法應(yīng)對科技發(fā)展帶來的挑戰(zhàn)要求。

02. 企業(yè)應(yīng)用觀測建設(shè)路徑

面對上述挑戰(zhàn)，企業(yè)常常會踏上構(gòu)建可觀測性工具體系的征途，而在融合ITIM基礎(chǔ)監(jiān)控之后，針對應(yīng)用的可觀測能力補(bǔ)充往往在中間階段進(jìn)行建設(shè)落地。

• 針對應(yīng)用的可觀測體系，首先需要建設(shè)狹義上的應(yīng)用監(jiān)控工具（APM），通過請求跟蹤（Trace）標(biāo)記，實現(xiàn)應(yīng)用架構(gòu)可視化、應(yīng)用流量指標(biāo)化、請求記錄數(shù)據(jù)化；
• 在觀測數(shù)據(jù)補(bǔ)足后，應(yīng)用觀測進(jìn)入下一階段建設(shè)目標(biāo)——數(shù)據(jù)聯(lián)動，將應(yīng)用觀測數(shù)據(jù)（Trace）和指標(biāo)（metric）、日志（log）關(guān)聯(lián)起來；通過多維度視角監(jiān)控業(yè)務(wù)系統(tǒng)運(yùn)行狀況，為告警產(chǎn)生后的故障定位提供可追溯的現(xiàn)場記錄。

03. 企業(yè)應(yīng)用觀測建設(shè)思路

1）總體定位

鏈路追蹤的工具，即前面提到的APM，因為其自動化生成了一系列數(shù)據(jù)之間的關(guān)聯(lián)關(guān)系，在整個可觀測體系中是一個類似中樞的存在。

這張圖概括了鏈路追蹤在整個可觀測體系建設(shè)中的定位以及與其他工具的關(guān)聯(lián)關(guān)系：

• 向前可關(guān)聯(lián)到用戶操作，鏈路追蹤可以將用戶在終端上的發(fā)起的請求和后端鏈路聯(lián)系起來，實現(xiàn)前端到后端完整的時間線和因果關(guān)系呈現(xiàn)；
• 向后則可串聯(lián)到具體日志，鏈路追蹤可以定位到具體某個服務(wù)的某次或某一批請求，從而精確匹配到相關(guān)日志來解析問題所在；
• 向下則可以在鎖定某個服務(wù)節(jié)點問題后，通過資源標(biāo)簽定位到具體承載這個服務(wù)節(jié)點的進(jìn)程級監(jiān)控和主機(jī)操作系統(tǒng)層級的監(jiān)控，或是容器平臺的監(jiān)控。

另外鏈路追蹤本身也是可以進(jìn)行一些指標(biāo)提取的，經(jīng)典指標(biāo)例如請求量、請求成功率、各種分位的時延，這些指標(biāo)在配置了一定的告警規(guī)則后，也都可以直接作為告警來源。產(chǎn)生異常后主動觸達(dá)運(yùn)維人員。

由此可見，在構(gòu)建全面的可觀測性體系時，孤立地看待與應(yīng)用性能管理（APM）工具的建設(shè)是一種偏頗的思路。不少企業(yè)曾嘗試獨立為APM工具設(shè)立項目并推進(jìn)實施，然而最終這些工具并未能實現(xiàn)廣泛的采納與應(yīng)用，項目所帶來的實際效益遠(yuǎn)低于初始預(yù)期。究其根本，是因為單一的APM工具所能覆蓋的問題場景極為有限。我們應(yīng)當(dāng)將APM盡可能和各類其他觀測工具做串聯(lián)打通，通過APM建立起基于業(yè)務(wù)實際請求流量的“橋梁”，有目標(biāo)性地拉通各個觀測工具和不同類型的觀測數(shù)據(jù)，實現(xiàn)完整有效的觀測效果。

接下來我們就具體的串聯(lián)打通場景提出一些具體實踐供各位讀者參考。

① 前端到后端串聯(lián)排障

當(dāng)具備對用戶終端數(shù)據(jù)進(jìn)行采集的能力，那就可以結(jié)合這種前端監(jiān)控工具（RUM）和鏈路追蹤工具（APM）通過一些機(jī)制來實現(xiàn)前端到后端的串聯(lián)排障。

圖中可以解釋這一過程的原理，用戶在移動應(yīng)用或者Web瀏覽器網(wǎng)頁上訪問時，會生成一個Session被記錄，一個Session中記錄了一個用戶的完整操作流程，包括他依次打開了哪些頁面，在每個頁面上進(jìn)行了怎樣的操作，觸發(fā)了哪些后臺請求。當(dāng)產(chǎn)生了一個具體的后臺請求后，RUM工具可以按照APM工具定義的Trace標(biāo)識規(guī)則（TraceID的生成規(guī)則），來對這個請求進(jìn)行標(biāo)記，這樣在后端也可以完整跟蹤到這個請求在后端系統(tǒng)具體經(jīng)過了哪些服務(wù)，在哪個服務(wù)上處理消耗的時間過長或者出現(xiàn)了報錯。

② 鏈路跟蹤與日志關(guān)聯(lián)

對于開發(fā)人員來說，直接將問題定位到代碼級別是最高效的。但告警信息的有限以及指標(biāo)類數(shù)據(jù)的高度抽象，使得運(yùn)維人員在很多時候其實無法給出這么詳細(xì)的信息，無法有效輔助開發(fā)人員進(jìn)行問題定位和解決。這時，鏈路追蹤和日志關(guān)聯(lián)的方式就給出了一種有效的解決手段。

具體的實現(xiàn)方式如下圖所示：

可能會有工程師擔(dān)心這種方式對代碼侵入性很大，很難實踐，但其實不然，業(yè)界有非常多好用的日志框架來幫你解決這個問題，我們只需要額外生成一份日志輸出的配置文件做批量下發(fā)即可。

以下就用Logback日志框架配合Skywalking探針（一種業(yè)界流行的開源APM探針）來做個例子，其中關(guān)鍵的修改點在于：

• 引用skywalking官方提供的工具類

• 在Logger配置中引用這個Appender

在這個過程中，業(yè)務(wù)并不會有很大感知，只是會發(fā)現(xiàn)他們輸出的日志中增加了Skywalking注入的TraceID等信息。接下來我們在日志解析過程中就可以提取這些Trace信息，便于后續(xù)直接根據(jù)這些Trace信息進(jìn)行關(guān)聯(lián)檢索和分析。

③ 鏈路追蹤下鉆到資源層監(jiān)控

這里會進(jìn)一步分為三種不同類型的場景：

• 下鉆到組件或數(shù)據(jù)庫排查問題

APM所捕獲到的調(diào)用數(shù)據(jù)中，有一部分是對組件或數(shù)據(jù)庫的調(diào)用。這種調(diào)用可以將系統(tǒng)所用到的組件和數(shù)據(jù)庫直觀地呈現(xiàn)在拓?fù)鋱D和某一條具體的調(diào)用鏈中，如果相關(guān)的組件或數(shù)據(jù)庫出現(xiàn)了問題，大概率會在這種可視化的形式中有所體現(xiàn)，例如拓?fù)鋱D上的狀態(tài)呈現(xiàn)以及調(diào)用鏈瀑布圖中的長條。當(dāng)然，這里只是解決了發(fā)現(xiàn)的問題，我們只能在APM中判斷這些組件或者數(shù)據(jù)庫的故障對上游調(diào)用者產(chǎn)生了影響，但至于為何產(chǎn)生以及這些組件及數(shù)據(jù)庫的真實運(yùn)行狀態(tài)，我們?nèi)匀恍枰柚渌O(jiān)控工具來呈現(xiàn)和分析。

此時APM可以在調(diào)用信息中提取出對應(yīng)組件或數(shù)據(jù)庫的資源標(biāo)識，這可能是IP地址，或是域名鏈接，再通過這些標(biāo)識信息去對應(yīng)的組件監(jiān)控或數(shù)據(jù)庫監(jiān)控中獲取到這些資源的核心監(jiān)控指標(biāo)信息及相關(guān)日志，通過同一個平臺的頁面跳轉(zhuǎn)或者嵌入來實現(xiàn)一套連貫的排障流程，提升此類場景的排障效率。

• 下鉆到進(jìn)程所在的主機(jī)/容器集群排查問題

當(dāng)我們在系統(tǒng)中通過APM探針或者SDK按照規(guī)范要求上報了Trace信息，一般都會攜帶對應(yīng)服務(wù)所在的主機(jī)或者容器集群信息，最常見的就是主機(jī)的IP地址以及容器的ContainerID，這兩種信息會作為我們?nèi)で笃渌O(jiān)控工具時對主機(jī)和容器監(jiān)控的索引，從而能夠在識別到某個服務(wù)節(jié)點故障后，對其所在的主機(jī)或者容器進(jìn)行下鉆，查看到主機(jī)和容器層級上更加精確的指標(biāo)數(shù)據(jù)或者容器數(shù)據(jù)。

• 下鉆到網(wǎng)絡(luò)行為分析網(wǎng)絡(luò)問題

我們知道，計算機(jī)網(wǎng)絡(luò)其實底層有七層協(xié)議，而我們平時大多數(shù)情況會將這七層協(xié)議轉(zhuǎn)化抽象成單次請求。但不排除，有時我們的故障發(fā)生在比較深的網(wǎng)絡(luò)層面，在APM調(diào)用鏈中只能得知某一段span的耗時增加、返回碼錯誤或者無響應(yīng)斷鏈，無法進(jìn)一步排查深層次的網(wǎng)絡(luò)問題。這時就可以通過這一進(jìn)程將請求的span獲取到內(nèi)核態(tài)的 sys span ，再從sys span映射到網(wǎng)絡(luò)監(jiān)控中的具體net span，然后就可以從專業(yè)的網(wǎng)絡(luò)監(jiān)控中獲取到這次網(wǎng)絡(luò)請求在各個環(huán)節(jié)的詳細(xì)信息。

通常某次請求出現(xiàn)網(wǎng)絡(luò)問題的概率還是比較小的，往往是短時間大面積出現(xiàn)網(wǎng)絡(luò)問題，這個時候我們也可以從APM的某些樣本請求中獲取一個大致的范圍，接下來按一定條件跳轉(zhuǎn)到專業(yè)的網(wǎng)絡(luò)監(jiān)控，查看相應(yīng)的指標(biāo)趨勢（例如丟包數(shù)量、丟包率、CRC校驗通過率等）。

04. 結(jié)語

以上，我們介紹了比較成熟理想的企業(yè)應(yīng)用觀測中樞建設(shè)方案?？偟膩碚f，應(yīng)用觀測領(lǐng)域目前尚處于快速發(fā)展、落地探索階段，各企業(yè)在建設(shè)應(yīng)用觀測中樞的過程中不應(yīng)操之過急。企業(yè)內(nèi)部從一個試點出發(fā)，以點帶面，逐漸推廣是比較理想且穩(wěn)妥的建設(shè)節(jié)奏。其最終實現(xiàn)的觀測能力也將會對企業(yè)內(nèi)部的系統(tǒng)維穩(wěn)及代碼調(diào)優(yōu)起到極大的助力作用。