დოკუმენტაცია

შეცდომების თვალყური

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

დაყენება

შექმენით პროექტი დაფაზე და დააკოპირეთ მისი DSN. შემდეგ მიმართეთ მასზე თქვენი არსებული SDK:

Sentry.init({
  dsn: "https://<key>@vitrinaengine.com/ingest/<project>",
});

ეს არის მთელი ინტეგრაცია. მუშაობს ნებისმიერი Sentry SDK — JavaScript, Python, Ruby, Go, PHP, .NET — რადგან ეს სწორედ მათი ქსელური პროტოკოლია და არა მისი მსგავსი რამ.

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

როგორ იქცევა შეცდომები issue-ებად

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

Issue, რომელიც მოაგვარეთ და რომელიც ისევ განმეორდა, ხელახლა იხსნება როგორც რეგრესია და გატყობინებთ, ნაცვლად იმისა, რომ ჩუმად დაამატოს კიდევ ერთი შემთხვევა დახურულ issue-ს.

Source map-ები

ატვირთეთ რელიზის map-ები და მინიფიცირებული ბრაუზერის სტეკი წასაკითხი გახდება. ატვირთეთ ისინი თქვენი ბილდიდან API-ით — იხილეთ API-ის ცნობარი.

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

ინციდენტზე მიმაგრებული შეცდომები

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

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

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

ლოგები თქვენი სერვერებიდან და ქსელიდან

Business-ისა და უფრო მაღალ გეგმებზე პროექტი იღებს იმ ლოგებსაც, რომლებსაც თქვენი მანქანები ისედაც წერენ: syslog Linux-იდან და Cisco-სა და Juniper-ის აღჭურვილობიდან, Windows-ის მოვლენების ჟურნალი და macOS-ის ერთიანი ჟურნალი. მიმართეთ უკვე გამოყენებული ლოგების გამგზავნი თქვენი პროექტის ლოგების ენდპოინტზე, რომელიც პროექტის გვერდზეა მითითებული DSN-ის გვერდით. თავად მანქანებზე დასაყენებელი არაფერია.

ინახება მხოლოდ შეცდომები. syslog-ის დონეები err-ზე დაბლა, Windows-ის დონეები Error-ზე დაბლა და ყველაფერი, რასაც macOS-ის ჟურნალი Default-ს ან უფრო ჩუმს უწოდებს, უქმდება დათვლამდე და ანგარიშში ჩართვამდე — ჯანმრთელი ჰოსტი არაფერს გიჯდებათ, ხოლო გაფრთხილებები, რომელთა გამოც არავის გამოიძახებდნენ, არ ავსებს თქვენს პრობლემების სიას.

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

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

კვოტები

თითოეულ გეგმას აქვს მოვლენების თვიური ლიმიტი — 5000 Free-ზე, 50 000 Starter-ზე, 250 000 Pro-ზე, 1 000 000 Business-ზე. მიღება ასევე შეზღუდულია სიხშირით თითო პროექტზე, და სწორედ ეს ხდება სინამდვილეში: გამეორების ციკლში მოხვედრილი გამონაკლისი სხვა შემთხვევაში წუთებში წვავს თვიურ კვოტას.

ცალკეული მოვლენები ინახება თქვენი გეგმის შეცდომების შენახვის ვადით — შვიდი დღე Free-ზე, ოცდაათი Starter-ზე, სამოცი Pro-ზე, ოთხმოცდაათი Business-ზე. მათგან აგებული issue-ები მოვლენებს გადარჩება: მათი მრიცხველები და პირველი და ბოლო ნახვა რჩება იმდენ ხანს, რამდენსაც თქვენი გეგმის ისტორიის შენახვა.

რას არ ვაკეთებთ

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