🥇Не New Relic'ом одним: погляд на Datadog та Atatus

У середовищі SRE-/DevOps-інженерів нікого не здивуєш, що одного разу з'являється клієнт (або система моніторингу) і повідомляє, що «все зникло»: сайт не працює, оплати не проходять, життя — тлін… Як би не хотілося допомогти у такій ситуації зробити це без простого і зрозумілого інструменту буває дуже складно. Найчастіше проблема прихована в коді самого додатка - потрібно лише її локалізувати.

І в горі, і в радості.

Так склалося, що ми вже дуже давно і дуже полюбили New Relic. Він був і залишається відмінним засобом для моніторингу продуктивності програми, а також дозволяє інструментувати мікросервісну архітектуру (за допомогою свого агента) та багато іншого. І все могло бути чудово, якби не зміни у ціновій політиці сервісу: його вартість з 2013 року зросла в 3+ рази. До того ж, з минулого року для отримання trial-акаунта потрібне спілкування з персональним менеджером, що ускладнює презентацію продукту потенційному замовнику.

Звичайна ситуація: New Relic не потрібен на «постійній основі», про нього згадують лише тоді, коли почалися проблеми. Але платити все одно потрібно регулярно (по 140 USD за сервер за місяць), а в хмарній інфраструктурі, що автоматично масштабується, суми набігають немаленькі. Хоча і є можливість Pay-As-You-Go, але для включення New Relic потрібно перезапустити додаток, що може призвести до втрати тієї проблемної ситуації, заради якої все починалося. Нещодавно New Relic впровадив новий тарифний план Необхідний, - Який на перший погляд виглядає розумною альтернативою Professional ... але при детальному розгляді виявилося, що частина важливих функцій відсутня (зокрема, в ньому немає Key Transactions, Cross Application Tracing, Розподілена трасування).

В результаті ми задумалися про пошук дешевшої альтернативи, і наш вибір припав на два сервіси Datadog та Atatus. Чому саме на них?

Про конкурентів

Відразу зазначу, що на ринку є й інші рішення. Ми навіть розглядали Open Source-варіанти, але не кожен клієнт має вільні потужності для розміщення рішень категорії self-hosted… — до того ж, вони вимагатимуть додаткового обслуговування. Вибрана нами парочка виявилася найближчою до нашим потребам:

вбудована та розвинена підтримка 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, що дозволяє відстежити запит користувача з моменту його підключення до завершення роботи, а також знайти логи за цим запитом (як на стороні веб-сервера, так і на стороні consumer'ів).

При використанні Datadog ми зіткнулися з тим, що він іноді неправильно будував карту мікросервісів і деякими технічними недоліками. Наприклад, він невірно визначав тип сервісу (сприймав Django за сервіс кешування) і викликав 500 помилки в PHP-додатку, що використовує популярну бібліотеку Predis.

Атат - Наймолодший інструмент; сервіс запущено у 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, вже відсортовано за Most time consuming, що дуже зручно: ми відразу бачимо те, чим програма займається. Тут же є приклади довгих запитів, які автоматично збираються New Relic'ом. Перемикаючи сортування, легко знайти:

найнавантаженіший контролер програми;
найчастіше запитуваний контролер;
найповільніший із контролерів.

Крім того, можна розгорнути кожну транзакцію і побачити, чим займався додаток у момент виконання коду:

Нарешті, у додатку зберігаються приклади трейсів довгих запитів (які відпрацьовують понад 2 секунди). Ось панель для довгої транзакції:

Видно, що багато часу займають два методи, а разом з цим показується час, коли був виконаний запит, його URI і домен. Дуже часто це допомагає знайти запит у логах. Перейшовши в Trace detailsможна подивитися, звідки викликаються ці методи:

А Database queries — оцінити запити до баз даних, які виконувалися в момент роботи програми:

Озброївшись цими знаннями, ми можемо оцінити причину уповільнення програми та разом із розробником виробити стратегію вирішення проблеми. Насправді New Relic не завжди дає чітку картину, проте він допомагає вибрати вектор розслідування:

довгий PDO::Construct привів нас до дивного функціонування pgpoll;
нестабільність у часі Memcache::Get підказала про некоректне налаштування віртуальної машини;
час, що підозріло виріс, на обробку шаблону призвело до вкладеного циклу з перевіркою наявності в об'єктному сховищі 500 аватарок;
і так далі…

Ще буває, що замість виконання коду на основному екрані росте щось пов'язане із зовнішнім зберіганням даних — і не важливо, що це буде: Redis або PostgreSQL — всі вони ховаються у вкладці Бази даних.

Можна вибрати конкретну базу для дослідження та провести сортування запитів – аналогічно тому, як це робиться у Transactions. А перейшовши у вкладку запиту, можна побачити, скільки цей запит зустрічається в кожному з контролерів програми, а також оцінити, як часто він викликається. Це дуже зручно:

Аналогічні дані містить вкладка Зовнішні послуги, яка приховує запити до зовнішніх HTTP-сервісів, такі як звернення до об'єктного сховища, відправка подій в sentry тощо. За своїм наповненням вкладка повністю аналогічна Databases:

Конкуренти: можливості та враження

Тепер найцікавіше порівняти можливості New Relic з тим, що пропонують конкуренти. На жаль, нам не вдалося перевірити всі три інструменти на одній версії одного працюючого в production програми. Проте ми постаралися порівняти максимально ідентичні ситуації/конфігурації.

1. Датадог

Datadog зустрічає нас панеллю зі стіною сервісів:

Він намагається розбити програми на компоненти/мікросервіси, тому у наведеного в прикладі програми Django ми побачимо 2 підключення до PostgreSQL (defaultdb и postgres), а також Celery, Redis. Робота з Datadog вимагає від вас мінімальних знань принципів MVC: потрібно розуміти, куди взагалі приходять запити користувачів. Зазвичай у цьому допомагає карта сервісів:

До речі, щось схоже є і в New Relic:

... причому їхня карта, на мій погляд, зроблена простіше і зрозуміліше: вона відображає не компоненти однієї програми (що зробило б її надмірно докладною, як у Datadog), а тільки конкретні сервіси або мікросервіси.

Повернемося до Datadog: з карти сервісів видно, що запити користувачів надходять до Django. Перейдемо в сервіс Django і побачимо те, що очікували:

На жаль, за замовчуванням тут немає графіка Web transaction time, аналогічного тому, що бачимо на головній панелі New Relic Однак його можна налаштувати на місці графіка % of Time spent. Достатньо переключити його в Avg time per request by Type… І ось уже знайомий графік дивиться на нас!

Чому Datadog віддали перевагу іншому графіку — нам загадка. Засмутило ще й те, що система не запам'ятовує вибір користувача (на відміну від обох конкурентів), а тому — рятує тільки створення панелей користувача.

Зате потішила можливість Datadog перейти з цих графіків на метрики пов'язаних серверів, прочитати логи і оцінити завантаження обробників веб-сервера (Gunicorn). Все майже як у New Relic ... і навіть трохи більше (логи)!

Нижче графіків розміщуються транзакції, повністю аналогічні New Relic:

У Datadog транзакції називаються ресурсами. Можна відсортувати контролери за кількістю запитів, за середнім часом відповіді, за максимальним витраченим часом за вибраний проміжок часу.

Ресурс можна розгорнути та побачити все те, що ми вже спостерігали у New Relic:

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

Будь-який приклад ресурсу в Datadog можна розкрити та вивчити:

Наведені параметри запиту, зведена діаграма за витраченим часом на кожен із компонентів та діаграма-водоспад, в якій видно послідовність викликів. А також доступне перемикання на деревоподібний вид діаграми-водоспаду:

І найцікавіше — перегляд завантаження хоста, на якому було виконано запит, та перегляд логів запиту.

Чудова інтеграція!

Може виникнути питання, де вкладки Бази даних и Зовнішні послуги, як у New Relic. Тут їх немає: оскільки Datadog розбирає додаток на компоненти, PostgreSQL вважатиметься окремим сервісом, а замість External Services варто шукати aws.storage (Аналогічно буде і для кожного іншого зовнішнього сервісу, до якого може звертатися додаток).

А ось приклад з postgres:

По суті є все те, що ми хотіли:

Видно, з якого сервісу прийшов запит.

Datadog відмінно інтегрується з NGINX Ingress і дозволяє проводити наскрізне трасування з моменту надходження запиту в кластер, а також дозволяє приймати метрики statsd, збирати логи та метрики хостів.

Величезний плюс Datadog у тому, що його ціна складається з моніторингу інфраструктури, APM, Log Management та Synthetics test, тобто. можна гнучко підібрати план.

2. Atatus

Команда Ататус стверджує, що їхній сервіс — такий, як New Relic, але краще. Подивимося, чи це так насправді.

Заголовна панель дійсно виглядає аналогічно, але визначити використовувані в Redis і memcached не вдалося.

APM за замовчуванням вибирає всі транзакції, хоча, зазвичай, потрібні лише Web. Як і Datadog, немає можливості перейти на потрібний сервіс з основної панелі. Більше того, транзакції перебувають у списку після помилок, що для APM виглядає не дуже логічно.

У транзакціях Atatus все максимально схоже на New Relic. Мінус — одразу не видно динаміки для кожного з контролерів. Її доводиться шукати в таблиці контролерів, сортуючи за Most Time Consumed:

Звичний нам список контролерів доступний у вкладці Дивитись:

Чимось дана таблиця нагадує 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 - відмінний результат!

Вкладка External Requests повністю ідентична Databases.

Висновки

Обидва представлені інструменти непогано показали себе в ролі APM. Кожен із них може запропонувати необхідний мінімум. Коротко узагальнити наші враження можна так:

Собака даних

Плюси:

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

Мінуси:

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

Атат