იური ბუშმელევი "რაკის რუკა მორების შეგროვებისა და მიწოდების სფეროში" - მოხსენების ტრანსკრიპტი

ჟურნალები სისტემის მნიშვნელოვანი ნაწილია, რაც საშუალებას გაძლევთ გაიგოთ, რომ ის მუშაობს (ან არ მუშაობს) ისე, როგორც მოსალოდნელია. მიკროსერვისის არქიტექტურის პირობებში ლოგინებთან მუშაობა ხდება სპეციალური ოლიმპიადის ცალკე დისციპლინა. ბევრი საკითხია, რომელიც უნდა გადაიჭრას:

• როგორ დავწეროთ ჟურნალები აპლიკაციიდან;
• სად დავწეროთ ჟურნალები;
• როგორ მივაწოდოთ ჟურნალები შესანახად და დასამუშავებლად;
• როგორ დავამუშავოთ და შეინახოთ ჟურნალები.

ამჟამად პოპულარული კონტეინერიზაციის ტექნოლოგიების გამოყენება ქვიშას ამატებს ქვიშას პრობლემის გადაჭრის ვარიანტების სფეროში.

ზუსტად ეს არის იური ბუშმელევის მოხსენების ტრანსკრიპტი "რაკის რუკა მორების შეგროვებისა და მიწოდების სფეროში".

ვისაც აინტერესებს, გთხოვთ, კატის ქვეშ.

მე მქვია იური ბუშმელევი. ვმუშაობ ლაზადაში. დღეს მე ვისაუბრებ იმაზე, თუ როგორ გავაკეთეთ ჩვენი მორები, როგორ მოვაგროვეთ ისინი და რას ვწერთ იქ.

საიდან ვართ? Ვინ ვართ ჩვენ? Lazada არის #1 ონლაინ საცალო ვაჭრობა სამხრეთ-აღმოსავლეთ აზიის ექვს ქვეყანაში. ყველა ეს ქვეყანა გადანაწილებულია მონაცემთა ცენტრებს შორის. ახლა სულ არის 4 მონაცემთა ცენტრი. რატომ არის ეს მნიშვნელოვანი? იმიტომ, რომ ზოგიერთი გადაწყვეტილება გამოწვეული იყო იმით, რომ ცენტრებს შორის ძალიან სუსტი კავშირია. ჩვენ გვაქვს მიკროსერვისის არქიტექტურა. გამიკვირდა, როცა აღმოვაჩინე, რომ უკვე გვაქვს 80 მიკროსერვისი. როცა დავალება დავიწყე ლოგებით, იყო მხოლოდ 20. გარდა ამისა, არის საკმაოდ დიდი PHP მემკვიდრეობა, რომელსაც ასევე უნდა ვიცხოვრო და შევეგუო. ეს ყველაფერი წარმოქმნის ჩვენთვის ამ მომენტში 6 მილიონზე მეტ შეტყობინებას წუთში მთლიანი სისტემისთვის. შემდგომ მე გაჩვენებთ, თუ როგორ ვცდილობთ ვიცხოვროთ ამით და რატომ არის ასე.

როგორმე უნდა იცხოვრო ამ 6 მილიონი მესიჯით. რა ვუყოთ მათ? საჭიროა 6 მილიონი შეტყობინება:

• გაგზავნა აპიდან
• მიღება მიწოდებისთვის
• მიწოდება ანალიზისთვის და შესანახად.
• ანალიზი
• შეინახეთ როგორმე.

როდესაც სამი მილიონი შეტყობინება იყო, დაახლოებით იგივე სახე მქონდა. იმიტომ, რომ ჩვენ დავიწყეთ რამდენიმე გროშით. გასაგებია, რომ იქ აპლიკაციის ჟურნალები წერია. მაგალითად, ვერ დაუკავშირდა მონაცემთა ბაზას, ვერ დაუკავშირდა მონაცემთა ბაზას, მაგრამ ვერ წაიკითხა რაღაც. მაგრამ ამის გარდა, თითოეული ჩვენი მიკროსერვისი ასევე წერს წვდომის ჟურნალს. თითოეული მოთხოვნა, რომელიც მიდის მიკროსერვისში, შედის ჟურნალში. რატომ ვაკეთებთ ამას? დეველოპერებს სურთ შეძლონ კვალი. თითოეული წვდომის ჟურნალი შეიცავს traceid ველს, რომლის მიხედვითაც სპეციალური ინტერფეისი ხსნის მთელ ჯაჭვს და ლამაზად აჩვენებს კვალს. კვალი აჩვენებს, თუ როგორ წარიმართა მოთხოვნა და ეს ეხმარება ჩვენს დეველოპერებს უფრო სწრაფად გაუმკლავდნენ ნებისმიერ უცნობ ნაგავს.

