காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

ஒரு வருடத்திற்கு முன்பு நாங்கள் ஒரு விளம்பரத் திட்டத்தின் பைலட் பதிப்பை அறிமுகப்படுத்தினோம் மின்சார ஸ்கூட்டர்களின் பரவலாக்கப்பட்ட வாடகை.

ஆரம்பத்தில், இந்த திட்டம் ரோட்-டு-பார்சிலோனா என்று அழைக்கப்பட்டது, பின்னர் அது ரோட்-டு-பெர்லின் ஆனது (எனவே ஸ்கிரீன்ஷாட்களில் R2B), இறுதியில் இது xRide என்று அழைக்கப்பட்டது.

திட்டத்தின் முக்கிய யோசனை இதுதான்: மையப்படுத்தப்பட்ட கார் அல்லது ஸ்கூட்டர் வாடகை சேவைக்கு பதிலாக (நாங்கள் ஸ்கூட்டர்கள் அல்லது மின்சார மோட்டார் சைக்கிள்களைப் பற்றி பேசுகிறோம், கிக்ஸ்கூட்டர்கள் / ஸ்கூட்டர்கள் அல்ல) பரவலாக்கப்பட்ட வாடகைக்கு ஒரு தளத்தை உருவாக்க விரும்பினோம். நாங்கள் சந்தித்த சிரமங்களைப் பற்றி முன்பே எழுதியது.

ஆரம்பத்தில், இந்த திட்டம் கார்களில் கவனம் செலுத்தியது, ஆனால் காலக்கெடு, உற்பத்தியாளர்களுடனான மிக நீண்ட தகவல்தொடர்பு மற்றும் அதிக எண்ணிக்கையிலான பாதுகாப்பு கட்டுப்பாடுகள் காரணமாக, மின்சார ஸ்கூட்டர்கள் விமானிக்கு தேர்ந்தெடுக்கப்பட்டன.

பயனர் தொலைபேசியில் iOS அல்லது Android பயன்பாட்டை நிறுவி, அவர் விரும்பிய ஸ்கூட்டரை அணுகினார், அதன் பிறகு தொலைபேசியும் ஸ்கூட்டரும் ஒரு பியர்-டு-பியர் இணைப்பை ஏற்படுத்தியது, ETH பரிமாற்றம் செய்யப்பட்டது மற்றும் பயனர் ஸ்கூட்டரை இயக்குவதன் மூலம் சவாரியைத் தொடங்கலாம். தொலைபேசி. பயணத்தின் முடிவில், தொலைபேசியில் உள்ள பயனரின் பணப்பையிலிருந்து Ethereum ஐப் பயன்படுத்தி பயணத்திற்கு பணம் செலுத்தவும் முடியும்.

ஸ்கூட்டர்களுக்கு கூடுதலாக, பயனர் பயன்பாட்டில் "ஸ்மார்ட் சார்ஜர்களை" பார்த்தார், அதைப் பார்வையிடுவதன் மூலம் தற்போதைய பேட்டரி குறைவாக இருந்தால் பயனர் அதை மாற்றலாம்.

இது பொதுவாக எங்கள் பைலட் எப்படி இருந்தது, கடந்த ஆண்டு செப்டம்பரில் இரண்டு ஜெர்மன் நகரங்களில் தொடங்கப்பட்டது: பான் மற்றும் பெர்லின்.

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

பின்னர், ஒரு நாள், பானில், அதிகாலையில், எங்கள் ஆதரவுக் குழு (ஸ்கூட்டர்களை வேலை செய்யும் வரிசையில் பராமரிக்க தளத்தில் அமைந்துள்ளது) எச்சரித்தது: ஸ்கூட்டர்களில் ஒன்று ஒரு தடயமும் இல்லாமல் காணாமல் போனது.

அதைக் கண்டுபிடித்து திருப்பித் தருவது எப்படி?

இந்த கட்டுரையில் நான் இதைப் பற்றி பேசுவேன், ஆனால் முதலில் - எங்கள் சொந்த IoT தளத்தை நாங்கள் எவ்வாறு உருவாக்கினோம் மற்றும் அதை எவ்வாறு கண்காணித்தோம் என்பது பற்றி.

என்ன, ஏன் கண்காணிக்க வேண்டும்: ஸ்கூட்டர்கள், உள்கட்டமைப்பு, சார்ஜிங் நிலையங்கள்?

எனவே, எங்கள் திட்டத்தில் எதைக் கண்காணிக்க விரும்புகிறோம்?

முதலாவதாக, இவை ஸ்கூட்டர்கள் - மின்சார ஸ்கூட்டர்கள் மிகவும் விலை உயர்ந்தவை, போதுமான அளவு தயாராக இல்லாமல் அத்தகைய திட்டத்தை நீங்கள் தொடங்க முடியாது; முடிந்தால், ஸ்கூட்டர்களைப் பற்றி முடிந்தவரை தகவல்களை சேகரிக்க வேண்டும்: அவற்றின் இருப்பிடம், கட்டண நிலை , முதலியன

கூடுதலாக, எங்கள் சொந்த தகவல் தொழில்நுட்ப உள்கட்டமைப்பின் நிலையை கண்காணிக்க விரும்புகிறேன் - தரவுத்தளங்கள், சேவைகள் மற்றும் அவை வேலை செய்ய வேண்டிய அனைத்தும். "ஸ்மார்ட் சார்ஜர்கள்" செயலிழந்தால் அல்லது முழு பேட்டரிகள் தீர்ந்துவிட்டால், அவற்றின் நிலையை கண்காணிக்கவும் அவசியம்.

ஸ்கூட்டர்கள்

எங்கள் ஸ்கூட்டர்கள் என்ன, அவற்றைப் பற்றி நாம் என்ன தெரிந்து கொள்ள விரும்புகிறோம்?

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

முதல் மற்றும் மிக முக்கியமான விஷயம் ஜி.பி.எஸ் ஆயத்தொலைவுகள் ஆகும், ஏனெனில் அவர்களுக்கு நன்றி அவர்கள் எங்கு இருக்கிறார்கள், எங்கு நகர்கிறார்கள் என்பதை நாம் புரிந்து கொள்ள முடியும்.

அடுத்தது பேட்டரி சார்ஜ் ஆகும், இதற்கு நன்றி ஸ்கூட்டர்களின் சார்ஜிங் முடிவடைகிறது என்பதைத் தீர்மானித்து ஒரு ஜூஸரை அனுப்பலாம் அல்லது குறைந்தபட்சம் பயனரை எச்சரிக்கலாம்.

நிச்சயமாக, எங்கள் வன்பொருள் கூறுகளில் என்ன நடக்கிறது என்பதைச் சரிபார்க்க வேண்டியது அவசியம்:

  • புளூடூத் வேலை செய்யுமா?
  • ஜிபிஎஸ் தொகுதி தானே வேலை செய்கிறது?
    • GPS ஆனது தவறான ஆயங்களை அனுப்புவது மற்றும் சிக்கிக்கொள்ளலாம் என்பதில் எங்களுக்கு ஒரு சிக்கல் இருந்தது, மேலும் ஸ்கூட்டரில் கூடுதல் சோதனைகள் மூலம் மட்டுமே இதை தீர்மானிக்க முடியும்,
      மேலும் சிக்கலைத் தீர்க்க விரைவில் ஆதரவைத் தெரிவிக்கவும்

கடைசியாக: மென்பொருளின் சோதனைகள், OS மற்றும் செயலி, நெட்வொர்க் மற்றும் வட்டு சுமை ஆகியவற்றில் தொடங்கி, எங்களுக்கு மிகவும் குறிப்பிட்ட எங்கள் சொந்த தொகுதிகளின் சரிபார்ப்புகளுடன் முடிவடைகிறது (ஜோலோகாம், திறவுகோல்).

வன்பொருள்

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

எங்கள் "இரும்பு" பகுதி என்ன?

மிகக் குறுகிய கால அவகாசம் மற்றும் விரைவான முன்மாதிரியின் தேவை ஆகியவற்றைக் கருத்தில் கொண்டு, கூறுகளை செயல்படுத்துவதற்கும் தேர்ந்தெடுப்பதற்கும் எளிதான விருப்பத்தைத் தேர்ந்தெடுத்தோம் - ராஸ்பெர்ரி பை.
Rpi ஐத் தவிர, எங்களிடம் தனிப்பயன் பலகை இருந்தது (இறுதித் தீர்வின் அசெம்பிளி செயல்முறையை விரைவுபடுத்துவதற்காக நாமே உருவாக்கி சீனாவிடம் இருந்து ஆர்டர் செய்தோம்) மற்றும் ஒரு ரிலே (ஸ்கூட்டரை ஆன்/ஆஃப் செய்ய) ஒரு பேட்டரி சார்ஜ் ரீடர், ஒரு மோடம், ஆண்டெனாக்கள். இவை அனைத்தும் ஒரு சிறப்பு "xRide பெட்டியில்" சுருக்கமாக தொகுக்கப்பட்டன.

முழு பெட்டியும் கூடுதல் பவர் பேங்க் மூலம் இயக்கப்பட்டது என்பதையும் கவனத்தில் கொள்ள வேண்டும், இது ஸ்கூட்டரின் பிரதான பேட்டரி மூலம் இயக்கப்படுகிறது.

பற்றவைப்பு விசையை “ஆஃப்” நிலைக்கு மாற்றிய உடனேயே பிரதான பேட்டரி அணைக்கப்பட்டதால், பயணத்தின் முடிவில் கூட கண்காணிப்பைப் பயன்படுத்தவும் ஸ்கூட்டரை இயக்கவும் இது சாத்தியமாக்கியது.

டோக்கரா? எளிய லினக்ஸ்? மற்றும் வரிசைப்படுத்தல்

கண்காணிப்புக்குத் திரும்புவோம், எனவே ராஸ்பெர்ரி - நம்மிடம் என்ன இருக்கிறது?

இயற்பியல் சாதனங்களுக்கு கூறுகளை வரிசைப்படுத்துதல், புதுப்பித்தல் மற்றும் வழங்குதல் ஆகியவற்றின் செயல்முறையை விரைவுபடுத்த நாங்கள் பயன்படுத்த விரும்பிய முதல் விஷயங்களில் ஒன்று டோக்கர்.

