એકલા નવા અવશેષ નથી: ડેટાડોગ અને એટાટસ પર એક નજર

SRE/DevOps એન્જિનિયરોના વાતાવરણમાં, તે કોઈને આશ્ચર્ય નહીં કરે કે એક દિવસ ક્લાયન્ટ (અથવા મોનિટરિંગ સિસ્ટમ) દેખાય છે અને અહેવાલ આપે છે કે "બધું ખોવાઈ ગયું છે": સાઇટ કામ કરતી નથી, ચૂકવણી થતી નથી, જીવન ક્ષીણ થઈ રહ્યું છે. ... આવી પરિસ્થિતિમાં તમે ગમે તેટલી મદદ કરવા માંગતા હોવ તો પણ, સરળ અને સમજી શકાય તેવા સાધન વિના આ કરવું ખૂબ જ મુશ્કેલ બની શકે છે. ઘણીવાર સમસ્યા એપ્લીકેશન કોડમાં જ છુપાયેલી હોય છે; તમારે ફક્ત તેને સ્થાનિકીકરણ કરવાની જરૂર છે.

અને દુઃખ અને આનંદમાં...

એવું બન્યું કે અમે ન્યૂ રેલિક સાથે લાંબા અને ઊંડે પ્રેમમાં પડ્યા છીએ. તે એપ્લીકેશનની કામગીરીને મોનિટર કરવા માટે એક ઉત્તમ સાધન હતું અને રહે છે, અને તમને માઇક્રોસર્વિસ આર્કિટેક્ચર (તેના એજન્ટનો ઉપયોગ કરીને) અને ઘણું બધું કરવા માટે પણ પરવાનગી આપે છે. અને જો તે સેવાની કિંમત નીતિમાં ફેરફાર માટે ન હોત તો બધું સરસ બની શક્યું હોત: તે ખર્ચ 2013 વર્ષથી 3+ ગણો વધ્યો. વધુમાં, ગયા વર્ષથી, ટ્રાયલ એકાઉન્ટ મેળવવા માટે વ્યક્તિગત મેનેજર સાથે સંચારની જરૂર છે, જે સંભવિત ગ્રાહકને ઉત્પાદન પ્રસ્તુત કરવાનું મુશ્કેલ બનાવે છે.

સામાન્ય પરિસ્થિતિ: "કાયમી ધોરણે" નવા અવશેષની જરૂર નથી; જ્યારે સમસ્યાઓ શરૂ થાય ત્યારે જ તેઓ તેને યાદ કરે છે. પરંતુ તમારે હજુ પણ નિયમિતપણે ચૂકવણી કરવાની જરૂર છે (દર મહિને સર્વર દીઠ 140 USD), અને આપમેળે સ્કેલિંગ ક્લાઉડ ઇન્ફ્રાસ્ટ્રક્ચરમાં રકમો ઘણી મોટી છે. પે-એઝ-યુ-ગો વિકલ્પ હોવા છતાં, ન્યૂ રેલિકને સક્ષમ કરવા માટે તમારે એપ્લિકેશનને ફરીથી શરૂ કરવાની જરૂર પડશે, જે સમસ્યારૂપ પરિસ્થિતિને ગુમાવી શકે છે જેના માટે તે બધું શરૂ કરવામાં આવ્યું હતું. થોડા સમય પહેલા, ન્યૂ રેલિકે એક નવો ટેરિફ પ્લાન રજૂ કર્યો હતો - એસેન્શિયલ્સ, - જે પ્રથમ નજરમાં પ્રોફેશનલ માટે વાજબી વિકલ્પ જેવું લાગે છે... પરંતુ નજીકથી તપાસ કરવા પર તે બહાર આવ્યું કે કેટલાક મહત્વપૂર્ણ કાર્યો ખૂટે છે (ખાસ કરીને, તેની પાસે નથી મુખ્ય વ્યવહારો, ક્રોસ એપ્લિકેશન ટ્રેસિંગ, વિતરિત ટ્રેસિંગ).

પરિણામે, અમે સસ્તો વિકલ્પ શોધવા વિશે વિચારવાનું શરૂ કર્યું, અને અમારી પસંદગી બે સેવાઓ પર પડી: Datadog અને Atatus. શા માટે તેમના પર?

