બીજી મોનિટરિંગ સિસ્ટમ

16 મોડેમ, 4 સેલ્યુલર ઓપરેટર્સ = આઉટગોઇંગ સ્પીડ 933.45 Mbit/s

પરિચય

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

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

અમારી પાસે એક ચોક્કસ ઉત્પાદન છે. ડેટા ટ્રાન્સમિશન ચેનલોના થ્રુપુટ અને ફોલ્ટ ટોલરન્સનો સારાંશ આપવા માટે અમે એક વ્યાપક ઉકેલ તૈયાર કરીએ છીએ. આ તે છે જ્યારે ઘણી ચેનલો હોય છે, ચાલો કહીએ કે Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ બીજું કંઈક (5 Mbit/s), પરિણામ એક સ્થિર અને ઝડપી ચેનલ છે, જેની ઝડપ કંઈક આના જેવી હશે આ: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

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

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

સમસ્યાની રચના

મોનિટરિંગ સિસ્ટમ બે મૂળભૂત રીતે અલગ-અલગ વર્ગોના મેટ્રિક્સ પ્રદાન કરે છે: રીઅલ-ટાઇમ મેટ્રિક્સ અને અન્ય તમામ. મોનિટરિંગ સિસ્ટમમાં ફક્ત નીચેની આવશ્યકતાઓ હતી:

1. રીઅલ-ટાઇમ મેટ્રિક્સનું ઉચ્ચ-આવર્તન સિંક્રનસ એક્વિઝિશન અને વિલંબ કર્યા વિના સંચાર વ્યવસ્થાપન સિસ્ટમમાં તેમનું સ્થાનાંતરણ.
   વિવિધ મેટ્રિક્સની ઉચ્ચ આવર્તન અને સિંક્રનાઇઝેશન માત્ર મહત્વપૂર્ણ નથી, તે ડેટા ટ્રાન્સમિશન ચેનલોની એન્ટ્રોપીનું વિશ્લેષણ કરવા માટે મહત્વપૂર્ણ છે. જો એક ડેટા ટ્રાન્સમિશન ચેનલમાં સરેરાશ વિલંબ 30 મિલિસેકન્ડનો હોય, તો માત્ર એક મિલીસેકન્ડના બાકીના મેટ્રિક્સ વચ્ચે સિંક્રનાઇઝેશનમાં ભૂલ પરિણામી ચેનલની ઝડપમાં લગભગ 5% જેટલો ઘટાડો તરફ દોરી જશે. જો આપણે 1 ચેનલોમાં 4 મિલીસેકન્ડનો સમય ખોટો કરીએ, તો સ્પીડ ડીગ્રેડેશન સરળતાથી ઘટીને 30% થઈ શકે છે. વધુમાં, ચેનલોમાં એન્ટ્રોપી ખૂબ જ ઝડપથી બદલાય છે, તેથી જો આપણે તેને દર 0.5 મિલીસેકન્ડમાં એક કરતા ઓછા વખત માપીશું, તો નાના વિલંબ સાથે ઝડપી ચેનલો પર આપણને ઉચ્ચ ગતિનું અધોગતિ મળશે. અલબત્ત, આવી ચોકસાઈ તમામ મેટ્રિક્સ માટે જરૂરી નથી અને બધી પરિસ્થિતિઓમાં પણ નથી. જ્યારે ચેનલમાં વિલંબ 500 મિલિસેકન્ડનો હોય છે, અને અમે તેની સાથે કામ કરીએ છીએ, ત્યારે 1 મિલિસેકન્ડની ભૂલ લગભગ ધ્યાનપાત્ર રહેશે નહીં. ઉપરાંત, લાઇફ સપોર્ટ સિસ્ટમ મેટ્રિક્સ માટે, અમારી પાસે 2 સેકન્ડના પૂરતા મતદાન અને સિંક્રનાઇઝેશન રેટ છે, પરંતુ મોનિટરિંગ સિસ્ટમ પોતે જ અલ્ટ્રા-હાઇ પોલિંગ રેટ અને મેટ્રિક્સના અતિ-ચોક્કસ સિંક્રનાઇઝેશન સાથે કામ કરવા સક્ષમ હોવી જોઈએ.