როგორ ვიცხოვროთ მასთან? ახლა მოკლედ აღვწერ ოფციონთა სფეროს - როგორ გვარდება ეს პრობლემა ზოგადად. როგორ მოვაგვაროთ მორების შეგროვების, გადაცემის და შენახვის პრობლემა.

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

მორების შეგროვებით, დაახლოებით იგივე სიტუაციაა. ამ კონკრეტული ნაწილის გადაჭრის ამდენი ვარიანტი არ არის. ისინი უფრო მეტია, მაგრამ ჯერ არც ისე ბევრი.

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

მე გაჩვენებთ, როგორ გავაკეთეთ ეს ლაზადაში და როგორ დაიწყო ეს ყველაფერი.

ერთი წლის წინ ჩამოვედი ლაზადაში და ლოგის პროექტზე გამგზავნეს. იქ ასე იყო. აპლიკაციის ჟურნალი დაიწერა stdout-ზე და stderr-ზე. ყველაფერი მოდურად გაკეთდა. მაგრამ შემდეგ დეველოპერებმა ის გადააგდეს სტანდარტული ნაკადებიდან და შემდეგ ინფრასტრუქტურის სპეციალისტები ამას როგორმე გაერკვნენ. ინფრასტრუქტურის სპეციალისტებსა და დეველოპერებს შორის ასევე არიან გამომშვებები, რომლებმაც თქვეს: "აჰ... კარგი, მოდით, უბრალოდ ჩავაკრათ ისინი ფაილში ჭურვით და ეს არის ის." და რადგან ეს ყველაფერი კონტეინერშია, მათ შეახვიეს იგი პირდაპირ კონტეინერში, დააფიქსირეს დირექტორია შიგნით და განათავსეს. ვფიქრობ, ყველასთვის გასაგებია რაც მოხდა.

ცოტა უფრო შორს გავიხედოთ. როგორ მივაწოდეთ ეს მორები. ვიღაცამ აირჩია td-agent, რომელიც რეალურად სრულყოფილად არის, მაგრამ არც ისე თავისუფლად. მე ჯერ კიდევ არ მესმის ამ ორი პროექტის ურთიერთობა, მაგრამ როგორც ჩანს, ისინი დაახლოებით იგივეა. და ეს თავისუფლად, რუბიში დაწერილი, წაიკითხა ჟურნალის ფაილები, გააანალიზა ისინი JSON-ში რამდენიმე რეგულარული გამონათქვამის გამოყენებით. შემდეგ ისინი გაგზავნეს კაფკასთან. უფრო მეტიც, კაფკაში გვქონდა 4 ცალკე თემა თითოეული API-სთვის. რატომ 4? იმის გამო, რომ არსებობს ცოცხალი, არის დადგმა, და რადგან არის stdout და stderr. დეველოპერები აწარმოებენ მათ და ინფრასტრუქტურის მუშაკებმა უნდა შექმნან ისინი კაფკაში. მეტიც, კაფკას სხვა დეპარტამენტი აკონტროლებდა. ამიტომ საჭირო იყო ბილეთის შექმნა ისე, რომ იქ თითოეული აპისთვის 4 თემა შეექმნათ. ყველას დაავიწყდა ეს. ზოგადად, ეს იყო ნაგავი და ნარჩენები.

რა გავაკეთეთ ამის შემდეგ? კაფკას გავუგზავნეთ. კაფკადან მოშორებით, მორების ნახევარი გაფრინდა ლოგსტაშში. მორების მეორე ნახევარი გაიზიარა. ზოგი ერთ გრეილოგში გაფრინდა, ზოგი მეორე გრეილოგში. შედეგად, ეს ყველაფერი გაფრინდა ერთ Elasticsearch კლასტერში. ანუ მთელი ეს არეულობა ბოლოს იქ დაეცა. თქვენ არ გჭირდებათ ამის გაკეთება!

ასე გამოიყურება ზემოდან დანახვისას. თქვენ არ გჭირდებათ ამის გაკეთება! აქ პრობლემური ადგილები მაშინვე აღინიშნება ნომრებით. ისინი რეალურად უფრო მეტია, მაგრამ 6 ნამდვილად პრობლემურია, რომლებთანაც რაღაც უნდა გაკეთდეს. მათ შესახებ ახლა ცალკე მოგიყვებით.

აქ (1,2,3) ჩვენ ვწერთ ფაილებს და, შესაბამისად, აქ ერთდროულად სამი რეკია.

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

