მთავარი დასკვნა
თითოეული ჩანაწერი დაუკავშირეთ დიაგნოსტიკურ კითხვას: რომელი ოპერაცია ჩავარდა, რომელ სერვისზე იმოქმედა და როდის? პაროლები, ტოკენები და არასაჭირო პირადი მონაცემები ჟურნალებში არ შეიტანოთ.
რომელ კითხვას უნდა უპასუხოს ჟურნალმა?
აპლიკაციის ჟურნალი აღრიცხავს პროგრამის მუშაობისას წარმოქმნილ მოვლენებს დროის ნიშნულებით. გაშვება და გამორთვა, მოთხოვნების შედეგები, მოულოდნელი შეცდომები, გარე სერვისების წარუმატებელი გამოძახებები და კონფიგურაციის ცვლილებები გამოძიების სხვადასხვა კითხვას პასუხობს. ოპერაციული სისტემისა და სერვერის ჟურნალები გარემომცველ გარემოს აღწერს; აპლიკაციის ჟურნალებს შეუძლია ახსნას, რას ცდილობდა აპლიკაცია.
ოპერაცია
მოთხოვნის, დავალების ან ინტეგრაციის დასაწყისი და შედეგი.
შეცდომა
გამონაკლისი, დამოკიდებული კომპონენტის მარცხი ან გაუმართაობა, რომელიც მომხმარებელზე მოქმედებს.
ცვლილება
გამოშვების, კონფიგურაციის ან პრივილეგიის ცვლილების დრო და მოქმედი პირი.
აირჩიეთ ველები, რომლებიც მოვლენას ხსნის
თანმიმდევრული ველები ჩანაწერების ძიებასა და შედარებას ამარტივებს. ხშირად სასარგებლოა დრო, დონე, სერვისი და გარემო, მოვლენის ტიპი, შედეგი, მოკლე შეტყობინება, მოთხოვნის ან კვალის იდენტიფიკატორი და, სადაც უსაფრთხოა, შეცდომის კოდი. სერვისებს შორის მოვლენების შედარებისას საათები სინქრონიზებული იყოს და დროის სარტყელი მკაფიოდ ჩანდეს. ყველა ჩანაწერს ყველა შესაძლო დეტალი არ სჭირდება.
დრო და წყარო
UTC ან აშკარად მითითებული დროის სარტყელი; სერვისი, ვერსია და გარემო.
მოვლენა და შედეგი
მოვლენის სტაბილური სახელი, შედეგი და შერჩეული აღრიცხვის დონე.
კორელაცია
მოთხოვნის ID და, ხელმისაწვდომობისას, trace/span ID‑ები; თვითონ იდენტიფიკატორი საიდუმლო ან ანგარიშის მონაცემი არ უნდა იყოს.
დონეები თანმიმდევრულად გამოიყენეთ
დონე აჩვენებს, რამდენად სასწრაფოდ სჭირდება ჩანაწერს ყურადღება, თუმცა სახელები და ზუსტი მნიშვნელობები აღრიცხვის ბიბლიოთეკაზეა დამოკიდებული. გუნდში შეათანხმეთ მოკლე ლექსიკა: DEBUG დამატებითი დეველოპერული დეტალებისთვის, INFO ნორმალური ეტაპებისთვის, WARN მოულოდნელი, მაგრამ აღდგენადი მდგომარეობისთვის, ERROR წარუმატებელი ოპერაციისთვის და CRITICAL/FATAL კომპონენტის მძიმე მარცხისთვის. სხვადასხვა სერვისში არათანმიმდევრული დონეები გაფრთხილების წესებს ასუსტებს.
DEBUG / TRACE
დეტალური დიაგნოსტიკა; საწარმოო გარემოში შეზღუდეთ მოცულობა და მგრძნობიარე ველები.
INFO / WARN
აღწერეთ ნორმალური პროგრესი და საყურადღებო მდგომარეობები, რომლებიც ჯერ მარცხს არ წარმოადგენს.
ERROR / CRITICAL
ხელი შეუწყვეთ ესკალაციას, როდესაც ფუნქცია მწყობრიდან გამოდის ან ზემოქმედება უფრო ფართოა.
სტრუქტურირებული ჩანაწერები წაკითხვადი იყოს
ისეთი სტრუქტურირებული ფორმატი, როგორიცაა JSON, თითოეულ მოვლენას თანმიმდევრულ გასაღებებს აძლევს და როგორც ტექსტურ ძიებას, ისე ველებზე დაფუძნებულ გაფილტვრასა თუ კორელაციას უზრუნველყოფს. სერვისებს შორის ველების სახელები და ტიპები თანმიმდევრული იყოს. გამოიყენეთ მოკლე შეტყობინება, შეცდომის ტიპი და ოპერაციის კონტექსტი ცალკე ველებში განათავსეთ და საჭიროებისას სრული სტეკის კვალი შეინარჩუნეთ. JSONL გავრცელებული ფორმატია, სადაც თითო ხაზზე ერთი JSON‑ობიექტია.
{"timestamp":"2026-10-09T08:30:00Z","level":"ERROR","service":"billing-api","event":"payment_authorization_failed","request_id":"req-7f21","error_code":"upstream_timeout"}
არ შეიტანოთ საიდუმლოებები და არასაჭირო პირადი მონაცემები
მოთხოვნის შიგთავსი, URL‑პარამეტრები, ქუქიები, ტოკენები, პაროლები და მომხმარებლის სრული მონაცემები შეიძლება ჟურნალში უნებლიეთ მოხვდეს. მგრძნობიარე მნიშვნელობები შეგროვებისთანავე წაშალეთ ან დაფარეთ და შეინარჩუნეთ მხოლოდ დასახელებული მიზნისთვის საჭირო ველები. აკონტროლეთ წვდომა გადაცემისა და შენახვისას, შეზღუდეთ პრივილეგიები და შეინარჩუნეთ ცვლილებების ისტორია.
უნდა აღირიცხოს ყველა მოვლენა?
არა. აირჩიეთ მნიშვნელოვანი ოპერაციები და გამოძიების კითხვები; ზედმეტმა ხმაურმა შეიძლება სასარგებლო ჩანაწერები დამალოს.
ყველგან ერთნაირია დონეების სახელები?
არა. ბიბლიოთეკები და პლატფორმები განსხვავდება; აღწერეთ თქვენი მნიშვნელობები და შესაბამისობის წესები.