શું મોનીટરીંગ મૃત છે? - લાંબી જીવંત દેખરેખ

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

હું માનું છું કે યોગ્ય મોનિટરિંગ સિસ્ટમ ગોઠવવામાં સમસ્યા છે. જો કોઈ મુશ્કેલી ન આવી હોત, તો મારા ભાષણમાં એક થીસીસ હશે: "કૃપા કરીને પ્રોમિથિયસ + ગ્રાફના અને પ્લગઈન્સ 1, 2, 3 ઇન્સ્ટોલ કરો." કમનસીબે, તે હવે તે રીતે કામ કરતું નથી. અને મુખ્ય સમસ્યા એ છે કે દરેક વ્યક્તિ સોફ્ટવેર ઘટકોના સંદર્ભમાં 2008 માં અસ્તિત્વમાં છે તે બાબતમાં વિશ્વાસ કરવાનું ચાલુ રાખે છે.

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

અમે બધાએ નીચેની જેમ વાર્તાનો સામનો કર્યો છે: ચોક્કસ ડેવોપ્સ, ચોક્કસ એડમિન કામ કરી રહ્યા છે, એક ડેવલપમેન્ટ ટીમ તેમની પાસે આવે છે અને કહે છે - "અમે મુક્ત થયા છીએ, હવે મોનિટર કરો." શું મોનીટર? તે કેવી રીતે કામ કરે છે?

બરાબર. અમે જૂના જમાનાની રીત પર નજર રાખીએ છીએ. અને તે પહેલેથી જ બદલાઈ રહ્યું છે, અને તે તારણ આપે છે કે તમે સેવા Aનું નિરીક્ષણ કર્યું છે, જે સેવા B બની છે, જે સેવા C સાથે ક્રિયાપ્રતિક્રિયા કરે છે. પરંતુ વિકાસ ટીમ તમને કહે છે: "સોફ્ટવેર ઇન્સ્ટોલ કરો, તે દરેક વસ્તુનું નિરીક્ષણ કરવું જોઈએ!"

તો શું બદલાયું છે? - બધું બદલાઈ ગયું છે!

2008 બધું બરાબર છે

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

જો આપણે મોનિટરિંગ પ્રદાન કરવા માટે એડમિનિસ્ટ્રેટરે કરેલા કાર્યની માત્રાની તુલના કરીએ, તો તેમાંથી 98% આપોઆપ હતું: જે વ્યક્તિ મોનિટરિંગ કરે છે તેણે Zabbix કેવી રીતે ઇન્સ્ટોલ કરવું, તેને કેવી રીતે ગોઠવવું અને ચેતવણીઓને કેવી રીતે ગોઠવવી તે સમજવું આવશ્યક છે. અને 2% - બાહ્ય તપાસ માટે: કે સાઇટ પ્રતિસાદ આપે છે અને ડેટાબેઝને વિનંતી કરે છે, કે નવા ઓર્ડર આવ્યા છે.

2010 ભાર વધી રહ્યો છે

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

તદુપરાંત, ઇન્ફ્રાસ્ટ્રક્ચર સાથે સંકળાયેલ એન્ટિટી હજી પણ મેનેજરના માથામાં સૌથી મોટી છે. મારા મગજમાં હજી પણ એક વિચાર છે કે જે વ્યક્તિ મોનિટરિંગ કરી રહી છે તે વ્યક્તિ છે જે ઝબ્બિક્સ ઇન્સ્ટોલ કરશે અને તેને ગોઠવવામાં સક્ષમ હશે.

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

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

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

પરંતુ ભાગ્યે જ કોઈ 10 વર્ષ સુધી કોઈ પ્રોજેક્ટ સાથે આવે છે.

મોનિટરિંગમેનનું રેઝ્યૂમે

ધારો કે તમે એક નવા સ્ટાર્ટઅપ પર આવ્યા છો જેણે તરત જ 20 ડેવલપર્સને હાયર કર્યા છે, 15 માઇક્રોસર્વિસિસ લખી છે અને તમે એડમિન છો જેને કહેવામાં આવ્યું છે: “Ci/CD બનાવો. કૃપા કરીને." તમે CI/CD બનાવ્યું છે અને અચાનક તમે સાંભળો છો: "અમારા માટે "ક્યુબ" માં ઉત્પાદન સાથે કામ કરવું મુશ્કેલ છે, એપ્લિકેશન તેમાં કેવી રીતે કાર્ય કરશે તે સમજ્યા વિના. અમને સમાન "ક્યુબ" માં સેન્ડબોક્સ બનાવો.
તમે આ ક્યુબમાં સેન્ડબોક્સ બનાવો. તેઓ તરત જ તમને કહે છે: "અમને એક સ્ટેજ ડેટાબેઝ જોઈએ છે જે ઉત્પાદનમાંથી દરરોજ અપડેટ થાય છે, જેથી અમે સમજીએ કે તે ડેટાબેઝ પર કામ કરે છે, પરંતુ તે જ સમયે ઉત્પાદન ડેટાબેઝને બગાડે નહીં."

