🥇Жалғыз жаңа релик емес: Датадог пен Ататусқа қарау

SRE/DevOps инженерлерінің ортасында бір күні клиенттің (немесе мониторинг жүйесінің) пайда болуы және «бәрі жоғалды» деп хабарлауы ешкімді таң қалдырмайды: сайт жұмыс істемейді, төлемдер өтпейді, өмір азайып келеді. ... Мұндай жағдайда қанша көмектескіңіз келсе де, қарапайым және түсінікті құралсыз мұны істеу өте қиын болуы мүмкін. Көбінесе мәселе қолданба кодының өзінде жасырылады, оны локализациялау қажет.

Қайғыда да, қуанышта да…

Біз Жаңа Реликке ұзақ және қатты ғашық болдық. Бұл қолданбаның өнімділігін бақылаудың тамаша құралы болды және болып қала береді, сонымен қатар микросервис архитектурасын (оның агентін пайдалана отырып) және т.б. құралдарға мүмкіндік береді. Қызметтің баға саясатындағы өзгерістер болмаса, бәрі тамаша болар еді: ол құны 2013 жыл 3+ есе өсті. Сонымен қатар, өткен жылдан бастап сынақ есептік жазбасын алу үшін жеке менеджермен байланысу қажет, бұл өнімді әлеуетті тұтынушыға ұсынуды қиындатады.

Әдеттегі жағдай: Жаңа реликті «тұрақты негізде» қажет етпейді, олар оны проблемалар басталған кезде ғана есте сақтайды. Бірақ сіз әлі де жүйелі түрде төлеуіңіз керек (бір серверге айына 140 АҚШ доллары) және автоматты түрде масштабталатын бұлттық инфрақұрылымда сомалар айтарлықтай үлкен болады. «Барған сайын төле» опциясы бар болса да, New Relic мүмкіндігін қосу қолданбаны қайта іске қосуды талап етеді, бұл оның барлығы басталған проблемалық жағдайды жоғалтуға әкелуі мүмкін. Жақында New Relic жаңа тарифтік жоспарды енгізді - негіздері, - бұл бір қарағанда Кәсібиге ақылға қонымды балама болып көрінеді... бірақ мұқият тексергеннен кейін кейбір маңызды функциялардың жоқ екені анықталды (атап айтқанда, ол жоқ. Негізгі транзакциялар, Қолданбалар арасындағы бақылау, Бөлінген бақылау).

Нәтижесінде біз арзанырақ балама іздеу туралы ойлана бастадық және біздің таңдауымыз екі қызметке түсті: Datadog және Atatus. Неліктен оларда?

Бәсекелестер туралы

Нарықта басқа шешімдер бар екенін бірден айтайын. Біз тіпті Open Source опцияларын қарастырдық, бірақ әрбір клиенттің өздігінен орналастырылған шешімдерді орналастыру мүмкіндігі жоқ... - бұған қоса, олар қосымша техникалық қызмет көрсетуді қажет етеді. Біз таңдаған жұп ең жақын болып шықты біздің қажеттіліктеріміз:

PHP қосымшаларына кіріктірілген және әзірленген қолдау (біздің клиенттеріміздің стегі өте алуан түрлі, бірақ бұл New Relic-ке балама іздеу контекстінде айқын көшбасшы);
қолжетімді баға (бір хост үшін айына 100 АҚШ долларынан аз);
автоматты аспаптар;
Kubernetes-пен интеграция;
New Relic интерфейсіне ұқсастық айтарлықтай плюс болып табылады (себебі біздің инженерлер оған үйреніп қалған).

Сондықтан, бастапқы іріктеу кезеңінде біз бірнеше басқа танымал шешімдерді алып тастадық, атап айтқанда:

Tideways, AppDynamics және Dynatrace - құны бойынша;
Stackify Ресей Федерациясында бұғатталған және тым аз деректерді көрсетеді.

Мақаланың қалған бөлігі алдымен қарастырылып жатқан шешімдер қысқаша ұсынылатын етіп құрылымдалған, содан кейін мен New Relic-пен әдеттегі өзара әрекеттесуіміз және басқа қызметтерде ұқсас операцияларды орындау тәжірибесі/әсерлері туралы айтатын боламын.

