नयाँ अवशेष एक्लै होइन: Datadog र Atatus मा एक नजर

SRE/DevOps ईन्जिनियरहरूको वातावरणमा, यसले कसैलाई आश्चर्यचकित पार्दैन कि एक दिन एक ग्राहक (वा अनुगमन प्रणाली) देखा पर्दछ र रिपोर्ट गर्दछ कि "सबै हराएको छ": साइटले काम गर्दैन, भुक्तानीहरू मार्फत जान सक्दैन, जीवन क्षय हुँदैछ। ... तपाईं यस्तो अवस्थामा जति नै मद्दत गर्न चाहनुहुन्छ, यो सरल र बुझ्न सकिने उपकरण बिना यो गर्न धेरै गाह्रो हुन सक्छ। प्रायः समस्या एप्लिकेसन कोडमा लुकेको हुन्छ; तपाईले यसलाई स्थानीयकरण गर्न आवश्यक छ।

अनि दु:ख र खुशीमा...

यो यस्तो भयो कि हामी नयाँ अवशेषको साथ लामो र गहिरो प्रेममा परेका छौं। यो अनुप्रयोग प्रदर्शन निगरानीको लागि उत्कृष्ट उपकरण थियो र रहन्छ, र यसले तपाईंलाई माइक्रोसर्भिस आर्किटेक्चर (यसको एजेन्ट प्रयोग गरेर) र धेरै धेरै उपकरण बनाउन अनुमति दिन्छ। र सबै कुरा राम्रो हुन सक्छ यदि यो सेवाको मूल्य निर्धारण नीतिमा परिवर्तनहरूको लागि नभएको भए: यो लागत 2013 वर्ष बाट 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 समर्थन गर्दैन। उन्नत इन्स्ट्रुमेन्टेसनलाई नयाँ अवशेषका लागि विशेष रूपमा सम्पादनहरू आवश्यक पर्दछ। अन्तमा, Kubernetes समर्थन अझै प्रयोगात्मक छ।

2010 मा यसको विकास सुरु भयो डाटाडोग Kubernetes वातावरणमा प्रयोगको सर्तमा नयाँ अवशेष भन्दा स्पष्ट रूपमा बढी रोचक देखिन्छ। विशेष गरी, यसले NGINX Ingress, लग सङ्कलन, statsd र OpenTracing प्रोटोकलहरूसँग एकीकरणलाई समर्थन गर्दछ, जसले तपाईंलाई प्रयोगकर्ता अनुरोधलाई यो पूरा भएको समयदेखि ट्र्याक गर्न अनुमति दिन्छ, साथै यस अनुरोधका लागि लगहरू फेला पार्छ (वेब ​​सर्भर साइडमा दुवै। र उपभोक्ता मा)।

Datadog प्रयोग गर्दा, हामीले कहिलेकाहीं यसले माइक्रोसर्भिस नक्सा गलत तरिकाले बनाएको छ, र केही प्राविधिक कमजोरीहरू देख्यौं। उदाहरणका लागि, यसले सेवा प्रकारलाई गलत पहिचान गर्‍यो (क्यासिङ सेवाको लागि Django लाई गल्ती गर्दै) र लोकप्रिय Predis पुस्तकालय प्रयोग गरेर PHP अनुप्रयोगमा 500 त्रुटिहरू निम्त्यायो।

Atatus - सबैभन्दा कान्छो उपकरण; सेवा 2014 मा सुरु भएको थियो। यसको मार्केटिङ बजेट स्पष्ट रूपमा सूचीबद्ध प्रतिस्पर्धीहरू भन्दा कम छ, उल्लेख धेरै कम सामान्य छन्। जे होस्, उपकरण आफैंमा नयाँ रिलिकसँग धेरै मिल्दोजुल्दो छ, न केवल यसको क्षमताहरूमा (एपीएम, ब्राउजर निगरानी, ​​आदि), तर उपस्थितिमा पनि।

