მარტო არა ახალი რელიქვია: შეხედე დათადოგსა და ატატუსს

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

და მწუხარებაში და სიხარულში…

მოხდა ისე, რომ ჩვენ დიდი ხანია და ღრმად შევიყვარეთ New Relic. ეს იყო და რჩება შესანიშნავ ინსტრუმენტად აპლიკაციის მუშაობის მონიტორინგისთვის და ასევე საშუალებას გაძლევთ დააინსტალიროთ მიკროსერვისის არქიტექტურა (მისი აგენტის გამოყენებით) და ბევრი, ბევრად მეტი. და ყველაფერი შეიძლებოდა მშვენიერი ყოფილიყო, რომ არა სერვისის ფასების პოლიტიკაში ცვლილებები: ეს დაჯდა დან 2013 წლის გაიზარდა 3+ ჯერ. გარდა ამისა, გასული წლიდან საცდელი ანგარიშის მოპოვება მოითხოვს პერსონალურ მენეჯერთან კომუნიკაციას, რაც ართულებს პროდუქტის პოტენციურ მომხმარებელს წარდგენას.

ჩვეული სიტუაცია: ახალი რელიქვია არ არის საჭირო „მუდმივ საფუძველზე“ მათ ახსოვთ მხოლოდ იმ მომენტში, როდესაც პრობლემები იწყება. მაგრამ თქვენ მაინც უნდა გადაიხადოთ რეგულარულად (თვეში 140 აშშ დოლარი თითო სერვერზე), ხოლო ავტომატურად მასშტაბურ ღრუბლოვან ინფრასტრუქტურაში თანხები საკმაოდ დიდია. მიუხედავად იმისა, რომ არსებობს Pay-As-You-Go ვარიანტი, New Relic-ის ჩართვა მოგიწევთ აპლიკაციის გადატვირთვას, რამაც შეიძლება გამოიწვიოს პრობლემური სიტუაციის დაკარგვა, რისთვისაც ეს ყველაფერი დაიწყო. ცოტა ხნის წინ, New Relic-მა შემოიტანა ახალი სატარიფო გეგმა - საფუძვლები, - რომელიც ერთი შეხედვით Professional-ის გონივრულ ალტერნატივად გამოიყურება... მაგრამ უფრო დეტალური შემოწმების შედეგად აღმოჩნდა, რომ რამდენიმე მნიშვნელოვანი ფუნქცია აკლია (კერძოდ, მას არ გააჩნია ძირითადი ტრანზაქციები, ჯვარედინი განაცხადის კვალიფიკაცია, განაწილებული ტრასინგი).

შედეგად დავიწყეთ იაფი ალტერნატივის ძიებაზე ფიქრი და ჩვენი არჩევანი ორ სერვისზე დაეცა: Datadog და Atatus. რატომ მათზე?

კონკურენტების შესახებ

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

• ჩაშენებული და განვითარებული მხარდაჭერა PHP აპლიკაციებისთვის (ჩვენი კლიენტების დასტა ძალიან მრავალფეროვანია, მაგრამ ეს აშკარა ლიდერია New Relic-ის ალტერნატივის ძიების კონტექსტში);
• ხელმისაწვდომი ღირებულება (თვეში 100 აშშ დოლარზე ნაკლები თითო მასპინძელზე);
• ავტომატური აპარატურა;
• კუბერნეტებთან ინტეგრაცია;
• New Relic ინტერფეისის მსგავსება შესამჩნევი პლუსია (რადგან ჩვენი ინჟინრები შეჩვეულები არიან).

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

• Tideways, AppDynamics და Dynatrace - ღირებულებით;
• Stackify დაბლოკილია რუსეთის ფედერაციაში და აჩვენებს ძალიან მცირე მონაცემებს.

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

შერჩეული კონკურსანტების პრეზენტაცია

on new Relic, ალბათ ყველას გსმენიათ? ამ სერვისმა განვითარება დაიწყო 10 წელზე მეტი ხნის წინ, 2008 წელს. ჩვენ მას აქტიურად ვიყენებთ 2012 წლიდან და არ გვქონია პრობლემა PHP-ში, Ruby-სა და Python-ში მართლაც დიდი რაოდენობის აპლიკაციების ინტეგრირებისას და ასევე გვქონდა C#-თან და Go-სთან ინტეგრაციის გამოცდილება. სერვისის ავტორებს აქვთ გადაწყვეტილებები აპლიკაციების მონიტორინგისთვის, ინფრასტრუქტურის, მიკროსერვისის ინფრასტრუქტურის მოკვლევისთვის, მომხმარებლის მოწყობილობებისთვის მოსახერხებელი აპლიკაციების შესაქმნელად და მრავალი სხვა.

