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

?

2023

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

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

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

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

2023

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

2023

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

磊劉

剛浦

明李卓嘉鄭

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

CSA

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

/research/）上查看。在此感謝以上專家及單位。如此文有不妥當(dāng)之處，敬請讀者聯(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īng)用使企業(yè)機(jī)構(gòu)能夠利用他們的數(shù)據(jù)特征來獲得競爭優(yōu)勢。它能夠在正確的時(shí)間提高正確數(shù)據(jù)的戰(zhàn)略重要性，以便根據(jù)明確的數(shù)據(jù)分析結(jié)果采取快速行動?？捎^測性是一種強(qiáng)大的工具。如果能夠在戰(zhàn)略中予以規(guī)劃并成功執(zhí)行?？捎^測性應(yīng)用將成為數(shù)據(jù)驅(qū)動型決策能力建設(shè)的最強(qiáng)支撐?！北景灼榻B了可觀測性在云原生場景的架構(gòu)設(shè)計(jì)，闡述在云原生場景使用

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

404.1

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

404.2

事件預(yù)測...............................................................................................................

404.3

日志審計(jì)...............................................................................................................

414.3

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

474.4

微服務(wù)追蹤..........................................................................................................

50?

2023

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

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

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

565.1

Prometheus

項(xiàng)目..................................................................................................565.2

OpenTelemetry

項(xiàng)目.............................................................................................

595.3

SkyWalking

項(xiàng)目....................................................................................................63附件.引用文獻(xiàn)............................................................................................................

67?

2023

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

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

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

API

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

公司

Matt

Stine

在

2013

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

年

Matt

Stine將原生特征歸納為六大點(diǎn)，分別是：

模塊化

Modularity

可觀測性

Observability

可部署性

Deployability

可測試性

Testability

可處理性

Disposability

可替換性

Replaceability?

2023

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

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

IT

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

2023

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

PDCA

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

1

——

監(jiān)控（Monitoring）Level

2

——

基

礎(chǔ)

可

觀

測

性

（Basic

Observability）Level

3

——

因

果

可

觀

測

性

（Causal

Observability）Level

4

——

主動可觀測性（Proactive

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

2023

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

監(jiān)控2.1.1

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

能力在

Level1

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

基礎(chǔ)可觀測性?

2023

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

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

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

5W1H

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

Level

2

相較于

Level

1

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

2023

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

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

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

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

Level

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

能力Level2

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

2023

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

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

因果可觀測性2.3.1

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

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

Observability）”。具備因果分析能力的可觀測性體系，通過收集、分析和解析足夠多維度的數(shù)據(jù)，達(dá)到理解系統(tǒng)內(nèi)事件、狀態(tài)變化之間的關(guān)系，從而更深入地洞察系統(tǒng)運(yùn)行狀態(tài)。因果可觀測性強(qiáng)調(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

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

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

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

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

1

兩種類型數(shù)據(jù)要素拓?fù)涫且蚬捎^測性的第一個(gè)必要維度。

拓?fù)涫?/p>

IT

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

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

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有15拓?fù)湫畔ⅲ═opology）指的是系統(tǒng)中各主機(jī)、進(jìn)程、容器、API、Service

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

IT

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

2023

云安全聯(lián)盟大中華區(qū)版權(quán)所有16空間地圖是拓?fù)涞纳S，提供

IT

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

水平拓?fù)洌涸谙嗤愋偷脑刂g建立的連接關(guān)系地圖，如進(jìn)程到進(jìn)程、服務(wù)到服務(wù)、主機(jī)到主機(jī)

垂直拓?fù)洌涸诓煌愋偷脑刂g建立的連接關(guān)系地圖，如數(shù)據(jù)中心到主機(jī)、主機(jī)到進(jìn)程、進(jìn)程到服務(wù)、服務(wù)到應(yīng)用程序通過技術(shù)實(shí)現(xiàn)水平層、垂直層的空間地圖，自動化、實(shí)時(shí)性的繪制，將可觀測性數(shù)據(jù)與空間地圖的實(shí)體關(guān)聯(lián)，拉動時(shí)間軸，展示隨時(shí)間變化的空間拓?fù)?、關(guān)聯(lián)數(shù)據(jù)，能夠比較變化前后的系統(tǒng)狀態(tài)，是可觀測性能力的集中式成果體現(xiàn)。2.3.2