துரதிர்ஷ்டவசமாக, RPi இல் டோக்கர் வேலை செய்தாலும், குறிப்பாக மின் நுகர்வு அடிப்படையில், அதிக செலவைக் கொண்டுள்ளது என்பது விரைவில் தெளிவாகியது.

"நேட்டிவ்" OS ஐப் பயன்படுத்தும் வித்தியாசம், அவ்வளவு வலுவாக இல்லாவிட்டாலும், மிக விரைவாக சார்ஜ் இழக்கும் சாத்தியக்கூறு குறித்து எச்சரிக்கையாக இருக்க எங்களுக்கு இன்னும் போதுமானதாக இருந்தது.

இரண்டாவது காரணம், Node.js (sic!) இல் உள்ள எங்கள் கூட்டாளர் நூலகங்களில் ஒன்றாகும் - இது Go/C/C++ இல் எழுதப்படாத கணினியின் ஒரே கூறு ஆகும்.

நூலகத்தின் ஆசிரியர்களுக்கு "சொந்த" மொழிகள் எதிலும் வேலை செய்யும் பதிப்பை வழங்க நேரம் இல்லை.

குறைந்த செயல்திறன் கொண்ட சாதனங்களுக்கு முனை மிகவும் நேர்த்தியான தீர்வாக இல்லை என்பது மட்டுமல்லாமல், நூலகமே மிகவும் வள-பசியுடன் இருந்தது.

நாங்கள் விரும்பினாலும், டோக்கரைப் பயன்படுத்துவது எங்களுக்கு மிகவும் அதிகமாக இருக்கும் என்பதை நாங்கள் உணர்ந்தோம். சொந்த OS க்கு ஆதரவாக தேர்வு செய்யப்பட்டது மற்றும் அதன் கீழ் நேரடியாக வேலை செய்கிறது.

OS

இதன் விளைவாக, நாங்கள் மீண்டும், OS ஆக எளிமையான விருப்பத்தைத் தேர்ந்தெடுத்து, ராஸ்பியனைப் பயன்படுத்தினோம் (பைக்கான டெபியன் உருவாக்கம்).

எங்களின் அனைத்து மென்பொருட்களையும் Goவில் எழுதுகிறோம், எனவே எங்கள் கணினியில் உள்ள முக்கிய வன்பொருள் முகவர் தொகுதியையும் Goவில் எழுதினோம்.

ஜி.பி.எஸ், புளூடூத், சார்ஜ் படிப்பது, ஸ்கூட்டரை ஆன் செய்தல் போன்றவற்றுடன் வேலை செய்வதற்கு அவர்தான் பொறுப்பு.

வரிசைப்படுத்த

சாதனங்களுக்கு (OTA) புதுப்பிப்புகளை வழங்குவதற்கான ஒரு பொறிமுறையை செயல்படுத்த வேண்டியதன் அவசியத்தைப் பற்றிய கேள்வி உடனடியாக எழுந்தது - இரண்டுமே எங்கள் முகவர்/பயன்பாட்டிற்கான புதுப்பிப்புகள் மற்றும் OS/Firmwareக்கான புதுப்பிப்புகள் (ஏஜென்ட்டின் புதிய பதிப்புகளுக்கு கர்னலில் புதுப்பிப்புகள் தேவைப்படலாம். அல்லது கணினி கூறுகள், நூலகங்கள் போன்றவை) .

சந்தையின் நீண்ட பகுப்பாய்விற்குப் பிறகு, சாதனத்திற்கு புதுப்பிப்புகளை வழங்குவதற்கு நிறைய தீர்வுகள் உள்ளன.

swupd/SWUpdate/OSTree போன்ற ஒப்பீட்டளவில் எளிமையான, பெரும்பாலும் புதுப்பித்தல்/இரட்டை-பூட் சார்ந்த பயன்பாடுகள் முதல் மெண்டர் மற்றும் பலேனா போன்ற முழு அளவிலான இயங்குதளங்கள் வரை.

முதலாவதாக, இறுதி முதல் இறுதி தீர்வுகளில் நாங்கள் ஆர்வமாக உள்ளோம் என்று முடிவு செய்தோம், எனவே தேர்வு உடனடியாக தளங்களில் விழுந்தது.

மிகவும் பலேனா உண்மையில் அதன் balenaEngine இன் உள்ளே அதே டோக்கரைப் பயன்படுத்துவதால் அது விலக்கப்பட்டது.

ஆனால் இது இருந்தபோதிலும், நாங்கள் தொடர்ந்து அவர்களின் தயாரிப்பைப் பயன்படுத்துகிறோம் என்பதை நான் கவனிக்கிறேன் பலேனா எட்சர் SD கார்டுகளில் ஃபிளாஷ் ஃபார்ம்வேருக்கு - இதற்கான எளிய மற்றும் மிகவும் வசதியான பயன்பாடு.

எனவே, இறுதியில் தேர்வு விழுந்தது மெண்டர். மெண்டர் என்பது ஃபார்ம்வேரை அசெம்பிளிங், டெலிவரி மற்றும் இன்ஸ்டால் செய்வதற்கான முழுமையான தளமாகும்.

ஒட்டுமொத்த பிளாட்ஃபார்ம் அழகாக இருக்கிறது, ஆனால் மெண்டர் பில்டரைப் பயன்படுத்தி எங்கள் ஃபார்ம்வேரின் சரியான பதிப்பை உருவாக்க எங்களுக்கு ஒன்றரை வாரங்கள் ஆனது.
அதன் பயன்பாட்டின் நுணுக்கங்களில் நாம் எவ்வளவு அதிகமாக மூழ்கிவிட்டோமோ, அதை முழுமையாகப் பயன்படுத்துவதற்கு நம்மிடம் இருந்ததை விட அதிக நேரம் தேவைப்படும் என்பது தெளிவாகியது.

அடடா, எங்களின் இறுக்கமான காலக்கெடுவால், மெண்டரின் பயன்பாட்டைக் கைவிட்டு, இன்னும் எளிமையான ஒன்றைத் தேர்ந்தெடுக்க வேண்டிய கட்டாயத்தில் உள்ளோம்.

Ansible

எங்கள் சூழ்நிலையில் எளிமையான தீர்வு அன்சிபிளைப் பயன்படுத்துவதாகும். தொடங்குவதற்கு ஓரிரு விளையாட்டுப் புத்தகங்கள் போதும்.

அவற்றின் சாராம்சம் என்னவென்றால், நாங்கள் ஹோஸ்டிலிருந்து (CI சேவையகம்) ssh வழியாக எங்கள் ராஸ்பெர்ரிகளுடன் இணைக்கப்பட்டு அவர்களுக்கு புதுப்பிப்புகளை விநியோகித்தோம்.

ஆரம்பத்தில், எல்லாம் எளிமையானது - நீங்கள் சாதனங்களுடன் ஒரே நெட்வொர்க்கில் இருக்க வேண்டும், வைஃபை வழியாக ஊற்றுவது.

அலுவலகத்தில் ஒரே நெட்வொர்க்குடன் இணைக்கப்பட்ட ஒரு டஜன் சோதனை ராஸ்பெர்ரிகள் இருந்தன, ஒவ்வொரு சாதனமும் அன்சிபிள் இன்வெண்டரியில் குறிப்பிடப்பட்ட நிலையான ஐபி முகவரியைக் கொண்டிருந்தது.

எங்கள் கண்காணிப்பு முகவரை இறுதி சாதனங்களுக்கு வழங்கியது அன்சிபிள்

3G / LTE ஆனது

துரதிர்ஷ்டவசமாக, எங்களிடம் உண்மையான ஸ்கூட்டர்களைப் பெறுவதற்கு முன்பு, அன்சிபிலுக்கான இந்த பயன்பாட்டு வழக்கு வளர்ச்சி பயன்முறையில் மட்டுமே வேலை செய்ய முடியும்.

ஏனெனில் ஸ்கூட்டர்கள், நீங்கள் புரிந்து கொண்டபடி, ஒரு வைஃபை ரூட்டருடன் இணைக்கப்பட்டிருக்காது, நெட்வொர்க்கில் தொடர்ந்து புதுப்பிப்புகளுக்காக காத்திருக்கிறது.

உண்மையில், ஸ்கூட்டர்கள் மொபைல் 3G/LTE தவிர வேறு எந்த இணைப்பையும் கொண்டிருக்க முடியாது (அப்போது கூட எல்லா நேரத்திலும் இல்லை).

இது உடனடியாக குறைந்த இணைப்பு வேகம் மற்றும் நிலையற்ற தொடர்பு போன்ற பல சிக்கல்களையும் வரம்புகளையும் விதிக்கிறது.

ஆனால் மிக முக்கியமான விஷயம் என்னவென்றால், 3G/LTE நெட்வொர்க்கில், நெட்வொர்க்கிற்கு ஒதுக்கப்பட்ட நிலையான ஐபியை நாம் வெறுமனே நம்ப முடியாது.

இது சில சிம் கார்டு வழங்குநர்களால் ஓரளவு தீர்க்கப்படுகிறது; நிலையான IP முகவரிகளுடன் IoT சாதனங்களுக்காக வடிவமைக்கப்பட்ட சிறப்பு சிம் கார்டுகள் கூட உள்ளன. ஆனால் அத்தகைய சிம் கார்டுகளுக்கான அணுகல் எங்களிடம் இல்லை மற்றும் ஐபி முகவரிகளைப் பயன்படுத்த முடியவில்லை.

நிச்சயமாக, கான்சல் போன்ற எங்காவது சேவை கண்டுபிடிப்பு அல்லது ஐபி முகவரிகளை பதிவு செய்வதற்கான யோசனைகள் இருந்தன, ஆனால் இதுபோன்ற யோசனைகளை நாங்கள் கைவிட வேண்டியிருந்தது, ஏனெனில் எங்கள் சோதனைகளில் ஐபி முகவரி அடிக்கடி மாறக்கூடும், இது பெரும் உறுதியற்ற தன்மைக்கு வழிவகுத்தது.

இந்த காரணத்திற்காக, அளவீடுகளை வழங்குவதற்கான மிகவும் வசதியான பயன்பாடானது இழுக்கும் மாதிரியைப் பயன்படுத்துவதில்லை, அங்கு தேவையான அளவீடுகளுக்கான சாதனங்களுக்குச் செல்வோம், ஆனால் சாதனத்திலிருந்து அளவீடுகளை நேரடியாக சேவையகத்திற்கு வழங்குகிறோம்.