2. ન્યૂનતમ સંસાધન વપરાશ અને એક સ્ટેક.
   અંતિમ ઉપકરણ કાં તો એક શક્તિશાળી ઓન-બોર્ડ કોમ્પ્લેક્સ હોઈ શકે છે જે રસ્તા પરની પરિસ્થિતિનું વિશ્લેષણ કરી શકે છે અથવા લોકોનું બાયોમેટ્રિક રેકોર્ડિંગ કરી શકે છે, અથવા એક હથેળીના કદના સિંગલ-બોર્ડ કમ્પ્યુટર હોઈ શકે છે જે વિડિયો પ્રસારિત કરવા માટે ખાસ દળોના સૈનિક તેના શરીરના બખ્તરની નીચે પહેરે છે. નબળી સંચાર પરિસ્થિતિઓમાં વાસ્તવિક સમય. આવા વિવિધ આર્કિટેક્ચર અને કમ્પ્યુટિંગ પાવર હોવા છતાં, અમે સમાન સોફ્ટવેર સ્ટેક રાખવા માંગીએ છીએ.
3. છત્રી આર્કિટેક્ચર
   મેટ્રિક્સને અંતિમ ઉપકરણ પર એકત્રિત અને એકીકૃત, સ્થાનિક રીતે સંગ્રહિત અને વાસ્તવિક સમયમાં અને પૂર્વવર્તી રીતે વિઝ્યુઅલાઈઝ કરવા જોઈએ. જો કનેક્શન હોય, તો સેન્ટ્રલ મોનિટરિંગ સિસ્ટમમાં ડેટા ટ્રાન્સફર કરો. જ્યારે કોઈ કનેક્શન ન હોય, ત્યારે મોકલવાની કતાર એકઠી થવી જોઈએ અને RAM નો વપરાશ ન કરવો જોઈએ.
4. ગ્રાહકની મોનિટરિંગ સિસ્ટમમાં એકીકરણ માટે API, કારણ કે કોઈને ઘણી મોનિટરિંગ સિસ્ટમ્સની જરૂર નથી. ગ્રાહકે કોઈપણ ઉપકરણો અને નેટવર્કમાંથી એક જ મોનિટરિંગમાં ડેટા એકત્રિત કરવો આવશ્યક છે.

શું થયું

પહેલેથી જ પ્રભાવશાળી લોન્ગરેડ પર ભાર ન આવે તે માટે, હું તમામ મોનિટરિંગ સિસ્ટમ્સના ઉદાહરણો અને માપન આપીશ નહીં. આ બીજા લેખ તરફ દોરી જશે. હું ફક્ત એટલું જ કહીશ કે અમે એક મોનિટરિંગ સિસ્ટમ શોધી શક્યા નથી જે 1 મિલિસેકન્ડથી ઓછી ભૂલ સાથે એકસાથે બે મેટ્રિક્સ લેવામાં સક્ષમ છે અને તે 64 MB RAM સાથે ARM આર્કિટેક્ચર અને 86 સાથે x64_32 આર્કિટેક્ચર બંને પર સમાન રીતે અસરકારક રીતે કાર્ય કરે છે. જીબી રેમ. તેથી, અમે અમારા પોતાના લખવાનું નક્કી કર્યું, જે આ બધું કરી શકે. અમને જે મળ્યું તે અહીં છે:

વિવિધ નેટવર્ક ટોપોલોજી માટે ત્રણ ચેનલોના થ્રુપુટનો સારાંશ

કેટલાક મુખ્ય મેટ્રિક્સનું વિઝ્યુલાઇઝેશન

સ્થાપત્ય

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

સિસ્ટમ ક્લાસિક મોડ્યુલર સિદ્ધાંત અનુસાર લાગુ કરવામાં આવી છે અને તેમાં ઘણી સબસિસ્ટમ્સ છે:

1. મેટ્રિક્સ નોંધણી.
   દરેક મેટ્રિક તેના પોતાના થ્રેડ દ્વારા આપવામાં આવે છે અને સમગ્ર ચેનલોમાં સિંક્રનાઇઝ થાય છે. અમે 10 નેનોસેકન્ડ્સ સુધી સિંક્રનાઇઝેશન ચોકસાઈ પ્રાપ્ત કરવામાં સક્ષમ હતા.
2. મેટ્રિક્સ સ્ટોરેજ
   અમે સમય શ્રેણી માટે અમારું પોતાનું સ્ટોરેજ લખવાનું અથવા પહેલેથી જ ઉપલબ્ધ હોય તેવી કોઈ વસ્તુનો ઉપયોગ કરવાનું પસંદ કરતા હતા. ડેટાબેઝની પૂર્વવૃત્તિની માહિતી માટે જરૂરી છે જે અનુગામી વિઝ્યુલાઇઝેશનને આધીન છે. એટલે કે, તેમાં ચેનલમાં દર 0.5 મિલીસેકન્ડમાં વિલંબ અથવા ટ્રાન્સપોર્ટ નેટવર્કમાં ભૂલ રીડિંગ્સ પરનો ડેટા નથી, પરંતુ દરેક ઇન્ટરફેસ પર દર 500 મિલિસેકન્ડે ઝડપ છે. ક્રોસ-પ્લેટફોર્મ અને ઓછા સંસાધન વપરાશ માટેની ઉચ્ચ આવશ્યકતાઓ ઉપરાંત, અમારા માટે પ્રક્રિયા કરવામાં સક્ષમ બનવું અત્યંત મહત્વપૂર્ણ છે. ડેટા જ્યાં સંગ્રહિત થાય છે. આ પ્રચંડ કમ્પ્યુટિંગ સંસાધનોને બચાવે છે. અમે 2016 થી આ પ્રોજેક્ટમાં ટેરન્ટૂલ DBMS નો ઉપયોગ કરી રહ્યા છીએ અને અત્યાર સુધી અમને ક્ષિતિજ પર તેના માટે કોઈ રિપ્લેસમેન્ટ દેખાતું નથી. લવચીક, શ્રેષ્ઠ સંસાધન વપરાશ સાથે, પર્યાપ્ત તકનીકી સપોર્ટ કરતાં વધુ. ટેરન્ટૂલ એક GIS મોડ્યુલ પણ લાગુ કરે છે. અલબત્ત, તે પોસ્ટજીઆઈએસ જેટલું શક્તિશાળી નથી, પરંતુ કેટલાક સ્થાન-સંબંધિત મેટ્રિક્સ (પરિવહન માટે સંબંધિત) સ્ટોર કરવાના અમારા કાર્યો માટે તે પૂરતું છે.
3. મેટ્રિક્સનું વિઝ્યુલાઇઝેશન
   અહીં બધું પ્રમાણમાં સરળ છે. અમે વેરહાઉસમાંથી ડેટા લઈએ છીએ અને તેને વાસ્તવિક સમયમાં અથવા પૂર્વવર્તી રીતે પ્રદર્શિત કરીએ છીએ.
