SRE (સાઇટ રિલાયબિલિટી એન્જિનિયરિંગ) એ વેબ પ્રોજેક્ટ્સની ઉપલબ્ધતાને સુનિશ્ચિત કરવાનો અભિગમ છે. તે DevOps માટેનું માળખું માનવામાં આવે છે અને DevOps પ્રેક્ટિસ લાગુ કરવામાં સફળતા કેવી રીતે પ્રાપ્ત કરવી તે વિશે વાત કરે છે. આ લેખમાં અનુવાદ પ્રકરણ 6 મોનિટરિંગ ડિસ્ટ્રિબ્યુટેડ સિસ્ટમ્સ પુસ્તકો સાઇટ વિશ્વસનીયતા એન્જિનિયરિંગ Google માંથી. મેં આ અનુવાદ જાતે તૈયાર કર્યો અને મોનિટરિંગ પ્રક્રિયાઓને સમજવામાં મારા પોતાના અનુભવ પર આધાર રાખ્યો. ટેલિગ્રામ ચેનલમાં @monitorim_it и માધ્યમ પર બ્લોગ મેં સેવા સ્તરના લક્ષ્યો વિશે સમાન પુસ્તકના પ્રકરણ 4 ના અનુવાદની લિંક પણ પ્રકાશિત કરી.

બિલાડી દ્વારા અનુવાદ. વાંચનનો આનંદ માણો!

Google ની SRE ટીમો પાસે સફળ મોનિટરિંગ અને સૂચના સિસ્ટમ્સ બનાવવા માટે મૂળભૂત સિદ્ધાંતો અને શ્રેષ્ઠ પ્રયાસો છે. આ પ્રકરણ વેબ પેજ વિઝિટરને કઈ સમસ્યાઓનો સામનો કરવો પડી શકે છે અને વેબ પેજને પ્રદર્શિત કરવામાં મુશ્કેલી ઊભી કરતી સમસ્યાઓનું નિરાકરણ કેવી રીતે કરવું તે અંગે માર્ગદર્શન પૂરું પાડે છે.

વ્યાખ્યાઓ

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

મોનીટરીંગ

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

વ્હાઇટ બોક્સ મોનીટરીંગ

લોગ્સ, જાવા વર્ચ્યુઅલ મશીન પ્રોફાઇલિંગ મેટ્રિક્સ અથવા આંતરિક આંકડાઓ જનરેટ કરતા HTTP હેન્ડલર મેટ્રિક્સ સહિત આંતરિક સિસ્ટમ ઘટકો દ્વારા પ્રદર્શિત મેટ્રિક્સ પર આધારિત દેખરેખ.

બ્લેક બોક્સ મોનીટરીંગ

વપરાશકર્તાના દૃષ્ટિકોણથી એપ્લિકેશન વર્તનનું પરીક્ષણ.

ડેશબોર્ડ

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

ચેતવણી (સૂચના)

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

મૂળભૂત કારણ

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

નોડ અને મશીન (નોડ અને મશીન)

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

• એકબીજા સાથે જોડાયેલ: ઉદાહરણ તરીકે, કેશીંગ સર્વર અને વેબ સર્વર;
• હાર્ડવેરના એક ભાગ પર અસંબંધિત સેવાઓ: ઉદાહરણ તરીકે, કોડ રિપોઝીટરી અને રૂપરેખાંકન સિસ્ટમ માટે વિઝાર્ડ, જેમ કે પપેટ અથવા વડા.

દબાણ કરો

સૉફ્ટવેર ગોઠવણીમાં કોઈપણ ફેરફાર.

મોનિટરિંગ શા માટે જરૂરી છે?

એપ્લીકેશનને મોનિટર કરવાની જરૂર હોવાના ઘણા કારણો છે:

લાંબા ગાળાના વલણોનું વિશ્લેષણ

ડેટાબેઝ કેટલો મોટો છે અને તે કેટલી ઝડપથી વધી રહ્યો છે? વપરાશકર્તાઓની દૈનિક સંખ્યા કેવી રીતે બદલાય છે?

પ્રદર્શન સરખામણી

શું Ajax DB 2.72 ની સરખામણીમાં બાઈટ 3.14 ના Acme બકેટ પર વિનંતીઓ ઝડપી છે? વધારાના નોડના દેખાવ પછી વિનંતીઓ કેશ કરવામાં કેટલી સારી છે? શું સાઇટ ગયા સપ્તાહની સરખામણીમાં ધીમી ચાલી રહી છે?

ચેતવણી (સૂચના)

કંઈક તૂટી ગયું છે અને કોઈએ તેને ઠીક કરવાની જરૂર છે. અથવા કંઈક જલ્દી તૂટી જશે અને કોઈએ તેને જલ્દી તપાસવાની જરૂર છે.

ડેશબોર્ડ બનાવી રહ્યા છીએ

ડેશબોર્ડ્સે મૂળભૂત પ્રશ્નોના જવાબ આપવા જોઈએ અને તેમાંથી કંઈક શામેલ કરવું જોઈએ "4 સુવર્ણ સંકેતો" — વિલંબ (લેટન્સી), ટ્રાફિક (ટ્રાફિક), ભૂલો (ભૂલો) અને લોડ કદ (સંતૃપ્તિ).

પૂર્વદર્શી વિશ્લેષણનું સંચાલન (ડિબગીંગ)

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

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

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

મોનિટરિંગ સિસ્ટમ માટે વાજબી અપેક્ષાઓ સેટ કરવી

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

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

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

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

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

લક્ષણો વિરુદ્ધ કારણો

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

લક્ષણ
કારણ

HTTP ભૂલ 500 અથવા 404 મેળવવી
ડેટાબેઝ સર્વર્સ કનેક્શન્સને નકારે છે

ધીમો સર્વર પ્રતિસાદો
ઉચ્ચ CPU ઉપયોગ અથવા ક્ષતિગ્રસ્ત ઇથરનેટ કેબલ

એન્ટાર્કટિકાના વપરાશકર્તાઓ બિલાડી GIF પ્રાપ્ત કરી રહ્યાં નથી
તમારું CDN વૈજ્ઞાનિકો અને બિલાડીઓને ધિક્કારે છે, તેથી કેટલાક IP સરનામાંને બ્લેકલિસ્ટ કરવામાં આવ્યા છે

ખાનગી સામગ્રી દરેક જગ્યાએથી ઉપલબ્ધ થઈ ગઈ છે
નવા સોફ્ટવેર રીલીઝના રોલઆઉટથી ફાયરવોલ તમામ ACL ભૂલી ગયા અને દરેકને અંદર આવવા દો

મહત્તમ સિગ્નલ અને ન્યૂનતમ અવાજ સાથે સારી મોનિટરિંગ સિસ્ટમ બનાવવા માટે "શું" અને "શા માટે" સૌથી મહત્વપૂર્ણ બિલ્ડીંગ બ્લોક્સ છે.

બ્લેક બોક્સ વિ વ્હાઇટ બોક્સ

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

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

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

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

ચાર સુવર્ણ સંકેતો

ચાર સુવર્ણ મોનિટરિંગ સિગ્નલો વિલંબ, ટ્રાફિક, ભૂલો અને સંતૃપ્તિ છે. જો તમે માત્ર ચાર વપરાશકર્તા સિસ્ટમ મેટ્રિક્સને માપી શકો છો, તો તે ચાર પર ધ્યાન કેન્દ્રિત કરો.

વિલંબ

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

ટ્રાફિક

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

ભૂલો

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

સંતૃપ્તિ

મેટ્રિક બતાવે છે કે તમારી સેવાનો કેટલો સઘન ઉપયોગ થાય છે. આ એક સિસ્ટમ મોનિટરિંગ માપદંડ છે જે સૌથી વધુ પ્રતિબંધિત એવા સંસાધનોને ઓળખે છે (ઉદાહરણ તરીકે, મેમરી-સંબંધિત સિસ્ટમ પર, મેમરી બતાવે છે, I/O-સંબંધિત સિસ્ટમ પર, I/Os ની સંખ્યા દર્શાવે છે). નોંધ કરો કે ઘણી સિસ્ટમો 100% ઉપયોગ સુધી પહોંચે તે પહેલાં કાર્યક્ષમતામાં ઘટાડો કરે છે, તેથી ઉપયોગિતાનું લક્ષ્ય રાખવું મહત્વપૂર્ણ છે.

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

છેલ્લે, સંતૃપ્તિ તોળાઈ રહેલી સંતૃપ્તિ વિશેની આગાહીઓ સાથે પણ સંકળાયેલી છે, ઉદાહરણ તરીકે: "એવું લાગે છે કે તમારો ડેટાબેઝ 4 કલાકમાં તમારી હાર્ડ ડ્રાઈવને ભરી દેશે."

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

"પૂંછડી" (અથવા ઇન્સ્ટ્રુમેન્ટેશન અને પ્રદર્શન) વિશે ચિંતા

શરૂઆતથી મોનિટરિંગ સિસ્ટમ બનાવતી વખતે, સરેરાશ મૂલ્યો પર આધારિત સિસ્ટમ વિકસાવવાની લાલચ છે: સરેરાશ લેટન્સી, નોડ્સનો સરેરાશ CPU ઉપયોગ અથવા સરેરાશ ડેટાબેઝ પૂર્ણતા. છેલ્લા બે ઉદાહરણોનો ભય સ્પષ્ટ છે: પ્રોસેસર્સ અને ડેટાબેસેસનો નિકાલ ખૂબ જ અણધારી રીતે કરવામાં આવે છે. આ જ વિલંબને લાગુ પડે છે. જો તમે પ્રતિ સેકન્ડ 100 વિનંતીઓ સાથે 1000ms ની સરેરાશ લેટન્સી સાથે વેબ સેવા ચલાવો છો, તો 1% વિનંતીઓમાં 5 સેકન્ડ લાગી શકે છે. જો વપરાશકર્તાઓ આવી બહુવિધ વેબ સેવાઓ પર આધાર રાખે છે, તો એક બેકએન્ડની 99મી ટકાવારી સરળતાથી ફ્રન્ટએન્ડનો સરેરાશ પ્રતિભાવ સમય બની શકે છે.

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