மெ.த.பி.க்குள்ளேயே

இந்தச் சிக்கலுக்குத் தீர்வாக, விபிஎன்-ஐத் தேர்ந்தெடுத்தோம் - குறிப்பாக வயர்கார்ட்.

கணினியின் தொடக்கத்தில் வாடிக்கையாளர்கள் (ஸ்கூட்டர்கள்) VPN சேவையகத்துடன் இணைக்கப்பட்டு அவர்களுடன் இணைக்க முடிந்தது. புதுப்பிப்புகளை வழங்க இந்த சுரங்கப்பாதை பயன்படுத்தப்பட்டது.

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

கோட்பாட்டில், அதே சுரங்கப்பாதை கண்காணிப்புக்குப் பயன்படுத்தப்படலாம், ஆனால் அத்தகைய இணைப்பு எளிமையான உந்துதலை விட மிகவும் சிக்கலானது மற்றும் குறைந்த நம்பகத்தன்மை கொண்டது.

கிளவுட் ஆதாரங்கள்

கடைசியாக, எங்கள் கிளவுட் சேவைகள் மற்றும் தரவுத்தளங்களைக் கண்காணிப்பது அவசியம், ஏனெனில் நாங்கள் அவற்றிற்கு குபெர்னெட்ஸைப் பயன்படுத்துகிறோம், எனவே கிளஸ்டரில் கண்காணிப்பு முடிந்தவரை எளிமையானது. வெறுமனே, பயன்படுத்தி தலைமையில், வரிசைப்படுத்துதலுக்காக, பெரும்பாலான சந்தர்ப்பங்களில் இதைப் பயன்படுத்துகிறோம். மற்றும், நிச்சயமாக, கிளவுட் கண்காணிக்க நீங்கள் ஸ்கூட்டர்கள் தங்களை அதே தீர்வுகளை பயன்படுத்த வேண்டும்.

கொடுக்கப்பட்டது

அச்சச்சோ, நாங்கள் விளக்கத்தை வரிசைப்படுத்தியதாகத் தெரிகிறது, இறுதியில் நமக்குத் தேவையானவற்றைப் பட்டியலிடுவோம்:

  • ஒரு விரைவான தீர்வு, வளர்ச்சி செயல்முறையின் போது ஏற்கனவே கண்காணிப்பு அவசியம்
  • தொகுதி/அளவு - பல அளவீடுகள் தேவை
  • பதிவு சேகரிப்பு தேவை
  • நம்பகத்தன்மை - வெற்றியைத் தொடங்க தரவு முக்கியமானது
  • நீங்கள் இழுக்கும் மாதிரியைப் பயன்படுத்த முடியாது - உங்களுக்கு புஷ் தேவை
  • வன்பொருள் மட்டுமல்ல, மேகக்கணியும் நமக்கு ஒருங்கிணைந்த கண்காணிப்பு தேவை

இறுதிப் படம் இப்படித்தான் இருந்தது

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

அடுக்கு தேர்வு

எனவே, கண்காணிப்பு அடுக்கைத் தேர்ந்தெடுப்பதற்கான கேள்வியை நாங்கள் எதிர்கொண்டோம்.

முதலாவதாக, எங்களின் அனைத்துத் தேவைகளையும் ஒரே நேரத்தில் பூர்த்தி செய்யும், ஆனால் அதே நேரத்தில் எங்கள் தேவைகளுக்கு ஏற்ப அதன் பயன்பாட்டை மாற்றியமைக்கும் வகையில் மிகவும் முழுமையான ஆல் இன் ஒன் தீர்வை நாங்கள் தேடுகிறோம். இருப்பினும், வன்பொருள், கட்டிடக்கலை மற்றும் காலக்கெடு ஆகியவற்றால் எங்களுக்கு பல கட்டுப்பாடுகள் விதிக்கப்பட்டுள்ளன.

போன்ற முழு அளவிலான அமைப்புகளில் தொடங்கி பல்வேறு வகையான கண்காணிப்பு தீர்வுகள் உள்ளன Nagios, icinga அல்லது zabbix மற்றும் கடற்படை நிர்வாகத்திற்கான ஆயத்த தீர்வுகளுடன் முடிவடைகிறது.

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

ஆரம்பத்தில், பிந்தையது எங்களுக்கு ஒரு சிறந்த தீர்வாகத் தோன்றியது, ஆனால் சிலருக்கு முழு கண்காணிப்பு இல்லை, மற்றவர்களுக்கு இலவச பதிப்புகளின் திறன்கள் குறைவாகவே இருந்தன, மற்றவை எங்கள் "விருப்பங்களை" மறைக்கவில்லை அல்லது எங்கள் காட்சிகளுக்கு ஏற்றவாறு நெகிழ்வாக இல்லை. சில வெறுமனே காலாவதியானவை.

இதேபோன்ற பல தீர்வுகளை பகுப்பாய்வு செய்த பிறகு, இதேபோன்ற அடுக்கை நாமே அமைப்பது எளிதாகவும் வேகமாகவும் இருக்கும் என்ற முடிவுக்கு விரைவாக வந்தோம். ஆம், முற்றிலும் ஆயத்தமான ஃப்ளீட் மேனேஜ்மென்ட் பிளாட்ஃபார்மை பயன்படுத்துவதை விட இது சற்று சிக்கலானதாக இருக்கும், ஆனால் நாம் சமரசம் செய்ய வேண்டியதில்லை.

ஏறக்குறைய நிச்சயமாக, ஏராளமான தீர்வுகளில், எங்களுக்கு முற்றிலும் பொருந்தக்கூடிய ஒரு ஆயத்தமானது ஏற்கனவே உள்ளது, ஆனால் எங்கள் விஷயத்தில் ஒரு குறிப்பிட்ட அடுக்கை நாமே சேகரித்து அதை "நமக்காக" தனிப்பயனாக்குவது மிக வேகமாக இருந்தது. ஆயத்த தயாரிப்புகளை சோதிக்கிறது.

இவை அனைத்தையும் கொண்டு, நாங்கள் ஒரு முழு கண்காணிப்பு தளத்தையும் நாமே ஒன்றுசேர்க்க முயற்சிக்கவில்லை, ஆனால் மிகவும் செயல்பாட்டு "ஆயத்த" அடுக்குகளைத் தேடுகிறோம், அவற்றை நெகிழ்வாக உள்ளமைக்கும் திறனுடன் மட்டுமே.

(B)ELK?

உண்மையில் கருதப்பட்ட முதல் தீர்வு நன்கு அறியப்பட்ட ELK ஸ்டாக் ஆகும்.
உண்மையில், இது BELK என்று அழைக்கப்பட வேண்டும், ஏனெனில் இது அனைத்தும் பீட்ஸில் தொடங்குகிறது - https://www.elastic.co/what-is/elk-stack

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

நிச்சயமாக, ELK என்பது கண்காணிப்புத் துறையில் மிகவும் பிரபலமான மற்றும் சக்திவாய்ந்த தீர்வுகளில் ஒன்றாகும், மேலும் பதிவுகளை சேகரித்து செயலாக்குவதில் இன்னும் அதிகமாக உள்ளது.

பதிவுகளை சேகரிக்க ELK பயன்படும் என்றும், அத்துடன் Prometheus இலிருந்து பெறப்பட்ட அளவீடுகளின் நீண்ட கால சேமிப்புக்காகவும் நாங்கள் எண்ணினோம்.

காட்சிப்படுத்தலுக்கு நீங்கள் கிராஃபானைப் பயன்படுத்தலாம்.

உண்மையில், புதிய ELK ஸ்டாக் அளவீடுகளை சுயாதீனமாக சேகரிக்க முடியும் (மெட்ரிக்பீட்), மேலும் கிபானாவும் அவற்றைக் காண்பிக்க முடியும்.

இருப்பினும், ELK ஆரம்பத்தில் பதிவுகளிலிருந்து வளர்ந்தது மற்றும் இதுவரை அளவீடுகளின் செயல்பாடு பல தீவிர குறைபாடுகளைக் கொண்டுள்ளது:

  • ப்ரோமிதியஸை விட மெதுவானது
  • ப்ரோமிதியஸை விட மிகக் குறைவான இடங்களில் ஒருங்கிணைக்கிறது
  • அவர்களுக்கான விழிப்பூட்டல்களை அமைப்பது கடினம்
  • அளவீடுகள் அதிக இடத்தை எடுத்துக்கொள்கின்றன
  • கிபானில் அளவீடுகளுடன் டேஷ்போர்டுகளை அமைப்பது கிராஃபானை விட மிகவும் சிக்கலானது

பொதுவாக, ELK இல் உள்ள அளவீடுகள் கனமானவை மற்றும் பிற தீர்வுகளைப் போல இன்னும் வசதியாக இல்லை, அவற்றில் இப்போது ப்ரோமிதியஸை விட அதிகமாக உள்ளன: TSDB, விக்டோரியா மெட்ரிக்ஸ், கோர்டெக்ஸ் போன்றவை. நிச்சயமாக, நான் உடனடியாக ஒரு முழுமையான ஆல் இன் ஒன் தீர்வைப் பெற விரும்புகிறேன், ஆனால் மெட்ரிக்பீட் விஷயத்தில் பல சமரசங்கள் இருந்தன.

மேலும் ELK அடுக்கில் பல கடினமான தருணங்கள் உள்ளன:

  • நீங்கள் ஒரு பெரிய அளவிலான தரவைச் சேகரித்தால், அது கனமானது, சில நேரங்களில் மிகவும் கனமானது
  • நீங்கள் அதை "சமைப்பது எப்படி" என்று தெரிந்து கொள்ள வேண்டும் - நீங்கள் அதை அளவிட வேண்டும், ஆனால் இதைச் செய்வது சாதாரணமானது அல்ல.
  • அகற்றப்பட்ட இலவச பதிப்பு - இலவச பதிப்பில் சாதாரண எச்சரிக்கை இல்லை, தேர்வு நேரத்தில் அங்கீகாரம் இல்லை

சமீபத்தில் கடைசி புள்ளி சிறப்பாகவும் கூடுதலாகவும் மாறிவிட்டது என்று நான் சொல்ல வேண்டும் திறந்த மூல எக்ஸ்-பேக்கில் வெளியீடு (அங்கீகாரம் உட்பட) விலை மாதிரியே மாறத் தொடங்கியது.

