ગુમ થયેલ સ્કૂટર પરત કરો, અથવા એક IoT મોનિટરિંગની વાર્તા

એક વર્ષ પહેલાં અમે પ્રમોશનલ પ્રોજેક્ટનું પાઇલટ વર્ઝન લૉન્ચ કર્યું હતું ઇલેક્ટ્રિક સ્કૂટરનું વિકેન્દ્રિત ભાડું.

શરૂઆતમાં, પ્રોજેક્ટને રોડ-ટુ-બાર્સેલોના કહેવામાં આવતું હતું, પછીથી તે રોડ-ટુ-બર્લિન બન્યું (તેથી સ્ક્રીનશોટમાં R2B), અને અંતે તેને xRide કહેવામાં આવ્યું.

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

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

વપરાશકર્તાએ ફોન પર iOS અથવા Android એપ્લિકેશન ઇન્સ્ટોલ કરી, તેને ગમતા સ્કૂટરનો સંપર્ક કર્યો, ત્યારબાદ ફોન અને સ્કૂટરે પીઅર-ટુ-પીઅર કનેક્શન સ્થાપિત કર્યું, ETH ની આપ-લે કરવામાં આવી અને વપરાશકર્તા સ્કૂટર ચાલુ કરીને રાઇડ શરૂ કરી શકે છે. ફોન. સફરના અંતે, ફોન પરના વપરાશકર્તાના વૉલેટમાંથી Ethereum નો ઉપયોગ કરીને સફર માટે ચૂકવણી કરવાનું પણ શક્ય હતું.

સ્કૂટર ઉપરાંત, વપરાશકર્તાએ એપ્લિકેશનમાં “સ્માર્ટ ચાર્જર” જોયું, જેની મુલાકાત લઈને વપરાશકર્તા વર્તમાન બેટરી ઓછી હોય તો તેને જાતે બદલી શકે છે.

આ સામાન્ય રીતે અમારા પાયલોટ જેવો દેખાતો હતો, જે ગયા વર્ષે સપ્ટેમ્બરમાં બે જર્મન શહેરો: બોન અને બર્લિનમાં લોન્ચ કરવામાં આવ્યો હતો.

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

તેને કેવી રીતે શોધવું અને પરત કરવું?

આ લેખમાં હું આ વિશે વાત કરીશ, પરંતુ પ્રથમ - અમે અમારું પોતાનું IoT પ્લેટફોર્મ કેવી રીતે બનાવ્યું અને અમે તેનું નિરીક્ષણ કેવી રીતે કર્યું તે વિશે.

શું અને શા માટે મોનિટર કરવું: સ્કૂટર, ઈન્ફ્રાસ્ટ્રક્ચર, ચાર્જિંગ સ્ટેશન?

તો, અમે અમારા પ્રોજેક્ટમાં શું મોનિટર કરવા માગીએ છીએ?

સૌ પ્રથમ, આ પોતે સ્કૂટર છે - ઇલેક્ટ્રિક સ્કૂટર પોતે ખૂબ ખર્ચાળ છે, તમે પૂરતા પ્રમાણમાં તૈયાર થયા વિના આવા પ્રોજેક્ટને શરૂ કરી શકતા નથી; જો શક્ય હોય, તો તમે સ્કૂટર વિશે શક્ય તેટલી વધુ માહિતી એકત્રિત કરવા માંગો છો: તેમના સ્થાન વિશે, ચાર્જ સ્તર વિશે , વગેરે

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

સ્કૂટર

અમારા સ્કૂટર શું હતા અને અમે તેમના વિશે શું જાણવા માગીએ છીએ?

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

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

અલબત્ત, અમારા હાર્ડવેર ઘટકો સાથે શું થઈ રહ્યું છે તે તપાસવું પણ જરૂરી છે:

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

અને છેલ્લે: સૉફ્ટવેરની તપાસ, OS અને પ્રોસેસર, નેટવર્ક અને ડિસ્ક લોડથી શરૂ કરીને, અમારા પોતાના મોડ્યુલોની તપાસ સાથે સમાપ્ત થાય છે જે અમારા માટે વધુ વિશિષ્ટ છે (જોલોકોમ, કીક્લોક).

હાર્ડવેર

આપણો "લોખંડ" ભાગ શું હતો?

ટૂંકી શક્ય સમયમર્યાદા અને ઝડપી પ્રોટોટાઇપિંગની જરૂરિયાતને ધ્યાનમાં રાખીને, અમે અમલીકરણ અને ઘટકોની પસંદગી માટે સૌથી સરળ વિકલ્પ પસંદ કર્યો - રાસ્પબેરી પી.
આરપીઆઈ ઉપરાંત, અમારી પાસે એક કસ્ટમ બોર્ડ હતું (જે અમે જાતે વિકસાવ્યું હતું અને અંતિમ ઉકેલની એસેમ્બલી પ્રક્રિયાને ઝડપી બનાવવા માટે ચાઇનાથી આદેશ આપ્યો હતો) અને ઘટકોનો સમૂહ - એક રિલે (સ્કૂટરને ચાલુ/બંધ કરવા માટે), બેટરી ચાર્જ રીડર, મોડેમ, એન્ટેના. આ બધું એક ખાસ “xRide બોક્સ”માં કોમ્પેક્ટલી પેક કરવામાં આવ્યું હતું.

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

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

ડોકર? સાદો Linux? અને જમાવટ

ચાલો મોનિટરિંગ પર પાછા આવીએ, તેથી રાસ્પબેરી - અમારી પાસે શું છે?

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

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

