eBPF/BCC वापरून उच्च Ceph लेटन्सी पासून कर्नल पॅच पर्यंत

लिनक्समध्ये कर्नल आणि ऍप्लिकेशन्स डीबग करण्यासाठी मोठ्या प्रमाणात साधने आहेत. त्यापैकी बहुतेकांचा अनुप्रयोगाच्या कार्यक्षमतेवर नकारात्मक प्रभाव पडतो आणि उत्पादनात वापरला जाऊ शकत नाही.

एक दोन वर्षांपूर्वी होते दुसरे साधन विकसित केले आहे - eBPF. हे कमी ओव्हरहेडसह कर्नल आणि वापरकर्ता अनुप्रयोग शोधणे शक्य करते आणि प्रोग्राम्सची पुनर्बांधणी आणि कर्नलमध्ये तृतीय-पक्ष मॉड्यूल लोड करण्याची आवश्यकता न ठेवता.

ईबीपीएफ वापरणार्‍या अनेक ऍप्लिकेशन युटिलिटीज आधीच आहेत आणि या लेखात आम्ही लायब्ररीवर आधारित तुमची स्वतःची प्रोफाइलिंग युटिलिटी कशी लिहायची ते पाहू. PythonBCC. लेख वास्तविक घटनांवर आधारित आहे. विशिष्ट परिस्थितींमध्ये विद्यमान उपयुक्तता कशा वापरल्या जाऊ शकतात हे दाखवण्यासाठी आम्ही समस्येपासून निराकरणाकडे जाऊ.

सेफ मंद आहे

Ceph क्लस्टरमध्ये एक नवीन होस्ट जोडला गेला आहे. त्यात काही डेटा स्थलांतरित केल्यानंतर, आमच्या लक्षात आले की त्याद्वारे लेखन विनंत्यांवर प्रक्रिया करण्याचा वेग इतर सर्व्हरच्या तुलनेत खूपच कमी होता.

इतर प्लॅटफॉर्मच्या विपरीत, या होस्टने bcache आणि नवीन linux 4.15 कर्नल वापरले. या कॉन्फिगरेशनचा यजमान येथे वापरण्याची ही पहिलीच वेळ होती. आणि त्या क्षणी हे स्पष्ट झाले की समस्येचे मूळ सैद्धांतिकदृष्ट्या काहीही असू शकते.

होस्टची चौकशी करत आहे

सेफ-ओएसडी प्रक्रियेमध्ये काय होते ते बघून सुरुवात करूया. यासाठी आपण वापरणार आहोत परफ и फ्लेमस्कोप (ज्याबद्दल आपण अधिक वाचू शकता येथे):

चित्र सांगते की कार्य fdatasync() फंक्शन्सना विनंती पाठवण्यात बराच वेळ घालवला generic_make_request(). याचा अर्थ बहुधा समस्यांचे कारण osd डिमनच्या बाहेर कुठेतरी आहे. हे एकतर कर्नल किंवा डिस्क असू शकते. iostat आउटपुटने bcache डिस्क्सद्वारे विनंत्या प्रक्रिया करण्यात उच्च विलंब दर्शविला.

होस्ट तपासताना, आम्हाला आढळले की systemd-udevd डिमन मोठ्या प्रमाणात CPU वेळ वापरतो - अनेक कोरवर सुमारे 20%. हे विचित्र वर्तन आहे, म्हणून तुम्हाला याचे कारण शोधणे आवश्यक आहे. Systemd-udevd uevents सह कार्य करत असल्याने, आम्ही त्याद्वारे पाहण्याचा निर्णय घेतला udevadm मॉनिटर. हे दिसून आले की सिस्टममधील प्रत्येक ब्लॉक डिव्हाइससाठी मोठ्या संख्येने बदल इव्हेंट व्युत्पन्न केले गेले. हे अगदीच असामान्य आहे, त्यामुळे या सर्व घटना कशामुळे निर्माण होतात हे आपल्याला पहावे लागेल.

BCC टूलकिट वापरणे

जसे की आपण आधीच शोधले आहे, कर्नल (आणि सिस्टम कॉलमधील सेफ डिमन) खूप वेळ घालवतो. generic_make_request(). चला या फंक्शनची गती मोजण्याचा प्रयत्न करूया. IN बीसीसी आधीच एक अद्भुत उपयुक्तता आहे - कार्यक्षमता. आउटपुटमधील 1 सेकंदाच्या अंतराने आम्ही डिमॉनला त्याच्या PID द्वारे ट्रेस करू आणि परिणाम मिलीसेकंदमध्ये आउटपुट करू.

हे वैशिष्ट्य सहसा द्रुतपणे कार्य करते. ते फक्त डिव्हाइस ड्रायव्हर रांगेत विनंती पाठवते.

Bcache एक जटिल उपकरण आहे ज्यामध्ये तीन डिस्क असतात:

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

आम्हाला माहित आहे की विनंतीचे प्रसारण धीमे आहे, परंतु यापैकी कोणत्या डिव्हाइससाठी? आम्ही थोड्या वेळाने याचा सामना करू.