ஆனால் இந்த தீர்வை நாங்கள் பயன்படுத்தப் போகும் நேரத்தில், எந்த எச்சரிக்கையும் இல்லை.
ஒருவேளை நாம் ElastAlert அல்லது பிற சமூக தீர்வுகளைப் பயன்படுத்தி ஏதாவது ஒன்றை உருவாக்க முயற்சித்திருக்கலாம், ஆனால் நாங்கள் இன்னும் பிற மாற்றுகளைக் கருத்தில் கொள்ள முடிவு செய்தோம்.

லோகி - கிராபனா - ப்ரோமிதியஸ்

இந்த நேரத்தில், ஒரு சிறந்த தீர்வாக, ப்ரோமிதியஸை ஒரு அளவீடு வழங்குநராக, பதிவுகளுக்கான லோகியை அடிப்படையாகக் கொண்ட ஒரு கண்காணிப்பு அடுக்கை உருவாக்கலாம், மேலும் நீங்கள் அதே கிராஃபானாவைப் பயன்படுத்தலாம்.

துரதிர்ஷ்டவசமாக, திட்டத்தின் விற்பனை பைலட் தொடங்கும் நேரத்தில் (செப்டம்பர்-அக்டோபர் 19), லோகி இன்னும் பீட்டா பதிப்பில் 0.3-0.4 இல் இருந்தார், மேலும் வளர்ச்சியின் தொடக்கத்தில் அதை உற்பத்தித் தீர்வாகக் கருத முடியாது. அனைத்தும்.

தீவிரமான திட்டங்களில் லோகியைப் பயன்படுத்துவதில் எனக்கு இன்னும் அனுபவம் இல்லை, ஆனால் க்யூபெர்னெட்டஸில் உள்ள வெற்று-உலோகம் மற்றும் காய்கள் இரண்டிற்கும் Promtail (பதிவுகளைச் சேகரிக்கும் முகவர்) சிறப்பாகச் செயல்படும் என்று என்னால் சொல்ல முடியும்.

டிக்

ELK ஸ்டேக்கிற்கு மிகவும் தகுதியான (ஒரே?) முழு அம்சமான மாற்றாக இப்போது TICK ஸ்டேக் என்று மட்டுமே அழைக்க முடியும் - Telegraf, InfluxDB, Chronograf, Kapacitor.

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

கீழே உள்ள அனைத்து கூறுகளையும் இன்னும் விரிவாக விவரிக்கிறேன், ஆனால் பொதுவான யோசனை இதுதான்:

  • டெலிகிராஃப் - அளவீடுகளை சேகரிப்பதற்கான முகவர்
  • InfluxDB - அளவீடுகள் தரவுத்தளம்
  • கபாசிட்டர் - விழிப்பூட்டலுக்கான நிகழ்நேர அளவீடுகள் செயலி
  • க்ரோனோகிராஃப் - காட்சிப்படுத்தலுக்கான வலை குழு

InfluxDB, Kapacitor மற்றும் Chronograf ஆகியவற்றிற்கு நாங்கள் பயன்படுத்திய அதிகாரப்பூர்வ ஹெல்ம் விளக்கப்படங்கள் உள்ளன.

Influx 2.0 (beta) இன் சமீபத்திய பதிப்பில், Kapacitor மற்றும் Chronograf ஆகியவை InfluxDB இன் ஒரு பகுதியாக மாறிவிட்டன, இனி தனித்தனியாக இல்லை என்பதை கவனத்தில் கொள்ள வேண்டும்.

டெலிகிராஃப்

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

டெலிகிராஃப் ஒரு அரசு இயந்திரத்தில் அளவீடுகளை சேகரிப்பதற்கான மிக இலகுரக முகவர்.

அவர் எல்லாவற்றையும் பெரிய அளவில் கண்காணிக்க முடியும் Nginx செய்ய
சர்வர் Minecraft.

இது பல குளிர் நன்மைகளைக் கொண்டுள்ளது:

  • வேகமான மற்றும் இலகுரக (கோவில் எழுதப்பட்டது)
    • குறைந்த அளவு வளங்களை சாப்பிடுகிறது
  • முன்னிருப்பாக அளவீடுகளை அழுத்தவும்
  • தேவையான அனைத்து அளவீடுகளையும் சேகரிக்கிறது
    • எந்த அமைப்புகளும் இல்லாமல் கணினி அளவீடுகள்
    • சென்சார்களில் இருந்து தகவல் போன்ற வன்பொருள் அளவீடுகள்
    • உங்கள் சொந்த அளவீடுகளைச் சேர்ப்பது மிகவும் எளிதானது
  • பெட்டிக்கு வெளியே நிறைய செருகுநிரல்கள்
  • பதிவுகளை சேகரிக்கிறது

புஷ் அளவீடுகள் எங்களுக்கு அவசியமாக இருந்ததால், மற்ற எல்லா நன்மைகளும் இனிமையான சேர்த்தல்களை விட அதிகம்.

பதிவுகளை பதிவு செய்வதற்கு கூடுதல் பயன்பாடுகளை இணைக்க வேண்டிய அவசியமில்லை என்பதால், முகவரால் பதிவுகளை சேகரிப்பது மிகவும் வசதியானது.

நீங்கள் பயன்படுத்தினால், பதிவுகளுடன் பணிபுரிய மிகவும் வசதியான அனுபவத்தை Influx வழங்குகிறது இந்த syslog.

டெலிகிராஃப் பொதுவாக அளவீடுகளைச் சேகரிப்பதில் ஒரு சிறந்த முகவராகும், நீங்கள் மீதமுள்ள ICK அடுக்கைப் பயன்படுத்தாவிட்டாலும் கூட.

கிட்டத்தட்ட எங்கும் அளவீடுகளை எழுத முடியும் என்பதால், பலர் வசதிக்காக ELK மற்றும் பல்வேறு நேர-தொடர் தரவுத்தளங்களுடன் அதைக் கடக்கிறார்கள்.

InfluxDB

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

InfluxDB என்பது TICK அடுக்கின் முக்கிய மையமாகும், அதாவது அளவீடுகளுக்கான நேர-தொடர் தரவுத்தளமாகும்.
அளவீடுகளுக்கு கூடுதலாக, இன்ஃப்ளக்ஸ் பதிவுகளையும் சேமிக்க முடியும், இருப்பினும், சாராம்சத்தில், அதற்கான பதிவுகள் ஒரே அளவீடுகள் மட்டுமே, வழக்கமான எண் குறிகாட்டிகளுக்குப் பதிலாக, முக்கிய செயல்பாடு பதிவு உரையின் வரியால் மேற்கொள்ளப்படுகிறது.

InfluxDB ஆனது Goவில் எழுதப்பட்டுள்ளது மற்றும் எங்கள் (மிகவும் சக்தி வாய்ந்தது அல்ல) கிளஸ்டரில் உள்ள ELK உடன் ஒப்பிடும்போது மிக வேகமாக இயங்குவதாகத் தெரிகிறது.

Influx இன் சிறந்த நன்மைகளில் ஒன்று, தரவு வினவல்களுக்கு மிகவும் வசதியான மற்றும் பணக்கார API ஐயும் உள்ளடக்கியிருக்கும், அதை நாங்கள் மிகவும் தீவிரமாகப் பயன்படுத்தினோம்.

குறைபாடுகள் - $$$ அல்லது அளவிடுதல்?

டிக் ஸ்டேக்கில் நாம் கண்டறிந்த ஒரே ஒரு குறைபாடு உள்ளது - அது அன்பே. இன்னும் அதிகமாக.

கட்டணப் பதிப்பில் இலவசப் பதிப்பில் இல்லாதது என்ன?

எங்களால் புரிந்து கொள்ள முடிந்தவரை, டிக் ஸ்டேக்கின் கட்டணப் பதிப்பிற்கும் இலவசத்திற்கும் உள்ள ஒரே வித்தியாசம் அளவிடுதல் திறன்கள்.

அதாவது, அதிக அளவில் கிடைக்கும் இடத்தில் மட்டுமே நீங்கள் ஒரு கிளஸ்டரை உயர்த்த முடியும் நிறுவன பதிப்புகள்.

நீங்கள் முழு அளவிலான HA ஐ விரும்பினால், நீங்கள் பணம் செலுத்த வேண்டும் அல்லது சில ஊன்றுகோல்களைப் பயன்படுத்த வேண்டும். இரண்டு சமூக தீர்வுகள் உள்ளன - உதாரணமாக influxdb-ha ஒரு திறமையான தீர்வு போல் தெரிகிறது, ஆனால் அது உற்பத்திக்கு ஏற்றது அல்ல என்று எழுதப்பட்டுள்ளது
influx-spout - NATS மூலம் தரவு உந்தி ஒரு எளிய தீர்வு (அதையும் அளவிட வேண்டும், ஆனால் இதை தீர்க்க முடியும்).

இது ஒரு பரிதாபம், ஆனால் அவை இரண்டும் கைவிடப்பட்டதாகத் தெரிகிறது - புதிய கமிட்கள் எதுவும் இல்லை, சிக்கல் இன்ஃப்ளக்ஸ் 2.0 இன் புதிய பதிப்பின் விரைவில் எதிர்பார்க்கப்படும் வெளியீடு என்று நான் கருதுகிறேன், இதில் பல விஷயங்கள் வித்தியாசமாக இருக்கும் (இது பற்றி எந்த தகவலும் இல்லை. இன்னும் அதில் அளவிடுதல்).

அதிகாரப்பூர்வமாக ஒரு இலவச பதிப்பு உள்ளது ரிலே - உண்மையில், இது ஒரு பழமையான HA ஆகும், ஆனால் சமநிலைப்படுத்துவதன் மூலம் மட்டுமே,
எல்லா தரவும் சுமை சமநிலைக்கு பின்னால் உள்ள அனைத்து InfluxDB நிகழ்வுகளுக்கும் எழுதப்படும்.
அவரிடம் சில உள்ளது குறைபாடுகளை புள்ளிகளை மேலெழுதுவதில் சாத்தியமான சிக்கல்கள் மற்றும் முன்கூட்டியே அளவீடுகளுக்கான அடிப்படைகளை உருவாக்க வேண்டிய அவசியம் போன்றவை
(இது InfluxDB உடன் சாதாரண வேலையின் போது தானாகவே நிகழும்).