"મૂળ" OS નો ઉપયોગ કરીને તફાવત, જો કે તેટલો મજબૂત નથી, તેમ છતાં, અમને ખૂબ ઝડપથી ચાર્જ ગુમાવવાની સંભાવનાથી સાવચેત રહેવા માટે પૂરતો હતો.

બીજું કારણ Node.js (sic!) પરની અમારી ભાગીદાર પુસ્તકાલયોમાંની એક હતી - સિસ્ટમનો એકમાત્ર ઘટક જે Go/C/C++ માં લખાયો ન હતો.

પુસ્તકાલયના લેખકો પાસે કોઈપણ "મૂળ" ભાષાઓમાં કાર્યકારી સંસ્કરણ પ્રદાન કરવાનો સમય નથી.

નીચા-પ્રદર્શન ઉપકરણો માટે નોડ પોતે જ સૌથી ભવ્ય ઉકેલ નથી, પરંતુ પુસ્તકાલય પોતે ખૂબ સંસાધન-ભૂખ્યા હતા.

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

OS

પરિણામે, અમે, ફરીથી, OS તરીકે સૌથી સરળ વિકલ્પ પસંદ કર્યો અને Raspbian (Pi માટે ડેબિયન બિલ્ડ) નો ઉપયોગ કર્યો.

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

તે તે છે જે જીપીએસ, બ્લુટુથ સાથે કામ કરવા, ચાર્જ વાંચવા, સ્કૂટર ચાલુ કરવા વગેરે માટે જવાબદાર છે.

જમાવટ કરો

ઉપકરણ (OTA) પર અપડેટ્સ પહોંચાડવા માટેની મિકેનિઝમને અમલમાં મૂકવાની જરૂરિયાત વિશે તરત જ પ્રશ્ન ઊભો થયો - અમારા એજન્ટ/એપ્લિકેશનના અપડેટ્સ અને OS/ફર્મવેરના અપડેટ્સ (કારણ કે એજન્ટના નવા સંસ્કરણોને કર્નલમાં અપડેટ્સની જરૂર પડી શકે છે. અથવા સિસ્ટમ ઘટકો, પુસ્તકાલયો, વગેરે).

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

પ્રમાણમાં સરળ, swupd/SWUpdate/OSTree જેવી મોટાભાગે અપડેટ/ડ્યુઅલ-બૂટ ઓરિએન્ટેડ યુટિલિટીઝથી લઈને મેન્ડર અને બલેના જેવા સંપૂર્ણ પ્લેટફોર્મ પર.

સૌ પ્રથમ, અમે નક્કી કર્યું કે અમને એન્ડ-ટુ-એન્ડ સોલ્યુશન્સમાં રસ છે, તેથી પસંદગી તરત જ પ્લેટફોર્મ પર પડી.

પોતાને બલેના તે હકીકતને કારણે બાકાત રાખવામાં આવ્યું હતું કે તે વાસ્તવમાં તેના balenaEngine ની અંદર સમાન ડોકરનો ઉપયોગ કરે છે.

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

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

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

અરે, અમારી ચુસ્ત સમયમર્યાદાનો અર્થ એ છે કે અમને મેન્ડરનો ઉપયોગ છોડી દેવાની અને તેનાથી પણ સરળ પસંદ કરવાની ફરજ પડી હતી.

Ansible

અમારી પરિસ્થિતિમાં સૌથી સરળ ઉકેલ એન્સિબલનો ઉપયોગ કરવાનો હતો. શરૂઆત કરવા માટે થોડીક પ્લેબુક પૂરતી હતી.

તેમનો સાર એ હતો કે અમે ફક્ત હોસ્ટ (CI સર્વર) થી ssh દ્વારા અમારી રાસબેરી સાથે કનેક્ટ કર્યું અને તેમને અપડેટ્સનું વિતરણ કર્યું.

ખૂબ જ શરૂઆતમાં, બધું સરળ હતું - તમારે ઉપકરણો સાથે સમાન નેટવર્ક પર હોવું જરૂરી હતું, રેડવાની પ્રક્રિયા Wi-Fi દ્વારા કરવામાં આવી હતી.

ઓફિસમાં એક જ નેટવર્ક સાથે માત્ર એક ડઝન ટેસ્ટ રાસબેરી જોડાયેલી હતી, દરેક ઉપકરણમાં એક સ્થિર IP સરનામું હતું જે એન્સિબલ ઇન્વેન્ટરીમાં પણ ઉલ્લેખિત હતું.

તે Ansible હતું જેણે અમારા મોનિટરિંગ એજન્ટને અંતિમ ઉપકરણો સુધી પહોંચાડ્યું

3G / એલટીઇ

કમનસીબે, અમારી પાસે વાસ્તવિક સ્કૂટર હોય તે પહેલાં જ Ansible માટેનો આ ઉપયોગ વિકાસ મોડમાં જ કામ કરી શકે છે.

કારણ કે સ્કૂટર, જેમ તમે સમજો છો, એક Wi-Fi રાઉટર સાથે કનેક્ટ કરીને બેસો નહીં, સતત નેટવર્ક પર અપડેટ્સની રાહ જુઓ.

વાસ્તવમાં, સ્કૂટર પાસે મોબાઇલ 3G/LTE સિવાય અન્ય કોઈ કનેક્શન હોઈ શકતું નથી (અને પછી પણ હંમેશા નહીં).

આ તરત જ ઘણી સમસ્યાઓ અને મર્યાદાઓ લાદે છે, જેમ કે કનેક્શનની ઓછી ઝડપ અને અસ્થિર સંચાર.