Таңдалған сайыскерлерді таныстыру

туралы Жаңа Relic, бәрі естіген шығар? Бұл қызмет өзінің дамуын 10 жылдан астам уақыт бұрын, 2008 жылы бастады. Біз оны 2012 жылдан бері белсенді түрде қолданып келеміз және PHP, Ruby және Python тілдерінде шын мәнінде көп қосымшаларды біріктіруде еш қиындыққа тап болған жоқпыз, сонымен қатар C# және Go тілдерімен интеграциялау тәжірибеміз де болды. Сервис авторларында қосымшаларды, инфрақұрылымды бақылау, микросервис инфрақұрылымдарын қадағалау шешімдері, пайдаланушы құрылғылары үшін ыңғайлы қосымшалар жасалған және т.б.

Дегенмен, New Relic агенті меншікті протоколдарда жұмыс істейді және OpenTracing-ге қолдау көрсетпейді. Жетілдірілген құралдар Жаңа релик үшін арнайы өңдеулерді қажет етеді. Соңында, Kubernetes қолдауы әлі де эксперименталды.

Оның дамуы 2010 жылы басталды Датог Kubernetes орталарында пайдалану тұрғысынан New Relic-ке қарағанда айтарлықтай қызықты көрінеді. Атап айтқанда, ол NGINX Ingress, журнал жинау, statsd және OpenTracing протоколдарымен интеграцияны қолдайды, бұл пайдаланушы сұрауын аяқталғанға жалғанған сәттен бастап қадағалауға, сондай-ақ осы сұрауға арналған журналдарды табуға мүмкіндік береді (екеуі де веб-сервер жағында). және тұтынушыға).

Datadog қолданбасын пайдаланған кезде оның кейде микросервис картасын қате құрастырғанын және кейбір техникалық кемшіліктерді кездестірдік. Мысалы, ол қызмет түрін қате анықтады (Django-ны кэштеу қызметі деп қателесті) және танымал Predis кітапханасын пайдаланып PHP қолданбасында 500 қатені тудырды.

Атат — ең жас аспап; қызмет 2014 жылы іске қосылды. Оның маркетингтік бюджеті аталған бәсекелестерден анық төмен, ескертулер әлдеқайда сирек кездеседі. Дегенмен, құралдың өзі тек мүмкіндіктері (APM, Браузер мониторингі және т.б.) бойынша ғана емес, сыртқы түрі бойынша да New Relic-ке өте ұқсас.

Маңызды кемшілігі оның тек Node.js және PHP тілдерін қолдайды. Екінші жағынан, ол Datadog-қа қарағанда айтарлықтай жақсырақ жүзеге асырылады. Соңғысынан айырмашылығы, Atatus қолданбалардан кодқа өзгертулер енгізуді немесе қосымша белгілерді қосуды талап етпейді.

Жаңа реликпен қалай жұмыс істейміз

Енді New Relic-ті қалай қолданатынымызды анықтайық. Шешімін қажет ететін мәселе бар делік:

Оны графиктен көру оңай шегу -Оны талдап көрейік. New Relic-те веб-транзакциялар бірден веб-бағдарлама үшін таңдалады, барлық құрамдас бөліктер өнімділік графигінде көрсетіледі, қателік жылдамдығы, сұраныс жылдамдығы панелдері бар... Ең бастысы, осы панельдерден тікелей әртүрлі файлдар арасында жылжуыңызға болады. қолданбаның бөліктері (мысалы, MySQL түймесін басу дерекқор бөліміне әкеледі).

Өйткені қарастырылып отырған мысалда біз белсенділіктің өсуін көреміз PHP, осы диаграмманы басып, автоматты түрде өтіңіз операциялар:

Негізінде MVC үлгісінің контроллері болып табылатын транзакциялар тізімі қазірдің өзінде сұрыпталған Ең көп уақытты қажет етеді, бұл өте ыңғайлы: біз қолданбаның не істейтінін бірден көреміз. Мұнда New Relic автоматты түрде жинайтын ұзақ сұраулардың мысалдары берілген. Сұрыптауды ауыстыру арқылы табу оңай:

ең көп жүктелген қолданба контроллері;
жиі сұралатын контроллер;
контроллерлердің ең баяуы.

Сонымен қатар, сіз әрбір транзакцияны кеңейтіп, код орындалған кезде қолданбаның не істеп жатқанын көре аласыз:

Соңында, қолданба ұзақ сұраулар іздерінің мысалдарын сақтайды (2 секундтан көп уақыт алатындар). Міне, ұзақ транзакцияға арналған панель:

Екі әдіс көп уақытты қажет ететінін көруге болады, сонымен қатар сұраныс орындалған уақытта оның URI және домені де көрсетіледі. Көбінесе бұл журналдардан сұрауды табуға көмектеседі. Бару Мәліметтерді қадағалаңыз, сіз бұл әдістердің қайдан шақырылғанын көре аласыз:

Және Мәліметтер қорының сұраулары — қолданба жұмыс істеп тұрған кезде орындалған мәліметтер қорына сұраныстарды бағалау:

Осы біліммен қаруланған біз қолданбаның неліктен баяулап жатқанын бағалай аламыз және мәселені шешу стратегиясын жасау үшін әзірлеушімен жұмыс істей аламыз. Шындығында, New Relic әрқашан нақты суретті бермейді, бірақ ол тергеу векторын таңдауға көмектеседі:

ұзақ PDO::Construct бізді pgpoll-ның оғаш жұмыс істеуіне әкелді;
уақыт бойынша тұрақсыздық Memcache::Get виртуалды машинаның дұрыс конфигурацияланбағанын ұсынды;
шаблонды өңдеуге күдікті түрде ұлғайған уақыт объект қоймасында 500 аватардың болуын тексеретін кірістірілген циклге әкелді;
тағыда басқа…

Сондай-ақ, кодты орындаудың орнына негізгі экранда сыртқы деректерді сақтауға қатысты нәрсе өседі - және оның қандай болатыны маңызды емес: Redis немесе PostgreSQL - олардың барлығы қойындыда жасырылған. Мәліметтер базасы.

Зерттеу және сұрыптау сұраулары үшін арнайы базаны таңдауға болады – ол транзакциялардағы орындалатындай. Сұрау қойындысына өту арқылы сіз бұл сұраудың қолданба контроллерінің әрқайсысында қанша рет болатынын көре аласыз, сондай-ақ оның қаншалықты жиі шақырылатынын бағалай аласыз. Бұл өте ыңғайлы:

Қойындыда ұқсас деректер бар Сыртқы қызметтер, ол сыртқы HTTP қызметтеріне сұрауларды жасырады, мысалы, нысан қоймасына қатынасу, оқиғаларды күзетшіге жіберу немесе т.б. Қойындының мазмұны дерекқорларға толығымен ұқсас:

Бәсекелестер: мүмкіндіктер мен әсерлер

Енді ең қызықтысы - New Relic мүмкіндіктерін бәсекелестер ұсынатын нәрселермен салыстыру. Өкінішке орай, біз өндірісте жұмыс істейтін бір қолданбаның бір нұсқасында барлық үш құралды сынақтан өткізе алмадық. Дегенмен, біз мүмкіндігінше бірдей жағдайларды/конфигурацияларды салыстыруға тырыстық.

1.Datadog

Datadog бізді қызметтер қабырғасы бар панельмен қарсы алады:

Ол қолданбаларды компоненттерге/микросервистерге бөлуге тырысады, сондықтан Django қолданбасының мысалында PostgreSQL-ге 2 қосылымды көреміз (defaultdb и postgres), сондай-ақ балдыркөк, Редис. Datadog бағдарламасымен жұмыс істеу MVC принциптері туралы ең аз біліміңізді талап етеді: пайдаланушы сұраулары әдетте қайдан келетінін түсінуіңіз керек. Бұл әдетте көмектеседі қызметтер картасы:

Айтпақшы, Жаңа реликте ұқсас нәрсе бар:

... және олардың картасы, менің ойымша, қарапайым және түсінікті етіп жасалған: ол бір қолданбаның құрамдастарын көрсетпейді (бұл оны Datadog жағдайындағыдай тым егжей-тегжейлі етеді), тек нақты қызметтерді немесе микросервистерді көрсетеді.

Datadog-қа оралайық: сервистік картадан пайдаланушы сұрауларының Django-ға келетінін көреміз. Django қызметіне барайық және соңында не күткенімізді көрейік:

Өкінішке орай, әдепкі бойынша мұнда график жоқ Веб транзакция уақыты, негізгі New Relic панелінде көретінімізге ұқсас. Дегенмен, оны кестенің орнына конфигурациялауға болады жұмсалған уақыттың %. Оған ауысу жеткілікті Түр бойынша сұраудың орташа уақыты... ал қазір таныс график бізге қарап тұр!

Неліктен Datadog басқа диаграмманы таңдағаны біз үшін жұмбақ. Тағы бір ренжітетін нәрсе - жүйе пайдаланушының таңдауын есте сақтамайды (екі бәсекелестен айырмашылығы), сондықтан жалғыз шешім - пайдаланушы панельдерін жасау.

Бірақ мен Datadog-тың осы графиктерден қатысты серверлердің көрсеткіштеріне ауысу, журналдарды оқу және веб-сервер өңдеушілеріне (Gunicorn) жүктемені бағалау мүмкіндігіне риза болдым. Барлығы New Relic-тегідей дерлік... және одан да көп (бөренелер)!

Графиктердің астында New Relic-ке толығымен ұқсас транзакциялар берілген:

Datadog бағдарламасында транзакциялар шақырылады ресурстар. Контроллерлерді сұраулар саны, орташа жауап беру уақыты және таңдалған уақыт кезеңіне жұмсалған ең көп уақыт бойынша сұрыптауға болады.

Сіз ресурсты кеңейтіп, Жаңа реликте біз байқағанның бәрін көре аласыз:

Ресурста статистикалық мәліметтер, ішкі қоңыраулардың жалпыланған тізімі және жауап коды бойынша сұрыптауға болатын сұраулардың мысалдары бар... Айтпақшы, бұл сұрыптау біздің инженерлерге өте ұнады.

Datadog ішіндегі кез келген мысал ресурсын ашуға және зерттеуге болады:

Сұраныс параметрлері, әрбір құрамдасқа жұмсалған уақыттың жиынтық диаграммасы және қоңыраулар реттілігін көрсететін сарқырама диаграммасы ұсынылған. Сондай-ақ сарқырама диаграммасының ағаш көрінісіне ауысуға болады:

Ең қызығы, сұрау орындалған хосттың жүктемесін көру және сұрау журналдарын қарау.

Керемет интеграция!

Қойындылар қай жерде екенін сұрай аласыз Мәліметтер базасы и Сыртқы қызметтер, Жаңа реликтегідей. Мұнда ешқайсысы жоқ: Datadog қолданбаны компоненттерге ыдырататындықтан, PostgreSQL қарастырылады. бөлек қызмет, және Сыртқы қызметтердің орнына оны іздеу керек aws.storage (ол қолданба қол жеткізе алатын кез келген басқа сыртқы қызмет үшін ұқсас болады).

Мұнда мысал келтірілген postgres:

Негізінде біз қалағанның бәрі бар:

Сұраныс қай «қызметтен» келгенін көре аласыз.

Datadog NGINX Ingress бағдарламасымен тамаша біріктірілгенін және кластерге сұрау келген сәттен бастап соңына дейін бақылауды орындауға мүмкіндік беретінін, сонымен қатар статистикалық көрсеткіштерді алуға, журналдарды және хост көрсеткіштерін жинауға мүмкіндік беретінін еске салу орынсыз болар еді. .