கூடுதலாக, பகிர்தல் ஆதரிக்கப்படவில்லை, இது உங்களுக்குத் தேவையில்லாத நகல் அளவீடுகளுக்கான (செயலாக்கம் மற்றும் சேமிப்பகம் இரண்டும்) கூடுதல் மேல்நிலையைக் குறிக்கிறது, ஆனால் அவற்றைப் பிரிக்க எந்த வழியும் இல்லை.

விக்டோரியா அளவீடுகள்?

இதன் விளைவாக, பணம் செலுத்திய அளவைத் தவிர மற்ற எல்லாவற்றிலும் TICK ஸ்டாக்கில் நாங்கள் முழுமையாக திருப்தி அடைந்திருந்தாலும், மீதமுள்ள T_CK கூறுகளை விட்டுவிட்டு, InfluxDB தரவுத்தளத்தை மாற்றக்கூடிய இலவச தீர்வுகள் ஏதேனும் உள்ளதா என்பதைப் பார்க்க முடிவு செய்தோம்.

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

நிறைய நேர-தொடர் தரவுத்தளங்கள் உள்ளன, ஆனால் மிகவும் நம்பிக்கைக்குரிய ஒன்று விக்டோரியா மெட்ரிக்ஸ், இது பல நன்மைகளைக் கொண்டுள்ளது:

  • குறைந்தபட்சம் முடிவுகளின்படி வேகமாகவும் எளிதாகவும் வரையறைகள்
  • ஒரு கிளஸ்டர் பதிப்பு உள்ளது, அதைப் பற்றி இப்போது நல்ல மதிப்புரைகள் கூட உள்ளன
    • அவளால் துண்டிக்க முடியும்
  • InfluxDB நெறிமுறையை ஆதரிக்கிறது

விக்டோரியாவை அடிப்படையாகக் கொண்ட முற்றிலும் தனிப்பயன் அடுக்கை உருவாக்க நாங்கள் விரும்பவில்லை, மேலும் முக்கிய நம்பிக்கை என்னவென்றால், InfluxDB க்கு மாற்றாக இதைப் பயன்படுத்தலாம்.

துரதிர்ஷ்டவசமாக, InfluxDB நெறிமுறை ஆதரிக்கப்பட்ட போதிலும், இது சாத்தியமில்லை, இது அளவீடுகளைப் பதிவுசெய்ய மட்டுமே வேலை செய்கிறது - Prometheus API மட்டுமே "வெளியே" கிடைக்கிறது, அதாவது அதில் க்ரோனோகிராஃப் அமைக்க முடியாது.

மேலும், அளவீடுகளுக்கு எண் மதிப்புகள் மட்டுமே ஆதரிக்கப்படுகின்றன (தனிப்பயன் அளவீடுகளுக்கு சரம் மதிப்புகளைப் பயன்படுத்தினோம் - மேலும் பிரிவில் நிர்வாக குழு).

வெளிப்படையாக, அதே காரணத்திற்காக, இன்ஃப்ளக்ஸ் போன்ற பதிவுகளை VM சேமிக்க முடியாது.

மேலும், உகந்த தீர்வைத் தேடும் நேரத்தில், விக்டோரியா மெட்ரிக்ஸ் இன்னும் பிரபலமாகவில்லை, ஆவணங்கள் மிகவும் சிறியதாக இருந்தது மற்றும் செயல்பாடு பலவீனமாக இருந்தது என்பதைக் கவனத்தில் கொள்ள வேண்டும்.
(கிளஸ்டர் பதிப்பு மற்றும் பகிர்வு பற்றிய விரிவான விளக்கம் எனக்கு நினைவில் இல்லை).

அடிப்படை தேர்வு

இதன் விளைவாக, பைலட்டிற்கு நாங்கள் இன்னும் ஒரு InfluxDB முனைக்கு நம்மை கட்டுப்படுத்திக்கொள்வோம் என்று முடிவு செய்யப்பட்டது.

இந்த தேர்வுக்கு பல முக்கிய காரணங்கள் இருந்தன:

  • டிக் ஸ்டேக்கின் முழு செயல்பாடும் எங்களுக்கு மிகவும் பிடித்திருந்தது
  • நாங்கள் ஏற்கனவே அதை வரிசைப்படுத்த முடிந்தது, அது நன்றாக வேலை செய்தது
  • காலக்கெடு முடிந்துவிட்டதால் மற்ற விருப்பங்களைச் சோதிக்க அதிக நேரம் இல்லை.
  • இவ்வளவு பெரிய சுமையை நாங்கள் எதிர்பார்க்கவில்லை

பைலட்டின் முதல் கட்டத்திற்கு எங்களிடம் அதிக ஸ்கூட்டர்கள் இல்லை, மேலும் வளர்ச்சியின் போது சோதனை செய்ததில் செயல்திறன் சிக்கல்கள் எதுவும் இல்லை.

எனவே, இந்த திட்டத்திற்கு அளவிடுதல் தேவையில்லாமல் ஒரு Influx node போதுமானதாக இருக்கும் என்று நாங்கள் முடிவு செய்தோம் (முடிவில் உள்ள முடிவுகளைப் பார்க்கவும்).

ஸ்டாக் மற்றும் பேஸ் - இப்போது TICK ஸ்டேக்கின் மீதமுள்ள கூறுகள் பற்றி முடிவு செய்துள்ளோம்.

கபாசிட்டர்

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

கபாசிட்டர் என்பது டிக் ஸ்டேக்கின் ஒரு பகுதியாகும், இது தரவுத்தளத்தில் நுழையும் அளவீடுகளை நிகழ்நேரத்தில் கண்காணிக்கும் மற்றும் விதிகளின் அடிப்படையில் பல்வேறு செயல்களைச் செய்யக்கூடிய ஒரு சேவையாகும்.

பொதுவாக, இது சாத்தியமான ஒழுங்கின்மை கண்காணிப்பு மற்றும் இயந்திர கற்றலுக்கான கருவியாக நிலைநிறுத்தப்பட்டுள்ளது (இந்த செயல்பாடுகளுக்கு தேவை இருப்பதாக எனக்குத் தெரியவில்லை), ஆனால் அதன் பயன்பாட்டின் மிகவும் பிரபலமான வழக்கு மிகவும் பொதுவானது - எச்சரிக்கை.

அறிவிப்புகளுக்காக இதைப் பயன்படுத்தினோம். ஒரு குறிப்பிட்ட ஸ்கூட்டர் ஆஃப்லைனில் செல்லும்போது ஸ்லாக் விழிப்பூட்டல்களை நாங்கள் அமைத்துள்ளோம், மேலும் இது ஸ்மார்ட் சார்ஜர்கள் மற்றும் முக்கியமான உள்கட்டமைப்பு கூறுகளுக்கும் செய்யப்பட்டது.

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

இது சிக்கல்களுக்கு விரைவாக பதிலளிப்பதை சாத்தியமாக்கியது, அத்துடன் எல்லாம் இயல்பு நிலைக்கு திரும்பியது என்ற அறிவிப்புகளைப் பெறுகிறது.

ஒரு எளிய எடுத்துக்காட்டு: எங்கள் “பெட்டியை” இயக்குவதற்கான கூடுதல் பேட்டரி செயலிழந்தது அல்லது சில காரணங்களால் சக்தி தீர்ந்துவிட்டது; புதிய ஒன்றை நிறுவுவதன் மூலம், சிறிது நேரத்திற்குப் பிறகு ஸ்கூட்டரின் செயல்பாடு மீட்டமைக்கப்பட்டது என்ற அறிவிப்பைப் பெறுவோம்.

இன்ஃப்ளக்ஸ் 2.0 கபாசிட்டர் டிபியின் ஒரு பகுதியாக மாறியது

கால வரைபடம்

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

கண்காணிப்புக்கான பல்வேறு UI தீர்வுகளை நான் பார்த்திருக்கிறேன், ஆனால் செயல்பாடு மற்றும் UX ஆகியவற்றின் அடிப்படையில், க்ரோனோகிராஃப் உடன் ஒப்பிட முடியாது என்று என்னால் கூற முடியும்.

டிக் ஸ்டேக்கை, கிராஃபானை இணைய இடைமுகமாகப் பயன்படுத்தத் தொடங்கினோம்.
அதன் செயல்பாட்டை நான் விவரிக்க மாட்டேன்; எதையும் அமைப்பதற்கான அதன் பரந்த சாத்தியக்கூறுகள் அனைவருக்கும் தெரியும்.

இருப்பினும், கிராஃபனா இன்னும் முற்றிலும் உலகளாவிய கருவியாக உள்ளது, அதே நேரத்தில் க்ரோனோகிராஃப் முக்கியமாக இன்ஃப்ளக்ஸ் பயன்படுத்த வடிவமைக்கப்பட்டுள்ளது.

நிச்சயமாக, இதற்கு நன்றி, க்ரோனோகிராஃப் மிகவும் புத்திசாலி அல்லது வசதியான செயல்பாட்டை வாங்க முடியும்.

க்ரோனோகிராஃப் உடன் பணிபுரிவதன் முக்கிய வசதி என்னவென்றால், எக்ஸ்ப்ளோர் மூலம் உங்கள் InfluxDB இன் உட்புறங்களை நீங்கள் பார்க்கலாம்.

கிராஃபானா கிட்டத்தட்ட ஒரே மாதிரியான செயல்பாட்டைக் கொண்டிருப்பதாகத் தோன்றுகிறது, ஆனால் உண்மையில், க்ரோனோகிராஃபில் ஒரு டாஷ்போர்டை அமைப்பது ஒரு சில மவுஸ் கிளிக்குகளில் (அதே நேரத்தில் அங்குள்ள காட்சிப்படுத்தலைப் பார்க்கும்போது) செய்ய முடியும், கிராஃபானாவில் நீங்கள் இன்னும் விரைவில் அல்லது பின்னர் JSON உள்ளமைவைத் திருத்த (நிச்சயமாக க்ரோனோகிராஃப் உங்கள் கையால் கட்டமைக்கப்பட்ட டாஷாக்களை பதிவேற்ற அனுமதிக்கிறது மற்றும் தேவைப்பட்டால் அவற்றை JSON ஆக திருத்தலாம் - ஆனால் அவற்றை UI இல் உருவாக்கிய பிறகு நான் ஒருபோதும் தொட வேண்டியதில்லை).