પરંતુ સૌથી મહત્વની બાબત એ છે કે 3G/LTE નેટવર્કમાં આપણે નેટવર્કને સોંપેલ સ્ટેટિક IP પર આધાર રાખી શકતા નથી.

કેટલાક સિમ કાર્ડ પ્રદાતાઓ દ્વારા આ આંશિક રીતે ઉકેલવામાં આવે છે; સ્થિર IP સરનામાંવાળા IoT ઉપકરણો માટે ડિઝાઇન કરાયેલ ખાસ સિમ કાર્ડ્સ પણ છે. પરંતુ અમારી પાસે આવા સિમ કાર્ડ્સની ઍક્સેસ નથી અને અમે IP સરનામાંનો ઉપયોગ કરી શકતા નથી.

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

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

વીપીએન

આ સમસ્યાના ઉકેલ તરીકે, અમે VPN પસંદ કર્યું - ખાસ વાયરગાર્ડ.

સિસ્ટમની શરૂઆતમાં ગ્રાહકો (સ્કૂટર) VPN સર્વર સાથે જોડાયેલા હતા અને તેમની સાથે કનેક્ટ થવામાં સક્ષમ હતા. આ ટનલનો ઉપયોગ અપડેટ્સ પહોંચાડવા માટે થતો હતો.

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

મેઘ સંસાધનો

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

આપેલ

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

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

અંતિમ છબી કંઈક આના જેવી દેખાતી હતી

સ્ટેક પસંદગી

તેથી, અમને મોનિટરિંગ સ્ટેક પસંદ કરવાના પ્રશ્નનો સામનો કરવો પડ્યો.

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

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

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

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

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

આ બધા સાથે, અમે એક સંપૂર્ણ મોનિટરિંગ પ્લેટફોર્મ જાતે એસેમ્બલ કરવાનો પ્રયાસ કર્યો ન હતો, પરંતુ સૌથી વધુ કાર્યકારી "તૈયાર" સ્ટેક્સ શોધી રહ્યા હતા, ફક્ત તેમને લવચીક રીતે ગોઠવવાની ક્ષમતા સાથે.

(B)ELK?

પ્રથમ સોલ્યુશન જે ખરેખર માનવામાં આવતું હતું તે જાણીતું ELK સ્ટેક હતું.
હકીકતમાં, તેને BELK કહેવા જોઈએ, કારણ કે તે બધા બીટ્સથી શરૂ થાય છે - https://www.elastic.co/what-is/elk-stack

અલબત્ત, ELK એ મોનિટરિંગના ક્ષેત્રમાં સૌથી પ્રસિદ્ધ અને શક્તિશાળી ઉકેલો પૈકીનું એક છે, અને તેથી પણ વધુ લોગ એકત્રિત કરવા અને પ્રક્રિયા કરવા માટે.

અમારો ઇરાદો હતો કે ELK નો ઉપયોગ લોગ એકત્રિત કરવા અને તેમજ પ્રોમિથિયસ પાસેથી મેળવેલ મેટ્રિક્સના લાંબા ગાળાના સંગ્રહ માટે કરવામાં આવશે.

વિઝ્યુલાઇઝેશન માટે તમે ગ્રાફનનો ઉપયોગ કરી શકો છો.

વાસ્તવમાં, નવો ELK સ્ટેક સ્વતંત્ર રીતે મેટ્રિક્સ એકત્રિત કરી શકે છે (મેટ્રિકબીટ), અને કિબાના પણ તેમને પ્રદર્શિત કરી શકે છે.

પરંતુ તેમ છતાં, ELK શરૂઆતમાં લૉગ્સમાંથી વિકસ્યું હતું અને અત્યાર સુધી મેટ્રિક્સની કાર્યક્ષમતામાં ઘણી ગંભીર ખામીઓ છે:

• પ્રોમિથિયસ કરતાં નોંધપાત્ર રીતે ધીમું
• પ્રોમિથિયસ કરતાં ઘણા ઓછા સ્થળોએ એકીકૃત થાય છે
• તેમના માટે ચેતવણીઓ સેટ કરવી મુશ્કેલ છે
• મેટ્રિક્સ ઘણી જગ્યા લે છે
• ગ્રાફન કરતાં કિબાનમાં મેટ્રિક્સ સાથે ડેશબોર્ડ સેટ કરવું વધુ જટિલ છે

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

અને ELK સ્ટેકમાં ઘણી મુશ્કેલ ક્ષણો છે:

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

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

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

લોકી - ગ્રાફના - પ્રોમિથિયસ

આ ક્ષણે, એક સારો ઉકેલ મેટ્રિક્સ પ્રદાતા તરીકે પ્રોમિથિયસ પર આધારિત મોનિટરિંગ સ્ટેક, લોગ માટે લોકી અને વિઝ્યુલાઇઝેશન માટે તમે સમાન ગ્રાફનાનો ઉપયોગ કરી શકો છો.

કમનસીબે, પ્રોજેક્ટના વેચાણ પાયલોટની શરૂઆતના સમયે (સપ્ટેમ્બર-ઓક્ટોબર 19), લોકી હજી પણ બીટા સંસ્કરણ 0.3-0.4 માં હતું, અને વિકાસની શરૂઆતના સમયે તેને ઉત્પાદન ઉકેલ તરીકે ગણી શકાય નહીં. બધા પર.

