本文我們聚焦可觀測的另一個重要支柱——日志管理，從日志的數據特點角度出發，分析日志數據在可觀測體系中的意義，深度剖析日志與可觀測體系融合建設的難點與思路，并分享企業日志系統設計選型思路以及落地實踐參考。

01. 從數據特點看日志與可觀測

1）指標數據和日志數據的區別

首先我們來看一個企業中比較普遍的現象，當系統發生故障時，運維人員通常關注指標類數據，而研發人員更“鐘情“于日志數據，為什么會有這種區別呢？

從兩個方面來分析，第一個方面就是運維與研發自身職責的不同，運維更希望能夠快速的解決問題，而研發更注重于準確找到問題的根源。第二個方面就是指標數據與日志數據的本身特點具備著差異性。

運維人員能夠通過指標數據，快速地了解當前系統的狀態，通過指標聚合，從業務一步步追隨到集群、再到具體的節點。而日志數據能夠詳細記錄到代碼執行的過程，如果能夠收集到包含根因的日志數據，那么研發人員就可以非常準確地鎖定故障發生的位置和原因，從而進行修復工作。

指標數據：以數字形式呈現，可聚合并持續穩定輸出，數據直觀、精確，通常用于查詢和展示。

日志數據：以文本形式承載，不可聚合，輸出并不具備周期性，通常數據量較大，需要從海量日志中找到所需要的字段進行進一步的處理。

2）如何實現破局，發揮日志數據價值？

透過以上這類現象，不難發現，日志數據在傳統的運維過程中，由于數據量大，價值信息少，文本形式的數據也無法像指標一樣，進行有效聚合，掌握全貌，日志數據無法高效定位，也使得日志在傳統運維中應用范圍受到限制。

而如今可觀測時代下，日志數據要想解決以上存在的這些問題，發揮數據價值，實現成功破局，核心必須聚焦在提升日志數據傳遞到人的價值密度。通常商業化或開源日志工具會具備以下四種特點，實現日志數據價值呈現：

• 日志主動監控：利用機器來自動化檢測文本，獲取有效信息后再輸出。
• 結構化：清洗成結構化數據后，對某些字段進行統計。
• 可觀測串聯：將其他類型的觀測數據于日志串聯，快速定位。
• 日志聚類：將日志用機器學習算法進行分類后再統計。

前三種往往是單獨在日志系統內部可以完成的，第四種則會涉及到可觀測的體系化建設，這里可能不只是一個技術實現的問題，還需要依賴企業對可觀測理念的感知和認可。本文也重點就這個話題進行展開。

3）可觀測三大支柱數據聯動，快速定位問題

云原生時代IT可觀測的三大支柱數據：Metrics，Tracing，Logging，日志數據在其中承擔著“排障的最后一公里”的角色，基于其信息量大的特點為研發、運維提供最直觀豐富了解到IT系統運行的細節信息。

隨著可觀測體系的技術發展，可觀測三大數據的融合和串聯，已經成為提升日志價值信息密度的重要手段，前端的Metrics，Tracing數據就宛如快捷的交通工具，而故障的最后一公里就需要依賴日志數據來支撐，融合串聯，快速定位關鍵信息點。

4）日志數據在可觀測時代的全新意義

近年來，隨著SRE理論的推廣，運維角色職能發生了變化，從聚焦于底層資源的穩定性，變為需要關注整個服務對上層業務支撐的可靠性，這個過程中，對全局架構和上層業務的一定了解是必須的。

在這種情況下，傳統的監控指標已經不滿足于運維的需求，要從運維角度去了解整體架構和業務，而這一過程中，可觀測技術就是一把鑰匙。在可觀測體系中，日志數據代表著一個個Event事件，不再是大面積的平鋪陳列，而是作為觀測結果的必備屬性，與其他數據相輔相成，在新的運維模式下扮演著更加重要的角色。如此即是可觀測技術發展給日志數據賦予的全新意義。

02. 開源社區與企業實踐探討

以上是基于理論來闡述新時代日志和可觀測密不可分的關系，那么在實踐層面，可觀測技術又是如何推動日志數據的呢？我們首先先了解一下開源社區關于日志的發展歷程。

早期的可觀測開源項目基本都是圍繞著 Trace 這一類數據開展的，而隨著可觀測技術的發展，可以看到，日志在最新的OT協議中，已經被納入標準規范。

OT協議希望能夠統一日志規范，其目的也是想將可觀測三支柱數據中最難結構化的數據也進行一定程度的規范，最終形成一套相互關聯的數據作為可觀測平臺的數據后臺。這個在其官方推薦的新版OT數據采集架構中就可以體現，它希望我們在匯聚三種數據的時候，有一個統一的富化過程，加強三種數據的關聯性，從而能更好發揮觀測數據的實際效用。

接下來我們來看一個有趣的企業實踐，很多企業會嘗試去使用日志數據作為底座來建設可觀測平臺，認為這是可觀測性建設的一種可靠方案，但事實上，基于日志數據構建可觀測體系的方式仍然是優劣并存的。