მეორე წერტილი (2,3) არის ის, რომ ჩვენ გვაქვს ბევრი მოთხოვნა, რომელიც მოდის API-ზე. API წერს უამრავ მონაცემს ფაილში. ფაილები იზრდება. ჩვენ უნდა მოვატრიალოთ ისინი. რადგან სხვაგვარად იქ ვერცერთი დისკის შენახვას ვერ შეძლებთ. მათი როტაცია ცუდია, რადგან ისინი გადამისამართებულია გარსის მეშვეობით დირექტორიაში. ჩვენ არ შეგვიძლია მისი როტაცია. თქვენ არ შეგიძლიათ აპლიკაციას უთხრათ ხელახლა გახსნას სახელურები. რადგან დეველოპერები სულელივით გიყურებენ: „რა აღწერები? ჩვენ ჩვეულებრივ ვწერთ stdout-ს. Framework-მა გადააკეთა copytruncate-ად logrotate, რომელიც უბრალოდ აკეთებს ფაილის ასლს და აფორმებს ორიგინალს. შესაბამისად, ამ კოპირების პროცესებს შორის, დისკზე ადგილი ჩვეულებრივ ამოიწურება.

(4) ჩვენ გვქონდა სხვადასხვა ფორმატები სხვადასხვა API-ში. ისინი ოდნავ განსხვავდებოდნენ, მაგრამ regexp სხვაგვარად უნდა დაეწერა. მას შემდეგ, რაც ეს ყველაფერი მართავს თოჯინას, იყო კლასების დიდი თაიგული საკუთარი ტარაკნებით. გარდა ამისა, td-agent-ს უმეტესად შეეძლო მეხსიერების ჭამა, სულელი ყოფილიყო, შეეძლო უბრალოდ მოეჩვენებინა, რომ მუშაობდა და არაფერს აკეთებდა. გარეგნულად შეუძლებელი იყო იმის გაგება, რომ ის არაფერს აკეთებდა. საუკეთესო შემთხვევაში, ის დაეცემა და ვინმე მას მოგვიანებით აიყვანს. უფრო სწორედ, გაფრთხილება შემოფრინდება და ვიღაც წავა და ხელებით აწია.

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

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

მაგრამ რაღაც უნდა გაკეთდეს! აშკარაა, რომ სტანდარტები უნდა დავამკვიდროთ. ჩვენ უკვე გვქონდა გარკვეული სტანდარტები. ზოგი ცოტა მოგვიანებით მოვიყვანეთ. საბედნიეროდ, ყველა API-სთვის ერთი ჟურნალის ფორმატი უკვე დამტკიცებული იყო იმ დროს. ის პირდაპირ არის ჩაწერილი სერვისის ურთიერთქმედების სტანდარტებში. შესაბამისად, მათ, ვისაც უნდა მიიღოს ჟურნალები, უნდა დაწერონ ისინი ამ ფორმატში. თუ ვინმე არ წერს ჟურნალებს ამ ფორმატში, მაშინ ჩვენ არაფრის გარანტიას არ ვიძლევით.

გარდა ამისა, მსურს მქონდეს ერთი სტანდარტი მორების ჩაწერის, მიწოდებისა და შეგროვების მეთოდებისთვის. სინამდვილეში, სად უნდა დაწეროთ ისინი და როგორ მივაწოდოთ ისინი. იდეალური სიტუაციაა, როდესაც პროექტები ერთსა და იმავე ბიბლიოთეკას იყენებენ. არის ცალკე ლოგინგ ბიბლიოთეკა Go-სთვის, არის ცალკე ბიბლიოთეკა PHP-სთვის. ვინც გვყავს, ყველამ უნდა გამოიყენოს ისინი. ამ დროისთვის ვიტყოდი, რომ 80 პროცენტით ვაღწევთ წარმატებას. მაგრამ ზოგიერთი აგრძელებს კაქტუსების ჭამას.

და იქ (სლაიდზე) "SLA ჟურნალის მიწოდებისთვის" ძლივს იწყებს გამოჩენას. ჯერ არ არის, მაგრამ ჩვენ ამაზე ვმუშაობთ. იმიტომ, რომ ძალიან მოსახერხებელია, როცა ინფრა ამბობს, რომ თუ ასეთ და ამგვარ ფორმატში წერ ამა თუ იმ ადგილას და არაუმეტეს N მესიჯის წამში, მაშინ ჩვენ მას დიდი ალბათობით იქ მივაწოდებთ. ის ხსნის უამრავ თავის ტკივილს. თუ არსებობს SLA, მაშინ ეს უბრალოდ შესანიშნავია!

როგორ დავიწყეთ პრობლემის მოგვარება? მთავარი საკომისიო იყო td-agent. გაურკვეველი იყო, სად მიდის ჩვენი მორები. მიეწოდება ისინი? მიდიან? სად არიან მაინც? ამიტომ, გადაწყდა td-agent ჩანაცვლება პირველი ნივთით. ვარიანტები, თუ რითი უნდა შეიცვალოს იგი, მოკლედ აღვნიშნე აქ.

გამართული. ჯერ ერთი, წინა სამსახურში შევხვდი და ისიც პერიოდულად ცვიოდა. მეორეც, ეს იგივეა, მხოლოდ პროფილში.

