હાઇલોડ++, મિખાઇલ માકુરોવ, મેક્સિમ ચેર્નેત્સોવ (ઇન્ટરસ્વ્યાઝ): ઝબ્બીક્સ, એક સર્વર પર 100kNVPS

આગામી હાઇલોડ++ કોન્ફરન્સ 6 અને 7 એપ્રિલ, 2020 ના રોજ સેન્ટ પીટર્સબર્ગમાં યોજાશે વિગતો અને ટિકિટ લિંક. HighLoad++ Moscow 2018. Hall “Moscow”. નવેમ્બર 9, 15:00. થીસીસ અને પ્રસ્તુતિ.

* મોનીટરીંગ - ઓનલાઈન અને એનાલિટિક્સ.
* ZABBIX પ્લેટફોર્મની મૂળભૂત મર્યાદાઓ.
* સ્કેલિંગ વિશ્લેષણ સંગ્રહ માટે ઉકેલ.
* ZABBIX સર્વરનું ઓપ્ટિમાઇઝેશન.
* UI ઓપ્ટિમાઇઝેશન.
* 40k NVPS થી વધુ લોડ હેઠળ સિસ્ટમ ચલાવવાનો અનુભવ કરો.
* સંક્ષિપ્ત તારણો.

મિખાઇલ માકુરોવ (ત્યારબાદ - એમએમ): - કેમ છો બધા!

મેક્સિમ ચેર્નેત્સોવ (ત્યારબાદ - MCH): - શુભ બપોર!

MM: - ચાલો હું મેક્સિમનો પરિચય આપું. મેક્સ એક પ્રતિભાશાળી એન્જિનિયર છે, હું જાણું છું તે શ્રેષ્ઠ નેટવર્કર છે. મેક્સિમ નેટવર્ક અને સેવાઓ, તેમના વિકાસ અને કામગીરીમાં સામેલ છે.

MCH: - અને હું તમને મિખાઇલ વિશે કહેવા માંગુ છું. મિખાઇલ સી ડેવલપર છે. તેમણે અમારી કંપની માટે ઘણા હાઇ-લોડ ટ્રાફિક પ્રોસેસિંગ સોલ્યુશન્સ લખ્યા. અમે યુરલ્સમાં રહીએ છીએ અને કામ કરીએ છીએ, ખડતલ પુરુષોના શહેરમાં ચેલ્યાબિન્સ્ક, ઇન્ટરસ્વિયાઝ કંપનીમાં. અમારી કંપની 16 શહેરોમાં XNUMX લાખ લોકો માટે ઇન્ટરનેટ અને કેબલ ટેલિવિઝન સેવાઓ પૂરી પાડતી કંપની છે.

MM: - અને તે કહેવું યોગ્ય છે કે Intersvyaz માત્ર એક પ્રદાતા કરતાં વધુ છે, તે એક IT કંપની છે. અમારા મોટાભાગના ઉકેલો અમારા IT વિભાગ દ્વારા બનાવવામાં આવે છે.

એ: ટ્રાફિકની પ્રક્રિયા કરતા સર્વર્સથી કોલ સેન્ટર અને મોબાઇલ એપ્લિકેશન પર. IT વિભાગ પાસે હવે લગભગ 80 લોકો ખૂબ જ વૈવિધ્યસભર ક્ષમતાઓ ધરાવે છે.

Zabbix અને તેના આર્કિટેક્ચર વિશે

MCH: - અને હવે હું વ્યક્તિગત રેકોર્ડ સેટ કરવાનો પ્રયાસ કરીશ અને એક મિનિટમાં કહીશ કે Zabbix શું છે (ત્યારબાદ "Zabbix" તરીકે ઓળખાય છે).

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

આર્કિટેક્ચર વિશે સંક્ષિપ્તમાં. આપણે કહી શકીએ કે તે ત્રણ ઘટકો ધરાવે છે:

• સર્વર. સી માં લખાયેલ. તેના બદલે જટિલ પ્રક્રિયા અને થ્રેડો વચ્ચે માહિતી ટ્રાન્સફર સાથે. બધી પ્રક્રિયા તેમાં થાય છે: ડેટાબેઝને પ્રાપ્ત કરવાથી બચાવવા સુધી.
• તમામ ડેટા ડેટાબેઝમાં સંગ્રહિત છે. Zabbix MySQL, PostreSQL અને Oracle ને સપોર્ટ કરે છે.
• વેબ ઈન્ટરફેસ PHP માં લખાયેલ છે. મોટાભાગની સિસ્ટમો પર તે Apache સર્વર સાથે આવે છે, પરંતુ nginx + php સાથે સંયોજનમાં વધુ કાર્યક્ષમ રીતે કાર્ય કરે છે.

આજે અમે ઝબ્બિક્સ સાથે સંબંધિત અમારી કંપનીના જીવનની એક વાર્તા કહેવા માંગીએ છીએ...

Intersvyaz કંપનીના જીવનની વાર્તા. આપણી પાસે શું છે અને આપણને શું જોઈએ છે?

5 કે 6 મહિના પહેલા. કામ પછી એક દિવસ...

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

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

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

MM: - તે સ્પષ્ટ છે. શું તમે કંઈક જોયું છે, શું તમે ડાયગ્નોસ્ટિક્સમાંથી કંઈક ખોદ્યું છે?

MCH: - પ્રથમ વસ્તુ જેની સાથે તમારે વ્યવહાર કરવો પડશે તે ડેટાબેઝ છે. MySQL સતત લોડ થાય છે, નવા મેટ્રિક્સ સ્ટોર કરે છે, અને જ્યારે Zabbix ઘટનાઓનો સમૂહ જનરેટ કરવાનું શરૂ કરે છે, ત્યારે ડેટાબેઝ શાબ્દિક રીતે થોડા કલાકો માટે ઓવરડ્રાઈવમાં જાય છે. મેં તમને રૂપરેખાંકન ઑપ્ટિમાઇઝ કરવા વિશે પહેલેથી જ કહ્યું છે, પરંતુ શાબ્દિક રીતે આ વર્ષે તેઓએ હાર્ડવેર અપડેટ કર્યું છે: સર્વર્સ પાસે SSD RAIDs પર સો ગીગાબાઇટ્સથી વધુ મેમરી અને ડિસ્ક એરે છે - લાંબા ગાળે તેને રેખીય રીતે વધારવાનો કોઈ અર્થ નથી. આપણે શું કરીએ?

MM: - તે સ્પષ્ટ છે. સામાન્ય રીતે, MySQL એ LTP ડેટાબેઝ છે. દેખીતી રીતે, તે હવે અમારા કદના મેટ્રિક્સના આર્કાઇવને સંગ્રહિત કરવા માટે યોગ્ય નથી. ચાલો તેને આકૃતિ કરીએ.

MCH: - ચાલો!

હેકાથોનના પરિણામે ઝબ્બીક્સ અને ક્લિકહાઉસનું એકીકરણ

થોડા સમય પછી અમને રસપ્રદ ડેટા પ્રાપ્ત થયો:

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

Clickhouse અને Elasticsearch ની સરખામણી

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

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

કુલ મળીને, પ્રોસેસર વપરાશ અને ઝડપના સંદર્ભમાં ક્લિકહાઉસ એલાસ્ટિક્સ કરતાં નોંધપાત્ર રીતે શ્રેષ્ઠ હતું. તે જ સમયે, ડેટા કમ્પ્રેશનને કારણે, ક્લિકહાઉસ હાર્ડ ડ્રાઈવ પર 11 ગણો ઓછો ઉપયોગ કરે છે અને લગભગ 30 ગણી ઓછી ડિસ્ક કામગીરી કરે છે:

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

સંસાધનોને ઑપ્ટિમાઇઝ કરવા માટે, તમે તમારા હાલના મુખ્ય ડેટાબેઝની બાજુમાં ક્લિકહાઉસ ઇન્સ્ટોલ કરી શકો છો અને ત્યાં CPU સમય અને ડિસ્ક ઑપરેશનનો ઘણો બચાવ કરી શકો છો. અમે મેટ્રિક્સના આર્કાઇવને હાલના ક્લિકહાઉસ ક્લસ્ટરમાં ખસેડ્યા છે:

અમે મુખ્ય MySQL ડેટાબેઝને એટલી રાહત આપી છે કે અમે તેને Zabbix સર્વર સાથે એક મશીન પર જોડી શકીએ છીએ અને MySQL માટે સમર્પિત સર્વરને છોડી શકીએ છીએ.

ઝબ્બિક્સમાં મતદાન કેવી રીતે કાર્ય કરે છે?

4 મહિના પહેલા

MM: - સારું, શું આપણે આધાર સાથેની સમસ્યાઓ વિશે ભૂલી શકીએ?

MCH: - તે ખાતરી માટે છે! બીજી સમસ્યા જે આપણે હલ કરવાની જરૂર છે તે છે ધીમા ડેટા સંગ્રહ. હવે અમારા તમામ 15 પ્રોક્સી સર્વર SNMP અને મતદાન પ્રક્રિયાઓથી ઓવરલોડ થઈ ગયા છે. અને નવા અને નવા સર્વર્સ ઇન્સ્ટોલ કરવા સિવાય કોઈ રસ્તો નથી.

MM: - મહાન. પરંતુ પહેલા, અમને કહો કે ઝબ્બિક્સમાં મતદાન કેવી રીતે કાર્ય કરે છે?