एउटा महत्त्वपूर्ण कमजोरी यो हो कि यसले केवल Node.js र PHP लाई समर्थन गर्दछ। अर्कोतर्फ, यो Datadog भन्दा राम्रोसँग लागू गरिएको छ। पछिल्लोको विपरीत, एटाटसलाई परिमार्जन गर्न वा कोडमा थप लेबलहरू थप्न अनुप्रयोगहरू आवश्यक पर्दैन।

हामी कसरी New Relic सँग काम गर्छौं

अब हामी सामान्यतया नयाँ अवशेष कसरी प्रयोग गर्छौं भनेर पत्ता लगाउनुहोस्। मानौं हामीसँग एउटा समस्या छ जसको समाधान चाहिन्छ:

ग्राफमा हेर्न सजिलो छ splash - यसलाई विश्लेषण गरौं। नयाँ रेलिकमा, वेब लेनदेनहरू तुरुन्तै वेब अनुप्रयोगको लागि चयन गरिन्छ, सबै कम्पोनेन्टहरू प्रदर्शन ग्राफमा संकेत गरिएका छन्, त्यहाँ त्रुटि-दर, अनुरोध-दर प्यानलहरू छन्... सबैभन्दा महत्त्वपूर्ण कुरा के हो भने यी प्यानलहरूबाट तपाईं विभिन्न बीचमा सार्न सक्नुहुन्छ। अनुप्रयोगका भागहरू (उदाहरणका लागि, MySQL मा क्लिक गर्दा डाटाबेस खण्डमा जान्छ)।

विचाराधीन उदाहरणमा हामी गतिविधिमा वृद्धि देख्छौं PHP, यो चार्ट मा क्लिक गर्नुहोस् र स्वचालित रूपमा जानुहोस् लेनदेन:

लेनदेनको सूची, जुन अनिवार्य रूपमा MVC मोडेलबाट नियन्त्रकहरू हुन्, पहिले नै क्रमबद्ध गरिएको छ धेरै समय लाग्ने, जुन धेरै सुविधाजनक छ: हामी तुरुन्तै देख्छौं कि अनुप्रयोगले के गर्छ। यहाँ लामो प्रश्नहरूको उदाहरणहरू छन् जुन स्वचालित रूपमा New Relic द्वारा सङ्कलन गरिन्छ। क्रमबद्ध स्विच गरेर, यो फेला पार्न सजिलो छ:

• सबैभन्दा लोड भएको अनुप्रयोग नियन्त्रक;
• प्रायः अनुरोध गरिएको नियन्त्रक;
• नियन्त्रकहरूको सबैभन्दा ढिलो।

थप रूपमा, तपाइँ प्रत्येक लेनदेन विस्तार गर्न सक्नुहुन्छ र कोड कार्यान्वयन भएको समयमा अनुप्रयोगले के गरिरहेको थियो हेर्नुहोस्:

अन्तमा, एप्लिकेसनले लामो अनुरोधहरूको ट्रेसहरूको उदाहरणहरू भण्डार गर्दछ (जसले २ सेकेन्ड भन्दा बढी समय लिन्छ)। यहाँ लामो लेनदेनको लागि प्यानल छ:

यो देख्न सकिन्छ कि दुई विधिहरूले धेरै समय लिन्छ, र एकै समयमा जब अनुरोध कार्यान्वयन गरिएको थियो, यसको URI र डोमेन पनि देखाइएको छ। धेरै पटक यो लग मा अनुरोध फेला पार्न मद्दत गर्छ। जाँदै विवरणहरू ट्रेस गर्नुहोस्, तपाईले देख्न सक्नुहुन्छ कि यी विधिहरू कहाँबाट बोलाइन्छ:

र भित्र डाटाबेस प्रश्नहरू - डाटाबेसहरूमा प्रश्नहरूको मूल्याङ्कन गर्नुहोस् जुन अनुप्रयोग चलिरहेको बेला कार्यान्वयन गरिएको थियो:

यस ज्ञानको साथ सशस्त्र, हामी किन एप्लिकेसन ढिलो भइरहेको छ भनेर मूल्याङ्कन गर्न सक्छौं र समस्या समाधान गर्ने रणनीतिको साथ आउन विकासकर्तासँग काम गर्न सक्छौं। वास्तवमा, नयाँ अवशेषले सधैं स्पष्ट चित्र दिँदैन, तर यसले अनुसन्धानको भेक्टर छनौट गर्न मद्दत गर्दछ:

