მაღალი ცეფის შეყოვნებიდან ბირთვის პაჩამდე eBPF/BCC გამოყენებით

Linux-ს აქვს უამრავი ინსტრუმენტი ბირთვისა და აპლიკაციების გამართვისთვის. მათი უმეტესობა უარყოფითად აისახება აპლიკაციის შესრულებაზე და არ შეიძლება გამოყენებულ იქნას წარმოებაში.

რამდენიმე წლის წინ იყო შემუშავებულია კიდევ ერთი ინსტრუმენტი - eBPF. ეს შესაძლებელს ხდის ბირთვისა და მომხმარებლის აპლიკაციების მიკვლევას დაბალი ზედნადებით და პროგრამების აღდგენისა და მესამე მხარის მოდულების ბირთვში ჩატვირთვის გარეშე.

უკვე არსებობს მრავალი აპლიკაციის პროგრამა, რომელიც იყენებს eBPF-ს და ამ სტატიაში განვიხილავთ, თუ როგორ უნდა დაწეროთ თქვენი საკუთარი პროფილირების პროგრამა ბიბლიოთეკის საფუძველზე. PythonBCC. სტატია ეფუძნება რეალურ მოვლენებს. ჩვენ გადავალთ პრობლემის გადასაჭრელად, რათა ვაჩვენოთ, თუ როგორ შეიძლება არსებული კომუნალური საშუალებების გამოყენება კონკრეტულ სიტუაციებში.

Ceph არის ნელი

Ceph კლასტერს დაემატა ახალი მასპინძელი. ზოგიერთი მონაცემის მასზე გადატანის შემდეგ, ჩვენ შევამჩნიეთ, რომ მის მიერ ჩაწერის მოთხოვნების დამუშავების სიჩქარე გაცილებით დაბალი იყო, ვიდრე სხვა სერვერებზე.

სხვა პლატფორმებისგან განსხვავებით, ამ ჰოსტმა გამოიყენა bcache და ახალი Linux 4.15 ბირთვი. ეს იყო პირველი შემთხვევა, როდესაც ამ კონფიგურაციის მასპინძელი გამოიყენებოდა აქ. და იმ მომენტში ცხადი იყო, რომ პრობლემის საფუძველი თეორიულად შეიძლება იყოს ყველაფერი.

მასპინძლის გამოკვლევა

დავიწყოთ იმით, თუ რა ხდება ceph-osd პროცესის შიგნით. ამისთვის გამოვიყენებთ perf и ფლესკოპი (დაწვრილებით, რომლის შესახებაც შეგიძლიათ წაიკითხოთ აქ):

სურათი გვეუბნება, რომ ფუნქცია fdatasync () დიდი დრო დახარჯა ფუნქციების მოთხოვნის გაგზავნაში generic_make_request(). ეს ნიშნავს, რომ, სავარაუდოდ, პრობლემების მიზეზი არის osd დემონის მიღმა. ეს შეიძლება იყოს ბირთვი ან დისკი. iostat გამომავალმა აჩვენა მაღალი შეყოვნება bcache დისკების მიერ მოთხოვნების დამუშავებისას.

ჰოსტის შემოწმებისას აღმოვაჩინეთ, რომ systemd-udevd დემონი მოიხმარს დიდი რაოდენობით CPU დროს - დაახლოებით 20% რამდენიმე ბირთვზე. ეს უცნაური საქციელია, ამიტომ უნდა გაარკვიოთ რატომ. იმის გამო, რომ Systemd-udevd მუშაობს uevents-თან, გადავწყვიტეთ გადავხედოთ მათ udevadm მონიტორი. გამოდის, რომ სისტემაში თითოეული ბლოკის მოწყობილობისთვის გენერირდება ცვლილების მოვლენების დიდი რაოდენობა. ეს საკმაოდ უჩვეულოა, ამიტომ ჩვენ მოგვიწევს შევხედოთ რა იწვევს ყველა ამ მოვლენას.

BCC ინსტრუმენტარიუმის გამოყენებით

