ईबीपीएफ/बीसीसी का उपयोग करके हाई सेफ लेटेंसी से कर्नेल पैच तक

लिनक्स में कर्नेल और एप्लिकेशन को डीबग करने के लिए बड़ी संख्या में उपकरण हैं। उनमें से अधिकांश का अनुप्रयोग प्रदर्शन पर नकारात्मक प्रभाव पड़ता है और उत्पादन में उनका उपयोग नहीं किया जा सकता है।

कुछ साल पहले वहाँ था एक और उपकरण विकसित किया गया है - ईबीपीएफ। यह कम ओवरहेड के साथ कर्नेल और उपयोगकर्ता अनुप्रयोगों का पता लगाना संभव बनाता है और कार्यक्रमों को पुनर्निर्माण करने और कर्नेल में तीसरे पक्ष के मॉड्यूल को लोड करने की आवश्यकता के बिना।

पहले से ही कई एप्लिकेशन उपयोगिताएँ हैं जो ईबीपीएफ का उपयोग करती हैं, और इस लेख में हम देखेंगे कि लाइब्रेरी के आधार पर अपनी खुद की प्रोफाइलिंग उपयोगिता कैसे लिखें पायथनबीसीसी. लेख वास्तविक घटनाओं पर आधारित है. हम यह दिखाने के लिए समस्या से समाधान की ओर जाएंगे कि विशिष्ट परिस्थितियों में मौजूदा उपयोगिताओं का उपयोग कैसे किया जा सकता है।

सेफ़ धीमा है

सेफ क्लस्टर में एक नया होस्ट जोड़ा गया है। कुछ डेटा को इसमें स्थानांतरित करने के बाद, हमने देखा कि इसके द्वारा लेखन अनुरोधों को संसाधित करने की गति अन्य सर्वरों की तुलना में बहुत कम थी।

अन्य प्लेटफ़ॉर्म के विपरीत, इस होस्ट ने bcache और नए linux 4.15 कर्नेल का उपयोग किया। यह पहली बार था जब इस कॉन्फ़िगरेशन का होस्ट यहां उपयोग किया गया था। और उस क्षण यह स्पष्ट था कि समस्या की जड़ सैद्धांतिक रूप से कुछ भी हो सकती है।

मेज़बान की जाँच

आइए यह देखना शुरू करें कि सेफ-ओएसडी प्रक्रिया के अंदर क्या होता है। इसके लिए हम प्रयोग करेंगे पर्फ़ и फ्लेमस्कोप (जिसके बारे में आप अधिक पढ़ सकते हैं यहां):

चित्र हमें बताता है कि फ़ंक्शन fdatasync() फ़ंक्शंस के लिए अनुरोध भेजने में बहुत समय व्यतीत हुआ जेनेरिक_मेक_अनुरोध(). इसका मतलब यह है कि सबसे अधिक संभावना है कि समस्याओं का कारण ओएसडी डेमॉन के बाहर ही कहीं है। यह या तो कर्नेल या डिस्क हो सकता है। Iostat आउटपुट ने bcache डिस्क द्वारा प्रसंस्करण अनुरोधों में उच्च विलंबता दिखाई।

होस्ट की जांच करते समय, हमने पाया कि सिस्टमडी-यूडीवीडी डेमॉन बड़ी मात्रा में सीपीयू समय की खपत करता है - कई कोर पर लगभग 20%। यह अजीब व्यवहार है, इसलिए आपको इसका कारण पता लगाना होगा। चूँकि Systemd-udevd uevents के साथ काम करता है, इसलिए हमने उन पर गौर करने का निर्णय लिया udevadm मॉनिटर. यह पता चला है कि सिस्टम में प्रत्येक ब्लॉक डिवाइस के लिए बड़ी संख्या में परिवर्तन घटनाएं उत्पन्न हुईं। यह काफी असामान्य है, इसलिए हमें यह देखना होगा कि इन सभी घटनाओं का कारण क्या है।

बीसीसी टूलकिट का उपयोग करना

जैसा कि हम पहले ही पता लगा चुके हैं, कर्नेल (और सिस्टम कॉल में सेफ़ डेमॉन) बहुत समय बिताता है जेनेरिक_मेक_अनुरोध(). आइए इस फ़ंक्शन की गति को मापने का प्रयास करें। में बीसीसी वहाँ पहले से ही एक अद्भुत उपयोगिता मौजूद है - funclatency. हम आउटपुट के बीच 1 सेकंड के अंतराल के साथ उसके पीआईडी ​​द्वारा डेमॉन का पता लगाएंगे और परिणाम को मिलीसेकंड में आउटपुट करेंगे।

