0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

eBPF安全可觀測性的前景展望

Linux閱碼場 ? 來源:Linux閱碼場 ? 作者:Linux閱碼場 ? 2022-08-17 11:27 ? 次閱讀

一、eBPF安全可觀測性的前景展望

本次分享將從監(jiān)控和可觀測性、eBPF安全可觀測性分析、內核安全可觀測性展望三個方面展開。

1.監(jiān)控(Monitoring)vs可觀測性(Observability)

7ee8b5ca-1dd4-11ed-ba43-dac502259ad0.png

從上圖可以看到,監(jiān)控只是可觀測性的冰山一角,而大部分都隱藏在水面之下的深層次問題無法簡單通過監(jiān)控解決。

目前監(jiān)控也開始可視化,但絕大部分都是事先預定義參數(shù),然后事后查看日志,進行分析。監(jiān)控的缺點包括:

可擴展性差,需要修改代碼和編譯;驗證周期長;數(shù)據(jù)來源窄等問題。

可觀測性是通過主動定制度量的搜集和內核數(shù)據(jù)聚合,包括以下三種:

Logging

實時或者事后特定事件信息

分布式服務器集群的海量數(shù)據(jù)溯源圖

離散信息整理各種異步信息

Tracing

數(shù)據(jù)源:提供數(shù)據(jù)來源

采集框架:往上對接數(shù)據(jù)源,采集解析發(fā)送數(shù)據(jù),往下對用戶態(tài)提供接口

前端交互:對接Tracing內核框架,直接與用戶交互,負責采集配置和數(shù)據(jù)分析

Metrics(度量)這也是可觀測性與監(jiān)控最主要的區(qū)別

系統(tǒng)中某一類信息的統(tǒng)計聚合,比如CPU、內存、網(wǎng)絡吞吐、硬盤 I/O、硬盤使用等情況。當度量值觸發(fā)異常閾值時,系統(tǒng)可以發(fā)出告警信息或主動處理,比如殺死或隔離進程;

主要目的:監(jiān)控(Monitoring)和預警(Alert)

總結一下監(jiān)控和觀測的區(qū)別:

監(jiān)控收集和分析系統(tǒng)數(shù)據(jù),查看系統(tǒng)當前的狀態(tài),對可預見的問題進行分析處理;

可觀測性通過觀察系統(tǒng)并衡量系統(tǒng)的內部狀態(tài),從其外部輸出的數(shù)據(jù)推斷出來系統(tǒng)此時處于某種程度的度量,特別是我們所關心的場景和事件;

7f1a63f4-1dd4-11ed-ba43-dac502259ad0.png

2.eBPF安全可觀測性分析

先簡單定義下什么是安全:安全指的是某種對象或者對象屬性不受威脅的狀態(tài)。

所謂安全可觀測性:

通過觀測整個系統(tǒng),從低級別的內核可見性到跟蹤文件訪問、網(wǎng)絡活動或能力(capability)變化,一直到應用層,涵蓋了諸如對易受攻擊的共享庫的函數(shù)調用、跟蹤進程執(zhí)行或解析發(fā)出的 HTTP 請求。因此這里的安全是整體的概念。

提供對各種內核子系統(tǒng)的可觀測性,涵蓋了命名空間逃逸、Capabilities 和特權升級、文件系統(tǒng)和數(shù)據(jù)訪問、HTTP、DNS、TLS 和 TCP 等協(xié)議的網(wǎng)絡活動,以及系統(tǒng)調用層的事件,以審計系統(tǒng)調用和跟蹤進程執(zhí)行。

日志、跟蹤及度量三個維度檢查相關輸出,進而來衡量系統(tǒng)內部安全狀態(tài)的能?。