如果未來OT協議真的能覆蓋到每種觀測對象并將日志輸出標準統一，那么這種方式確實有一定的好處，除了代碼無入侵以及組件復雜度降低，更重要的一點好處就是日志數據和其他的觀測數據可以天然串聯，更方便實現前文所提到的串聯排障以及架構分析。

但是目前這種方式也存在很大的局限性，規范推行的本身也是需要一定時間的，而且很多企業所擁有的存量系統十分繁多復雜，如果進行改造，建設可行性和周期都是一個很大的問號。

接下來我們就來針對日志與可觀測融合建設的幾個難點進行更加深入剖析，給出一些的有效的建設思路和方法。

03. 日志與可觀測體系融合建設的難點與思路

1）可觀測體系中的日志與其他數據串聯的難點

前面提到，日志數據可以通過可觀測數據的相互串聯來提升自身的數據價值，那么在具體建設中會遇到哪些難點呢？

① 難點一：數據格式不統一。在中大型企業中，還有不少老舊設備的日志，這些日志數據需要經過加工處理才可以識別出必要字段

解決思路：清洗轉化，格式兼容

② 難點二：數據采集方式不統一。指標類數據，目前流行的采集方式已達上百種，有特有協議，有自定義輸出，但一般會在demension中包含資源ID之類的上下文信息

解決思路：提取公共因子為關聯線索（時間、資源ID等）

③ 難點三：煙囪式工具，前臺界面無法串聯。很多企業有傳統的監控工具，也有專門的日志系統，即使數據關聯上了，兩者的界面難以打通，串聯觀測的體驗仍舊不佳

解決思路：盡量選用可拓展性較強的產品，或者一開始建設時就選用融合設計的產品

2）關聯日志數據的解決方案

針對這些難以關聯的問題，我們也有對應的關聯手段。同時企業間存量日志情況各不相同，可以使用不同的方式做可觀測關聯。

• 通過執行時關聯：日志、跟蹤和指標都會記錄發生的時間或時間范圍。這是最基本的關聯形式。
• 通過請求上下文關聯：盡可能通過在日志記錄中包含 TraceId 和 SpanId 來記錄日志和請求的關系，這樣每次跟蹤到一條具體的請求時，也能快速找到這個請求產生之后所觸發的日志。
• 通過資源上下文關聯：指標數據和跟蹤數據中也會包含一定的資源數據，例如主機IP或服務地址，如果能確定好這些資源關系的映射，可以進一步縮小關聯日志的范圍從而做到精準排障。

在實際的可觀測系統落地的過程中，不同類型日志需要采用不一樣的關聯方式，常見關聯方式如下圖：

04. 企業日志系統設計思路與選型建議

1）日志系統設計思路

如何設計企業日志系統呢？傳統日志系統通常采用5層式獨立結構，但這樣的建設模式，排障時需從大量日志數據入手，難以快速定位到問題。

而隨著可觀測技術的發展，很多企業開始建設監控系統、日志管理系統、調用鏈追蹤系統，但由于分開建設，底層數據之間無關聯。雖然實現了三大支柱數據的系統建設，但彼此之間屬于煙囪模式，無法有效聯動，難以有效提升故障定位效率。

而雙價值鏈條所驅動的企業級日志系統，通過日志數據流轉鏈和可觀測全景數據鏈的驅動，解決了日志數據“管理難”，“應用難”的問題。全棧可觀測平臺的建設，提供了一站式的排障能力，支持統一告警與統一展示，降低故障排查難度，提升排障效率。

2）企業日志系統選型建議：

結合上文提到的設計思路和難點，我們為企業日志系統選型提供以下幾點建議：

① 選用覆蓋完整的，且各類觀測工具可自由組合的可觀測平臺

覆蓋完的工具或平臺，往往從一開始就會考慮幾種數據之間的融合設計（不僅局限于數據，還有UI界面上的串聯），避免煙囪式建設。

同時以融合理念進行設計的產品，可以根據自身現狀分批、分階段建設，有限控制建設成本，實現最終的可觀測體系建設，讓企業能夠順利轉型過渡。

② 選用支持開源協議的云平臺或商業產品

• 順應業界主流趨勢：開源社區（OT）已經在很早期就開始設計幾種數據的關聯關系，并逐步迭代。
• 方便拓展對接：可以與自己早期使用的開源工具或者組件相互對接，兼容存量系統。
• 生態長存：采集和處理工具千千萬，唯開源生態長存，可拓展和替換是必須考慮的因素。

③ 需具備強大的日志清洗能力，沉淀常用組件清洗模板

助力標準化建設：有利于減輕落地推廣的難度，提升觀測體系的覆蓋度，沉淀經驗和標準，也有利于規范的落地。

05. 案例分享

1）某新能源企業運維一體化項目

① 建設背景

