《云原生可觀測性技術(shù)研究與應用》

?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有1@2023

云安全聯(lián)盟大中華區(qū)－保留所有權(quán)利。你可以在你的電腦上下載.儲存.展示.查看及打印，或者訪問云安全聯(lián)盟大中華區(qū)官網(wǎng)（）。須遵守以下：（a）本文只可作個人.信息獲取.非商業(yè)用途；（b）

本文內(nèi)容不得篡改；（c）本文不得轉(zhuǎn)發(fā)；（d）該商標.版權(quán)或其他聲明不得刪除。在遵循

中華人民共和國著作權(quán)法相關(guān)條款情況下合理使用本文內(nèi)容，使用時請注明引用于云安全聯(lián)盟大中華區(qū)。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有2?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有3致謝《云原生可觀測性技術(shù)研究與應用》由CSA大中華區(qū)云原生安全工作組內(nèi)企業(yè)云原生可觀測性白皮書項目組專家撰寫，感謝以下專家的貢獻：項目組組長：王亮主要貢獻者：高巍陳

磊劉

剛浦

明李卓嘉鄭

偉謝奕智申屠鵬會楊文宏研究協(xié)調(diào)員：羅智杰閉俊林貢獻單位：北京沃東天駿信息技術(shù)有限公司北京神州綠盟科技有限公司天翼云科技有限公司安易科技(北京)有限公司中國工商銀行股份有限公司(以上排名不分先后)關(guān)于研究工作組的更多介紹，請在

CSA

大中華區(qū)官網(wǎng)（https://c-

/research/）上查看。在此感謝以上專家及單位。如此文有不妥當之處，敬請讀者聯(lián)系

CSA

GCR

秘書處給與雅正!

聯(lián)系郵箱

research@；國際云安全聯(lián)盟

CSA

公眾號?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有4序言2018

年，可觀測性（Observability）被引入

IT

領(lǐng)域，CNCF-Landscape

率先出現(xiàn)了

Observability

的分組。自此以后，“可觀測性”逐漸取代“監(jiān)控”，成為云原生技術(shù)領(lǐng)域最熱門的話題之一。Gartner

發(fā)布的《2023

年十大戰(zhàn)略技術(shù)趨勢》中，提到了可觀測性的發(fā)展趨勢解讀。文中談到：“可觀測性應用使企業(yè)機構(gòu)能夠利用他們的數(shù)據(jù)特征來獲得競爭優(yōu)勢。它能夠在正確的時間提高正確數(shù)據(jù)的戰(zhàn)略重要性，以便根據(jù)明確的數(shù)據(jù)分析結(jié)果采取快速行動。可觀測性是一種強大的工具。如果能夠在戰(zhàn)略中予以規(guī)劃并成功執(zhí)行?？捎^測性應用將成為數(shù)據(jù)驅(qū)動型決策能力建設(shè)的最強支撐?！北景灼榻B了可觀測性在云原生場景的架構(gòu)設(shè)計，闡述在云原生場景使用

eBPF技術(shù)完成可觀測性數(shù)據(jù)采集的技術(shù)實現(xiàn)及優(yōu)勢。云原生可觀測性的應用場景涵蓋了事件根因分析、安全溯源分析等主要內(nèi)容，旨在闡述云原生可觀測性的生產(chǎn)實踐。云原生場景業(yè)務彈性變化節(jié)奏加快、工作負載生命周期縮短、工作負載直接的訪問關(guān)系更加復雜。在輕量、多變、短生命周期的云原生環(huán)境獲得足夠多的數(shù)據(jù)，得以對事件根因進行分析，對入侵行為進行溯源，對未知威脅進行預測，是將可觀測性能力運用至云原生安全領(lǐng)域后帶來的安全能力提升。這也是可觀測性對云原生場景安全的價值體現(xiàn)。希望通過本白皮書為讀者深入淺出的介紹云原生可觀測性及云原生可觀測性對安全能力的賦能。使得廣大云原生基礎(chǔ)設(shè)施運維者、云原生業(yè)務使用者能夠借鑒本文的評估自身系統(tǒng)云原生可觀測性的成熟度及發(fā)展戰(zhàn)略。李雨航

Yale

LiCSA

大中華區(qū)主席兼研究院院長?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有5目錄致謝...............................................................................................................................

4序言...............................................................................................................................

51.可觀測性概述............................................................................................................

81.1

云原生可觀測性發(fā)展.............................................................................................

81.2

可觀測性定義.........................................................................................................

92.云原生可觀測性成熟度..........................................................................................

102.1

監(jiān)控.......................................................................................................................

112.2

基礎(chǔ)可觀測性.......................................................................................................

112.3

因果可觀測性.......................................................................................................

142.4

主動可觀測性.......................................................................................................

183.云原生觀測體系能力構(gòu)建......................................................................................

213.1

云原生可觀測性信號...........................................................................................

213.2

云原生可觀測能力構(gòu)建......................................................................................

283.3

核心能力-基于

eBPF

構(gòu)建云原生數(shù)據(jù)采集技術(shù)................................................334.云原生可觀測性應用場景......................................................................................

404.1

故障分析...............................................................................................................

404.2

事件預測...............................................................................................................

404.3

日志審計...............................................................................................................

414.3

監(jiān)控......................................................................................................................

474.4

微服務追蹤..........................................................................................................

50?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有64.5

安全檢測分析.......................................................................................................

535.優(yōu)秀云原生可觀測項目介紹..................................................................................

565.1

Prometheus

項目..................................................................................................565.2

OpenTelemetry

項目.............................................................................................

595.3

SkyWalking

項目....................................................................................................63附件.引用文獻............................................................................................................

67?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有71.可觀測性概述1.1

云原生可觀測性發(fā)展CNCF

云原生定義對云生技術(shù)描述為：在現(xiàn)代動態(tài)環(huán)境（如公有云、私有云和混合云）中構(gòu)建和運行可擴展的應用程序的能力。容器、服務網(wǎng)格、微服務、不可變基礎(chǔ)設(shè)施和聲明性

API

均是基于云原生技術(shù)的特征。采用云原生技術(shù)使松散耦合的系統(tǒng)具有彈性、可管理和可觀察性。結(jié)合強大的自動化功能，能夠以最少的工作量頻繁且可預測地進行高影響力的更改。Pivotal

公司

Matt

Stine

在

2013

年首次提出云原生概念。2017

年

Matt

Stine將原生特征歸納為六大點，分別是：

模塊化

Modularity

可觀測性

Observability

可部署性

Deployability

可測試性

Testability

可處理性

Disposability

可替換性

Replaceability?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有8作為六大特征之一的可觀測性是保證云原生應用穩(wěn)定性的基礎(chǔ)。在云原生時代，應用規(guī)模不斷擴大，復雜度愈來愈高，而其中潛藏的問題和風險也隨之增多。這對支撐平臺及業(yè)務自身的穩(wěn)定性提出更高要求。能夠支撐業(yè)務的快速迭代、故障快速響應能力、適應復雜的微服務拓撲、保證高效運維。在數(shù)字化大趨勢下，云計算成為企業(yè)數(shù)字化轉(zhuǎn)型的關(guān)鍵。以云上開發(fā)為核心的云原生技術(shù)得到了廣泛的使用。云原生在企業(yè)上云和基礎(chǔ)實施架構(gòu)上的大量應用，也對企業(yè)的運維監(jiān)控安全提出了新的挑戰(zhàn)。分布式、解耦合的新型系統(tǒng)架構(gòu)，服務調(diào)用鏈長、系統(tǒng)行為復雜、軟件系統(tǒng)穩(wěn)定性保障困難，解決以上問題需要采用新的方式對系統(tǒng)進行觀測。1.2

可觀測性定義在控制理論中，“可觀測性是從系統(tǒng)外部輸出的數(shù)據(jù)衡量系統(tǒng)內(nèi)部狀態(tài)的程度”?？捎^測性是人類對機器可以觀察、理解和處理所述系統(tǒng)狀態(tài)的功能?？捎^測性是在沒有考慮目標的情況下決定系統(tǒng)在實現(xiàn)時應該具有哪些輸出。在

IT