თუმცა, New Relic აგენტი მუშაობს საკუთრების პროტოკოლებზე და არ უჭერს მხარს OpenTracing. გაფართოებული ინსტრუმენტაცია საჭიროებს რედაქტირებას სპეციალურად New Relic-ისთვის. და ბოლოს, Kubernetes მხარდაჭერა ჯერ კიდევ ექსპერიმენტულია.

მისი განვითარება 2010 წელს დაიწყო მონაცემთადაგი საგრძნობლად უფრო საინტერესო გამოიყურება ვიდრე New Relic ზუსტად Kubernetes-ის გარემოში გამოყენების თვალსაზრისით. კერძოდ, ის მხარს უჭერს ინტეგრაციას NGINX Ingress, ჟურნალის შეგროვება, statsd და OpenTracing პროტოკოლებთან, რაც საშუალებას გაძლევთ თვალყური ადევნოთ მომხმარებლის მოთხოვნას დაკავშირების მომენტიდან დასრულებამდე, ასევე იპოვოთ ჟურნალები ამ მოთხოვნისთვის (როგორც ვებ სერვერის მხარეს. და მომხმარებელზე).

Datadog-ის გამოყენებისას შევხვდით, რომ ის ზოგჯერ არასწორად აშენებდა მიკროსერვისის რუკას და ტექნიკურ ხარვეზებს. მაგალითად, მან არასწორად გამოავლინა სერვისის ტიპი (შეცდომით შეცდა Django ქეშირების სერვისში) და გამოიწვია 500 შეცდომა PHP აპლიკაციაში პოპულარული Predis ბიბლიოთეკის გამოყენებით.

ატატუსი - ყველაზე ახალგაზრდა ინსტრუმენტი; სერვისი 2014 წელს დაიწყო. მისი მარკეტინგული ბიუჯეტი აშკარად ჩამოუვარდება ჩამოთვლილ კონკურენტებს, ხსენებები გაცილებით ნაკლებად გავრცელებულია. თუმცა, თავად ინსტრუმენტი ძალიან ჰგავს New Relic-ს, არა მხოლოდ მისი შესაძლებლობებით (APM, ბრაუზერის მონიტორინგი და ა.შ.), არამედ გარეგნულადაც.

მნიშვნელოვანი ნაკლი ის არის, რომ ის მხარს უჭერს მხოლოდ Node.js და PHP. მეორეს მხრივ, ის შესამჩნევად უკეთესად არის დანერგილი, ვიდრე Datadog. ამ უკანასკნელისგან განსხვავებით, Atatus არ მოითხოვს აპლიკაციებს ცვლილებების შეტანას ან კოდში დამატებითი ეტიკეტების დამატებას.

როგორ ვმუშაობთ New Relic-თან

ახლა მოდით გაერკვნენ, თუ როგორ ვიყენებთ ზოგადად New Relic-ს. ვთქვათ, გვაქვს პრობლემა, რომელსაც გადაწყვეტა სჭირდება:

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

ვინაიდან განსახილველ მაგალითში ჩვენ ვხედავთ აქტივობის ზრდას PHPდააწკაპუნეთ ამ დიაგრამაზე და ავტომატურად გადადით გარიგებები:

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

• ყველაზე დატვირთული აპლიკაციის კონტროლერი;
• ყველაზე ხშირად მოთხოვნადი კონტროლერი;
• ყველაზე ნელი კონტროლერებიდან.

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

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

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

ხოლო მონაცემთა ბაზის მოთხოვნები — შეაფასეთ მოთხოვნები მონაცემთა ბაზებზე, რომლებიც შესრულდა აპლიკაციის მუშაობის დროს:

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

• გრძელი PDO::Construct მიგვიყვანა pgpoll-ის უცნაურ ფუნქციონირებამდე;
• დროთა განმავლობაში არასტაბილურობა Memcache::Get ვარაუდობენ, რომ ვირტუალური მანქანა არასწორად იყო კონფიგურირებული;
• შაბლონის დამუშავების საეჭვოდ გაზრდილმა დრომ გამოიწვია წყობილი მარყუჟი, რომელიც ამოწმებდა 500 ავატარის არსებობას ობიექტების საცავში;
• და ა.შ.

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

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

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

კონკურენტები: შესაძლებლობები და შთაბეჭდილებები

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

1. დათადოგი

Datadog გვესალმება პანელით სერვისების კედლით:

ის ცდილობს აპლიკაციების კომპონენტებად/მიკროსერვისებად დაყოფას, ასე რომ, Django აპლიკაციის მაგალითში ვნახავთ 2 კავშირს PostgreSQL-თან (defaultdb и postgres), ასევე ნიახური, რედისი. Datadog-თან მუშაობა მოითხოვს MVC პრინციპების მინიმალურ ცოდნას: თქვენ უნდა გესმოდეთ, საიდან მოდის ზოგადად მომხმარებლის მოთხოვნები. ეს ჩვეულებრივ ეხმარება სერვისების რუკა:

სხვათა შორის, მსგავსი რამ არის New Relic-ში:

... და მათი რუკა, ჩემი აზრით, უფრო მარტივი და გასაგები ხდება: მასში არ არის ნაჩვენები ერთი აპლიკაციის კომპონენტები (რაც მას ზედმეტად დეტალურად გახდის, როგორც Datadog-ის შემთხვევაში), არამედ მხოლოდ კონკრეტულ სერვისებს ან მიკროსერვისებს.

მოდით დავუბრუნდეთ Datadog-ს: სერვისის რუქიდან ვხედავთ, რომ მომხმარებლის მოთხოვნები მოდის Django-ში. მოდით გადავიდეთ Django სერვისზე და საბოლოოდ ვნახოთ რას ველოდით:

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

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

მაგრამ მე კმაყოფილი ვიყავი Datadog-ში ამ გრაფიკებიდან გადასვლის უნარით, დაკავშირებული სერვერების მეტრიკაზე, წავიკითხე ჟურნალები და შევაფასო დატვირთვა ვებ სერვერის დამმუშავებლებზე (Gunicorn). ყველაფერი თითქმის იგივეა, რაც New Relic-ში... და კიდევ ცოტა მეტი (ლოგი)!

გრაფიკების ქვემოთ მოცემულია ტრანზაქციები სრულიად მსგავსი New Relic:

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

შეგიძლიათ გააფართოვოთ რესურსი და ნახოთ ყველაფერი, რაც უკვე დავაკვირდით New Relic-ში:

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

Datadog-ში ნებისმიერი მაგალითის რესურსის გახსნა და შესწავლა შესაძლებელია:

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

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

დიდი ინტეგრაცია!

შეიძლება გაინტერესებთ სად არის ჩანართები მონაცემთა ბაზა и გარე სერვისები, როგორც ახალ რელიქტში. აქ არცერთი არ არის: ვინაიდან Datadog ანაწილებს აპლიკაციას კომპონენტებად, განიხილება PostgreSQL ცალკე სერვისი, და გარე სერვისების ნაცვლად ღირს ძებნა aws.storage (ის მსგავსი იქნება ყველა სხვა გარე სერვისისთვის, რომელზეც აპლიკაციას შეუძლია წვდომა).

აი მაგალითად postgres:

არსებითად არის ყველაფერი რაც გვინდოდა:

თქვენ ხედავთ, რომელი „სერვისიდან“ მოვიდა მოთხოვნა.

არ იქნება უხერხული შეგახსენოთ, რომ Datadog სრულყოფილად ინტეგრირდება NGINX Ingress-თან და საშუალებას გაძლევთ განახორციელოთ ბოლომდე მიკვლევა კლასტერში მოთხოვნის ჩამოსვლის მომენტიდან, ასევე გაძლევთ საშუალებას მიიღოთ statsd მეტრიკა, შეაგროვოთ ჟურნალები და ჰოსტის მეტრიკა. .

Datadog-ის უზარმაზარი პლუსია მისი ფასი ვითარდება ინფრასტრუქტურის მონიტორინგიდან, APM, Log Management და Synthetics ტესტიდან, ე.ი. თქვენ შეგიძლიათ აირჩიოთ თქვენი გეგმა მოქნილად.