સ્પર્ધકો વિશે

મને હમણાં જ કહેવા દો કે બજારમાં અન્ય ઉકેલો છે. અમે ઓપન સોર્સ વિકલ્પોનો પણ વિચાર કર્યો છે, પરંતુ દરેક ક્લાયન્ટને સ્વ-હોસ્ટેડ સોલ્યુશન્સ હોસ્ટ કરવાની મફત ક્ષમતા હોતી નથી... - વધુમાં, તેમને વધારાની જાળવણીની જરૂર પડશે. અમે જે યુગલને પસંદ કર્યું તે સૌથી નજીકનું હતું અમારી જરૂરિયાતો:

• PHP એપ્લિકેશન્સ માટે બિલ્ટ-ઇન અને વિકસિત સપોર્ટ (અમારા ક્લાયન્ટ્સનો સ્ટેક ખૂબ જ વૈવિધ્યસભર છે, પરંતુ આ ન્યૂ રેલિકના વિકલ્પની શોધના સંદર્ભમાં સ્પષ્ટ નેતા છે);
• સસ્તું ખર્ચ (યજમાન દીઠ દર મહિને 100 USD કરતાં ઓછો);
• સ્વચાલિત સાધન;
• કુબરનેટ્સ સાથે એકીકરણ;
• ન્યૂ રેલિક ઇન્ટરફેસની સમાનતા એ નોંધપાત્ર વત્તા છે (કારણ કે અમારા એન્જિનિયરો તેનો ઉપયોગ કરે છે).

તેથી, પ્રારંભિક પસંદગીના તબક્કે, અમે અન્ય કેટલાક લોકપ્રિય ઉકેલોને દૂર કર્યા, અને ખાસ કરીને:

• Tideways, AppDynamics અને Dynatrace - ખર્ચ માટે;
• Stackify રશિયન ફેડરેશનમાં અવરોધિત છે અને ખૂબ ઓછો ડેટા બતાવે છે.

બાકીના લેખની રચના એવી રીતે કરવામાં આવી છે કે પ્રશ્નમાંના ઉકેલો સૌપ્રથમ સંક્ષિપ્તમાં રજૂ કરવામાં આવશે, ત્યારબાદ હું ન્યૂ રેલિક સાથેની અમારી લાક્ષણિક ક્રિયાપ્રતિક્રિયા અને અન્ય સેવાઓમાં સમાન કામગીરી કરવાના અનુભવ/પ્રભાવ વિશે વાત કરીશ.

પસંદ કરેલા સ્પર્ધકોની રજૂઆત

પર નવું અવશેષ, કદાચ બધાએ સાંભળ્યું હશે? આ સેવા તેના વિકાસની શરૂઆત 10 કરતાં વધુ વર્ષ પહેલાં, 2008 માં થઈ હતી. અમે 2012 થી સક્રિયપણે તેનો ઉપયોગ કરી રહ્યા છીએ અને PHP, રૂબી અને પાયથોનમાં ખરેખર મોટી સંખ્યામાં એપ્લિકેશનોને એકીકૃત કરવામાં અમને કોઈ સમસ્યા નથી અને અમને C# અને Go સાથે સંકલન કરવાનો અનુભવ પણ મળ્યો છે. સેવાના લેખકો પાસે મોનિટરિંગ એપ્લીકેશન, ઇન્ફ્રાસ્ટ્રક્ચર, માઇક્રોસર્વિસ ઇન્ફ્રાસ્ટ્રક્ચરને ટ્રેસ કરવા, વપરાશકર્તા ઉપકરણો માટે અનુકૂળ એપ્લિકેશનો બનાવવા અને ઘણું બધું માટે ઉકેલો છે.

જો કે, ન્યૂ રેલિક એજન્ટ માલિકીના પ્રોટોકોલ પર ચાલે છે અને ઓપનટ્રેસિંગને સપોર્ટ કરતું નથી. અદ્યતન ઇન્સ્ટ્રુમેન્ટેશન માટે ખાસ કરીને ન્યૂ રેલિક માટે સંપાદનની જરૂર છે. છેલ્લે, કુબરનેટ્સ સપોર્ટ હજુ પણ પ્રાયોગિક છે.