મને હજુ સુધી ગંભીર પ્રોજેક્ટ્સમાં લોકીનો વાસ્તવમાં ઉપયોગ કરવાનો અનુભવ નથી, પરંતુ હું કહી શકું છું કે પ્રોમટેલ (લોગ એકત્ર કરવા માટેનો એજન્ટ) બેર-મેટલ અને કુબરનેટ્સમાં શીંગો બંને માટે સરસ કામ કરે છે.

ટિક

ELK સ્ટેક માટે કદાચ સૌથી લાયક (એકમાત્ર?) સંપૂર્ણ સુવિધાયુક્ત વિકલ્પને હવે ફક્ત TICK સ્ટેક કહી શકાય - ટેલિગ્રાફ, ઇન્ફ્લક્સડીબી, ક્રોનોગ્રાફ, કેપેસિટર.

હું નીચેના તમામ ઘટકોનું વધુ વિગતવાર વર્ણન કરીશ, પરંતુ સામાન્ય વિચાર આ છે:

• ટેલિગ્રાફ - મેટ્રિક્સ એકત્રિત કરવા માટે એજન્ટ
• InfluxDB - મેટ્રિક્સ ડેટાબેઝ
• કેપેસિટર - ચેતવણી માટે રીઅલ-ટાઇમ મેટ્રિક્સ પ્રોસેસર
• ક્રોનોગ્રાફ - વિઝ્યુલાઇઝેશન માટે વેબ પેનલ

InfluxDB, Kapacitor અને Chronograf માટે અધિકૃત સુકાન ચાર્ટ્સ છે જેનો અમે ઉપયોગ કરતા હતા.

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

ટેલિગ્રાફ

ટેલિગ્રાફ રાજ્ય મશીન પર મેટ્રિક્સ એકત્રિત કરવા માટે ખૂબ જ હળવા એજન્ટ છે.

તેમણે દરેક વસ્તુ એક વિશાળ જથ્થો મોનીટર કરી શકો છો, થી nginx માટે
સર્વર Minecraft.

તેના અસંખ્ય શાનદાર ફાયદા છે:

• ઝડપી અને હલકો (ગો માં લખાયેલ)
  • સંસાધનોની ન્યૂનતમ રકમ ખાય છે
• ડિફૉલ્ટ રૂપે મેટ્રિક્સને દબાણ કરો
• તમામ જરૂરી મેટ્રિક્સ એકત્રિત કરે છે
  • કોઈપણ સેટિંગ્સ વિના સિસ્ટમ મેટ્રિક્સ
  • હાર્ડવેર મેટ્રિક્સ જેમ કે સેન્સરમાંથી માહિતી
  • તમારા પોતાના મેટ્રિક્સ ઉમેરવાનું ખૂબ જ સરળ છે
• બૉક્સની બહાર ઘણાં બધાં પ્લગિન્સ
• લોગ એકત્રિત કરે છે

અમારા માટે પુશ મેટ્રિક્સ જરૂરી હોવાથી, અન્ય તમામ લાભો સુખદ ઉમેરણો કરતાં વધુ હતા.

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

જો તમે ઉપયોગ કરો છો તો ઇન્ફ્લક્સ લોગ સાથે કામ કરવા માટે સૌથી અનુકૂળ અનુભવ પ્રદાન કરે છે syslog.

ટેલિગ્રાફ સામાન્ય રીતે મેટ્રિક્સ એકત્ર કરવા માટે એક ઉત્તમ એજન્ટ છે, પછી ભલે તમે બાકીના ICK સ્ટેકનો ઉપયોગ ન કરો.

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

InfluxDB

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

InfluxDB પણ Go માં લખાયેલું છે અને અમારા (સૌથી શક્તિશાળી નથી) ક્લસ્ટર પર ELK ની તુલનામાં ખૂબ ઝડપથી ચાલે છે.

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

ગેરફાયદા - $$$ અથવા સ્કેલિંગ?

TICK સ્ટેકમાં માત્ર એક ખામી છે જે અમે શોધી કાઢી છે - તે પ્રિય. પણ વધુ.

પેઇડ વર્ઝનમાં શું છે જે ફ્રી વર્ઝનમાં નથી?

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

એટલે કે, તમે ફક્ત ઉચ્ચ ઉપલબ્ધતા સાથે ક્લસ્ટર ઉભા કરી શકો છો એન્ટરપ્રાઇઝ આવૃત્તિઓ.

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

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

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

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

વિક્ટોરિયા મેટ્રિક્સ?

પરિણામે, અમે પેઇડ સ્કેલિંગ સિવાયની દરેક બાબતમાં TICK સ્ટેકથી સંપૂર્ણપણે સંતુષ્ટ હોવા છતાં, અમે બાકીના T_CK ઘટકોને છોડીને, InfluxDB ડેટાબેઝને બદલી શકે તેવા કોઈ મફત ઉકેલો છે કે કેમ તે જોવાનું અમે નક્કી કર્યું.

ત્યાં ઘણા બધા સમય-શ્રેણી ડેટાબેસેસ છે, પરંતુ સૌથી આશાસ્પદ એક વિક્ટોરિયા મેટ્રિક્સ છે, તેના ઘણા ફાયદા છે:

• ઝડપી અને સરળ, ઓછામાં ઓછા પરિણામો અનુસાર બેન્ચમાર્ક
• ત્યાં એક ક્લસ્ટર સંસ્કરણ છે, જેના વિશે હવે સારી સમીક્ષાઓ પણ છે
  • તેણી શૉર્ડ કરી શકે છે
• InfluxDB પ્રોટોકોલને સપોર્ટ કરે છે