ფაილის ბიტი. რამდენად კარგი იყო ჩვენთვის? ის ფაქტი, რომ ის არის Go-ში და ჩვენ გვაქვს დიდი გამოცდილება გოში. შესაბამისად, თუ რამეა, შეგვეძლო როგორმე დავამატოთ საკუთარ თავს. ამიტომაც არ ავიღეთ. ისე, რომ ცდუნებაც კი არ არსებობდეს, რომ საკუთარი თავის გადაწერა დაიწყო.

sysadmin-ის აშკარა გამოსავალი არის ყველა სახის syslogs ამ რაოდენობით (syslog-ng/rsyslog/nxlog).

ან დაწერეთ რაიმე თქვენი, მაგრამ ჩვენ გავაუქმეთ იგი, ისევე როგორც filebeat. თუ რამეს წერ, მაშინ ჯობია დაწერო რამე სასარგებლო ბიზნესისთვის. მორების მიწოდებისთვის ჯობია რაიმე მზა აიღოთ.

მაშასადამე, არჩევანი რეალურად მოვიდა არჩევანზე syslog-ng-სა და rsyslog-ს შორის. rsyslog-ისკენ დავიხარე უბრალოდ იმიტომ, რომ ჩვენ უკვე გვქონდა გაკვეთილები rsyslog-ისთვის Puppet-ში და მათ შორის აშკარა განსხვავება ვერ ვიპოვე. რა არის syslog, რა არის syslog. დიახ, ზოგიერთი დოკუმენტაცია უარესია, ზოგი უკეთესი. მან იცის ეს გზა და ამას სხვანაირად აკეთებს.

და ცოტა რამ rsyslog-ის შესახებ. ჯერ ერთი, მაგარია, რადგან ბევრი მოდული აქვს. მას აქვს ადამიანის მიერ წასაკითხი RainerScript (თანამედროვე კონფიგურაციის ენა). გასაოცარი ბონუსი არის ის, რომ ჩვენ შეგვიძლია მივბაძოთ td-agent-ის ქცევას მისი სტანდარტული ხელსაწყოებით და არაფერი შეცვლილა აპლიკაციებში. ანუ td-agent-ს ვცვლით rsyslog-ზე და სხვას ჯერ არ შევეხებით. და დაუყოვნებლივ ვიღებთ სამუშაო მიწოდებას. შემდეგი, mmnormalize არის მაგარი რამ rsyslog-ის შესახებ. ის საშუალებას გაძლევთ გაანალიზოთ ჟურნალები, მაგრამ არა Grok-ით და regexp-ით. ის ქმნის აბსტრაქტულ სინტაქსურ ხეს. ის აანალიზებს ჟურნალებს ისევე, როგორც შემდგენელი აანალიზებს წყაროს კოდს. ეს საშუალებას გაძლევთ იმუშაოთ ძალიან სწრაფად, ჭამოთ პატარა CPU და, ზოგადად, ეს უბრალოდ ძალიან მაგარი რამ არის. არის კიდევ რამდენიმე ბონუსები. მათზე არ შევჩერდები.

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

ჩვენ გადავწყვიტეთ, რომ ჩაგვეწერა ჟურნალები unix სოკეტში. და არა /dev/log-ში, რადგან ჩვენ გვაქვს სისტემური ჟურნალების არეულობა, ამ მილსადენში არის ჟურნალი. მოდით მივწეროთ მორგებულ სოკეტს. ჩვენ მას დავამაგრებთ ცალკეულ წესებს. არაფერში ხელი არ შევუშალოთ. ყველაფერი იქნება გამჭვირვალე და გასაგები. ასე რომ, ჩვენ რეალურად გავაკეთეთ. დირექტორია ამ სოკეტებით არის სტანდარტიზებული და გადაგზავნილია ყველა კონტეინერში. კონტეინერებს შეუძლიათ ნახონ მათთვის საჭირო სოკეტი, გახსნან და დაწერონ მასზე.

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

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

მაგრამ არსებობს ნიუანსი იმის შესახებ, თუ როგორ უნდა ჩართოთ ისინი მოგვიანებით ამ ნაწილში (Logstash/Graylog/ES). ეს ნაწილი (rsyslog-rsyslog) გამოიყენება მონაცემთა ცენტრებს შორის. აქ არის შეკუმშული tcp ბმული, რომელიც საშუალებას გაძლევთ დაზოგოთ გამტარობა და, შესაბამისად, როგორმე გაზარდოთ იმის ალბათობა, რომ ჩვენ მივიღებთ სხვა მონაცემთა ცენტრიდან, როდესაც არხი სავსეა. იმიტომ, რომ ჩვენ გვაქვს ინდონეზია, სადაც ყველაფერი ცუდია. სწორედ აქ არის მუდმივი პრობლემა.

