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

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

И в тъгата, и в радостта...

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

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

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

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

Срещу това, на пазара присъстват и други решения. Ние дори разгледахме варианти с отворен код, но не всеки клиент разполага със свободни ресурси за разположение на решения от категория self-hosted... — допълнително, те ще изискват допълнително обслужване. Избраната от нас двойка се оказа най-близка до нашите нужди:

вградена и развита поддръжка на PHP приложения (стекът на нашите клиенти е много разнообразен, но това е ясен лидер в контекста на търсенето на алтернатива на New Relic);
достъпна цена (по-малко от 100 USD на месец за хостинг);
автоматизирана инструментализация;
интеграция с Kubernetes;
подобие с интерфейса на New Relic — очевидно предимство (защото нашите инженери са свикнали с него).

Следователно, на етапа на първоначален отбор отсяхме няколко други популярни решения, а именно:

Tideways, AppDynamics и Dynatrace — за цената;
Stackify — блокиран в РФ и показва твърде малко данни.

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

Представяне на подбраните конкуренти

Относно New Relic, вероятно е чувал всеки? Тази услуга започна развитието си преди повече от 10 години, през 2008 година. Ние активно я използваме от 2012 година и не сме имали проблеми с интеграцията на наистина голям брой приложения на езиците PHP, Ruby и Python, а също така имаме опит с интеграция на C# и Go. Авторите на услугата предлагат решения за мониторинг на приложения, инфраструктура, трасировка на микросервизни инфраструктури, създадени са удобни приложения за клиентски устройства и много друго.

Обаче агентът на New Relic работи по проприетарни протоколи, няма поддръжка за OpenTracing. За разширена инструментализация е необходимо да се правят корекции специално за New Relic. Накрая, поддръжката на Kubernetes все още има експериментален статус.

Започнал своето развитие през 2010 година Datadog изглежда значително по-интересен от New Relic, особено по отношение на използването в Kubernetes среди. В частност, той поддържа интеграция с NGINX Ingress, събиране на логове, протоколи statsd и OpenTracing, което позволява да се проследи потребителската заявка от момента на свързването до приключването на работата, а също така да се намерят логовете за тази заявка (както на страната на уеб сървъра, така и на страна на потребителите).

При използването на Datadog се сблъскахме с проблема, че понякога неправилно конструираше картата на микросервизите и имаше някои технически недостатъци. Например, той погрешно идентифицираше типа на услугата (възприе де Django като услуга за кеширане) и предизвикваше 500 грешки в PHP приложението, което използва популярната библиотека Predis.

Atatus — най-младият инструмент; услугата стартира през 2014 година. Неговият маркетингов бюджет очевидно изостава от изброените конкуренти, споменаванията се срещат значително по-рядко. Независимо от това, инструментът сам по себе си е много подобен на New Relic, не само в възможностите (APM, Browser monitoring и т.н.), но и във външния вид.

Същественият недостатък е, че поддържа само Node.js и PHP. От друга страна, е реализиран значително по-добре в сравнение с Datadog. За разлика от последния, Atatus не изисква от приложенията допълнителни изменения и обозначаване на код.

Как работим с New Relic

Сега да разгледаме как обикновено използваме New Relic. Да предположим, че имаме проблем, който трябва да решим:

На графика е лесно да се забележи всплеск — ще го анализираме. В New Relic за уеб приложението веднага са избрани уеб транзакции, в графика на производителността са посочени всички компоненти, налични са панели за error-rate, request-rate... Основното е, че директно от тези панели можем да преминаваме между различните части на приложението (например, кликването на MySQL ще ни отведе в секцията с бази данни).

Тъй като в разглеждания пример виждаме увеличение на активността PHP, ще кликнем на този график и автоматично ще преминем в Transactions:

Списъкът с транзакции, които по същество са контролерите от модела MVC, вече е сортиран по Най-времеемките, което е много удобно: веднага виждаме с какво се занимава приложението. Тук също има примери за дълги заявки, които автоматично се събират от New Relic. Като променим сортирането, лесно можем да намерим:

най-натоварения контролер на приложението;
най-често заявявания контролер;
най-бавния от контролерите.

Освен това можем да разгърнем всяка транзакция и да видим с какво е занимавало приложението по време на изпълнението на кода:

Накрая, в приложението се съхраняват примери за trace на дълги заявки (които отнемат повече от 2 секунди). Ето панел за дълга транзакция:

Ясно е, че двата метода заемат много време, а заедно с това се показва и времето, когато е извършен запитването, неговия URI и домейн. Много често това помага да се намери запитването в логовете. Преминавайки в Детайли на трасето, можем да видим откъде се извикват тези методи:

А в Запитвания към базата данни — да оценим запитванията към базите данни, които са изпълнени по време на работа на приложението:

С тези знания можем да оценим причината за забавянето на приложението и заедно с разработчика да разработим стратегия за решаване на проблема. В действителност New Relic не винаги дава ясна картина, но помага да се избере вектор на разследването:

дълго PDO::Construct ни доведе до странно функциониране на pgpoll;
нестабилност във времето Memcache::Get подсказа за неправилна конфигурация на виртуалната машина;
подозрително увеличено време за обработка на шаблона доведе до вложен цикъл с проверка за наличие в обектното хранилище на 500 аватара;
и така нататък…

Случва се също така, че вместо изпълнение на кода на основния екран расте нещо, свързано с външното съхранение на данни — и не е важно какво ще бъде това: Redis или PostgreSQL, — всички те са скрити в раздела Бази данни.

Можете да изберете конкретна база за проучване и да проведете сортиране на запитванията — аналогично на това, което се прави в Транзакции. А като преминете в раздела на запитването, можете да видите колко често тази заявка се среща във всеки от контролерите на приложението и също да оцените колко често се извиква. Това е много удобно:

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

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

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

1. Datadog

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

Той се опитва да раздели приложенията на компоненти/микросервизи, затова в примера с Django приложението ще видим 2 свързвания към PostgreSQL (defaultdb и postgres), както и Celery, 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, управление на логове и синтетични тестове, т.е. можете гъвкаво да подберете план.

2. Atatus

Екипът на Atatus твърди, че услугата им – "е същата като New Relic, но по-добра". Да видим, дали наистина е така.

Заглавната панела наистина изглежда аналогично, но не успяхме да определим как се използват Redis и memcached в приложението.

APM по подразбиране избира всички транзакции, въпреки че обикновено са необходими само Web. Както и в Datadog, няма възможност да се премине към необходимата услуга от основната панела. Освен това, транзакциите са в списъка след грешките, което за APM изглежда не много логично.

В транзакциите при Atatus всичко е максимално близко до New Relic. Минус – веднага не се вижда динамиката за всеки от контролерите. Тя трябва да се търси в таблицата на контролерите, сортирайки по Most Time Consumed:

Познатият ни списък с контролери е достъпен в таба Explore:

По нещо тази таблица напомня на Datadog и е по-добра от аналогичната в New Relic.

Всяка транзакция може да се разгъне и да се види с какво се е занимавало приложението:

Панела също напомня повече на Datadog: има количество запитвания, обща картина на повикванията. Горната панела предлага таб с грешки HTTP Failures и примери за бавни запитвания Session Traces:

Ако преминете в транзакцията, е виден пример на трасето, можете да получите списък с запитванията към базата и да видите заглавките на запитването. Всичко е аналогично на New Relic:

Въобще, Atatus ни зарадва с подробни трасета – без типичните за New Relic обединения на повикванията в reminder-блок:

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

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

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

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

Изводи

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

Datadog

Предимства:

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

Минуси:

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

Atatus

Предимства:

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

Минуси:

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

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