როგორც უკვე გავარკვიეთ, ბირთვი (და ცეფის დემონი სისტემის ზარში) დიდ დროს ატარებს generic_make_request(). შევეცადოთ გავზომოთ ამ ფუნქციის სიჩქარე. IN BCC უკვე არის მშვენიერი უტილიტა - funclatency. ჩვენ მივყვებით დემონს მისი PID-ით 1 წამის ინტერვალით გამოსავალს შორის და გამოვატანთ შედეგს მილიწამებში.

ეს ფუნქცია ჩვეულებრივ სწრაფად მუშაობს. ყველაფერი რაც აკეთებს არის მოთხოვნის გადაცემა მოწყობილობის დრაივერის რიგში.

Bcache არის რთული მოწყობილობა, რომელიც რეალურად შედგება სამი დისკისაგან:

• დამხმარე მოწყობილობა (ქეშირებული დისკი), ამ შემთხვევაში ეს არის ნელი HDD;
• ქეშირების მოწყობილობა (ქეშირების დისკი), აქ ეს არის NVMe მოწყობილობის ერთი დანაყოფი;
• bcache ვირტუალური მოწყობილობა, რომლითაც აპლიკაცია მუშაობს.

ჩვენ ვიცით, რომ მოთხოვნის გადაცემა ნელია, მაგრამ რომელი მოწყობილობისთვის? ამას ცოტა მოგვიანებით შევეხებით.

ჩვენ ახლა ვიცით, რომ მოვლენებმა შეიძლება გამოიწვიოს პრობლემები. იმის დადგენა, თუ რა იწვევს მათ თაობას, არც ისე ადვილია. დავუშვათ, რომ ეს არის გარკვეული სახის პროგრამული უზრუნველყოფა, რომელიც გაშვებულია პერიოდულად. ვნახოთ, რა სახის პროგრამული უზრუნველყოფა მუშაობს სისტემაში სკრიპტის გამოყენებით 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-ს გაშვებით, პერიოდულად გაშვებით udevadm ტრიგერით uevents გენერირებისთვის.

BCC-ზე დაფუძნებული ინსტრუმენტების წერა

შევეცადოთ დავწეროთ მარტივი პროგრამა ყველაზე ნელი ზარების თვალსაჩინოებისა და ჩვენებისთვის generic_make_request(). ჩვენ ასევე გვაინტერესებს დისკის სახელი, რომლისთვისაც გამოიძახეს ეს ფუნქცია.

გეგმა მარტივია:

• რეგისტრაცია kprobe on generic_make_request():
  • ჩვენ ვინახავთ დისკის სახელს მეხსიერებაში, რომელიც ხელმისაწვდომია ფუნქციის არგუმენტის საშუალებით;
  • ჩვენ ვინახავთ დროის ნიშანს.

• რეგისტრაცია კრეტპრობი დაბრუნებისთვის generic_make_request():
  • ჩვენ ვიღებთ მიმდინარე დროის ნიშანს;
  • ჩვენ ვეძებთ შენახულ დროის ნიშანს და ვადარებთ მას მიმდინარე ნიშანს;
  • თუ შედეგი აღემატება მითითებულს, მაშინ ვპოულობთ შენახულ დისკის სახელს და ვაჩვენებთ მას ტერმინალზე.

Kprobes и კრეტპრობები გამოიყენეთ breakpoint მექანიზმი ფუნქციის კოდის შესაცვლელად ფრენის დროს. Შეგიძლია წაიკითხო დოკუმენტაცია и კარგი სტატია ამ თემაზე. თუ გადახედავთ სხვადასხვა კომუნალური პროგრამის კოდს BCC, მაშინ ხედავთ, რომ მათ აქვთ იდენტური სტრუქტურა. ასე რომ, ამ სტატიაში ჩვენ გამოვტოვებთ სკრიპტის არგუმენტების ანალიზს და გადავალთ თავად 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 და ტიპის მნიშვნელობა struct data_t. ცხრილი ხელმისაწვდომი იქნება ჩვენი 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-ს და დროის ნიშანს, მაგრამ არ გამოვყოფთ მეხსიერებას მონაცემთა ახალი სტრუქტურისთვის. ამის ნაცვლად, ჩვენ ვეძებთ ჰეშის ცხრილში უკვე არსებულ სტრუქტურას == მიმდინარე 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 პროგრამა მეშვეობით 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")