eBPF的安全可觀測性表現(xiàn)為對內核來說其存在感極低但觀測能力卻異常強大(藥效好,副作用?。?/p>

程序沙箱化:通過eBPF驗證器保護內核穩(wěn)定運行。

侵入性低:無須修改內核代碼,且無須停止程序運行。

透明化:從內核中透明搜集數(shù)據(jù),保證企業(yè)最重要的數(shù)據(jù)資產(chǎn)。

可配置:Cilium等自定義乃至自動化配置策略,更新靈活性高,過濾條件豐富。

快速檢測:在內核中直接處理各種事件,不需要回傳用戶態(tài),使得異常檢測方便和快速。

其中的程序沙箱話離不開更安全的eBPF Verifier(其中最重要的是邊界檢查):

擁有加載eBPF程序的流程所需的特權

無crash或其他異常導致系統(tǒng)崩潰的情況

程序可以正常結束,無死循環(huán)

檢查內存越界

檢查寄存器溢出

eBPF的可觀測性應用場景主要有以下三類:

1.云原生容器的安全可觀測性

這也是傳統(tǒng)BPF基于網(wǎng)絡應用場景的進一步發(fā)展:

隨著云網(wǎng)邊端的急速發(fā)展,人們的目光越發(fā)的聚焦在目前最火熱的云原生場景上。Falco、Tracee、Tetragon、Datadog-agent、KubeArmor是現(xiàn)階段云原生場景下比較流行的幾款運行時防護方案。

這些方案主要是基于eBPF掛載內核函數(shù)并編寫過濾策略,在內核層出現(xiàn)異常攻擊時觸發(fā)預置的策略,無需再返回用戶層而直接發(fā)出告警甚至阻斷。

以預防的方式在整個操作系統(tǒng)中執(zhí)行安全策略,而不是對事件異步地做出反應。除了能夠為多個層級的訪問控制指定允許列表外,還能夠自動檢測特權和 Capabilities 升級或命名空間提權(容器逃逸),并自動終止受影響的進程。

安全策略可以通過 Kubernetes(CRD)、JSON API 或 Open Policy Agent(OPA)等系統(tǒng)注入。

2.應用層安全可觀測方案

7f3e4008-1dd4-11ed-ba43-dac502259ad0.png

3.內核層安全可觀測方案

7f600e72-1dd4-11ed-ba43-dac502259ad0.png

3.內核安全可觀測性展望

下面從傳統(tǒng)內核安全、Android內核安全、KRSI等幾個方面展開討論。

傳統(tǒng)內核安全方案存在著諸多需要解決的問題:

正如Linus Torvalds曾經(jīng)說過的,大多數(shù)安全問題都是bug造成的,而bug又是軟件開發(fā)過程的一部分,是軟件就有bug。

至于是安全還是非安全漏洞bug,內核社區(qū)的做法就是盡可能多的測試,找出更多潛在漏洞這樣近似于黑名單的做法。

內核代碼提交走的流程比較繁瑣,應用到具體內核版本上,又存在周期長以及版本適配的問題,所以導致內核在安全方面發(fā)展的速度明顯慢于其他模塊。同時,隨著智能化、數(shù)字化、云化的飛速發(fā)展,全球基于Linux系統(tǒng)的設備數(shù)以百億計,而這些設備的安全保障主要取決于主線內核的安全性和健壯性,當某一內核LTS版本被發(fā)有漏洞,這樣相關的機器都會面臨被攻破利用的局面,損失難以估量。

嵌入式領域的Android內核安全:

現(xiàn)如今,世界上越來越多的智能終端包括手機、TV、SmartBox和IoT、汽車、多媒體設備等等,均深度使用Android系統(tǒng),而Android的底層正是Linux內核,這也讓Linux內核的安全性對Android產(chǎn)生重大影響。

由于歷史原因,Google在Android內核開源的問題上,理念和Linux內核社區(qū)不是十分的匹配,這也導致了Android對內核做了大量的針對性修改,但是無法合入到Upstream上。這也導致了Android內核在安全側有部分不同于Linux內核,側重點也存在不同。

在操作系統(tǒng)級別,Android平臺不僅提供Linux內核的安全功能,而且還提供安全的進程間通信 (IPC)機制,以便在不同進程中運行的應用之間安全通信。操作系統(tǒng)級別的這些安全功能旨在確保即使是原生代碼也要受應用沙盒的限制。無論相應代碼是自帶應用行為導致的結果,還是利用應用漏洞導致的結果,系統(tǒng)都能防止違規(guī)應用危害其他應用、Android 系統(tǒng)或設備本身。

Android內核安全特性:

HWAddressSanitizer(硬件支持的內存檢測工具)

KASAN

Top-byte Ignore

KCFI(流控完整性校驗)

ShadowCallStack(堆棧保護)

目前工作的關注重點是內核安全可觀測性利器-KRSI:

KRSI (Kernel Runtime Security Instrumentation)的原型通過LSM (Linux security module)形式實現(xiàn),可以將eBPF program掛載到kernel的security hook(安全掛鉤點)上。內核的安全性主要包括兩個方面:Signals和Mitigations,這兩者密不可分。

Signals:意味著系統(tǒng)有一些異?;顒拥嫩E象、事件

Mitigations:在檢測到異常行為之后所采取的告警或阻斷措施

KRSI基于LSM來實現(xiàn),這也就使其能夠進行訪問控制策略的決策,但這不是KRSI的工作重心,主要是為了全面監(jiān)視系統(tǒng)行為,以便檢測攻擊(最重要的應用場景,但目前主要還是只做檢測居多,因為貿然做阻斷處理可能會比較危險)。從這種角度來看,KRSI可以說是內核審計機制的擴展,使用eBPF來提供比目前內核審計子系統(tǒng)更高級別的可配置性。

KRSI工具可以看作是eBPF和LSM的強強聯(lián)合:KRSI = eBPF + LSM

7f724754-1dd4-11ed-ba43-dac502259ad0.png

1.KRSI允許適當?shù)奶貦嘤脩魧PF程序掛載到LSM子系統(tǒng)提供的數(shù)百個鉤子中的任何一個上面。

