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

新時代技術背景下，運維面臨的挑戰(zhàn)加劇：

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

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

2）云原生、微服務技術應用

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

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

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

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

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

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

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

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

1）總體定位

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 在Logger配置中引用這個Appender

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

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

這里會進一步分為三種不同類型的場景：

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

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

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

• 下鉆到進程所在的主機/容器集群排查問題

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

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

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

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

04. 結(jié)語

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