અમારો વિક્ટોરિયા પર આધારિત સંપૂર્ણપણે કસ્ટમ સ્ટેક બનાવવાનો ઈરાદો નહોતો અને મુખ્ય આશા એ હતી કે અમે તેનો ઉપયોગ InfluxDB માટે ડ્રોપ-ઇન રિપ્લેસમેન્ટ તરીકે કરી શકીએ.

કમનસીબે, આ શક્ય નથી, હકીકત એ છે કે InfluxDB પ્રોટોકોલ સમર્થિત હોવા છતાં, તે ફક્ત મેટ્રિક્સ રેકોર્ડ કરવા માટે કાર્ય કરે છે - ફક્ત Prometheus API "બહાર" ઉપલબ્ધ છે, જેનો અર્થ છે કે તેના પર ક્રોનોગ્રાફ સેટ કરવું શક્ય બનશે નહીં.

વધુમાં, માત્ર આંકડાકીય મૂલ્યો મેટ્રિક્સ માટે સમર્થિત છે (અમે કસ્ટમ મેટ્રિક્સ માટે સ્ટ્રિંગ મૂલ્યોનો ઉપયોગ કર્યો છે - વિભાગમાં તેના પર વધુ એડમિન પેનલ).

દેખીતી રીતે, આ જ કારણસર, VM ઇન્ફ્લક્સની જેમ લોગ સ્ટોર કરી શકતું નથી.

ઉપરાંત, એ નોંધવું જોઈએ કે શ્રેષ્ઠ ઉકેલની શોધ કરતી વખતે, વિક્ટોરિયા મેટ્રિક્સ હજી એટલી લોકપ્રિય નહોતી, દસ્તાવેજીકરણ ખૂબ નાનું હતું અને કાર્યક્ષમતા નબળી હતી.
(મને ક્લસ્ટર સંસ્કરણ અને શાર્ડિંગનું વિગતવાર વર્ણન યાદ નથી).

આધાર પસંદગી

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

આ પસંદગીના ઘણા મુખ્ય કારણો હતા:

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

પાયલોટના પ્રથમ તબક્કા માટે અમારી પાસે ઘણા સ્કૂટર નહોતા, અને વિકાસ દરમિયાન પરીક્ષણમાં કોઈ કાર્યપ્રદર્શન સમસ્યાઓ સામે આવી ન હતી.

તેથી, અમે નક્કી કર્યું કે આ પ્રોજેક્ટ માટે એક ઇન્ફ્લક્સ નોડ સ્કેલિંગની જરૂર વગર અમારા માટે પૂરતું હશે (અંતમાં તારણો જુઓ).

અમે સ્ટેક અને બેઝ પર નિર્ણય લીધો છે - હવે TICK સ્ટેકના બાકીના ઘટકો વિશે.

કેપેસિટર

કેપેસિટર એ TICK સ્ટેકનો એક ભાગ છે, એક એવી સેવા જે ડેટાબેઝમાં દાખલ થતા મેટ્રિક્સને વાસ્તવિક સમયમાં મોનિટર કરી શકે છે અને નિયમોના આધારે વિવિધ ક્રિયાઓ કરી શકે છે.

સામાન્ય રીતે, તે સંભવિત વિસંગતતા ટ્રેકિંગ અને મશીન લર્નિંગ માટેના સાધન તરીકે સ્થિત છે (મને ખાતરી નથી કે આ કાર્યોની માંગ છે), પરંતુ તેના ઉપયોગનો સૌથી લોકપ્રિય કેસ વધુ સામાન્ય છે - ચેતવણી.

આ રીતે અમે સૂચનાઓ માટે તેનો ઉપયોગ કર્યો. જ્યારે કોઈ ચોક્કસ સ્કૂટર ઑફલાઈન થઈ જાય ત્યારે અમે સ્લૅક ચેતવણીઓ સેટ કરીએ છીએ અને સ્માર્ટ ચાર્જર અને મહત્ત્વના ઈન્ફ્રાસ્ટ્રક્ચર ઘટકો માટે પણ એવું જ કરવામાં આવ્યું હતું.

આનાથી સમસ્યાઓનો ઝડપથી જવાબ આપવાનું શક્ય બન્યું, તેમજ સૂચનાઓ પ્રાપ્ત થઈ કે બધું સામાન્ય થઈ ગયું છે.

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

ઇનફ્લક્સ 2.0 કેપેસિટર DB નો ભાગ બન્યો

કાલઆલેખક

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

અમે TICK સ્ટેકનો ઉપયોગ કરવાનું શરૂ કર્યું, વિચિત્ર રીતે, વેબ ઈન્ટરફેસ તરીકે Grafan સાથે.
હું તેની કાર્યક્ષમતાનું વર્ણન કરીશ નહીં; દરેક વ્યક્તિ કંઈપણ સેટ કરવા માટે તેની વિશાળ શક્યતાઓ જાણે છે.

જો કે, ગ્રાફના હજુ પણ સંપૂર્ણપણે સાર્વત્રિક સાધન છે, જ્યારે ક્રોનોગ્રાફ મુખ્યત્વે ઇન્ફ્લક્સ સાથે ઉપયોગ માટે રચાયેલ છે.

અને અલબત્ત, આનો આભાર, ક્રોનોગ્રાફ વધુ હોંશિયાર અથવા અનુકૂળ કાર્યક્ષમતા પરવડી શકે છે.

કદાચ ક્રોનોગ્રાફ સાથે કામ કરવાની મુખ્ય સગવડ એ છે કે તમે અન્વેષણ દ્વારા તમારા ઇન્ફ્લક્સડીબીની અંદરના ભાગને જોઈ શકો છો.

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

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

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