領(lǐng)域，可觀測性是在日志與監(jiān)控指標組成的傳統(tǒng)監(jiān)控基礎(chǔ)上，依據(jù)由日志、指標、鏈路追蹤三種核心數(shù)據(jù)來洞悉系統(tǒng)運行狀態(tài)。通過統(tǒng)一的鏈路追蹤洞察系統(tǒng)服務調(diào)用鏈，并與日志、指標數(shù)據(jù)聯(lián)動分析，可實現(xiàn)對云原生系統(tǒng)的高效故障定位與故障解決，保障云原生系統(tǒng)穩(wěn)定性。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有9可觀測性具有三個方面的特征，首先是度量能力，可觀測性的度量能力能夠幫助使用者在系統(tǒng)處于非常極端復雜的場景時，也能理解和解釋系統(tǒng)當前的狀態(tài)。其次是探索分析，可觀測性不應該預定調(diào)試/排查模式和路徑，而應該能夠自由地對所有采集到的各類狀態(tài)數(shù)據(jù)在各種維度和組合之間進行關(guān)聯(lián)分析，不斷探索分析出新的關(guān)聯(lián)性。最后是按需改變，可觀測性最好是在不改變原有代碼的情況下，按需進行埋點。2.云原生可觀測性成熟度研究可觀測性成熟度模型的目標是提供一種可衡量、可復制的理論基礎(chǔ)用以評估、改進可觀測性體系能力。遵循

PDCA

模型通過對可觀測性能力持續(xù)改進，提高對云原生系統(tǒng)的感知能力，縮短運維過程中尋找根因、排除故障的時間。衡量和評估云原生系統(tǒng)可觀測性的成熟度模型，可定義為如下四個級別：Level

1

——

監(jiān)控（Monitoring）Level

2

——

基

礎(chǔ)

可

觀

測

性

（Basic

Observability）Level

3

——

因

果

可

觀

測

性

（Causal

Observability）Level

4

——

主動可觀測性（Proactive

Observability）可觀測性成熟度模型的每個級別，建立在前一級別已實現(xiàn)的基礎(chǔ)上。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有102.1

監(jiān)控2.1.1

目標：確定系統(tǒng)組件是否按預期正常工作可觀測性成熟度模型中，監(jiān)控是第一個階段。此階段對資產(chǎn)、進程、資源使用等數(shù)據(jù)持續(xù)采樣、度量和記錄，獲取實時或定期的信息和數(shù)據(jù)。跟蹤單個系統(tǒng)組件的特定參數(shù)，度量系統(tǒng)組件狀態(tài)。系統(tǒng)組件運行狀態(tài)如超出預設(shè)范圍，觸發(fā)警報、狀態(tài)更改、通知。監(jiān)控級的目標之一是設(shè)置實時警報，在系統(tǒng)出現(xiàn)問題或達到預定閾值時能夠及時報警。2.1.2

能力在

Level1

階段，被監(jiān)控的系統(tǒng)各組件之間無相關(guān)性，此級別主要目標是了解系統(tǒng)組件是否正常工作。監(jiān)控級會開始對基本的性能數(shù)據(jù)進行采集，以確保系統(tǒng)在負載情況下不會受到顯著影響。監(jiān)控級的主要目標是建立起最基本的監(jiān)控能力，以確保系統(tǒng)的基本穩(wěn)定性和可用性。關(guān)鍵功能：系統(tǒng)輸入：事件和組件級指標系統(tǒng)輸出：報警、日志價值：獲得基本信息，系統(tǒng)組件的健康狀態(tài)出現(xiàn)問題時的警報和通知2.2

基礎(chǔ)可觀測性?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有112.2.1

目標：確定系統(tǒng)故障可觀測性通常指基于對復雜系統(tǒng)外部輸出的了解，能夠了解其內(nèi)部狀態(tài)或狀況的程度。系統(tǒng)越可觀測，定位問題根本原因的過程就越快速越準確，而無需進行額外的測試或編碼。為保證復雜動態(tài)的系統(tǒng)可靠運行，需要知道系統(tǒng)組件是否正常運行，還需要了解它為什么不運行。當出現(xiàn)問題時，希望遵循“5W1H”的原則了解問題詳情：who、when、where、what、why、how。Level1

監(jiān)控措施基于預置規(guī)則實現(xiàn)告警、通知。預置規(guī)則依賴于一個關(guān)鍵性的假設(shè)，即能夠在問題發(fā)生之前預測將會遇到的問題類型。這種方法不能覆蓋足夠多的場景，無法回答

5W1H

的問題。云原生環(huán)境是動態(tài)的、復雜的、多變的，無法事先預知可能會出現(xiàn)什么樣的問題。因此云原生應用下的可觀測性方案，應可以根據(jù)更完整、更深入的可觀測性數(shù)據(jù)，實時感知事件，并提供定位可能無法預料的問題根因的能力?？捎^測性成熟度

Level

2

相較于

Level

1

的數(shù)據(jù)具有更大的廣度和深度?？捎^測性系統(tǒng)主要關(guān)注三種關(guān)鍵類型的數(shù)據(jù)來提供系統(tǒng)洞察力：指標、日志和跟蹤?？捎^測性的這三大支柱是從微服務、應用程序、數(shù)據(jù)庫、云原生基礎(chǔ)設(shè)施中收集的，旨在提供對系統(tǒng)行為的更為完整的視圖。每種數(shù)據(jù)提供不同類型的信息：?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有12

指標：了解服務性能和狀態(tài)的數(shù)值測量--四個黃金信號：延遲、流量、錯誤率和飽和度。

日志：了解系統(tǒng)在給定時間點的行為--統(tǒng)中發(fā)生的相關(guān)事件（例如事務、警告、錯誤）的時間戳記記錄

追蹤：解決性能問題--顯示數(shù)據(jù)如何從端到端流經(jīng)應用程序的詳細快照（例如，用戶請求）可觀測性強調(diào)數(shù)據(jù)的統(tǒng)一性，通過構(gòu)建統(tǒng)一的平臺來實現(xiàn)指標、日志和跟蹤數(shù)據(jù)的匯聚與處理，突破單點工具的能力限制。建設(shè)統(tǒng)一數(shù)據(jù)平臺可將各種可觀測性工具整合在一個集中的界面，提高管理和維護系統(tǒng)的效率。通過手工關(guān)聯(lián)數(shù)據(jù)來推斷事件的可疑原因，需要跨系統(tǒng)手動查詢。在

Level

2中，尚未涉及自動化方法來統(tǒng)一和關(guān)聯(lián)來自各種工具匯聚的孤立數(shù)據(jù)，準確定位問題的根本原需要大量的人力投入。2.2.2

能力Level2

階段，理解可觀測性數(shù)據(jù)之間的關(guān)系，將上下文數(shù)據(jù)結(jié)合。關(guān)鍵功能：系統(tǒng)輸入：Level1+鏈路、指標、日志系統(tǒng)輸出：Level1+圖標、日志可視化綜合儀表盤?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有13價值：通過從更多來源收集數(shù)據(jù)，更深入、廣泛、全面地了解整個系統(tǒng)健康狀況，更好地支持問題診斷除已知故障類型外，還能夠發(fā)現(xiàn)未知故障模式從各種類型的數(shù)據(jù)中獲得有益的洞察力--例如，跟蹤有助于識別性能瓶頸，指標可提供出色的

KPI，日志可用于查找軟件缺陷。2.3

因果可觀測性2.3.1

目標：確定問題根本原因影響面及規(guī)避方法可觀測性的核心價值在于提高排查問題的效率?？捎^測性工具通過分析數(shù)據(jù)，定位問題，進一步確認問題的根本性原因（Root

Cause）?？捎^測性體系用于因果判斷，可以更深入全面地理解系統(tǒng)的運行和行為，得出系統(tǒng)中事件之間的因果關(guān)系。通過對因果關(guān)系分析理解，找出引發(fā)問題的根本性原因。具備因果分析能力的可觀測性體系可定義為“因果可觀測性（Causal

Observability）”。具備因果分析能力的可觀測性體系，通過收集、分析和解析足夠多維度的數(shù)據(jù)，達到理解系統(tǒng)內(nèi)事件、狀態(tài)變化之間的關(guān)系，從而更深入地洞察系統(tǒng)運行狀態(tài)。因果可觀測性強調(diào)在數(shù)據(jù)分析中尋找因果關(guān)系，并將這些關(guān)系轉(zhuǎn)化為對系統(tǒng)事件之間關(guān)系的可視化呈現(xiàn)。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有14因果可觀測性與基礎(chǔ)觀測性有所不同，Level2

強調(diào)數(shù)據(jù)，Level3

強調(diào)關(guān)系。Level2