2010 માં તેનો વિકાસ શરૂ થયો ડેટાડોગ Kubernetes વાતાવરણમાં ઉપયોગની દ્રષ્ટિએ ચોક્કસપણે ન્યૂ રેલિક કરતાં નોંધપાત્ર રીતે વધુ રસપ્રદ લાગે છે. ખાસ કરીને, તે NGINX ઇન્ગ્રેસ, લોગ કલેક્શન, statsd અને OpenTracing પ્રોટોકોલ્સ સાથે એકીકરણને સમર્થન આપે છે, જે તમને વપરાશકર્તાની વિનંતીને પૂર્ણ થવાથી કનેક્ટ કરવાની ક્ષણથી ટ્રૅક કરવા માટે પરવાનગી આપે છે, તેમજ આ વિનંતી માટે લૉગ્સ શોધી શકે છે (બંને વેબ સર્વર બાજુ પર. અને ઉપભોક્તા પર).

ડેટાડોગનો ઉપયોગ કરતી વખતે, અમારે એવું જણાયું કે તે કેટલીકવાર માઇક્રોસર્વિસ મેપને ખોટી રીતે બનાવે છે, અને કેટલીક તકનીકી ખામીઓ. ઉદાહરણ તરીકે, તેણે સેવાના પ્રકારને ખોટી રીતે ઓળખ્યો (કેશિંગ સેવા માટે Django ભૂલથી) અને લોકપ્રિય પ્રિડિસ લાઇબ્રેરીનો ઉપયોગ કરીને PHP એપ્લિકેશનમાં 500 ભૂલો થઈ.

એટાટસ - સૌથી નાનું સાધન; આ સેવા 2014 માં શરૂ કરવામાં આવી હતી. તેનું માર્કેટિંગ બજેટ સૂચિબદ્ધ સ્પર્ધકો કરતાં સ્પષ્ટપણે હલકી ગુણવત્તાવાળા છે, ઉલ્લેખો ખૂબ ઓછા સામાન્ય છે. જો કે, ટૂલ પોતે ન્યૂ રેલિક જેવું જ છે, માત્ર તેની ક્ષમતાઓ (APM, બ્રાઉઝર મોનિટરિંગ, વગેરે) માં જ નહીં, પણ દેખાવમાં પણ.

એક નોંધપાત્ર ખામી એ છે કે તે માત્ર Node.js અને PHP ને સપોર્ટ કરે છે. બીજી બાજુ, તે Datadog કરતાં નોંધપાત્ર રીતે વધુ સારી રીતે લાગુ કરવામાં આવે છે. બાદમાંથી વિપરીત, એટાટસને કોડમાં ફેરફાર કરવા અથવા વધારાના લેબલ્સ ઉમેરવા માટે એપ્લિકેશનની જરૂર નથી.

અમે ન્યૂ રેલિક સાથે કેવી રીતે કામ કરીએ છીએ

હવે ચાલો જાણીએ કે આપણે સામાન્ય રીતે ન્યૂ રેલિકનો ઉપયોગ કેવી રીતે કરીએ છીએ. ચાલો કહીએ કે અમારી પાસે એક સમસ્યા છે જેને ઉકેલની જરૂર છે:

તે ગ્રાફ પર જોવાનું સરળ છે всплеск - ચાલો તેનું વિશ્લેષણ કરીએ. ન્યૂ રેલિકમાં, વેબ એપ્લિકેશન માટે વેબ વ્યવહારો તરત જ પસંદ કરવામાં આવે છે, બધા ઘટકો પ્રદર્શન ગ્રાફમાં સૂચવવામાં આવે છે, ત્યાં ભૂલ-દર, વિનંતી-દર પેનલ્સ છે... સૌથી મહત્ત્વની બાબત એ છે કે આ પેનલ્સમાંથી તમે સીધા જ વિવિધ વચ્ચે ખસેડી શકો છો. એપ્લિકેશનના ભાગો (ઉદાહરણ તરીકે, MySQL પર ક્લિક કરવાથી ડેટાબેઝ વિભાગ તરફ દોરી જશે).

કારણ કે વિચારણા હેઠળના ઉદાહરણમાં આપણે પ્રવૃત્તિમાં ઉછાળો જોઈએ છીએ PHP, આ ચાર્ટ પર ક્લિક કરો અને આપમેળે જાઓ વ્યવહારો:

વ્યવહારોની સૂચિ, જે અનિવાર્યપણે MVC મોડલના નિયંત્રકો છે, તે પહેલાથી જ દ્વારા સૉર્ટ કરેલ છે સૌથી વધુ સમય માંગી લે છે, જે ખૂબ અનુકૂળ છે: અમે તરત જ જોઈએ છીએ કે એપ્લિકેશન શું કરે છે. અહીં લાંબા પ્રશ્નોના ઉદાહરણો છે જે ન્યૂ રેલિક દ્વારા આપમેળે એકત્રિત કરવામાં આવે છે. સૉર્ટિંગને સ્વિચ કરીને, તે શોધવાનું સરળ છે:

• સૌથી વધુ લોડ થયેલ એપ્લિકેશન નિયંત્રક;
• સૌથી વધુ વારંવાર વિનંતી કરાયેલ નિયંત્રક;
• નિયંત્રકોમાં સૌથી ધીમું.

વધુમાં, તમે દરેક ટ્રાન્ઝેક્શનને વિસ્તૃત કરી શકો છો અને કોડ એક્ઝિક્યુટ કરવામાં આવ્યો ત્યારે એપ્લિકેશન શું કરી રહી હતી તે જોઈ શકો છો:

છેલ્લે, એપ્લિકેશન લાંબી વિનંતીઓ (જે 2 સેકન્ડથી વધુ સમય લે છે) ના ટ્રેસના ઉદાહરણો સ્ટોર કરે છે. લાંબા વ્યવહાર માટે અહીં પેનલ છે:

તે જોઈ શકાય છે કે બે પદ્ધતિઓ ઘણો સમય લે છે, અને તે જ સમયે જ્યારે વિનંતી એક્ઝિક્યુટ કરવામાં આવી હતી, તેના URI અને ડોમેન પણ બતાવવામાં આવે છે. ઘણી વાર આ લૉગમાં વિનંતી શોધવામાં મદદ કરે છે. જઈ રહ્યો છુ વિગતો ટ્રેસ કરો, તમે જોઈ શકો છો કે આ પદ્ધતિઓ ક્યાંથી મંગાવવામાં આવે છે:

અને સાઇન ડેટાબેઝ પ્રશ્નો ડેટાબેસેસ માટે ક્વેરીઝનું મૂલ્યાંકન કરો કે જે એપ્લિકેશન ચાલી રહી હતી ત્યારે એક્ઝિક્યુટ કરવામાં આવી હતી:

આ જ્ઞાનથી સજ્જ, અમે મૂલ્યાંકન કરી શકીએ છીએ કે એપ્લિકેશન શા માટે ધીમી પડી રહી છે અને સમસ્યાને ઉકેલવા માટેની વ્યૂહરચના સાથે આવવા માટે વિકાસકર્તા સાથે કામ કરી શકીએ છીએ. વાસ્તવમાં, ન્યૂ રેલિક હંમેશા સ્પષ્ટ ચિત્ર આપતું નથી, પરંતુ તે તપાસના વેક્ટરને પસંદ કરવામાં મદદ કરે છે:

• લાંબી PDO::Construct અમને pgpoll ની વિચિત્ર કામગીરી તરફ દોરી ગયા;
• સમય જતાં અસ્થિરતા Memcache::Get સૂચવ્યું કે વર્ચ્યુઅલ મશીન ખોટી રીતે ગોઠવેલ છે;
• ટેમ્પલેટ પ્રોસેસિંગ માટે શંકાસ્પદ રીતે વધેલા સમયને કારણે ઑબ્જેક્ટ સ્ટોરેજમાં 500 અવતારની હાજરી તપાસવા માટે નેસ્ટેડ લૂપ તરફ દોરી જાય છે;
• વગેરે…

એવું પણ બને છે કે કોડ ચલાવવાને બદલે, બાહ્ય ડેટા સ્ટોરેજને લગતું કંઈક મુખ્ય સ્ક્રીન પર વધે છે - અને તે શું હશે તે કોઈ વાંધો નથી: Redis અથવા PostgreSQL - તે બધા ટેબમાં છુપાયેલા છે. ડેટાબેસેસ.