यह सुविधा आमतौर पर तेज़ी से काम करती है. यह बस अनुरोध को डिवाइस ड्राइवर कतार में भेज देता है।

Bcache एक जटिल उपकरण है जिसमें वास्तव में तीन डिस्क होती हैं:

• बैकिंग डिवाइस (कैश्ड डिस्क), इस मामले में यह एक धीमी एचडीडी है;
• कैशिंग डिवाइस (कैशिंग डिस्क), यहां यह NVMe डिवाइस का एक विभाजन है;
• bcache वर्चुअल डिवाइस जिसके साथ एप्लिकेशन चलता है।

हम जानते हैं कि अनुरोध संचरण धीमा है, लेकिन इनमें से किस डिवाइस के लिए? हम इससे थोड़ी देर बाद निपटेंगे।

अब हम जानते हैं कि घटनाओं से समस्याएं पैदा होने की संभावना है। यह पता लगाना कि वास्तव में उनकी पीढ़ी का कारण क्या है, इतना आसान नहीं है। आइए मान लें कि यह एक प्रकार का सॉफ़्टवेयर है जो समय-समय पर लॉन्च किया जाता है। आइए देखें कि स्क्रिप्ट का उपयोग करके सिस्टम पर किस प्रकार का सॉफ़्टवेयर चलता है execsnoop उसी से बीसीसी उपयोगिता किट. चलिए इसे चलाते हैं और आउटपुट को एक फ़ाइल में भेजते हैं।

उदाहरण के लिए, इस तरह:

/usr/share/bcc/tools/execsnoop  | tee ./execdump

हम यहां execsnoop का पूरा आउटपुट नहीं दिखाएंगे, लेकिन हमारी रुचि की एक पंक्ति इस तरह दिखी:

sh 1764905 5802 0 sudo arcconf getconfig 1 AD | grep Temperature | awk -F '[:/]' '{print $2}' | sed 's/^ ([0-9]*) C.*/1/'

तीसरा कॉलम प्रक्रिया का पीपीआईडी ​​(मूल पीआईडी) है। पीआईडी ​​5802 के साथ प्रक्रिया हमारी निगरानी प्रणाली के धागों में से एक बन गई। निगरानी प्रणाली के कॉन्फ़िगरेशन की जाँच करते समय, गलत पैरामीटर पाए गए। एचबीए एडॉप्टर का तापमान हर 30 सेकंड में लिया जाता था, जो कि आवश्यकता से कहीं अधिक है। चेक अंतराल को लंबे अंतराल में बदलने के बाद, हमने पाया कि इस होस्ट पर अनुरोध प्रसंस्करण विलंबता अब अन्य होस्ट की तुलना में अलग नहीं है।

लेकिन यह अभी भी स्पष्ट नहीं है कि bcache डिवाइस इतना धीमा क्यों था। हमने एक समान कॉन्फ़िगरेशन के साथ एक परीक्षण प्लेटफ़ॉर्म तैयार किया और bcache पर fio चलाकर, समय-समय पर uevents उत्पन्न करने के लिए udevadm ट्रिगर चलाकर समस्या को पुन: उत्पन्न करने का प्रयास किया।

बीसीसी-आधारित उपकरण लिखना

आइए सबसे धीमी कॉलों का पता लगाने और उन्हें प्रदर्शित करने के लिए एक सरल उपयोगिता लिखने का प्रयास करें जेनेरिक_मेक_अनुरोध(). हमें उस ड्राइव के नाम में भी रुचि है जिसके लिए यह फ़ंक्शन बुलाया गया था।

योजना सरल है:

• पंजीकरण करवाना kprobe पर जेनेरिक_मेक_अनुरोध():
  • हम डिस्क नाम को मेमोरी में सहेजते हैं, जिसे फ़ंक्शन तर्क के माध्यम से एक्सेस किया जा सकता है;
  • हम टाइमस्टैम्प सहेजते हैं।

• पंजीकरण करवाना cretprobe से वापसी के लिए जेनेरिक_मेक_अनुरोध():
  • हमें वर्तमान टाइमस्टैम्प मिलता है;
  • हम सहेजे गए टाइमस्टैम्प की तलाश करते हैं और इसकी तुलना वर्तमान टाइमस्टैम्प से करते हैं;
  • यदि परिणाम निर्दिष्ट से अधिक है, तो हम सहेजे गए डिस्क नाम को ढूंढते हैं और इसे टर्मिनल पर प्रदर्शित करते हैं।