2.為了簡化這個步驟,KRSI在/sys/kernel/security/bpf下面導出了一個新的文件系統(tǒng)層次結構——每個鉤子對應一個文件。

3.可以使用bpf()系統(tǒng)調用將BPF程序(新的BPF_PROG_TYPE_LSM 類型)掛載到這些鉤子上,并且可以有多個程序掛載到任何給定的鉤子。

4.每當觸發(fā)一個安全鉤子時,將依次調用所有掛載的BPF程序,只要任一BPF程序返回錯誤狀態(tài),那么請求的操作將被拒絕。

5.KRSI能夠從函數(shù)級別做阻斷操作,相比進程具有更細粒度,危險程度也會小得多。

后續(xù)計劃

內核安全問題是個非常復雜的話題,牽一發(fā)而動全身,防御機制、加固配置、漏洞利用等等挑戰(zhàn)性的技術。在進行加固防御的過程中,又會產(chǎn)生性能或者系統(tǒng)穩(wěn)定性相關的影響。

從eBPF + LSM的角度可以更加可視化、數(shù)據(jù)豐富的觀測內核安全情況,進而在內核Livepatch、漏洞檢測以及防御提權相關攻擊手段上,有著進一步的發(fā)展空間。

二、Linux進程調度與性能優(yōu)化

本次分享將從進程調度概念、進程調度框架、進程調度算法和性能優(yōu)化四個方面展開。

1.進程調度概念

7f87ad4c-1dd4-11ed-ba43-dac502259ad0.png

最初的Linux只有進程,task_struct相當于進程控制塊(PCB),后來出現(xiàn)了線程,task_struct就開始對應線程。Linux沒有從概念上直接區(qū)分兩者,如果不同的task_struct間共享資源,它們屬于同一進程中的線程,否則就屬于不同的進程。