તમે આ બધામાં જીવો છો. રિલીઝના 2 અઠવાડિયા બાકી છે, તેઓ તમને કહે છે: "હવે આ બધું મોનિટર કરીએ..." એટલે કે. ક્લસ્ટર ઇન્ફ્રાસ્ટ્રક્ચરનું નિરીક્ષણ કરો, માઇક્રોસર્વિસ આર્કિટેક્ચરનું નિરીક્ષણ કરો, બાહ્ય સેવાઓ સાથેના કાર્યનું નિરીક્ષણ કરો...

અને મારા સાથીદારો સામાન્ય યોજનાને તેમના માથામાંથી બહાર કાઢે છે અને કહે છે: “સારું, અહીં બધું સ્પષ્ટ છે! એક પ્રોગ્રામ ઇન્સ્ટોલ કરો જે આ બધાનું નિરીક્ષણ કરશે. હા, હા: પ્રોમિથિયસ + ગ્રાફના + પ્લગઇન્સ.
અને તેઓ ઉમેરે છે: "તમારી પાસે બે અઠવાડિયા છે, ખાતરી કરો કે બધું સુરક્ષિત છે."

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

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

ચાલો એક એકદમ સામાન્ય કેસ યાદ કરીએ: કેટલીક સેવાઓ PHP માં છે, કેટલીક સેવાઓ Go માં છે, કેટલીક સેવાઓ JS માં છે. તેઓ કોઈક રીતે એકબીજા સાથે કામ કરે છે. આ તે છે જ્યાં "માઈક્રોસર્વિસ" શબ્દ આવ્યો છે: ત્યાં ઘણી બધી વ્યક્તિગત સિસ્ટમો છે કે વિકાસકર્તાઓ પ્રોજેક્ટને સંપૂર્ણ રીતે સમજી શકતા નથી. ટીમનો એક ભાગ JS માં સેવાઓ લખે છે જે તેમના પોતાના પર કામ કરે છે અને બાકીની સિસ્ટમ કેવી રીતે કામ કરે છે તે જાણતા નથી. બીજો ભાગ પાયથોનમાં સેવાઓ લખે છે અને અન્ય સેવાઓ કેવી રીતે કાર્ય કરે છે તેમાં દખલ કરતી નથી; તેઓ તેમના પોતાના વિસ્તારમાં અલગ છે. ત્રીજું એક PHP માં સેવાઓ લખવાનું છે અથવા બીજું કંઈક.
આ તમામ 20 લોકોને 15 સેવાઓમાં વહેંચવામાં આવ્યા છે, અને માત્ર એક જ એડમિન છે જેણે આ બધું સમજવું જોઈએ. બંધ! અમે સિસ્ટમને માત્ર 15 માઇક્રો સર્વિસિસમાં વિભાજિત કરી છે કારણ કે 20 લોકો આખી સિસ્ટમને સમજી શકતા નથી.

પરંતુ તેને કોઈક રીતે મોનિટર કરવાની જરૂર છે ...

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

હું શું કહું... હ્યુસ્ટન, અમને સમસ્યા છે.

આધુનિક સૉફ્ટવેર પ્રોજેક્ટનું નિરીક્ષણ કરવું એ પોતે જ એક સૉફ્ટવેર પ્રોજેક્ટ છે

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

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