能力拓?fù)淇梢詷O大地提高因果判定的準(zhǔn)確性和有效性，Level

3

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

2023

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

主動可觀測性2.4.1

目標(biāo)：自動輸出問題根因、自動化響應(yīng)，智能預(yù)測、主動預(yù)防Level

4

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

和機(jī)器學(xué)習(xí)（ML）

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

2023

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

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

階段添加了模式識別、異常檢測和更準(zhǔn)確的問題修復(fù)建議。

對于主動可觀測性而言，因果可觀測性是一個(gè)必要的基礎(chǔ)：時(shí)間序列拓?fù)涮峁┝艘粋€(gè)必要的框架。數(shù)據(jù)是原材料，原材料經(jīng)過分析之后得出的答案?？焖俚陌迅哔|(zhì)量結(jié)果和答案傳達(dá)出來，快速做出決策、采取行動，是主動可觀測性需要重點(diǎn)考慮的問題。任何一套可觀測性解決方案或建設(shè)可觀測性體系之前，都應(yīng)解決三個(gè)最本質(zhì)的問題：

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

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

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

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

依托拓?fù)涞貓D、云原生系統(tǒng)產(chǎn)生的數(shù)據(jù)進(jìn)行分析，能顯示一個(gè)事件在垂直和水平方向的拓?fù)湟蕾囮P(guān)系，能夠自動確定異常問題的根源。?

2023

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

Level

4

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

IT

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

ML

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

Level4

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

能力Level

4，目前是

IT

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

SRE

和

DevOps

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

+

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

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

RCA+預(yù)測價(jià)值：自動根因定位、自動化

RCA、告警降噪、預(yù)測異常；借用

Gartner?

2022

年

3

月“Innovation

Insight

for

Observability”文章中的一段話作為本章總結(jié)：“發(fā)現(xiàn)異常很容易，因?yàn)樗鼈円恢倍荚诎l(fā)生。

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

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

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

Gartner?“Innovation

Insight

for

Observability”，2022

Mar，PadraigByrne

&

Josh

Chessman.?

2023

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

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

/

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

1

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

指標(biāo)?

2023

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

Web

服務(wù)器上觀察到的

HTTP

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

-

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

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

應(yīng)用程序日志

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

2023

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

安全日志–

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

系統(tǒng)日志

-

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

審核日志

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

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

-涉及管理影響組織

IT

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

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

30

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

2023

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

錯(cuò)誤：傳達(dá)發(fā)生情況并詳細(xì)說明發(fā)生故障的原因

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

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

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

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

2010

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

:

a

Large-Scale

Distributed

Systems

Tracing

Infrastructure》

Dapper

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

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

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

2023

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

跨度（Span）：由于每次

Trace

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

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

span

name,

span

id,

parent

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

parent

id

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

trace

id

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

Tree），如下圖

2

所示：圖

2

追蹤樹11

圖片引用自

Google

Dapper

:

a

Large-Scale

Distributed

Systems

Tracing

Infrastructure?

2023

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

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

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

Trace、Span

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

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

把

Span

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

Dapper

守護(hù)進(jìn)程和采集器從主機(jī)中將日志他們拉取出來3.

將拉取出的日志寫入

Dapper

的

Bigtable

倉庫中，其中

Bigtable

中的行表示一次跟蹤，列表示一個(gè)

span。?

2023

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

3

Dapper

工作流程2

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

HTTP

或者

RPC

請求發(fā)送給追蹤系統(tǒng)?；诜?wù)的鏈路追蹤劣勢在于比基于日志的追蹤消耗更多的資源，也有更強(qiáng)的侵入性?；诜?wù)的鏈路追蹤優(yōu)勢為這些資源消耗換來收益的直接結(jié)果是精確性與穩(wěn)定性均有所保證，從而不必再依賴日志歸集作為追蹤數(shù)據(jù)的來源?；诜?wù)的追蹤被

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ù)：運(yùn)維人員建立或者利用現(xiàn)有數(shù)據(jù)建立相關(guān)性。應(yīng)該對所有的信號使用相同的元數(shù)據(jù)結(jié)構(gòu)。盡可能對日志使用相同的標(biāo)簽。如有必要，運(yùn)維人員可自建標(biāo)簽，附加到所有類型信號的數(shù)據(jù)。連續(xù)收集所有可觀測性信號，每條數(shù)據(jù)的范圍都標(biāo)記為某個(gè)時(shí)間戳。在不同的維度上，每個(gè)可觀測性信號都需要綁定到某個(gè)“目標(biāo)”，

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

