ჟურნალები Kubernetes-ში (და არა მხოლოდ) დღეს: მოლოდინები და რეალობა

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

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

• ვინმეს სურს უსაფრთხოების და აუდიტის ჟურნალების ნახვა;
• ვინმე - მთელი ინფრასტრუქტურის ცენტრალიზებული ჭრა;
• ზოგისთვის კი საკმარისია მხოლოდ აპლიკაციის ჟურნალების შეგროვება, მაგალითად, ბალანსერების გამოკლებით.

ქვემოთ მოცემულია ქვემოთ მოყვანილი ფრაგმენტი იმის შესახებ, თუ როგორ განვახორციელეთ სხვადასხვა „სურვილების სია“ და რა სირთულეები შეგვხვდა.

თეორია: ხე-ტყის ინსტრუმენტების შესახებ

ფონი ხე-ტყის სისტემის კომპონენტების შესახებ

ლოგინგმა დიდი გზა გაიარა, რის შედეგადაც შემუშავდა ჟურნალების შეგროვებისა და ანალიზის მეთოდოლოგიები, რასაც დღეს ვიყენებთ. ჯერ კიდევ 1950-იან წლებში Fortran-მა შემოიტანა სტანდარტული შეყვანის/გამომავალი ნაკადების ანალოგი, რომელიც დაეხმარა პროგრამისტს მისი პროგრამის გამართვაში. ეს იყო პირველი კომპიუტერული ჟურნალები, რომლებმაც გაუადვილეს ცხოვრება იმდროინდელ პროგრამისტებს. დღეს ჩვენ მათში ვხედავთ ხე-ტყის სისტემის პირველ კომპონენტს - მორების წყარო ან „მწარმოებელი“..

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

ჟურნალების მოცულობის ზრდასთან და ვებ ტექნოლოგიების ფართოდ დანერგვასთან ერთად, გაჩნდა კითხვა, თუ რა ჟურნალები უნდა იყოს მოხერხებულად ჩვენებული მომხმარებლებისთვის. მარტივი კონსოლის ხელსაწყოები (awk/sed/grep) შეიცვალა უფრო მოწინავეებით ჟურნალის მნახველები - მესამე კომპონენტი.

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

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

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

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

თუ ოდესღაც ჩვეულებრივი ანაბეჭდები საკმარისი იქნებოდა "ლოგის სისტემისთვის", ახლა სიტუაცია ძალიან შეიცვალა.

კუბერნეტები და მორები

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

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

• ვიღაც ხსნის დასტას EFK (Elasticsearch, Fluentd, Kibana);
• ვიღაც ცდილობს ახლახან გამოშვებულს ლოკი ან იყენებს ხე-ტყის ოპერატორი;
• ჩვენს (და იქნებ არა მარტო ჩვენ?..) დიდწილად კმაყოფილი ვარ საკუთარი განვითარებით - ხის სახლი...

როგორც წესი, ჩვენ ვიყენებთ შემდეგ პაკეტებს K8s კლასტერებში (თვითმმართველობის გადაწყვეტილებებისთვის):

• Fluentd + Elasticsearch + Kibana;
• Fluentd + ClickHouse + Loghouse.

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

ივარჯიშეთ ლოგებით K8s-ში

"ყოველდღიური ჟურნალები", რამდენი ხართ იქ?..

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

მოდით ვცადოთ ClickHouse

მოდით შევხედოთ პროექტზე ცენტრალიზებულ საცავს აპლიკაციით, რომელიც საკმაოდ აქტიურად წარმოქმნის ჟურნალებს: 5000 ხაზზე მეტი წამში. დავიწყოთ მუშაობა მის ჟურნალებთან, დავამატოთ ClickHouse-ში.

როგორც კი მაქსიმალური რეალური დრო იქნება საჭირო, 4 ბირთვიანი სერვერი ClickHouse-ით უკვე გადატვირთული იქნება დისკის ქვესისტემაზე:

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

DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts

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

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

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

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

რაც შეეხება Elasticsearch-ს?

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

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

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

მაშინ ჩნდება ბუნებრივი კითხვა:

რა ჟურნალებია ნამდვილად საჭირო?

შევეცადოთ თავად შევცვალოთ მიდგომა: ჟურნალები ერთდროულად უნდა იყოს ინფორმატიული და არა დაფარული ყველა მოვლენა სისტემაში.

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