માપન માટે યોગ્ય સ્તરની વિગતો પસંદ કરી રહ્યા છીએ

સિસ્ટમના વિવિધ ઘટકોને વિગતના વિવિધ સ્તરે માપવા આવશ્યક છે. દાખ્લા તરીકે:

• સમયગાળા દરમિયાન CPU ઉપયોગની દેખરેખ રાખવાથી લાંબા ગાળાના સ્પાઇક્સ દેખાશે નહીં જે ઉચ્ચ વિલંબ તરફ દોરી જાય છે.
• બીજી બાજુ, વેબ સેવા માટે દર વર્ષે 9 કલાકથી વધુ ડાઉનટાઇમ (99,9% વાર્ષિક અપટાઇમ) ના લક્ષ્યાંક માટે, HTTP 200 પ્રતિસાદ માટે મિનિટમાં એક કે બે વાર કરતાં વધુ વખત તપાસ કરવી બિનજરૂરી રીતે વારંવાર થવાની સંભાવના છે.
• તેવી જ રીતે, 99,9% ઉપલબ્ધતા માટે હાર્ડ ડ્રાઈવની જગ્યા દર 1-2 મિનિટે એક કરતા વધુ વખત તપાસવી કદાચ જરૂરી નથી.

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

1. દર સેકન્ડે CPU લોડને માપો.
2. વિગતો ઘટાડીને 5% કરો.
3. દર મિનિટે એકંદર મેટ્રિક્સ.

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

શક્ય તેટલું સરળ, પરંતુ સરળ નથી

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

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

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

તેથી, શક્ય તેટલું સરળ બનાવવા માટે તમારી મોનિટરિંગ સિસ્ટમને ડિઝાઇન કરો. શું ટ્રૅક કરવું તે પસંદ કરતી વખતે, નીચેનાને ધ્યાનમાં રાખો:

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

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

સિદ્ધાંતોને એકસાથે બાંધવા

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

દેખરેખ અને ચેતવણીના નિયમો બનાવતી વખતે, નીચેના પ્રશ્નો પૂછવાથી તમને ખોટા હકારાત્મક અને બિનજરૂરી ચેતવણીઓ ટાળવામાં મદદ મળી શકે છે:

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

આ પ્રશ્નો ચેતવણીઓ અને ચેતવણી પ્રણાલીઓ પરના મૂળભૂત ફિલસૂફીને પ્રતિબિંબિત કરે છે:

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

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

લાંબા ગાળાની દેખરેખ

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

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

બિગટેબલ SRE: ઓવર-અલર્ટની વાર્તા

Google નું આંતરિક ઈન્ફ્રાસ્ટ્રક્ચર સામાન્ય રીતે સેવા સ્તર (SLO) સામે જોગવાઈ અને માપવામાં આવે છે. ઘણા વર્ષો પહેલા, બિગટેબલની સેવા SLO જીવંત ક્લાયંટનું અનુકરણ કરતા સિન્થેટિક ટ્રાન્ઝેક્શનના સરેરાશ પ્રદર્શન પર આધારિત હતી. બિગટેબલમાં સમસ્યાઓ અને સ્ટોરેજ સ્ટેકના નીચલા સ્તરને કારણે, સરેરાશ કામગીરી "મોટી" પૂંછડી દ્વારા સંચાલિત હતી: સૌથી ખરાબ 5% ક્વેરીઝ બાકીના કરતાં ઘણી વખત નોંધપાત્ર રીતે ધીમી હતી.

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

પરિસ્થિતિનો ઉકેલ લાવવા માટે, ટીમે ત્રણ-પાંખીય અભિગમ અપનાવ્યો: બિગટેબલના પ્રદર્શનને સુધારવા માટે સખત મહેનત કરતી વખતે, અમે અસ્થાયી ધોરણે અમારું SLO ધ્યેય ક્વેરી રિસ્પોન્સ લેટન્સી માટે 75મી ટકાવારી તરીકે સેટ કર્યું છે. અમે ઇમેઇલ ચેતવણીઓ પણ બંધ કરી દીધી છે કારણ કે તેમાંના ઘણા એવા હતા કે તેનું નિદાન કરવામાં સમય પસાર કરવો અશક્ય હતું.

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

Gmail: અનુમાનિત, અલ્ગોરિધમિક માનવ પ્રતિભાવો

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

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

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

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

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

લાંબા ગાળાના

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

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

નિષ્કર્ષ

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

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

અંત સુધી અનુવાદ વાંચવા બદલ આભાર. મોનિટરિંગ વિશે મારી ટેલિગ્રામ ચેનલ પર સબ્સ્ક્રાઇબ કરો @monitorim_it и માધ્યમ પર બ્લોગ.

સોર્સ: www.habr.com