2.ატატუსი

Atatus-ის გუნდი ამტკიცებს, რომ მათი მომსახურება "იგივეა, რაც New Relic, მაგრამ უკეთესი". ვნახოთ, მართლა ასეა თუ არა ეს.

მთავარი პანელი ნამდვილად ჰგავს, მაგრამ შეუძლებელი იყო განაცხადში გამოყენებული Redis და memcached-ის დადგენა.

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

Atatus-ის ტრანზაქციებში ყველაფერი მაქსიმალურად ჰგავს New Relic-ს. მინუსი ის არის, რომ თითოეული კონტროლერის დინამიკა დაუყოვნებლივ არ ჩანს. თქვენ უნდა მოძებნოთ ის კონტროლერის ცხრილში, დახარისხება ყველაზე მეტად მოხმარებული დრო:

კონტროლერების ჩვეულებრივი სია ხელმისაწვდომია ჩანართში მეტის ნახვა:

გარკვეულწილად, ეს ცხრილი მოგვაგონებს Datadog-ს და მე ის უფრო მომწონს, ვიდრე New Relic-ის მსგავსი.

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

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

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

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

თუმცა, მას აკლია ფილტრი, რომელიც (როგორც New Relic) შეწყვეტს ულტრა სწრაფ მოთხოვნებს (<5 ms). მეორეს მხრივ, მომეწონა საბოლოო გარიგების პასუხის ჩვენება (წარმატება ან შეცდომა).

პანელი მონაცემთა ბაზა დაგეხმარებათ შეისწავლოთ მოთხოვნები გარე მონაცემთა ბაზებზე, რომლებსაც აპლიკაცია აკეთებს. შეგახსენებთ, რომ Atatus იპოვა მხოლოდ PostgreSQL და MySQL, თუმცა Redis და memcached ასევე ჩართულია პროექტში.

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

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

დასკვნები

ორივე წარმოდგენილი ინსტრუმენტი კარგად ასრულებდა APM-ის როლს. ნებისმიერ მათგანს შეუძლია შესთავაზოს საჭირო მინიმუმი. ჩვენი შთაბეჭდილებები შეიძლება მოკლედ ჩამოვაყალიბოთ შემდეგნაირად:

მონაცემთადაგი

დადებითი:

• მოსახერხებელი სატარიფო განრიგი (APM ღირს 31 აშშ დოლარი თითო ჰოსტზე);
• კარგად მუშაობდა პითონთან;
• OpenTracing-თან ინტეგრაციის შესაძლებლობა
• კუბერნეტებთან ინტეგრაცია;
• ინტეგრაცია NGINX Ingress-თან.

Cons:

• ერთადერთი APM, რომელმაც განაპირობა აპლიკაციის მიუწვდომლობა მოდულის შეცდომის გამო (predis);
• სუსტი PHP ავტომატური ინსტრუმენტაცია;
• სერვისების ნაწილობრივ უცნაური განმარტება და მათი მიზანი.

ატატუსი

დადებითი:

• ღრმა PHP ინსტრუმენტაცია;
• მომხმარებლის ინტერფეისი New Relic-ის მსგავსი.

Cons:

• არ მუშაობს ძველ ოპერაციულ სისტემებზე (Ubuntu 12.05, CentOS 5);
• სუსტი ავტოინსტრუმენტაცია;
• მხოლოდ ორი ენის მხარდაჭერა (Node.js და PHP);
• ნელი ინტერფეისი.

თუ გავითვალისწინებთ Atatus-ის 69 აშშ დოლარს თვეში სერვერზე, ჩვენ უფრო მეტად გამოვიყენებთ Datadog-ს, რომელიც კარგად აერთიანებს ჩვენს საჭიროებებს (ვებ აპლიკაციები K8-ში) და აქვს მრავალი სასარგებლო ფუნქცია.

PS

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

• «ინსტრუმენტები Kubernetes-ზე გაშვებული აპლიკაციების დეველოპერებისთვის";
• «kubectl-debug დანამატი Kubernetes pods-ში გამართვისთვის";
• «მიკროსერვისები: ზომა მნიშვნელოვანია, მაშინაც კი, თუ თქვენ გაქვთ Kubernetes".

წყარო: www.habr.com