Datadog-тың үлкен плюс - бұл оның бағасы қалыптасуда инфрақұрылым мониторингінен, APM, Log Management және Synthetics тестінен, яғни. Сіз өзіңіздің жоспарыңызды икемді түрде таңдай аласыз.

2.Ата

Ататус командасы олардың қызметі «Жаңа реликпен бірдей, бірақ жақсырақ» деп мәлімдейді. Бұл шынымен рас па, көрейік.

Негізгі панель ұқсас көрінеді, бірақ қолданбада пайдаланылған Redis және memcached анықтау мүмкін болмады.

APM әдепкі бойынша барлық транзакцияларды таңдайды, дегенмен әдетте тек веб-транзакциялар қажет. Datadog сияқты, негізгі панельден қажетті қызметке өту мүмкіндігі жоқ. Оның үстіне транзакциялар қателерден кейін тізімделеді, бұл APM үшін өте қисынды болып көрінбейді.

Ататус транзакцияларында барлығы New Relic-ке барынша ұқсас. Кемшілігі - әрбір контроллер үшін динамика бірден көрінбейді. Оны сұрыптау арқылы контроллер кестесінен іздеу керек Ең көп жұмсалатын уақыт:

Контроллерлердің әдеттегі тізімі қойындыда қол жетімді зерттеу:

Кейбір жолдармен бұл кесте Datadog-ты еске түсіреді және маған New Relic-тегі ұқсас кестеге қарағанда жақсырақ ұнайды.

Әрбір транзакцияны кеңейтіп, қолданба не істеп жатқанын көре аласыз:

Панель де Datadog-ты еске түсіреді: бірқатар сұраныстар, қоңыраулардың жалпы суреті бар. Жоғарғы панель қате қойындысын береді HTTP қателері және баяу сұраулардың мысалдары Сеанс іздері:

Егер транзакцияға барсаңыз, сіз іздің мысалын көре аласыз, дерекқорға сұраныстар тізімін ала аласыз және сұрау тақырыптарын көре аласыз. Барлығы New Relic-ке ұқсас:

Жалпы, Ататус егжей-тегжейлі іздерге риза болды - еске салу блогына қоңыраулардың әдеттегі Жаңа реликті жабыстырусыз:

Дегенмен, оған (Новая релик сияқты) ультра жылдам сұрауларды (<5 мс) өшіретін сүзгі жоқ. Екінші жағынан, транзакцияның соңғы жауабын көрсету (сәттілік немесе қате) маған ұнады.

Панель Мәліметтер базасы қолданба жасайтын сыртқы дерекқорларға сұрауларды зерттеуге көмектеседі. Еске сала кетейін, Atatus тек PostgreSQL және MySQL-ті тапты, дегенмен Redis және memcached де жобаға қатысады.

Сұраныстар әдеттегі критерийлер бойынша сұрыпталады: жауап беру жиілігі, орташа жауап беру уақыты және т.б. Мен сондай-ақ ең баяу сұраулары бар қойындыны атап өткім келеді - бұл өте ыңғайлы. Сонымен қатар, PostgreSQL үшін осы қойындыдағы деректер кеңейтімдегі деректермен сәйкес келді pg_stat_statements - тамаша нәтиже!

Қойынды Сыртқы сұраулар Деректер қорымен толығымен бірдей.

қорытындылар

Ұсынылған құралдардың екеуі де APM рөлінде жақсы жұмыс істеді. Олардың кез келгені қажетті минимумды ұсына алады. Алған әсерлерімізді қысқаша былайша тұжырымдауға болады:

Датог

Артықшылықтары:

ыңғайлы тарифтік кесте (APM бір хост үшін 31 АҚШ доллары тұрады);
Python-мен жақсы жұмыс істеді;
OpenTracing-пен біріктіру мүмкіндігі
Kubernetes-пен интеграция;
NGINX Ingress бағдарламасымен интеграция.

Кемшіліктері:

модуль қатесіне (предис) байланысты қолданбаның қолжетімсіз болуына себепші болған жалғыз APM;
әлсіз PHP автоматты аспаптары;
қызметтердің және олардың мақсатының ішінара оғаш анықтамасы.

Атат