ჩვენ ვიფიქრეთ იმაზე, თუ როგორ ვაწარმოებთ რეალურ მონიტორინგს, რა ალბათობით აღწევენ აპლიკაციიდან ჩაწერილი ჟურნალები? ჩვენ გადავწყვიტეთ მეტრიკის დაწყება. Rsyslog-ს აქვს სტატისტიკის შეგროვების საკუთარი მოდული, რომელსაც აქვს გარკვეული სახის მრიცხველები. მაგალითად, მას შეუძლია გაჩვენოთ რიგის ზომა, ან რამდენი შეტყობინება შემოვიდა ამა თუ იმ მოქმედებისთვის. თქვენ უკვე შეგიძლიათ მათგან რაიმეს აღება. გარდა ამისა, მას აქვს მორგებული მრიცხველები, რომელთა კონფიგურაციაც შეგიძლიათ და ის გაჩვენებთ, მაგალითად, შეტყობინებების რაოდენობას, რომელიც ჩაწერილია ზოგიერთ API-მ. შემდეგ პითონში დავწერე rsyslog_exporter და გავაგზავნეთ ეს ყველაფერი პრომეთესთან და დავხატეთ. ჩვენ ძალიან გვინდოდა Graylog-ის მეტრიკა, მაგრამ ჯერჯერობით არ გვქონდა დრო მათი დაყენებისთვის.

რა პრობლემებია? პრობლემა წარმოიშვა იმით, რომ ჩვენ აღმოვაჩინეთ (უცებ!) რომ ჩვენი Live API წერს 50 12 შეტყობინებას წამში. ეს არის მხოლოდ Live API დადგმის გარეშე. გრეილოგი კი მხოლოდ XNUMX ათას შეტყობინებას გვაჩვენებს წამში. და გაჩნდა გონივრული კითხვა, სად არის ნარჩენები? საიდანაც დავასკვენით, რომ გრეილოგი უბრალოდ ვერ უმკლავდება. ჩვენ შევხედეთ და, მართლაც, Graylog-მა Elasticsearch-თან ერთად ვერ აითვისა ეს ნაკადი.

შემდეგი, სხვა აღმოჩენები, რომლებიც ჩვენ ამ გზაზე გავაკეთეთ.

სოკეტში ჩაწერა დაბლოკილია. Როგორ მოხდა? როდესაც მე გამოვიყენე rsyslog მიწოდებისთვის, რაღაც მომენტში ჩვენ გავტეხეთ არხი მონაცემთა ცენტრებს შორის. მიწოდება დადგა ერთ ადგილას, მიწოდება სხვაგან. ეს ყველაფერი ჩამოყალიბდა მანქანაში API-ებით, რომლებიც წერენ rsyslog სოკეტში. რიგი იყო. შემდეგ ივსება უნიქსის სოკეტში ჩაწერის რიგი, რომელიც ნაგულისხმევად არის 128 პაკეტი. და შემდეგი ჩაწერა() აპლიკაციის ბლოკებში. როდესაც გადავხედეთ ბიბლიოთეკას, რომელსაც ვიყენებთ Go აპლიკაციებში, იქ ეწერა, რომ სოკეტში ჩაწერა ხდება არადაბლოკვის რეჟიმში. დარწმუნებული ვიყავით, რომ არაფერი დაბლოკილი იყო. იმიტომ რომ წავიკითხეთ სტატია ბადუშეჩკას შესახებვინც დაწერა ამის შესახებ. მაგრამ არის მომენტი. ასევე იყო უსასრულო მარყუჟი ამ ზარის ირგვლივ, რომლის დროსაც იყო მუდმივი მცდელობა, რომ მესიჯი შეეტანა სოკეტში. ჩვენ ის არ შევამჩნიეთ. ბიბლიოთეკის გადაწერა მომიწია. მას შემდეგ ის რამდენჯერმე შეიცვალა, მაგრამ ახლა ყველა ქვესისტემაში ჩაკეტვები მოვიშორეთ. ამიტომ, შეგიძლიათ შეაჩეროთ rsyslog და არაფერი დაეცემა.

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

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

როგორ მოვაგვაროთ elasticsearch პრობლემა? თუ გჭირდებათ ჟურნალების სწრაფად მოპოვება ერთ ადგილას, ისე, რომ არ გაუშვათ ყველა მანქანაში და შეაგროვოთ ისინი იქ, გამოიყენეთ ფაილების შენახვა. ეს გარანტირებულია მუშაობაში. ეს კეთდება ნებისმიერი სერვერიდან. თქვენ უბრალოდ უნდა ჩადოთ დისკები იქ და დააყენოთ syslog. ამის შემდეგ, თქვენ გარანტირებული გაქვთ ყველა ჟურნალი ერთ ადგილას. შემდეგ შესაძლებელი იქნება ნელ-ნელა elasticsearch-ის, graylog-ის ან სხვა რამის კონფიგურაცია. მაგრამ თქვენ უკვე გექნებათ ყველა ჟურნალი და, უფრო მეტიც, შეგიძლიათ შეინახოთ ისინი, რამდენადაც საკმარისია დისკის მასივები.

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