கிபானா டாஷ்போர்டுகள் மற்றும் அவற்றுக்கான கட்டுப்பாடுகளை உருவாக்குவதற்கு மிகவும் பணக்கார திறன்களைக் கொண்டுள்ளது, ஆனால் அத்தகைய செயல்பாடுகளுக்கான UX மிகவும் சிக்கலானது.

வசதியான டாஷ்போர்டை உருவாக்க சில நல்ல புரிதல் தேவைப்படும். க்ரோனோகிராஃப் டாஷ்போர்டுகளின் செயல்பாடு குறைவாக இருந்தாலும், அவற்றை உருவாக்குவது மற்றும் தனிப்பயனாக்குவது மிகவும் எளிமையானது.

டாஷ்போர்டுகள், இனிமையான காட்சி பாணியைத் தவிர, உண்மையில் கிராஃபானா அல்லது கிபானாவில் உள்ள டாஷ்போர்டுகளிலிருந்து வேறுபட்டவை அல்ல:

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

வினவல் சாளரம் இப்படி இருக்கும்:

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

மற்றவற்றுடன், InfluxDB தரவுத்தளத்தில் உள்ள புலங்களின் வகைகளை அறிந்துகொள்வது, கால வரைபடம் தானாகவே வினவலை எழுதுவதற்கு அல்லது சராசரி போன்ற சரியான திரட்டல் செயல்பாட்டைத் தேர்ந்தெடுப்பதற்கு சில நேரங்களில் தானாகவே உதவும் என்பதைக் கவனத்தில் கொள்ள வேண்டும்.

நிச்சயமாக, பதிவுகளைப் பார்ப்பதற்கு க்ரோனோகிராஃப் முடிந்தவரை வசதியானது. இது போல் தெரிகிறது:

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

முன்னிருப்பாக, Influx பதிவுகள் syslog ஐப் பயன்படுத்துவதற்கு ஏற்றவாறு வடிவமைக்கப்பட்டுள்ளன, எனவே அவை ஒரு முக்கியமான அளவுரு - தீவிரத்தன்மையைக் கொண்டுள்ளன.

மேலே உள்ள வரைபடம் குறிப்பாக பயனுள்ளதாக இருக்கும்; அதில் நீங்கள் ஏற்படும் பிழைகளைக் காணலாம் மற்றும் தீவிரம் அதிகமாக இருந்தால் வண்ணம் உடனடியாக தெளிவாகக் காட்டுகிறது.

இரண்டு முறை இந்த வழியில் முக்கியமான பிழைகளைப் பிடித்தோம், கடந்த வாரத்திற்கான பதிவுகளைப் பார்க்கச் சென்று சிவப்பு ஸ்பைக்கைப் பார்த்தோம்.

நிச்சயமாக, இதுபோன்ற பிழைகளுக்கு விழிப்பூட்டல்களை அமைப்பதே சிறந்தது, ஏனென்றால் இதற்கான அனைத்தையும் நாங்கள் ஏற்கனவே வைத்திருந்தோம்.

நாங்கள் இதை சிறிது நேரம் ஆன் செய்தோம், ஆனால் பைலட்டைத் தயாரிக்கும் செயல்பாட்டில், எங்களுக்கு நிறைய பிழைகள் ஏற்படுகின்றன (எல்டிஇ நெட்வொர்க் கிடைக்காதது போன்ற கணினிகள் உட்பட), இது ஸ்லாக் சேனலையும் "ஸ்பேம்" செய்தது. மிகவும், எந்த பிரச்சனையும் இல்லாமல், பெரும் நன்மை.

இந்த வகையான பெரும்பாலான பிழைகளைக் கையாள்வதும், அவற்றுக்கான தீவிரத்தை சரிசெய்து, எச்சரிக்கையை இயக்குவதும் சரியான தீர்வாக இருக்கும்.

இந்த வழியில், புதிய அல்லது முக்கியமான பிழைகள் மட்டுமே Slack இல் இடுகையிடப்படும். இறுக்கமான காலக்கெடுவைக் கொடுக்கப்பட்ட அத்தகைய அமைப்பிற்கு போதுமான நேரம் இல்லை.

அங்கீகார

க்ரோனோகிராஃப் OAuth மற்றும் OIDC ஐ அங்கீகாரமாக ஆதரிக்கிறது என்பதும் குறிப்பிடத்தக்கது.

இது மிகவும் வசதியானது, ஏனெனில் இது உங்கள் சேவையகத்துடன் எளிதாக இணைக்கவும் மற்றும் முழு அளவிலான SSO ஐ உருவாக்கவும் அனுமதிக்கிறது.

எங்கள் விஷயத்தில், சர்வர் இருந்தது திறவுகோல் — இது கண்காணிப்புடன் இணைக்கப் பயன்படுத்தப்பட்டது, ஆனால் அதே சர்வர் ஸ்கூட்டர் மற்றும் கோரிக்கைகளை பின்-இறுதியில் அங்கீகரிக்கவும் பயன்படுத்தப்பட்டது.

"நிர்வாகம்"

நான் விவரிக்கும் கடைசி கூறு Vue இல் உள்ள எங்களின் சுயமாக எழுதப்பட்ட "நிர்வாக குழு" ஆகும்.
அடிப்படையில் இது ஒரு முழுமையான சேவையாகும், இது எங்கள் சொந்த தரவுத்தளங்கள், மைக்ரோ சர்வீஸ்கள் மற்றும் இன்ஃப்ளக்ஸ்டிபியிலிருந்து ஒரே நேரத்தில் மெட்ரிக்ஸ் தரவிலிருந்து ஸ்கூட்டர் தகவலைக் காண்பிக்கும்.

கூடுதலாக, அவசர மறுதொடக்கம் அல்லது ஆதரவுக் குழுவிற்கான பூட்டை தொலைவிலிருந்து திறப்பது போன்ற பல நிர்வாக செயல்பாடுகள் அங்கு நகர்த்தப்பட்டன.

வரைபடங்களும் இருந்தன. க்ரோனோகிராஃப் என்பதற்குப் பதிலாக கிராஃபானாவுடன் தொடங்கினோம் என்று நான் ஏற்கனவே குறிப்பிட்டுள்ளேன் - ஏனெனில் கிராஃபானா வரைபடங்கள் செருகுநிரல்களின் வடிவத்தில் கிடைக்கின்றன, அதில் ஸ்கூட்டர்களின் ஆயங்களை நாம் பார்க்கலாம். துரதிர்ஷ்டவசமாக, கிராஃபனாவிற்கான வரைபட விட்ஜெட்களின் திறன்கள் மிகவும் குறைவாகவே உள்ளன, இதன் விளைவாக, ஒரு சில நாட்களில் உங்கள் சொந்த வலைப் பயன்பாட்டை வரைபடங்களுடன் எழுதுவது மிகவும் எளிதாக இருந்தது, இந்த நேரத்தில் ஆயங்களைப் பார்ப்பது மட்டுமல்லாமல், காண்பிக்கவும். ஸ்கூட்டர் செல்லும் பாதை, வரைபடத்தில் உள்ள தரவை வடிகட்ட முடியும், முதலியன (எங்களால் ஒரு எளிய டாஷ்போர்டில் உள்ளமைக்க முடியாத செயல்பாடு).

Influx இன் ஏற்கனவே குறிப்பிடப்பட்ட நன்மைகளில் ஒன்று உங்கள் சொந்த அளவீடுகளை எளிதாக உருவாக்கும் திறன் ஆகும்.
இது பல்வேறு வகையான காட்சிகளுக்குப் பயன்படுத்த அனுமதிக்கிறது.

பேட்டரி சார்ஜ், லாக் நிலை, சென்சார் செயல்திறன், புளூடூத், ஜிபிஎஸ் மற்றும் பல சுகாதார சோதனைகள்: அனைத்து பயனுள்ள தகவல்களையும் பதிவு செய்ய முயற்சித்தோம்.
இதையெல்லாம் நிர்வாக குழுவில் காட்டினோம்.

நிச்சயமாக, எங்களுக்கு மிக முக்கியமான அளவுகோல் ஸ்கூட்டரின் இயக்க நிலை - உண்மையில், இன்ஃப்ளக்ஸ் இதை தானே சரிபார்த்து, நோட்ஸ் பிரிவில் “பச்சை விளக்குகள்” மூலம் காண்பிக்கும்.

இது செயல்பாட்டின் மூலம் செய்யப்படுகிறது இறந்த மனிதன் - எங்கள் பெட்டியின் செயல்திறனைப் புரிந்துகொண்டு அதே விழிப்பூட்டல்களை ஸ்லாக்கிற்கு அனுப்ப அதைப் பயன்படுத்தினோம்.

மூலம், ஸ்கூட்டர்களுக்கு தி சிம்ப்சன்ஸின் கதாபாத்திரங்களின் பெயர்களை நாங்கள் பெயரிட்டோம் - அவற்றை ஒருவருக்கொருவர் வேறுபடுத்துவது மிகவும் வசதியாக இருந்தது.

பொதுவாக, இந்த வழி மிகவும் வேடிக்கையாக இருந்தது. “கைஸ், ஸ்மிதர்ஸ் இறந்துவிட்டார்!” போன்ற சொற்றொடர்கள் தொடர்ந்து கேட்கப்பட்டன.

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

சர அளவீடுகள்

விக்டோரியா மெட்ரிக்ஸைப் போலவே, எண் மதிப்புகளை மட்டும் சேமிக்க InfluxDB உங்களை அனுமதிக்கிறது.

இது அவ்வளவு முக்கியமில்லை என்று தோன்றுகிறது - எல்லாவற்றிற்கும் மேலாக, பதிவுகளைத் தவிர, எந்த அளவீடுகளையும் எண்களின் வடிவத்தில் சேமிக்க முடியுமா (தெரிந்த மாநிலங்களுக்கு மேப்பிங்கைச் சேர்க்கவும் - ஒரு வகையான enum)?

எங்கள் விஷயத்தில், சரம் அளவீடுகள் மிகவும் பயனுள்ளதாக இருக்கும் ஒரு காட்சியாவது இருந்தது.
எங்கள் "ஸ்மார்ட் சார்ஜர்களின்" சப்ளையர் மூன்றாம் தரப்பினர், வளர்ச்சி செயல்முறை மற்றும் இந்த சார்ஜர்கள் வழங்கக்கூடிய தகவல்களின் மீது எங்களுக்கு எந்த கட்டுப்பாடும் இல்லை.