基礎(chǔ)可觀測性關(guān)注收集、分析數(shù)據(jù)以理解系統(tǒng)的狀態(tài)和行為，Level3

因果可觀測性強調(diào)數(shù)據(jù)與數(shù)據(jù)、實體與實體、事件與事件或更多維度數(shù)據(jù)之間的聯(lián)系。構(gòu)建因果可觀測性，涉及數(shù)據(jù)收集、關(guān)系收集、數(shù)據(jù)處理、關(guān)系處理、因果推斷等步驟，以揭示事件發(fā)生的因果過程。面對復雜性、不確定性和變化性的云原生應用場景，對事件因果的理解有助于更好地預測、解釋、優(yōu)化和管理系統(tǒng)。調(diào)查故障根因時，需收集事件發(fā)生的時間、空間、參數(shù)變化等數(shù)據(jù)，從而了解導致問題出現(xiàn)、傳播，以及隨著時間的推移而變化的事件狀態(tài)。解決這些問題，需要引入新的能力：網(wǎng)絡(luò)數(shù)據(jù)、拓撲數(shù)據(jù)、時間、空間地圖、自動化關(guān)聯(lián)技術(shù)。這些能力可以更全面地理解系統(tǒng)運行狀態(tài)，定位問題的根本原因。為了建立因果可觀測性，需要補充兩種類型的數(shù)據(jù)要素：拓撲、時間。拓撲時間系統(tǒng)中各實體對象相互之間的連接關(guān)系（例如根據(jù)鏈路相關(guān)數(shù)據(jù)繪制的服務拓撲）持續(xù)抓取觀測數(shù)據(jù)的時間維度表

1

兩種類型數(shù)據(jù)要素拓撲是因果可觀測性的第一個必要維度。

拓撲是

IT

環(huán)境中所有組件的映射，它跨越所有層，從網(wǎng)絡(luò)到應用程序再到存儲，顯示一切是如何相關(guān)的。

拓撲結(jié)合了組件之間的邏輯依賴性、物理接近性和其他關(guān)系，以提供人類可讀的可視化和可操作的關(guān)系數(shù)據(jù)。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有15拓撲信息（Topology）指的是系統(tǒng)中各主機、進程、容器、API、Service

之間的關(guān)系和連接方式。拓撲的價值在于提供系統(tǒng)的高級視圖，幫助運維者理解不同實體之間的依賴關(guān)系、通信路徑和層次結(jié)構(gòu)。通過拓撲信息，能夠更全面清晰地了解系統(tǒng)結(jié)構(gòu)。拓撲信息在可觀測性數(shù)據(jù)中扮演著一種定位和上下文的角色，輔助理解數(shù)據(jù)所涉及的組件、服務、資源以及它們之間的關(guān)系。拓撲信息是一個系統(tǒng)的結(jié)構(gòu)圖，展示了系統(tǒng)內(nèi)部各個元素之間的連接和依賴關(guān)系。這種結(jié)構(gòu)圖可以是物理上的（如網(wǎng)絡(luò)拓撲、主機之間的連接），也可以是邏輯上的（如服務之間的依賴關(guān)系、數(shù)據(jù)流動路徑）。將信息點連接至系統(tǒng)元素，使得每個維度的數(shù)據(jù)不是孤立的點。時間是因果可觀測性的第二個必要維度。在充滿微服務、云資源和容器不斷變化的動態(tài)環(huán)境中，拓撲信息的變化是非常迅速的。系統(tǒng)狀態(tài)可能在問題多次出現(xiàn)的過程中發(fā)生變化。為了確立因果可觀測性，需要引入一個至關(guān)重要的維度：時間。為了深入了解現(xiàn)代

IT

環(huán)境的動態(tài)行為并獲取實現(xiàn)因果可觀測性所需的上下文。隨著時間的推移，捕獲拓撲信息的變化，并將其與可觀測性數(shù)據(jù)進行關(guān)聯(lián)，以跟蹤整個堆棧的變化。當出現(xiàn)問題時，可以回溯到問題開始的確切時間點，并查看是什么變化導致了這個問題。通過這種時間維度的關(guān)聯(lián)，能夠更準確地定位問題的根本原因，實現(xiàn)對問題的全面分析和解決。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有16空間地圖是拓撲的升維，提供

IT

環(huán)境中所有元素的關(guān)系映射，空間地圖是一張三維的元素連接拓撲，涵蓋水平的實體關(guān)系拓撲，垂直的依賴關(guān)系拓撲?？臻g地圖結(jié)合了組件之間的邏輯依賴性、物理鄰近性和其他關(guān)系，以提供可讀的可視化和可操作的關(guān)系數(shù)據(jù)。

水平拓撲：在相同類型的元素之間建立的連接關(guān)系地圖，如進程到進程、服務到服務、主機到主機

垂直拓撲：在不同類型的元素之間建立的連接關(guān)系地圖，如數(shù)據(jù)中心到主機、主機到進程、進程到服務、服務到應用程序通過技術(shù)實現(xiàn)水平層、垂直層的空間地圖，自動化、實時性的繪制，將可觀測性數(shù)據(jù)與空間地圖的實體關(guān)聯(lián)，拉動時間軸，展示隨時間變化的空間拓撲、關(guān)聯(lián)數(shù)據(jù)，能夠比較變化前后的系統(tǒng)狀態(tài)，是可觀測性能力的集中式成果體現(xiàn)。2.3.2

能力拓撲可以極大地提高因果判定的準確性和有效性，Level

3

對空間地圖的引入是重大的進步。關(guān)鍵功能：通過拓撲為指標、鏈路、流量、日志提供上下文，隨事件推移關(guān)聯(lián)相關(guān)數(shù)據(jù)，追蹤變化；系統(tǒng)輸入：Level1+Level2+網(wǎng)絡(luò)+拓撲+時間?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有17系統(tǒng)輸出：Level1+Level2+空間拓撲+數(shù)據(jù)關(guān)聯(lián)+時序變化價值：通過統(tǒng)一時間序列拓撲中的孤立數(shù)據(jù)，獲得統(tǒng)一、清晰、相關(guān)的環(huán)境狀態(tài)上下文視圖通過拓撲可視化和分析了解因果關(guān)系，顯著加快根本原因識別和解決時間基本自動化調(diào)查的基礎(chǔ)，例如根本原因分析、業(yè)務影響分析和警報關(guān)聯(lián)自動將與同一根本原因相關(guān)的警報集中在一起，從而減少噪音和干擾所需的上下文2.4

主動可觀測性2.4.1

目標：自動輸出問題根因、自動化響應，智能預測、主動預防Level

4

主動可觀測性，典型特征是引入“AIOps”技術(shù)，通過自動化和智能化的方法實現(xiàn)更深入更準確的洞察力，將傳統(tǒng)的被動式運維轉(zhuǎn)變?yōu)橹鲃邮竭\維。將人工智能（AI）

和機器學習（ML）

技術(shù)融入到可觀測性體系中。在這一階段中，更加強調(diào)分析結(jié)果和答案，而不僅僅關(guān)注原始數(shù)據(jù)和分析過程。主動可觀測性將分析結(jié)果呈現(xiàn)給用戶，并輔助決策和采取行動。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有18Level4

主動可觀測性建立在該成熟度模型中因果可觀測級別的核心功能之上。Level4

階段添加了模式識別、異常檢測和更準確的問題修復建議。

對于主動可觀測性而言，因果可觀測性是一個必要的基礎(chǔ)：時間序列拓撲提供了一個必要的框架。數(shù)據(jù)是原材料，原材料經(jīng)過分析之后得出的答案。快速的把高質(zhì)量結(jié)果和答案傳達出來，快速做出決策、采取行動，是主動可觀測性需要重點考慮的問題。任何一套可觀測性解決方案或建設(shè)可觀測性體系之前，都應解決三個最本質(zhì)的問題：

通知：在問題出現(xiàn)并造成影響前后，能夠在多快的時間內(nèi)得到通知？

診斷：能迅速地對問題進行分類，了解影響？

理解：如何找到潛在的原因以快速解決問題？AIOps

利用因果關(guān)系，使用基于拓撲驅(qū)動的漸進式故障樹分析算法。AIOps具備強大的拓撲繪制能力，實時獲得基礎(chǔ)架構(gòu)、流程和服務依賴關(guān)系的可視化關(guān)系，更好地理解系統(tǒng)的運行情況和交互關(guān)系。AIOps

