🥇 اکیلے نیا Relic نہیں: Datadog اور Atatus پر ایک نظر

SRE/DevOps انجینئرز کے ماحول میں، یہ کسی کو حیران نہیں کرے گا کہ ایک دن ایک کلائنٹ (یا مانیٹرنگ سسٹم) نمودار ہوتا ہے اور رپورٹ کرتا ہے کہ "سب کچھ کھو گیا ہے": سائٹ کام نہیں کرتی، ادائیگیاں نہیں ہوتیں، زندگی زوال پذیر ہوتی ہے۔ ... اس سے کوئی فرق نہیں پڑتا ہے کہ ایسی صورت حال میں آپ کتنی ہی مدد کرنا چاہیں گے، یہ آسان اور قابل فہم ٹول کے بغیر کرنا بہت مشکل ہو سکتا ہے۔ اکثر مسئلہ ایپلیکیشن کوڈ میں ہی چھپا ہوتا ہے؛ آپ کو بس اسے لوکلائز کرنے کی ضرورت ہوتی ہے۔

اور غم اور خوشی میں...

ایسا ہوا کہ ہم نیو ریلک کے ساتھ طویل اور گہری محبت میں گر گئے ہیں۔ یہ ایپلیکیشن کی کارکردگی کی نگرانی کے لیے ایک بہترین ٹول تھا اور اب بھی ہے، اور یہ آپ کو مائیکرو سروس فن تعمیر (اس کے ایجنٹ کا استعمال کرتے ہوئے) اور بہت کچھ کرنے کی بھی اجازت دیتا ہے۔ اور سب کچھ بہت اچھا ہوسکتا تھا اگر یہ سروس کی قیمتوں کی پالیسی میں تبدیلیوں کے لئے نہ ہوتا: یہ لاگت آئے 2013 سال سے 3+ گنا اضافہ ہوا۔. اس کے علاوہ، پچھلے سال سے، ٹرائل اکاؤنٹ حاصل کرنے کے لیے ذاتی مینیجر کے ساتھ بات چیت کی ضرورت ہوتی ہے، جس کی وجہ سے پروڈکٹ کو ممکنہ کسٹمر کے سامنے پیش کرنا مشکل ہو جاتا ہے۔

معمول کی صورتحال: "مستقل بنیادوں" پر نئے ریلک کی ضرورت نہیں ہے؛ وہ اسے صرف اس وقت یاد رکھتے ہیں جب مسائل شروع ہوتے ہیں۔ لیکن آپ کو اب بھی باقاعدگی سے ادائیگی کرنے کی ضرورت ہے (140 USD فی سرور فی مہینہ)، اور خود بخود اسکیلنگ کلاؤڈ انفراسٹرکچر میں رقم کافی زیادہ بڑھ جاتی ہے۔ اگرچہ پے-ایس-یو-گو آپشن موجود ہے، نیو ریلیک کو فعال کرنے کے لیے آپ کو ایپلیکیشن کو دوبارہ شروع کرنے کی ضرورت ہوگی، جس کی وجہ سے اس مشکل صورتحال کو ختم کرنا پڑ سکتا ہے جس کے لیے یہ سب شروع کیا گیا تھا۔ کچھ عرصہ قبل، نیو ریلک نے ایک نیا ٹیرف پلان متعارف کرایا تھا۔ لوازم, - جو پہلی نظر میں پروفیشنل کے لیے ایک معقول متبادل لگتا ہے... لیکن قریب سے جانچنے پر پتہ چلا کہ کچھ اہم فنکشنز غائب ہیں (خاص طور پر، اس میں نہیں ہے کلیدی لین دین, کراس ایپلیکیشن ٹریسنگ, تقسیم شدہ ٹریسنگ).

نتیجے کے طور پر، ہم نے ایک سستا متبادل تلاش کرنے کے بارے میں سوچنا شروع کیا، اور ہمارا انتخاب دو خدمات پر پڑا: Datadog اور Atatus۔ ان پر کیوں؟

حریفوں کے بارے میں۔

مجھے فوراً کہنے دو کہ مارکیٹ میں اور بھی حل موجود ہیں۔ یہاں تک کہ ہم نے اوپن سورس کے اختیارات پر غور کیا، لیکن ہر کلائنٹ میں خود میزبانی کے حل کی میزبانی کرنے کی مفت صلاحیت نہیں ہے... - اس کے علاوہ، انہیں اضافی دیکھ بھال کی ضرورت ہوگی۔ ہم نے جس جوڑے کا انتخاب کیا وہ سب سے قریب نکلا۔ ہماری ضروریات:

پی ایچ پی ایپلی کیشنز کے لیے بلٹ ان اور تیار کردہ سپورٹ (ہمارے کلائنٹس کا اسٹیک بہت متنوع ہے، لیکن یہ نیو ریلیک کے متبادل کی تلاش کے تناظر میں ایک واضح رہنما ہے)؛
سستی لاگت (فی میزبان فی مہینہ 100 USD سے کم)؛
خودکار آلات؛
Kubernetes کے ساتھ انضمام؛
نیو ریلک انٹرفیس کی مماثلت ایک قابل توجہ پلس ہے (کیونکہ ہمارے انجینئر اس کے عادی ہیں)۔

لہذا، ابتدائی انتخاب کے مرحلے پر، ہم نے کئی دوسرے مقبول حلوں کو ختم کیا، اور خاص طور پر:

Tideways، AppDynamics اور Dynatrace - قیمت کے لیے؛
Stackify روسی فیڈریشن میں مسدود ہے اور بہت کم ڈیٹا دکھاتا ہے۔

باقی مضمون کو اس طرح ترتیب دیا گیا ہے کہ زیر بحث حل پہلے مختصراً پیش کیے جائیں گے، اس کے بعد میں نیو ریلیک کے ساتھ ہمارے عام تعامل اور دیگر خدمات میں اسی طرح کی کارروائیوں کو انجام دینے کے تجربے/ تاثرات کے بارے میں بات کروں گا۔

منتخب حریفوں کی پریزنٹیشن

کے بارے میں نیوزی اوشیش، شاید سب نے سنا ہے؟ اس سروس نے اپنی ترقی کا آغاز 10 سال سے زیادہ پہلے 2008 میں کیا تھا۔ ہم اسے 2012 سے فعال طور پر استعمال کر رہے ہیں اور ہمیں PHP، Ruby اور Python میں ایپلی کیشنز کی ایک بڑی تعداد کو ضم کرنے میں کوئی دشواری نہیں ہوئی ہے، اور ہمیں C# اور Go کے ساتھ انضمام کا تجربہ بھی ہوا ہے۔ سروس کے مصنفین کے پاس مانیٹرنگ ایپلی کیشنز، انفراسٹرکچر، مائیکرو سروس انفراسٹرکچر کا پتہ لگانے، صارف کے آلات کے لیے آسان ایپلی کیشنز بنانے اور بہت کچھ کے حل ہیں۔

تاہم، نیو ریلک ایجنٹ ملکیتی پروٹوکول پر چلتا ہے اور اوپن ٹریسنگ کو سپورٹ نہیں کرتا ہے۔ جدید آلات کے لیے خاص طور پر نیو ریلیک کے لیے ترمیم کی ضرورت ہوتی ہے۔ آخر میں، Kubernetes سپورٹ اب بھی تجرباتی ہے۔

2010 میں اس کی ترقی کا آغاز ہوا۔ ڈیٹاڈوگ Kubernetes ماحول میں استعمال کے لحاظ سے بالکل واضح طور پر New Relic سے زیادہ دلچسپ لگتا ہے۔ خاص طور پر، یہ NGINX Ingress، لاگ کلیکشن، statsd اور OpenTracing پروٹوکولز کے ساتھ انضمام کی حمایت کرتا ہے، جو آپ کو صارف کی درخواست کو مکمل ہونے سے منسلک ہونے کے ساتھ ساتھ اس درخواست کے لاگز تلاش کرنے کی اجازت دیتا ہے (دونوں ویب سرور سائیڈ پر اور صارفین پر)۔