અને જો તમે પણ એડમિન અને ડેવલપર્સને તે તબક્કે આપો છો જ્યારે રિલીઝ પહેલા થોડો સમય બાકી હોય, તો વ્યક્તિએ આ સમગ્ર પ્રોટોકોલને સમજવાની જરૂર પડશે. તે. આ સ્કેલના પ્રોજેક્ટમાં નોંધપાત્ર સમય લાગે છે, અને આ સિસ્ટમના વિકાસમાં પરિબળ હોવું જોઈએ.
પરંતુ ઘણી વાર, ખાસ કરીને સ્ટાર્ટઅપ્સમાં, આપણે જોઈએ છીએ કે કેવી રીતે મોનિટરિંગ પછીથી મુલતવી રાખવામાં આવે છે. “હવે અમે ખ્યાલનો પુરાવો બનાવીશું, અમે તેની સાથે લોન્ચ કરીશું, તેને પડવા દો - અમે બલિદાન આપવા તૈયાર છીએ. અને પછી અમે તે બધા પર નજર રાખીશું." જ્યારે (અથવા જો) પ્રોજેક્ટ પૈસા કમાવવાનું શરૂ કરે છે, ત્યારે વ્યવસાય હજી વધુ સુવિધાઓ ઉમેરવા માંગે છે - કારણ કે તે કામ કરવાનું શરૂ કરી દીધું છે, તેથી તેને વધુ રોલઆઉટ કરવાની જરૂર છે! અને તમે તે બિંદુ પર છો જ્યાં તમારે પહેલા પહેલાની દરેક વસ્તુને મોનિટર કરવાની જરૂર છે, જે 1% સમય લેતો નથી, પરંતુ ઘણું વધારે છે. અને માર્ગ દ્વારા, દેખરેખ માટે વિકાસકર્તાઓની જરૂર પડશે, અને તેમને નવી સુવિધાઓ પર કામ કરવા દેવાનું સરળ છે. પરિણામે, નવી સુવિધાઓ લખવામાં આવે છે, બધું ખરાબ થઈ જાય છે, અને તમે અનંત મડાગાંઠમાં છો.

તો શરૂઆતથી શરૂ થતા પ્રોજેક્ટને કેવી રીતે મોનિટર કરવું, અને જો તમને કોઈ પ્રોજેક્ટ મળે જેનું નિરીક્ષણ કરવાની જરૂર હોય તો શું કરવું, પરંતુ તમને ખબર નથી કે ક્યાંથી શરૂ કરવું?

પ્રથમ, તમારે યોજના બનાવવાની જરૂર છે.

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

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

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

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

મારો મુખ્ય વિચાર એ છે કે મોનિટરિંગ વિકાસ પ્રક્રિયા સાથે સમાંતર ચાલવું જોઈએ. જો તમે અન્ય કાર્યો (CI/CD બનાવવી, સેન્ડબોક્સિંગ, ઈન્ફ્રાસ્ટ્રક્ચર રિઓર્ગેનાઈઝેશન) માટે મોનિટરિંગ ટીમને વિચલિત કરો છો, તો મોનિટરિંગમાં વિલંબ થવા લાગશે અને તમે ક્યારેય વિકાસને પકડી શકશો નહીં (અથવા વહેલા કે પછી તમારે તેને રોકવું પડશે).

સ્તર દ્વારા બધું

આ રીતે હું મોનિટરિંગ સિસ્ટમનું સંગઠન જોઉં છું.

1) એપ્લિકેશન સ્તર:

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

2) ઈન્ફ્રાસ્ટ્રક્ચર સ્તર:

• ઓર્કેસ્ટ્રેશન સ્તરનું નિરીક્ષણ;
• સિસ્ટમ સોફ્ટવેર મોનીટરીંગ;
• આયર્ન સ્તરનું નિરીક્ષણ.

3) ફરીથી એપ્લિકેશન સ્તર - પરંતુ એન્જિનિયરિંગ ઉત્પાદન તરીકે:

• એપ્લિકેશન લોગ એકત્રિત અને મોનીટરીંગ;
• એપીએમ;
• ટ્રેસીંગ

4) ચેતવણી:

• ચેતવણી પ્રણાલીનું સંગઠન;
• ફરજ પ્રણાલીનું સંગઠન;
• "નોલેજ બેઝ" નું સંગઠન અને ઘટના પ્રક્રિયા માટે કાર્યપ્રવાહ.

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

એપ્લિકેશન લેયર - બિઝનેસ લોજિક મોનિટરિંગ

અહીં અમે એ હકીકતને તપાસવા વિશે વાત કરી રહ્યા છીએ કે એપ્લિકેશન વપરાશકર્તા માટે કામ કરે છે.

આ સ્તર વિકાસના તબક્કા દરમિયાન થવું જોઈએ. ઉદાહરણ તરીકે, અમારી પાસે શરતી પ્રોમિથિયસ છે: તે સર્વર પર જાય છે જે તપાસ કરે છે, એન્ડપોઇન્ટ ખેંચે છે અને એન્ડપોઇન્ટ જાય છે અને API ને તપાસે છે.

