company_banner

Не New Relic’ом одним: взгляд на Datadog и Atatus



    В среде SRE-/DevOps-инженеров никого не удивишь, что однажды появляется клиент (или система мониторинга) и сообщает, что «всё пропало»: сайт не работает, оплаты не проходят, жизнь — тлен… Как бы ни хотелось помочь в такой ситуации, сделать это без простого и понятного инструмента бывает очень сложно. Зачастую проблема скрыта в коде самого приложения — нужно лишь локализовать её.

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


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

    Обычная ситуация: New Relic не нужен на «постоянной основе», о нём вспоминают только в тот момент, когда начались проблемы. Но платить-то всё равно нужно регулярно (по 140 USD за сервер за месяц), а в автоматически масштабирующейся облачной инфраструктуре суммы набегают немаленькие. Хотя и есть возможность «Pay-As-You-Go», но для включения New Relic потребуется перезапустить приложение, что может привести к потере той проблемной ситуации, ради которой всё затевалось. Не так давно New Relic внедрил новый тарифный план — Essentials, — который на первый взгляд выглядит разумной альтернативой Professional… но при детальном рассмотрении оказалось, что часть важных функций отсутствует (в частности, в нём нет Key Transactions, Cross Application Tracing, Distributed Tracing).

    В результате мы задумались о поиске более дешевой альтернативы, и наш выбор пал на два сервиса Datadog и Atatus. Почему именно на них?

    О конкурентах


    Сразу оговорюсь, что на рынке присутствуют и другие решения. Мы даже рассматривали Open Source-варианты, но не у каждого клиента есть свободные мощности для размещения решений категории 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, что позволяет отследить пользовательский запрос с момента его подключения до завершения работы, а также найти логи по этому запросу (как на стороне веб-сервера, так и на стороне consumer’ов).

    При использовании 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, уже отсортирован по Most time consuming, что очень удобно: мы сразу видим то, чем приложение занимается. Здесь же в наличии примеры долгих запросов, которые автоматически собираются New Relic’ом. Переключая сортировку, легко найти:

    • самый нагруженный контроллер приложения;
    • самый часто запрашиваемый контроллер;
    • самый медленный из контроллеров.

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



    Наконец, в приложении сохраняются примеры трейсов долгих запросов (которые отрабатывают более 2 секунд). Вот панель для долгой транзакции:



    Видно, что много времени занимают два метода, а вместе с этим показывается и время, когда был исполнен запрос, его URI и домен. Очень часто это помогает найти запрос в логах. Перейдя в Trace details, можно посмотреть, откуда вызываются эти методы:



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



    Вооружившись этими знаниями, мы можем оценить причину замедления приложения и вместе с разработчиком выработать стратегию решения проблемы. В реальности New Relic не всегда даёт чёткую картину, однако он помогает выбрать вектор расследования:

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

    Ещё бывает, что вместо исполнения кода на основном экране растёт что-то связанное с внешним хранением данных — и не важно, что это будет: Redis или PostgreSQL, — все они прячутся во вкладке Databases.



    Можно выбрать конкретную базу для исследования и провести сортировку запросов — аналогично тому, как это делается в Transactions. А перейдя во вкладку запроса, можно увидеть, сколько этот запрос встречается в каждом из контроллеров приложения, а также оценить, как часто он вызывается. Это очень удобно:



    Аналогичные данные содержит вкладка External Services, которая скрывает в себе запросы к внешним HTTP-сервисам, такие как обращение к объектному хранилищу, отправка событий в sentry или тому подобное. По своему наполнению вкладка полностью аналогична Databases:



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


    Теперь самое интересное — сравним возможности New Relic с тем, что предлагают конкуренты. К сожалению, нам не удалось проверить все три инструмента на одной версии одного работающего в production приложения. Тем не менее, мы постарались сравнить максимально идентичные ситуации/конфигурации.

    1. Datadog


    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 можно раскрыть и изучить:



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



    И самое интересное — просмотр загрузки хоста, на котором был исполнен запрос, и просмотр логов запроса.



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

    Может возникнуть вопрос, где вкладки Databases и External Services, как в 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:



    Привычный нам список контроллеров доступен во вкладке Explore:



    Чем-то данная таблица напоминает Datadog и нравится больше аналогичной в New Relic.

    Каждую транзакцию можно развернуть и посмотреть, чем занималось приложение:



    Панель тоже скорее напоминает Datadog: есть количество запросов, общая картина вызовов. Верхняя панель предоставляет вкладку с ошибками HTTP Failures и примеры медленных запросов Session Traces:



    Если перейти в транзакцию, виден пример трейса, можно получить список запросов к базе и посмотреть заголовки запроса. Всё аналогично New Relic:



    Вообще, Atatus порадовал подробными трейсами — без типичных для New Relic склеиваний вызовов в reminder-блок:




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

    Панель Databases поможет изучить запросы к внешним базам, которые делает приложение. Напомню, Atatus нашел только PostgreSQL и MySQL, хотя в проекте задействованы ещё Redis и memcached.



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



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

    Выводы


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

    Datadog


    Плюсы:

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

    Минусы:

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

    Atatus


    Плюсы:

    • глубокая инструментация PHP;
    • cхожий с New Relic пользовательский интерфейс.

    Минусы:

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

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

    P.S.


    Читайте также в нашем блоге:

    Флант
    774,21
    Специалисты по DevOps и Kubernetes
    Поделиться публикацией

    Комментарии 10

      +1
      Azure AppInsight не рассматривали?
        +1
        Звучит так, что это только для Azure? Тогда по определению нам не подходит: очень разные провайдеры используются у клиентов. В начале указано требование про Kubernetes — так вот он развернут и в Google, и в AWS, и в Azure, и даже бывает bare metal.
          0
          Он не только для Azure :)
            0
            Но я в любом случае не вижу у него ничего про PHP, который для нас был первичен…
              +1
              У них есть SDK для PHP, но без официальной поддержки. Насколько он актуален — не уверен, с PHP не работал.
                0
                Про актуальность хороший вопрос, потому что коммиты выглядят так, будто бы с прошлого октября ничего не происходит :|
        0
        ELASTIC APM не пробовали в бою?
          0
          Не пробовали, но очень хотелось бы. Сейчас мы смотрим в сторону Jaeger + prometheus exporter к нему. Это частично закроет наши потребности к APM без установки дополнительного софта в наших кластерах. Вдохновение брали вот отсюда.

          К сожалению стек ES+Kibana бывает очень требователен к ресурсам, которые у клиентов есть не всегда. Иногда дешевле платить за облако, нежели иметь self-hosted решение.
          +1

          Спасибо за обзор, триггернули старую болячку — фантомная боль на месте слишком дорогого NewRelic) Огорчился, что они усложнили процесс триала, порадовался, что появился план pay-as-you-go.


          А какие self-hosted решения вы рассматривали?

            +1
            Конечно упомянутый выше elastic apm, pinba и Pinpoint. Про Pinpoint уже, кстати писали на habr'e.

            Коротенько напишу обо всех:
            • Pinba — старое решение, но закрывает только php, да и то не очень то хорошо. Хочется универсальный инструмент для go, php, nodejs, python.
            • Pinpoint — пробовал ставить на домашнем стенде. В итоге APM потреблял больше ресурсов, чем инструментируемое приложение.
            • Про elastic apm ответ выше.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое