વિતરિત ટ્રેસિંગ: અમે તે બધું ખોટું કર્યું

નૉૅધ. અનુવાદ: આ સામગ્રીના લેખક સિન્ડી શ્રીધરન છે, જે imgix પર એન્જિનિયર છે જે API વિકાસ અને ખાસ કરીને માઇક્રોસર્વિસ પરીક્ષણમાં નિષ્ણાત છે. આ સામગ્રીમાં, તેણીએ વિતરિત ટ્રેસીંગના ક્ષેત્રમાં વર્તમાન સમસ્યાઓની તેણીની વિગતવાર દ્રષ્ટિ શેર કરી છે, જ્યાં તેણીના મતે, દબાવી દેવાની સમસ્યાઓ હલ કરવા માટે ખરેખર અસરકારક સાધનોનો અભાવ છે.

[ચિત્રમાંથી લેવામાં આવ્યું છે અન્ય સામગ્રી વિતરિત ટ્રેસિંગ વિશે.]

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

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

જો કે, જો આપણે કલ્પના કરીએ કે આ બધી સમસ્યાઓ હલ થઈ ગઈ છે, તો ઉચ્ચ સંભાવના છે કે આના સંદર્ભમાં કંઈપણ નોંધપાત્ર રીતે બદલાશે નહીં. અંતિમ વપરાશકર્તા અનુભવ. સૌથી સામાન્ય ડિબગીંગ દૃશ્યોમાં ટ્રેસીંગ હજુ પણ વ્યવહારુ ઉપયોગનું ન હોઈ શકે - તે જમાવવામાં આવ્યા પછી પણ.

આવા અલગ ટ્રેસ

વિતરિત ટ્રેસિંગમાં કેટલાક વિષમ ઘટકોનો સમાવેશ થાય છે:

• એપ્લીકેશન અને મિડલવેરને નિયંત્રણ સાધનોથી સજ્જ કરવું;
• વિતરિત સંદર્ભ ટ્રાન્સફર;
• નિશાનોનો સંગ્રહ;
• ટ્રેસ સ્ટોરેજ;
• તેમના નિષ્કર્ષણ અને વિઝ્યુલાઇઝેશન.

ડિસ્ટ્રિબ્યુટેડ ટ્રેસિંગ વિશે ઘણી બધી વાતો તેને એક પ્રકારની યુનરી ઓપરેશન તરીકે ગણવામાં આવે છે જેનો એકમાત્ર હેતુ સિસ્ટમનું સંપૂર્ણ નિદાન કરવામાં મદદ કરવાનો છે. આ મોટે ભાગે વિતરિત ટ્રેસિંગ વિશેના વિચારો ઐતિહાસિક રીતે કેવી રીતે રચાયા છે તેના કારણે છે. IN બ્લોગ એન્ટ્રીઓ, જ્યારે Zipkin સ્ત્રોતો ખોલવામાં આવ્યા હતા, તે ઉલ્લેખ કરવામાં આવ્યો હતો કે તે [ઝિપકીન] ટ્વિટરને ઝડપી બનાવે છે. ટ્રેસીંગ માટેની પ્રથમ વ્યાપારી તકોને પણ તરીકે પ્રમોટ કરવામાં આવી હતી APM સાધનો.

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

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

ટ્રેસમાં અતિ મૂલ્યવાન ડેટા હોય છે જે ઉત્પાદન પરીક્ષણ, આપત્તિ પુનઃપ્રાપ્તિ પરીક્ષણ, ભૂલ ઇન્જેક્શન પરીક્ષણ વગેરે જેવા કાર્યોમાં મદદ કરી શકે છે. હકીકતમાં, કેટલીક કંપનીઓ પહેલાથી જ સમાન હેતુઓ માટે ટ્રેસિંગનો ઉપયોગ કરે છે. સાથે શરૂઆત કરીએ સાર્વત્રિક સંદર્ભ ટ્રાન્સફર સ્ટોરેજ સિસ્ટમમાં સ્પાન્સને ખસેડવા સિવાય અન્ય ઉપયોગો છે:

• ઉદાહરણ તરીકે, ઉબેર ઉપયોગ કરે છે પરીક્ષણ ટ્રાફિક અને ઉત્પાદન ટ્રાફિક વચ્ચે તફાવત કરવા માટે પરિણામો ટ્રેસિંગ.
• ફેસબુક ઉપયોગ કરે છે નિયમિત આપત્તિ પુનઃપ્રાપ્તિ પરીક્ષણો દરમિયાન જટિલ પાથ વિશ્લેષણ અને ટ્રાફિક સ્વિચિંગ માટે ડેટા ટ્રેસ કરો.
• સોશિયલ નેટવર્ક પણ લાગુ પડે છે Jupyter નોટબુક્સ કે જે વિકાસકર્તાઓને ટ્રેસ પરિણામો પર મનસ્વી ક્વેરીઝ ચલાવવાની મંજૂરી આપે છે.
• અનુયાયીઓ એલડીએફઆઈ (વંશ આધારિત નિષ્ફળતા ઇન્જેક્શન) ઉપયોગ કરો ભૂલ ઇન્જેક્શન સાથે પરીક્ષણ માટે વિતરિત નિશાનો.

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

જ્યારે તે આવે છે હજુ સુધી ડિબગીંગ સ્ક્રિપ્ટ સુધી પહોંચે છે, પ્રાથમિક ઈન્ટરફેસ ડાયાગ્રામ રહે છે ટ્રેસવ્યુ (જોકે કેટલાક તેને કહે છે "ગેંટ ચાર્ટ" અથવા "ધોધ ડાયાગ્રામ"). હેઠળ ટ્રેસવ્યુ я મારો મતલબ છે તમામ સ્પાન્સ અને તેની સાથેનો મેટાડેટા જે એકસાથે ટ્રેસ બનાવે છે. દરેક ઓપન સોર્સ ટ્રેસિંગ સિસ્ટમ, તેમજ દરેક કોમર્શિયલ ટ્રેસિંગ સોલ્યુશન, ઓફર કરે છે ટ્રેસવ્યુ ટ્રેસને વિઝ્યુઅલાઈઝ કરવા, વિગત આપવા અને ફિલ્ટર કરવા માટે યુઝર ઈન્ટરફેસ.

મેં અત્યાર સુધી જોયેલી તમામ ટ્રેસીંગ સિસ્ટમ્સની સમસ્યા એ છે કે પરિણામી વિઝ્યુલાઇઝેશન (ટ્રેસવ્યુ) લગભગ સંપૂર્ણપણે ટ્રેસ જનરેશન પ્રક્રિયાના લક્ષણોને પ્રતિબિંબિત કરે છે. જ્યારે વૈકલ્પિક વિઝ્યુલાઇઝેશન પ્રસ્તાવિત કરવામાં આવે ત્યારે પણ: હીટમેપ્સ, સર્વિસ ટોપોલોજી, લેટન્સી હિસ્ટોગ્રામ, તેઓ હજુ પણ આખરે નીચે આવે છે ટ્રેસવ્યુ.

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

ટ્રેસવ્યુ સાથે સમસ્યા

લક્ષ્યસ્થાન ટ્રેસવ્યુ - વિતરિત સિસ્ટમના તમામ ઘટકોમાં એક વિનંતીની હિલચાલનું સંપૂર્ણ ચિત્ર પ્રદાન કરો કે જેની સાથે તે સંબંધિત છે. કેટલીક વધુ અદ્યતન ટ્રેસિંગ સિસ્ટમ્સ તમને વ્યક્તિગત સ્પાન્સમાં ડ્રિલ ડાઉન કરવાની અને સમય જતાં બ્રેકડાઉન જોવાની મંજૂરી આપે છે અંદર એક પ્રક્રિયા (જ્યારે સ્પાન્સની કાર્યાત્મક સીમાઓ હોય છે).

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

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

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

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

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

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

