અમે પ્રોમિથિયસ, ક્લિકહાઉસ અને ELK પર મોનિટરિંગ કેવી રીતે બનાવ્યું

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

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

પ્રોજેક્ટ વિશે

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

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

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

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

પ્રોમિથિયસ

અમે ત્રણ મુખ્ય સૂચકાંકોના આધારે પ્રોમિથિયસની પસંદગી કરી:

1. ઉપલબ્ધ મેટ્રિક્સની વિશાળ સંખ્યા. અમારા કિસ્સામાં તેમાંથી 60 હજાર છે. અલબત્ત, એ નોંધવું યોગ્ય છે કે અમે તેમાંના મોટા ભાગનો ઉપયોગ કરતા નથી (કદાચ લગભગ 95%). બીજી બાજુ, તે બધા પ્રમાણમાં સસ્તા છે. અમારા માટે, અગાઉ ઉપયોગમાં લેવાતા Icinga ની તુલનામાં આ અન્ય આત્યંતિક છે. તેમાં, મેટ્રિક્સ ઉમેરવું એ એક ખાસ પીડા હતી: હાલના લોકો ખર્ચાળ હતા (ફક્ત કોઈપણ પ્લગઇનનો સ્રોત કોડ જુઓ). કોઈપણ પ્લગઈન એ બેશ અથવા પાયથોનમાં એક સ્ક્રિપ્ટ હતી, જેનું લોંચ વપરાશ સંસાધનોની દ્રષ્ટિએ ખર્ચાળ છે.
2. આ સિસ્ટમ પ્રમાણમાં ઓછી માત્રામાં સંસાધનોનો ઉપયોગ કરે છે. 600 MB RAM, 15% એક કોર અને બે ડઝન IOPS અમારા તમામ મેટ્રિક્સ માટે પૂરતા છે. અલબત્ત, તમારે મેટ્રિક્સ નિકાસકારોને ચલાવવા પડશે, પરંતુ તે બધા ગોમાં લખેલા છે અને તે ખૂબ પાવર ભૂખ્યા નથી. મને નથી લાગતું કે આધુનિક વાસ્તવિકતાઓમાં આ કોઈ સમસ્યા છે.
3. કુબરનેટ્સમાં સ્થળાંતર કરવાની ક્ષમતા પ્રદાન કરે છે. ગ્રાહકની યોજનાઓને ધ્યાનમાં લેતા, પસંદગી સ્પષ્ટ છે.

ઇએલકે

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

ક્લીકહાઉસ

શરૂઆતમાં, પસંદગી InfluxDB પર પડી. અમે Nginx લૉગ્સ, pg_stat_statements માંથી આંકડા એકત્રિત કરવાની અને પ્રોમિથિયસ ઐતિહાસિક ડેટાને સંગ્રહિત કરવાની જરૂરિયાત અનુભવી. અમને ઈન્ફ્લક્સ પસંદ નહોતું કારણ કે તે સમયાંતરે મોટી માત્રામાં મેમરીનો વપરાશ કરવાનું શરૂ કર્યું અને ક્રેશ થઈ ગયું. વધુમાં, હું remote_addr દ્વારા ક્વેરીઝને જૂથબદ્ધ કરવા માંગતો હતો, પરંતુ આ DBMS માં જૂથીકરણ ફક્ત ટૅગ્સ દ્વારા જ છે. ટૅગ્સ ખર્ચાળ છે (મેમરી), તેમની સંખ્યા શરતી રીતે મર્યાદિત છે.

અમે ફરીથી અમારી શોધ શરૂ કરી. ન્યૂનતમ સંસાધન વપરાશ સાથેના વિશ્લેષણાત્મક ડેટાબેઝની જરૂર હતી, પ્રાધાન્ય ડિસ્ક પર ડેટા કમ્પ્રેશન સાથે.

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

ન્યૂરેલિક

NewRelic ઐતિહાસિક રીતે અમારી સાથે છે કારણ કે તે ગ્રાહકની પસંદગી હતી. અમે તેનો ઉપયોગ APM તરીકે કરીએ છીએ.

ઝબ્બીક્સ

અમે વિવિધ API ના બ્લેક બોક્સને મોનિટર કરવા માટે ફક્ત Zabbix નો ઉપયોગ કરીએ છીએ.

એક મોનીટરીંગ અભિગમ વ્યાખ્યાયિત

અમે કાર્યને વિઘટિત કરવા માગીએ છીએ અને તે રીતે દેખરેખ માટેના અભિગમને વ્યવસ્થિત બનાવવા માગીએ છીએ.

આ કરવા માટે, મેં અમારી સિસ્ટમને નીચેના સ્તરોમાં વિભાજિત કરી:

• હાર્ડવેર અને VMS;
• ઓપરેટિંગ સિસ્ટમ;
• સિસ્ટમ સેવાઓ, સોફ્ટવેર સ્ટેક;
• અરજી;
• વ્યાપાર તર્ક.

આ અભિગમ શા માટે અનુકૂળ છે:

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

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

વર્ચ્યુઅલ મશીનો

હોસ્ટિંગ અમને પ્રોસેસર, ડિસ્ક, મેમરી અને નેટવર્ક ફાળવે છે. અને અમને પ્રથમ બે સાથે સમસ્યા હતી. તેથી, મેટ્રિક્સ:

CPU ચોરાયેલો સમય - જ્યારે તમે Amazon (t2.micro, ઉદાહરણ તરીકે) પર વર્ચ્યુઅલ મશીન ખરીદો છો, ત્યારે તમારે સમજવું જોઈએ કે તમને સંપૂર્ણ પ્રોસેસર કોર ફાળવવામાં આવ્યો નથી, પરંતુ તેના સમયનો માત્ર એક ક્વોટા છે. અને જ્યારે તમે તેને ખાલી કરો છો, ત્યારે પ્રોસેસર તમારી પાસેથી છીનવી લેવામાં આવશે.

આ મેટ્રિક તમને આવી ક્ષણોને ટ્રૅક કરવા અને નિર્ણયો લેવાની મંજૂરી આપે છે. ઉદાહરણ તરીકે, શું વધારે ટેરિફ લેવા અથવા પૃષ્ઠભૂમિ કાર્યો અને API વિનંતીઓની પ્રક્રિયાને વિવિધ સર્વર્સ પર વિતરિત કરવી જરૂરી છે?

IOPS + CPU iowait સમય - કેટલાક કારણોસર, ઘણા ક્લાઉડ હોસ્ટિંગ્સ પર્યાપ્ત IOPS પ્રદાન ન કરીને પાપ કરે છે. વધુમાં, નીચા IOPS સાથેનું સમયપત્રક તેમના માટે દલીલ નથી. તેથી, તે CPU iowait એકત્રિત કરવા યોગ્ય છે. ગ્રાફની આ જોડી સાથે - નીચા IOPS અને ઉચ્ચ I/O રાહ સાથે - તમે પહેલાથી જ હોસ્ટિંગ સાથે વાત કરી શકો છો અને સમસ્યા હલ કરી શકો છો.

ઓપરેટિંગ સિસ્ટમ

ઓપરેટિંગ સિસ્ટમ મેટ્રિક્સ:

• % માં ઉપલબ્ધ મેમરીનો જથ્થો;
• સ્વેપ વપરાશ પ્રવૃત્તિ: vmstat swapin, swapout;
• % માં ફાઇલ સિસ્ટમ પર ઉપલબ્ધ ઇનોડ્સ અને ખાલી જગ્યાની સંખ્યા
• સરેરાશ ભાર;
• બે રાજ્યમાં જોડાણોની સંખ્યા;
• કોન્ટ્રાક ટેબલ પૂર્ણતા;
• ss યુટિલિટી, iproute2 પેકેજનો ઉપયોગ કરીને નેટવર્કની ગુણવત્તાનું નિરીક્ષણ કરી શકાય છે - તેના આઉટપુટમાંથી RTT કનેક્શન્સનું સૂચક મેળવો અને તેને ડેસ્ટ પોર્ટ દ્વારા જૂથબદ્ધ કરો.

ઑપરેટિંગ સિસ્ટમ સ્તરે પણ અમારી પાસે પ્રક્રિયાઓ જેવી એન્ટિટી છે. સિસ્ટમમાં પ્રક્રિયાઓના સમૂહને ઓળખવું મહત્વપૂર્ણ છે જે તેના સંચાલનમાં મહત્વપૂર્ણ ભૂમિકા ભજવે છે. જો, ઉદાહરણ તરીકે, તમારી પાસે ઘણા pgpools છે, તો તમારે તે દરેક માટે માહિતી એકત્રિત કરવાની જરૂર છે.

મેટ્રિક્સનો સમૂહ નીચે મુજબ છે:

• સી.પી. યુ;
• મેમરી મુખ્યત્વે નિવાસી છે;
• IO - પ્રાધાન્ય IOPS માં;
• ફાઇલએફડી - ઓપન અને લિમિટ;
• નોંધપાત્ર પૃષ્ઠ નિષ્ફળતાઓ - આ રીતે તમે સમજી શકો છો કે કઈ પ્રક્રિયા સ્વેપ થઈ રહી છે.

