🥇Не само нова реликвија: поглед на Датадог и Ататус

Во опкружувањето на инженерите на SRE/DevOps, никого нема да изненади што еден ден се појавува клиент (или систем за следење) и известува дека „сè е изгубено“: страницата не работи, плаќањата не поминуваат, животот се распаѓа ... Без разлика колку би сакале да помогнете во таква ситуација, да го направите ова без едноставна и разбирлива алатка може да биде многу тешко. Честопати проблемот е скриен во самиот код на апликацијата, само треба да го локализирате.

И во тага и во радост…

Така се случи што долго и длабоко се заљубивме во New Relic. Беше и останува одлична алатка за следење на перформансите на апликацијата, а исто така ви овозможува да ја инструментирате архитектурата на микросервис (користејќи го нејзиниот агент) и многу, многу повеќе. И сè можеше да биде одлично ако не беа промените во ценовната политика на услугата: тоа чини од 2013 година порасна 3+ пати. Дополнително, од минатата година, за добивање пробна сметка потребна е комуникација со личен менаџер, што го отежнува презентирањето на производот на потенцијален клиент.

Вообичаена ситуација: Нова реликвија не е потребна на „постојана основа“ тие се сеќаваат на неа само во моментот кога ќе започнат проблемите. Но, сепак треба редовно да плаќате (140 американски долари по сервер месечно), а во инфраструктурата на облакот што автоматски се зголемува, сумите се собираат прилично големи. Иако постои опција Pay-As-You-Go, за овозможување на New Relic ќе треба да ја рестартирате апликацијата, што може да доведе до губење на проблематичната ситуација за која се започна. Не така одамна, New Relic воведе нов тарифен план - Најважен, - што на прв поглед изгледа како разумна алтернатива на Professional... но по повнимателно испитување се покажа дека недостасуваат некои важни функции (поточно, нема Клучни трансакции, Вкрстено следење на апликации, Дистрибуирано следење).

Како резултат на тоа, почнавме да размислуваме да бараме поевтина алтернатива, а нашиот избор падна на две услуги: Datadog и Atatus. Зошто на нив?

За конкурентите

Веднаш да кажам дека има и други решенија на пазарот. Ги разгледавме дури и опциите со отворен код, но не секој клиент има слободен капацитет да хостира решенија за самодомаќини... - дополнително, тие ќе бараат дополнително одржување. Парот што го избравме се покажа како најблизок нашите потреби:

вградена и развиена поддршка за PHP апликации (оџакот на нашите клиенти е многу разновиден, но ова е јасен лидер во контекст на барање алтернатива на New Relic);
прифатлива цена (помалку од 100 американски долари месечно по домаќин);
автоматска инструментација;
интеграција со Kubernetes;
Сличноста со интерфејсот New Relic е забележлив плус (бидејќи нашите инженери се навикнати на тоа).

Затоа, во почетната фаза на селекција, елиминиравме неколку други популарни решенија, а особено:

Tideways, AppDynamics и Dynatrace - по цена;
Stackify е блокиран во Руската Федерација и покажува премалку податоци.

Остатокот од статијата е структуриран на тој начин што прво накратко ќе бидат претставени решенијата за кои станува збор, по што ќе зборувам за нашата типична интеракција со 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. Да речеме дека имаме проблем за кој треба да се реши:

Лесно е да се види на графиконот прскање - Ајде да го анализираме. Во 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. Ајде да одиме на услугата Џанго и конечно да видиме што очекувавме:

За жал, овде стандардно нема графикон Време на веб трансакција, слично на она што го гледаме на главниот панел New Relic. Сепак, може да се конфигурира наместо распоредот % од потрошеното време. Доволно е да го префрлите на Просечно време по барање по тип... и сега познатиот график гледа во нас!

Зошто Datadog избра поинаков графикон е мистерија за нас. Друга фрустрирачка работа е тоа што системот не се сеќава на изборот на корисникот (за разлика од двата конкуренти), и затоа единственото решение е да креира сопствени панели.

Но, бев задоволен од можноста во Datadog да се префрлам од овие графикони на метриката на поврзаните сервери, да ги читам дневниците и да го проценам оптоварувањето на управувачите на веб-серверите (Gunicorn). Сè е речиси исто како во New Relic... па дури и малку повеќе (трупци)!

Под графиконите се прикажани трансакции целосно слични на New Relic:

Во Datadog, трансакциите се нарекуваат ресурси. Можете да ги сортирате контролорите според бројот на барања, според просечното време на одговор и според максималното време поминато за одреден временски период.

Можете да го проширите ресурсот и да видите сè што веќе забележавме во New Relic:

Има статистика за ресурсот, генерализирана листа на внатрешни повици и примери на барања кои може да се подредат по код за одговор... Патем, на нашите инженери навистина им се допадна ова сортирање.

Секој примерен ресурс во Datadog може да се отвори и проучува:

Прикажани се параметри за барање, збирна табела на времето поминато на секоја компонента и табела со водопад што ја прикажува низата на повици. Може да се префрлите и на приказ на дрво на табелата со водопади:

И најинтересно е гледање на оптоварувањето на домаќинот на кој е извршено барањето и прегледување на дневниците за барања.

Одлична интеграција!

Можеби се прашувате каде се јазичињата Бази на податоци и Надворешни услуги, како во New Relic. Нема тука: бидејќи 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 во блок за потсетување:

Сепак, му недостига филтер кој (како New Relic) ќе ги прекине ултра брзите барања (<5 ms). Од друга страна, ми се допадна прикажувањето на одговорот на конечната трансакција (успех или грешка).

Панел Бази на податоци ќе ви помогне да ги проучите барањата до надворешни бази на податоци што ги прави апликацијата. Да потсетам дека Atatus ги најде само PostgreSQL и MySQL, иако во проектот се вклучени и Redis и memcached.

Барањата се подредени според вообичаените критериуми: фреквенција на одговор, просечно време на одговор итн. Исто така, би сакал да го спомнам јазичето со најбавните прашања - тоа е многу погодно. Покрај тоа, податоците во ова јазиче за PostgreSQL се совпаднаа со податоците од наставката pg_stat_statements - одличен резултат!

Јазиче Надворешни барања целосно идентично со Базите на податоци.

Наоди

Двете презентирани алатки се покажаа добро во улогата на APM. Секој од нив може да го понуди потребниот минимум. Нашите впечатоци може накратко да се сумираат на следниов начин:

Датадог

Позитивни:

удобен тарифен распоред (АПМ чини 31 УСД по домаќин);
работеше добро со Python;
Можност за интеграција со OpenTracing
интеграција со Kubernetes;
интеграција со NGINX Ingress.

Конс:

единствениот APM што предизвика апликацијата да стане недостапна поради грешка во модулот (predis);
слаба PHP авто-инструментација;
делумно чудна дефиниција на услугите и нивната намена.

Ататус