आम्हाला आता माहित आहे की uevents मुळे समस्या निर्माण होण्याची शक्यता आहे. त्यांच्या पिढीचे नेमके कारण काय आहे हे शोधणे इतके सोपे नाही. चला असे गृहीत धरू की हे काही प्रकारचे सॉफ्टवेअर आहे जे वेळोवेळी लॉन्च केले जाते. स्क्रिप्ट वापरून सिस्टमवर कोणत्या प्रकारचे सॉफ्टवेअर चालते ते पाहू execsnoop त्याच पासून BCC युटिलिटी किट. चला ते चालवू आणि आउटपुट फाईलमध्ये पाठवू.

उदाहरणार्थ यासारखे:

/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/'

तिसरा स्तंभ प्रक्रियेचा PPID (पालक PID) आहे. PID 5802 सह प्रक्रिया आमच्या मॉनिटरिंग सिस्टमच्या थ्रेड्सपैकी एक असल्याचे दिसून आले. मॉनिटरिंग सिस्टमचे कॉन्फिगरेशन तपासताना, चुकीचे पॅरामीटर्स आढळले. HBA अॅडॉप्टरचे तापमान दर 30 सेकंदांनी घेतले जाते, जे आवश्यकतेपेक्षा बरेचदा जास्त असते. चेक इंटरव्हल ला बदलल्यानंतर, आम्हाला आढळले की या होस्टवरील विनंती प्रक्रियेची लेटन्सी इतर होस्टच्या तुलनेत वेगळी नाही.

परंतु bcache डिव्हाइस इतके धीमे का होते हे अद्याप अस्पष्ट आहे. आम्ही समान कॉन्फिगरेशनसह एक चाचणी प्लॅटफॉर्म तयार केला आणि bcache वर fio चालवून, uevents व्युत्पन्न करण्यासाठी नियमितपणे udevadm ट्रिगर चालवून समस्या पुनरुत्पादित करण्याचा प्रयत्न केला.

BCC-आधारित साधने लेखन

सर्वात हळू कॉल ट्रेस आणि प्रदर्शित करण्यासाठी एक साधी उपयुक्तता लिहिण्याचा प्रयत्न करूया generic_make_request(). आम्हाला ज्या ड्राइव्हसाठी हे फंक्शन कॉल केले गेले होते त्या नावामध्ये देखील स्वारस्य आहे.

योजना सोपी आहे:

• नोंदणी करा kprobe वर generic_make_request():
  • आम्ही डिस्कचे नाव मेमरीमध्ये सेव्ह करतो, फंक्शन आर्ग्युमेंटद्वारे प्रवेश करता येतो;
  • आम्ही टाइमस्टॅम्प जतन करतो.

• नोंदणी करा kretprobe पासून परत येण्यासाठी generic_make_request():
  • आम्हाला वर्तमान टाइमस्टॅम्प मिळतो;
  • आम्ही जतन केलेला टाइमस्टॅम्प शोधतो आणि त्याची सध्याच्या टाईमस्टॅम्पशी तुलना करतो;
  • जर परिणाम निर्दिष्ट केलेल्यापेक्षा जास्त असेल तर आम्हाला सेव्ह केलेले डिस्क नाव सापडेल आणि ते टर्मिनलवर प्रदर्शित होईल.

Kprobes и kretprobes फ्लायवर फंक्शन कोड बदलण्यासाठी ब्रेकपॉईंट यंत्रणा वापरा. तुम्ही वाचू शकता दस्तऐवजीकरण и चांगले या विषयावरील लेख. मधील विविध युटिलिटीजचा कोड पाहिल्यास बीसीसी, नंतर आपण पाहू शकता की त्यांची एक समान रचना आहे. म्हणून या लेखात आपण स्क्रिप्ट वितर्क पार्स करणे वगळू आणि BPF प्रोग्राममध्येच पुढे जाऊ.

पायथन स्क्रिप्टमधील eBPF मजकूर यासारखा दिसतो:

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

फंक्शन्समधील डेटाची देवाणघेवाण करण्यासाठी, eBPF प्रोग्राम वापरतात हॅश टेबल. आम्ही तेच करू. आम्ही PID ही प्रक्रिया की म्हणून वापरू आणि संरचनेला मूल्य म्हणून परिभाषित करू:

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 आणि प्रकाराचे मूल्य संरचना डेटा_टी. आमच्या BPF कार्यक्रमाच्या संदर्भात टेबल उपलब्ध असेल. 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);
}

येथे कॉल केलेल्या फंक्शनचा पहिला वितर्क दुसरा वितर्क म्हणून बदलला जाईल generic_make_request(). यानंतर, आम्ही ज्या संदर्भात काम करत आहोत त्या प्रक्रियेचा PID आणि सध्याचा टाइमस्टॅम्प नॅनोसेकंदमध्ये मिळतो. आम्ही हे सर्व नव्याने निवडलेल्या मध्ये लिहितो struct data_t डेटा. आम्हाला संरचनेवरून डिस्कचे नाव मिळते जैव, जे कॉल करताना पास केले जाते generic_make_request(), आणि त्याच संरचनेत जतन करा डेटा. शेवटची पायरी म्हणजे आधी उल्लेख केलेल्या हॅश टेबलमध्ये एंट्री जोडणे.