તમે સંશોધન અને સૉર્ટ પ્રશ્નો માટે ચોક્કસ આધાર પસંદ કરી શકો છો - તે વ્યવહારોમાં કેવી રીતે કરવામાં આવે છે તેના જેવું જ. અને વિનંતી ટેબ પર જઈને, તમે જોઈ શકો છો કે દરેક એપ્લિકેશન નિયંત્રકોમાં આ વિનંતી કેટલી વાર આવે છે, અને તે કેટલી વાર કૉલ કરવામાં આવે છે તેનો અંદાજ પણ લગાવી શકો છો. તે ખૂબ આરામદાયક છે:

ટેબમાં સમાન ડેટા છે બાહ્ય સેવાઓ, જે બાહ્ય HTTP સેવાઓની વિનંતીઓને છુપાવે છે, જેમ કે ઑબ્જેક્ટ સ્ટોરેજને ઍક્સેસ કરવી, સંત્રીને ઇવેન્ટ્સ મોકલવી, અથવા તેના જેવી. ટેબની સામગ્રી સંપૂર્ણપણે ડેટાબેસેસ જેવી જ છે:

સ્પર્ધકો: તકો અને છાપ

હવે સૌથી રસપ્રદ બાબત એ છે કે સ્પર્ધકો જે ઓફર કરે છે તેની સાથે ન્યૂ રેલિકની ક્ષમતાઓની તુલના કરવી. કમનસીબે, અમે પ્રોડક્શનમાં ચાલી રહેલી એક એપ્લિકેશનના એક વર્ઝન પર ત્રણેય ટૂલ્સનું પરીક્ષણ કરવામાં સક્ષમ ન હતા. જો કે, અમે શક્ય તેટલી સમાન પરિસ્થિતિઓ/રૂપરેખાંકનોની તુલના કરવાનો પ્રયાસ કર્યો.

1. ડેટાડોગ

ડેટાડોગ સેવાઓની દિવાલ સાથેની પેનલ સાથે અમને આવકારે છે:

તે એપ્લીકેશનને ઘટકો/માઈક્રોસર્વિસીસમાં તોડવાનો પ્રયાસ કરે છે, તેથી ઉદાહરણમાં જેંગો એપ્લિકેશનમાં આપણે PostgreSQL સાથે 2 જોડાણો જોઈશું (defaultdb и postgres), તેમજ સેલરી, રેડિસ. ડેટાડોગ સાથે કામ કરવા માટે તમારે MVC સિદ્ધાંતોનું ન્યૂનતમ જ્ઞાન હોવું જરૂરી છે: તમારે સમજવું જરૂરી છે કે વપરાશકર્તાની વિનંતીઓ સામાન્ય રીતે ક્યાંથી આવે છે. આ સામાન્ય રીતે મદદ કરે છે સેવાઓનો નકશો:

માર્ગ દ્વારા, ન્યૂ રેલિકમાં કંઈક સમાન છે:

... અને તેમના નકશાને, મારા મતે, સરળ અને સ્પષ્ટ બનાવવામાં આવ્યો છે: તે એક એપ્લિકેશનના ઘટકોને પ્રદર્શિત કરતું નથી (જે તેને વધુ પડતું વિગતવાર બનાવે છે, જેમ કે ડેટાડોગના કિસ્સામાં), પરંતુ માત્ર ચોક્કસ સેવાઓ અથવા માઇક્રોસેવાઓ.

ચાલો ડેટાડોગ પર પાછા આવીએ: સર્વિસ મેપ પરથી આપણે જોઈ શકીએ છીએ કે યુઝર વિનંતીઓ જેંગો પર આવે છે. ચાલો Django સેવા પર જઈએ અને છેલ્લે જોઈએ કે આપણે શું અપેક્ષા રાખીએ છીએ:

કમનસીબે, અહીં મૂળભૂત રીતે કોઈ ગ્રાફ નથી વેબ વ્યવહાર સમય, આપણે મુખ્ય ન્યૂ રેલિક પેનલ પર જે જોઈએ છીએ તેના જેવું જ. જો કે, તે શેડ્યૂલની જગ્યાએ ગોઠવી શકાય છે વિતાવેલ સમયનો %. તેના પર સ્વિચ કરવા માટે તે પૂરતું છે પ્રકાર દ્વારા વિનંતી દીઠ સરેરાશ સમય... અને હવે પરિચિત આલેખ આપણી તરફ જોઈ રહ્યો છે!

