🥇Не 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.

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, можна паглядзець, адкуль выклікаюцца гэтыя метады:

А ў Запыты да базы дадзеных - ацаніць запыты да баз дадзеных, якія выконваліся ў момант працы прыкладання:

Узброіўшыся гэтымі ведамі, мы можам ацаніць прычыну запаволення прыкладання і разам з распрацоўшчыкам выпрацаваць стратэгію вырашэння праблемы. У рэальнасці 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;
збольшага дзіўнае вызначэнне сэрвісаў і іх прызначэнні.

Atatus