MCH: - ટૂંકમાં, 20 પ્રકારના મેટ્રિક્સ અને તેમને મેળવવાની એક ડઝન રીતો છે. Zabbix ક્યાં તો “રિક્વેસ્ટ-રિસ્પોન્સ” મોડમાં ડેટા એકત્રિત કરી શકે છે અથવા “ટ્રેપર ઈન્ટરફેસ” દ્વારા નવા ડેટાની રાહ જોઈ શકે છે.

તે નોંધવું યોગ્ય છે કે મૂળ ઝબ્બિક્સમાં આ પદ્ધતિ (ટ્રેપર) સૌથી ઝડપી છે.

લોડ વિતરણ માટે પ્રોક્સી સર્વર્સ છે:

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

MM: - આર્કિટેક્ચર સાથે બધું સ્પષ્ટ છે. આપણે સ્ત્રોતો જોવાની જરૂર છે ...

થોડા દિવસો પછી

nmap fping કેવી રીતે જીત્યું તેની વાર્તા

MM: "મને લાગે છે કે મેં કંઈક ખોદ્યું છે."

MCH: - મને કહો!

MM: – મેં શોધ્યું કે ઉપલબ્ધતા તપાસતી વખતે, Zabbix એક સમયે વધુમાં વધુ 128 હોસ્ટને તપાસે છે. મેં આ સંખ્યા વધારીને 500 કરવાનો પ્રયાસ કર્યો અને તેમના પિંગ (પિંગ) માં ઇન્ટર-પેકેટ અંતરાલને દૂર કરવાનો પ્રયાસ કર્યો - આનાથી પ્રદર્શન બમણું થયું. પરંતુ મને મોટી સંખ્યામાં ગમશે.

MCH: – મારી પ્રેક્ટિસમાં, મારે ક્યારેક હજારો યજમાનોની ઉપલબ્ધતા તપાસવી પડે છે, અને મેં આ માટે nmap કરતાં વધુ ઝડપી કંઈ જોયું નથી. મને ખાતરી છે કે આ સૌથી ઝડપી રસ્તો છે. ચાલો તેને અજમાવીએ! આપણે પુનરાવર્તન દીઠ યજમાનોની સંખ્યામાં નોંધપાત્ર વધારો કરવાની જરૂર છે.

MM: - પાંચસો કરતાં વધુ તપાસો? 600?

MCH: - ઓછામાં ઓછા બે હજાર.

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

MCH: - મહાન! અને ક્યારે?

MM: - હંમેશની જેમ, ગઈકાલે.

MCH: - અમે fping અને nmap બંને સંસ્કરણોની તુલના કરી:

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

મતદાન ઑપ્ટિમાઇઝેશન

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

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

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

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

આ યજમાનોના સમગ્ર પેક માટે કરવામાં આવે છે. આ મોડ આખરે સંપૂર્ણપણે અસુમેળ કરતાં ધીમો નથી, કારણ કે મતદાન દોઢસો SNMP મૂલ્યો હજુ પણ 1 સમય સમાપ્ત કરતાં વધુ ઝડપી છે.

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

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

લગભગ ત્રણ મહિના પહેલા

આર્કિટેક્ચર બદલો - ભાર વધારો!

MM: - સારું, મેક્સ, શું ઉત્પાદક બનવાનો સમય છે? મારે શક્તિશાળી સર્વર અને સારા એન્જિનિયરની જરૂર છે.

MCH: - ઠીક છે, ચાલો તેની યોજના કરીએ. 5 હજાર મેટ્રિક્સ પ્રતિ સેકન્ડના ડેડ પોઈન્ટથી આગળ વધવાનો સમય છે.

અપગ્રેડ પછી સવાર

MCH: - મીશા, અમે અમારી જાતને અપડેટ કરી, પરંતુ સવાર સુધીમાં અમે પાછા ફર્યા... અનુમાન કરો કે અમે કેટલી ઝડપ હાંસલ કરવામાં સફળ થયા?

MM: - મહત્તમ 20 હજાર.

MCH: - હા, 25! કમનસીબે, અમે જ્યાંથી શરૂઆત કરી હતી ત્યાંથી અમે બરાબર છીએ.

MM: - કેમ? શું તમે કોઈ ડાયગ્નોસ્ટિક્સ ચલાવ્યું છે?

MCH: - હા પાક્કુ! અહીં, ઉદાહરણ તરીકે, એક રસપ્રદ ટોચ છે:

MM: - ચાલો જોઈએ. હું જોઉં છું કે અમે મોટી સંખ્યામાં મતદાન થ્રેડોનો પ્રયાસ કર્યો છે:

પરંતુ તે જ સમયે તેઓ અડધાથી પણ સિસ્ટમને રિસાયકલ કરી શક્યા નહીં:

અને એકંદર પ્રદર્શન તદ્દન નાનું છે, લગભગ 4 હજાર મેટ્રિક્સ પ્રતિ સેકન્ડ:

આના સિવાય બીજું કઈ?

MCH: - હા, એક પોલર્સનો સ્ટ્રેસ:

MM: - અહીં તમે સ્પષ્ટપણે જોઈ શકો છો કે મતદાન પ્રક્રિયા "સેમાફોર્સ" ની રાહ જોઈ રહી છે. આ તાળાઓ છે:

MCH: - અસ્પષ્ટ.

MM: - જુઓ, આ એવી પરિસ્થિતિ જેવી જ છે જ્યાં થ્રેડોનો સમૂહ એવા સંસાધનો સાથે કામ કરવાનો પ્રયાસ કરી રહ્યો છે કે જેની સાથે એક સમયે માત્ર એક જ કામ કરી શકે. પછી તેઓ જે કરી શકે છે તે સમય જતાં આ સંસાધનને શેર કરવાનું છે:

અને આવા સંસાધન સાથે કામ કરવાની કુલ કામગીરી એક કોરની ગતિ દ્વારા મર્યાદિત છે:

આ સમસ્યાને હલ કરવાની બે રીત છે.

મશીનના હાર્ડવેરને અપગ્રેડ કરો, ઝડપી કોરો પર સ્વિચ કરો:

અથવા આર્કિટેક્ચર બદલો અને તે જ સમયે લોડ બદલો:

MCH: - માર્ગ દ્વારા, પરીક્ષણ મશીન પર અમે લડાઇ કરતા ઓછા કોરોનો ઉપયોગ કરીશું, પરંતુ તે કોર દીઠ આવર્તનમાં 1,5 ગણા ઝડપી છે!

MM: - ચોખ્ખુ? તમારે સર્વર કોડ જોવાની જરૂર છે.

Zabbix સર્વરમાં ડેટા પાથ

MCH: - તેને સમજવા માટે, અમે ઝબ્બીક્સ સર્વરની અંદર ડેટા કેવી રીતે ટ્રાન્સફર થાય છે તેનું વિશ્લેષણ કરવાનું શરૂ કર્યું:

સરસ ચિત્ર, બરાબર ને? ચાલો તેને વધુ કે ઓછા સ્પષ્ટ કરવા માટે તેને સ્ટેપ બાય સ્ટેપ કરીએ. ડેટા એકત્રિત કરવા માટે જવાબદાર થ્રેડો અને સેવાઓ છે:

તેઓ એકત્રિત મેટ્રિક્સને સોકેટ દ્વારા પ્રીપ્રોસેસર મેનેજરને ટ્રાન્સમિટ કરે છે, જ્યાં તેઓ કતારમાં સાચવવામાં આવે છે:

"પ્રીપ્રોસેસર મેનેજર" તેના કામદારોને ડેટા ટ્રાન્સમિટ કરે છે, જે પ્રીપ્રોસેસિંગ સૂચનાઓનું અમલીકરણ કરે છે અને તે જ સોકેટ દ્વારા તેમને પાછા આપે છે:

આ પછી, પ્રીપ્રોસેસર મેનેજર તેમને ઇતિહાસ કેશમાં સંગ્રહિત કરે છે:

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

MM: - અમે જોયું તે પ્રથમ વસ્તુ એ હતી કે મોટાભાગના થ્રેડો કહેવાતા "રૂપરેખાંકન કેશ" માટે સ્પર્ધા કરે છે (મેમરી એરિયા જ્યાં તમામ સર્વર રૂપરેખાંકનો સંગ્રહિત થાય છે). ડેટા એકત્ર કરવા માટે જવાબદાર થ્રેડો ખાસ કરીને ઘણાં બ્લોકિંગ કરે છે:

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

મતદાન કરનારાઓએ સંઘર્ષ ન કરવો જોઈએ

તેથી, અમે સૌ પ્રથમ કતારને 4 ભાગોમાં વિભાજીત કરી અને મતદાન કરનારાઓને આ કતારોને, આ ભાગોને એક જ સમયે, સલામત પરિસ્થિતિઓમાં અવરોધિત કરવાની મંજૂરી આપી:

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

પ્રીપ્રોસેસર મેનેજર પ્રાધાન્ય આપવા સક્ષમ હોવા જોઈએ

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

આ સમસ્યાને ઉકેલવા માટે, અમે બીજું સોકેટ ઉમેર્યું છે જે ખાસ કરીને કામદારોને સમર્પિત હતું:

આમ, પ્રીપ્રોસેસર મેનેજર પાસે તેના કામને પ્રાધાન્ય આપવાની તક હતી અને, જો બફર વધે છે, તો કાર્ય દૂર કરવાની પ્રક્રિયાને ધીમું કરવાનું છે, કામદારોને આ બફર લેવાની તક આપે છે:

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

અમે સોકેટ્સની સંખ્યામાં વધારો કરીએ છીએ - અમને પરિણામ મળે છે

આગળ, પ્રીપ્રોસેસર મેનેજર પોતે એક અડચણ બની ગયો, કારણ કે તે એક થ્રેડ છે. તે કોર સ્પીડ પર આરામ કરે છે, લગભગ 70 હજાર મેટ્રિક્સ પ્રતિ સેકન્ડની મહત્તમ ઝડપ આપે છે:

તેથી, અમે ચાર, સોકેટ્સના ચાર સેટ સાથે, કામદારો બનાવ્યા:

અને આનાથી અમને આશરે 130 હજાર મેટ્રિક્સની ઝડપ વધારવાની મંજૂરી મળી:

વૃદ્ધિની બિન-રેખીયતા એ હકીકત દ્વારા સમજાવવામાં આવે છે કે ઇતિહાસ કેશ માટે સ્પર્ધા દેખાઈ છે. 4 પ્રીપ્રોસેસર મેનેજર અને હિસ્ટ્રી સિંકર્સે તેના માટે સ્પર્ધા કરી. આ બિંદુએ, અમે પરીક્ષણ મશીન પર સેકન્ડ દીઠ આશરે 130 હજાર મેટ્રિક્સ પ્રાપ્ત કરી રહ્યા હતા, લગભગ 95% પ્રોસેસર દ્વારા તેનો ઉપયોગ:

લગભગ 2,5 મહિના પહેલા

snmp-સમુદાય તરફથી ઇનકારે NVPsમાં દોઢ ગણો વધારો કર્યો

MM: - મેક્સ, મારે નવી ટેસ્ટ કારની જરૂર છે! અમે હવે વર્તમાનમાં બંધબેસતા નથી.

MCH: - હવે તમારી પાસે શું છે?

MM: – હવે – 130k NVPs અને શેલ્ફ-રેડી પ્રોસેસર.

MCH: - વાહ! કૂલ! રાહ જુઓ, મારી પાસે બે પ્રશ્નો છે. મારી ગણતરી મુજબ, આપણી જરૂરિયાત લગભગ 15-20 હજાર મેટ્રિક્સ પ્રતિ સેકન્ડ છે. શા માટે આપણને વધુની જરૂર છે?

MM: "મારે કામ પૂરું કરવું છે." હું જોવા માંગુ છું કે આપણે આ સિસ્ટમમાંથી કેટલું નિચોવી શકીએ.

MCH: - પણ…

MM: "પરંતુ તે વ્યવસાય માટે નકામું છે."

MCH: - તે સ્પષ્ટ છે. અને બીજો પ્રશ્ન: શું આપણે ડેવલપરની મદદ વિના, આપણી પોતાની જાતે જે છે તેને સમર્થન આપી શકીએ?

MM: - મને નથી લાગતું. રૂપરેખાંકન કેશ કેવી રીતે કાર્ય કરે છે તે બદલવું એ એક સમસ્યા છે. તે મોટાભાગના થ્રેડોમાં ફેરફારોને અસર કરે છે અને જાળવવું ખૂબ મુશ્કેલ છે. મોટે ભાગે, તેને જાળવી રાખવું ખૂબ મુશ્કેલ હશે.

MCH: "તો પછી આપણને કોઈક પ્રકારનો વિકલ્પ જોઈએ છે."

MM: - આવો વિકલ્પ છે. નવી લોકીંગ સિસ્ટમને છોડીને અમે ઝડપી કોરો પર સ્વિચ કરી શકીએ છીએ. અમને હજુ પણ 60-80 હજાર મેટ્રિક્સનું પ્રદર્શન મળશે. તે જ સમયે, અમે બાકીના બધા કોડ છોડી શકીએ છીએ. ક્લિકહાઉસ અને અસિંક્રનસ મતદાન કાર્ય કરશે. અને તેની જાળવણી કરવામાં સરળતા રહેશે.

MCH: - અમેઝિંગ! હું સૂચન કરું છું કે આપણે અહીં અટકીએ.

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

ઉદાહરણ તરીકે, snmp-કમ્યુનિટી મેક્રોને છોડી દેવાથી, જે ઘણીવાર દસ્તાવેજો અને ઉદાહરણોમાં જોવા મળે છે, અમારા કિસ્સામાં NVP ને લગભગ 1,5 ગણો વધુ ઝડપી બનાવવાનું શક્ય બન્યું.