ამიტომ მივედით დასკვნამდე, რომ ცენტრალიზებული ხე-ტყე ყოველთვის არ არის გამართლებული. ძალიან ხშირად კლიენტს სურს შეაგროვოს ყველა ჟურნალი ერთ ადგილზე, თუმცა სინამდვილეში, მთელი ჟურნალიდან, საჭიროა მხოლოდ პირობითი 5% შეტყობინებები, რომლებიც კრიტიკულია ბიზნესისთვის:

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

ილუსტრაცია ცხოვრებიდან

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

საჭირო იყო ჟურნალების შეგროვების ცენტრალიზებული სისტემის „დამეგობრება“ კორპორატიული პრობლემების გამოვლენის სენსორით - QRadar. ამ სისტემას შეუძლია ჟურნალების მიღება syslog პროტოკოლის მეშვეობით და მათი ამოღება FTP-დან. თუმცა, დაუყოვნებლივ შეუძლებელი იყო მისი ინტეგრირება remote_syslog მოდულთან fluentd-ისთვის (როგორც იქნა, ჩვენ არ ვართ მარტო). QRadar-ის დაყენების პრობლემები კლიენტის უსაფრთხოების ჯგუფის მხარეზე აღმოჩნდა.

შედეგად, ბიზნესისთვის კრიტიკული ჟურნალების ნაწილი აიტვირთა FTP QRadar-ზე, ხოლო მეორე ნაწილი გადამისამართდა დისტანციური syslog-ის მეშვეობით პირდაპირ კვანძებიდან. ამისთვის კი დავწერეთ მარტივი სქემა - იქნებ ვინმეს დაეხმაროს მსგავსი პრობლემის გადაჭრაში... შედეგად მიღებული სქემის წყალობით, კლიენტმა თავად მიიღო და გააანალიზა კრიტიკული ჟურნალები (მისი საყვარელი ხელსაწყოების გამოყენებით) და ჩვენ შევძელით შეგვემცირებინა ხე-ტყის სისტემის ღირებულება, დაზოგეთ მხოლოდ გასული თვე.

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

კრიტერიუმები ჟურნალებისთვის

ასეთი მაგალითები მივყავართ დასკვნამდე, რომ გარდა ჟურნალის შეგროვების სისტემის არჩევისა, საჭიროა ასევე თავად შეიმუშავეთ მორები! რა მოთხოვნებია აქ?

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

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

2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"

შეცდომა ნიშნავს, რომ თქვენ აგზავნით ველს, რომლის ტიპიც არასტაბილურია, მზა რუკებით. უმარტივესი მაგალითია ველი nginx ჟურნალში ცვლადით $upstream_status. ის შეიძლება შეიცავდეს რიცხვს ან სტრიქონს. Მაგალითად:

{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}

ჟურნალები აჩვენებს, რომ სერვერმა 10.100.0.10 უპასუხა 404 შეცდომით და მოთხოვნა გაიგზავნა სხვა შინაარსის საცავში. შედეგად, ჟურნალებში მნიშვნელობა ასეთი გახდა:

"upstream_response_time": "0.001, 0.007"

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

რაც შეეხება საიმედოობას?

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

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

"helm.sh/hook-delete-policy": hook-succeeded

ამის გამო, მიგრაციის შესრულების ჟურნალი არ იყო ჩართული საცავში. ამ შემთხვევაში პოლიტიკა დაგეხმარებათ. before-hook-creation.

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

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

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

დასკვნები

ამ სტატიაში ჩვენ არ ვუყურებთ SaaS გადაწყვეტილებებს, როგორიცაა Datadog. აქ აღწერილი ბევრი პრობლემა ამა თუ იმ გზით უკვე მოგვარებულია ჟურნალების შეგროვებაში სპეციალიზირებული კომერციული კომპანიების მიერ, მაგრამ ყველას არ შეუძლია გამოიყენოს SaaS სხვადასხვა მიზეზის გამო. (ძირითადი არის ღირებულება და შესაბამისობა 152-FZ).

ჟურნალების ცენტრალიზებული შეგროვება თავიდან მარტივი ამოცანაა, მაგრამ ეს საერთოდ არ არის. მნიშვნელოვანია გვახსოვდეს, რომ:

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

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

PS

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «წარმოგიდგენთ loghouse - ღია კოდის სისტემას Kubernetes-ში ჟურნალებთან მუშაობისთვის";
• «გამოშვებები Kubernetes ეკოსისტემისთვის KubeCon'19-დან: JFrog Container Registry, Kui IBM-დან, Loki 1.0.0…";
• «მონიტორინგი და Kubernetes (მიმოხილვა და ვიდეო ანგარიში)".

წყარო: www.habr.com