இதன் விளைவாக, சார்ஜிங் API இலட்சியத்திலிருந்து வெகு தொலைவில் இருந்தது, ஆனால் முக்கிய பிரச்சனை என்னவென்றால், அவற்றின் நிலையை எங்களால் எப்போதும் புரிந்து கொள்ள முடியவில்லை.

இங்குதான் இன்ஃப்ளக்ஸ் மீட்புக்கு வந்தது. InfluxDB தரவுத்தள புலத்தில் எங்களுக்கு வந்த சரம் நிலையை மாற்றங்கள் இல்லாமல் எழுதினோம்.

சில நேரம், "ஆன்லைன்" மற்றும் "ஆஃப்லைன்" போன்ற மதிப்புகள் மட்டுமே அங்கு கிடைத்தன, அதன் அடிப்படையில் எங்கள் நிர்வாக குழுவில் தகவல் காட்டப்பட்டு, ஸ்லாக்கிற்கு அறிவிப்புகள் அனுப்பப்பட்டன. இருப்பினும், ஒரு கட்டத்தில், "துண்டிக்கப்பட்ட" போன்ற மதிப்புகளும் அங்கு தோன்றத் தொடங்கின.

ஒரு குறிப்பிட்ட எண்ணிக்கையிலான முயற்சிகளுக்குப் பிறகு சார்ஜரால் சேவையகத்துடன் இணைப்பை நிறுவ முடியாவிட்டால், இணைப்பு இழந்த பிறகு இந்த நிலை ஒரு முறை அனுப்பப்பட்டது.

எனவே, நாம் ஒரு நிலையான மதிப்புகளை மட்டுமே பயன்படுத்தினால், சரியான நேரத்தில் ஃபார்ம்வேரில் இந்த மாற்றங்களைக் காண முடியாது.

பொதுவாக, சரம் அளவீடுகள் பயன்பாட்டிற்கான அதிக சாத்தியக்கூறுகளை வழங்குகின்றன; அவற்றில் எந்த தகவலையும் நீங்கள் பதிவு செய்யலாம். இருப்பினும், நிச்சயமாக, நீங்கள் இந்த கருவியை கவனமாகப் பயன்படுத்த வேண்டும்.

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

வழக்கமான அளவீடுகளுக்கு கூடுதலாக, InfluxDB இல் GPS இருப்பிடத் தகவலையும் பதிவு செய்துள்ளோம். எங்கள் நிர்வாக குழுவில் ஸ்கூட்டர்களின் இருப்பிடத்தைக் கண்காணிக்க இது நம்பமுடியாத அளவிற்கு பயனுள்ளதாக இருந்தது.
உண்மையில், நமக்குத் தேவையான நேரத்தில் எங்கே, எந்த ஸ்கூட்டர் இருக்கிறது என்பது எங்களுக்கு எப்போதும் தெரியும்.

நாங்கள் ஸ்கூட்டரைத் தேடும் போது இது எங்களுக்கு மிகவும் பயனுள்ளதாக இருந்தது (முடிவில் உள்ள முடிவுகளைப் பார்க்கவும்).

உள்கட்டமைப்பு கண்காணிப்பு

ஸ்கூட்டர்களைத் தவிர, எங்கள் முழு (மாறாக விரிவான) உள்கட்டமைப்பையும் கண்காணிக்க வேண்டும்.

மிகவும் பொதுவான கட்டிடக்கலை இதைப் போன்றது:

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

தூய கண்காணிப்பு அடுக்கை நாங்கள் முன்னிலைப்படுத்தினால், இது போல் தெரிகிறது:

காணாமல் போன ஸ்கூட்டரை அல்லது ஒரு IoT கண்காணிப்பின் கதையை திருப்பித் தரவும்

கிளவுட்டில் நாம் பார்க்க விரும்புவது:

  • தரவுத்தளங்கள்
  • திறவுகோல்
  • நுண் சேவைகள்

எங்கள் கிளவுட் சேவைகள் அனைத்தும் குபெர்னெட்டஸில் அமைந்துள்ளதால், அதன் நிலையைப் பற்றிய தகவல்களைச் சேகரிப்பது நன்றாக இருக்கும்.

அதிர்ஷ்டவசமாக, Telegraf out of the box குபெர்னெட்ஸ் கிளஸ்டரின் நிலையைப் பற்றிய அதிக எண்ணிக்கையிலான அளவீடுகளை சேகரிக்க முடியும், மேலும் க்ரோனோகிராஃப் உடனடியாக அழகான டாஷ்போர்டுகளை வழங்குகிறது.

காய்களின் செயல்திறன் மற்றும் நினைவக நுகர்வு ஆகியவற்றை நாங்கள் முக்கியமாக கண்காணித்தோம். வீழ்ச்சி ஏற்பட்டால், ஸ்லாக்கில் எச்சரிக்கைகள்.

குபெர்னெட்டஸில் காய்களைக் கண்காணிக்க இரண்டு வழிகள் உள்ளன: டெமான்செட் மற்றும் சைட்கார்.
இரண்டு முறைகளும் விரிவாக விவரிக்கப்பட்டுள்ளன இந்த வலைப்பதிவு இடுகையில்.

நாங்கள் Telegraf Sidecar ஐப் பயன்படுத்தினோம், மேலும் அளவீடுகளுக்கு கூடுதலாக, பாட் பதிவுகளை சேகரித்தோம்.

எங்கள் விஷயத்தில், நாங்கள் பதிவுகளுடன் டிங்கர் செய்ய வேண்டியிருந்தது. Telegraf ஆனது Docker API இலிருந்து பதிவுகளை இழுக்க முடியும் என்ற உண்மை இருந்தபோதிலும், எங்களின் இறுதி சாதனங்களுடன் ஒரே மாதிரியான பதிவுகள் சேகரிப்பு மற்றும் கன்டெய்னர்களுக்கான syslog உள்ளமைக்கப்பட வேண்டும் என்று நாங்கள் விரும்பினோம். ஒருவேளை இந்த தீர்வு அழகாக இல்லை, ஆனால் அதன் வேலை பற்றி எந்த புகாரும் இல்லை மற்றும் பதிவுகள் க்ரோனோகிராஃபில் நன்றாக காட்டப்பட்டன.

கண்காணிப்பு கண்காணிப்பு???

இறுதியில், கண்காணிப்பு அமைப்புகளைக் கண்காணிப்பதற்கான பழைய கேள்வி எழுந்தது, ஆனால் அதிர்ஷ்டவசமாக அல்லது துரதிர்ஷ்டவசமாக, இதற்கு எங்களுக்கு போதுமான நேரம் இல்லை.

டெலிகிராஃப் அதன் சொந்த அளவீடுகளை எளிதாக அனுப்பலாம் அல்லது அதே இன்ஃப்ளக்ஸ் அல்லது வேறு எங்காவது அனுப்புவதற்கு InfluxDB தரவுத்தளத்திலிருந்து அளவீடுகளை சேகரிக்கலாம்.

கண்டுபிடிப்புகள்

பைலட்டின் முடிவுகளிலிருந்து நாம் என்ன முடிவுகளை எடுத்தோம்?

நீங்கள் எப்படி கண்காணிப்பு செய்ய முடியும்?

முதலாவதாக, TICK ஸ்டாக் எங்கள் எதிர்பார்ப்புகளை முழுமையாக பூர்த்திசெய்தது மற்றும் நாங்கள் ஆரம்பத்தில் எதிர்பார்த்ததை விட அதிக வாய்ப்புகளை எங்களுக்கு வழங்கியது.

எங்களுக்கு தேவையான அனைத்து செயல்பாடுகளும் இருந்தன. அதனுடன் நாங்கள் செய்த அனைத்தும் எந்த பிரச்சனையும் இல்லாமல் வேலை செய்தன.

உற்பத்தித்

இலவச பதிப்பில் உள்ள TICK ஸ்டேக்கின் முக்கிய பிரச்சனை அளவிடுதல் திறன்கள் இல்லாதது. இது எங்களுக்கு ஒரு பிரச்சனையாக இருக்கவில்லை.

நாங்கள் சரியான சுமை தரவு/புள்ளிவிவரங்களைச் சேகரிக்கவில்லை, ஆனால் ஒரே நேரத்தில் சுமார் 30 ஸ்கூட்டர்களில் இருந்து தரவைச் சேகரித்தோம்.

அவை ஒவ்வொன்றும் மூன்று டஜன் அளவீடுகளுக்கு மேல் சேகரித்தன. அதே நேரத்தில், சாதனங்களிலிருந்து பதிவுகள் சேகரிக்கப்பட்டன. ஒவ்வொரு 10 வினாடிகளுக்கும் தரவு சேகரிப்பு மற்றும் அனுப்புதல் நிகழ்ந்தது.

பைலட்டின் ஒன்றரை வாரத்திற்குப் பிறகு, "குழந்தைப் பருவ சிக்கல்கள்" சரி செய்யப்பட்டு, மிக முக்கியமான சிக்கல்கள் ஏற்கனவே தீர்க்கப்பட்டபோது, ​​சேவையகத்திற்கு தரவை அனுப்பும் அதிர்வெண்ணைக் குறைக்க வேண்டியிருந்தது என்பதை கவனத்தில் கொள்ள வேண்டும். 30 வினாடிகள். எங்கள் LTE சிம் கார்டுகளின் போக்குவரத்து விரைவாக மறைந்து போகத் தொடங்கியதால் இது அவசியமானது.

போக்குவரத்தின் பெரும்பகுதி பதிவுகளால் நுகரப்பட்டது; அளவீடுகள், 10-வினாடி இடைவெளியுடன் கூட, நடைமுறையில் அதை வீணாக்கவில்லை.

இதன் விளைவாக, சில காலத்திற்குப் பிறகு, சாதனங்களில் பதிவுகளின் சேகரிப்பை முழுவதுமாக முடக்கினோம், ஏனெனில் நிலையான சேகரிப்பு இல்லாமல் கூட குறிப்பிட்ட சிக்கல்கள் ஏற்கனவே தெளிவாகத் தெரிந்தன.

சில சந்தர்ப்பங்களில், பதிவுகளைப் பார்ப்பது இன்னும் அவசியமாக இருந்தால், நாங்கள் VPN வழியாக WireGuard வழியாக இணைக்கப்பட்டுள்ளோம்.