Datadog શા માટે એક અલગ ચાર્ટ પસંદ કર્યો તે અમારા માટે એક રહસ્ય છે. બીજી નિરાશાજનક બાબત એ છે કે સિસ્ટમ વપરાશકર્તાની પસંદગીને યાદ રાખતી નથી (બંને સ્પર્ધકોથી વિપરીત), અને તેથી એકમાત્ર ઉકેલ કસ્ટમ પેનલ્સ બનાવવાનો છે.

પરંતુ ડેટાડોગમાં આ ગ્રાફમાંથી સંબંધિત સર્વરના મેટ્રિક્સ પર સ્વિચ કરવાની, લૉગ્સ વાંચવાની અને વેબ સર્વર હેન્ડલર્સ (ગ્યુનિકોર્ન) પરના ભારનું મૂલ્યાંકન કરવાની ક્ષમતાથી મને આનંદ થયો. બધું લગભગ ન્યૂ રેલિક જેવું જ છે... અને તેનાથી પણ થોડું વધારે (લોગ)!

ગ્રાફની નીચે સંપૂર્ણપણે ન્યૂ રેલિક જેવા વ્યવહારો છે:

ડેટાડોગમાં, વ્યવહારો કહેવામાં આવે છે સંસાધનો. તમે વિનંતિઓની સંખ્યા દ્વારા, સરેરાશ પ્રતિસાદ સમય દ્વારા અને પસંદ કરેલ સમયગાળા માટે વિતાવેલા મહત્તમ સમય દ્વારા નિયંત્રકોને સૉર્ટ કરી શકો છો.

તમે સંસાધનને વિસ્તૃત કરી શકો છો અને તે બધું જોઈ શકો છો જે અમે પહેલાથી જ ન્યૂ રેલિકમાં જોયું છે:

સંસાધન પર આંકડાઓ છે, આંતરિક કૉલ્સની સામાન્ય સૂચિ, અને વિનંતીઓના ઉદાહરણો છે જે પ્રતિસાદ કોડ દ્વારા સૉર્ટ કરી શકાય છે... માર્ગ દ્વારા, અમારા એન્જિનિયરોને આ સૉર્ટિંગ ખરેખર ગમ્યું.

ડેટાડોગમાં કોઈપણ ઉદાહરણ સંસાધન ખોલી અને અભ્યાસ કરી શકાય છે:

વિનંતીના પરિમાણો, દરેક ઘટક પર વિતાવેલ સમયનો સારાંશ ચાર્ટ અને કોલનો ક્રમ દર્શાવતો વોટરફોલ ચાર્ટ રજૂ કરવામાં આવ્યો છે. તમે વોટરફોલ ચાર્ટના ટ્રી વ્યૂ પર પણ સ્વિચ કરી શકો છો:

અને સૌથી રસપ્રદ બાબત એ હોસ્ટના લોડને જોવાનું છે કે જેના પર વિનંતી કરવામાં આવી હતી અને વિનંતી લૉગ્સ જોવી.

મહાન એકીકરણ!

તમને આશ્ચર્ય થશે કે ટેબ્સ ક્યાં છે ડેટાબેસેસ и બાહ્ય સેવાઓ, ન્યૂ રેલિકની જેમ. અહીં કોઈ નથી: ડેટાડોગ એપ્લિકેશનને ઘટકોમાં વિઘટિત કરે છે, પોસ્ટગ્રેએસક્યુએલ ધ્યાનમાં લેવામાં આવશે એક અલગ સેવા, અને બાહ્ય સેવાઓને બદલે તે શોધવા યોગ્ય છે aws.storage (તે દરેક અન્ય બાહ્ય સેવા માટે સમાન હશે જે એપ્લિકેશન ઍક્સેસ કરી શકે છે).

અહીં સાથે એક ઉદાહરણ છે postgres:

અનિવાર્યપણે ત્યાં બધું છે જે આપણે ઇચ્છીએ છીએ:

તમે જોઈ શકો છો કે વિનંતી કઈ "સેવા" તરફથી આવી છે.

