🥇فقط جدید نیست: نگاهی به Datadog و Atatus

در محیط مهندسان SRE/DevOps، هیچ کس تعجب نخواهد کرد که یک روز یک مشتری (یا یک سیستم نظارتی) ظاهر می شود و گزارش می دهد که "همه چیز از بین رفته است": سایت کار نمی کند، پرداخت ها انجام نمی شود، زندگی در حال زوال است. ... مهم نیست که چقدر دوست دارید در چنین شرایطی کمک کنید، انجام این کار بدون یک ابزار ساده و قابل درک می تواند بسیار دشوار باشد. اغلب مشکل در خود کد برنامه پنهان است، فقط باید آن را بومی سازی کنید.

و در غم و شادی…

این اتفاق افتاد که ما مدت ها و عمیقاً عاشق New Relic شده ایم. این یک ابزار عالی برای نظارت بر عملکرد برنامه بود و باقی می ماند، و همچنین به شما امکان می دهد معماری میکروسرویس (با استفاده از عامل آن) و بسیاری موارد دیگر را ابزارسازی کنید. و همه چیز می‌توانست عالی باشد اگر تغییراتی در سیاست قیمت‌گذاری خدمات نبود: آن هزینه از سال 2013 3+ بار رشد کرد. علاوه بر این، از سال گذشته، دریافت اکانت آزمایشی نیاز به ارتباط با یک مدیر شخصی دارد که ارائه محصول به مشتری بالقوه را دشوار می کند.

وضعیت معمول: New Relic به صورت "دائمی" مورد نیاز نیست، آنها آن را فقط در لحظه ای که مشکلات شروع می شود به یاد می آورند. اما شما هنوز باید به طور منظم پرداخت کنید (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 آغاز کرد دیتادوگ دقیقاً از نظر استفاده در محیط های Kubernetes بسیار جالب تر از New Relic است. به طور خاص، از ادغام با پروتکل‌های NGINX Ingress، جمع‌آوری گزارش، statsd و OpenTracing پشتیبانی می‌کند، که به شما امکان می‌دهد درخواست کاربر را از لحظه اتصال تا تکمیل ردیابی کنید، و همچنین گزارش‌هایی را برای این درخواست (هر دو در سمت سرور وب) پیدا کنید. و بر روی مصرف کننده).

هنگام استفاده از Datadog، با این مواجه شدیم که گاهی اوقات نقشه میکروسرویس را اشتباه ساخته است و برخی از کاستی های فنی. به عنوان مثال، نوع سرویس را اشتباه شناسایی کرد (به اشتباه جنگو را با یک سرویس کش اشتباه گرفت) و باعث ایجاد 500 خطا در یک برنامه PHP با استفاده از کتابخانه محبوب Predis شد.

آتاتوس - جوانترین ساز؛ این سرویس در سال 2014 راه اندازی شد. بودجه بازاریابی آن به وضوح از رقبای ذکر شده پایین تر است، ذکرها بسیار کمتر رایج است. با این حال، خود این ابزار نه تنها از نظر قابلیت‌ها (APM، مانیتورینگ مرورگر و غیره)، بلکه از نظر ظاهری نیز بسیار شبیه به New Relic است.

یک اشکال مهم این است که فقط از Node.js و PHP پشتیبانی می کند. از طرف دیگر، به طور قابل توجهی بهتر از Datadog پیاده سازی شده است. برخلاف دومی، Atatus نیازی به برنامه‌های کاربردی برای ایجاد تغییرات یا اضافه کردن برچسب‌های اضافی به کد ندارد.

نحوه کار ما با New Relic

حالا بیایید بفهمیم که چگونه از New Relic استفاده می کنیم. فرض کنید مشکلی داریم که نیاز به راه حل دارد:

دیدن آن در نمودار آسان است چلپ چلوپ - بیایید آن را تجزیه و تحلیل کنیم. در New Relic، تراکنش‌های وب بلافاصله برای یک برنامه وب انتخاب می‌شوند، همه اجزا در نمودار عملکرد نشان داده می‌شوند، پنل‌های نرخ خطا، نرخ درخواست وجود دارد... آنچه که از همه مهمتر این است که مستقیماً از این پانل‌ها می‌توانید بین مختلف حرکت کنید. بخش هایی از برنامه (به عنوان مثال، با کلیک بر روی MySQL به بخش پایگاه داده منتهی می شود).

از آنجایی که در مثال مورد بررسی شاهد افزایش فعالیت هستیم پی اچ پی، روی این نمودار کلیک کنید و به طور خودکار به معاملات:

فهرست تراکنش‌ها، که اساساً کنترل‌کننده‌هایی از مدل MVC هستند، قبلاً بر اساس مرتب‌سازی شده‌اند بیشترین زمان را می گیرد، که بسیار راحت است: ما بلافاصله می بینیم که برنامه چه کاری انجام می دهد. در اینجا نمونه هایی از پرس و جوهای طولانی است که به طور خودکار توسط New Relic جمع آوری می شوند. با تغییر مرتب سازی، پیدا کردن آسان است:

بارگیری ترین کنترلر برنامه؛
اغلب درخواستی ترین کنترلر؛
کندترین کنترلر

علاوه بر این، می توانید هر تراکنش را گسترش دهید و ببینید برنامه در زمان اجرای کد چه کار می کرد:

در نهایت، برنامه نمونه هایی از ردپاهای درخواست های طولانی (آنهایی که بیش از 2 ثانیه طول می کشد) را ذخیره می کند. این پانل برای یک تراکنش طولانی است:

مشاهده می شود که دو روش زمان زیادی می برد و همزمان زمانی که درخواست اجرا شد، URI و دامنه آن نیز نمایش داده می شود. اغلب اوقات این به یافتن درخواست در گزارش ها کمک می کند. قصد دارم به ردیابی جزئیات، می توانید ببینید که این متدها از کجا فراخوانی می شوند:

و در پرس و جوهای پایگاه داده - پرس و جوهای پایگاه داده را که در حین اجرای برنامه اجرا شده اند ارزیابی کنید:

با داشتن این دانش، می‌توانیم دلیل کند شدن برنامه را ارزیابی کنیم و با توسعه‌دهنده همکاری کنیم تا استراتژی حل مشکل را ارائه دهیم. در واقعیت، New Relic همیشه تصویر واضحی ارائه نمی دهد، اما به انتخاب بردار بررسی کمک می کند:

طولانی PDO::Construct ما را به عملکرد عجیب pgpoll سوق داد.
بی ثباتی در طول زمان Memcache::Get پیشنهاد کرد که ماشین مجازی به درستی پیکربندی نشده است.
افزایش مشکوک زمان برای پردازش الگو منجر به یک حلقه تودرتو شد که وجود 500 آواتار را در ذخیره سازی اشیاء بررسی می کند.
و غیره…

همچنین اتفاق می افتد که به جای اجرای کد، چیزی مربوط به ذخیره سازی داده های خارجی در صفحه اصلی رشد می کند - و مهم نیست که چه خواهد بود: Redis یا PostgreSQL - همه آنها در برگه پنهان هستند. پایگاه داده ها.

شما می توانید یک پایگاه خاص را برای تحقیق انتخاب کنید و پرس و جوها را مرتب کنید - مشابه نحوه انجام آن در تراکنش ها. و با رفتن به تب درخواست می توانید مشاهده کنید که این درخواست چند بار در هر یک از کنترلرهای برنامه اتفاق می افتد و همچنین تخمین بزنید که چند بار فراخوانی می شود. خیلی راحته:

برگه حاوی داده های مشابه است خدمات خارجی، که درخواست های سرویس های HTTP خارجی مانند دسترسی به ذخیره سازی اشیا، ارسال رویدادها به نگهبان یا موارد مشابه را پنهان می کند. محتوای برگه کاملاً شبیه پایگاه داده است:

رقبا: فرصت ها و برداشت ها

اکنون جالب ترین چیز مقایسه قابلیت های New Relic با آنچه رقبا ارائه می دهند است. متأسفانه، ما نتوانستیم هر سه ابزار را روی یک نسخه از یک برنامه در حال تولید آزمایش کنیم. با این حال، ما سعی کردیم موقعیت‌ها/پیکربندی‌هایی را که تا حد امکان یکسان بودند، مقایسه کنیم.

1.Datadog

Datadog با پانل با دیواری از خدمات به ما خوش آمد می گوید:

سعی می‌کند برنامه‌ها را به کامپوننت‌ها/میکروسرویس‌ها تقسیم کند، بنابراین در مثال برنامه جنگو ما 2 اتصال به PostgreSQL (defaultdb и postgres) و همچنین کرفس، ردیس. کار با Datadog مستلزم داشتن حداقل دانش از اصول MVC است: باید بدانید که درخواست‌های کاربر عموماً از کجا می‌آیند. این معمولا کمک می کند نقشه خدمات:

به هر حال، چیزی مشابه در New Relic وجود دارد:

... و نقشه آنها، به نظر من، ساده‌تر و واضح‌تر شده است: اجزای یک برنامه کاربردی را نمایش نمی‌دهد (که آن را بیش از حد جزئی می‌کند، همانطور که در مورد Datadog وجود دارد)، بلکه فقط خدمات یا میکروسرویس‌های خاص را نشان می‌دهد.