સ્પાન્સ ખૂબ નીચા સ્તરના છે

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

તદુપરાંત, હું નીચેની બાબતો પર ભાર મૂકવાની સ્વતંત્રતા લઈશ: આદર્શ રીતે, અમને જરૂર નથી સંપૂર્ણ ચિત્ર વિનંતી જીવનચક્ર દરમિયાન થયું હતું, જે આધુનિક ટ્રેસિંગ સાધનો દ્વારા રજૂ થાય છે. તેના બદલે, ઉચ્ચ-સ્તરની અમૂર્તતાના કેટલાક સ્વરૂપની આવશ્યકતા છે જેમાં શું વિશેની માહિતી શામેલ છે ખોટું થયું (બેકટ્રેસ જેવું જ), કેટલાક સંદર્ભો સાથે. સમગ્ર ટ્રેસ જોવાને બદલે, હું તેને જોવાનું પસંદ કરું છું ભાગ, જ્યાં કંઈક રસપ્રદ અથવા અસામાન્ય બને છે. હાલમાં, શોધ મેન્યુઅલી હાથ ધરવામાં આવે છે: એન્જિનિયર ટ્રેસ મેળવે છે અને કંઈક રસપ્રદની શોધમાં સ્વતંત્ર રીતે સ્પેન્સનું વિશ્લેષણ કરે છે. શંકાસ્પદ પ્રવૃત્તિ શોધવાની આશામાં વ્યક્તિગત ટ્રેસમાં સ્પેન્સ પર નજર રાખતા લોકોનો અભિગમ બિલકુલ માપમાં આવતો નથી (ખાસ કરીને જ્યારે તેઓને વિવિધ સ્પાન્સમાં એન્કોડ કરાયેલા તમામ મેટાડેટાનો અર્થ સમજવો પડે છે, જેમ કે span ID, RPC પદ્ધતિનું નામ, ગાળાની અવધિ. 'a, લૉગ્સ, ટૅગ્સ, વગેરે).

ટ્રેસવ્યુ માટે વિકલ્પો

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

હું વિઝ્યુઅલ ડિઝાઇનર અથવા UX નિષ્ણાત નથી, પરંતુ આગળના વિભાગમાં હું આ વિઝ્યુલાઇઝેશન્સ કેવા દેખાશે તેના પર થોડા વિચારો શેર કરવા માંગુ છું.

ચોક્કસ સેવાઓ પર ધ્યાન આપો

એવા સમયે જ્યારે ઉદ્યોગ વિચારોની આસપાસ એકીકૃત થઈ રહ્યો છે SLO (સેવા સ્તરના ઉદ્દેશ્યો) અને SLI (સેવા સ્તરના સૂચકાંકો), તે વાજબી લાગે છે કે વ્યક્તિગત ટીમોએ તેમની સેવાઓ આ લક્ષ્યો સાથે સંરેખિત છે તેની ખાતરી કરવા માટે પ્રાથમિકતા આપવી જોઈએ. તે તેને અનુસરે છે સેવા લક્ષી વિઝ્યુલાઇઝેશન આવી ટીમો માટે શ્રેષ્ઠ અનુરૂપ છે.

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

1. લેટન્સી ડિસ્ટ્રિબ્યુશન ડાયાગ્રામ માત્ર અત્યંત અગ્રણી વિનંતીઓ માટે (બાહ્ય વિનંતીઓ);
2. જ્યારે સેવા SLO ધ્યેયો હાંસલ ન થયા હોય તેવા કિસ્સાઓ માટે વિલંબના વિતરણના આકૃતિઓ;
3. ક્વેરીઝમાં સૌથી વધુ "સામાન્ય", "રસપ્રદ" અને "વિચિત્ર" ટૅગ્સ જે મોટેભાગે પુનરાવર્તન કરવામાં આવે છે;
4. કેસો માટે લેટન્સી બ્રેકડાઉન જ્યાં નિર્ભરતા સેવાઓ તેમના SLO લક્ષ્યો હાંસલ કરતી નથી;
5. વિવિધ ડાઉનસ્ટ્રીમ સેવાઓ માટે લેટન્સી બ્રેકડાઉન.

આમાંના કેટલાક પ્રશ્નોનો જવાબ બિલ્ટ-ઇન મેટ્રિક્સ દ્વારા આપવામાં આવતો નથી, જે વપરાશકર્તાઓને સ્પાન્સની તપાસ કરવાની ફરજ પાડે છે. પરિણામે, અમારી પાસે અત્યંત વપરાશકર્તા-પ્રતિકૂળ પદ્ધતિ છે.

આ પ્રશ્ન ઉભો કરે છે: વિવિધ ટીમો દ્વારા નિયંત્રિત વિવિધ સેવાઓ વચ્ચેની જટિલ ક્રિયાપ્રતિક્રિયાઓ વિશે શું? તે નથી ટ્રેસવ્યુ આવી પરિસ્થિતિને પ્રકાશિત કરવા માટે સૌથી યોગ્ય સાધન માનવામાં આવતું નથી?

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

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

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

ટોપોલોજીનું નિર્માણ

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

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

ચાલો એક ઉદાહરણ લઈએ. ચાલો એક કાલ્પનિક સમાચાર સાઇટની કલ્પના કરીએ. હોમ પેજ સેવા (પહેલું પાનું) Redis સાથે, ભલામણ સેવા સાથે, જાહેરાત સેવા અને વિડિઓ સેવા સાથે ડેટાની આપલે કરે છે. વિડિયો સર્વિસ S3 પરથી વિડિયો અને ડાયનામોડીબીમાંથી મેટાડેટા લે છે. ભલામણ સેવા ડાયનામોડીબી પાસેથી મેટાડેટા મેળવે છે, રેડિસ અને માયએસક્યુએલમાંથી ડેટા લોડ કરે છે અને કાફકાને સંદેશા લખે છે. જાહેરાત સેવા MySQL પાસેથી ડેટા મેળવે છે અને કાફકાને સંદેશા લખે છે.

નીચે આ ટોપોલોજીની યોજનાકીય રજૂઆત છે (ઘણા કોમર્શિયલ રૂટીંગ પ્રોગ્રામ ટોપોલોજીનું નિર્માણ કરે છે). જો તમારે સેવા નિર્ભરતાને સમજવાની જરૂર હોય તો તે ઉપયોગી થઈ શકે છે. જો કે, દરમિયાન ડીબગ, જ્યારે કોઈ ચોક્કસ સેવા (કહો, વિડિઓ સેવા) પ્રતિભાવ સમય વધારે દર્શાવે છે, ત્યારે આવી ટોપોલોજી બહુ ઉપયોગી નથી.

કાલ્પનિક સમાચાર સાઇટનો સેવા રેખાકૃતિ

નીચેનો આકૃતિ વધુ યોગ્ય રહેશે. સેવામાં સમસ્યા છે (વિડિઓ) બરાબર કેન્દ્રમાં દર્શાવવામાં આવ્યું છે. વપરાશકર્તા તરત જ તેની નોંધ લે છે. આ વિઝ્યુલાઇઝેશન પરથી, તે સ્પષ્ટ થાય છે કે S3 પ્રતિભાવ સમયમાં વધારો થવાને કારણે વિડિયો સેવા અસાધારણ રીતે કામ કરી રહી છે, જે મુખ્ય પૃષ્ઠના ભાગની લોડિંગ ઝડપને અસર કરે છે.

માત્ર "રસપ્રદ" સેવાઓ પ્રદર્શિત કરતી ગતિશીલ ટોપોલોજી

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

તુલનાત્મક પ્રદર્શન

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

બે ટ્રેસની સરખામણી કરવા માટે મૂળભૂત રીતે નવા વિઝ્યુલાઇઝેશનની જરૂર નથી. વાસ્તવમાં, ટ્રેસવ્યુ જેવી જ માહિતી રજૂ કરતી હિસ્ટોગ્રામ જેવી કંઈક પૂરતી છે. આશ્ચર્યજનક રીતે, આ સરળ પદ્ધતિ પણ ફક્ત બે નિશાનોને અલગથી અભ્યાસ કરવા કરતાં વધુ ફળ લાવી શકે છે. તેનાથી પણ વધુ શક્તિશાળી શક્યતા હશે કલ્પના કરવી નિશાનોની સરખામણી કુલ. GC (કચરો સંગ્રહ) ને સક્ષમ કરવા માટે તાજેતરમાં જમાવવામાં આવેલ ડેટાબેઝ રૂપરેખાંકન ફેરફાર કેટલાંક કલાકોના સ્કેલ પર ડાઉનસ્ટ્રીમ સેવાના પ્રતિભાવ સમયને કેવી રીતે અસર કરે છે તે જોવા માટે તે અત્યંત ઉપયોગી થશે. જો હું અહીં જે વર્ણન કરી રહ્યો છું તે ઇન્ફ્રાસ્ટ્રક્ચર ફેરફારોની અસરના A/B વિશ્લેષણ જેવું લાગે છે ઘણી સેવાઓમાં ટ્રેસ પરિણામોનો ઉપયોગ કરીને, પછી તમે સત્યથી ખૂબ દૂર નથી.

નિષ્કર્ષ

હું ટ્રેસિંગની ઉપયોગીતા પર પ્રશ્ન નથી કરતો. હું નિષ્ઠાપૂર્વક માનું છું કે ટ્રેસમાં સમાયેલ હોય તેટલી સમૃદ્ધ, કારણભૂત અને સંદર્ભિત માહિતી એકત્રિત કરવાની બીજી કોઈ પદ્ધતિ નથી. જો કે, હું એ પણ માનું છું કે તમામ ટ્રેસીંગ સોલ્યુશન્સ આ ડેટાનો અત્યંત બિનકાર્યક્ષમતાથી ઉપયોગ કરે છે. જ્યાં સુધી ટ્રેસીંગ ટૂલ્સ ટ્રેસવ્યુ રજૂઆત પર અટવાયેલા રહે છે, ત્યાં સુધી તેઓ ટ્રેસમાં સમાવિષ્ટ ડેટામાંથી બહાર કાઢી શકાય તેવી મૂલ્યવાન માહિતીનો મહત્તમ ઉપયોગ કરવાની તેમની ક્ષમતામાં મર્યાદિત રહેશે. વધુમાં, સંપૂર્ણપણે બિન-મૈત્રીપૂર્ણ અને અસ્પષ્ટ દ્રશ્ય ઇન્ટરફેસ વિકસાવવાનું જોખમ છે જે એપ્લિકેશનમાં ભૂલોનું નિવારણ કરવાની વપરાશકર્તાની ક્ષમતાને ગંભીરપણે મર્યાદિત કરશે.

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

વિશ્લેષણ અને અનુમાનને સરળ બનાવવા માટે ઑપ્ટિમાઇઝ કરવામાં આવે તે રીતે ટ્રેસ પરિણામોમાં ઉપલબ્ધ વિવિધ સિગ્નલોનું પ્રતિનિધિત્વ કરતી સિસ્ટમ ડિઝાઇન કરવા માટે તે નોંધપાત્ર માનસિક પ્રયત્નો લેશે. તમારે ડિબગીંગ દરમિયાન સિસ્ટમ ટોપોલોજીને કેવી રીતે અમૂર્ત કરવું તે વિશે વિચારવાની જરૂર છે જે વપરાશકર્તાને વ્યક્તિગત નિશાનો અથવા સ્પાન્સને જોયા વિના અંધ સ્થળોને દૂર કરવામાં મદદ કરે છે.

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

અનુવાદક તરફથી પીએસ

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

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

સોર્સ: www.habr.com