Kprobes и cretprobes तुरंत फ़ंक्शन कोड बदलने के लिए ब्रेकपॉइंट तंत्र का उपयोग करें। तुम पढ़ सकते हो प्रलेखन и अच्छा इस विषय पर आलेख. यदि आप विभिन्न उपयोगिताओं के कोड को देखते हैं बीसीसी, तो आप देख सकते हैं कि उनकी संरचना एक समान है। इसलिए इस लेख में हम स्क्रिप्ट तर्कों को पार्स करना छोड़ देंगे और बीपीएफ प्रोग्राम पर ही आगे बढ़ेंगे।

पायथन स्क्रिप्ट के अंदर eBPF टेक्स्ट इस तरह दिखता है:

bpf_text = “”” # Here will be the bpf program code “””

कार्यों के बीच डेटा का आदान-प्रदान करने के लिए eBPF प्रोग्राम का उपयोग किया जाता है हैश टेबल. हम वैसा ही करेंगे. हम प्रक्रिया पीआईडी ​​को कुंजी के रूप में उपयोग करेंगे, और संरचना को मूल्य के रूप में परिभाषित करेंगे:

struct data_t {
	u64 pid;
	u64 ts;
	char comm[TASK_COMM_LEN];
	u64 lat;
	char disk[DISK_NAME_LEN];
};

BPF_HASH(p, u64, struct data_t);
BPF_PERF_OUTPUT(events);

यहां हम एक हैश तालिका पंजीकृत करते हैं जिसे कहा जाता है p, कुंजी प्रकार के साथ u64 और प्रकार का एक मान संरचना डेटा_t. तालिका हमारे बीपीएफ कार्यक्रम के संदर्भ में उपलब्ध होगी। BPF_PERF_OUTPUT मैक्रो एक अन्य तालिका को पंजीकृत करता है जिसे कहा जाता है घटनाओं, जिसका उपयोग किया जाता है डेटा ट्रांसमिशन उपयोगकर्ता स्थान में.

किसी फ़ंक्शन को कॉल करने और उससे लौटने के बीच, या विभिन्न फ़ंक्शन पर कॉल के बीच देरी को मापते समय, आपको यह ध्यान रखना होगा कि प्राप्त डेटा एक ही संदर्भ से संबंधित होना चाहिए। दूसरे शब्दों में, आपको कार्यों के संभावित समानांतर लॉन्च के बारे में याद रखना होगा। हमारे पास एक प्रक्रिया के संदर्भ में किसी फ़ंक्शन को कॉल करने और किसी अन्य प्रक्रिया के संदर्भ में उस फ़ंक्शन से लौटने के बीच विलंबता को मापने की क्षमता है, लेकिन यह संभवतः बेकार है। यहाँ एक अच्छा उदाहरण होगा बायोलेटेंसी उपयोगिता, जहां हैश तालिका कुंजी को एक सूचक पर सेट किया गया है संरचना अनुरोध, जो एक डिस्क अनुरोध को दर्शाता है।

इसके बाद, हमें वह कोड लिखना होगा जो अध्ययन के तहत फ़ंक्शन को कॉल करने पर चलेगा:

void start(struct pt_regs *ctx, struct bio *bio) {
	u64 pid = bpf_get_current_pid_tgid();
	struct data_t data = {};
	u64 ts = bpf_ktime_get_ns();
	data.pid = pid;
	data.ts = ts;
	bpf_probe_read_str(&data.disk, sizeof(data.disk), (void*)bio->bi_disk->disk_name);
	p.update(&pid, &data);
}

यहां कॉल किए गए फ़ंक्शन का पहला तर्क दूसरे तर्क के रूप में प्रतिस्थापित किया जाएगा जेनेरिक_मेक_अनुरोध(). इसके बाद, हम जिस प्रक्रिया के संदर्भ में काम कर रहे हैं, उसकी पीआईडी ​​और नैनोसेकंड में वर्तमान टाइमस्टैम्प प्राप्त करते हैं। हम यह सब नए सिरे से चयनित रूप में लिखते हैं संरचना डेटा_टी डेटा. हमें डिस्क का नाम संरचना से मिलता है जैव, जो कॉल करते समय पास हो जाता है जेनेरिक_मेक_अनुरोध(), और इसे उसी संरचना में सहेजें तिथि. अंतिम चरण हैश तालिका में एक प्रविष्टि जोड़ना है जिसका पहले उल्लेख किया गया था।