Prometheus

或

OpenTelemetry

Prometheus

接收指標(biāo)，利用日志收集器（OpenTelemetry、Fluentd、Fluentbit

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

OTLP（指標(biāo)、日志和跟蹤）等多維度集合數(shù)據(jù)時(shí)，應(yīng)用附加目標(biāo)標(biāo)簽信息，確保數(shù)據(jù)一致性。運(yùn)維人員可以基于相同的標(biāo)簽，在不同的可觀測性信號之間切換。允許從每個(gè)信號中選擇與特定過程、組件、時(shí)間相關(guān)的信息，從而快速瀏覽具有相同標(biāo)簽信號的細(xì)節(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)。運(yùn)維人員能夠通過跟蹤綁定到單條日志的請求

ID

標(biāo)簽，快速定位日志。3.2.2

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

4

所示：?

2023

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

4

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

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

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

運(yùn)行時(shí)、DB、中間件、業(yè)務(wù)軟件。

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

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

CNCF

推薦的

Fluentd

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

Filebeat

和

Logstash。?

2023

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

CNCF中主要有的

Jaeger，SkyWalking

或

Zipkin

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

API

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

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

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

Kafka

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

HDFS/HBase

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

Prometheus

存儲（Prometheus

本身也實(shí)現(xiàn)了

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

TSDB

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

Prometheus

集群架構(gòu)。而

Thanos

和

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

CNCF

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

openTSDB

或Clickhouse

來進(jìn)行指標(biāo)數(shù)據(jù)存儲。

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

2023

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

Kibana

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

Grafana

進(jìn)行展示，也可以使用原生的

Prometheus、Thanos

或

Cortex

查看。服務(wù)拓?fù)涫峭ㄟ^數(shù)據(jù)流向和調(diào)用關(guān)系，以

UI

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

或

TraceID

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

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

2023

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

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

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

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

核心能力-基于

eBPF

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

linux

內(nèi)核

eBPF

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

Linux

內(nèi)核

eBPF

技術(shù)原理eBPF

起源于

Linux

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

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

Berkeley

Packet

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

BPF(Berkeley

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

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

Linux

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

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

BPF

被簡稱為

eBPF。?

2023

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

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

64

位

RISC

指令集，在

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

eBPF

程序。eBPF

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

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

程序通常包括

4

部分：

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

eBPF

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

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

加載器：它將字節(jié)碼后端加載到內(nèi)核中，當(dāng)加載器進(jìn)程中止時(shí)，字節(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)]有更多的后端或前端進(jìn)行讀寫操作eBPF

程序的運(yùn)行流程，如下圖

5

所示：?

2023

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

5

eBPF

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

eBPF

程序2.使用

LLVM

編譯成

bytecode

的

ELF

文件3.使用

bpf

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

verifier

會驗(yàn)證

eBPF

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

JIT

compiler

把

eBPF

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

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

VM

方式安全運(yùn)行3.3.2

基于

eBPF

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

2023

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

eBPF

可以同時(shí)檢測在該機(jī)器上運(yùn)行的所有應(yīng)用程序代碼。當(dāng)將

eBPF

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

能夠?qū)趶V泛的可能來源的可視化事件的定制指標(biāo)進(jìn)行收集和核內(nèi)聚合。基于

eBPF

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

OpenTelemetry

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

eBPF

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

6：圖

6

基于

eBPF

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

2023

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

eBPF

采集數(shù)據(jù)導(dǎo)入

OpenTelemetry

Collector，步驟如下：1.

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

kubernetes

集群節(jié)點(diǎn)上基于

eBPF

的

tracepoint

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

eBPF

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

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

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

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

OpenTelemetry

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

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

kubernetes

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

eBPF

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

kubernetes

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

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

OpenTelemetry

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

Exporter

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

eBPF

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

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

資源消耗占比小，eBPF

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

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

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

2023

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

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

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

基于的

eBPF

云原生可觀測性增強(qiáng)示例

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

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

hook內(nèi)核的

accept,

connect,

send,

recv

等

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

kubernetes

集群的

metadata

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

container,

pod,

service,

node

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

eBPF

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

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

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

eBPF

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

TCP

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

kubernetes

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

HTTP

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

HTTP

