Не само New Relic: ​​поглед към Datadog и Atatus

В средата на инженерите на SRE/DevOps няма да изненада никого, че един ден клиент (или система за наблюдение) се появява и съобщава, че „всичко е загубено“: сайтът не работи, плащанията не преминават, животът се разпада ... Колкото и да искате да помогнете в такава ситуация, може да бъде много трудно да направите това без прост и разбираем инструмент. Често проблемът се крие в самия код на приложението, просто трябва да го локализирате.

И в скръб и в радост...

Така се случи, че отдавна и дълбоко се влюбихме в New Relic. Той беше и остава отличен инструмент за наблюдение на производителността на приложенията, а също така ви позволява да инструментирате архитектурата на микросервизите (използвайки нейния агент) и много, много повече. И всичко можеше да е страхотно, ако не бяха промените в ценовата политика на услугата: тя цена от 2013 година нарасна 3+ пъти. Освен това от миналата година получаването на пробен акаунт изисква комуникация с личен мениджър, което затруднява представянето на продукта на потенциален клиент.

Обичайната ситуация: Нова реликва не е необходима на „постоянна основа“, те я помнят само в момента, в който започнат проблемите. Но все още трябва да плащате редовно (140 USD на сървър на месец), а в автоматично мащабираща се облачна инфраструктура сумите са доста големи. Въпреки че има опция Pay-As-You-Go, активирането на New Relic ще изисква от вас да рестартирате приложението, което може да доведе до загуба на проблемната ситуация, за която е стартирано. Неотдавна New Relic представи нов тарифен план - Essentials, - което на пръв поглед изглежда като разумна алтернатива на Professional... но при по-внимателно разглеждане се оказа, че някои важни функции липсват (по-специално, той няма Ключови транзакции, Кръстосано проследяване на приложения, Разпределено проследяване).

В резултат на това започнахме да мислим да търсим по-евтина алтернатива и изборът ни падна върху две услуги: Datadog и Atatus. Защо на тях?

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

Веднага да кажа, че на пазара има и други решения. Ние дори обмисляхме опции с отворен код, но не всеки клиент има свободен капацитет за хостване на самостоятелно хоствани решения... - освен това те ще изискват допълнителна поддръжка. Двойката, която избрахме, се оказа най-близка нашите нужди:

• вградена и разработена поддръжка за PHP приложения (стекът на нашите клиенти е много разнообразен, но това е ясен лидер в контекста на търсене на алтернатива на New Relic);
• достъпна цена (по-малко от 100 USD на месец на хост);
• автоматична апаратура;
• интеграция с 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 - всички те са скрити в раздела Данни.

Можете да изберете конкретна база за проучване и сортиране на заявки - подобно на начина, по който се прави в Transactions. И като отидете в раздела за заявки, можете да видите колко пъти се появява тази заявка във всеки от контролерите на приложения, както и да прецените колко често се извиква. Много е удобно:

Разделът съдържа подобни данни Външни услуги, който скрива заявки към външни HTTP услуги, като достъп до хранилище на обекти, изпращане на събития към часовия или други подобни. Съдържанието на раздела е напълно подобно на Бази данни:

Конкуренти: възможности и впечатления

Сега най-интересното е да сравним възможностите на New Relic с това, което предлагат конкурентите. За съжаление, не успяхме да тестваме и трите инструмента на една версия на едно приложение, работещо в производствена среда. Въпреки това се опитахме да сравним ситуации/конфигурации, които бяха възможно най-идентични.

1.Datadog

Datadog ни посреща с панел със стена от услуги:

Опитва се да раздели приложенията на компоненти/микроуслуги, така че в примера за приложение на Django ще видим 2 връзки към PostgreSQL (defaultdb и postgres), както и целина, Redis. Работата с Datadog изисква да имате минимални познания за принципите на MVC: трябва да разберете откъде обикновено идват потребителските заявки. Това обикновено помага карта на услугите:

Между другото, има нещо подобно в New Relic:

... и тяхната карта според мен е направена по-опростена и по-ясна: не показва компонентите на едно приложение (което би го направило прекалено подробно, както в случая с Datadog), а само конкретни услуги или микроуслуги.

Да се ​​върнем към Datadog: от картата на услугата можем да видим, че потребителските заявки идват към Django. Нека отидем на услугата 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:

Като цяло Atatus е доволен от подробни следи - без типичното залепване на обаждания в New Relic в блок за напомняне:

Липсва обаче филтър, който (като New Relic) би отрязал ултра-бързи заявки (<5ms). От друга страна ми хареса показването на крайния отговор на транзакцията (успех или грешка).

панел Данни ще ви помогне да проучите заявките към външни бази данни, които приложението прави. Нека ви напомня, че Atatus намери само PostgreSQL и MySQL, въпреки че Redis и memcached също участват в проекта.

Заявките се сортират според обичайните критерии: честота на отговор, средно време за отговор и т.н. Бих искал също да спомена раздела с най-бавните заявки - това е много удобно. Освен това данните в този раздел за PostgreSQL съвпадаха с данните от разширението pg_stat_statements - отличен резултат!

Раздел Външни заявки напълно идентичен с базите данни.

Данни

И двата представени инструмента се представиха добре в ролята на APM. Всеки от тях може да предложи необходимия минимум. Нашите впечатления могат да бъдат обобщени накратко, както следва:

Куче за данни

плюсове:

• удобен тарифен график (APM струва 31 USD на хост);
• работи добре с Python;
• Възможност за интеграция с OpenTracing
• интеграция с Kubernetes;
• интеграция с NGINX Ingress.

против:

• единственият APM, който е накарал приложението да стане недостъпно поради грешка в модула (predis);
• слаба PHP авто-инструментация;
• отчасти странно определение на услугите и тяхната цел.

Ататус

плюсове:

• дълбоко инструментиране на PHP;
• потребителски интерфейс, подобен на New Relic.

против:

• не работи на по-стари операционни системи (Ubuntu 12.05, CentOS 5);
• слаба автоинструментация;
• поддръжка само на два езика (Node.js и PHP);
• Бавен интерфейс.

Имайки предвид цената на Atatus от 69 USD на месец на сървър, бихме предпочели да използваме Datadog, който се интегрира добре с нашите нужди (уеб приложения в K8s) и има много полезни функции.

PS

Прочетете също в нашия блог:

• «Инструменти за разработчици на приложения, работещи на Kubernetes»;
• «kubectl-debug плъгин за отстраняване на грешки в Kubernetes pods»;
• «Микроуслуги: Размерът има значение, дори ако имате Kubernetes".

Източник: www.habr.com