ჩვენც მოგვიწევს განვსაზღვროთ struct data_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 მოწყობილობას ჰგავდა, სინამდვილეში შეჩერებული ზარია generic_make_request() ქეშირებული დისკისთვის.

იჭრება ბირთვში

კონკრეტულად რა არის შენელებული მოთხოვნის გადაცემის დროს? ჩვენ ვხედავთ, რომ დაგვიანება ხდება მოთხოვნის აღრიცხვის დაწყებამდეც, ე.ი. კონკრეტული მოთხოვნის აღრიცხვა მასზე სტატისტიკის (/proc/diskstats ან iostat) შემდგომი გამოტანის შესახებ ჯერ არ დაწყებულა. ამის მარტივად შემოწმება შესაძლებელია iostat-ის გაშვებით პრობლემის რეპროდუცირებისას, ან BCC სკრიპტის ბიოლატენტობა, რომელიც ეფუძნება მოთხოვნის აღრიცხვის დაწყებას და დასასრულს. არცერთი ამ კომუნალური პროგრამა არ აჩვენებს პრობლემებს ქეშირებულ დისკზე მოთხოვნებთან დაკავშირებით.

ფუნქციას თუ გადავხედავთ generic_make_request(), შემდეგ ვნახავთ, რომ სანამ მოთხოვნა დაიწყებს აღრიცხვას, გამოიძახება კიდევ ორი ​​ფუნქცია. Პირველი - generic_make_request_checks(), ამოწმებს მოთხოვნის ლეგიტიმურობას დისკის პარამეტრებთან დაკავშირებით. მეორე - blk_queue_enter(), რომელსაც აქვს საინტერესო გამოწვევა Wait_event_interruptible():

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_ყინვა_სიღრმე. ამის შემდეგ, ბირთვი ელოდება რიგის დაცლას blk_mq_freeze_queue_wait().

ამ რიგის გასასუფთავებლად საჭირო დრო უდრის დისკის შეყოვნებას, რადგან ბირთვი ელოდება რიგში მდგომი ყველა ოპერაციის დასრულებას. როდესაც რიგი ცარიელია, პარამეტრების ცვლილებები გამოიყენება. რის შემდეგაც ე.წ blk_mq_unfreeze_queue(), მრიცხველის შემცირება გაყინვა_სიღრმე.

ახლა ჩვენ საკმარისად ვიცით სიტუაციის გამოსასწორებლად. 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 მოვლენების გენერირება, როდესაც დისკის კონფიგურაციაში ცვლილებები არ არის (მაგალითად, მოწყობილობა არ არის დამონტაჟებული/გამორთული) არ არის კარგი პრაქტიკა. თუმცა, ჩვენ შეგვიძლია დავეხმაროთ ბირთვს არ გააკეთოს ზედმეტი სამუშაო და გაყინოს მოთხოვნის რიგი, თუ ეს არ არის საჭირო. სამი პატარა ჩაიდინოს სიტუაციის გამოსწორება.

დასკვნა

eBPF არის ძალიან მოქნილი და ძლიერი ინსტრუმენტი. სტატიაში ჩვენ გადავხედეთ ერთ პრაქტიკულ შემთხვევას და ვაჩვენეთ მცირე ნაწილი იმისა, რისი გაკეთებაც შეიძლება. თუ თქვენ დაინტერესებული ხართ BCC კომუნალური პროგრამების შემუშავებით, ღირს გადახედოთ ოფიციალური გაკვეთილი, რომელიც კარგად აღწერს საფუძვლებს.

არსებობს სხვა საინტერესო გამართვისა და პროფილირების ინსტრუმენტები, რომლებიც დაფუძნებულია eBPF-ზე. Ერთ - ერთი მათგანი - bpftrace, რომელიც საშუალებას გაძლევთ დაწეროთ ძლიერი ერთი ლაინერი და პატარა პროგრამები awk-ის მსგავს ენაზე. სხვა - ebpf_exporter, საშუალებას გაძლევთ შეაგროვოთ დაბალი დონის, მაღალი გარჩევადობის მეტრიკა პირდაპირ თქვენს პრომეთეს სერვერზე, შემდგომში ლამაზი ვიზუალიზაციისა და გაფრთხილებების მიღების შესაძლებლობით.

წყარო: www.habr.com