這里要注意,用戶態(tài)中的進程和線程與內核態(tài)間的映射關系:用戶態(tài)函數(shù)getpid()得到的是內核中的tgid;用戶態(tài)函數(shù)gettid()得到的是內核中的pid。

Posix支持一級調度和二級調度兩種模式,二級調度會先調度進程,然后才是進程中的線程。而Linux選擇的是直接調度線程的一級調度,效率會比二級調度高。

Linux進程調度體系如下圖:

7fb2844a-1dd4-11ed-ba43-dac502259ad0.png

CPU資源管理器(what):調度器(scheduler)就是CPU資源管理器,因為操作系統(tǒng)的重要作用之一是管理各種系統(tǒng)資源,而CPU是其中最重要的資源。常用直接共享型資源的管理方法有時分、空分、獨占等,IO一般是獨占資源,內存支持空分管理,而CPU只支持時分,因此這種時分管理方法就是進程調度。

為什么要及為什么能調度(why):

為什么要調度:宏觀并行,微觀串行,支持多任務的協(xié)作與搶占。最初是協(xié)作,后來為了防止個別進程長期霸占CPU,引入了搶占機制。

為什么能調度:包括主動調度和被動調度,線程上下文可切換。

調度時機(when):

主動調度:通過主動調用sched_yield的自愿性主動調度,以及進程由于等待資源而阻塞的非自愿性主動調度。

被動調度:

觸發(fā)點:設置 TIF_NEED_RESCHED 標志,主要是時鐘中斷和喚醒搶占。

執(zhí)行點:檢查 TIF_NEED_RESCHED 標志 和 滿足preempt_count == 0的條件。

主要包括以下四種場景:

系統(tǒng)調用完成返回用戶空間

完成返回用戶空間

中斷完成返回內核空間

出禁用搶占臨界區(qū)

如何進行調度(how):調用pick_next_task()選擇下一個調度進程和通過context_switch切換進程(上下文:內存空間,寄存器和棧)。

下面按時間順序簡單介紹一下linux調度器的發(fā)展歷史:

傳統(tǒng)Unix調度器:區(qū)分IO密集型和CPU密集型,但全局只有一個未排序的運行隊列,多CPU會有競爭,而且調度選擇需要遍歷整個隊列,復雜度為O(n)。

O(1)調度器:運行隊列從全局變成每個CPU一個,鏈表分成活動和過期兩個數(shù)組,引入位圖,復雜度降為為O(1)。

SD調度器:考慮到會因為個別進程的偽裝而造成的實際調度不公平,不再區(qū)分IO和CPU密集型,未合入內核。

RSDL調度器:組時間配額,有點像Cgroup,但未合入內核。

CFS(完全公平調度器):從SD/RSDL中吸取了完全公平的思想,目前內核主流調度器。

可以從以下幾個方面來評價調度器:

1.響應性:存在大量人機交互的PC和手機要重視響應。

2.吞吐量:服務器更關心吞吐量,而提高響應性會增加進程切換的評論,也就會降低吞吐量。所以響應和吞吐是一對矛盾。

3.公平性:相對公平,實際和理論的運行時間應該相符。

4.適應性:也就是可擴展性。

5.節(jié)能性智能手機的需求,需要通過調度均衡來省電。

2.進程調度框架

如下圖所示,Linux一共有5個調度類:(stop和idle每個CPU一個)

stop:無調度策略,用戶空間不可用,內核用來處理線程遷移等優(yōu)先級極高的事情。

idle:無調度策略,用戶空間不可用,無其他進程調用時才調用idle進程。

deadline:硬實時,要在確定時延內完成調度。

realtime:軟實時,盡力而為保證實時性。

time-share:按優(yōu)先級分配時間片。

7fc69e08-1dd4-11ed-ba43-dac502259ad0.png

調度類之間的關系:除非資源限制,優(yōu)先調度高優(yōu)先級進程。但要注意,Linux考慮到在惡劣環(huán)境下,普通進程應該仍有被調度的機會,會默認預留有5%的帶寬給普通進程。