ஒவ்வொரு தனித்தனி சூழலும் ஒருவருக்கொருவர் பிரிக்கப்பட்டதையும் நான் சேர்க்கிறேன், மேலும் மேலே விவரிக்கப்பட்ட சுமை உற்பத்தி சூழலுக்கு மட்டுமே பொருத்தமானது.

வளர்ச்சிச் சூழலில், ஒவ்வொரு 10 வினாடிகளுக்கும் தரவைத் தொடர்ந்து சேகரிக்கும் ஒரு தனி InfluxDB நிகழ்வை நாங்கள் எழுப்பியுள்ளோம், மேலும் செயல்திறன் சிக்கல்கள் எதையும் நாங்கள் சந்திக்கவில்லை.

டிக் - சிறிய மற்றும் நடுத்தர திட்டங்களுக்கு ஏற்றது

இந்த தகவலின் அடிப்படையில், டிக் ஸ்டாக் ஒப்பீட்டளவில் சிறிய திட்டங்கள் அல்லது திட்டங்களுக்கு ஏற்றதாக இருக்கும் என்று நான் முடிவு செய்கிறேன்.

உங்களிடம் ஆயிரக்கணக்கான காய்கள் அல்லது நூற்றுக்கணக்கான இயந்திரங்கள் இல்லையென்றால், ஒரு InfluxDB நிகழ்வு கூட சுமையை நன்றாகக் கையாளும்.

சில சந்தர்ப்பங்களில், இன்ஃப்ளக்ஸ் ரிலே ஒரு பழமையான உயர் கிடைக்கும் தீர்வாக நீங்கள் திருப்தி அடையலாம்.

மற்றும், நிச்சயமாக, "செங்குத்து" அளவை அமைப்பதில் இருந்து யாரும் உங்களைத் தடுக்கவில்லை மற்றும் வெவ்வேறு வகையான அளவீடுகளுக்கு வெவ்வேறு சேவையகங்களை ஒதுக்குகிறார்கள்.

கண்காணிப்புச் சேவைகளில் எதிர்பார்க்கப்படும் சுமை பற்றி உங்களுக்குத் தெரியாவிட்டால், அல்லது நீங்கள் மிகவும் "கனமான" கட்டமைப்பைப் பெற்றிருப்பீர்கள்/உறுதிப்படுத்தினால், TICK ஸ்டேக்கின் இலவச பதிப்பைப் பயன்படுத்த நான் பரிந்துரைக்க மாட்டேன்.

நிச்சயமாக, ஒரு எளிய தீர்வு வாங்க வேண்டும் InfluxDB எண்டர்பிரைஸ் - ஆனால் இங்கே நான் எப்படியாவது கருத்து தெரிவிக்க முடியாது, ஏனென்றால் எனக்கு நுணுக்கங்கள் தெரிந்திருக்கவில்லை. இது மிகவும் விலை உயர்ந்தது மற்றும் சிறிய நிறுவனங்களுக்கு நிச்சயமாக பொருந்தாது என்ற உண்மையைத் தவிர.

இந்த நிலையில், இன்று, விக்டோரியா மெட்ரிக்ஸ் மற்றும் லோகியைப் பயன்படுத்தி பதிவுகள் மூலம் அளவீடுகளைச் சேகரிக்கப் பரிந்துரைக்கிறேன்.

உண்மை, நான் மீண்டும் முன்பதிவு செய்கிறேன், லோகி/கிராஃபனா ரெடிமேட் டிக் ஐ விட மிகவும் குறைவான வசதியானது (அவற்றின் பல்துறைத்திறன் காரணமாக), ஆனால் அவை இலவசம்.

முக்கியமான: இங்கு விவரிக்கப்பட்டுள்ள அனைத்து தகவல்களும் பதிப்பு இன்ஃப்ளக்ஸ் 1.8 க்கு பொருத்தமானவை, தற்போது இன்ஃப்ளக்ஸ் 2.0 வெளியிடப்பட உள்ளது.

போர் நிலைமைகளில் இதை முயற்சிக்க எனக்கு வாய்ப்பு இல்லை என்றாலும், மேம்பாடுகளைப் பற்றி முடிவுகளை எடுப்பது கடினம், இடைமுகம் நிச்சயமாக இன்னும் சிறப்பாக மாறிவிட்டது, கட்டிடக்கலை எளிமைப்படுத்தப்பட்டுள்ளது (கேபாசிட்டர் மற்றும் க்ரோனோகிராஃப் இல்லாமல்),
வார்ப்புருக்கள் தோன்றின ("கொலையாளி அம்சம்" - நீங்கள் Fortnite இல் பிளேயர்களைக் கண்காணிக்கலாம் மற்றும் உங்களுக்குப் பிடித்த வீரர் ஒரு கேமில் வெற்றி பெற்றால் அறிவிப்புகளைப் பெறலாம்) ஆனால், துரதிர்ஷ்டவசமாக, இந்த நேரத்தில், பதிப்பு 2 இல் நாங்கள் முதல் பதிப்பைத் தேர்ந்தெடுத்த முக்கிய விஷயம் இல்லை - பதிவு சேகரிப்பு இல்லை.

இந்த செயல்பாடு Influx 2.0 இல் தோன்றும், ஆனால் எங்களால் எந்த காலக்கெடுவையும் கண்டுபிடிக்க முடியவில்லை, தோராயமானவை கூட.

IoT இயங்குதளங்களை உருவாக்குவது எப்படி (இப்போது)

இறுதியில், பைலட்டை அறிமுகப்படுத்திய பிறகு, எங்கள் தரத்திற்கு ஏற்ற மாற்று இல்லாத நிலையில், நாமே எங்கள் சொந்த முழு அளவிலான IoT ஸ்டேக்கைச் சேகரித்தோம்.

இருப்பினும், சமீபத்தில் இது பீட்டா பதிப்பில் கிடைக்கிறது OpenBalena - நாங்கள் திட்டத்தை உருவாக்கத் தொடங்கியபோது அவள் அங்கு இல்லை என்பது ஒரு பரிதாபம்.

இறுதி முடிவு மற்றும் அன்சிபிள் + டிக் + வயர்கார்டு அடிப்படையிலான இயங்குதளத்தில் நாங்கள் முழுமையாக திருப்தி அடைந்துள்ளோம். ஆனால் இன்று, உங்கள் சொந்த IoT தளத்தை நீங்களே உருவாக்க முயற்சிக்கும் முன் பலேனாவை உன்னிப்பாகப் பார்க்க பரிந்துரைக்கிறேன்.

ஏனெனில் இறுதியில் நாம் செய்தவற்றில் பெரும்பாலானவற்றை இது செய்ய முடியும், மேலும் OpenBalena இலவசம் மற்றும் திறந்த மூலமாகும்.

புதுப்பிப்புகளை அனுப்புவது மட்டுமல்லாமல், ஐஓடி சூழலில் பயன்படுத்தக்கூடிய வகையில் VPN ஏற்கனவே உள்ளமைக்கப்பட்டு வடிவமைக்கப்பட்டுள்ளது என்பது ஏற்கனவே தெரியும்.

மற்றும் சமீபத்தில், அவர்கள் கூட வெளியிட்டனர் வன்பொருள், இது அவர்களின் சுற்றுச்சூழல் அமைப்புடன் எளிதாக இணைக்கிறது.

ஏய், ஸ்கூட்டரைக் காணவில்லையா?

அதனால் "ரால்ப்" என்ற ஸ்கூட்டர் ஒரு தடயமும் இல்லாமல் காணாமல் போனது.

InfluxDB இலிருந்து GPS அளவீடுகள் தரவுகளுடன், எங்கள் "நிர்வாக குழு" இல் உள்ள வரைபடத்தைப் பார்க்க உடனடியாக ஓடினோம்.

கண்காணிப்பு தரவுகளுக்கு நன்றி, ஸ்கூட்டர் கடந்த நாள் 21:00 மணியளவில் வாகன நிறுத்துமிடத்தை விட்டு வெளியேறி, சில பகுதிகளுக்கு சுமார் அரை மணி நேரம் ஓட்டிச் சென்று, ஏதோ ஒரு ஜெர்மன் வீட்டின் அருகே காலை 5 மணி வரை நிறுத்தப்பட்டது என்பதை நாங்கள் எளிதாகக் கண்டறிந்தோம்.

காலை 5 மணிக்குப் பிறகு, கண்காணிப்புத் தரவு எதுவும் பெறப்படவில்லை - அதாவது கூடுதல் பேட்டரி முழுவதுமாக டிஸ்சார்ஜ் செய்யப்பட்டது அல்லது ஸ்கூட்டரில் இருந்து ஸ்மார்ட் ஹார்டுவேரை எப்படி அகற்றுவது என்பதைத் தாக்குபவர் இறுதியாகக் கண்டுபிடித்தார்.
இருந்த போதிலும், ஸ்கூட்டர் இருந்த முகவரிக்கு போலீசார் வரவழைக்கப்பட்டனர். ஸ்கூட்டர் அங்கு இல்லை.

இருப்பினும், வீட்டின் உரிமையாளரும் இதைப் பார்த்து ஆச்சரியப்பட்டார், ஏனெனில் அவர் நேற்றிரவு இந்த ஸ்கூட்டரை அலுவலகத்தில் இருந்து வீட்டிற்கு ஓட்டினார்.

அது முடிந்தவுடன், ஆதரவு ஊழியர்களில் ஒருவர் அதிகாலையில் வந்து ஸ்கூட்டரை எடுத்தார், அதன் கூடுதல் பேட்டரி முழுவதுமாக டிஸ்சார்ஜ் செய்யப்பட்டிருப்பதைக் கண்டு அதை (கால்நடையில்) வாகன நிறுத்துமிடத்திற்கு அழைத்துச் சென்றார். மேலும் ஈரப்பதம் காரணமாக கூடுதல் பேட்டரி தோல்வியடைந்தது.

ஸ்கூட்டரை நாங்களே திருடிக்கொண்டோம். எப்படி, யார் போலீஸ் வழக்கில் சிக்கலைத் தீர்த்தார்கள் என்று எனக்குத் தெரியவில்லை, ஆனால் கண்காணிப்பு சரியாக வேலை செய்தது...

ஆதாரம்: www.habr.com

கருத்தைச் சேர்