ეს ნაწილი Logstash-თან და Graylog-თან ერთად, ნამდვილად იზრდება. ამიტომ, თქვენ უნდა მოიცილოთ იგი. თქვენ უნდა აირჩიოთ ერთი.

გადავწყვიტეთ დაგვეტოვებინა Logstash და Kibana. იმიტომ, რომ ჩვენ გვაქვს უსაფრთხოების განყოფილება. რა კავშირია? კავშირი იმაში მდგომარეობს, რომ Kibana X-Pack-ის და Shield-ის გარეშე არ გაძლევთ საშუალებას განასხვავოთ წვდომის უფლებები ჟურნალებზე. ამიტომ მათ აიღეს გრეილოგი. მას აქვს ეს ყველაფერი. არ მომწონს, მაგრამ მუშაობს. ჩვენ ვიყიდეთ ახალი აპარატურა, დავაინსტალირეთ ახალი Graylog და გადავიტანეთ ყველა ჟურნალი მკაცრი ფორმატის ცალკე Graylog-ში. სხვადასხვა ტიპის ერთიდაიგივე სფეროს პრობლემა ორგანიზაციულად მოვაგვარეთ.

კონკრეტულად რა შედის ახალ გრეილოგში. ჩვენ უბრალოდ დავწერეთ ყველაფერი დოკერში. ჩვენ ავიღეთ რამდენიმე სერვერი, გამოვაქვეყნეთ კაფკას სამი ინსტანცია, 7 Graylog სერვერის ვერსია 2.3 (რადგან მე მინდოდა Elasticsearch ვერსია 5). ეს ყველაფერი გაჩნდა HDD-ის რეიდებზე. ჩვენ ვნახეთ ინდექსირების მაჩვენებელი 100 ათასამდე შეტყობინება წამში. ჩვენ ვნახეთ რიცხვი, რომ 140 ტერაბაიტი მონაცემები კვირაში.

და ისევ საკომისიო! წინ გვაქვს ორი გაყიდვა. ჩვენ გადავედით 6 მილიონ პოსტზე. ჩვენ გრეილოგს საღეჭი დრო არ გვაქვს. როგორმე ისევ უნდა გადარჩე.

ასე გადავრჩით. დაემატა კიდევ რამდენიმე სერვერი და SSD. ამჟამად ასე ვცხოვრობთ. ახლა ჩვენ უკვე ვღეჭავთ 160 ათას შეტყობინებას წამში. ჩვენ ჯერ არ მივაღწიეთ ზღვარს, ამიტომ გაურკვეველია, რამდენად შეგვიძლია რეალურად გავიდეთ მისგან.

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

შეაგროვეთ მეტრიკა Graylog-დან.

შექმენით განაკვეთის ლიმიტი ისე, რომ გვქონდეს ერთი გიჟური API, რომელიც არ გვკლავს სიჩქარეს და ყველაფერს.

და ბოლოს, ხელი მოაწერეთ რაიმე სახის SLA-ს დეველოპერებთან, რათა ამდენი მოვემსახუროთ. თუ მეტს დაწერ ბოდიში.

და დაწერე დოკუმენტაცია.

მოკლედ, ყველაფრის შედეგი, რაც განვიცადეთ. პირველი, სტანდარტები. მეორე, syslog არის ტორტი. მესამე, rsyslog მუშაობს ზუსტად ისე, როგორც წერია სლაიდზე. და მოდით გადავიდეთ კითხვებზე.

კითხვები.

კითხვა: რატომ გადაწყვიტეს არ მიიღონ ... (filebeat?)

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

კითხვა: რატომ არ წერთ ჟურნალებს HDFS-ში?

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

კითხვა: სვეტის ფორმატი უფრო შესაფერისი იქნება.

პასუხი: Მე მესმის. ორივე ხელით ვართ „მომხრე“.

კითხვა: თქვენ წერთ rsyslog-ს. ორივე TCP და UDP ხელმისაწვდომია იქ. მაგრამ თუ UDP, მაშინ როგორ უზრუნველყოფთ მიწოდების გარანტიას?