如下圖所示,從用戶空間到內核空間,進程優(yōu)先級會發(fā)生轉換:

7feaa74e-1dd4-11ed-ba43-dac502259ad0.png

用戶空間優(yōu)先級:分為1~99優(yōu)先級從低到高的實時進程,以及nice值-20~19動態(tài)優(yōu)先級從高到低的分時進程。

映射到內核空間優(yōu)先級分為三步:

1.實時優(yōu)先級:實時進程不變,分時進程從動態(tài)優(yōu)先級映射為100~139靜態(tài)優(yōu)先級由高到低。

2.規(guī)范優(yōu)先級:實時進程映射為-1~98優(yōu)先級由高到低,99為空,分時進程靜態(tài)優(yōu)先級不變。

3.動態(tài)優(yōu)先級:可以看到動態(tài)優(yōu)先級幾乎等于規(guī)范優(yōu)先級,只有在解決優(yōu)先級反轉問題時采用優(yōu)先級繼承策略時才會變化,此時會體現(xiàn)為動態(tài)優(yōu)先級。

注意:-1和-2分別對應deadline和stop的邏輯優(yōu)先級。

那如何進行進程切換呢?

切換用戶空間:不同進程的用戶空間不同,需要切換。

切換內核棧:不同進程共享內核空間,但需要切換內核棧。進程切換就像火車切換軌道,換道后,車上的人感覺火車沒變,但是因為軌道變了,行程也就跟著變了。線程的執(zhí)行過程就是函數(shù)調用樹的深度優(yōu)先遍歷,進程的切換點是__schedule函數(shù),該函數(shù)前半部分在進程A的調用棧上執(zhí)行,后半部分就跑到進程B的調用棧上執(zhí)行了,返回則在新進程上執(zhí)行。

3.進程調度算法

CFS調度器定義:通過引入虛擬運行時間vruntime(realtime / weight),每次選擇vruntime最小的進程(紅黑樹來管理)來調度,在真實硬件上模擬理想多任務處理器。

枯燥的定義不太容易理解的話,下面我們通過一個與實際生活比較貼近的例子來解釋CFS調度模型。

7ffa9d5c-1dd4-11ed-ba43-dac502259ad0.png

請仔細觀察上圖,圖中事物與進程調度的映射關系如下:

水杯:表示進程,蓋子打開的水杯表示進程處于就緒和執(zhí)行狀態(tài),其中Ready Table上的水杯都是就緒態(tài)進程,水龍頭下的水杯是運行態(tài)進程。蓋子閉合的表示阻塞態(tài)的進程,它們都在不同的Wait Box中。

水杯的粗細:表示不同的優(yōu)先級。

watermark:表示虛擬運行時間vruntime,min watermark會被pick to run。

Ready Table:表示可運行隊列rq。

Wait Box:表示不同Event對應的等待隊列,如果只能由對應的Event喚醒的話,就屬于不可中斷的深睡眠,否則就是也可由signal喚醒的可中斷淺睡眠。

水龍頭:表示CPU,水龍頭中放出來的水就是CPU時間。

操作pick to run的手:表示調度算法,如果調度過于頻繁,那杯子接的水就少,水龍頭的水掉地上浪費了(響應好但性能差);反之調度周期長的話,杯子接的水太多會造成不平均(性能好但響應差)。權衡下來既不能接太少,最小值就是調度粒度;也不能接太多,最大值就是時間片。

這里需要特別注意的幾點:

1.進程的狀態(tài)

注意區(qū)別進程的5種狀態(tài)中的運行態(tài)和就緒態(tài),所有就緒態(tài)進程都位于cpu的運行隊列中,而每個cpu上當前只有一個運行態(tài)進程??梢钥吹较旅娴拇a分別通過on_rq和on_cpu來確定進程是runnable的就緒態(tài)還是running的運行態(tài)。對應上面的例子,桌子上的開口水杯表示就緒(on_rq),水龍頭下的開口水杯表示運行(on_cpu)。

