અમે સ્પોર્ટમાસ્ટરનું નિરીક્ષણ કરીએ છીએ - કેવી રીતે અને શું સાથે

અમે ઉત્પાદન ટીમો બનાવવાના તબક્કે એક મોનિટરિંગ સિસ્ટમ બનાવવા વિશે વિચાર્યું. તે સ્પષ્ટ થઈ ગયું કે અમારો વ્યવસાય - શોષણ - આ ટીમોમાં આવતો નથી. તે શા માટે છે?

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

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

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

પ્લેટફોર્મ કે જેના પર અમારા ઑનલાઇન સ્ટોર્સ કામ કરે છે તે આના જેવું દેખાય છે:

• આગળ
• મધ્યમ ઓફિસ
• પાછા કામે

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

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

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

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

સિસ્ટમ માળખું અને સ્ટેક

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

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

તેથી, તેઓએ હાથીને ભાગોમાં ખાવાનું નક્કી કર્યું.

અમારી સિસ્ટમમાં નીચેનાનો સમાવેશ થાય છે:

• હાર્ડવેર;
• ઓપરેટિંગ સિસ્ટમ;
• સોફ્ટવેર;
• મોનિટરિંગ એપ્લિકેશનમાં UI ભાગો;
• બિઝનેસ મેટ્રિક્સ;
• એકીકરણ કાર્યક્રમો;
• માહિતી સુરક્ષા;
• નેટવર્ક્સ;
• ટ્રાફિક બેલેન્સર.

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

તેથી, સ્ટેક વિશે.

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

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

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

અન્ય સ્તરો માટેના ડેટા સ્ત્રોતો, ઉદાહરણ તરીકે, બિઝનેસ મેટ્રિક્સ, ત્રણ ઘટકોમાં વિભાજિત છે.

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

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

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

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

છેલ્લે, ત્રીજે સ્થાને, ડેટા સ્ત્રોત એ કેન્દ્રિય લોગીંગ સિસ્ટમ છે. અમે લોગ માટે સ્થિતિસ્થાપક સ્ટેકનો ઉપયોગ કરીએ છીએ, અને પછી અમે આ ડેટાને બિઝનેસ મેટ્રિક્સ માટે અમારી મોનિટરિંગ સિસ્ટમમાં ખેંચી શકીએ છીએ. આ બધા ઉપરાંત, અમારી પાસે અમારી પોતાની મોનિટરિંગ API સેવા છે, જે Python માં લખેલી છે, જે API દ્વારા કોઈપણ સેવાઓને ક્વેરી કરે છે અને તેમાંથી Zabbix માં ડેટા એકત્રિત કરે છે.

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

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

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

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

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

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

પ્રોસ્પેક્ટ્સ

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

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

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

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

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

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

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

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

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

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

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

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

જો તમે નોંધપાત્ર સંખ્યામાં એકીકરણ સાથે મોટા પ્રોજેક્ટ્સનું પણ નિરીક્ષણ કરો છો, તો ટિપ્પણીઓમાં લખો કે તમને આ માટે કઈ સિલ્વર બુલેટ મળી.

સોર્સ: www.habr.com