ઉત્પાદનમાં બે દિવસ પછી

ઘટના ઇતિહાસ પોપ-અપ દૂર કરી રહ્યા છીએ

MCH: - મીશા, અમે બે દિવસથી સિસ્ટમનો ઉપયોગ કરી રહ્યા છીએ, અને બધું કામ કરે છે. પરંતુ જ્યારે બધું કામ કરે છે ત્યારે જ! અમે નેટવર્કના એકદમ મોટા સેગમેન્ટના સ્થાનાંતરણ સાથે કામ કરવાની યોજના બનાવી હતી, અને અમે ફરીથી અમારા હાથથી તપાસ કરી કે શું વધ્યું અને શું નહીં.

MM: - ન હોઈ શકે! અમે 10 વખત બધું તપાસ્યું. સર્વર સંપૂર્ણ નેટવર્ક અનુપલબ્ધતાને પણ તરત જ સંભાળે છે.

MCH: - હા, હું બધું સમજું છું: સર્વર, ડેટાબેઝ, ટોપ, ઓસ્ટેટ, લોગ્સ - બધું જ ઝડપી છે... પરંતુ આપણે વેબ ઈન્ટરફેસ જોઈએ છીએ, અને સર્વર પર "શેલ્ફમાં" પ્રોસેસર છે અને આ:

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

આનું કારણ ઘટના ઇતિહાસ પૉપ-અપ્સની પેઢી હતી જે સૂચિમાં દરેક આઇટમ માટે જનરેટ થાય છે. તેથી, અમે આ વિન્ડોઝની પેઢીને છોડી દીધી (કોડમાં 5 લીટીઓ ટિપ્પણી કરી), અને આનાથી અમારી સમસ્યાઓ હલ થઈ.

વિજેટ્સ માટેનો લોડિંગ સમય, સંપૂર્ણપણે અનુપલબ્ધ હોવા છતાં પણ, અમારા માટે સ્વીકાર્ય 10-15 સેકન્ડમાં ઘણી મિનિટોથી ઘટાડી દેવામાં આવ્યો છે, અને સમય પર ક્લિક કરીને ઇતિહાસ હજી પણ જોઈ શકાય છે:

કામ પછી. 2 મહિના પહેલા

MCH: - મીશા, તમે જઈ રહ્યા છો? આપણે વાત કરવી છે.

MM: - મારો ઇરાદો નહોતો. Zabbix સાથે ફરીથી કંઈક?

MCH: - ના, આરામ કરો! હું ફક્ત કહેવા માંગતો હતો: બધું કામ કરે છે, આભાર! મારી પાસે બીયર છે.

Zabbix કાર્યક્ષમ છે

Zabbix એકદમ સાર્વત્રિક અને સમૃદ્ધ સિસ્ટમ અને કાર્ય છે. તેનો ઉપયોગ બૉક્સની બહારના નાના સ્થાપનો માટે થઈ શકે છે, પરંતુ જેમ જેમ જરૂરિયાતો વધે છે, તેમ તેમ તેને ઑપ્ટિમાઇઝ કરવું પડશે. મેટ્રિક્સના મોટા આર્કાઇવને સંગ્રહિત કરવા માટે, યોગ્ય સ્ટોરેજનો ઉપયોગ કરો:

• તમે બિલ્ટ-ઇન ટૂલ્સનો ઉપયોગ Elasticsearch સાથે એકીકરણના સ્વરૂપમાં કરી શકો છો અથવા ટેક્સ્ટ ફાઇલો પર ઇતિહાસ અપલોડ કરી શકો છો (સંસ્કરણ XNUMX પરથી ઉપલબ્ધ છે);
• તમે ક્લિકહાઉસ સાથે અમારા અનુભવ અને એકીકરણનો લાભ લઈ શકો છો.

મેટ્રિક્સ એકત્રિત કરવાની ઝડપને નાટ્યાત્મક રીતે વધારવા માટે, તેમને અસુમેળ પદ્ધતિઓનો ઉપયોગ કરીને એકત્રિત કરો અને તેમને ટ્રેપર ઇન્ટરફેસ દ્વારા Zabbix સર્વર પર ટ્રાન્સમિટ કરો; અથવા તમે Zabbix પોલર્સને અસિંક્રોનસ બનાવવા માટે પેચનો ઉપયોગ કરી શકો છો.

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

એ જ Zabbix પેચ