4. સેન્ટ્રલ મોનિટરિંગ સિસ્ટમ સાથે ડેટાનું સિંક્રનાઇઝેશન.
   સેન્ટ્રલ મોનિટરિંગ સિસ્ટમ તમામ ઉપકરણોમાંથી ડેટા મેળવે છે, તેને ચોક્કસ ઇતિહાસ સાથે સંગ્રહિત કરે છે અને API દ્વારા ગ્રાહકની મોનિટરિંગ સિસ્ટમને મોકલે છે. ક્લાસિક મોનિટરિંગ સિસ્ટમ્સથી વિપરીત, જેમાં "હેડ" આસપાસ ચાલે છે અને ડેટા એકત્રિત કરે છે, અમારી પાસે વિપરીત યોજના છે. જ્યારે કનેક્શન હોય ત્યારે ઉપકરણો પોતે જ ડેટા મોકલે છે. આ એક ખૂબ જ મહત્વપૂર્ણ મુદ્દો છે, કારણ કે તે તમને તે સમયગાળા માટે ઉપકરણમાંથી ડેટા પ્રાપ્ત કરવાની મંજૂરી આપે છે જે દરમિયાન તે ઉપલબ્ધ ન હતું અને જ્યારે ઉપકરણ અનુપલબ્ધ હોય ત્યારે ચેનલો અને સંસાધનો લોડ કરી શકતા નથી. અમે ઈન્ફ્લક્સ મોનિટરિંગ સર્વરનો ઉપયોગ સેન્ટ્રલ મોનિટરિંગ સિસ્ટમ તરીકે કરીએ છીએ. તેના એનાલોગથી વિપરીત, તે પાછલી માહિતી આયાત કરી શકે છે (એટલે ​​કે, મેટ્રિક્સ પ્રાપ્ત થયાની ક્ષણથી અલગ ટાઇમ સ્ટેમ્પ સાથે). એકત્રિત મેટ્રિક્સને ગ્રાફના દ્વારા વિઝ્યુઅલાઈઝ કરવામાં આવે છે, ફાઇલ સાથે સંશોધિત કરવામાં આવે છે. આ પ્રમાણભૂત સ્ટેક પણ પસંદ કરવામાં આવ્યો હતો કારણ કે તે લગભગ કોઈપણ ગ્રાહક મોનિટરિંગ સિસ્ટમ સાથે તૈયાર API એકીકરણ ધરાવે છે.
5. સેન્ટ્રલ ડિવાઇસ મેનેજમેન્ટ સિસ્ટમ સાથે ડેટા સિંક્રનાઇઝેશન.
   ડિવાઇસ મેનેજમેન્ટ સિસ્ટમ ઝીરો ટચ પ્રોવિઝનિંગ (ફર્મવેર, રૂપરેખાંકન, વગેરે અપડેટ કરવું) લાગુ કરે છે અને, મોનિટરિંગ સિસ્ટમથી વિપરીત, ઉપકરણ દીઠ માત્ર સમસ્યાઓ પ્રાપ્ત કરે છે. આ ઑન-બોર્ડ હાર્ડવેર વૉચડોગ સેવાઓ અને લાઇફ સપોર્ટ સિસ્ટમ્સના તમામ મેટ્રિક્સના ઑપરેશન માટે ટ્રિગર્સ છે: CPU અને SSD તાપમાન, CPU લોડ, ફ્રી સ્પેસ અને ડિસ્ક પર સ્માર્ટ હેલ્થ. સબસિસ્ટમ સ્ટોરેજ પણ ટેરેન્ટૂલ પર બનેલ છે. આ અમને હજારો ઉપકરણોમાં સમય શ્રેણીને એકીકૃત કરવામાં નોંધપાત્ર ઝડપ આપે છે, અને આ ઉપકરણો સાથે ડેટાને સિંક્રનાઇઝ કરવાના મુદ્દાને પણ સંપૂર્ણપણે હલ કરે છે. ટેરન્ટૂલમાં ઉત્તમ કતાર અને ખાતરીપૂર્વકની ડિલિવરી સિસ્ટમ છે. અમને આ મહત્વપૂર્ણ સુવિધા બોક્સની બહાર મળી છે, સરસ!

નેટવર્ક મેનેજમેન્ટ સિસ્ટમ

આગળ શું છે

અત્યાર સુધી, અમારી સૌથી નબળી કડી કેન્દ્રીય મોનિટરિંગ સિસ્ટમ છે. તે પ્રમાણભૂત સ્ટેક પર 99.9% લાગુ કરવામાં આવે છે અને તેના ઘણા ગેરફાયદા છે:

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

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

નિષ્કર્ષ

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

જો કોઈને આ લેખના અવકાશની બહારના પ્રશ્નો હોય, તો તમે મને a.rodin @ qedr.com પર લખી શકો છો

સોર્સ: www.habr.com