पासून परतल्यावर खालील फंक्शन कॉल केले जाईल generic_make_request():

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);
    }
}

हे फंक्शन मागील सारखेच आहे: आम्ही प्रक्रियेचा PID आणि टाइमस्टॅम्प शोधतो, परंतु नवीन डेटा स्ट्रक्चरसाठी मेमरी वाटप करत नाही. त्याऐवजी, की == चालू पीआयडी वापरून आधीपासून अस्तित्वात असलेल्या स्ट्रक्चरसाठी हॅश टेबल शोधतो. जर रचना सापडली, तर आपण चालू प्रक्रियेचे नाव शोधून त्यास जोडतो.

आम्ही येथे वापरत असलेली बायनरी शिफ्ट थ्रेड GID मिळविण्यासाठी आवश्यक आहे. त्या आम्ही ज्या संदर्भात काम करत आहोत त्या संदर्भात धागा सुरू करणाऱ्या मुख्य प्रक्रियेचा 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")

आम्हालाही ठरवावे लागेल संरचना डेटा_टी आमच्या स्क्रिप्टमध्ये, अन्यथा आम्ही काहीही वाचू शकणार नाही:

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 डिव्हाइससारखे दिसत होते ते प्रत्यक्षात एक स्टॉलिंग कॉल आहे generic_make_request() कॅश्ड डिस्कसाठी.

कर्नल मध्ये खणणे

रिक्वेस्ट ट्रान्समिशन दरम्यान नक्की काय मंद होत आहे? आम्ही पाहतो की विनंती लेखांकन सुरू होण्यापूर्वीच विलंब होतो, म्हणजे. त्यावर (/proc/diskstats किंवा iostat) आकडेवारीच्या पुढील आउटपुटसाठी विशिष्ट विनंतीचे लेखांकन अद्याप सुरू झालेले नाही. समस्येचे पुनरुत्पादन करताना iostat चालवून हे सहजपणे सत्यापित केले जाऊ शकते, किंवा BCC स्क्रिप्ट बायोलेटेंसी, जे विनंती अकाउंटिंगच्या प्रारंभ आणि समाप्तीवर आधारित आहे. यापैकी कोणतीही युटिलिटी कॅश्ड डिस्कच्या विनंत्यांना समस्या दर्शवणार नाही.

फंक्शन बघितले तर generic_make_request(), नंतर आपण पाहू की विनंतीचे अकाउंटिंग सुरू होण्यापूर्वी, आणखी दोन फंक्शन्स कॉल केली जातात. पहिला - generic_make_request_checks(), डिस्क सेटिंग्जशी संबंधित विनंतीची वैधता तपासते. दुसरा - 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(), काउंटर कमी करणे freeze_depth.

आता आम्हाला परिस्थिती सुधारण्यासाठी पुरेसे माहित आहे. udevadm ट्रिगर कमांड ब्लॉक उपकरणासाठी सेटिंग्ज लागू करण्यास कारणीभूत ठरते. या सेटिंग्ज udev नियमांमध्ये वर्णन केल्या आहेत. sysfs द्वारे किंवा कर्नल सोर्स कोड पाहून कोणती सेटिंग्ज रांग गोठवत आहेत ते आपण शोधू शकतो. आम्ही BCC उपयुक्तता देखील वापरून पाहू शकतो ट्रेस, जे टर्मिनलवर प्रत्येक कॉलसाठी कर्नल आणि यूजरस्पेस स्टॅक ट्रेस आउटपुट करेल 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 नियम फार क्वचितच बदलतात आणि सहसा हे नियंत्रित पद्धतीने घडते. म्हणून आम्ही पाहतो की आधीच सेट केलेली मूल्ये लागू केल्याने देखील अनुप्रयोगातून डिस्कवर विनंती हस्तांतरित करण्यात विलंब होतो. अर्थात, डिस्क कॉन्फिगरेशनमध्ये कोणतेही बदल नसताना (उदाहरणार्थ, डिव्हाइस माउंट केलेले/डिस्कनेक्ट केलेले नाही) udev इव्हेंट तयार करणे ही चांगली सराव नाही. तथापि, आम्ही कर्नलला अनावश्यक काम न करण्यास मदत करू शकतो आणि आवश्यक नसल्यास विनंती रांग गोठवू शकतो. तीन लहान वचनबद्ध परिस्थिती दुरुस्त करा.

निष्कर्ष

eBPF हे अतिशय लवचिक आणि शक्तिशाली साधन आहे. लेखात आम्ही एक व्यावहारिक केस पाहिला आणि काय केले जाऊ शकते याचा एक छोटासा भाग प्रदर्शित केला. तुम्हाला BCC युटिलिटीज विकसित करण्यात स्वारस्य असल्यास, ते पाहण्यासारखे आहे अधिकृत ट्यूटोरियल, जे मूलभूत गोष्टींचे चांगले वर्णन करते.

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

स्त्रोत: www.habr.com