Datadog استعمال کرتے وقت، ہمیں اس کا سامنا کرنا پڑا کہ اس نے بعض اوقات مائیکرو سروس میپ کو غلط طریقے سے بنایا، اور کچھ تکنیکی کوتاہیاں۔ مثال کے طور پر، اس نے سروس کی قسم کی غلط شناخت کی (کیشنگ سروس کے لیے Django کو غلط سمجھنا) اور مشہور Predis لائبریری کا استعمال کرتے ہوئے PHP ایپلی کیشن میں 500 غلطیاں پیدا کیں۔

اتاتس - سب سے چھوٹا آلہ؛ سروس 2014 میں شروع کی گئی تھی۔ اس کا مارکیٹنگ بجٹ واضح طور پر درج حریفوں سے کمتر ہے، ذکر بہت کم عام ہیں۔ تاہم، یہ ٹول بذات خود نیو ریلیک سے بہت ملتا جلتا ہے، نہ صرف اپنی صلاحیتوں (اے پی ایم، براؤزر مانیٹرنگ، وغیرہ) میں، بلکہ ظاہری شکل میں بھی۔

ایک اہم خرابی یہ ہے کہ یہ صرف Node.js اور PHP کو سپورٹ کرتا ہے۔ دوسری طرف، یہ Datadog کے مقابلے میں نمایاں طور پر بہتر طور پر لاگو کیا جاتا ہے. مؤخر الذکر کے برعکس، Atatus کو کوڈ میں ترمیم کرنے یا اضافی لیبل شامل کرنے کے لیے ایپلیکیشنز کی ضرورت نہیں ہے۔

ہم نیو ریلیک کے ساتھ کیسے کام کرتے ہیں۔

اب آئیے یہ معلوم کرتے ہیں کہ ہم عام طور پر New Relic کو کس طرح استعمال کرتے ہیں۔ ہم کہتے ہیں کہ ہمارے پاس ایک مسئلہ ہے جس کے حل کی ضرورت ہے:

گراف پر دیکھنا آسان ہے۔ سپاش - آئیے اس کا تجزیہ کرتے ہیں۔ نیو ریلیک میں، ویب ٹرانزیکشنز کو فوری طور پر ویب ایپلیکیشن کے لیے منتخب کیا جاتا ہے، تمام اجزاء کارکردگی کے گراف میں دکھائے جاتے ہیں، غلطی کی شرح، درخواست کی شرح کے پینلز موجود ہیں... سب سے اہم بات یہ ہے کہ ان پینلز سے آپ براہ راست مختلف لین دین کے درمیان منتقل ہو سکتے ہیں۔ ایپلیکیشن کے حصے (مثال کے طور پر، MySQL پر کلک کرنے سے ڈیٹا بیس سیکشن کی طرف جائے گا)۔

چونکہ زیر غور مثال میں ہم سرگرمی میں اضافہ دیکھتے ہیں۔ پی ایچ پیاس چارٹ پر کلک کریں اور خود بخود اس پر جائیں۔ معاملات:

لین دین کی فہرست، جو کہ بنیادی طور پر MVC ماڈل کے کنٹرولرز ہیں، پہلے سے ترتیب دی گئی ہے۔ سب سے زیادہ وقت لگتا ہے۔، جو بہت آسان ہے: ہم فوری طور پر دیکھتے ہیں کہ درخواست کیا کرتی ہے۔ یہاں طویل سوالات کی مثالیں ہیں جو خود بخود نیو ریلک کے ذریعہ جمع کی جاتی ہیں۔ چھانٹی کو تبدیل کرنے سے، یہ تلاش کرنا آسان ہے:

سب سے زیادہ بھری ہوئی ایپلی کیشن کنٹرولر؛
اکثر درخواست کردہ کنٹرولر؛
سب سے سست کنٹرولرز۔

اس کے علاوہ، آپ ہر ٹرانزیکشن کو بڑھا سکتے ہیں اور دیکھ سکتے ہیں کہ کوڈ کے عمل میں آنے کے وقت ایپلیکیشن کیا کر رہی تھی:

آخر میں، ایپلی کیشن لمبی درخواستوں کے نشانات کی مثالیں ذخیرہ کرتی ہے (جو کہ 2 سیکنڈ سے زیادہ لیتی ہیں)۔ یہاں ایک طویل لین دین کا پینل ہے:

یہ دیکھا جا سکتا ہے کہ دو طریقوں میں کافی وقت لگتا ہے، اور اسی وقت جب درخواست کی گئی تھی، اس کا URI اور ڈومین بھی دکھایا گیا ہے۔ اکثر یہ نوشتہ جات میں درخواست کو تلاش کرنے میں مدد کرتا ہے۔ جارہا ہوں تفصیلات ٹریس کریں۔، آپ دیکھ سکتے ہیں کہ ان طریقوں کو کہاں سے بلایا جاتا ہے:

اور اندر ڈیٹا بیس کے سوالات - ڈیٹا بیس کے سوالات کا اندازہ کریں جو ایپلیکیشن چلتے وقت انجام دیے گئے تھے:

اس علم سے لیس، ہم اندازہ کر سکتے ہیں کہ ایپلیکیشن سست کیوں ہو رہی ہے اور اس مسئلے کو حل کرنے کے لیے ایک حکمت عملی کے ساتھ آنے کے لیے ڈویلپر کے ساتھ مل کر کام کر سکتے ہیں۔ حقیقت میں، نیو ریلک ہمیشہ ایک واضح تصویر نہیں دیتا، لیکن یہ تحقیقات کے ویکٹر کو منتخب کرنے میں مدد کرتا ہے:

طویل PDO::Construct ہمیں pgpoll کے عجیب کام کی طرف لے گیا۔
وقت کے ساتھ عدم استحکام Memcache::Get تجویز کیا کہ ورچوئل مشین کو غلط طریقے سے ترتیب دیا گیا تھا۔
ٹیمپلیٹ پروسیسنگ کے لیے مشتبہ طور پر بڑھے ہوئے وقت کی وجہ سے آبجیکٹ اسٹوریج میں 500 اوتاروں کی موجودگی کی جانچ پڑتال کے لیے ایک نیسٹڈ لوپ بنا۔
وغیرہ…

ایسا بھی ہوتا ہے کہ کوڈ پر عمل درآمد کرنے کے بجائے، بیرونی ڈیٹا اسٹوریج سے متعلق کوئی چیز مرکزی سکرین پر بڑھتی ہے - اور اس سے کوئی فرق نہیں پڑتا کہ یہ کیا ہوگا: Redis یا PostgreSQL - وہ سب ٹیب میں چھپے ہوئے ہیں۔ ڈیٹا بیس.

آپ تحقیق اور ترتیب کے سوالات کے لیے ایک مخصوص بنیاد منتخب کر سکتے ہیں - جیسا کہ یہ لین دین میں کیا جاتا ہے۔ اور درخواست والے ٹیب پر جا کر، آپ دیکھ سکتے ہیں کہ ہر ایپلیکیشن کنٹرولر میں یہ درخواست کتنی بار آتی ہے، اور یہ بھی اندازہ لگا سکتے ہیں کہ اسے کتنی بار کال کی جاتی ہے۔ یہ بہت آرام دہ ہے:

ٹیب میں اسی طرح کا ڈیٹا ہے۔ بیرونی خدمات، جو بیرونی HTTP خدمات کی درخواستوں کو چھپاتا ہے، جیسے آبجیکٹ اسٹوریج تک رسائی حاصل کرنا، سنٹری کو ایونٹس بھیجنا، یا اس جیسی۔ ٹیب کا مواد مکمل طور پر ڈیٹا بیس سے ملتا جلتا ہے:

حریف: مواقع اور تاثرات

اب سب سے دلچسپ بات یہ ہے کہ نیو ریلیک کی صلاحیتوں کا موازنہ کیا جائے جو حریف پیش کرتے ہیں۔ بدقسمتی سے، ہم پروڈکشن میں چلنے والی ایک ایپلیکیشن کے ایک ورژن پر تینوں ٹولز کی جانچ نہیں کر سکے۔ تاہم، ہم نے ان حالات/کنفیگریشنز کا موازنہ کرنے کی کوشش کی جو ممکن حد تک ایک جیسی تھیں۔