અમે ડોકરમાં તમામ મોનિટરિંગ ગોઠવીએ છીએ, અને અમે મેટ્રિક્સ ડેટા એકત્રિત કરવા માટે સલાહકારનો ઉપયોગ કરીએ છીએ. અન્ય મશીનો પર અમે પ્રોસેસ-એક્સપોર્ટરનો ઉપયોગ કરીએ છીએ.

સિસ્ટમ સેવાઓ, સોફ્ટવેર સ્ટેક

દરેક એપ્લિકેશનની પોતાની વિશિષ્ટતાઓ હોય છે, અને મેટ્રિક્સના ચોક્કસ સેટને અલગ પાડવું મુશ્કેલ છે.

સાર્વત્રિક સમૂહ છે:

• વિનંતી દર;
• ભૂલોની સંખ્યા;
• વિલંબ
• સંતૃપ્તિ

આ સ્તર પર દેખરેખના અમારા સૌથી આકર્ષક ઉદાહરણો Nginx અને PostgreSQL છે.

અમારી સિસ્ટમમાં સૌથી વધુ લોડ થયેલ સેવા ડેટાબેઝ છે. ભૂતકાળમાં, ડેટાબેઝ શું કરી રહ્યું હતું તે શોધવામાં અમને ઘણીવાર મુશ્કેલી પડતી હતી.

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

આટલી જ એડમિન જરૂર છે.

અમે વાંચવા અને લખવાની વિનંતીઓની પ્રવૃત્તિના ગ્રાફ બનાવીએ છીએ:

બધું સરળ અને સ્પષ્ટ છે, દરેક વિનંતીનો પોતાનો રંગ છે.

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

અંગત રીતે, મેં request_time, upstream_response_time, body_bytes_sent, request_length, request_id ઉમેર્યું. અમે પ્રતિસાદ સમય અને ભૂલોની સંખ્યાનું આયોજન કરીએ છીએ:

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

પરંતુ એક વધુ સમસ્યા રહે છે - ઘટનાના કારણોને ઝડપી દૂર કરવાની ખાતરી કરવા માટે.

ઘટના ઠરાવ

સમસ્યાને ઓળખવાથી લઈને ઉકેલ લાવવા સુધીની સમગ્ર પ્રક્રિયાને સંખ્યાબંધ પગલાઓમાં વિભાજિત કરી શકાય છે:

• સમસ્યાની ઓળખ;
• ફરજ સંચાલકને સૂચના;
• ઘટનાનો પ્રતિભાવ;
• કારણો દૂર.

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

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

અમે સૂચનાના લખાણમાં આ બધી માહિતીને સરળ રીતે સમાવીએ છીએ, તેને વિકિ પૃષ્ઠની લિંક આપીએ છીએ જે વર્ણવે છે કે આ સમસ્યાનો જવાબ કેવી રીતે આપવો, તેને કેવી રીતે હલ કરવો અને તેને કેવી રીતે આગળ વધારવો.

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

પોઈન્ટ એક દંપતિ.

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

બીજું, ગંભીરતાના સ્તરોનો યોગ્ય રીતે ઉપયોગ કરો. દરેક ભાષાનું પોતાનું ધોરણ હોય છે. વ્યક્તિગત રીતે, હું ચાર સ્તરોને અલગ પાડું છું:

1. કોઈ ભૂલ નથી;
2. ગ્રાહક બાજુ ભૂલ;
3. ભૂલ આપણા પક્ષે છે, આપણે પૈસા ગુમાવતા નથી, આપણે જોખમ સહન કરતા નથી;
4. ભૂલ આપણા પક્ષે છે, આપણે પૈસા ગુમાવીએ છીએ.

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

જો તમારો આખો વ્યવસાય બ્રાઉઝરમાં એક બટન છે, તો તમારે મોનિટર કરવાની જરૂર છે કે તે ક્લિક કરે છે અને યોગ્ય રીતે કાર્ય કરે છે કે કેમ. બાકીના બધામાં વાંધો નથી.

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

ઑપરેટિંગ સિસ્ટમ મેટ્રિક્સ અલબત્ત મહત્વપૂર્ણ છે, પરંતુ વ્યવસાયને તેમાં રસ નથી, અમને તેના માટે ચૂકવણી કરવામાં આવતી નથી.

સોર્સ: www.habr.com