તમને યાદ કરાવવાનું ખોટું નથી કે ડેટાડોગ NGINX ઇન્ગ્રેસ સાથે સંપૂર્ણ રીતે સંકલિત થાય છે અને ક્લસ્ટરમાં વિનંતી આવે ત્યારથી તમને એન્ડ-ટુ-એન્ડ ટ્રેસિંગ કરવાની મંજૂરી આપે છે, અને તમને સ્ટેટ્સડી મેટ્રિક્સ પ્રાપ્ત કરવા, લૉગ્સ એકત્રિત કરવા અને હોસ્ટ મેટ્રિક્સ મેળવવાની પણ મંજૂરી આપે છે. .

ડેટાડોગનો એક મોટો ફાયદો એ તેની કિંમત છે વિકાસ કરે છે ઇન્ફ્રાસ્ટ્રક્ચર મોનિટરિંગ, APM, લોગ મેનેજમેન્ટ અને સિન્થેટીક્સ ટેસ્ટ, એટલે કે. તમે તમારી યોજનાને લવચીક રીતે પસંદ કરી શકો છો.

2.એટાટસ

એટાટસ ટીમ દાવો કરે છે કે તેમની સેવા "ન્યૂ રેલિક જેવી જ છે, પરંતુ વધુ સારી છે." ચાલો જોઈએ કે આ ખરેખર આવું છે.

મુખ્ય પેનલ સમાન દેખાય છે, પરંતુ એપ્લિકેશનમાં વપરાયેલ Redis અને memcached નક્કી કરવું શક્ય ન હતું.

APM મૂળભૂત રીતે તમામ વ્યવહારો પસંદ કરે છે, જો કે સામાન્ય રીતે માત્ર વેબ વ્યવહારોની જરૂર હોય છે. ડેટાડોગની જેમ, મુખ્ય પેનલમાંથી ઇચ્છિત સેવા પર નેવિગેટ કરવાની કોઈ રીત નથી. વધુમાં, ટ્રાન્ઝેક્શન ભૂલો પછી સૂચિબદ્ધ છે, જે APM માટે બહુ તાર્કિક લાગતું નથી.

Atatus વ્યવહારોમાં, બધું શક્ય તેટલું ન્યૂ રેલિક જેવું જ છે. નુકસાન એ છે કે દરેક નિયંત્રક માટે ગતિશીલતા તરત જ દેખાતી નથી. તમારે તેને કંટ્રોલર ટેબલમાં જોવાનું છે, તેના દ્વારા વર્ગીકરણ કરવું સૌથી વધુ સમય વપરાતો:

નિયંત્રકોની સામાન્ય સૂચિ ટેબમાં ઉપલબ્ધ છે અન્વેષણ:

કેટલીક રીતે, આ ટેબલ ડેટાડોગની યાદ અપાવે છે અને મને તે ન્યૂ રેલિકમાં સમાન ટેબલ કરતાં વધુ ગમે છે.

તમે દરેક વ્યવહારને વિસ્તૃત કરી શકો છો અને એપ્લિકેશન શું કરી રહી હતી તે જોઈ શકો છો:

પેનલ ડેટાડોગની વધુ યાદ અપાવે છે: ત્યાં સંખ્યાબંધ વિનંતીઓ છે, કૉલ્સનું સામાન્ય ચિત્ર. ટોચની પેનલ ભૂલ ટેબ પ્રદાન કરે છે HTTP નિષ્ફળતાઓ અને ધીમા પ્રશ્નોના ઉદાહરણો સત્ર ટ્રેસ:

જો તમે ટ્રાન્ઝેક્શન પર જાઓ છો, તો તમે ટ્રેસનું ઉદાહરણ જોઈ શકો છો, તમે ડેટાબેઝની વિનંતીઓની સૂચિ મેળવી શકો છો અને વિનંતી હેડરો જોઈ શકો છો. બધું ન્યૂ રેલિક જેવું જ છે:

સામાન્ય રીતે, એટાટસ વિગતવાર નિશાનોથી ખુશ છે - રિમાઇન્ડર બ્લોકમાં કૉલના વિશિષ્ટ નવા અવશેષને ગ્લુઇંગ કર્યા વિના:

જો કે, તેમાં ફિલ્ટરનો અભાવ છે જે (ન્યૂ રેલિકની જેમ) અલ્ટ્રા-ફાસ્ટ વિનંતીઓ (<5ms)ને કાપી નાખશે. બીજી બાજુ, મને અંતિમ વ્યવહાર પ્રતિભાવ (સફળતા અથવા ભૂલ) નું પ્રદર્શન ગમ્યું.