依托拓撲地圖、云原生系統(tǒng)產(chǎn)生的數(shù)據(jù)進行分析，能顯示一個事件在垂直和水平方向的拓撲依賴關(guān)系，能夠自動確定異常問題的根源。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有19在

Level

4

階段，目標是關(guān)注更高效且無事故的

IT

運維?？捎^測系統(tǒng)基于AI/

ML

算法模型，感知服務或組件偏離正常行為的趨勢，并在出現(xiàn)故障之前采取措施規(guī)避問題。對未發(fā)生事件的預測能力是

Level4

階段可觀測系統(tǒng)的典型特征。2.4.2

能力Level

4，目前是

IT

技術(shù)領(lǐng)域中最高的可觀測性成熟度級別。需要拓撲和時間提供的額外上下文，準確評估根本原因、確定業(yè)務影響、檢測異常并主動確定何時提醒

SRE

和

DevOps

團隊。關(guān)鍵功能：系統(tǒng)輸入：Level1+Level2+Level3

+

大數(shù)據(jù)分析/ML

模型系統(tǒng)輸出：Level1+Level2+Level3+空間拓撲+自動化

RCA+預測價值：自動根因定位、自動化

RCA、告警降噪、預測異常；借用

Gartner?

2022

年

3

月“Innovation

Insight

for

Observability”文章中的一段話作為本章總結(jié)：“發(fā)現(xiàn)異常很容易，因為它們一直都在發(fā)生。

當每天收集十億個事件時，每兩分鐘就會發(fā)生一百萬分之一的事件。

可觀測性工具的關(guān)鍵是發(fā)現(xiàn)與手頭問題相關(guān)的異常，然后從可能相關(guān)的日志文件/指標中鏈接其他信息。

通過在上下文中顯示相關(guān)信息，操作員可以更快地找出問題的潛在根本原因?！报C

Gartner?“Innovation

Insight

for

Observability”，2022

Mar，PadraigByrne

&

Josh

Chessman.?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有203.云原生觀測體系能力構(gòu)建3.1

云原生可觀測性信號云原生可觀測性的實現(xiàn)依賴于監(jiān)控指標

/

監(jiān)控度量（Metrics）、事件日志（Logs）和鏈路追蹤（Traces）三種數(shù)據(jù)類型。這三種數(shù)據(jù)各有側(cè)重，不是完全獨立，三種數(shù)據(jù)之間有重合或者可以結(jié)合之處。圖

1

三種數(shù)據(jù)類型3.1.1

指標?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有21指標是數(shù)據(jù)的數(shù)字表示形式。它們分為兩大類：已經(jīng)是數(shù)字數(shù)據(jù)和提煉（聚合）成數(shù)字的數(shù)據(jù)。前者的一個例子是溫度，后者例如在

Web

服務器上觀察到的

HTTP

請求計數(shù)器。數(shù)字是存儲數(shù)據(jù)的最有效方式，隨著時間的推移，所有成熟的行業(yè)都趨向于指標優(yōu)先。指標的典型示例用例

-

衡量主機（例如虛擬機）堆內(nèi)存使用情況的儀表。我們稱之為“堆內(nèi)存字節(jié)”。指標由一個名稱、一組標簽（有時稱為屬性或標簽）和每個時間點的數(shù)值（例如每秒一個值）組成。每個具有特定名稱和標簽的指標實例通常稱為“時間序列”或“流”。3.1.2

日志事件日志（Logging）：日志的職責是記錄離散事件，應用運行過程會持續(xù)輸出日志數(shù)據(jù)，這些日志數(shù)據(jù)是業(yè)務系統(tǒng)運行狀態(tài)的各種事件及業(yè)務處理邏輯時輸出的，通過這些記錄事后分析出程序的行為，基本上可以還原業(yè)務流程處理的全過程。事件日志可以詳細解釋系統(tǒng)的運行狀態(tài)，但是存儲和查詢需要消耗大量的資源。日志是描述操作系統(tǒng)、應用程序、服務器或其他設(shè)備中的使用模式、活動和操作的一個或多個文本條目。日志可以分為不同的類別，例如：

應用程序日志

-應用程序內(nèi)部事件創(chuàng)建的記錄。日志可幫助開發(fā)人員了解和評估應用程序在運行過程中的行為模式。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有22

安全日志–

事件與系統(tǒng)中檢測規(guī)則匹配后創(chuàng)建對該事件的記錄。包括登錄失敗、密碼更改、資源訪問、資源更改、策略更改、發(fā)生時間。安全管理員通過安全日志可回溯與檢測規(guī)則匹配的事件。

系統(tǒng)日志

-

系統(tǒng)日志記錄操作系統(tǒng)中的事件，包括處理物理和邏輯設(shè)備的內(nèi)核級消息、引導順序、用戶或應用程序身份驗證以及其他活動、故障、資源狀態(tài)消息。

審核日志

-事件和更改的記錄。記錄執(zhí)行活動人員、執(zhí)行活動內(nèi)容以及系統(tǒng)如何響應。系統(tǒng)管理員根據(jù)業(yè)務需求確定審核日志收集內(nèi)容。安全管理員可根據(jù)審核日志回溯人員對系統(tǒng)的使用。

基礎(chǔ)架構(gòu)日志

-涉及管理影響組織

IT

基礎(chǔ)的物理和邏輯設(shè)備。在本地或云中通過

API、Syslog、主機代理收集獲取。日志記錄應用程序或系統(tǒng)在發(fā)生故障時的狀態(tài),在執(zhí)行根本原因分析時，這些記錄特別有價值。存儲在日志中的信息是自由格式的文本，因此很難得出含義。在過去的

30

年中，已經(jīng)進行了許多嘗試將架構(gòu)應用于日志，但它們尚未特別成功。使用統(tǒng)一架構(gòu)的原因使提取相關(guān)信息更易于訪問。通常是通過解析、分段和分析日志文件中的文本來完成的。日志數(shù)據(jù)還可以轉(zhuǎn)換為其他可觀測性信號，指標和跟蹤。一旦數(shù)據(jù)成為指標，它就可以用于了解隨時間的變化。日志數(shù)據(jù)還可以通過日志分析技術(shù)進行可視化和分析?；趯?shù)據(jù)獲取不同顆粒度，日志可設(shè)置不同級別:“錯誤”、“警告”、“信息”和“調(diào)試”。錯誤是最不詳細的日志級別，調(diào)試是最詳細的日志級別。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有23

錯誤：傳達發(fā)生情況并詳細說明發(fā)生故障的原因

警告：需要注意的高級消息，不一定是失敗信息

消息：系統(tǒng)的工作狀態(tài)

調(diào)試：存儲每個操作的詳細信息。通常，僅在故障排除期間或具備充足得存儲或性能而短期使用。3.1.3

追蹤鏈路追蹤（Tracing）：鏈路追蹤大都是依據(jù)谷歌在

2010

年發(fā)表的論文《Dapper

:

a

Large-Scale

Distributed

Systems

Tracing

Infrastructure》

Dapper

理論來實現(xiàn)的，調(diào)用鏈記錄的是串聯(lián)單個事務內(nèi)全過程的日志數(shù)據(jù)，通過對請求打標、透傳、串聯(lián)，最終可以還原出一次完整的請求，可以幫助工程師輕松分析出請求中異常點。但是鏈路追蹤和事件日志一樣有著相同的問題就是資源消耗較大，通常也需要通過采樣的方式減少數(shù)據(jù)量。為了有效地進行分布式追蹤，Dapper

提出了追蹤（Trace）與跨度（Span）兩個概念：

追蹤（Trace）：從客戶端發(fā)起請求抵達系統(tǒng)的邊界開始，記錄請求流經(jīng)的每一個服務，直到到向客戶端返回響應為止，這整個過程就稱為一次追蹤。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有24

跨度（Span）：由于每次

Trace

都可能會調(diào)用數(shù)量不定、坐標不定的多個服務，為了能夠記錄具體調(diào)用了哪些服務，以及調(diào)用的順序、開始時點、執(zhí)行時長等信息，每次開始調(diào)用服務前都要先埋入一個調(diào)用記錄，這個記錄稱為一個跨度。Dapper

使用以跨度為基本樹節(jié)點的跟蹤樹構(gòu)建跟蹤模型，并為每個跨度記錄了一個可讀的

span

name,

span

id,

parent

id，這樣就能重建出一次分布式跟蹤過程中不同跨度之間的關(guān)系。沒有

