ლოგი თუ მეტრიკა: რამდენი დაკვირვებადობა სჭირდება სისტემას ერთ სერვერზე

Grafana-მ Workflows გამოუშვა და Adaptive Telemetry გააფართოვა, Sentry-მ ლოგსა და მეტრიკას შორის განსხვავება ახსნა, OpenTelemetry-მ უსაფრთხოებისთვის ვერსიების წესები შეცვალა, ხოლო CNCF-ის ბლოგში აჩვენეს, როგორ შეიკვეცოს კოდში AI-ასისტენტის ტელემეტრია. ეს ყველაფერი ათეულობით სერვისის მქონე გუნდებისთვის არის დაწერილი. კითხვა „რა ჩაიწეროს ჟურნალში და რა დაითვალოს“ ერთ სერვერზე მდგომი სისტემის წინაშეც დგას, და ბიზნესის მფლობელისთვის სასარგებლოა იცოდეს, რაში იხდის მონიტორინგში.

რა გამოვიდა

Grafana Labs-მა 21 ოქტომბერს საჯარო preview-ში Grafana Workflows წარადგინა: გუნდის პროცესი ავტომატურ ნაბიჯებად იქცევა. შაბლონი major incident kickoff Slack-ში არხს ქმნის, განრიგით მორიგე ინციდენტ-მეთაურს პოულობს, runbook-ს ამაგრებს და ინციდენტის timeline-ში წერს. ნაბიჯი ask Assistant მათ მოდელს სთხოვს, ინციდენტზე შეჯამება შეკრიბოს და დაკვირვებები ჰიპოთეზებისგან გამოყოს. შაბლონი on-call handoff report მორიგის შეცვლისას კვირის ინციდენტებზე ანგარიშს კრებს.

ერთი დღით ადრე, 20 ოქტომბერს, Grafana-მ აღწერა, როგორ აშორებს Adaptive Telemetry გადასახადს მონაცემების მოცულობისგან. ტრასებისთვის: volumetric sampling შერჩევის ბიუჯეტს სერვისებს შორის ყოფს და, მათი ტესტებით, დაახლოებით 25%-ით მეტ სასარგებლო ინფორმაციას იძლევა, ვიდრე იმავე მოცულობის შემთხვევითი შერჩევა, ხოლო გადაგდებული ტრასები 24 საათი ID-ით ხელმისაწვდომია. ლოგებისთვის: გადაგდების წესები პირდაპირ კოლექტორებზე მოქმედებს, ხოლო ის, რისი დაკარგვაც გეცოდებათ, თქვენს იაფ ობიექტურ საცავში მიდის უკან დაბრუნების შესაძლებლობით.

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

OpenTelemetry-მ 22 ოქტომბერს ვერსიების პოლიტიკა განაახლა: სტაბილურ SDK-ებსა და Contrib კომპონენტებს ახლა უსაფრთხოებისთვის ქცევის შეცვლა მინორულ და patch-რელიზებში შეუძლიათ, საჯარო API-ს ამასთან არ ეხებიან, ხოლო release notes ვალდებულია ახსნას, რა შეიცვალოს კონფიგურაციაში.

კვირის ყველაზე პრაქტიკული ტექსტი: CNCF-მა 22 ოქტომბერს აჩვენა, როგორ გაიფილტროს კოდში AI-ასისტენტის ტელემეტრია OpenTelemetry Collector-ით. ერთმა პატარა ამოცანამ Claude Code-სთვის 181 ჩანაწერი და 289 KB JSON მისცა. ავტორმა ექვსი კითხვა ამოწერა: ღირებულება მოდელების მიხედვით, ტოკენები, რომელი ინსტრუმენტები ვარდება, სად არის დაყოვნება, რა გატყდა. ყველაზე მთვლელები და მოკლე ატრიბუტები პასუხობენ, ხოლო ფაილების შიგთავსი და პრომპტები მხოლოდ ადგილს იკავებს. შემდეგ კოლექტორის კონფიგურაცია: მოვლენა api_request გადაიგდოს, ეს ჩანაწერების დაახლოებით მეოთხედია, ექვსი ატრიბუტი წაიშალოს, იდენტიფიკატორები დაჰეშდეს და ჰეში 16 სიმბოლომდე მოიჭრას, რადგან სრული SHA256 UUID-ზე გრძელია და პირველი გაშვების შემდეგ ლოგების მოცულობა გაიზარდა.

რატომ სჭირდება ეს ბიზნესს

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

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

როგორ მაქვს ეს მოწყობილი

აშშ-ში PDR-კომპანიასთან 2021 წლიდან ვმუშაობ და ინფრასტრუქტურას თავად ვაკვირდები: სერვერი Debian-ზე Google Cloud-ში, VPN, ქსელური აპარატურა და ტელეფონია. Grafana Workflows იქ საჭირო არ არის, მორიგე ერთია, და ეს მე ვარ. სამაგიეროდ 2025 წელს კომპანიაში 4 ტელევიზორზე TV-დაფა გამოვიტანე, თითოეულზე თავისი დაფა: მფლობელისთვის, წარმოებისთვის შეკვეთების მიხედვით, front desk-ისთვის და გამყიდველებისთვის. ბიზნესისთვის ეს იგივე მეტრიკებია, რასაც ინჟინერი დეშბორდში უყურებს. Leaderboard თანამშრომლებს 15 მაჩვენებლით ითვლის. ხოლო ყოველი ზარის ჩანაწერი და AI-გარჩევა, ვინ და რატომ დარეკა, Sentry-ს ტერმინებში ლოგია: მისით აღადგენენ, რა მოხდა კონკრეტულ კლიენტთან.

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

კოდში AI-ასისტენტი მეც მაქვს, ის რუტინას, ტესტებსა და გამართვას იღებს. მისი ტელემეტრია კოლექტორში არ შემიყვანია, მაგრამ CNCF-ის სტატიის თანმიმდევრობა სწორია: ჯერ კითხვები, მერე ველები.

რას გავაკეთებდი

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

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

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

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

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