ડેશબોર્ડ્સ પોતે, સુખદ દ્રશ્ય શૈલી સિવાય, વાસ્તવમાં ગ્રાફના અથવા કિબાનાના ડેશબોર્ડ્સથી અલગ નથી:

ક્વેરી વિન્ડો આના જેવી દેખાય છે:

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

અને અલબત્ત, ક્રોનોગ્રાફ લોગ જોવા માટે શક્ય તેટલું અનુકૂળ છે. તે આના જેવું દેખાય છે:

મૂળભૂત રીતે, ઇન્ફ્લક્સ લોગ્સ સિસ્લોગનો ઉપયોગ કરવા માટે તૈયાર કરવામાં આવે છે અને તેથી તેમની પાસે એક મહત્વપૂર્ણ પરિમાણ છે - ગંભીરતા.

ટોચ પરનો ગ્રાફ ખાસ કરીને ઉપયોગી છે; તેના પર તમે જે ભૂલો થાય છે તે જોઈ શકો છો અને જો તીવ્રતા વધારે હોય તો રંગ તરત જ સ્પષ્ટપણે બતાવે છે.

બે વખત અમે મહત્વપૂર્ણ ભૂલો આ રીતે પકડ્યા, છેલ્લા અઠવાડિયાના લોગ જોવા જઈએ છીએ અને લાલ સ્પાઇક જોયા છે.

અલબત્ત, આદર્શ રીતે આવી ભૂલો માટે ચેતવણીઓ સેટ કરવી પડશે, કારણ કે અમારી પાસે આ માટે બધું પહેલેથી જ હતું.

અમે આને થોડા સમય માટે ચાલુ પણ કર્યું હતું, પરંતુ પાયલોટ તૈયાર કરવાની પ્રક્રિયામાં તે બહાર આવ્યું કે અમને ઘણી બધી ભૂલો આવી રહી છે (LTE નેટવર્કની અનુપલબ્ધતા જેવી સિસ્ટમ સહિત), જેણે સ્લેક ચેનલને પણ "સ્પામ" કરી. ખૂબ, કોઈપણ સમસ્યા ઊભી કર્યા વિના. મહાન લાભ.

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

આ રીતે, ફક્ત નવી અથવા મહત્વપૂર્ણ ભૂલો જ Slack પર પોસ્ટ કરવામાં આવશે. ચુસ્ત સમયમર્યાદાને જોતાં આવા સેટઅપ માટે પૂરતો સમય નહોતો.

પ્રમાણીકરણ

એ પણ ઉલ્લેખનીય છે કે ક્રોનોગ્રાફ ઓથેન્ટિકેશન તરીકે OAuth અને OIDC ને સપોર્ટ કરે છે.

આ ખૂબ જ અનુકૂળ છે, કારણ કે તે તમને તેને તમારા સર્વર સાથે સરળતાથી જોડવાની અને સંપૂર્ણ સુવિધાયુક્ત SSO બનાવવાની મંજૂરી આપે છે.

અમારા કિસ્સામાં, સર્વર હતું કીક્લોક — તેનો ઉપયોગ મોનિટરિંગ સાથે જોડાવા માટે થતો હતો, પરંતુ તે જ સર્વરનો ઉપયોગ સ્કૂટરને પ્રમાણિત કરવા અને બેક-એન્ડની વિનંતીઓ માટે પણ થતો હતો.

"એડમિન"

છેલ્લું ઘટક જેનું હું વર્ણન કરીશ તે Vue માં અમારી સ્વ-લિખિત "એડમિન પેનલ" છે.
મૂળભૂત રીતે તે માત્ર એક સ્વતંત્ર સેવા છે જે અમારા પોતાના ડેટાબેઝ, માઇક્રોસર્વિસિસ અને ઇન્ફ્લક્સડીબીના મેટ્રિક્સ ડેટામાંથી સ્કૂટરની માહિતી એક સાથે પ્રદર્શિત કરે છે.

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

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

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

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

અલબત્ત, અમારા માટે સૌથી મહત્વપૂર્ણ માપદંડ સ્કૂટરની ઓપરેટિંગ સ્થિતિ હતી - વાસ્તવમાં, ઇન્ફ્લક્સ આ પોતે જ તપાસે છે અને નોડ્સ વિભાગમાં તેને "લીલી લાઇટ" સાથે બતાવે છે.

આ કાર્ય દ્વારા કરવામાં આવે છે મૃત માણસ — અમે તેનો ઉપયોગ અમારા બોક્સના પ્રદર્શનને સમજવા અને તે જ ચેતવણીઓ Slack ને મોકલવા માટે કર્યો છે.

માર્ગ દ્વારા, અમે સ્કૂટર્સનું નામ ધ સિમ્પસનના પાત્રોના નામ પર રાખ્યું - તેમને એકબીજાથી અલગ પાડવાનું ખૂબ અનુકૂળ હતું

અને સામાન્ય રીતે તે આ રીતે વધુ મનોરંજક હતું. "ગાય્સ, સ્મિથર્સ મૃત્યુ પામ્યા છે!" જેવા શબ્દસમૂહો સતત સાંભળવામાં આવતા હતા.

સ્ટ્રિંગ મેટ્રિક્સ

તે મહત્વપૂર્ણ છે કે InfluxDB તમને માત્ર આંકડાકીય મૂલ્યો જ સંગ્રહિત કરવાની મંજૂરી આપે છે, જેમ કે વિક્ટોરિયા મેટ્રિક્સના કિસ્સામાં છે.