parent

id

的跨度被稱為根跨度。一次特定跟蹤的所有相關(guān)跨度會共享同一個通用的

trace

id

。換句話說每一個追蹤實際上都是由若干個有順序、有層級關(guān)系的跨度所組成一顆追蹤樹（Trace

Tree），如下圖

2

所示：圖

2

追蹤樹11

圖片引用自

Google

Dapper

:

a

Large-Scale

Distributed

Systems

Tracing

Infrastructure?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有25追蹤（Tracing）通常表示一個具體的事務實例，即計算機通過特定程序的路徑，使它們成為可觀察性中的詳細且昂貴的信號?？缍龋⊿pans）高度情境化，需要進行上下文關(guān)聯(lián)。除此之外，跨度（Spans）

還記錄有關(guān)啟動它的“父”跨度（Spans）的信息。這使得在分布式系統(tǒng)的不同參與者（如服務、隊列、數(shù)據(jù)庫等）之間建立因果關(guān)系成為可能。

基于日志的追蹤數(shù)據(jù)收集基于日志的追蹤的思路是將

Trace、Span

等信息直接輸出到應用日志中，然后根據(jù)收集到的日志數(shù)據(jù)，從全局日志信息中反推出完整的調(diào)用鏈拓撲關(guān)系?；谌罩镜淖粉檾?shù)據(jù)收集的優(yōu)點在于其對網(wǎng)絡(luò)消息完全沒有侵入性，對應用程序只有很少量的侵入性，對性能影響也非常低。但其缺點是直接依賴于日志歸集過程，日志本身不追求絕對的連續(xù)與一致，這也使得基于日志的追蹤往往不甚精準。另外，業(yè)務服務的調(diào)用與日志的歸集并不是同時完成的，也通常不由同一個進程完成，有可能發(fā)生業(yè)務調(diào)用已經(jīng)順利結(jié)束了，但由于日志歸集不及時或者精度丟失，導致日志出現(xiàn)延遲或缺失記錄，進而產(chǎn)生追蹤失真。Dapper

的跟蹤記錄和收集管道實現(xiàn)如下圖所示，共分為三個階段：1.

把

Span

數(shù)據(jù)寫入到本地日志文件2.

Dapper

守護進程和采集器從主機中將日志他們拉取出來3.

將拉取出的日志寫入

Dapper

的

Bigtable

倉庫中，其中

Bigtable

中的行表示一次跟蹤，列表示一個

span。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有26圖

3

Dapper

工作流程2

基于服務的追蹤數(shù)據(jù)收集基于服務追蹤的實現(xiàn)思路是通過某些手段給目標應用注入追蹤探針（Probe），通過探針獲取服務調(diào)用信息并發(fā)送給鏈路追蹤系統(tǒng)。探針在結(jié)構(gòu)上可視為一個寄生在目標服務身上的小型微服務系統(tǒng)，它一般會有自己專用的服務注冊、心跳檢測等功能，有專門的數(shù)據(jù)收集協(xié)議，把從目標系統(tǒng)中監(jiān)控得到的服務調(diào)用信息，通過另一次獨立的

HTTP

或者

RPC

請求發(fā)送給追蹤系統(tǒng)?；诜盏逆溌纷粉櫫觿菰谟诒然谌罩镜淖粉櫹母嗟馁Y源，也有更強的侵入性。基于服務的鏈路追蹤優(yōu)勢為這些資源消耗換來收益的直接結(jié)果是精確性與穩(wěn)定性均有所保證，從而不必再依賴日志歸集作為追蹤數(shù)據(jù)的來源?；诜盏淖粉櫛?/p>

Zipkin、SkyWalking、Pinpoint

等追蹤系統(tǒng)廣泛采用。2

圖片引用自

Google

Dapper

:

a

Large-Scale

Distributed

Systems

Tracing

Infrastructure?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有273.2

云原生可觀測能力構(gòu)建3.2.1

信號關(guān)聯(lián)有兩種基本方法可以關(guān)聯(lián)數(shù)據(jù)：運維人員建立或者利用現(xiàn)有數(shù)據(jù)建立相關(guān)性。應該對所有的信號使用相同的元數(shù)據(jù)結(jié)構(gòu)。盡可能對日志使用相同的標簽。如有必要，運維人員可自建標簽，附加到所有類型信號的數(shù)據(jù)。連續(xù)收集所有可觀測性信號，每條數(shù)據(jù)的范圍都標記為某個時間戳。在不同的維度上，每個可觀測性信號都需要綁定到某個“目標”，

能夠查看目標的指標、跟蹤和日志三個維度可觀測性數(shù)據(jù)。通過一致的元數(shù)據(jù)來切換來自同一目標（例如，同一應用程序）的可觀測性信號。利用基于拉取的系統(tǒng)，如

Prometheus

或

OpenTelemetry

Prometheus

接收指標，利用日志收集器（OpenTelemetry、Fluentd、Fluentbit

）收集日志。確保收集器附加一組一致的目標標簽或?qū)傩?，例如“集群”、“namespace”、”label“、“Pod”。在處理

OTLP（指標、日志和跟蹤）等多維度集合數(shù)據(jù)時，應用附加目標標簽信息，確保數(shù)據(jù)一致性。運維人員可以基于相同的標簽，在不同的可觀測性信號之間切換。允許從每個信號中選擇與特定過程、組件、時間相關(guān)的信息，從而快速瀏覽具有相同標簽信號的細節(jié)內(nèi)容。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有28日志中共享與請求相關(guān)的相同信息（請求

ID、操作

ID）。確保日志記錄和跟蹤的這些

ID

是相關(guān)聯(lián)的，從而確保數(shù)據(jù)可基于事件請求

ID

緊密地相互關(guān)聯(lián)。運維人員能夠通過跟蹤綁定到單條日志的請求

ID

標簽，快速定位日志。3.2.2

典型業(yè)務架構(gòu)可觀測性業(yè)務架構(gòu)可分為以下五層（數(shù)據(jù)源、數(shù)據(jù)采集層、數(shù)據(jù)存儲層、應用展示層、智能化層）。五層架構(gòu)可作為可觀測性建設(shè)的內(nèi)容，也是當前大多數(shù)企業(yè)正在實踐的部分。典型可觀測性業(yè)務架構(gòu)如下圖

4

所示：?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有29圖

4

典型可觀測性業(yè)務架構(gòu)

數(shù)據(jù)源可觀測的數(shù)據(jù)源大致可分為幾大類，硬件、操作系統(tǒng)與網(wǎng)絡(luò)以及軟件。硬件如服務器的硬盤、電源、風扇和主板等；網(wǎng)絡(luò)設(shè)備如交換機、路由器和網(wǎng)關(guān)等設(shè)備；安全設(shè)備如防火墻；機房設(shè)施如空調(diào)、電力等；這些硬件在運行時都會產(chǎn)生狀態(tài)數(shù)據(jù)。操作系統(tǒng)其實也是一種軟件，由于其特殊性這里將其單獨歸類，操作系統(tǒng)內(nèi)會有

CPU、內(nèi)存、存儲相關(guān)的使用和狀態(tài)數(shù)據(jù)，操作系統(tǒng)間會有通信的網(wǎng)絡(luò)數(shù)據(jù)。軟件包含集群編排系統(tǒng)、Docker

運行時、DB、中間件、業(yè)務軟件。

數(shù)據(jù)采集對數(shù)據(jù)進行分析總結(jié)出三種獨立的數(shù)據(jù)類型，分別從三個不同的維度來展示應用的狀態(tài)，這三種數(shù)據(jù)類型分別是日志數(shù)據(jù)（Logging）、鏈路數(shù)據(jù)（Tracing）和指標數(shù)據(jù)（Metric）日志是記錄了發(fā)生在運行中的操作系統(tǒng)或其他軟件中的事件。常見于事件日志、事物日志、消息日志等，而與可觀測性相關(guān)主要就是事件日志。事件日志（Event

logs）記錄了在系統(tǒng)運行期間發(fā)生的事件，以便于了解系統(tǒng)活動和診斷問題。它對于了解復雜系統(tǒng)的活動軌跡至關(guān)重要，尤其是只有很少用戶交互的應用程序（例如服務器應用程序）。目前，許多企業(yè)使用

CNCF

推薦的

Fluentd

作為主要的日志數(shù)據(jù)采集工具。此外還有一些企業(yè)采用

Filebeat

和