પેનલ ડેટાબેસેસ બાહ્ય ડેટાબેસેસની વિનંતીઓનો અભ્યાસ કરવામાં તમને મદદ કરશે જે એપ્લિકેશન બનાવે છે. હું તમને યાદ અપાવી દઉં કે Atatus ને માત્ર PostgreSQL અને MySQL જ મળ્યું, જોકે Redis અને memcached પણ પ્રોજેક્ટમાં સામેલ છે.

વિનંતિઓને સામાન્ય માપદંડો અનુસાર સૉર્ટ કરવામાં આવે છે: પ્રતિભાવ આવર્તન, સરેરાશ પ્રતિસાદ સમય, અને તેથી વધુ. હું સૌથી ધીમી ક્વેરીઝ સાથે ટેબનો પણ ઉલ્લેખ કરવા માંગુ છું - તે ખૂબ અનુકૂળ છે. વધુમાં, PostgreSQL માટે આ ટેબમાંનો ડેટા એક્સ્ટેંશનના ડેટા સાથે એકરુપ છે pg_stat_statements - ઉત્તમ પરિણામ!

ટેબ બાહ્ય વિનંતીઓ સંપૂર્ણપણે ડેટાબેસેસ સમાન.

તારણો

બંને પ્રસ્તુત સાધનોએ એપીએમની ભૂમિકામાં સારું પ્રદર્શન કર્યું. તેમાંથી કોઈપણ જરૂરી ન્યૂનતમ ઓફર કરી શકે છે. અમારી છાપનો ટૂંકમાં સારાંશ નીચે મુજબ કરી શકાય છે:

ડેટાડોગ

ગુણ:

• અનુકૂળ ટેરિફ શેડ્યૂલ (APM ની કિંમત હોસ્ટ દીઠ 31 USD છે);
• પાયથોન સાથે સારી રીતે કામ કર્યું;
• OpenTracing સાથે એકીકરણની શક્યતા
• કુબરનેટ્સ સાથે એકીકરણ;
• NGINX ઇન્ગ્રેસ સાથે એકીકરણ.

વિપક્ષ:

• એકમાત્ર APM જે મોડ્યુલ ભૂલ (predis) ને કારણે એપ્લિકેશન અનુપલબ્ધ થવાનું કારણ બને છે;
• નબળા PHP ઓટો-ઇન્સ્ટ્રુમેન્ટેશન;
• સેવાઓ અને તેમના હેતુની અંશતઃ વિચિત્ર વ્યાખ્યા.

એટાટસ

ગુણ:

• ડીપ PHP ઇન્સ્ટ્રુમેન્ટેશન;
• ન્યૂ રેલિક જેવું જ યુઝર ઇન્ટરફેસ.

વિપક્ષ:

• જૂની ઓપરેટિંગ સિસ્ટમ્સ પર કામ કરતું નથી (Ubuntu 12.05, CentOS 5);
• નબળા ઓટો-ઇન્સ્ટ્રુમેન્ટેશન;
• માત્ર બે ભાષાઓ માટે સપોર્ટ (Node.js અને PHP);
• ધીમો ઈન્ટરફેસ.

એટાટસની સર્વર દીઠ 69 યુએસડીની કિંમતને ધ્યાનમાં લેતા, અમે તેના બદલે ડેટાડોગનો ઉપયોગ કરીશું, જે અમારી જરૂરિયાતો (K8s માં વેબ એપ્લિકેશન) સાથે સારી રીતે સંકલિત છે અને તેમાં ઘણી ઉપયોગી સુવિધાઓ છે.

PS

અમારા બ્લોગ પર પણ વાંચો:

• «કુબરનેટ્સ પર ચાલતી એપ્લિકેશનના વિકાસકર્તાઓ માટેના સાધનો»;
• «Kubernetes પોડ્સમાં ડિબગીંગ માટે kubectl-debug પ્લગઇન»;
• «માઇક્રોસર્વિસિસ: તમારી પાસે કુબરનેટ્સ હોય તો પણ, કદ મહત્વપૂર્ણ છે».

સોર્સ: www.habr.com