એવું લાગે છે કે આ એટલું મહત્વનું નથી - છેવટે, લોગ્સ સિવાય, કોઈપણ મેટ્રિક્સ નંબરોના સ્વરૂપમાં સંગ્રહિત કરી શકાય છે (ફક્ત જાણીતા રાજ્યો માટે મેપિંગ ઉમેરો - એક પ્રકારનું એનમ)?

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

પરિણામે, ચાર્જિંગ API આદર્શથી દૂર હતું, પરંતુ મુખ્ય સમસ્યા એ હતી કે અમે હંમેશા તેમની સ્થિતિને સમજી શકતા નથી.

આ તે છે જ્યાં પ્રવાહ બચાવમાં આવ્યો. અમે ફક્ત તે સ્ટ્રિંગ સ્ટેટસ લખી છે જે અમને InfluxDB ડેટાબેઝ ફીલ્ડમાં બદલાવ કર્યા વિના આવે છે.

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

તે પછીથી બહાર આવ્યું તેમ, આ સ્થિતિ કનેક્શન ગુમાવ્યા પછી એકવાર મોકલવામાં આવી હતી, જો ચાર્જર ચોક્કસ સંખ્યાના પ્રયત્નો પછી સર્વર સાથે કનેક્શન સ્થાપિત કરી શક્યું ન હતું.

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

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

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

જ્યારે અમે સ્કૂટર શોધી રહ્યા હતા ત્યારે આ અમારા માટે ખૂબ જ ઉપયોગી હતું (અંતમાં તારણો જુઓ).

ઈન્ફ્રાસ્ટ્રક્ચર મોનીટરીંગ

સ્કૂટર ઉપરાંત, અમારે અમારા સમગ્ર (બદલે વ્યાપક) ઈન્ફ્રાસ્ટ્રક્ચરનું નિરીક્ષણ કરવાની પણ જરૂર હતી.

એક ખૂબ જ સામાન્ય આર્કિટેક્ચર કંઈક આના જેવું દેખાતું હતું:

જો આપણે શુદ્ધ મોનિટરિંગ સ્ટેકને પ્રકાશિત કરીએ, તો તે આના જેવો દેખાય છે:

અમે ક્લાઉડમાં શું તપાસવા માંગીએ છીએ તે છે:

• ડેટાબેસેસ
• કીક્લોક
• સૂક્ષ્મ સેવાઓ

અમારી બધી ક્લાઉડ સેવાઓ કુબરનેટ્સમાં સ્થિત હોવાથી, તેના રાજ્ય વિશે માહિતી એકત્રિત કરવી સરસ રહેશે.

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

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

કુબરનેટ્સમાં પોડ્સને ટ્રૅક કરવાની બે રીતો છે: ડેમનસેટ અને સાઇડકાર.
બંને પદ્ધતિઓ વિગતવાર વર્ણવેલ છે આ બ્લોગ પોસ્ટમાં.

અમે ટેલિગ્રાફ સાઇડકારનો ઉપયોગ કર્યો અને મેટ્રિક્સ ઉપરાંત, પોડ લોગ એકત્રિત કર્યા.

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

મોનીટરીંગ મોનીટરીંગ???

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

જો કે ટેલિગ્રાફ તેના પોતાના મેટ્રિક્સ સરળતાથી મોકલી શકે છે અથવા તે જ ઈન્ફ્લક્સ પર અથવા બીજે ક્યાંક મોકલવા માટે InfluxDB ડેટાબેઝમાંથી મેટ્રિક્સ એકત્રિત કરી શકે છે.

તારણો

પાયલોટના પરિણામો પરથી અમે કયા તારણો કાઢ્યા?

તમે મોનિટરિંગ કેવી રીતે કરી શકો છો?

સૌ પ્રથમ, TICK સ્ટેક અમારી અપેક્ષાઓને પૂર્ણપણે પૂર્ણ કરે છે અને અમે શરૂઆતમાં જે અપેક્ષા રાખી હતી તેના કરતાં અમને વધુ તકો આપી.

અમને જરૂરી તમામ કાર્યક્ષમતા હાજર હતી. અમે તેની સાથે જે કર્યું તે બધું સમસ્યા વિના કામ કર્યું.

ઉત્પાદકતા

મફત સંસ્કરણમાં TICK સ્ટેકની મુખ્ય સમસ્યા સ્કેલિંગ ક્ષમતાઓનો અભાવ છે. આ અમારા માટે કોઈ સમસ્યા ન હતી.

અમે ચોક્કસ લોડ ડેટા/આંકડા એકત્રિત કર્યા નથી, પરંતુ અમે એક સમયે લગભગ 30 સ્કૂટરમાંથી ડેટા એકત્રિત કર્યો છે.

તેમાંથી દરેકે ત્રણ ડઝનથી વધુ મેટ્રિક્સ એકત્રિત કર્યા. તે જ સમયે, ઉપકરણોમાંથી લોગ એકત્રિત કરવામાં આવ્યા હતા. દર 10 સેકન્ડે ડેટા સંગ્રહ અને મોકલવાનું થયું.

એ નોંધવું અગત્યનું છે કે પાયલોટના દોઢ અઠવાડિયા પછી, જ્યારે મોટાભાગની "બાળપણની સમસ્યાઓ" સુધારાઈ ગઈ હતી અને સૌથી મહત્વપૂર્ણ સમસ્યાઓ પહેલાથી જ ઉકેલાઈ ગઈ હતી, ત્યારે અમારે સર્વર પર ડેટા મોકલવાની આવર્તન ઘટાડવી પડી હતી. 30 સેકન્ડ. આ જરૂરી બન્યું કારણ કે અમારા LTE SIM કાર્ડ્સ પરનો ટ્રાફિક ઝડપથી અદૃશ્ય થવા લાગ્યો.