• लामो PDO::Construct pgpoll को अनौठो प्रकार्यमा हामीलाई नेतृत्व गर्यो;
• समय संग अस्थिरता Memcache::Get सुझाव दियो कि भर्चुअल मेसिन गलत कन्फिगर गरिएको थियो;
• टेम्प्लेट प्रशोधनका लागि संदिग्ध रूपमा बढेको समयले वस्तु भण्डारणमा 500 अवतारहरूको उपस्थिति जाँच गर्ने नेस्टेड लूपको नेतृत्व गर्‍यो;
• आदि ...

यो पनि हुन्छ कि कोड कार्यान्वयन गर्नुको सट्टा, बाह्य डेटा भण्डारणसँग सम्बन्धित केहि चीजहरू मुख्य स्क्रिनमा बढ्छ - र यसले के हुनेछ भन्ने फरक पर्दैन: Redis वा PostgreSQL - ती सबै ट्याबमा लुकेका छन्। डेटाबेस.

तपाईं अनुसन्धान र क्रमबद्ध प्रश्नहरूको लागि एक विशिष्ट आधार चयन गर्न सक्नुहुन्छ - लेनदेनमा कसरी गरिन्छ। र अनुरोध ट्याबमा गएर, तपाइँ प्रत्येक एप्लिकेसन नियन्त्रकहरूमा यो अनुरोध कति पटक हुन्छ देख्न सक्नुहुन्छ, र यो कति पटक कल गरिन्छ भनेर पनि अनुमान गर्न सक्नुहुन्छ। यो धेरै सहज छ:

ट्याबले समान डेटा समावेश गर्दछ बाह्य सेवाहरू, जसले बाह्य HTTP सेवाहरूमा अनुरोधहरू लुकाउँछ, जस्तै वस्तु भण्डारण पहुँच, सेन्ट्रीमा घटनाहरू पठाउने, वा यस्तै। ट्याबको सामग्री पूर्णतया डाटाबेससँग मिल्दोजुल्दो छ:

प्रतियोगीहरू: अवसरहरू र प्रभावहरू

अब सबैभन्दा चाखलाग्दो कुरा भनेको प्रतिस्पर्धीहरूले प्रस्ताव गर्ने नयाँ रिलिकको क्षमताहरू तुलना गर्नु हो। दुर्भाग्यवश, हामीले उत्पादनमा चलिरहेको एउटा अनुप्रयोगको एउटा संस्करणमा सबै तीनवटा उपकरणहरू परीक्षण गर्न सकेनौं। यद्यपि, हामीले परिस्थिति/कन्फिगरेसनहरू तुलना गर्ने प्रयास गर्यौं जुन सम्भव भएसम्म समान थिए।

1. डाटाडग

Datadog ले सेवाहरूको पर्खाल भएको प्यानलको साथ हामीलाई स्वागत गर्दछ:

यसले एप्लिकेसनहरूलाई कम्पोनेन्ट/माइक्रोसर्भिसेसहरूमा तोड्ने प्रयास गर्छ, त्यसैले उदाहरणमा Django अनुप्रयोगमा हामीले PostgreSQL मा २ जडानहरू देख्नेछौं।defaultdb и postgres), साथै सेलेरी, रेडिस। Datadog सँग काम गर्नको लागि तपाईंलाई MVC सिद्धान्तहरूको न्यूनतम ज्ञान हुनु आवश्यक छ: तपाईंले प्रयोगकर्ताका अनुरोधहरू सामान्यतया कहाँबाट आउँछन् भन्ने कुरा बुझ्न आवश्यक छ। यो सामान्यतया मद्दत गर्छ सेवा नक्सा:

वैसे, नयाँ अवशेष मा केहि समान छ:

... र तिनीहरूको नक्सा, मेरो विचारमा, सरल र स्पष्ट बनाइएको छ: यसले एउटा अनुप्रयोगको कम्पोनेन्टहरू प्रदर्शन गर्दैन (जसले डेटाडगको मामलामा जस्तै यसलाई अत्यधिक विस्तृत बनाउँदछ), तर केवल विशिष्ट सेवाहरू वा माइक्रोसेवाहरू।