1. ڈیٹا ڈاگ

Datadog خدمات کی دیوار کے ساتھ ایک پینل کے ساتھ ہمارا استقبال کرتا ہے:

یہ ایپلی کیشنز کو اجزاء/مائیکرو سروسز میں توڑنے کی کوشش کرتا ہے، لہذا مثال کے طور پر Django ایپلی کیشن میں ہم PostgreSQL سے 2 کنکشن دیکھیں گے (defaultdb и postgres) کے ساتھ ساتھ سیلری، ریڈیس۔ Datadog کے ساتھ کام کرنے کے لیے آپ کو MVC اصولوں کا کم سے کم علم ہونا ضروری ہے: آپ کو یہ سمجھنے کی ضرورت ہے کہ عام طور پر صارف کی درخواستیں کہاں سے آتی ہیں۔ یہ عام طور پر مدد کرتا ہے۔ خدمات کا نقشہ:

ویسے، نیو ریلک میں بھی کچھ ایسا ہی ہے:

... اور ان کا نقشہ، میری رائے میں، آسان اور واضح بنایا گیا ہے: یہ ایک ایپلیکیشن کے اجزاء کو ظاہر نہیں کرتا ہے (جو اسے حد سے زیادہ تفصیل سے بنا دے گا، جیسا کہ ڈیٹا ڈاگ کے معاملے میں)، بلکہ صرف مخصوص خدمات یا مائیکرو سروسز۔

آئیے ڈیٹا ڈوگ پر واپس آتے ہیں: سروس میپ سے ہم دیکھ سکتے ہیں کہ صارف کی درخواستیں جینگو پر آتی ہیں۔ آئیے جینگو سروس پر جائیں اور آخر میں دیکھیں کہ ہم کیا توقع کرتے ہیں:

بدقسمتی سے، یہاں پر ڈیفالٹ کوئی گراف نہیں ہے۔ ویب ٹرانزیکشن کا وقت، جیسا کہ ہم مرکزی نیو ریلک پینل پر دیکھتے ہیں۔ تاہم، یہ شیڈول کی جگہ پر ترتیب دیا جا سکتا ہے گزارے ہوئے وقت کا %. اسے تبدیل کرنا کافی ہے۔ قسم کے لحاظ سے فی درخواست اوسط وقت... اور اب واقف گراف ہماری طرف دیکھ رہا ہے!

Datadog نے ایک مختلف چارٹ کیوں چنا ہمارے لیے ایک معمہ ہے۔ ایک اور مایوس کن بات یہ ہے کہ سسٹم صارف کی پسند کو یاد نہیں رکھتا (دونوں حریفوں کے برعکس) اور اس لیے واحد حل اپنی مرضی کے پینل بنانا ہے۔

لیکن میں Datadog میں ان گرافس سے متعلقہ سرورز کے میٹرکس پر جانے، لاگز کو پڑھنے اور ویب سرور ہینڈلرز (گنی کارن) پر بوجھ کا جائزہ لینے کی صلاحیت سے خوش تھا۔ سب کچھ تقریباً ویسا ہی ہے جیسا کہ نیو ریلک میں ہے... اور اس سے بھی کچھ زیادہ (لاگز)!

گراف کے نیچے لین دین مکمل طور پر New Relic سے ملتے جلتے ہیں۔

Datadog میں، لین دین کو کہا جاتا ہے۔ حوالہ جات. آپ کنٹرولرز کو درخواستوں کی تعداد، اوسط جوابی وقت، اور ایک منتخب مدت کے لیے زیادہ سے زیادہ وقت کے حساب سے ترتیب دے سکتے ہیں۔

آپ وسائل کو وسعت دے سکتے ہیں اور ہر وہ چیز دیکھ سکتے ہیں جو ہم نے پہلے ہی نیو ریلک میں دیکھا ہے:

وسائل پر اعداد و شمار، داخلی کالوں کی عمومی فہرست، اور درخواستوں کی مثالیں ہیں جنہیں رسپانس کوڈ کے ذریعے ترتیب دیا جا سکتا ہے... ویسے، ہمارے انجینئرز کو یہ چھانٹی واقعی پسند آئی۔