મોટાભાગનો ટ્રાફિક લોગ દ્વારા વપરાતો હતો; મેટ્રિક્સ પોતે, 10-સેકન્ડના અંતરાલ સાથે પણ, વ્યવહારીક રીતે તેનો બગાડ કરતા નથી.

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

કેટલાક કિસ્સાઓમાં, જો લોગ્સ જોવું હજુ પણ જરૂરી હતું, તો અમે ફક્ત વાયરગાર્ડ દ્વારા VPN દ્વારા કનેક્ટ કર્યું.

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

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

TICK - નાનાથી મધ્યમ પ્રોજેક્ટ માટે આદર્શ

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

જો તમારી પાસે હજારો પોડ્સ અથવા સેંકડો મશીનો ન હોય, તો એક InfluxDB ઉદાહરણ પણ લોડને બરાબર હેન્ડલ કરશે.

કેટલાક કિસ્સાઓમાં, તમે આદિમ ઉચ્ચ ઉપલબ્ધતા ઉકેલ તરીકે ઇન્ફ્લક્સ રિલેથી સંતુષ્ટ થઈ શકો છો.

અને, અલબત્ત, તમને "વર્ટિકલ" સ્કેલિંગ સેટ કરવાથી અને વિવિધ પ્રકારના મેટ્રિક્સ માટે અલગ-અલગ સર્વર્સ ફાળવવાથી કોઈ રોકતું નથી.

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

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

આ કિસ્સામાં, આજે, હું વિક્ટોરિયા મેટ્રિક્સ અને લોકીનો ઉપયોગ કરીને લૉગ્સ દ્વારા મેટ્રિક્સ એકત્રિત કરવા તરફ જોવાની ભલામણ કરીશ.

સાચું, હું ફરીથી એક આરક્ષણ કરીશ કે લોકી/ગ્રાફના તૈયાર TICK કરતાં ઘણી ઓછી અનુકૂળ છે (તેમની વધુ વૈવિધ્યતાને કારણે), પરંતુ તે મફત છે.

મહત્વપૂર્ણ: અહીં વર્ણવેલ તમામ માહિતી આવૃત્તિ ઇન્ફ્લક્સ 1.8 માટે સુસંગત છે, અત્યારે ઇન્ફ્લક્સ 2.0 રિલીઝ થવાનું છે.

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

આ કાર્યક્ષમતા Influx 2.0 માં પણ દેખાશે, પરંતુ અમે કોઈ સમયમર્યાદા શોધી શક્યા નથી, અંદાજિત પણ.

IoT પ્લેટફોર્મ કેવી રીતે ન બનાવવું (હવે)

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

જો કે, તાજેતરમાં તે બીટા વર્ઝનમાં ઉપલબ્ધ છે ઓપનબાલેના - તે અફસોસની વાત છે કે જ્યારે અમે પ્રોજેક્ટ બનાવવાનું શરૂ કર્યું ત્યારે તે ત્યાં ન હતી.

અમે અંતિમ પરિણામ અને Ansible + TICK + WireGuard પર આધારિત પ્લેટફોર્મથી સંપૂર્ણપણે સંતુષ્ટ છીએ જે અમે જાતે એસેમ્બલ કર્યું છે. પરંતુ આજે, હું તમારું પોતાનું IoT પ્લેટફોર્મ જાતે બનાવવાનો પ્રયાસ કરતા પહેલા બલેનાને નજીકથી જોવાની ભલામણ કરીશ.

કારણ કે આખરે તે અમે જે કર્યું તેમાંથી મોટા ભાગનું કરી શકે છે, અને OpenBalena મફત અને ઓપન સોર્સ છે.

તે પહેલાથી જ જાણે છે કે કેવી રીતે માત્ર અપડેટ્સ જ મોકલવા નહીં, પણ VPN પણ પહેલેથી જ બિલ્ટ ઇન છે અને IoT પર્યાવરણમાં ઉપયોગ માટે તૈયાર છે.

અને તાજેતરમાં જ, તેઓએ તેમની રજૂઆત પણ કરી હાર્ડવેર, જે સરળતાથી તેમના ઇકોસિસ્ટમ સાથે જોડાય છે.

અરે, ગુમ થયેલા સ્કૂટરનું શું?

તેથી સ્કૂટર, "રાલ્ફ", કોઈ નિશાન વગર ગાયબ થઈ ગયું.

અમે તરત જ InfluxDB ના GPS મેટ્રિક્સ ડેટા સાથે અમારી "એડમિન પેનલ" માં નકશા જોવા દોડ્યા.

મોનિટરિંગ ડેટા માટે આભાર, અમે સરળતાથી નક્કી કર્યું કે સ્કૂટર છેલ્લા દિવસે 21:00 ની આસપાસ પાર્કિંગની જગ્યામાંથી બહાર નીકળી ગયું હતું, લગભગ અડધો કલાક કેટલાક વિસ્તારમાં ચાલ્યું હતું અને કેટલાક જર્મન ઘરની બાજુમાં સવારે 5 વાગ્યા સુધી પાર્ક કરવામાં આવ્યું હતું.

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

જો કે, ઘરના માલિકને પણ આનાથી આશ્ચર્ય થયું હતું, કારણ કે તે ગઈકાલે રાત્રે ઓફિસેથી ઘરે આ સ્કૂટર પર સવાર થઈ ગયો હતો.

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

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

સોર્સ: www.habr.com