Logstash。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有30鏈路追蹤即調(diào)用鏈監(jiān)控，特點是通過記錄多個在請求間跨服務完成的邏輯請求信息，幫助開發(fā)人員優(yōu)化性能和進行問題追蹤。鏈路追蹤可以捕獲每個請求遇到的異常和錯誤，即時信息和有價值的數(shù)據(jù)。鏈路追蹤的技術(shù)選型目前在

CNCF中主要有的

Jaeger，SkyWalking

或

Zipkin

幾種工具供選擇。指標數(shù)據(jù)是應用程序運行時產(chǎn)生的內(nèi)部指標，以

API

接口的方式提供查詢。指標數(shù)據(jù)具有時間點的特性，不同的時間點對應的指標是不同的，因此用以存儲指標數(shù)據(jù)的數(shù)據(jù)庫一般稱為時序列數(shù)據(jù)庫。

數(shù)據(jù)存儲采集到的數(shù)據(jù)需要進行處理并進行存儲，為下一步的數(shù)據(jù)應用和展示提供數(shù)據(jù)基礎(chǔ)。一般場景日志數(shù)據(jù)和鏈路追蹤數(shù)據(jù)存儲可使用

ElasticSearch、ClickHouse等非關(guān)系數(shù)據(jù)庫。在大規(guī)模日志采集場景下可以添加

Kafka

作為緩沖。對需要進行大數(shù)據(jù)分析等場景時，也可以選擇

HDFS/HBase

存儲。對于指標數(shù)據(jù)推薦使用

Prometheus

存儲（Prometheus

本身也實現(xiàn)了

TSDB數(shù)據(jù)庫），但是原生的

TSDB

對于大數(shù)據(jù)量的保存及查詢支持不太友好，該數(shù)據(jù)庫不能保證可靠性，且無法支持

Prometheus

集群架構(gòu)。而

Thanos

和

Cortex都是在數(shù)據(jù)可靠性和集群高可用方面進行了優(yōu)化和增強，目前都是

CNCF

孵化中的項目，也是不錯的選擇。在大規(guī)模場景下還可以選擇

openTSDB

或Clickhouse

來進行指標數(shù)據(jù)存儲。

數(shù)據(jù)展示?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有31展示層是對采集數(shù)據(jù)的基礎(chǔ)應用，也是當前企業(yè)主要的應用場景。圖表展示是可觀測性面向用戶最為直觀的呈現(xiàn)，將復雜的數(shù)據(jù)以圖或表形式展示出來，便于運維人員快速了解應用狀態(tài)，基于經(jīng)驗做出判斷或預測。對于日志數(shù)據(jù)和鏈路追蹤數(shù)據(jù)的查看可以通過

Kibana

查看，對于指標數(shù)據(jù)可使用

Grafana

進行展示，也可以使用原生的

Prometheus、Thanos

或

Cortex

查看。服務拓撲是通過數(shù)據(jù)流向和調(diào)用關(guān)系，以

UI

的方式將服務依賴關(guān)系拓撲呈現(xiàn)出來。實際業(yè)務中，應用之間的關(guān)聯(lián)與依賴非常復雜，需要通過全局視角檢查具體的局部異常?？梢栽诜胀負洳榭磻迷谥付〞r間內(nèi)的調(diào)用及其性能狀況。監(jiān)控告警是最常用的場景，也是目前建設(shè)可觀測系統(tǒng)的核心目標。監(jiān)控告警通過事前配置好閾值，數(shù)據(jù)采集上來后通過計算與閾值比對，對于不符合規(guī)則要求的數(shù)據(jù)生成告警事件，通過告警渠道發(fā)送到目標設(shè)備。對于可觀測性數(shù)據(jù)的應用除以上幾項外，還可嘗試將三者的數(shù)據(jù)進行關(guān)聯(lián)，使同一個應用不同維度的事件立體化的展示出來。如請求發(fā)生異常時，應用一般會將請求以日志的方式輸出，調(diào)用鏈路也會上報調(diào)用異常，這兩類數(shù)據(jù)可以通過RequestID

或

TraceID

進行關(guān)聯(lián)。

智能化將人工智能和大數(shù)據(jù)應用于可觀測性，輔助運維實現(xiàn)自動化、智能化，以達到業(yè)務服務高效穩(wěn)定運行的目的。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有32智能分析依托大數(shù)據(jù)和人工智能技術(shù)對采集的日志、指標和鏈路數(shù)據(jù)進行分析，按需產(chǎn)生有價值的結(jié)果。智能分析的主要應用有趨勢預測、根因分析和智能決策三類不同場景。

趨勢預測：預測可能會發(fā)生的事件；

根因分析：確定事件發(fā)生的根本原因；

智能決策：基于根本原因后提供智能決策的解決方案。3.3

核心能力-基于

eBPF

構(gòu)建云原生數(shù)據(jù)采集技術(shù)隨著大量應用基于云原生技術(shù)進行開發(fā)、適配和遷移，應用出現(xiàn)微服務激增、多語言開發(fā)、多通信協(xié)議特征，系統(tǒng)架構(gòu)復雜度越來越高，傳統(tǒng)可觀測方法存在采集數(shù)據(jù)粒度不夠細致、資源消耗量大、外部代碼侵入等問題。近年來，業(yè)界開始關(guān)注

linux

內(nèi)核

eBPF

技術(shù)，獨有特性能更有效地解決發(fā)展中問題。3.3.1

Linux

內(nèi)核

eBPF

技術(shù)原理eBPF

起源于

Linux

內(nèi)核，可以運行沙箱程序，安全有效地擴展內(nèi)核功能，無需更改內(nèi)核源代碼或加載內(nèi)核模塊。eBPF

全稱“擴展的伯克利數(shù)據(jù)包過濾器(Extended

Berkeley

Packet

Filter)”，是一種數(shù)據(jù)包過濾技術(shù)，從

BPF(Berkeley

PacketFilter)技術(shù)擴展而來。BPF

提供了一種在內(nèi)核事件和用戶程序事件發(fā)生時安全注入代碼的機制，這就讓非內(nèi)核開發(fā)人員也可以對內(nèi)核進行控制。隨著

Linux

內(nèi)核的發(fā)展，BPF

逐步從最初的數(shù)據(jù)包過濾擴展到網(wǎng)絡(luò)、內(nèi)核、安全、跟蹤等，而且它的功能特性還在快速發(fā)展之中，這種擴展后的

BPF

被簡稱為

eBPF。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有33eBPF

是基于寄存器的虛擬機，使用自定義的

64

位

RISC

指令集，在

Linux內(nèi)核運行即時本地編譯的

eBPF

程序。eBPF

程序并不像常規(guī)的線程那樣，啟動后就一直保持運行，它需要由事件觸發(fā)后才會執(zhí)行。這些事件包括系統(tǒng)調(diào)用、內(nèi)核跟蹤點、內(nèi)核函數(shù)和用戶態(tài)函數(shù)的調(diào)用退出、網(wǎng)絡(luò)事件，等等。借助于強大的內(nèi)核態(tài)插樁（kprobe）和用戶態(tài)插樁（uprobe），eBPF

程序幾乎可以在內(nèi)核和應用的任意位置進行插樁。eBPF

程序通常包括

4

部分：

后端代碼：在內(nèi)核中加載和運行的

eBPF

字節(jié)碼，它將數(shù)據(jù)寫入內(nèi)核

map和環(huán)形緩沖區(qū)的數(shù)據(jù)結(jié)構(gòu)中；

加載器：它將字節(jié)碼后端加載到內(nèi)核中，當加載器進程中止時，字節(jié)碼會被內(nèi)核自動卸載;

前端代碼：從數(shù)據(jù)結(jié)構(gòu)中讀取數(shù)據(jù)，并將其顯示給用戶

數(shù)據(jù)結(jié)構(gòu)：后端和前端的通信手段。它們是由內(nèi)核管理的

map

和環(huán)形緩沖區(qū)，可以通過文件描述符訪問。需要在后端被加載之前創(chuàng)建，數(shù)據(jù)會持續(xù)存在，直到?jīng)]有更多的后端或前端進行讀寫操作eBPF

程序的運行流程，如下圖

5

所示：?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有34圖

5

eBPF

程序的運行流程1.用戶態(tài)編寫

eBPF

程序2.使用

LLVM

編譯成

bytecode

的

ELF

文件3.使用

bpf

系統(tǒng)調(diào)用，把程序加載進入內(nèi)核4.內(nèi)核的