8021256c-1dd4-11ed-ba43-dac502259ad0.png

2.優(yōu)先級與權重

CFS中的nice值會提前轉換為權重,nice的范圍是 [-20 -- 19],為了使得兩個相鄰的權重的占比差為10%,將以nice 0 為基準轉化為1024,整個數(shù)列是以1.25為公比的等比數(shù)列。將原來的等差數(shù)列轉為等比數(shù)列,因為調度策略的絕對值不重要,相對值(比例)才重要。

3.調度周期

調度周期 = 調度粒度 * 就緒和運行進程的數(shù)量,對應上面的例子就是所有開蓋玻璃杯數(shù)量(桌子上和水龍頭下的)與調度粒度的乘積,等于調度周期(所有杯子都接了一次水)。最小調度周期等于最小粒度乘以數(shù)量,如果計算算出來的時間片小于最小調度周期,內核就會讓時間片直接等于最小調度周期。

4.調度延遲

調度延遲是另一個概念,對應上面的例子就是從開口玻璃杯放到到桌子上開始計算,到送到水龍頭下接水的時間。但要注意,Linux中的調度延遲卻不這個意思,內核代碼體現(xiàn)的調度延遲是最小調度周期,也就是調度周期的最小值。

4.性能優(yōu)化

單個進程的性能優(yōu)化:

對于單個進程來說,可以通過下面的系統(tǒng)調用來改變進程(線程)的調度策略和優(yōu)先級,只有特權進程才能調高自己的調度策略或者優(yōu)先級。一般不要輕易地把進程設置為實時進程或者提高其優(yōu)先級,除非有充足的理由。

系統(tǒng)響應性與吞吐量的優(yōu)化:

系統(tǒng)的響應性和吞吐量是一對矛盾,很多時候我們要根據(jù)具體的情況來對系統(tǒng)進行配置。CONFIG_PREEMPT:是否開啟內核搶占,開啟可增加響應性,不開啟可增加吞吐量。一般服務器系統(tǒng)不會開啟,桌面和移動系統(tǒng)會開啟。

定時器tick頻率HZ:

定時器tick的頻率HZ,對系統(tǒng)的響應性和吞吐量也有很大的影響,HZ取值較大,系統(tǒng)響應性好,但是吞吐量會降低,HZ取值較小,吞吐量會增大,但是響應性會降低。

避免實時進程過度占用CPU:

為此內核提供了一對參數(shù),可以設置一個運行周期內,實時進程最多只能用多少CPU時間,這樣就可以給普通進程留下一些執(zhí)行時間。這兩個參數(shù)對應的文件是:

/proc/sys/kernel/sched_rt_period_us/proc/sys/kernel/sched_rt_runtime_us

可以通過cat和echo來查看和設置具體的值,單位是微妙默認值分別是1000000,950000,也就是說在每一秒內實時進程最多運行0.95s,會給普通進程保留0.5s。當然如果此時沒有普通進程,實時進程還是可以使用100%的CPU時間的。如果我們不希望實時進程使用過多的CPU時間的話,可以修改這個值。

子進程是否優(yōu)先運行的問題:

默認情況下父進程與剛fork出來的子進程,誰會先得到執(zhí)行是不確定的。如果在我們的環(huán)境中經(jīng)常會fork子進程,并且我們總是希望子進程比父進程先得到執(zhí)行,那么我們可以將/proc/sys/kernel/sched_child_runs_first值設為1。

審核編輯:彭靜
聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權轉載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 數(shù)據(jù)

    關注

    8

    文章

    6808

    瀏覽量

    88743
  • 監(jiān)控
    +關注

    關注

    6

    文章

    2162

    瀏覽量

    55041
  • 服務器
    +關注

    關注

    12

    文章

    8958

    瀏覽量

    85080
  • 代碼
    +關注

    關注

    30

    文章

    4722

    瀏覽量

    68229