से लौटने पर निम्नलिखित फ़ंक्शन को कॉल किया जाएगा जेनेरिक_मेक_अनुरोध():

void stop(struct pt_regs *ctx) {
    u64 pid = bpf_get_current_pid_tgid();
    u64 ts = bpf_ktime_get_ns();
    struct data_t* data = p.lookup(&pid);
    if (data != 0 && data->ts > 0) {
        bpf_get_current_comm(&data->comm, sizeof(data->comm));
        data->lat = (ts - data->ts)/1000;
        if (data->lat > MIN_US) {
            FACTOR
            data->pid >>= 32;
            events.perf_submit(ctx, data, sizeof(struct data_t));
        }
        p.delete(&pid);
    }
}

यह फ़ंक्शन पिछले वाले के समान है: हम प्रक्रिया की पीआईडी ​​और टाइमस्टैम्प का पता लगाते हैं, लेकिन नई डेटा संरचना के लिए मेमोरी आवंटित नहीं करते हैं। इसके बजाय, हम कुंजी == वर्तमान पीआईडी ​​का उपयोग करके पहले से मौजूद संरचना के लिए हैश तालिका खोजते हैं। यदि संरचना मिल जाती है, तो हम चल रही प्रक्रिया का नाम ढूंढते हैं और उसे इसमें जोड़ते हैं।

यहां हम जिस बाइनरी शिफ्ट का उपयोग करते हैं, वह थ्रेड जीआईडी ​​प्राप्त करने के लिए आवश्यक है। वे। मुख्य प्रक्रिया की पीआईडी ​​जिसने थ्रेड शुरू किया जिसके संदर्भ में हम काम कर रहे हैं। जिस फ़ंक्शन को हम कॉल करते हैं bpf_get_current_pid_tgid() थ्रेड की GID और उसकी PID दोनों को एक ही 64-बिट मान में लौटाता है।

टर्मिनल पर आउटपुट करते समय, हम वर्तमान में थ्रेड में रुचि नहीं रखते हैं, लेकिन हम मुख्य प्रक्रिया में रुचि रखते हैं। किसी दिए गए सीमा के साथ परिणामी देरी की तुलना करने के बाद, हम अपनी संरचना पास करते हैं तिथि तालिका के माध्यम से उपयोगकर्ता स्थान में घटनाओं, जिसके बाद हम प्रविष्टि को हटा देते हैं p.

इस कोड को लोड करने वाली पायथन स्क्रिप्ट में, हमें MIN_US और FACTOR को विलंब सीमा और समय इकाइयों से बदलने की आवश्यकता है, जिसे हम तर्कों से गुजारेंगे:

bpf_text = bpf_text.replace('MIN_US',str(min_usec))
if args.milliseconds:
	bpf_text = bpf_text.replace('FACTOR','data->lat /= 1000;')
	label = "msec"
else:
	bpf_text = bpf_text.replace('FACTOR','')
	label = "usec"

अब हमें BPF प्रोग्राम तैयार करने की आवश्यकता है बीपीएफ मैक्रो और नमूने पंजीकृत करें:

b = BPF(text=bpf_text)
b.attach_kprobe(event="generic_make_request",fn_name="start")
b.attach_kretprobe(event="generic_make_request",fn_name="stop")

हमें भी तय करना होगा संरचना डेटा_t हमारी स्क्रिप्ट में, अन्यथा हम कुछ भी नहीं पढ़ पाएंगे:

TASK_COMM_LEN = 16	# linux/sched.h
DISK_NAME_LEN = 32	# linux/genhd.h
class Data(ct.Structure):
	_fields_ = [("pid", ct.c_ulonglong),
            	("ts", ct.c_ulonglong),
            	("comm", ct.c_char * TASK_COMM_LEN),
            	("lat", ct.c_ulonglong),
            	("disk",ct.c_char * DISK_NAME_LEN)]

अंतिम चरण टर्मिनल पर डेटा आउटपुट करना है:

def print_event(cpu, data, size):
    global start
    event = ct.cast(data, ct.POINTER(Data)).contents
    if start == 0:
        start = event.ts
    time_s = (float(event.ts - start)) / 1000000000
    print("%-18.9f %-16s %-6d   %-1s %s   %s" % (time_s, event.comm, event.pid, event.lat, label, event.disk))