verifier

會驗證

eBPF

程序的合法性，確保其能夠安全、合規(guī)地在內(nèi)核中運行5.內(nèi)核會使用

JIT

compiler

把

eBPF

字節(jié)碼編譯成本地機器碼6.eBPF

程序在內(nèi)核中以

VM

方式安全運行3.3.2

基于

eBPF

云原生可觀測性技術(shù)架構(gòu)?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有35云原生環(huán)境中每臺機器(或虛擬機)只有一個內(nèi)核，所有運行在該機器上的容器都共享同一個內(nèi)核，內(nèi)核了解主機上運行的所有應用代碼。通過對內(nèi)核的檢測，基于

eBPF

可以同時檢測在該機器上運行的所有應用程序代碼。當將

eBPF

程序加載到內(nèi)核并將其附加到事件上時，它就會被觸發(fā)，而不考慮哪個進程與該事件有關(guān)。eBPF

能夠?qū)趶V泛的可能來源的可視化事件的定制指標進行收集和核內(nèi)聚合?；?/p>

eBPF

在操作系統(tǒng)內(nèi)核特性優(yōu)勢，與

OpenTelemetry

結(jié)合實現(xiàn)云原生觀測數(shù)據(jù)收集處理的架構(gòu)，極大增強云原生環(huán)境可觀測性能力?；?/p>

eBPF

的可觀測性架構(gòu)如下圖

6：圖

6

基于

eBPF

的可觀測性架構(gòu)?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有36關(guān)鍵點在

eBPF

采集數(shù)據(jù)導入

OpenTelemetry

Collector，步驟如下：1.

數(shù)據(jù)接收：在

kubernetes

集群節(jié)點上基于

eBPF

的

tracepoint

和kprobe/kretprobe，將內(nèi)核采集到的應用請求、系統(tǒng)調(diào)用、網(wǎng)絡(luò)傳輸性能等數(shù)據(jù)放到內(nèi)存中，在用戶態(tài)

eBPF

程序讀取數(shù)據(jù)，進行預處理；基于OpenTelemetry

規(guī)范實現(xiàn)

Receiver，以事件訂閱方式接收采集數(shù)據(jù)；2.

數(shù)據(jù)處理：基于

OpenTelemetry

規(guī)范實現(xiàn)

Processor，對采集數(shù)據(jù)進行協(xié)議解析和指標處理評估，然后填充

kubernetes

metadata（元信息），實現(xiàn)

eBPF

采集的內(nèi)核數(shù)據(jù)與

kubernetes

調(diào)度請求、上下文信息關(guān)聯(lián)；3.

數(shù)據(jù)導出：基于

OpenTelemetry

規(guī)范實現(xiàn)

Exporter

數(shù)據(jù)導出到可觀測平臺進行分析?；?/p>

eBPF

實現(xiàn)云原生可觀測性數(shù)據(jù)采集具有以下優(yōu)勢：1.

能夠采集更加全面的數(shù)據(jù)，數(shù)據(jù)指標覆蓋從程序調(diào)用、網(wǎng)絡(luò)傳輸性能、網(wǎng)絡(luò)協(xié)議棧性能、服務黃金指標等各個層面；2.

資源消耗占比小，eBPF

程序以本機機器指令運行，性能很高，基于內(nèi)核進行數(shù)據(jù)采集，對應用零侵入、零改造；3.

更加靈活具備可伸縮性，eBPF

程序可以在運行時動態(tài)附加到系統(tǒng)中，無需重新啟動目標系統(tǒng)；?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有374.

能夠輕松應對容器啟動、停止等動態(tài)特點，不需要任何的邊車（

Sidecar）侵入，直接通過內(nèi)核來觀測任意的容器行為。3.3.3

基于的

eBPF

云原生可觀測性增強示例

動態(tài)網(wǎng)絡(luò)性能監(jiān)控通過在每個

kubernetes節(jié)點上部署?個探針eBPF程序。這個探針通過

hook內(nèi)核的

accept,

connect,

send,

recv

等

L4(TCP、UDP)相關(guān)的系統(tǒng)調(diào)?，可以獲取進程與綁定地址的關(guān)系、通信雙?的地址、各連接收發(fā)的流量統(tǒng)計。探針會去獲取當前

kubernetes

集群的

metadata

數(shù)據(jù)(pid,

container,

pod,

service,

node

等)并把它們保存在內(nèi)存中，豐富原始

eBPF

數(shù)據(jù)。服務端在收集到通信雙?的

eBPF數(shù)據(jù)后做進?步數(shù)據(jù)填充，并存?數(shù)據(jù)庫。查詢時，根據(jù)指定的時間范圍、主機/服務/pod

等篩選條件查詢數(shù)據(jù)庫，從?構(gòu)造出該時段的各級別的動態(tài)拓撲圖。并且基于

eBPF

能進一步采集內(nèi)核級底層網(wǎng)絡(luò)可觀測性黃金信號數(shù)據(jù),如

TCP

網(wǎng)絡(luò)流量、網(wǎng)絡(luò)延遲、堵塞等數(shù)據(jù)，并建立與

kubernetes

對象關(guān)聯(lián)。

HTTP

黃金指標監(jiān)控云原生環(huán)境中有運行狀況的三個關(guān)鍵

HTTP

黃金指標：請求速率、請求延遲、請求響應代碼/錯誤?；?/p>

eBPF

能夠在不對應用程序進行任何更改的情況下提取這些數(shù)據(jù)，并且聚合相應的指標不是基于

IP，探針在獲得?絡(luò)報文之后，進?步解析

L7

內(nèi)容，包括

HTTP、HTTPS、gRPC

等將微服務的各個會話（?次請求和響應）的

URL、latency、錯誤碼關(guān)聯(lián)到服務標識。探針定期將會話聚合信息推送到服務端進?步豐富數(shù)據(jù)，構(gòu)建微服務鏈路、監(jiān)控儀表盤等。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有38

性能剖析（Profiling）傳統(tǒng)工具對系統(tǒng)中

CPU

進行定時采樣，以特定的時間間隔或速率采集正在運行的函數(shù)或堆棧跟蹤的計數(shù)，估計

CPU

的時間消耗分布，這種方式需要與應用強綁定，受開發(fā)語言局限，并且在跟蹤多線程、多請求應用時存在困難?；趀BPF

可以輕松地對堆棧跟蹤和時間進行內(nèi)核內(nèi)摘要,獲得系統(tǒng)級別特定進程的On-CPU

和

Off-CPU

事件?；?/p>

On-CPU

事件可以繪制?焰圖，直觀地展示各個調(diào)?棧所占時間?例。通過分析線程堆棧能夠定位分析服務

CPU

使用率高的問題，如果堆棧被轉(zhuǎn)儲的次數(shù)更多，則意味著線程堆棧占用了更多的

CPU

資源，如下圖

7：圖

7

CPU

資源?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有394.云原生可觀測性應用場景4.1

故障分析故障分析是云原生可觀測性的最基本的應用場景，也是可觀測性技術(shù)的持續(xù)發(fā)展的重要驅(qū)動力。谷歌給出可觀測性的核心價值快速排障（troubleshooting）?？捎^測性猶如整個

IT

系統(tǒng)的眼睛，它是運維人員發(fā)現(xiàn)問題、定位問題、解決問題的第一步，同時，也是運維監(jiān)控的實現(xiàn)“先知、先覺、先行”的重要條件。隨著云原生持續(xù)發(fā)展，業(yè)務對可靠性、穩(wěn)定性的要求越來越高。提前發(fā)現(xiàn)故障、快速發(fā)現(xiàn)故障、快速定位故障原因是做好穩(wěn)定性的核心要素，良好的可觀測性能夠幫助用戶在故障分析上事半功倍，有效提高業(yè)務上線運行地穩(wěn)定性。在故障分析領(lǐng)域，云原生可觀測技術(shù)協(xié)助運維人員發(fā)現(xiàn)故障事件，分析故障發(fā)生原因，快速定位故障根因，可極大提升云原生領(lǐng)域運維效率。4.2