MM: - હું થોડા મુદ્દા ઉમેરવા માંગુ છું. સમગ્ર વર્તમાન અહેવાલ, તમામ પરીક્ષણો, નંબરો અમે ઉપયોગ કરીએ છીએ તે ગોઠવણી માટે આપવામાં આવે છે. હવે અમે તેમાંથી અંદાજે 20 હજાર મેટ્રિક્સ પ્રતિ સેકન્ડ લઈ રહ્યા છીએ. જો તમે સમજવાનો પ્રયાસ કરી રહ્યાં છો કે આ તમારા માટે કામ કરશે કે કેમ, તો તમે સરખામણી કરી શકો છો. આજે જે ચર્ચા કરવામાં આવી હતી તે પેચના રૂપમાં GitHub પર પોસ્ટ કરવામાં આવી છે: github.com/miklert/zabbix

પેચમાં શામેલ છે:

• Clickhouse સાથે સંપૂર્ણ એકીકરણ (બંને Zabbix સર્વર અને ફ્રન્ટએન્ડ);
• પ્રીપ્રોસેસર મેનેજર સાથે સમસ્યાઓનું નિરાકરણ;
• અસુમેળ મતદાન.

પેચ lts સહિત તમામ સંસ્કરણ 4 સાથે સુસંગત છે. મોટે ભાગે, ન્યૂનતમ ફેરફારો સાથે તે સંસ્કરણ 3.4 પર કાર્ય કરશે.

તમારું ધ્યાન બદલ આભાર.

પ્રશ્નો

પ્રેક્ષકો તરફથી પ્રશ્ન (ત્યારબાદ – A): – શુભ બપોર! મહેરબાની કરીને મને કહો, શું તમારી પાસે Zabbix ટીમ સાથે અથવા તેમની સાથે તમારી સાથે સઘન ક્રિયાપ્રતિક્રિયા કરવાની યોજના છે, જેથી આ પેચ નથી, પરંતુ Zabbix નું સામાન્ય વર્તન છે?

MM: - હા, અમે અમુક ફેરફારો ચોક્કસ કરીશું. કંઈક થશે, કંઈક પેચમાં રહેશે.

એ: - ઉત્તમ અહેવાલ માટે ખૂબ ખૂબ આભાર! મહેરબાની કરીને મને કહો, પેચ લાગુ કર્યા પછી, Zabbix તરફથી સમર્થન રહેશે અને ઉચ્ચ સંસ્કરણો પર અપડેટ કરવાનું કેવી રીતે ચાલુ રાખવું? શું તમારા પેચ પછી 4.2, 5.0 પર Zabbix અપડેટ કરવું શક્ય બનશે?

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

એ: - તો તમે તમારા પેચને સપોર્ટ કરવાની યોજના ઘડી રહ્યા છો અને તમે તેને પ્રોડક્શનમાં સુરક્ષિત રીતે ઇન્સ્ટોલ કરી શકશો અને ભવિષ્યમાં કોઈ રીતે અપડેટ્સ પ્રાપ્ત કરી શકશો?

MM: - અમે ભારપૂર્વક તેની ભલામણ કરીએ છીએ. આ આપણા માટે ઘણી સમસ્યાઓ હલ કરે છે.

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

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

એ: - ખુબ ખુબ આભાર. મને કહો, કરવામાં આવેલા ફેરફારોના કોઈ દસ્તાવેજ છે?

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

nmap સાથે fping ને બદલવા વિશે

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

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

એ: - શું તે પ્રોક્સીઓ માટે પણ કામ કરે છે?

MM: - હા, પણ અમે તપાસ કરી નથી. મતદાન કોડ Zabbix અને સર્વર બંનેમાં સમાન છે. કામ કરવું જોઈએ. ચાલો હું ફરી એકવાર ભાર મૂકું: સિસ્ટમનું પ્રદર્શન એવું છે કે અમને પ્રોક્સીની જરૂર નથી.

MCH: - પ્રશ્નનો સાચો જવાબ છે: "તમારે આવી સિસ્ટમ સાથે પ્રોક્સીની શા માટે જરૂર છે?" ફક્ત NAT અથવા અમુક પ્રકારની ધીમી ચેનલ દ્વારા દેખરેખને કારણે...

એ: - અને જો હું યોગ્ય રીતે સમજું તો તમે ઝબ્બીક્સનો ઉપયોગ એલર્ટર તરીકે કરો છો. અથવા તમારા ગ્રાફિક્સ (જ્યાં આર્કાઇવ લેયર છે) અન્ય સિસ્ટમમાં ખસેડવામાં આવ્યા છે, જેમ કે ગ્રાફના? અથવા તમે આ કાર્યક્ષમતાનો ઉપયોગ કરી રહ્યાં નથી?