黃金指標(biāo)：請求速率、請求延遲、請求響應(yīng)代碼/錯(cuò)誤。基于

eBPF

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

IP，探針在獲得?絡(luò)報(bào)文之后，進(jìn)?步解析

L7

內(nèi)容，包括

HTTP、HTTPS、gRPC

等將微服務(wù)的各個(gè)會話（?次請求和響應(yīng)）的

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

2023

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

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

CPU

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

CPU

的時(shí)間消耗分布，這種方式需要與應(yīng)用強(qiáng)綁定，受開發(fā)語言局限，并且在跟蹤多線程、多請求應(yīng)用時(shí)存在困難。基于eBPF

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

和

Off-CPU

事件?；?/p>

On-CPU

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

CPU

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

CPU

資源，如下圖

7：圖

7

CPU

資源?

2023

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

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

IT

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

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

2023

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

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

Docker

和

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

Docker

日志審計(jì)Docker

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

從

1.6

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

syslogd

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

Docker

守護(hù)進(jìn)程都有一個(gè)默認(rèn)的日志驅(qū)動程序，通常這個(gè)默認(rèn)的日志驅(qū)動是

json-file，也就是以

JSON

文件的形式保存日志信息。同時(shí)

Docker

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

none、json-file、syslog

和

fluentd

等。下表

2

展示了當(dāng)前Docker

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

log

功能，該容器

docker

logs

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

2023

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

JSON。這是

Docker

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

的系統(tǒng)

log

服務(wù)，將日志消息寫入

syslog，確保

syslog

守護(hù)程序必須在

Docker

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

的

log

服務(wù)，可以代替

syslog

服務(wù)，將日志消息寫入journald，journald

守護(hù)進(jìn)程必須在主機(jī)上運(yùn)行。gelf將

log

寫入

graylog

或

Logstash

等端點(diǎn)。將

log

寫入

fluentd，確保

fluentd

在主機(jī)上已運(yùn)行。將

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

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

CISDocker

Benchmark

v1.6.0

版本中，2.13

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

除了對容器的日志審計(jì)外，CIS

Benchmark還針對

Docker

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

Docker

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

Linux

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

Docker

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

CIS

Docker

Benchmarkv1.12.0

版本中，1.1.3

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

Docker

守護(hù)進(jìn)程，可以通過

auditctl

-l

|

grep

/usr/bin/docker

命令，列出當(dāng)前的審計(jì)規(guī)則，默認(rèn)情況下，沒有針對

Docker

守護(hù)進(jìn)程的審計(jì)規(guī)則。CIS

Benchmark

中除了對

Docker

守護(hù)進(jìn)程提出了安全審計(jì)的建議外，還對Docker

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

Docker

文件和/var/lib/docker

目錄、需要審計(jì)

Docker

文件和/etc/docker

目錄、需要審計(jì)

Docker文件和

docker.socket

目錄等。更多針對

Docker

詳細(xì)的安全審計(jì)建議，可參考

CISDocker

Benchmark

標(biāo)準(zhǔn)。4.3.2

Kubernetes

日志審計(jì)

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

2023

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

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

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

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

Kubernetes

中,

具體可參考下

日志工具小節(jié)。

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

Kubernetes

中，除了

Pod

中應(yīng)用程序的日志外，Kubernetes

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

訪問日志、Pod

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

2023

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

Kubernetes

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

等；另一種是不在容器中運(yùn)行的，比如

kubelet、以及容器運(yùn)行時(shí)等。在使用

systemd

機(jī)制的服務(wù)器上，kubelet

和容器運(yùn)行時(shí)將日志寫入到

journald

中。如果沒有

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

目錄下的.log

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

目錄，繞過默認(rèn)的日志機(jī)制。Kubernetes

默認(rèn)使用的日志庫是

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

是

glog

的

fork

版本，由于

glog

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

Kubenetes

自己維護(hù)了一個(gè)

klog,

由于

Kubernetes

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

Kubernetes

v1.23.0

開始，klog

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

Benchmark

對

Kubernetes

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

CIS

Kubernetes

Benchmark

v1.6.0

版本中，1.2.22

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

路徑，啟動

Kubernetes

API

Server

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

API

Server

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

詳細(xì)的安全審計(jì)建議，可參考

CIS

kubernetes

Benchmark

標(biāo)準(zhǔn)。雖然

Kubernetes

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

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