事件預測在安全運維領(lǐng)域，自動化成為技術(shù)發(fā)展的趨勢。系統(tǒng)能夠完成人類根本無法完成的任務，例如通過機器學習方法，在錯誤或事件發(fā)生之前進行預測。實現(xiàn)預測能力，需要通過在可觀測性系統(tǒng)添加人工智能層。將人工智能的大數(shù)據(jù)分析能力及結(jié)果賦能于可觀測性系統(tǒng)，使可觀測性系統(tǒng)在問題發(fā)生之前提供預測能力。人工智能賦能的可觀測性系統(tǒng)，除了提供預測能力，并且可對預測發(fā)生的問題提供解決方案。在安全運維領(lǐng)域提升對未發(fā)生事件、未知威脅的感知能力。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有40為使得可觀測性系統(tǒng)具備更強的預測能力，需要更多的數(shù)據(jù)和更強大的算力支持，建立精確的模型和預測系統(tǒng)，提供更深刻的事件洞察能力。4.3

日志審計日志與審計對系統(tǒng)和應用行為的記錄，對云原生可觀測性的實現(xiàn)起到了重要的作用。通過日志系統(tǒng)獲取系統(tǒng)以及應用的詳細操作數(shù)據(jù)，是云原生可觀測性重要的數(shù)據(jù)來源。針對

Docker

和

Kubernetes，分別具有對應的日志采集機制，從安全審計的角度出發(fā)，可對日志數(shù)據(jù)進行存儲、歸類、查詢等操作處理。4.3.1

Docker

日志審計Docker

支持多種日志記錄機制，用以幫助用戶從正在運行的容器和服務中獲取信息，這種機制被稱為日志驅(qū)動程序。Docker

從

1.6

版本開始支持日志驅(qū)動，用戶可以將日志直接從容器輸出到如

syslogd

這樣的日志系統(tǒng)中。每個

Docker

守護進程都有一個默認的日志驅(qū)動程序，通常這個默認的日志驅(qū)動是

json-file，也就是以

JSON

文件的形式保存日志信息。同時

Docker

還支持其他的日志驅(qū)動，比如

none、json-file、syslog

和

fluentd

等。下表

2

展示了當前Docker

支持的日志驅(qū)動格式。驅(qū)動描述none不啟用

log

功能，該容器

docker

logs

沒有可用的日志，并且不返?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有41回任何輸出。local日志以自定義格式存儲，旨在最大程度地減少開銷。日志格式為

JSON。這是

Docker

的默認日志驅(qū)動程序。json-filesyslogLinux

的系統(tǒng)

log

服務，將日志消息寫入

syslog，確保

syslog

守護程序必須在

Docker

主機上已經(jīng)運行。journaldsystemd

的

log

服務，可以代替

syslog

服務，將日志消息寫入journald，journald

守護進程必須在主機上運行。gelf將

log

寫入

graylog

或

Logstash

等端點。將

log

寫入

fluentd，確保

fluentd

在主機上已運行。將

log

寫入

Amazon

CloudWatch

Logs。fluentdawslogssplunketwlogs使用

HTTP

Event

Collector

將

log

寫入

splunk將

log

寫為

Event

Tracing

for

Windows

(ETW)事件，僅適用于Windows

平臺gcplogs將

log

寫入

Google

Cloud

Platform

(GCP)logentries將

log

寫入

Rapid7

Logentries表

2

Docker

支持的日志驅(qū)動格式?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有42CIS

Benchmark

對

Docker

的日志審計也提出了安全建議和要求，例如，在

CISDocker

Benchmark

v1.6.0

版本中，2.13

小節(jié)要求需要配置集中和遠程的日志記錄，以確保所有的日志記錄都是安全的，進而滿足容災的需要，而具體的日志驅(qū)動程序，則可以根據(jù)自身情況進行選擇。

除了對容器的日志審計外，CIS

Benchmark還針對

Docker

主機，提出了相關(guān)的安全審計建議。對

Docker

主機的安全審計，一方面包括了常規(guī)的對

Linux

文件系統(tǒng)以及系統(tǒng)調(diào)用等進行審計。另一方面，也包括針對

Docker

守護進程等相關(guān)內(nèi)容的安全審計。例如

CIS

Docker

Benchmarkv1.12.0

版本中，1.1.3

小節(jié)要求，需要審計所有活動的

Docker

守護進程，可以通過

auditctl

-l

|

grep

/usr/bin/docker

命令，列出當前的審計規(guī)則，默認情況下，沒有針對

Docker

守護進程的審計規(guī)則。CIS

Benchmark

中除了對

Docker

守護進程提出了安全審計的建議外，還對Docker

相關(guān)的文件和目錄提出了安全審計建議，例如：需要審計

Docker

文件和/var/lib/docker

目錄、需要審計

Docker

文件和/etc/docker

目錄、需要審計

Docker文件和

docker.socket

目錄等。更多針對

Docker

詳細的安全審計建議，可參考

CISDocker

Benchmark

標準。4.3.2

Kubernetes

日志審計

應用程序日志應用程序的日志記錄可以更好的了解應用內(nèi)部的運行狀況，同時對調(diào)試問題、監(jiān)控集群活動以及對應用程序運行過程的安全性分析有著非常大的作用。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有43當前，大部分應用程序都有某種日志記錄機制，前文已經(jīng)介紹過，以

Docker為代表的容器引擎也被設(shè)計成支持日志記錄的方式。針對容器化應用，最簡單且最廣泛采用的日志記錄方式就是寫入標準輸出（stdout）和標準錯誤流（stderr）。但是，由容器引擎或運行時提供的原生日志功能，通常不足以構(gòu)成完整的日志審計方案。例如，當發(fā)生容器崩潰或者節(jié)點宕機等情況時，我們通常會想訪問應用的日志，這時可能就會出現(xiàn)問題。在集群中，日志應該具有獨立的存儲和生命周期，與節(jié)點、Pod

或容器的生命周期相獨立。這里通常會稱為集群級的日志。集群級的日志架構(gòu)需要一個獨立的后端用來存儲、分析和查詢?nèi)罩尽ubernetes

當前并不為日志數(shù)據(jù)提供原生的存儲解決方案，有很多現(xiàn)成的日志方案可以集成到

Kubernetes

中,

具體可參考下

日志工具小節(jié)。

系統(tǒng)組件日志在

Kubernetes

中，除了

Pod

中應用程序的日志外，Kubernetes

系統(tǒng)組件的日志同樣需要有一定的方案來記錄和存儲。系統(tǒng)組件的日志主要記錄了集群中發(fā)生的事件，這對于調(diào)試以及安全審計有著重要的作用。系統(tǒng)組件日志可以根據(jù)需要配置日志的粒度，靈活調(diào)整日志記錄的細節(jié)程度。日志可以是只顯示組件內(nèi)錯誤這種粗粒度的，也可以是更加細粒度的，例如記錄事件的每一個追蹤步驟（HTTP

訪問日志、Pod

狀態(tài)更新、控制器操作、調(diào)度器決策等）。?

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有44在

Kubernetes

中，系統(tǒng)組件根據(jù)部署運行方式的不同，可以分為兩種類型：其中一種是運行在容器中的，比如，kube-scheduler、kube-proxy

等；另一種是不在容器中運行的，比如

kubelet、以及容器運行時等。在使用

systemd

機制的服務器上，kubelet

和容器運行時將日志寫入到

journald

中。如果沒有

systemd，它們會將日志寫入到/var/log

目錄下的.log

文件中。容器中的系統(tǒng)組件通常將日志寫到/var/log

目錄，繞過默認的日志機制。Kubernetes

默認使用的日志庫是

klog，專門用來做日志初始化的相關(guān)操作，klog

是

glog

的

fork

版本，由于

glog

不再開發(fā)、在容器中運行有不易測試等一系列問題，所以

Kubenetes

自己維護了一個

klog,

由于

Kubernetes

近期版本一直持續(xù)不斷在精簡系統(tǒng)日志組件的，因此在

Kubernetes

v1.23.0

開始，klog

的一些命令行參數(shù)已經(jīng)被廢棄。CIS

Benchmark

對

Kubernetes

的日志審計也提出了安全建議和要求，例如，在

CIS

Kubernetes

Benchmark

v1.6.0

版本中，1.2.22

小結(jié)要求需要配置—audit-log-path

路徑，啟動

Kubernetes

API

Server

的審計功能，設(shè)置合適的日志路徑，進而可以獲取

API

Server

一系列按時間排序的與安全相關(guān)的記錄。更多針對Kubernetes

詳細的安全審計建議，可參考

CIS

kubernetes

Benchmark

標準。雖然

Kubernetes

沒有為集群級日志記錄提供原生的解決方案，但是Kubernetes

官方給出了幾種常見的參考設(shè)計方法（L