Datadog मा फर्कौं: सेवा नक्साबाट हामी देख्न सक्छौं कि प्रयोगकर्ता अनुरोधहरू Django मा आउँछन्। Django सेवामा जाऔं र अन्तमा हामीले के अपेक्षा गरेका थियौं हेरौं:

दुर्भाग्यवश, पूर्वनिर्धारित रूपमा यहाँ कुनै ग्राफ छैन वेब लेनदेन समय, हामीले मुख्य नयाँ रिलिक प्यानलमा देखेको जस्तै। यद्यपि, यो तालिकाको स्थानमा कन्फिगर गर्न सकिन्छ खर्च भएको समयको %। यसलाई स्विच गर्न पर्याप्त छ प्रकार अनुसार प्रति अनुरोध औसत समय... र अब परिचित ग्राफ हामीलाई हेर्दै छ!

किन Datadog फरक चार्ट रोज्यो हाम्रो लागि रहस्य हो। अर्को निराशाजनक कुरा यो हो कि प्रणालीले प्रयोगकर्ताको छनोट सम्झदैन (दुबै प्रतियोगीहरूको विपरीत), र यसैले मात्र समाधान अनुकूलन प्यानलहरू सिर्जना गर्नु हो।

तर म Datadog मा यी ग्राफहरूबाट सम्बन्धित सर्भरहरूको मेट्रिक्समा स्विच गर्न, लगहरू पढ्न र वेब सर्भर ह्यान्डलरहरू (गुनिकर्न) मा लोड मूल्याङ्कन गर्ने क्षमतासँग खुसी थिएँ। सबै कुरा लगभग नयाँ रिलिकमा जस्तै छ... र अलि बढी (लगहरू)!

ग्राफहरू तल लेनदेनहरू नयाँ अवशेषसँग पूर्ण रूपमा मिल्दोजुल्दो छन्:

Datadog मा, लेनदेन भनिन्छ स्रोतहरू। तपाईंले अनुरोधहरूको संख्या, औसत प्रतिक्रिया समय, र समयको चयन गरिएको अवधिको लागि खर्च गरिएको अधिकतम समयद्वारा नियन्त्रकहरूलाई क्रमबद्ध गर्न सक्नुहुन्छ।

तपाईंले स्रोत विस्तार गर्न सक्नुहुन्छ र हामीले नयाँ अवशेषमा पहिले नै अवलोकन गरेका सबै कुराहरू हेर्न सक्नुहुन्छ:

त्यहाँ स्रोतमा तथ्याङ्कहरू छन्, आन्तरिक कलहरूको सामान्यीकृत सूची, र प्रतिक्रिया कोडद्वारा क्रमबद्ध गर्न सकिने अनुरोधहरूको उदाहरणहरू... खैर, हाम्रा इन्जिनियरहरूले यो क्रमबद्धतालाई साँच्चै मन पराए।

Datadog मा कुनै पनि उदाहरण स्रोत खोल्न र अध्ययन गर्न सकिन्छ:

अनुरोध प्यारामिटरहरू, प्रत्येक कम्पोनेन्टमा बिताएको समयको सारांश चार्ट, र कलहरूको क्रम देखाउने झरना चार्ट प्रस्तुत गरिएको छ। तपाईं झरना चार्टको रूख दृश्यमा पनि स्विच गर्न सक्नुहुन्छ:

र सबैभन्दा चाखलाग्दो कुरा होस्टको लोड हेर्नु हो जसमा अनुरोध कार्यान्वयन गरिएको थियो र अनुरोध लगहरू हेर्दै।

महान एकीकरण!

तपाईलाई अचम्म लाग्न सक्छ कि ट्याबहरू कहाँ छन् डेटाबेस и बाह्य सेवाहरू, New Relic मा जस्तै। यहाँ कुनै पनि छैन: Datadog ले एप्लिकेसनलाई कम्पोनेन्टमा विघटन गरेको हुनाले, PostgreSQL लाई विचार गरिनेछ। एक अलग सेवा, र बाह्य सेवाहरूको सट्टा यो खोज्न लायक छ aws.storage (यो प्रत्येक अन्य बाह्य सेवाको लागि समान हुनेछ जुन अनुप्रयोगले पहुँच गर्न सक्छ)।

यहाँ संग एक उदाहरण छ postgres:

अनिवार्य रूपमा हामीले चाहेको सबै कुरा छ:

तपाइँ कुन "सेवा" बाट अनुरोध आएको देख्न सक्नुहुन्छ।

डाटाडगले NGINX Ingress सँग पूर्ण रूपमा एकीकृत हुन्छ र क्लस्टरमा अनुरोध आएको क्षणदेखि नै तपाईंलाई अन्त्य-देखि-अन्त ट्रेसिङ गर्न अनुमति दिन्छ, र तपाईंलाई statsd मेट्रिक्स प्राप्त गर्न, लगहरू सङ्कलन गर्न र होस्ट मेट्रिक्सहरू प्राप्त गर्न अनुमति दिन्छ भनी सम्झाउनु गलत हुनेछैन। ।

Datadog को एक ठूलो प्लस यसको मूल्य हो आकार लिइरहेको छ पूर्वाधार अनुगमन, एपीएम, लग व्यवस्थापन र सिन्थेटिक्स परीक्षणबाट, अर्थात्। तपाईं लचिलो रूपमा आफ्नो योजना चयन गर्न सक्नुहुन्छ।

2.Atatus

एटाटस टोलीले दाबी गर्दछ कि तिनीहरूको सेवा "नयाँ अवशेष जस्तै, तर राम्रो छ।" हेरौं यदि यो साँच्चै हो भने।

मुख्य प्यानल समान देखिन्छ, तर अनुप्रयोगमा प्रयोग गरिएको Redis र memcached निर्धारण गर्न सम्भव थिएन।

APM ले सबै लेनदेनहरू पूर्वनिर्धारित रूपमा चयन गर्छ, यद्यपि सामान्यतया वेब लेनदेनहरू मात्र आवश्यक हुन्छ। Datadog जस्तै, मुख्य प्यानलबाट इच्छित सेवामा नेभिगेट गर्ने कुनै तरिका छैन। यसबाहेक, लेनदेनहरू त्रुटिहरू पछि सूचीबद्ध छन्, जुन APM को लागी धेरै तार्किक लाग्दैन।

Atatus लेनदेनमा, सबै चीजहरू नयाँ रिलिकसँग सम्भव भएसम्म समान छन्। नकारात्मक पक्ष यो हो कि प्रत्येक नियन्त्रकको लागि गतिशीलता तुरुन्तै देखिने छैन। तपाईंले यसलाई नियन्त्रक तालिकामा खोज्नुपर्छ, क्रमबद्ध गर्दै सबैभन्दा धेरै समय खपत हुन्छ:

नियन्त्रकहरूको सामान्य सूची ट्याबमा उपलब्ध छ अन्वेषण:

केहि तरिकामा, यो तालिका Datadog को सम्झना दिलाउँछ र मलाई यो नयाँ Relic मा समान एक भन्दा राम्रो मनपर्छ।

तपाइँ प्रत्येक लेनदेन विस्तार गर्न सक्नुहुन्छ र हेर्न सक्नुहुन्छ कि अनुप्रयोगले के गरिरहेको थियो:

प्यानल पनि Datadog को सम्झना दिलाउने छ: त्यहाँ धेरै अनुरोधहरू छन्, कलहरूको सामान्य चित्र। शीर्ष प्यानलले त्रुटि ट्याब प्रदान गर्दछ HTTP विफलताहरू र ढिलो प्रश्नहरूको उदाहरणहरू सत्र ट्रेसहरू:

यदि तपाइँ लेनदेनमा जानुहुन्छ भने, तपाइँ ट्रेसको उदाहरण देख्न सक्नुहुन्छ, तपाइँ डेटाबेसमा अनुरोधहरूको सूची प्राप्त गर्न सक्नुहुन्छ र अनुरोध हेडरहरू हेर्न सक्नुहुन्छ। सबै नयाँ अवशेष जस्तै छ:

सामान्यतया, एटाटस विस्तृत ट्रेसहरूसँग खुसी भयो - रिमाइन्डर ब्लकमा कलहरूको सामान्य नयाँ अवशेष ग्लुइङ बिना:

यद्यपि, यसमा (नयाँ रेलिक जस्तै) अल्ट्रा-फास्ट अनुरोधहरू (<5ms) काट्ने फिल्टरको अभाव छ। अर्कोतर्फ, मलाई अन्तिम लेनदेन प्रतिक्रिया (सफलता वा त्रुटि) को प्रदर्शन मन पर्यो।

प्यानल डेटाबेस तपाइँलाई बाह्य डाटाबेसहरूमा अनुरोधहरू अध्ययन गर्न मद्दत गर्दछ जुन अनुप्रयोगले गर्दछ। मलाई तपाईलाई सम्झाउन दिनुहोस् कि Atatus ले PostgreSQL र MySQL मात्र फेला पारेको छ, यद्यपि Redis र memcached पनि परियोजनामा ​​संलग्न छन्।

अनुरोधहरू सामान्य मापदण्ड अनुसार क्रमबद्ध हुन्छन्: प्रतिक्रिया आवृत्ति, औसत प्रतिक्रिया समय, र यस्तै। म पनि ढिलो प्रश्नहरूको साथ ट्याब उल्लेख गर्न चाहन्छु - यो धेरै सुविधाजनक छ। यसबाहेक, PostgreSQL को लागि यो ट्याबमा डाटा विस्तारको डाटासँग मेल खान्छ। pg_stat_statements - उत्कृष्ट परिणाम!

ट्याब बाह्य अनुरोधहरू डाटाबेससँग पूर्ण रूपमा समान।

निष्कर्ष

दुबै प्रस्तुत उपकरणहरूले APM को भूमिकामा राम्रो प्रदर्शन गरे। तिनीहरू मध्ये कुनै पनि आवश्यक न्यूनतम प्रस्ताव गर्न सक्नुहुन्छ। हाम्रा प्रभावहरूलाई संक्षिप्त रूपमा निम्नानुसार संक्षेप गर्न सकिन्छ:

डाटाडोग

प्रो:

• सुविधाजनक ट्यारिफ तालिका (APM लागत 31 USD प्रति होस्ट);
• पाइथन संग राम्रो काम;
• OpenTracing संग एकीकरण को संभावना
• Kubernetes के साथ एकीकरण;
• NGINX Ingress के साथ एकीकरण।

Cons:

• मोड्युल त्रुटि (predis) को कारणले अनुप्रयोग अनुपलब्ध भएको एक मात्र APM;
• कमजोर PHP स्वत: उपकरण;
• सेवाहरू र तिनीहरूको उद्देश्यको आंशिक रूपमा अनौठो परिभाषा।

Atatus

प्रो:

• गहिरो PHP उपकरण;
• नयाँ रिलिक जस्तै प्रयोगकर्ता इन्टरफेस।

Cons:

• पुरानो अपरेटिङ सिस्टमहरूमा काम गर्दैन (Ubuntu 12.05, CentOS 5);
• कमजोर स्वचालित उपकरण;
• केवल दुई भाषाहरूको लागि समर्थन (Node.js र PHP);
• ढिलो इन्टरफेस।

प्रति सर्भर प्रति महिना ६९ USD को Atatus को मूल्यलाई ध्यानमा राख्दै, हामी Datadog को प्रयोग गर्छौं, जसले हाम्रा आवश्यकताहरू (K69s मा वेब अनुप्रयोगहरू) सँग राम्रोसँग एकीकृत हुन्छ र धेरै उपयोगी सुविधाहरू छन्।

PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «Kubernetes मा चलिरहेको अनुप्रयोगहरूको विकासकर्ताहरूको लागि उपकरण»;
• «Kubernetes pods मा डिबग गर्न को लागी kubectl-debug प्लगइन»;
• «Microservices: साइजको महत्व हुन्छ, यदि तपाईंसँग Kubernetes छ भने पनि"।

स्रोत: www.habr.com