პასუხი_ ორი წერტილია. პირველ რიგში, მე დაუყოვნებლივ ვეუბნები ყველას, რომ ჩვენ არ ვიძლევით გარანტიას მორების მიწოდებაზე. რადგან, როდესაც დეველოპერები მოდიან და იტყვიან: „მოდით, იქ დავიწყოთ ფინანსური მონაცემების წერა და თუ რამე მოხდება, სადმე დაგვიდებ“, ჩვენ მათ ვპასუხობთ: „მშვენიერია! დავიწყოთ სოკეტზე ჩაწერის დაბლოკვა და ეს გავაკეთოთ ტრანზაქციებში, რომ გარანტირებული გქონდეთ ჩვენთვის ჩასმა და დარწმუნდეთ, რომ მეორე მხრიდან მივიღეთ. და ამ მომენტში, ყველა მაშინვე ხდება არასაჭირო. და თუ არა, მაშინ რა კითხვები გვაქვს? თუ არ გსურთ გარანტია მოგცეთ სოკეტში ჩაწერა, მაშინ რატომ ვიძლევით გარანტიას მიწოდებაზე? ჩვენ მაქსიმალურ ძალისხმევას ვაკეთებთ. ჩვენ ნამდვილად ვცდილობთ მივაწოდოთ რაც შეიძლება მეტი და მაქსიმალურად, მაგრამ 100%-იან გარანტიას არ ვაძლევთ. ამიტომ, თქვენ არ გჭირდებათ იქ ფინანსური მონაცემების ჩაწერა. ამისათვის არსებობს ტრანზაქციის მონაცემთა ბაზები.

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

პასუხი_ ნორმალურია, რომ სხვა თანმიმდევრობით მოდიან. ამისათვის მზად უნდა იყოთ. იმის გამო, რომ ნებისმიერი ქსელის მიწოდება არ იძლევა თქვენთვის შეკვეთის გარანტიას, ან ამისათვის სპეციალური რესურსების დახარჯვა გჭირდებათ. თუ ჩვენ ვიღებთ ფაილების შენახვას, მაშინ თითოეული API ინახავს ჟურნალებს საკუთარ ფაილში. უფრო მეტიც, rsyslog ანაწილებს მათ დირექტორიაებად. თითოეულ API-ს აქვს საკუთარი ჟურნალი, სადაც შეგიძლიათ შეხვიდეთ და ნახოთ, შემდეგ კი შეგიძლიათ შეადაროთ ისინი ამ ჟურნალის დროის ანაბეჭდის გამოყენებით. თუ ისინი მიდიან Graylog-ში სანახავად, მაშინ ისინი დალაგდებიან დროის ნიშნულის მიხედვით. იქ ყველაფერი კარგად იქნება.

კითხვა: დროის ანაბეჭდი შეიძლება განსხვავდებოდეს მილიწამებით.

პასუხი: დროის ანაბეჭდი გენერირდება თავად API-ს მიერ. ეს, ფაქტობრივად, მთელი აზრია. ჩვენ გვაქვს NTP. API ქმნის დროის ნიშანს უკვე თავად შეტყობინებაში. ის არ არის დამატებული rsyslog-ის მიერ.

კითხვა: მონაცემთა ცენტრებს შორის ურთიერთქმედება არც თუ ისე ნათელია. მონაცემთა ცენტრის ფარგლებში ირკვევა, თუ როგორ ხდებოდა ლოგების შეგროვება და დამუშავება. როგორ არის ურთიერთქმედება მონაცემთა ცენტრებს შორის? ან თითოეული მონაცემთა ცენტრი ცხოვრობს თავისი ცხოვრებით?

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

კითხვა: არანორმალურ სიტუაციებში მორები იქიდან იღებთ?

პასუხი: შეგიძლიათ იქ შეხვიდეთ (ფაილის საცავში) და ნახოთ.

კითხვა: როგორ აკონტროლებ, რომ არ დაკარგო მორები?

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

კითხვა: elasticsearch-ში თქვენ ინახავთ ჟურნალებს ჭარბი რაოდენობით. რამდენი ასლი გაქვთ?

პასუხი: ერთი ასლი.

კითხვა: ეს მხოლოდ ერთი ხაზია?

პასუხი: ეს არის ოსტატი და რეპლიკა. მონაცემები ინახება დუბლიკატში.

კითხვა: როგორმე შეცვალეთ rsyslog ბუფერის ზომა?

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

Კითხვა: გატეხილი JSON წერ?

პასუხი: გატეხილი JSON გაუქმდება რელეის დროს, რადგან პაკეტი ძალიან დიდია. ან Graylog დაიკარგება, რადგან ის ვერ შეძლებს JSON-ის ანალიზს. მაგრამ აქ არის ნიუანსები, რომლებიც უნდა გამოსწორდეს და ისინი ძირითადად rsyslog-თანაა მიბმული. იქ უკვე შევავსე რამდენიმე ნომერი, რომლებზეც ჯერ კიდევ უნდა დამუშავდეს.

Კითხვა: რატომ კაფკა? სცადეთ RabbitMQ? გრეილოგი არ გროვდება ასეთ დატვირთვებში?

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