• 日志數據異構：和多家國內外企業有合作，對接的核心系統多達數十個，有自研、外購、外購二次開發、開源改造的企業系統，架構不一，日志多樣且分散。
• 日志規模爆發式增長：自建大數據平臺進行供應鏈分析、設備健康管控以及園區智能管理，日志規模隨著新能源業務迅猛發展而爆發式增長，每日TB級別日志流量，日志數據采集鏈路性能壓力極大。
• 日志主題劃分困難：多業務方，相互依賴關系復雜，日志主題劃分難度大，無法高效查詢分析日志，無法關聯分析日志。
• 硬件監控落后：缺乏有效的監控手段，硬件設別廠商多種多樣，需要針對每種硬件設備制作專門的監控指標采集插件或告警源插件，成本極高，且需要專門的技術人員針對這些硬件的指標數據進行值班監控。

② 建設內容

針對該企業現狀，嘉為鯨眼日志中心為其打造了相契合的解決方案，集中納管公司60+業務、4000+節點的日志，日數據量3TB+，制定60+系統的200+項監控策略，出現故障問題及時多渠道通知對應的專業人員進行排查，故障響應效率提升30%以上。

2）某銀行企業日志集中化改造項目

① 建設背景

• 日志串聯繁瑣：運維人員查看日志時往往需要根據交易串聯日志，當前日志串聯是通過各個應用管理員人力傳遞式查詢（業務系統負責人查看本系統內的關鍵字，查找到相關信息之后，傳遞給其他系統的負責人），繁瑣且耗時。
• 管理維度不同：根據企業組織架構有兩個運維部門，基礎運維室負責運維中間件、數據庫、系統日志，需要跨業務管理；應用運維室負責運維各業務部門的應用日志，需要業務隔離。
• 信息泄露風險：銀行內部通常有許多外包人員，并且有時候需要將日志數據發給系統服務商進行分析，日志中又包含了大量的客戶敏感信息，如果任何運維人員都可隨意查看日志中的敏感信息，信息安全風險將無法評估。
• 存儲成本高昂：為滿足審計要求，需要長時間保留日志，日志存儲成本高。且日志應用場景復雜，偶爾短時間大批量消費日志。

② 建設內容

銀行對于日志數據的安全和存儲都有更高的要求，嘉為藍鯨根據企業組織進行了精細授權管理，同時日志數據流轉處理過程中都進行了加密和脫敏處理，保障銀行的安全性需求。除此之外，針對銀行海量的日志數據存儲需求，采用三層存儲金字塔架構，降低存儲成本。

完成了數據源接入2000+，數據清洗1700+，日數據量1TB+，存儲成本降低50%以上，監控策略300+，儀表盤60+，沉淀30+采集配置模板、清洗模板、儀表盤模板。

3）某車企云管&研發運維一體化項目

① 建設背景

• 日志規模龐大：集團業務發展，整合集團“兩地三中心”，承載各類集團管控任務，支撐各事業部、品牌業務發展。集團現有云IaaS、PaaS、微服務治理服務，主機數1000+，日志規模龐大。
• 技術棧復雜：正在企業IT運維轉型的道路上，從傳統的單機應用邁向云原生應用，現有私有云平臺、華為混合云平臺、容器平臺，其中還包括14項云服務，技術棧復雜導致故障定位異常困難。
• 業務變更頻繁：應用系統敏捷開發、快速迭代，迭代周期縮短到2個月，導致故障數量增加，日志頻繁變化，還可能存在潛在的應用性能問題，對運維人員提出了更高要求。運維人員難以適應業務日志變化，難以通過歷史經驗進行問題定位。
• 人工運維困境：不同應用系統的編程語言多種多樣，日志格式繁多且不斷變化，依靠運維人員手動配置正則進行日志清洗非常低效。同時日志量級大，報警多，一些無關的錯誤日志容易掩蓋真正的問題。

② 建設內容

該大型企業主要問題在于業務的高速發展帶來了海量數據，復雜的技術棧，頻繁的變更，對運維的要求越來越高，人工運維已經難以快讀定位并處理問題。通過Trace全景分析+Metirc波動分析的建設，結合明細日志log數據，建立全景數據鏈條，從根源解決問題，快速定位故障根因。

對于人工運維難度大的問題，引入嘉為鯨眼AI能力，對日志進行日志聚類、模式智能異常檢測、模式趨勢可視化等人工智能手段方式，幫助運維人員快速掌握日志全貌，敏銳捕捉動態異常，動態配置監控策略，大大提升運維人員故障定位效率。

以上是嘉為在日志建設中的一些典型案例，感興趣的讀者可以點擊下方圖片查看回放或下載直播PPT獲得更多相關內容。

當前，可觀測性建設仍然在高速探索的階段，不同的企業運維建設階段不同，對于全?？捎^測能力的構建也有適合各自的建設路徑，本期我們僅僅是對日志系統之于可觀測的意義以及日志運維場景工具設計和落地實踐進行了分享，如果您在日常運維中也遇到了可觀測建設的相關問題，或是對可觀測有建設需求，歡迎聯系我們！