原文標題:PODS2022: eBPF安全可觀測性的前景展望&Linux進程調度與性能優(yōu)化速記(Day2)

文章出處:【微信號:LinuxDev,微信公眾號:Linux閱碼場】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    關于 eBPF 安全可觀測,你需要知道的那些事兒

    安全方面的一些思考和心得,本次分享將從監(jiān)控和可觀測、eBPF 安全可觀測
    發(fā)表于 09-08 15:31

    openEuler 倡議建立 eBPF 軟件發(fā)布標準

    eBPF 被廣泛應用在云原生、可觀測、性能調優(yōu)、安全、硬件加速等領域,并且其應用場景還在快速擴展,各種場景基于 eBPF 技術的創(chuàng)新 idea 呈現(xiàn)井噴現(xiàn)象,
    發(fā)表于 12-23 16:21

    基于拓撲分割的網(wǎng)絡可觀測分析方法

    針對電力網(wǎng)絡可觀測分析問題,對量測網(wǎng)絡建模、網(wǎng)絡拓撲可觀測分析理論、不可觀測節(jié)點的影響范圍等方面進行了研究,提出了一種基于拓撲分割的網(wǎng)絡
    發(fā)表于 03-06 18:03 ?0次下載
    基于拓撲分割的網(wǎng)絡<b class='flag-5'>可觀測</b><b class='flag-5'>性</b>分析方法

    如何將可觀測策略與APM工具結合起來

    獲悉IBM Instana被Gartner評選為2022年度應用性能監(jiān)控(APM)和可觀測(Observbility)魔力象限的領導者,我與我身邊同事們都與有榮焉。不僅Instana實現(xiàn)了其領先級企業(yè)可觀測
    的頭像 發(fā)表于 07-27 11:19 ?1200次閱讀

    介紹eBPF針對可觀測場景的應用

    隨著eBPF推出,由于具有高性能、高擴展、安全性等優(yōu)勢,目前已經(jīng)在網(wǎng)絡、安全、可觀察等領域廣泛應用,同時也誕生了許多優(yōu)秀的開源項目,如Cilium、Pixie等,而iLogtail 作
    的頭像 發(fā)表于 08-11 09:10 ?1516次閱讀

    六大頂級、開源的數(shù)據(jù)可觀測工具

    企業(yè)有很多商業(yè)數(shù)據(jù)可觀測工具可供選擇。商業(yè)工具在可伸縮、自動化和支持方面具有一些關鍵優(yōu)勢。然而,數(shù)據(jù)可觀測的開源工具允許團隊在沒有前期
    的頭像 發(fā)表于 12-16 11:29 ?1936次閱讀

    什么是eBPFeBPF為何備受追捧?

    用云杉網(wǎng)絡 VP 向陽的話來說:“ eBPF 最重要(沒有之一)的特點是安全性” 。他表示,以往必須編寫內核模塊才能做到的工作現(xiàn)在基本都能做到。
    的頭像 發(fā)表于 05-06 11:41 ?2186次閱讀

    eBPF,何以稱得上是革命的內核技術?

    提供了一種通用執(zhí)行引擎,可以基于系統(tǒng)或程序事件高效安全地執(zhí)行特定代碼,就像在實時 (JIT) 編譯器和驗證引擎的幫助下進行本機編譯一樣。 如今,eBPF 被廣泛用于各種場景:在現(xiàn)代數(shù)據(jù)中心和云原生環(huán)境中提供高性能網(wǎng)絡和負載平衡,以低成本提取細粒度的
    的頭像 發(fā)表于 05-08 08:26 ?568次閱讀
    <b class='flag-5'>eBPF</b>,何以稱得上是革命<b class='flag-5'>性</b>的內核技術?

    華為云應用運維管理平臺獲評中國信通院可觀測評估先進級

    近日,華為云應用運維管理平臺參與了中國信息通信研究院(以下簡稱“中國信通院”)主辦的“穩(wěn)保行動”的可觀測平臺能力評估。經(jīng)過中國信通院的檢驗,華為云應用運維管理平臺滿足云上軟件系統(tǒng)穩(wěn)定-可觀測
    的頭像 發(fā)表于 07-01 21:16 ?476次閱讀
    華為云應用運維管理平臺獲評中國信通院<b class='flag-5'>可觀測</b><b class='flag-5'>性</b>評估先進級

    使用APM無法實現(xiàn)真正可觀測的原因

    控制理論中的可觀測是指:系統(tǒng)可以由其外部輸出確定其內部狀態(tài)的程度。在復雜 IT 系統(tǒng)中,具備可觀測是為了讓系統(tǒng)能達到某個預定的穩(wěn)定性、錯誤率目標。隨著微服務數(shù)量的急速膨脹和云原生基
    的頭像 發(fā)表于 09-18 10:23 ?853次閱讀
    使用APM無法實現(xiàn)真正<b class='flag-5'>可觀測</b><b class='flag-5'>性</b>的原因

    什么是多云? 為什么我們需要多云可觀測 (Observability)?

    什么是多云? 為什么我們需要多云可觀測 (Observability)?
    的頭像 發(fā)表于 10-12 17:12 ?591次閱讀
    什么是多云? 為什么我們需要多云<b class='flag-5'>可觀測</b><b class='flag-5'>性</b> (Observability)?

    如何構建APISIX基于DeepFlow的統(tǒng)一可觀測性能力呢?

    隨著應用組件的可觀測逐漸受到重視,Apache APISIX 引入插件機制豐富了可觀測數(shù)據(jù)源。
    的頭像 發(fā)表于 01-18 10:11 ?880次閱讀
    如何構建APISIX基于DeepFlow的統(tǒng)一<b class='flag-5'>可觀測</b>性能力呢?

    華為云發(fā)布全棧可觀測平臺 AOM,以 AI 賦能應用運維可觀測

    應用可用與穩(wěn)定性。 該平臺發(fā)布標志著華為云在推動數(shù)字化轉型和智能化運維領域的又一重大突破,全棧可觀測平臺的推出不僅為企業(yè)提供了更加全面和深入的系統(tǒng)監(jiān)控和數(shù)據(jù)分析能力,還通過集成先進的人工智能技術,實現(xiàn)了對復雜應用環(huán)境的實時優(yōu)化和問題預警。 應用
    的頭像 發(fā)表于 10-15 09:54 ?415次閱讀
    華為云發(fā)布全棧<b class='flag-5'>可觀測</b>平臺 AOM,以 AI 賦能應用運維<b class='flag-5'>可觀測</b>

    【質量視角】可觀測背景下的質量保障思路

    目前質量團隊正在積極建設和完善應用監(jiān)控能力,旨在能及時發(fā)現(xiàn)并解決問題,為線上服務穩(wěn)定性保駕護航。隨著可觀測概念的逐漸普及,監(jiān)控的建設也有了新的挑戰(zhàn)和使命。本文將探討在可觀測背景下,
    的頭像 發(fā)表于 10-25 17:21 ?181次閱讀
    【質量視角】<b class='flag-5'>可觀測</b><b class='flag-5'>性</b>背景下的質量保障思路

    破局新生丨基調聽云可觀測與應用安全技術研討會在平潭圓滿舉辦

    2024年10月24日,由中國信通院穩(wěn)定性保障實驗室、華為云、基調聽云聯(lián)合主辦的“破局新生·可觀測與應用安全技術研討會”在福建平潭隆重舉行。本次研討會以技術研討為本,以創(chuàng)新發(fā)展為翼,匯集了來自金融
    的頭像 發(fā)表于 10-29 16:01 ?313次閱讀
    破局新生丨基調聽云<b class='flag-5'>可觀測</b><b class='flag-5'>性</b>與應用<b class='flag-5'>安全</b>技術研討會在平潭圓滿舉辦