MM: - હું ફરી એકવાર ભાર આપીશ: અમે સંપૂર્ણ એકીકરણ પ્રાપ્ત કર્યું છે. અમે ક્લિકહાઉસમાં ઇતિહાસ રેડી રહ્યા છીએ, પરંતુ તે જ સમયે અમે php ફ્રન્ટએન્ડ બદલ્યો છે. Php ફ્રન્ટએન્ડ ક્લિકહાઉસ પર જાય છે અને ત્યાંથી તમામ ગ્રાફિક્સ કરે છે. તે જ સમયે, પ્રમાણિક બનવા માટે, અમારી પાસે એક ભાગ છે જે સમાન ક્લિકહાઉસમાંથી અન્ય ગ્રાફિક ડિસ્પ્લે સિસ્ટમ્સમાં ડેટા બનાવે છે, તે જ Zabbix ડેટામાંથી.

MCH: - "ગ્રાફન" માં પણ.

સંસાધનોની ફાળવણી અંગેના નિર્ણયો કેવી રીતે લેવામાં આવ્યા?

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

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

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

એ: - અને ટીમનું કદ શું છે?

MCH: - તેણી તમારી સામે છે.

એ: - તો, હંમેશની જેમ, તમારે જુસ્સાની જરૂર છે?

MM: - મને ખબર નથી કે જુસ્સાદાર શું છે.

એ: - આ કિસ્સામાં, દેખીતી રીતે, તમે. તમારો ખૂબ ખૂબ આભાર, તમે અદ્ભુત છો.

MM: - આભાર.

Zabbix માટે પેચો વિશે

એ: – પ્રોક્સીઓનો ઉપયોગ કરતી સિસ્ટમ માટે (ઉદાહરણ તરીકે, કેટલીક વિતરિત સિસ્ટમોમાં), શું પોલર, પ્રોક્સી અને આંશિક રીતે ઝબ્બિક્સના જ પ્રીપ્રોસેસરને અનુકૂલન અને પેચ કરવું શક્ય છે; અને તેમની ક્રિયાપ્રતિક્રિયા? શું બહુવિધ પ્રોક્સીઓ સાથે સિસ્ટમ માટે હાલના વિકાસને ઑપ્ટિમાઇઝ કરવું શક્ય છે?

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

પ્રોક્સીઓમાં રસ સમજી શકાય તેવું છે. અમે તેને તપાસીશું. આ એક રસપ્રદ વિષય છે.

એ: - વિચાર આ હતો: જો તમે પોલર્સને પેચ કરી શકો છો, તો તમે તેમને પ્રોક્સી પર પેચ કરી શકો છો અને સર્વર સાથેની ક્રિયાપ્રતિક્રિયાને પેચ કરી શકો છો, અને ફક્ત સર્વર પર જ આ હેતુઓ માટે પ્રીપ્રોસેસરને અનુકૂળ કરી શકો છો.

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

એ: - મોટે ભાગે, તમારે સર્વર પર પ્રોક્સી ટ્રાન્સમિશનને પેચ કરવાની જરૂર નથી?

MCH: - ના, તે પ્રમાણભૂત છે.

MM: - વાસ્તવમાં, વિચારોમાંથી એક સંભળાતો ન હતો. અમે હંમેશા વિચારોના વિસ્ફોટ અને ફેરફારોની માત્રા અને સમર્થનની સરળતા વચ્ચે સંતુલન જાળવી રાખ્યું છે.

કેટલીક જાહેરાતો 🙂

અમારી સાથે રહેવા બદલ આભાર. શું તમને અમારા લેખો ગમે છે? વધુ રસપ્રદ સામગ્રી જોવા માંગો છો? ઓર્ડર આપીને અથવા મિત્રોને ભલામણ કરીને અમને ટેકો આપો, $4.99 થી વિકાસકર્તાઓ માટે ક્લાઉડ VPS, એન્ટ્રી-લેવલ સર્વર્સનું એક અનન્ય એનાલોગ, જેની શોધ અમારા દ્વારા તમારા માટે કરવામાં આવી છે: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps વિશેનું સંપૂર્ણ સત્ય $19 થી અથવા સર્વર કેવી રીતે શેર કરવું? (RAID1 અને RAID10 સાથે ઉપલબ્ધ, 24 કોરો સુધી અને 40GB DDR4 સુધી).

એમ્સ્ટરડેમમાં ઇક્વિનિક્સ ટાયર IV ડેટા સેન્ટરમાં ડેલ R730xd 2 ગણું સસ્તું? માત્ર અહીં 2 x ઇન્ટેલ ટેટ્રાડેકા-કોર Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ટીવી $199 થી નેધરલેન્ડમાં! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 થી! વિશે વાંચો ઇન્ફ્રાસ્ટ્રક્ચર કોર્પોરેશન કેવી રીતે બનાવવું. ડેલ R730xd E5-2650 v4 સર્વર્સના ઉપયોગ સાથેનો વર્ગ એક પેની માટે 9000 યુરોના મૂલ્યના છે?

સોર્સ: www.habr.com