بیایید به Datadog برگردیم: از نقشه سرویس می توانیم ببینیم که درخواست های کاربر به جنگو می آید. بیایید به سرویس جنگو برویم و در نهایت ببینیم چه انتظاری داشتیم:

متأسفانه، هیچ نموداری در اینجا به طور پیش فرض وجود ندارد زمان تراکنش وب، مشابه چیزی که در پنل اصلی New Relic می بینیم. با این حال، می توان آن را به جای زمان بندی پیکربندی کرد % از زمان صرف شده. کافی است آن را تغییر دهید میانگین زمان هر درخواست بر اساس نوع... و حالا نمودار آشنا به ما نگاه می کند!

اینکه چرا Datadog نمودار متفاوتی را انتخاب کرد برای ما یک راز است. نکته ناامید کننده دیگر این است که سیستم انتخاب کاربر را به خاطر نمی آورد (برخلاف هر دو رقیب) و بنابراین تنها راه حل ایجاد پنل های سفارشی است.

اما من از توانایی Datadog برای تغییر از این نمودارها به معیارهای سرورهای مرتبط، خواندن گزارش‌ها و ارزیابی بار روی سرورهای وب (Gunicorn) راضی بودم. همه چیز تقریباً مانند New Relic است ... و حتی کمی بیشتر (log)!

در زیر نمودارها تراکنش های کاملا مشابه 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 چندان منطقی به نظر نمی رسد.

در تراکنش های آتاتوس، همه چیز تا حد امکان شبیه به New Relic است. نکته منفی این است که پویایی هر کنترل کننده بلافاصله قابل مشاهده نیست. شما باید آن را در جدول کنترلر، مرتب سازی بر اساس جستجو کنید بیشترین زمان مصرف شده:

لیست معمولی کنترلرها در برگه موجود است کاوش:

این جدول از جهاتی یادآور Datadog است و من آن را بهتر از جدول مشابه در New Relic دوست دارم.

می توانید هر تراکنش را گسترش دهید و ببینید برنامه چه کاری انجام می دهد:

این پنل همچنین بیشتر یادآور Datadog است: تعدادی درخواست وجود دارد، یک تصویر کلی از تماس ها. پانل بالایی یک برگه خطا ارائه می دهد خرابی های HTTP و نمونه هایی از پرس و جوهای کند ردیابی جلسه:

اگر به یک تراکنش بروید، می توانید نمونه ای از یک ردیابی را ببینید، می توانید لیستی از درخواست ها را به پایگاه داده دریافت کنید و به سربرگ های درخواست نگاه کنید. همه چیز شبیه New Relic است:

به طور کلی، Atatus از ردیابی های دقیق - بدون چسباندن New Relic معمولی تماس ها به یک بلوک یادآور خوشحال است:

با این حال، فاقد فیلتری است که (مانند New Relic) درخواست های فوق سریع (<5 میلی ثانیه) را قطع کند. از طرفی نمایش پاسخ تراکنش نهایی (موفقیت یا خطا) را دوست داشتم.

پنل پایگاه داده ها به شما کمک می کند تا درخواست های مربوط به پایگاه داده های خارجی را که برنامه ایجاد می کند مطالعه کنید. اجازه دهید یادآوری کنم که Atatus فقط PostgreSQL و MySQL را پیدا کرد، اگرچه Redis و memcached نیز در این پروژه دخیل هستند.

درخواست ها بر اساس معیارهای معمول مرتب می شوند: فراوانی پاسخ، میانگین زمان پاسخ و غیره. من همچنین می خواهم به برگه ای با کندترین پرس و جو اشاره کنم - بسیار راحت است. علاوه بر این، داده‌های موجود در این برگه برای PostgreSQL با داده‌های برنامه افزودنی مطابقت دارد pg_stat_statements - نتیجه عالی!

برگه درخواست های خارجی کاملا مشابه پایگاه های داده

یافته ها

هر دو ابزار ارائه شده به خوبی در نقش APM عمل کردند. هر یک از آنها می تواند حداقل مورد نیاز را ارائه دهد. برداشت های ما را می توان به طور خلاصه به شرح زیر خلاصه کرد:

دیتادوگ

مزایا:

برنامه تعرفه مناسب (هزینه APM 31 USD برای هر میزبان)؛
به خوبی با پایتون کار کرد.
امکان ادغام با OpenTracing
ادغام با Kubernetes؛
ادغام با NGINX Ingress.

منفی:

تنها APM که باعث شد برنامه به دلیل خطای ماژول (predis) در دسترس نباشد.
ابزار دقیق PHP ضعیف.
تعریف تا حدی عجیب از خدمات و هدف آنها

آتاتوس