SRE/DevOps انجنيئرن جي ماحول ۾، اهو ڪنهن کي به حيران نه ڪندو ته هڪ ڏينهن هڪ ڪلائنٽ (يا هڪ مانيٽرنگ سسٽم) ظاهر ٿئي ٿو ۽ رپورٽ ڪري ٿو ته ”سڀ ڪجهه گم ٿي ويو آهي“: سائيٽ ڪم نٿي ڪري، ادائگيون نه ٿيون ٿين، زندگي زوال پذير آهي. ... اهڙي صورتحال ۾ توهان ڪيتري به مدد ڪرڻ چاهيندا، اهو آسان ۽ سمجھڻ واري اوزار کان سواء ڪرڻ تمام ڏکيو ٿي سگهي ٿو. گهڻو ڪري مسئلو پاڻ ۾ ايپليڪيشن ڪوڊ ۾ لڪيل آهي؛ توهان کي صرف ان کي مقامي ڪرڻ جي ضرورت آهي.
۽ غم ۽ خوشي ۾...
اهو ائين ئي ٿيو آهي ته اسان ڊگھي عرصي کان نيو ريلڪ سان پيار ۾ پئجي ويا آهيون. اهو ايپليڪيشن جي ڪارڪردگي جي نگراني لاءِ هڪ بهترين اوزار هو ۽ رهي ٿو، ۽ اهو پڻ توهان کي اجازت ڏئي ٿو ته مائڪرو سروس آرڪيٽيڪچر (ان جي ايجنٽ کي استعمال ڪندي) ۽ گهڻو ڪجهه. ۽ هر شي تمام سٺو ٿي سگهي ٿو جيڪڏهن اها خدمت جي قيمت جي پاليسي ۾ تبديلين لاءِ نه هجي ها: اهو جي قيمت 3+ ڀيرا وڌو. ان کان علاوه، گذريل سال کان وٺي، هڪ آزمائشي اڪائونٽ حاصل ڪرڻ لاء هڪ ذاتي مينيجر سان رابطي جي ضرورت آهي، جنهن کي اهو ڏکيو بڻائي ٿو پراڊڪٽ کي پيش ڪرڻ ممڪن ڪسٽمر ڏانهن.
معمولي صورتحال: "مستقل بنياد" تي نئين رشتي جي ضرورت ناهي؛ اهي صرف ان وقت ياد ڪندا آهن جڏهن مسئلا شروع ٿين ٿا. پر توھان کي اڃا تائين باقاعدي ادا ڪرڻ جي ضرورت آھي (140 USD في سرور في مھينا)، ۽ ھڪڙي خودڪار اسڪيلنگ ڪلائوڊ انفراسٽرڪچر ۾ رقمن ۾ اضافو ٿيو بلڪه وڏو. جيتوڻيڪ اتي ھڪڙو Pay-As-You-Go آپشن آھي، نيو Relic کي چالو ڪرڻ لاءِ توھان کي ايپليڪيشن کي ٻيهر شروع ڪرڻ جي ضرورت پوندي، جيڪا ٿي سگھي ٿي ان مسئلي واري صورتحال جي نقصان جو سبب جنھن لاءِ اھو سڀ شروع ڪيو ويو ھو. گهڻو وقت اڳ، نيو ريلڪ هڪ نئين ٽريف پلان متعارف ڪرايو. , - جيڪو پهرين نظر ۾ پروفيشنل لاءِ هڪ مناسب متبادل وانگر نظر اچي ٿو... پر ويجھي جاچ ڪرڻ تي اهو ظاهر ٿيو ته ڪجهه اهم افعال غائب آهن (خاص طور تي، اهو ناهي اهم ٽرانزيڪشن, ڪراس ايپليڪيشن ٽريڪنگ, ورهايل ٽريڪنگ).
نتيجي طور، اسان ھڪڙو سستو متبادل ڳولڻ بابت سوچڻ شروع ڪيو، ۽ اسان جي پسند ٻن خدمتن تي ٿي وئي: Datadog ۽ Atatus. انهن تي ڇو؟
مقابلي ڪندڙن بابت
مون کي فوري طور تي چوڻ ڏيو ته مارڪيٽ تي ٻيا حل آهن. اسان اوپن سورس آپشنز تي به غور ڪيو، پر ھر ڪلائنٽ وٽ مفت ظرفيت ناھي ته ھو ميزباني ڪيل خود ميزبان حل... - اضافي طور تي، انھن کي اضافي سار سنڀال جي ضرورت پوندي. اسان جي چونڊيل جوڙو سڀ کان ويجھو نڪتو اسان جي ضرورتن:
- PHP ايپليڪيشنن لاءِ ٺاهيل ۽ ترقي يافته سپورٽ (اسان جي گراهڪن جو اسٽيڪ تمام متنوع آهي، پر اهو نئون ريلڪ جي متبادل جي ڳولا جي حوالي سان هڪ واضح اڳواڻ آهي)؛
- سستي قيمت (100 USD کان گهٽ هر مهيني في ميزبان)؛
- خودڪار اوزار؛
- Kubernetes سان انضمام؛
- نيو ريلڪ انٽرفيس جي هڪجهڙائي هڪ قابل ذڪر پلس آهي (ڇاڪاڻ ته اسان جا انجنيئر ان کي استعمال ڪندا آهن).
تنهن ڪري، شروعاتي چونڊ اسٽيج تي، اسان ڪيترن ئي ٻين مشهور حلن کي ختم ڪيو، ۽ خاص طور تي:
- Tideways, AppDynamics ۽ Dynatrace - قيمت لاء;
- Stackify روسي فيڊريشن ۾ بند ٿيل آهي ۽ تمام گهٽ ڊيٽا ڏيکاري ٿو.
مضمون جو باقي حصو اهڙي طرح ترتيب ڏنو ويو آهي ته سوالن جا حل پهريان مختصر طور تي پيش ڪيا ويندا، جنهن کان پوءِ مان ڳالهائيندس نيو ريليڪ سان اسان جي عام ڳالهه ٻولهه ۽ ٻين خدمتن ۾ ساڳيون ڪارروايون انجام ڏيڻ جي تجربي/تاثرن بابت.
چونڊيل مقابلن جي پيشڪش
تي ، شايد هرڪو ٻڌو آهي؟ هن خدمت جي شروعات 10 سال کان وڌيڪ اڳ، 2008 ۾. اسان ان کي 2012 کان فعال طور تي استعمال ڪري رهيا آهيون ۽ PHP، Ruby ۽ Python ۾ ايپليڪيشنن جي وڏي تعداد کي ضم ڪرڻ ۾ ڪو مسئلو ناهي، ۽ اسان کي C# ۽ Go سان ضم ٿيڻ جو تجربو پڻ ڪيو آهي. خدمت جي ليکڪن وٽ ايپليڪيشنن جي نگراني ڪرڻ، انفراسٽرڪچر، مائڪرو سروسز انفراسٽرڪچر کي ٽريڪ ڪرڻ، صارف جي ڊوائيسز لاء آسان ايپليڪيشنون، ۽ گهڻو ڪجهه لاء حل آهن.
بهرحال، نيو ريلڪ ايجنٽ ملڪيت جي پروٽوڪول تي هلندو آهي ۽ OpenTracing کي سپورٽ نٿو ڪري. جديد اوزارن جي ضرورت آهي تبديلين لاءِ خاص طور تي نيو ريليڪ لاءِ. آخرڪار، ڪبرنيٽس سپورٽ اڃا تائين تجرباتي آهي.
2010 ۾ ان جي ترقي شروع ٿي خاص طور تي ڪبرنيٽس ماحول ۾ استعمال جي لحاظ کان خاص طور تي نيو ريلڪ کان وڌيڪ دلچسپ ڏسڻ ۾ اچي ٿو. خاص طور تي، اهو NGINX Ingress، log collection، statsd ۽ OpenTracing پروٽوڪول سان انضمام جي حمايت ڪري ٿو، جيڪو توهان کي اجازت ڏئي ٿو صارف جي درخواست کي ٽريڪ ڪرڻ جي ان وقت کان جڏهن اهو مڪمل ٿيڻ سان ڳنڍيل آهي، ۽ انهي سان گڏ هن درخواست لاء لاگز ڳوليو (ٻنهي ويب سرور جي پاسي تي. ۽ صارفين تي).
Datadog استعمال ڪرڻ وقت، اسان اهو محسوس ڪيو ته اهو ڪڏهن ڪڏهن microservice نقشي کي غلط طور تي ٺاهيو، ۽ ڪجهه ٽيڪنيڪل نقص. مثال طور، هن سروس جي قسم جي غلط سڃاڻپ ڪئي (جينگو کي ڪيشنگ سروس جي غلطي ڪرڻ) ۽ مشهور پريڊس لائبريري استعمال ڪندي PHP ايپليڪيشن ۾ 500 غلطيون پيدا ڪيون.
- سڀ کان ننڍي اوزار؛ سروس 2014 ۾ شروع ڪئي وئي. ان جي مارڪيٽنگ بجيٽ واضح طور تي درج ڪيل مقابلي کان گهٽ آهي، ذڪر تمام گهٽ عام آهن. تنهن هوندي به، اوزار پاڻ کي بلڪل نئين Relic سان ملندڙ جلندڙ آهي، نه رڳو ان جي صلاحيتن ۾ (APM، برائوزر جي نگراني، وغيره)، پر پڻ ظاهر ۾.
هڪ اهم خرابي اهو آهي ته اهو صرف سپورٽ ڪري ٿو Node.js ۽ PHP. ٻئي طرف، اهو Datadog کان بهتر طور تي لاڳو ڪيو ويو آهي. بعد ۾ برعڪس، Atatus ايپليڪيشنن کي تبديل ڪرڻ يا ڪوڊ ۾ اضافي ليبل شامل ڪرڻ جي ضرورت ناهي.
اسان ڪيئن ڪم ڪندا آهيون نيو ريليڪ سان
هاڻي اچو ته اهو سمجهون ته اسان عام طور تي نيو ريلڪ ڪيئن استعمال ڪندا آهيون. اچو ته اسان وٽ ھڪڙو مسئلو آھي جنھن کي حل ڪرڻ جي ضرورت آھي:
اهو گراف تي ڏسڻ لاء آسان آهي ڦاٽل - اچو ته ان جو تجزيو ڪريون. نيو ريليڪ ۾، ويب ٽرانزيڪشن کي فوري طور تي ويب ايپليڪيشن لاءِ چونڊيو ويو آهي، سڀئي حصا ڪارڪردگي گراف ۾ ظاهر ڪيا ويا آهن، اتي آهن غلطي جي شرح، درخواست جي شرح پينل... سڀ کان اهم ڇا آهي ته انهن پينلن مان توهان سڌو سنئون مختلف وچ ۾ منتقل ڪري سگهو ٿا. ايپليڪيشن جا حصا (مثال طور، MySQL تي ڪلڪ ڪرڻ سان ڊيٽابيس سيڪشن ڏانهن ويندي).
جيئن ته غور هيٺ مثال ۾ اسان کي سرگرمي ۾ اضافو ڏسڻ ۾ اچي ٿو پي PHP حفاظتيهن چارٽ تي ڪلڪ ڪريو ۽ خودڪار طريقي سان وڃو ٽرانسڪشن:
ٽرانزيڪشن جي فهرست، جيڪي بنيادي طور تي MVC ماڊل کان ڪنٽرولرز آهن، اڳ ۾ ئي ترتيب ڏنل آهن گهڻو وقت وٺندڙ، جيڪو تمام آسان آهي: اسان فوري طور تي ڏسون ٿا ته ايپليڪيشن ڇا ڪري ٿي. ھتي آھن ڊگھي سوالن جا مثال جيڪي پاڻمرادو گڏ ڪيا ويا آھن نيو Relic. ترتيب ڏيڻ کي تبديل ڪندي، اهو ڳولڻ آسان آهي:
- سڀ کان وڌيڪ لوڊ ٿيل ايپليڪيشن ڪنٽرولر؛
- اڪثر درخواست ڪيل ڪنٽرولر؛
- سڀ کان سست ڪنٽرولرز.
اضافي طور تي، توهان هر ٽرانزيڪشن کي وڌائي سگهو ٿا ۽ ڏسو ته ايپليڪيشن ڇا ڪري رهي هئي جڏهن ڪوڊ تي عمل ڪيو ويو هو:
آخرڪار، ايپليڪيشن ڊگھي درخواستن جي نشانين جا مثال محفوظ ڪري ٿو (جيڪي 2 سيڪنڊن کان وڌيڪ وٺن ٿا). هتي هڪ ڊگهو ٽرانزيڪشن لاء پينل آهي:
اهو ڏسي سگهجي ٿو ته ٻه طريقا تمام گهڻو وقت وٺن ٿا، ۽ ساڳئي وقت جڏهن درخواست تي عمل ڪيو ويو، ان جي URI ۽ ڊومين پڻ ڏيکاريل آهي. گهڻو ڪري اهو لاگن ۾ درخواست ڳولڻ ۾ مدد ڪري ٿو. ڏانھن وڃان پيو تفصيلات ٽريڪ ڪريو، توهان ڏسي سگهو ٿا ته اهي طريقا ڪٿان سڏيا ويا آهن:
۽ اندر ڊيٽابيس جا سوال - ڊيٽابيسس جي سوالن جو جائزو وٺو جيڪي پليجي ويا هئا جڏهن ايپليڪيشن هلندي هئي:
هن علم سان هٿياربند، اسان اندازو ڪري سگهون ٿا ته ايپليڪيشن سست ڇو ٿي رهي آهي ۽ ڊولپر سان ڪم ڪرڻ لاء هڪ حڪمت عملي سان مسئلو حل ڪرڻ لاء. حقيقت ۾، نيو ريلڪ هميشه هڪ واضح تصوير نه ڏيندو آهي، پر اهو تحقيق جي ویکٹر کي چونڊڻ ۾ مدد ڪري ٿو:
- ڊگهو
PDO::Constructاسان کي pgpoll جي عجيب ڪم ڪرڻ جي هدايت ڪئي؛ - وقت تي عدم استحڪام
Memcache::Getتجويز ڪيو ته ورچوئل مشين غلط ترتيب ڏني وئي هئي؛ - ٽيمپليٽ پروسيسنگ لاءِ مشڪوڪ طور تي وڌيل وقت جي نتيجي ۾ هڪ نسٽڊ لوپ کي چڪاس ڪيو ويو 500 اوتارن جي موجودگي کي چڪاس ڪرڻ واري شئي اسٽوريج ۾؛
- وغيره…
اهو پڻ ٿئي ٿو ته ڪوڊ تي عمل ڪرڻ جي بدران، خارجي ڊيٽا اسٽوريج سان لاڳاپيل ڪجهه مکيه اسڪرين تي وڌندو آهي - ۽ اهو مسئلو ناهي ته اهو ڇا ٿيندو: Redis يا PostgreSQL - اهي سڀئي ٽيب ۾ لڪيل آهن. بنيادي دستاويز.
توھان منتخب ڪري سگھوٿا ھڪڙو خاص بنياد تحقيق لاءِ ۽ سوالن کي ترتيب ڏيو - جھڙيءَ طرح اھو ڪيئن ٿئي ٿو ٽرانزيڪشن ۾. ۽ درخواست واري ٽيب تي وڃڻ سان، توهان ڏسي سگهو ٿا ته هي درخواست ڪيترا ڀيرا هر ايپليڪيشن ڪنٽرولر ۾ ٿئي ٿي، ۽ اهو پڻ اندازو لڳايو ته اهو ڪيترا ڀيرا سڏيو ويندو آهي. اهو تمام آرامده آهي:
ٽيب ساڳي ڊيٽا تي مشتمل آهي خارجي خدمتون، جيڪو خارجي HTTP خدمتن جي درخواستن کي لڪائيندو آهي، جهڙوڪ اعتراض جي اسٽوريج تائين رسائي، واقعن کي سينٽرري ڏانهن موڪلڻ، يا جهڙوڪ. ٽيب مڪمل طور تي ڊيٽابيس جي مواد سان ملندڙ جلندڙ آهي:
مقابلا: موقعا ۽ تاثرات
هاڻي سڀ کان وڌيڪ دلچسپ ڳالهه اها آهي ته نيو ريليڪ جي صلاحيتن جو مقابلو ڪرڻ سان مقابلو ڪندڙ پيش ڪن ٿا. بدقسمتي سان، اسان پيداوار ۾ هلندڙ هڪ ايپليڪيشن جي هڪ ورزن تي سڀني ٽن اوزارن کي جانچڻ جي قابل نه هئاسين. بهرحال، اسان ڪوشش ڪئي حالتن/ ترتيبن جو مقابلو ڪرڻ جي جيڪا ممڪن طور تي هڪجهڙائي هئي.
1. ڊيٽا ڊاگ
Datadog اسان کي خدمتن جي ديوار سان پينل سان سلام ڪري ٿو:
اهو ايپليڪيشنن کي حصن/مائڪرو سروسز ۾ ٽوڙڻ جي ڪوشش ڪري ٿو، تنهن ڪري مثال طور Django ايپليڪيشن اسان کي 2 ڪنيڪشن ڏسڻ ۾ ايندا PostgreSQL (defaultdb и postgres)، گڏوگڏ Celery، Redis. Datadog سان ڪم ڪرڻ جي ضرورت آهي ته توهان کي MVC اصولن جي گهٽ ۾ گهٽ ڄاڻ هجي: توهان کي سمجهڻ جي ضرورت آهي ته صارف جون درخواستون عام طور تي ڪٿان اچن ٿيون. اهو عام طور تي مدد ڪري ٿو خدمتن جو نقشو:
رستي جي ذريعي، نيو ريلڪ ۾ ڪجهه ساڳيو آهي:
... ۽ انهن جو نقشو، منهنجي خيال ۾، آسان ۽ واضح ڪيو ويو آهي: اهو هڪ ايپليڪيشن جي اجزاء کي نه ڏيکاريندو آهي (جيڪو ان کي وڌيڪ تفصيل سان ٺاهيندو، جيئن Datadog جي صورت ۾)، پر صرف مخصوص خدمتون يا مائڪرو سروسز.
اچو ته واپس وڃو Datadog: خدمت جي نقشي مان اسان ڏسي سگھون ٿا ته صارف جون درخواستون Django ڏانهن اچن ٿيون. اچو ته جيانگو سروس ڏانهن وڃو ۽ آخرڪار ڏسو ته اسان کي ڇا توقع آهي:
بدقسمتي سان، هتي ڊفالٽ طور ڪو گراف ناهي ويب ٽرانزيڪشن جو وقت، جيڪو اسان ڏسون ٿا ان سان ملندڙ جلندڙ مکيه نيو ريلڪ پينل تي. بهرحال، اهو شيڊول جي جاء تي ترتيب ڏئي سگهجي ٿو خرچ ٿيل وقت جو٪. ان کي تبديل ڪرڻ لاء ڪافي آهي سراسري وقت في درخواست قسم جي حساب سان... ۽ هاڻي واقف گراف اسان کي ڏسي رهيو آهي!
Datadog هڪ مختلف چارٽ ڇو چونڊيو اسان لاءِ هڪ راز آهي. هڪ ٻي مايوس ڪندڙ شيء اها آهي ته سسٽم صارف جي پسند کي ياد نه ڪندو آهي (ٻنهي مقابلي جي برعڪس)، ۽ تنهنڪري واحد حل آهي ڪسٽم پينل ٺاهڻ.
پر مان Datadog جي قابليت سان خوش ٿيس ته انهن گرافن مان مٽائڻ لاءِ لاڳاپيل سرورز جي ميٽرڪس، لاگز کي پڙهو ۽ ويب سرور هينڊلر (Gunicorn) تي لوڊ جو جائزو وٺي. هر شي لڳ ڀڳ ساڳي آهي جيئن نيو ريلڪ ۾ ... ۽ اڃا به ٿورو وڌيڪ (لاگ)!
هيٺ ڏنل گرافس ٽرانزيڪشن مڪمل طور تي نيو ريلڪ سان ملندڙ جلندڙ آهن:
Datadog ۾، ٽرانزيڪشن کي سڏيو ويندو آهي وسيلا. توھان ڪنٽرولرز کي ترتيب ڏئي سگھو ٿا درخواستن جي تعداد، اوسط جوابي وقت جي حساب سان، ۽ وقت جي چونڊيل مدت لاءِ خرچ ڪيل وڌ ۾ وڌ وقت.
توهان وسيلن کي وڌائي سگهو ٿا ۽ هر شي کي ڏسي سگهو ٿا جيڪو اسان اڳ ۾ ئي ڏٺو آهي New Relic:
وسيلن تي انگ اکر آهن، اندروني ڪالن جي هڪ عام فهرست، ۽ درخواستن جا مثال جيڪي ترتيب ڏئي سگھجن ٿيون جوابي ڪوڊ... رستي جي ذريعي، اسان جي انجنيئرن کي هن ترتيب کي واقعي پسند آيو.
Datadog ۾ ڪو به مثال وسيلو کوليو وڃي ٿو ۽ اڀياس ڪري سگھجي ٿو:
درخواست جي پيراگراف، هر جزو تي خرچ ڪيل وقت جو هڪ خلاصو چارٽ، ۽ هڪ آبشار چارٽ ڏيکاريل ڪالن جو سلسلو پيش ڪيو ويو آهي. توهان آبشار چارٽ جي وڻ جي ڏيک تي پڻ سوئچ ڪري سگهو ٿا:
۽ سڀ کان وڌيڪ دلچسپ شيء ميزبان جي لوڊ کي ڏسي رهيو آهي جنهن تي درخواست ڪئي وئي هئي ۽ درخواست جي لاگز کي ڏسڻ.
عظيم انضمام!
توھان حيران ٿي سگھوٿا جتي ٽيب آھن بنيادي دستاويز и خارجي خدمتون، جيئن نيو ريلڪ ۾. هتي ڪو به نه آهي: جيئن ته Datadog ايپليڪيشن کي اجزاء ۾ ختم ڪري ٿو، PostgreSQL سمجهيو ويندو هڪ الڳ خدمت، ۽ بدران ٻاهرين خدمتن جي ان کي ڳولڻ جي قابل آهي aws.storage (اهو ساڳيو هوندو هر ٻي خارجي خدمت لاءِ جنهن تائين اپليڪيشن رسائي ڪري سگهي ٿي).
هتي هڪ مثال سان گڏ آهي postgres:
بنيادي طور تي سڀ ڪجهه آهي جيڪو اسان چاهيون ٿا:
توھان ڏسي سگھوٿا ڪھڙي ”سروس“ جي درخواست آئي آھي.
اهو توهان کي ياد ڏيارڻ غلط نه ٿيندو ته Datadog مڪمل طور تي NGINX Ingress سان ضم ٿي ويو آهي ۽ توهان کي اجازت ڏئي ٿو ته آخر کان آخر تائين ٽريڪنگ ڪرڻ جي ان وقت کان جڏهن هڪ درخواست ڪلستر ۾ اچي ٿي، ۽ توهان کي اجازت ڏئي ٿي statsd ميٽرڪ حاصل ڪرڻ، لاگ گڏ ڪرڻ ۽ ميزباني جي ميٽرڪ. .
Datadog جو هڪ وڏو پلس اهو آهي ته ان جي قيمت ترقي ڪري ٿو انفرااسٽرڪچر مانيٽرنگ، APM، لاگ مئنيجمينٽ ۽ مصنوعيات جا امتحان، يعني. توھان پنھنجي منصوبي کي لچڪدار طريقي سان چونڊي سگھو ٿا.
2. ايٽٽس
Atatus ٽيم دعوي ڪري ٿو ته انهن جي خدمت "ساڳي ئي نئين ريلي وانگر آهي، پر بهتر." اچو ته ڏسون ته ڇا واقعي ائين آهي.
مکيه پينل ساڳيو نظر اچي ٿو، پر ايپليڪيشن ۾ استعمال ٿيل Redis ۽ memcached جو تعين ڪرڻ ممڪن نه هو.
APM سڀني ٽرانزيڪشن کي ڊفالٽ طور چونڊيندو آهي، جيتوڻيڪ عام طور تي صرف ويب ٽرانزيڪشن جي ضرورت هوندي آهي. Datadog وانگر، مکيه پينل مان گهربل خدمت ڏانهن نيويگيٽ ڪرڻ جو ڪو طريقو ناهي. ان کان علاوه، ٽرانزيڪشن غلطين کان پوء درج ٿيل آهن، جيڪي APM لاء بلڪل منطقي نه لڳي.
Atatus ٽرانزيڪشن ۾، هر شيء ممڪن آهي جيترو ممڪن آهي نيو ريلڪ. نقصان اهو آهي ته هر ڪنٽرولر لاء متحرڪ فوري طور تي نظر نه اينديون آهن. توھان کي ان کي ڳولڻو پوندو ڪنٽرولر ٽيبل ۾، ترتيب سان گهڻو وقت خرچ:
ڪنٽرولرز جي معمولي فهرست ٽيب ۾ موجود آهي ڳوليو:
ڪجهه طريقن سان، هي ٽيبل Datadog جي ياد ڏياريندو آهي ۽ مون کي اهو پسند آهي ته ساڳئي هڪ کان وڌيڪ نئين ريلڪ ۾.
توهان هر ٽرانزيڪشن کي وڌائي سگهو ٿا ۽ ڏسو ته ايپليڪيشن ڇا ڪري رهي هئي:
پينل پڻ Datadog جي وڌيڪ ياد ڏياريندڙ آهي: اتي ڪيتريون ئي درخواستون آهن، ڪالن جي عام تصوير. مٿين پينل هڪ غلطي ٽيب مهيا ڪري ٿو HTTP ناڪاميون ۽ سست سوالن جا مثال سيشن جا نشان:
جيڪڏهن توهان هڪ ٽرانزيڪشن ڏانهن وڃو ٿا، توهان هڪ ٽريس جو مثال ڏسي سگهو ٿا، توهان ڊيٽابيس ڏانهن درخواستن جي هڪ فهرست حاصل ڪري سگهو ٿا ۽ درخواست جي هيڊرز کي ڏسي سگهو ٿا. هر شي نئين Relic وانگر آهي:
عام طور تي، Atatus تفصيلي نشانن سان خوش ٿيو - بغير ڪنهن ياد ڏياريندڙ بلاڪ ۾ ڪالن جي عام نئين ريليڪ گلونگ کان سواء:
جڏهن ته، اهو هڪ فلٽر نه آهي جيڪو (جهڙوڪ نيو ريلڪ) الٽرا فاسٽ درخواستن کي ڪٽيندو (<5ms). ٻئي طرف، مون آخري ٽرانزيڪشن جي جواب جي ڊسپلي کي پسند ڪيو (ڪاميابي يا غلطي).
پينل بنيادي دستاويز توهان کي ٻاهرين ڊيٽابيس جي درخواستن جو مطالعو ڪرڻ ۾ مدد ڏيندو جيڪا ايپليڪيشن ٺاهي ٿي. مون کي توهان کي ياد ڏيارڻ ڏي ته Atatus صرف PostgreSQL ۽ MySQL مليو، جيتوڻيڪ Redis ۽ memcached پڻ منصوبي ۾ شامل آهن.
درخواستون معمول جي معيار مطابق ترتيب ڏنل آھن: جواب جي تعدد، اوسط جوابي وقت، وغيره. مان پڻ ذڪر ڪرڻ چاهيان ٿو ٽيب کي سست ترين سوالن سان - اهو تمام آسان آهي. ان کان علاوه، PostgreSQL لاءِ هن ٽيب ۾ ڊيٽا واڌ جي ڊيٽا سان ٺهڪي اچي ٿي - شاندار نتيجو!
ٽيب خارجي درخواستون مڪمل طور تي ڊيٽابيس سان هڪجهڙائي.
پهچڻ
ٻنهي پيش ڪيل اوزار APM جي ڪردار ۾ چڱي طرح انجام ڏنو. انهن مان ڪو به گهربل گهٽ ۾ گهٽ پيش ڪري سگهي ٿو. اسان جي تاثرات کي مختصر طور تي هن ريت بيان ڪري سگهجي ٿو:
ڊيٽودوگ
پرو:
- آسان ٽريف شيڊول (APM قيمت 31 USD في ميزبان)؛
- Python سان سٺو ڪم ڪيو؛
- OpenTracing سان انضمام جو امڪان
- Kubernetes سان انضمام؛
- NGINX Ingress سان انضمام.
ڪن
- واحد APM جيڪا ايپليڪيشن کي دستياب نه ٿيڻ جو سبب بڻيو ماڊل جي غلطي (predis)؛
- ڪمزور PHP خودڪار اوزار؛
- خدمتن ۽ انهن جي مقصد جي جزوي طور تي عجيب وصف.
Atatus
پرو:
- ڊيپ پي ايڇ پي اوزار؛
- يوزر انٽرفيس نئين ريلي وانگر.
ڪن
- پراڻن آپريٽنگ سسٽم تي ڪم نٿو ڪري (Ubuntu 12.05، CentOS 5)؛
- ڪمزور خودڪار اوزار؛
- صرف ٻن ٻولين لاءِ سپورٽ (Node.js ۽ PHP)؛
- سست انٽرفيس.
غور ڪندي Atatus جي قيمت 69 USD في مهيني في سرور، اسان بجاءِ Datadog استعمال ڪنداسين، جيڪو اسان جي ضرورتن سان چڱيءَ طرح ضم ٿئي ٿو (K8s ۾ ويب ايپليڪيشنون) ۽ ڪيتريون ئي ڪارائتيون خاصيتون آهن.
پي ايس
اسان جي بلاگ تي پڻ پڙهو:
- «"؛
- «"؛
- «».
جو ذريعو: www.habr.com