b["events"].open_perf_buffer(print_event)
# format output
start = 0
while 1:
    try:
        b.perf_buffer_poll()
    except KeyboardInterrupt:
        exit()

स्क्रिप्ट स्वयं यहां उपलब्ध है GitHub. आइए इसे एक परीक्षण प्लेटफ़ॉर्म पर चलाने का प्रयास करें जहां fio चल रहा है, bcache पर लिख रहा है, और udevadm मॉनिटर को कॉल करें:

अंत में! अब हम देखते हैं कि जो रुका हुआ bcache डिवाइस जैसा दिखता था वह वास्तव में एक रुकी हुई कॉल है जेनेरिक_मेक_अनुरोध() कैश्ड डिस्क के लिए.

कर्नेल में खोदो

अनुरोध ट्रांसमिशन के दौरान वास्तव में क्या धीमा हो रहा है? हम देखते हैं कि देरी अनुरोध लेखांकन की शुरुआत से पहले भी होती है, यानी। उस पर आंकड़ों के आगे के आउटपुट (/proc/diskstats या iostat) के लिए एक विशिष्ट अनुरोध का लेखांकन अभी तक शुरू नहीं हुआ है। समस्या को पुन: उत्पन्न करते समय iostat चलाकर इसे आसानी से सत्यापित किया जा सकता है, या बीसीसी स्क्रिप्ट बायोलेटेंसी, जो अनुरोध लेखांकन के प्रारंभ और अंत पर आधारित है। इनमें से कोई भी उपयोगिता कैश्ड डिस्क के अनुरोधों के लिए समस्याएँ नहीं दिखाएगी।

यदि हम फ़ंक्शन को देखें जेनेरिक_मेक_अनुरोध(), तो हम देखेंगे कि अनुरोध लेखांकन शुरू होने से पहले, दो और फ़ंक्शन कॉल किए जाते हैं। पहला - जेनेरिक_मेक_अनुरोध_चेक(), डिस्क सेटिंग्स के संबंध में अनुरोध की वैधता पर जाँच करता है। दूसरा - blk_queue_enter(), जिसमें एक दिलचस्प चुनौती है प्रतीक्षा_इवेंट_इंटरप्टिबल():

ret = wait_event_interruptible(q->mq_freeze_wq,
	(atomic_read(&q->mq_freeze_depth) == 0 &&
	(preempt || !blk_queue_preempt_only(q))) ||
	blk_queue_dying(q));

इसमें कर्नेल कतार के अनफ्रीज होने का इंतजार करता है। आइए देरी को मापें blk_queue_enter():

~# /usr/share/bcc/tools/funclatency  blk_queue_enter -i 1 -m               	 
Tracing 1 functions for "blk_queue_enter"... Hit Ctrl-C to end.

 	msecs           	: count 	distribution
     	0 -> 1      	: 341  	|****************************************|

 	msecs           	: count 	distribution
     	0 -> 1      	: 316  	|****************************************|

 	msecs           	: count 	distribution
     	0 -> 1      	: 255  	|****************************************|
     	2 -> 3      	: 0    	|                                    	|
     	4 -> 7      	: 0    	|                                    	|
     	8 -> 15     	: 1    	|                                    	|

ऐसा लगता है कि हम समाधान के करीब हैं। किसी कतार को फ़्रीज़/अनफ़्रीज़ करने के लिए उपयोग किए जाने वाले फ़ंक्शन हैं blk_mq_freeze_queue и blk_mq_unfreeze_queue. इनका उपयोग तब किया जाता है जब अनुरोध कतार सेटिंग्स को बदलना आवश्यक होता है, जो इस कतार में अनुरोधों के लिए संभावित रूप से खतरनाक होते हैं। कॉल करते समय blk_mq_freeze_queue() функцией blk_freeze_queue_start() काउंटर बढ़ा दिया गया है q->mq_freeze_depth. इसके बाद, कर्नेल कतार के खाली होने की प्रतीक्षा करता है blk_mq_freeze_queue_wait().

इस कतार को साफ़ करने में लगने वाला समय डिस्क विलंबता के बराबर है क्योंकि कर्नेल सभी कतारबद्ध परिचालनों के पूरा होने की प्रतीक्षा करता है। एक बार कतार खाली हो जाने पर, सेटिंग्स परिवर्तन लागू हो जाते हैं। जिसके बाद इसे बुलाया जाता है blk_mq_unfreeze_queue(), काउंटर को घटाना फ़्रीज़_गहराई.

