SRE/DevOps ինժեներների միջավայրում ոչ ոքի չի զարմացնի, որ մի օր հաճախորդը (կամ մոնիտորինգի համակարգը) հայտնվում է և հայտնում, որ «ամեն ինչ կորած է». կայքը չի աշխատում, վճարումները չեն կատարվում, կյանքը քայքայվում է։ ... Անկախ նրանից, թե որքան կցանկանայիք օգնել նման իրավիճակում, դա անելը առանց պարզ և հասկանալի գործիքի կարող է շատ դժվար լինել: Հաճախ խնդիրը թաքնված է հենց հավելվածի կոդում, պարզապես անհրաժեշտ է այն տեղայնացնել:
Եվ վշտի և ուրախության մեջ…
Այնպես եղավ, որ մենք վաղուց և խորապես սիրահարվել ենք New Relic-ին: Այն եղել և մնում է հիանալի գործիք հավելվածի կատարողականը վերահսկելու համար, ինչպես նաև թույլ է տալիս գործիքավորել միկրոսերվիսային ճարտարապետությունը (օգտագործելով իր գործակալը) և շատ ու շատ ավելին: Եվ ամեն ինչ կարող էր հիանալի լինել, եթե չլինեին ծառայության գնային քաղաքականության փոփոխությունները արժենալ աճել է 3+ անգամ. Բացի այդ, անցյալ տարվանից փորձնական հաշիվ ձեռք բերելու համար անհրաժեշտ է շփում անձնական մենեջերի հետ, ինչը դժվարացնում է ապրանքը պոտենցիալ հաճախորդին ներկայացնելը։
Սովորական իրավիճակ. Նոր մասունքը «մշտական հիմունքներով» պետք չէ, այն հիշում են միայն այն պահին, երբ սկսվում են խնդիրները։ Բայց դուք դեռ պետք է կանոնավոր վճարեք (ամսական 140 ԱՄՆ դոլար մեկ սերվերի համար), իսկ ավտոմատ կերպով մեծացող ամպային ենթակառուցվածքում գումարները բավականին մեծ են: Թեև կա Pay-As-You-Go տարբերակ, New Relic-ի ակտիվացման համար կպահանջվի վերագործարկել հավելվածը, ինչը կարող է հանգեցնել խնդրահարույց իրավիճակի կորստի, որի համար ամեն ինչ սկսվել է: Ոչ վաղ անցյալում New Relic-ը ներկայացրեց նոր սակագնային պլան. , — который на первый взгляд выглядит разумной альтернативой Professional… но при детальном рассмотрении оказалось, что часть важных функций отсутствует (в частности, в нём нет Հիմնական գործարքներ, Cross Application Tracing, Բաշխված հետագծում).
Արդյունքում մենք սկսեցինք մտածել ավելի էժան այլընտրանք փնտրելու մասին, և մեր ընտրությունը կանգ առավ երկու ծառայության վրա՝ Datadog և Atatus: Ինչու՞ նրանց վրա:
Մրցակիցների մասին
Միանգամից ասեմ, որ շուկայում այլ լուծումներ կան։ Մենք նույնիսկ հաշվի ենք առել բաց կոդով տարբերակները, բայց ոչ բոլոր հաճախորդներն ունեն ինքնակառավարվող լուծումներ հյուրընկալելու անվճար հնարավորություն... - բացի այդ, դրանք լրացուցիչ սպասարկում են պահանջում: Մեր ընտրած զույգը պարզվեց, որ ամենամտերիմն էր մեր կարիքները:
- PHP հավելվածների համար ներկառուցված և զարգացած աջակցություն (մեր հաճախորդների փաթեթը շատ բազմազան է, բայց սա ակնհայտ առաջատար է New Relic-ին այլընտրանք փնտրելու համատեքստում);
- մատչելի արժեք (ամսական 100 ԱՄՆ դոլարից պակաս մեկ հյուրընկալողի համար);
- ավտոմատ գործիքավորում;
- ինտեգրում 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 արձանագրությունների հետ, ինչը թույլ է տալիս հետևել օգտվողի հարցումին այն միանալու պահից մինչև ավարտը, ինչպես նաև գտնել այս հարցման տեղեկամատյանները (երկուսն էլ վեբ սերվերի կողմից: և սպառողի վրա):
Datadog-ն օգտագործելիս հանդիպեցինք, որ այն երբեմն սխալ է կառուցել միկրոսերվիսի քարտեզը և որոշ տեխնիկական թերություններ: Օրինակ, այն սխալ ճանաչեց ծառայության տեսակը (Django-ն շփոթեց քեշավորման ծառայության հետ) և 500 սխալ առաջացրեց PHP հավելվածում, որն օգտագործում էր հանրաճանաչ Predis գրադարանը:
- ամենաերիտասարդ գործիքը; ծառայությունը գործարկվել է 2014թ. Նրա մարքեթինգային բյուջեն ակնհայտորեն զիջում է թվարկված մրցակիցներին, հիշատակումները շատ ավելի քիչ են տարածված: Այնուամենայնիվ, գործիքն ինքնին շատ նման է New Relic-ին ոչ միայն իր հնարավորություններով (APM, Browser-ի մոնիտորինգ և այլն), այլ նաև արտաքին տեսքով:
Էական թերությունն այն է, որ այն աջակցում է միայն Node.js-ին և PHP-ին։ Մյուս կողմից, այն իրականացվում է նկատելիորեն ավելի լավ, քան Datadog-ը։ Ի տարբերություն վերջինիս, Atatus-ը չի պահանջում հավելվածներից փոփոխություններ կատարել կամ կոդի վրա հավելյալ պիտակներ ավելացնել։
Ինչպես ենք մենք աշխատում New Relic-ի հետ
Հիմա եկեք պարզենք, թե ինչպես ենք մենք ընդհանուր առմամբ օգտագործում 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-приложения мы увидим 2 подключения к PostgreSQL (defaultdb и postgres), а также Celery, Redis. Работа с Datadog требует от вас минимальных знаний принципов MVC: необходимо понимать, куда вообще приходят запросы пользователей. Обычно в этом помогает ծառայությունների քարտեզ:
Ի դեպ, New Relic-ում նման բան կա.
… причем их карта, на мой взгляд, сделана проще и понятнее: она отображает не компоненты одного приложения (что сделало бы её излишне подробной, как в случае Datadog), а только конкретные сервисы или микросервисы.
Եկեք վերադառնանք Datadog-ին. ծառայության քարտեզից մենք կարող ենք տեսնել, որ օգտվողների հարցումները գալիս են Django: Եկեք գնանք Django ծառայությանը և վերջապես տեսնենք, թե ինչ էինք սպասում.
К сожалению, по умолчанию тут нет графика Վեբ գործարքի ժամանակը, նման է այն, ինչ մենք տեսնում ենք հիմնական New Relic վահանակում: Այնուամենայնիվ, այն կարող է կազմաձևվել ժամանակացույցի փոխարեն Ծախսված ժամանակի %. Բավական է միացնել այն Avg time per request by Type... և այժմ ծանոթ գրաֆիկը նայում է մեզ:
Ինչու Datadog-ն այլ աղյուսակ ընտրեց, մեզ համար առեղծված է: Մեկ այլ հիասթափեցնող բան այն է, որ համակարգը չի հիշում օգտագործողի ընտրությունը (ի տարբերություն երկու մրցակիցների), և, հետևաբար, միակ լուծումը հարմարեցված վահանակներ ստեղծելն է:
Բայց ես գոհ էի Datadog-ի կարողությունից՝ անցնելու այս գրաֆիկներից հարակից սերվերների չափանիշներին, կարդալ տեղեկամատյանները և գնահատել վեբ սերվերի մշակողների (Gunicorn) բեռը: Ամեն ինչ գրեթե նույնն է, ինչ New Relic-ում... և նույնիսկ մի փոքր ավելին (տեղեկամատյաններ)!
Գրաֆիկների ներքևում ներկայացված են գործարքներ, որոնք ամբողջովին նման են New Relic-ին.
Datadog-ում գործարքները կոչվում են ռեսուրսներ. Կարգավորիչները կարող եք տեսակավորել ըստ հարցումների քանակի, արձագանքման միջին ժամանակի և ընտրված ժամանակահատվածի համար ծախսված առավելագույն ժամանակի:
Դուք կարող եք ընդլայնել ռեսուրսը և տեսնել այն ամենը, ինչ մենք արդեն նկատել ենք New Relic-ում.
Կան ռեսուրսի վերաբերյալ վիճակագրություն, ներքին զանգերի ընդհանրացված ցանկ և հարցումների օրինակներ, որոնք կարելի է տեսակավորել ըստ պատասխանի կոդի... Ի դեպ, մեր ինժեներներին շատ դուր եկավ այս տեսակավորումը։
Datadog-ի ցանկացած օրինակելի ռեսուրս կարելի է բացել և ուսումնասիրել.
Ներկայացված են հարցումի պարամետրերը, յուրաքանչյուր բաղադրիչի վրա ծախսված ժամանակի ամփոփ աղյուսակը և զանգերի հաջորդականությունը ցուցադրող ջրվեժի աղյուսակը: Կարող եք նաև անցնել ջրվեժի գծապատկերի ծառի տեսքին.
И самое интересное — просмотр загрузки хоста, на котором был исполнен запрос, и просмотр логов запроса.
Մեծ ինտեգրում!
Դուք կարող եք մտածել, թե որտեղ են ներդիրները Սայլակ и Արտաքին ծառայություններ, как в New Relic. Здесь их нет: поскольку Datadog разбирает приложение на компоненты, PostgreSQL будет считаться առանձին ծառայություն, և արտաքին ծառայությունների փոխարեն արժե փնտրել aws.storage (аналогично будет и для каждого другого внешнего сервиса, к которому может обращаться приложение).
Ահա մի օրինակ հետ postgres:
Ըստ էության, կա այն ամենը, ինչ մենք ուզում էինք.
Դուք կարող եք տեսնել, թե որ «ծառայությունից» է ստացվել հարցումը:
Не будет лишним напомнить, что Datadog отлично интегрируется с NGINX Ingress и позволяет производить сквозную трассировку с момента поступления запроса в кластер, а также позволяет принимать метрики statsd, собирать логи и метрики хостов.
Огромный плюс Datadog в том, что его цена զարգանում է ենթակառուցվածքի մոնիտորինգից, APM-ից, Log Management-ից և Synthetics թեստից, այսինքն. Դուք կարող եք ճկուն կերպով ընտրել ձեր պլանը:
2.Ատատուս
Команда Ататус утверждает, что их сервис — «такой же, как New Relic, но лучше». Посмотрим, так ли это на самом деле.
Հիմնական վահանակն իսկապես նման է, բայց հնարավոր չեղավ որոշել հավելվածում օգտագործվող Redis-ը և memcached-ը:
APM-ը լռելյայն ընտրում է բոլոր գործարքները, թեև սովորաբար միայն համացանցային գործարքներ են անհրաժեշտ: Ինչպես Datadog-ը, այնպես էլ հիմնական վահանակից դեպի ցանկալի ծառայություն անցնելու միջոց չկա: Ավելին, գործարքները թվարկվում են սխալներից հետո, ինչը APM-ի համար այնքան էլ տրամաբանական չի թվում։
Atatus-ի գործարքներում ամեն ինչ հնարավորինս նման է New Relic-ին: Բացասական կողմն այն է, որ յուրաքանչյուր վերահսկիչի դինամիկան անմիջապես տեսանելի չէ: Դուք պետք է որոնեք այն կարգավորիչի աղյուսակում՝ դասակարգելով ըստ Առավել սպառված ժամանակը:
Կարգավորիչների սովորական ցուցակը հասանելի է ներդիրում ուսումնասիրել:
Որոշ առումներով այս աղյուսակը հիշեցնում է Datadog-ը և ինձ այն ավելի շատ է դուր գալիս, քան New Relic-ի նմանատիպը:
Դուք կարող եք ընդլայնել յուրաքանչյուր գործարք և տեսնել, թե ինչ էր անում հավելվածը.
Վահանակը նույնպես ավելի շատ հիշեցնում է Datadog-ը՝ կան մի շարք հարցումներ, զանգերի ընդհանուր պատկեր։ Վերին վահանակը ապահովում է սխալի ներդիր HTTP-ի ձախողումներ և դանդաղ հարցումների օրինակներ Նիստի հետքեր:
Если перейти в транзакцию, виден пример трейса, можно получить список запросов к базе и посмотреть заголовки запроса. Всё аналогично New Relic:
Ընդհանուր առմամբ, Ատատուսը գոհ է մանրամասն հետքերից՝ առանց հիշեցումների բլոկի մեջ զանգերի բնորոշ Նոր մասունքի սոսնձման.
Այնուամենայնիվ, այն չունի զտիչ, որը (ինչպես New Relic) կկտրի ծայրահեղ արագ հարցումները (<5 ms): Մյուս կողմից, ինձ դուր եկավ վերջնական գործարքի պատասխանի ցուցադրումը (հաջողություն կամ սխալ):
Վահանակ Սայլակ կօգնի ձեզ ուսումնասիրել արտաքին տվյալների շտեմարանների հարցումները, որոնք կատարում է հավելվածը: Հիշեցնեմ, որ Atatus-ը գտել է միայն PostgreSQL-ն ու MySQL-ը, չնայած Redis-ն ու memcached-ը նույնպես ներգրավված են նախագծում։
Запросы сортируются по привычным критериям: частота срабатывания, среднее время ответа и так далее. Отдельно хочется отметить вкладку с самыми медленными запросами — это очень удобно. Более того, данные в этой вкладке для PostgreSQL совпали с данными от расширения - գերազանց արդյունք!
Ներդիր Արտաքին հարցումներ լիովին նույնական է տվյալների շտեմարաններին:
Արդյունքները
Ներկայացված երկու գործիքներն էլ լավ հանդես եկան APM-ի դերում: Նրանցից ցանկացածը կարող է առաջարկել պահանջվող նվազագույնը: Մեր տպավորությունները հակիրճ կարելի է ամփոփել հետևյալ կերպ.
Տվյալներիդոգ
Կոալիցիայում:
- հարմարավետ սակագնային գրաֆիկ (APM-ն արժե 31 ԱՄՆ դոլար մեկ հյուրընկալողի համար);
- լավ աշխատել Python-ի հետ;
- OpenTracing-ի հետ ինտեգրվելու հնարավորություն
- ինտեգրում Kubernetes-ի հետ;
- ինտեգրում NGINX Ingress-ի հետ:
Դեմ:
- միակ APM-ը, որի պատճառով հավելվածն անհասանելի է դարձել մոդուլի սխալի պատճառով (predis);
- թույլ PHP ավտոմատ գործիքավորում;
- Ծառայությունների և դրանց նպատակի մասամբ տարօրինակ սահմանումը:
Atatus
Կոալիցիայում:
- խորը PHP գործիքավորում;
- Օգտվողի միջերեսը նման է New Relic-ին:
Դեմ:
- չի աշխատում հին օպերացիոն համակարգերի վրա (Ubuntu 12.05, CentOS 5);
- слабая автоинструментация;
- աջակցություն միայն երկու լեզուների համար (Node.js և PHP);
- Դանդաղ ինտերֆեյս:
Հաշվի առնելով Atatus-ի գինը՝ ամսական 69 ԱՄՆ դոլար մեկ սերվերի համար, մենք կնախընտրեինք օգտագործել Datadog-ը, որը լավ է ինտեգրվում մեր կարիքներին (վեբ հավելվածներ K8-ում) և ունի բազմաթիվ օգտակար հատկություններ:
PS
Կարդացեք նաև մեր բլոգում.
- «";
- «";
- «.
Source: www.habr.com