જ્યારે સાઇટ કામ કરી રહી છે તેની ખાતરી કરવા માટે હોમ પેજને મોનિટર કરવા માટે વારંવાર કહેવામાં આવે છે, ત્યારે પ્રોગ્રામર્સ એક હેન્ડલ આપે છે જે API કામ કરી રહ્યું છે તેની ખાતરી કરવા માટે તેમને દર વખતે ખેંચી શકાય છે. અને આ ક્ષણે પ્રોગ્રામરો હજી પણ /api/test/helloworld લે છે અને લખે છે
બધું કામ કરે છે તેની ખાતરી કરવાનો એકમાત્ર રસ્તો? - ના!

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

ટેકનિકલ ટીપ્સ:

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

એપ્લિકેશન સ્તર - આરોગ્ય મેટ્રિક્સ મોનિટરિંગ

હવે અમે સેવાઓના બાહ્ય આરોગ્ય મેટ્રિક્સ વિશે વાત કરી રહ્યા છીએ.

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

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

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

એપ્લિકેશન લેયર - એકીકરણ મોનીટરીંગ

એકીકરણ મોનિટરિંગ બિઝનેસ-ક્રિટિકલ સિસ્ટમ્સ વચ્ચેના સંદેશાવ્યવહાર પર ધ્યાન કેન્દ્રિત કરે છે.

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

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

હું શું કરવાની ભલામણ કરું છું:

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

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

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

ઈન્ફ્રાસ્ટ્રક્ચર સ્તર

ઈન્ફ્રાસ્ટ્રક્ચર મોનિટરિંગ એવી વસ્તુ છે જે લાંબા સમયથી પોતાને મોનિટરિંગ માનવામાં આવે છે.

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

વ્યવસાય એકમ તરીકે એપ્લિકેશન સ્તર

કી પોઇન્ટ:

• ELK. આ ઉદ્યોગ ધોરણ છે. જો કોઈ કારણોસર તમે લૉગ્સ એકત્ર કરી રહ્યાં નથી, તો તરત જ તેમ કરવાનું શરૂ કરો.
• એપીએમ. એપ્લિકેશન મોનિટરિંગ (ન્યૂરેલિક, બ્લેકફાયર, ડેટાડોગ) ને ઝડપથી બંધ કરવાના માર્ગ તરીકે બાહ્ય APM. તમારી સાથે શું થઈ રહ્યું છે તે ઓછામાં ઓછું કોઈક રીતે સમજવા માટે તમે આ વસ્તુને અસ્થાયી રૂપે ઇન્સ્ટોલ કરી શકો છો.
• ટ્રેસિંગ. ડઝનેક માઇક્રોસર્વિસિસમાં, તમારે દરેક વસ્તુને ટ્રેસ કરવી પડશે, કારણ કે વિનંતી હવે તેના પોતાના પર રહેતી નથી. પછીથી ઉમેરવું ખૂબ જ મુશ્કેલ છે, તેથી વિકાસમાં ટ્રેસિંગને તરત જ શેડ્યૂલ કરવું વધુ સારું છે - આ વિકાસકર્તાઓનું કાર્ય અને ઉપયોગિતા છે. જો તમે હજી સુધી તેનો અમલ કર્યો નથી, તો તેનો અમલ કરો! Jaeger/Zipkin જુઓ

એલર્ટિંગ

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

ટેકનોલોજી સ્ટેક

ચાલો કલ્પના કરીએ કે આપણું સ્ટેક નીચે મુજબ છે:

• માહિતી સંગ્રહ - પ્રોમિથિયસ + ગ્રાફના;
• લોગ વિશ્લેષણ - ELK;
• APM અથવા ટ્રેસિંગ માટે - જેગર (ઝિપકીન).

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

થોડા ટેકનિકલ મુદ્દાઓ કે જે હું હમણાં જ દરેક જગ્યાએ જોઉં છું:

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

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

તારણો

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

આ સેન્ટ હાઇલોડ++ કોન્ફરન્સમાં અહેવાલનું વિસ્તૃત સંસ્કરણ છે.

જો તમને મારા વિચારો અને તેના પરના વિચારો અને સંબંધિત વિષયોમાં રસ હોય, તો તમે અહીં કરી શકો છો ચેનલ વાંચો 🙂

સોર્સ: www.habr.com