अब हम स्थिति को सुधारने के लिए पर्याप्त जानते हैं। Udevadm ट्रिगर कमांड ब्लॉक डिवाइस के लिए सेटिंग्स लागू करने का कारण बनता है। ये सेटिंग्स udev नियमों में वर्णित हैं। हम यह पता लगा सकते हैं कि कौन सी सेटिंग्स कतार को sysfs के माध्यम से बदलने का प्रयास करके या कर्नेल स्रोत कोड को देखकर फ्रीज कर रही हैं। हम बीसीसी उपयोगिता भी आज़मा सकते हैं निशान, जो टर्मिनल पर प्रत्येक कॉल के लिए कर्नेल और यूजरस्पेस स्टैक ट्रेस को आउटपुट करेगा blk_freeze_queue, उदाहरण के लिए:

~# /usr/share/bcc/tools/trace blk_freeze_queue -K -U
PID 	TID 	COMM        	FUNC        	 
3809642 3809642 systemd-udevd   blk_freeze_queue
    	blk_freeze_queue+0x1 [kernel]
    	elevator_switch+0x29 [kernel]
    	elv_iosched_store+0x197 [kernel]
    	queue_attr_store+0x5c [kernel]
    	sysfs_kf_write+0x3c [kernel]
    	kernfs_fop_write+0x125 [kernel]
    	__vfs_write+0x1b [kernel]
    	vfs_write+0xb8 [kernel]
    	sys_write+0x55 [kernel]
    	do_syscall_64+0x73 [kernel]
    	entry_SYSCALL_64_after_hwframe+0x3d [kernel]
    	__write_nocancel+0x7 [libc-2.23.so]
    	[unknown]

3809631 3809631 systemd-udevd   blk_freeze_queue
    	blk_freeze_queue+0x1 [kernel]
    	queue_requests_store+0xb6 [kernel]
    	queue_attr_store+0x5c [kernel]
    	sysfs_kf_write+0x3c [kernel]
    	kernfs_fop_write+0x125 [kernel]
    	__vfs_write+0x1b [kernel]
    	vfs_write+0xb8 [kernel]
    	sys_write+0x55 [kernel]
    	do_syscall_64+0x73 [kernel]
    	entry_SYSCALL_64_after_hwframe+0x3d [kernel]
    	__write_nocancel+0x7 [libc-2.23.so]
    	[unknown]

उदेव नियम बहुत कम बदलते हैं और आमतौर पर यह नियंत्रित तरीके से होता है। तो हम देखते हैं कि पहले से निर्धारित मानों को लागू करने से भी एप्लिकेशन से डिस्क पर अनुरोध स्थानांतरित करने में देरी होती है। बेशक, जब डिस्क कॉन्फ़िगरेशन में कोई बदलाव नहीं होता है (उदाहरण के लिए, डिवाइस माउंट/डिस्कनेक्ट नहीं होता है) तो udev ईवेंट उत्पन्न करना एक अच्छा अभ्यास नहीं है। हालाँकि, हम कर्नेल को अनावश्यक कार्य न करने में मदद कर सकते हैं और यदि आवश्यक न हो तो अनुरोध कतार को फ्रीज कर सकते हैं। तीन छोटा प्रतिबद्ध स्थिति को ठीक करें.

निष्कर्ष

eBPF एक बहुत ही लचीला और शक्तिशाली उपकरण है। लेख में हमने एक व्यावहारिक मामले को देखा और जो किया जा सकता है उसका एक छोटा सा हिस्सा प्रदर्शित किया। यदि आप बीसीसी उपयोगिताओं को विकसित करने में रुचि रखते हैं, तो यह देखने लायक है आधिकारिक ट्यूटोरियल, जो मूल बातों का अच्छी तरह से वर्णन करता है।

ईबीपीएफ पर आधारित अन्य दिलचस्प डिबगिंग और प्रोफाइलिंग टूल हैं। उन्हीं में से एक है - bpftrace, जो आपको awk जैसी भाषा में शक्तिशाली वन-लाइनर और छोटे प्रोग्राम लिखने की अनुमति देता है। एक और - ebpf_निर्यातक, आपको निम्न-स्तरीय, उच्च-रिज़ॉल्यूशन मेट्रिक्स को सीधे अपने प्रोमेथियस सर्वर में एकत्र करने की अनुमति देता है, बाद में सुंदर विज़ुअलाइज़ेशन और यहां तक ​​कि अलर्ट प्राप्त करने की क्षमता के साथ।

स्रोत: www.habr.com