კაფკას შესახებ. ასე მოხდა ისტორიულად. რომ მივედი, უკვე იქ იყო და მასზე უკვე ჟურნალები იწერებოდა. ჩვენ უბრალოდ გავზარდეთ ჩვენი კლასტერი და გადავიტანეთ მასში ჟურნალები. ჩვენ მას ვმართავთ, ვიცით, რას გრძნობს. რაც შეეხება RabbitMQ... ჩვენ გვაქვს პრობლემა RabbitMQ. და RabbitMQ ვითარდება ჩვენთვის. ჩვენ გვაქვს წარმოებაში და იყო პრობლემები. ახლა, გაყიდვამდე, მას შამანიზებდნენ და ნორმალურად დაიწყებდა მუშაობას. მაგრამ მანამდე არ ვიყავი მზად მისი წარმოებაში გაშვებისთვის. არის კიდევ ერთი წერტილი. Graylog–ს შეუძლია წაიკითხოს AMQP 0.9 ვერსია და rsyslog–ს შეუძლია დაწეროს AMQP 1.0 ვერსია. და არ არსებობს ერთი გამოსავალი, რომელსაც შეუძლია ორივე შუაში. არსებობს ან ერთი ან მეორე. ასე რომ, ჯერჯერობით მხოლოდ კაფკა. მაგრამ არის ნიუანსებიც. რადგან rsyslog-ის ვერსიის omkafka-მ, რომელსაც ჩვენ ვიყენებთ, შეიძლება დაკარგოს შეტყობინებების მთელი ბუფერი, რომელიც მან ამოიღო rsyslog-დან. სანამ ამას შევეგუებით.

Კითხვა: კაფკას იმიტომ იყენებ, რომ გქონდა? სხვა მიზნისთვის არ გამოიყენება?

პასუხი: კაფკა, რომელიც გამოიყენა მონაცემთა მეცნიერების ჯგუფმა. ეს არის სრულიად ცალკე პროექტი, რაზეც, სამწუხაროდ, ვერაფერს ვიტყვი. Არ ვიცი. მას მონაცემთა მეცნიერების გუნდი მართავდა. როდესაც ჟურნალები დაიწყო, მათ გადაწყვიტეს გამოეყენებინათ იგი, რათა არ დაეყენებინათ საკუთარი. ახლა ჩვენ განვაახლეთ Graylog და დავკარგეთ თავსებადობა, რადგან არსებობს კაფკას ძველი ვერსია. ჩვენ თვითონ უნდა გაგვეკეთებინა. ამავდროულად, ჩვენ მოვიშორეთ ეს ოთხი თემა თითოეული API-სთვის. ჩვენ გავაკეთეთ ერთი ფართო ტოპი ყველა ცოცხალისთვის, ერთი ფართო ტოპი ყველა დადგმისთვის და უბრალოდ იქ ვიღებთ ყველაფერს. Graylog ამ ყველაფერს პარალელურად ასახავს.

Კითხვა: რატომ გვჭირდება ეს შამანიზმი სოკეტებით? სცადეთ გამოიყენოთ syslog ჟურნალის დრაივერი კონტეინერებისთვის.

პასუხი: იმ დროს, როცა ეს კითხვა დავსვით, დოკერთან დაძაბული ურთიერთობა გვქონდა. ეს იყო დოკერი 1.0 ან 0.9. თავად დოკერი უცნაური იყო. მეორეც, თუ მასში ლოგიც ჩავრგეთ... გადაუმოწმებელი ეჭვი მაქვს, რომ ის ყველა ჟურნალს თავისში გადის, დოკერ დემონის მეშვეობით. თუ ჩვენ გვაქვს ერთი API, რომელიც გიჟდება, მაშინ დანარჩენ API-ებს შეექმნებათ ის, რომ მათ არ შეუძლიათ stdout და stderr გაგზავნა. არ ვიცი სად მიგვიყვანს ეს. მე მაქვს ეჭვი განცდის დონეზე, რომ არ არის საჭირო ამ ადგილას docker syslog დრაივერის გამოყენება. ჩვენს ფუნქციონალური ტესტირების განყოფილებას აქვს საკუთარი Graylog კლასტერი ჟურნალებით. ისინი იყენებენ დოკერის ჟურნალის დრაივერებს და როგორც ჩანს, იქ ყველაფერი კარგადაა. მაგრამ ისინი მაშინვე წერენ GELF-ს გრეილოგს. იმ მომენტში, როცა ეს ყველაფერი დავიწყეთ, ეს მხოლოდ მუშაობისთვის გვჭირდებოდა. ალბათ, მერე, როცა ვინმე მოვა და იტყვის, ასი წელია ნორმალურად მუშაობს, ვცადოთ.

Კითხვა: თქვენ აწვდით მონაცემთა ცენტრებს შორის rsyslog-ის გამოყენებით. რატომ არა კაფკაზე?

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

წყარო: www.habr.com