Datadog میں کسی بھی مثال کے وسائل کو کھولا اور مطالعہ کیا جا سکتا ہے:

درخواست کے پیرامیٹرز، ہر جزو پر گزارے گئے وقت کا خلاصہ چارٹ، اور کالوں کی ترتیب کو ظاہر کرنے والا واٹر فال چارٹ پیش کیا گیا ہے۔ آپ آبشار کے چارٹ کے درخت کے نظارے پر بھی جا سکتے ہیں:

اور سب سے دلچسپ چیز میزبان کا بوجھ دیکھنا ہے جس پر درخواست کی گئی تھی اور درخواست کے لاگز کو دیکھنا ہے۔

عظیم انضمام!

آپ سوچ رہے ہوں گے کہ ٹیبز کہاں ہیں۔ ڈیٹا بیس и بیرونی خدماتجیسا کہ نیو ریلک میں ہے۔ یہاں کوئی بھی نہیں ہے: چونکہ Datadog ایپلی کیشن کو اجزاء میں تحلیل کرتا ہے، PostgreSQL پر غور کیا جائے گا۔ ایک علیحدہ سروس، اور بیرونی خدمات کے بجائے یہ تلاش کرنے کے قابل ہے۔ aws.storage (یہ ہر دوسری بیرونی سروس کے لیے ایسا ہی ہوگا جس تک ایپلیکیشن رسائی حاصل کر سکتی ہے)۔

یہاں کے ساتھ ایک مثال ہے postgres:

بنیادی طور پر وہ سب کچھ ہے جو ہم چاہتے تھے:

آپ دیکھ سکتے ہیں کہ درخواست کس "سروس" سے آئی ہے۔

آپ کو یہ یاد دلانا غلط نہیں ہوگا کہ ڈیٹا ڈاگ NGINX Ingress کے ساتھ مکمل طور پر ضم ہو جاتا ہے اور کلسٹر میں درخواست آنے کے وقت سے آپ کو اینڈ ٹو اینڈ ٹریسنگ کرنے کی اجازت دیتا ہے، اور آپ کو اعدادوشمار کے میٹرکس حاصل کرنے، لاگز جمع کرنے اور میزبان میٹرکس کی بھی اجازت دیتا ہے۔ .

ڈیٹا ڈاگ کا ایک بہت بڑا پلس یہ ہے کہ اس کی قیمت شکل لے رہا ہے انفراسٹرکچر مانیٹرنگ، اے پی ایم، لاگ مینجمنٹ اور سنتھیٹکس ٹیسٹ سے، یعنی آپ اپنا منصوبہ لچکدار طریقے سے منتخب کر سکتے ہیں۔

2.Atatus

Atatus ٹیم کا دعوی ہے کہ ان کی سروس "نیو ریلک جیسی ہے، لیکن بہتر ہے۔" آئیے دیکھتے ہیں کہ کیا واقعی ایسا ہے۔

مرکزی پینل یکساں نظر آتا ہے، لیکن ایپلی کیشن میں استعمال ہونے والے Redis اور memcached کا تعین کرنا ممکن نہیں تھا۔

APM تمام لین دین کو بطور ڈیفالٹ منتخب کرتا ہے، حالانکہ عام طور پر صرف ویب ٹرانزیکشنز کی ضرورت ہوتی ہے۔ Datadog کی طرح، مین پینل سے مطلوبہ سروس پر جانے کا کوئی طریقہ نہیں ہے۔ مزید برآں، ٹرانزیکشنز کو غلطیوں کے بعد درج کیا جاتا ہے، جو APM کے لیے زیادہ منطقی نہیں لگتا۔

Atatus لین دین میں، ہر چیز نیو ریلیک کی طرح ممکن ہے۔ منفی پہلو یہ ہے کہ ہر کنٹرولر کی حرکیات فوری طور پر نظر نہیں آتی ہیں۔ آپ کو اسے کنٹرولر ٹیبل میں تلاش کرنا ہوگا، ترتیب دے کر سب سے زیادہ وقت استعمال کیا جاتا ہے۔:

کنٹرولرز کی معمول کی فہرست ٹیب میں دستیاب ہے۔ کھنگالیں:

کچھ طریقوں سے، یہ ٹیبل ڈیٹا ڈاگ کی یاد دلاتا ہے اور مجھے یہ نیو ریلک میں ملتے جلتے سے بہتر لگتا ہے۔

آپ ہر ٹرانزیکشن کو بڑھا سکتے ہیں اور دیکھ سکتے ہیں کہ ایپلیکیشن کیا کر رہی ہے:

پینل ڈیٹا ڈوگ کی زیادہ یاد دلانے والا بھی ہے: یہاں بہت سی درخواستیں ہیں، کالوں کی عمومی تصویر۔ اوپر والا پینل ایک خرابی کا ٹیب فراہم کرتا ہے۔ HTTP ناکامیاں اور سست سوالات کی مثالیں۔ سیشن کے نشانات:

اگر آپ کسی لین دین پر جاتے ہیں، تو آپ ٹریس کی مثال دیکھ سکتے ہیں، آپ ڈیٹا بیس میں درخواستوں کی فہرست حاصل کر سکتے ہیں اور درخواست کے ہیڈر کو دیکھ سکتے ہیں۔ ہر چیز نیو ریلیک کی طرح ہے:

عام طور پر، Atatus تفصیلی نشانات سے خوش ہوا - بغیر کسی ریمائنڈر بلاک میں کالوں کے مخصوص نئے ریلیک کے چپکے:

تاہم، اس میں فلٹر کا فقدان ہے جو (جیسے نیو ریلک) انتہائی تیز درخواستوں (<5ms) کو کاٹ دے گا۔ دوسری طرف، مجھے حتمی لین دین کے جواب (کامیابی یا غلطی) کا ڈسپلے پسند آیا۔

پینل ڈیٹا بیس آپ کو بیرونی ڈیٹا بیس کی درخواستوں کا مطالعہ کرنے میں مدد کرے گا جو ایپلیکیشن کرتی ہے۔ میں آپ کو یاد دلاتا ہوں کہ Atatus نے صرف PostgreSQL اور MySQL پایا، حالانکہ Redis اور memcached بھی اس پروجیکٹ میں شامل ہیں۔

درخواستوں کو معمول کے معیار کے مطابق ترتیب دیا جاتا ہے: ردعمل کی تعدد، اوسط جوابی وقت، وغیرہ۔ میں سست ترین سوالات کے ساتھ ٹیب کا بھی ذکر کرنا چاہوں گا - یہ بہت آسان ہے۔ مزید برآں، پوسٹگری ایس کیو ایل کے لیے اس ٹیب میں موجود ڈیٹا ایکسٹینشن کے ڈیٹا سے مطابقت رکھتا ہے۔ pg_stat_statements - بہترین نتیجہ!

ٹیب بیرونی درخواستیں ڈیٹا بیس سے بالکل مماثل۔

نتائج

دونوں پیش کردہ ٹولز نے اے پی ایم کے کردار میں اچھی کارکردگی کا مظاہرہ کیا۔ ان میں سے کوئی بھی مطلوبہ کم از کم پیش کر سکتا ہے۔ ہمارے تاثرات کو مختصراً اس طرح بیان کیا جا سکتا ہے:

ڈیٹاڈوگ

پیشہ:

آسان ٹیرف شیڈول (APM کی قیمت 31 USD فی میزبان)؛
ازگر کے ساتھ اچھا کام کیا؛
OpenTracing کے ساتھ انضمام کا امکان
Kubernetes کے ساتھ انضمام؛
NGINX Ingress کے ساتھ انضمام۔

Cons:

واحد APM جس کی وجہ سے ماڈیول کی خرابی (predis) کی وجہ سے ایپلیکیشن غیر دستیاب ہو گئی۔
کمزور پی ایچ پی آٹو انسٹرومینٹیشن؛
خدمات اور ان کے مقصد کی جزوی طور پر عجیب و غریب تعریف۔

اتاتس