Жилийн өмнө бид сурталчилгааны төслийн туршилтын хувилбарыг эхлүүлсэн .
Эхэндээ уг төслийг Зам-Барселон гэж нэрлэж байсан бол хожим нь Зам-Берлин (Тиймээс дэлгэцийн агшинд R2B) болж, эцэст нь xRide гэж нэрлэв.
Төслийн гол санаа нь: төвлөрсөн машин эсвэл скутер түрээслэхийн оронд (бид цахилгаан мотоциклийн тухай ярьж байна, скутер/скутер биш) бид төвлөрсөн бус түрээсийн платформ хийхийг хүссэн. Бидэнд тохиолдсон бэрхшээлүүдийн талаар .
Эхэндээ уг төсөл нь автомашинд төвлөрч байсан боловч эцсийн хугацаа, үйлдвэрлэгчидтэй маш урт харилцаа холбоо, аюулгүй байдлын асар их хязгаарлалт зэргээс шалтгаалан цахилгаан скутеруудыг туршилтын журмаар сонгосон.
Хэрэглэгч утсандаа iOS эсвэл Android програм суулгаж, дуртай скутер дээрээ дөхөж очсоны дараа утас болон скутер нь үе тэнгийн холбоо тогтоож, ETH солилцож, хэрэглэгч скутерээ асаан жолоодох боломжтой болсон. утас. Аяллын төгсгөлд утасныхаа түрийвчнээс Ethereum ашиглан аяллын төлбөрөө төлөх боломжтой болсон.
Скутерээс гадна хэрэглэгч уг программ дахь "ухаалаг цэнэглэгч" -ийг олж харсан бөгөөд түүн дээр зочлон хэрэглэгч одоогийн батерейг бага бол өөрөө сольж болно.
Өнгөрсөн оны есдүгээр сард Германы Бонн, Берлин гэсэн хоёр хотод хөөргөсөн манай нисгэгч ерөнхийдөө ийм л харагдаж байна.
Тэгээд нэг өдөр, Бонн хотод өглөө эрт манай туслах баг (скутерүүдийг ажиллуулахаар газар дээр нь байрладаг) сэрэмжлүүлэв: скутерүүдийн нэг нь ул мөргүй алга болжээ.
Үүнийг хэрхэн олж, буцааж өгөх вэ?
Энэ нийтлэлд би энэ тухай ярих болно, гэхдээ эхлээд бид IoT платформоо хэрхэн бүтээсэн, түүнийг хэрхэн хянаж байсан талаар ярих болно.
Юуг, яагаад хянах вэ: скутер, дэд бүтэц, цэнэглэх станц?
Тэгэхээр бид төсөлдөө юуг хянахыг хүссэн бэ?
Юуны өмнө эдгээр нь скутерууд өөрсдөө юм - цахилгаан скутер нь өөрөө нэлээд үнэтэй тул та хангалттай бэлтгэлгүйгээр ийм төслийг эхлүүлэх боломжгүй; боломжтой бол скутеруудын талаар аль болох их мэдээлэл цуглуулахыг хүсч байна: тэдгээрийн байршил, цэнэгийн түвшин. , гэх мэт.
Нэмж дурдахад би өөрийн мэдээллийн технологийн дэд бүтцийн байдал - мэдээллийн сан, үйлчилгээ, ажиллахад шаардлагатай бүх зүйлд хяналт тавихыг хүсч байна. Түүнчлэн "ухаалаг цэнэглэгч" эвдэрсэн эсвэл бүрэн батерей нь дууссан тохиолдолд тэдгээрийн төлөв байдлыг хянах шаардлагатай байв.
Скутер
Манай скутерууд юу байсан бэ, бид тэдний талаар юу мэдэхийг хүссэн бэ?
Эхний бөгөөд хамгийн чухал зүйл бол GPS-ийн координатууд бөгөөд тэдгээрийн ачаар бид хаана, хаана хөдөлж байгааг ойлгох боломжтой.
Дараа нь зайны цэнэг байгаа бөгөөд үүний ачаар бид скутеруудын цэнэглэлт дуусч байгааг тодорхойлж, шүүс шахагч илгээх эсвэл ядаж хэрэглэгчдэд анхааруулах боломжтой.
Мэдээжийн хэрэг, манай Тоног төхөөрөмжийн бүрэлдэхүүн хэсгүүдэд юу болж байгааг шалгах шаардлагатай:
- bluetooth ажилладаг уу?
- GPS модуль өөрөө ажилладаг уу?
- Түүнчлэн GPS нь буруу координат илгээж, гацах боломжтой байсан бөгөөд үүнийг зөвхөн скутер дээрх нэмэлт шалгалтаар тодорхойлох боломжтой байсан.
асуудлыг шийдвэрлэхийн тулд тусламжид аль болох хурдан мэдэгдэнэ үү
- Түүнчлэн GPS нь буруу координат илгээж, гацах боломжтой байсан бөгөөд үүнийг зөвхөн скутер дээрх нэмэлт шалгалтаар тодорхойлох боломжтой байсан.
Эцэст нь: үйлдлийн систем, процессор, сүлжээ, дискний ачааллаас эхлээд програм хангамжийн шалгалт, бидний хувьд илүү тодорхой байдаг модулиудын шалгалтууд (, ).
Тоног төхөөрөмжийн
Бидний "төмөр" хэсэг юу байсан бэ?
Хамгийн богино хугацаа, хурдан прототип хийх хэрэгцээг харгалзан бид хэрэгжүүлэх, бүрэлдэхүүн хэсгүүдийг сонгох хамгийн хялбар хувилбар болох Raspberry Pi-г сонгосон.
Rpi-ээс гадна бидэнд захиалгат самбар (эцсийн шийдлийг угсрах процессыг хурдасгахын тулд бид өөрсдөө боловсруулж, Хятадаас захиалсан) болон бүрэлдэхүүн хэсгүүдийн багц - реле (скутер асаах/унтраах) байсан. зай цэнэглэгч уншигч, модем, антен. Энэ бүгдийг тусгай "xRide хайрцаг" -д авсаархан савласан.
Мөн хайрцгийг бүхэлд нь нэмэлт тэжээлийн банкаар тэжээж, энэ нь эргээд скутерын үндсэн батерейгаар тэжээгддэг гэдгийг тэмдэглэх нь зүйтэй.
Энэ нь гал асаах түлхүүрийг "унтраах" байрлалд оруулсны дараа үндсэн батерейг шууд унтраасан тул аялал дууссаны дараа ч хяналтыг ашиглах, скутер асаах боломжтой болсон.
Докер? Энгийн Linux уу? болон байршуулалт
Хяналтанд буцаж орцгооё, бөөрөлзгөнө - бидэнд юу байгаа вэ?
Физик төхөөрөмжүүдэд бүрэлдэхүүн хэсгүүдийг байршуулах, шинэчлэх, хүргэх үйл явцыг хурдасгахын тулд бидний ашиглахыг хүссэн хамгийн эхний зүйл бол Docker байсан.
Харамсалтай нь, RPi дээрх Docker нь хэдийгээр ажилладаг ч эрчим хүчний хэрэглээний хувьд маш их зардал шаарддаг нь хурдан тодорхой болсон.
"Уугуул" OS-ийн ялгаа нь тийм ч хүчтэй биш ч цэнэгээ хурдан алдахаас болгоомжлоход хангалттай байсан.
Хоёрдахь шалтгаан нь Go/C/C++ дээр бичигдээгүй системийн цорын ганц бүрэлдэхүүн хэсэг болох Node.js (sic!) дээрх манай түнш номын сангуудын нэг байсан.
Номын сангийн зохиогчид аль ч "төрөлх" хэл дээрх ажлын хувилбарыг өгөх цаг байсангүй.
Зангилаа нь өөрөө бага хүчин чадалтай төхөөрөмжүүдийн хувьд хамгийн гоёмсог шийдэл биш төдийгүй номын сан өөрөө маш их нөөцтэй байсан.
Хэдийгээр бид хүссэн ч Docker-ийг ашиглах нь бидний хувьд хэт их зардал болно гэдгийг ойлгосон. Сонголт нь уугуул OS-ийн талд хийгдсэн бөгөөд түүний дор шууд ажилладаг.
OS
Үүний үр дүнд бид дахин үйлдлийн систем болох хамгийн энгийн хувилбарыг сонгож, Raspbian (Debian build for Pi) ашигласан.
Бид бүх программ хангамжаа Go дээр бичдэг тул системийнхээ үндсэн техник хангамжийн агент модулийг Go дээр бичсэн.
Тэр бол GPS, Bluetooth-тэй ажиллах, цэнэгийг унших, скутер асаах гэх мэтийг хариуцдаг.
Байрлуулах
Төхөөрөмжүүдэд шинэчлэлтийг (OTA) хүргэх механизмыг хэрэгжүүлэх шаардлагатай гэсэн асуулт тэр даруй гарч ирэв - манай агент/аппликейшн өөрөө болон үйлдлийн систем/програм хангамжийн шинэчлэлтүүд (учир нь агентын шинэ хувилбарууд цөмд шинэчлэлт хийх шаардлагатай байж магадгүй юм. эсвэл системийн бүрэлдэхүүн хэсэг, номын сан гэх мэт).
Зах зээл дээр нэлээд удаан дүн шинжилгээ хийсний дараа төхөөрөмжид шинэчлэлтүүдийг хүргэх маш олон шийдэл байгаа нь тогтоогджээ.
Харьцангуй энгийн, swupd/SWUpdate/OSTree зэрэг шинэчлэх/хос ачаалах зориулалттай хэрэгслүүдээс эхлээд Mender, Balena зэрэг бүрэн хэмжээний платформууд хүртэл.
Юуны өмнө бид төгсгөлийн шийдлүүдийг сонирхож байна гэж шийдсэн тул сонголт нь тэр даруй платформ дээр буув.
Өөрөө шүү дээ balenaEngine дотроо яг ижил Docker ашигладаг тул хассан.
Гэсэн хэдий ч бид тэдний бүтээгдэхүүнийг байнга хэрэглэж байсныг би тэмдэглэж байна SD карт дээрх флаш програм хангамжийн хувьд энэ нь энгийн бөгөөд маш тохиромжтой хэрэгсэл юм.
Тиймээс эцэст нь сонголт унав . Mender бол програм хангамжийг угсрах, хүргэх, суулгах бүрэн платформ юм.
Ерөнхийдөө платформ нь гайхалтай харагдаж байна, гэхдээ mender Builder ашиглан програмынхаа зөв хувилбарыг бүтээхэд бид долоо хоног хагасын хугацаа зарцуулсан.
Мөн бид түүний хэрэглээний нарийн ширийн зүйлд хэдий чинээ гүнзгий орох тусам үүнийг бүрэн ашиглахын тулд бидэнд байгаа хугацаанаас хамаагүй их цаг хугацаа шаардагдах нь тодорхой болсон.
Харамсалтай нь, бидний эцсийн хугацаа маш нарийн байсан нь бид Мендерийн хэрэглээг орхиж, илүү энгийн хувилбарыг сонгохоос өөр аргагүй болсон гэсэн үг юм.
Алгасах
Бидний нөхцөл байдлын хамгийн энгийн шийдэл бол Ansible ашиглах явдал байв. Эхлэхийн тулд хэд хэдэн тоглоомын ном хангалттай байсан.
Тэдний мөн чанар нь бид зүгээр л хостоос (CI сервер) ssh-ээр дамжуулан өөрийн бөөрөлзгөнөтэй холбогдож, тэдэнд шинэчлэлтүүдийг тараасан явдал байв.
Эхэндээ бүх зүйл энгийн байсан - та төхөөрөмжүүдтэй нэг сүлжээнд байх ёстой, цутгах нь Wi-Fi-аар хийгдсэн.
Оффис дээр нэг сүлжээнд холбогдсон хэдэн арван туршилтын бөөрөлзгөнө байсан бөгөөд төхөөрөмж бүр нь Ansible Inventory-д заасан статик IP хаягтай байв.
Манай хяналтын агентыг эцсийн төхөөрөмжид хүргэсэн нь Ansible байсан
3G / LTE
Харамсалтай нь, Ansible-д зориулсан энэхүү хэрэглээний тохиолдол нь бодит скутертэй болохоос өмнө зөвхөн хөгжүүлэлтийн горимд ажиллах боломжтой байсан.
Учир нь скутерууд нь таны ойлгож байгаагаар нэг Wi-Fi чиглүүлэгчтэй холбогдож суудаггүй бөгөөд сүлжээгээр шинэчлэлтүүдийг байнга хүлээж байдаг.
Бодит байдал дээр скутерууд нь гар утасны 3G/LTE-ээс өөр ямар ч холболттой байж чадахгүй (тэр ч байтугай үргэлж биш).
Энэ нь холболтын хурд бага, тогтворгүй харилцаа зэрэг олон асуудал, хязгаарлалтыг шууд бий болгодог.
Гэхдээ хамгийн чухал зүйл бол 3G/LTE сүлжээнд бид сүлжээнд хуваарилагдсан статик IP-д найдах боломжгүй юм.
Үүнийг зарим SIM карт нийлүүлэгчид хэсэгчлэн шийдэж, статик IP хаягтай IoT төхөөрөмжүүдэд зориулагдсан тусгай SIM картууд байдаг. Гэхдээ бид ийм SIM карт ашиглах боломжгүй байсан бөгөөд IP хаягийг ашиглах боломжгүй байсан.
Мэдээжийн хэрэг, Консул гэх мэт хаа нэгтээ IP хаягийн бүртгэлийг хийх санаанууд байсан, гэхдээ бид ийм санаануудыг орхих хэрэгтэй болсон, учир нь бидний туршилтын явцад IP хаяг хэтэрхий олон удаа өөрчлөгдөж, энэ нь ихээхэн тогтворгүй байдалд хүргэсэн.
Ийм учраас хэмжигдэхүүнийг хүргэх хамгийн тохиромжтой хэрэглээ нь татах загварыг ашиглах биш, шаардлагатай хэмжигдэхүүнийг авахын тулд төхөөрөмж рүү очих биш харин түлхэж, төхөөрөмжөөс хэмжигдэхүүнийг сервер рүү шууд дамжуулах явдал юм.
VPN
Энэ асуудлыг шийдэхийн тулд бид VPN-г сонгосон .
Үйлчлүүлэгчид (скутер) системийн эхэнд VPN серверт холбогдсон бөгөөд тэдэнтэй холбогдох боломжтой болсон. Энэ туннелийг шинэчлэлтүүдийг хүргэхэд ашигласан.
Онолын хувьд ижил хонгилыг хянахад ашиглаж болох боловч ийм холболт нь энгийн түлхэлтээс илүү төвөгтэй, найдвартай биш байв.
Үүлэн нөөц
Эцэст нь хэлэхэд, бид Кластерт хяналт тавих нь аль болох хялбар байхын тулд бид Kubernetes-ийг ашигладаг тул үүлэн үйлчилгээ болон мэдээллийн санг хянах шаардлагатай. Хамгийн тохиромжтой нь ашиглах , Байршуулахын тулд бид ихэнх тохиолдолд үүнийг ашигладаг. Мэдээжийн хэрэг, үүлийг хянахын тулд та скутертэй ижил шийдлүүдийг ашиглах хэрэгтэй.
Өгсөн
Өө, бид тайлбарыг цэгцэлсэн бололтой, эцэст нь бидэнд хэрэгтэй зүйлсийн жагсаалтыг гаргацгаая:
- Хөгжүүлэлтийн явцад хяналт тавих шаардлагатай байдаг тул хурдан шийдэл
- Эзлэхүүн/тоо хэмжээ – олон хэмжүүр шаардлагатай
- Лог цуглуулах шаардлагатай
- Найдвартай байдал - өгөгдөл нь амжилтанд хүрэхэд чухал ач холбогдолтой
- Та татах загварыг ашиглах боломжгүй - танд түлхэх хэрэгтэй
- Бидэнд зөвхөн техник хангамж төдийгүй үүлэнд нэгдсэн хяналт хэрэгтэй
Эцсийн зураг иймэрхүү харагдаж байв
Стекийн сонголт
Тиймээс бид хяналтын стекийг сонгох асуудалтай тулгарсан.
Юуны өмнө бид бидний бүх шаардлагыг нэгэн зэрэг хангах, гэхдээ бидний хэрэгцээнд нийцүүлэн ашиглахад хангалттай уян хатан байх хамгийн бүрэн гүйцэд шийдлийг хайж байсан. Гэсэн хэдий ч бидэнд техник хангамж, архитектур, эцсийн хугацаанаас хамаарч олон хязгаарлалт тавьсан.
гэх мэт бүрэн эрхт системээс эхлээд маш олон төрлийн хяналтын шийдлүүд байдаг , буюу Мөн флотын менежментэд зориулсан бэлэн шийдлүүдээр төгсдөг.
Эхэндээ, сүүлийнх нь бидний хувьд хамгийн тохиромжтой шийдэл мэт санагдаж байсан ч зарим нь бүрэн хяналтгүй, зарим нь үнэгүй хувилбаруудын боломжуудыг эрс хязгаарласан, зарим нь бидний "хүсэлтийг" хангаагүй эсвэл бидний хувилбарт нийцүүлэх хангалттай уян хатан биш байсан. Зарим нь зүгээр л хуучирсан.
Хэд хэдэн ижил төстэй шийдлүүдэд дүн шинжилгээ хийсний дараа бид ижил төстэй стекийг өөрсдөө угсрах нь илүү хялбар бөгөөд хурдан байх болно гэсэн дүгнэлтэд хүрсэн. Тийм ээ, энэ нь бүрэн бэлэн болсон флотын удирдлагын платформыг ашиглахаас арай илүү төвөгтэй байх болно, гэхдээ бид буулт хийх шаардлагагүй болно.
Бараг мэдээжийн хэрэг, асар их хэмжээний шийдлүүдийн дунд бидэнд бүрэн тохирох бэлэн шийдэл байдаг, гэхдээ бидний хувьд тодорхой стекийг өөрсдөө угсарч, үүнийг "өөрсдөдөө" тохируулах нь илүү хурдан байсан. бэлэн бүтээгдэхүүнийг турших.
Энэ бүхний хувьд бид бүхэл бүтэн хяналтын платформыг өөрсдөө угсрах гэж оролдсонгүй, харин зөвхөн уян хатан тохируулах чадвартай, хамгийн ажиллагаатай "бэлэн" стекүүдийг хайж байсан.
(B) ELK?
Үнэн хэрэгтээ авч үзсэн анхны шийдэл бол бидний сайн мэдэх ELK стек байв.
Уг нь бүх зүйл Beats-ээс эхэлдэг учраас BELK гэж нэрлэх хэрэгтэй -
Мэдээжийн хэрэг, ELK бол мониторингийн салбарт хамгийн алдартай, хүчирхэг шийдлүүдийн нэг бөгөөд үүнээс ч илүү бүртгэл цуглуулах, боловсруулахад зориулагдсан юм.
Бид ELK-ийг лог цуглуулах, мөн Prometheus-аас авсан хэмжигдэхүүнүүдийг удаан хугацаагаар хадгалахад ашиглахыг зорьсон.
Дүрслэхийн тулд та Grafan ашиглаж болно.
Үнэн хэрэгтээ, шинэ ELK стек нь хэмжүүрүүдийг бие даан цуглуулах боломжтой (metricbeat), Кибана мөн тэдгээрийг харуулах боломжтой.
Гэсэн хэдий ч ELK нь анх логуудаас үүссэн бөгөөд өнөөг хүртэл хэмжүүрүүдийн үйл ажиллагаа нь хэд хэдэн ноцтой сул талуудтай байдаг:
- Прометейгээс хамаагүй удаан
- Прометейг бодвол хамаагүй цөөн газарт нэгтгэдэг
- Тэдэнд сэрэмжлүүлэг тохируулах нь хэцүү байдаг
- Метрик нь маш их зай эзэлдэг
- Кибан дахь хэмжүүр бүхий хяналтын самбарыг тохируулах нь Графанаас хамаагүй илүү төвөгтэй юм
Ерөнхийдөө ELK-ийн хэмжүүрүүд нь хүнд бөгөөд бусад шийдлүүдийнх шиг тийм ч тохиромжтой биш бөгөөд одоо Prometheus-аас илүү олон зүйл байдаг: TSDB, Victoria Metrics, Cortex гэх мэт. Мэдээжийн хэрэг, би нэн даруй бүрэн хэмжээний бүгдийг нэг дор шийдмээр байна, гэхдээ metricbeat-ийн хувьд хэтэрхий олон буулт байсан.
Мөн ELK стек нь өөрөө хэд хэдэн хэцүү мөчтэй байдаг:
- Хэрэв та нэлээд их хэмжээний мэдээлэл цуглуулвал энэ нь хүнд, заримдаа бүр маш хүнд байдаг
- Та үүнийг "хэрхэн хоол хийхээ мэдэх" хэрэгтэй - үүнийг томруулах хэрэгтэй, гэхдээ үүнийг хийх нь тийм ч хялбар биш юм.
- Үнэгүй хувилбарыг хассан - үнэ төлбөргүй хувилбар нь ердийн анхааруулгагүй бөгөөд сонгох үед баталгаажуулалт байхгүй байсан.
Сүүлийн үед сүүлийн цэг нь илүү дээр болсон гэж хэлэх ёстой (гэрчлэлийг оруулаад) үнийн загвар нь өөрөө өөрчлөгдөж эхлэв.
Гэхдээ бид энэ шийдлийг ашиглах гэж байх үед ямар ч анхааруулга байгаагүй.
Магадгүй бид ElastAlert эсвэл бусад олон нийтийн шийдлүүдийг ашиглан ямар нэгэн зүйл бүтээхийг оролдож болох байсан ч бид өөр хувилбаруудыг авч үзэхээр шийдсэн.
Локи - Графана - Прометей
Одоогийн байдлаар сайн шийдэл бол хэмжүүрийн үйлчилгээ үзүүлэгчийн хувьд зөвхөн Prometheus дээр суурилсан хяналтын стек, бүртгэлд зориулсан Loki, дүрслэхийн тулд та ижил Grafana ашиглаж болно.
Харамсалтай нь төслийн борлуулалтын туршилт эхлэх үед (19 оны 0.3-р сараас 0.4-р сар) Локи XNUMX-XNUMX бета хувилбарт хэвээр байсан бөгөөд хөгжүүлэлт эхлэх үед үүнийг үйлдвэрлэлийн шийдэл гэж үзэх боломжгүй байв. бүх.
Би Loki-г ноцтой төслүүдэд ашиглаж байсан туршлагагүй ч Promtail (лог цуглуулах агент) нь нүцгэн металл болон кубернетийн хонхорцогт хоёуланд нь маш сайн ажилладаг гэж би хэлж чадна.
ШАЛГАХ
Магадгүй ELK стекийн хамгийн тохиромжтой (цорын ганц?) бүрэн боломжит хувилбарыг одоо зөвхөн TICK стек гэж нэрлэх боломжтой - Telegraf, InfluxDB, Chronograf, Kapacitor.
Би доорх бүх бүрэлдэхүүн хэсгүүдийг илүү дэлгэрэнгүй тайлбарлах болно, гэхдээ ерөнхий санаа нь:
- Telegraf - хэмжүүр цуглуулах агент
- InfluxDB - хэмжүүрийн мэдээллийн сан
- Kapacitor - анхааруулга өгөх бодит цагийн хэмжүүр процессор
- Хронограф - дүрслэх зориулалттай вэб самбар
InfluxDB, Kapacitor болон Chronograf-ийн хувьд бидний ашиглаж байсан албан ёсны жолооны графикууд байдаг.
Influx 2.0 (бета) хувилбарын хамгийн сүүлийн хувилбарт Kapacitor болон Chronograf нь InfluxDB-ийн нэг хэсэг болж, тусдаа байхаа больсон гэдгийг тэмдэглэх нь зүйтэй.
Телеграф
төрийн машин дээр хэмжүүр цуглуулах маш хөнгөн агент юм.
Тэр бүх зүйлийг асар их хэмжээгээр хянаж чаддаг нь
сервер .
Энэ нь хэд хэдэн гайхалтай давуу талуудтай:
- Хурдан бөгөөд хөнгөн (Go хэл дээр бичигдсэн)
- Хамгийн бага нөөцийг иддэг
- Анхдагчаар хэмжигдэхүүнийг түлхэх
- Шаардлагатай бүх хэмжигдэхүүнийг цуглуулдаг
- Ямар ч тохиргоогүйгээр системийн хэмжүүрүүд
- Мэдрэгчийн мэдээлэл гэх мэт техник хангамжийн хэмжүүрүүд
- Өөрийнхөө хэмжүүрүүдийг нэмэхэд маш хялбар байдаг
- Маш олон залгаасууд гарч ирсэн
- Лог цуглуулдаг
Түлхэх хэмжүүр нь бидэнд хэрэгтэй байсан тул бусад бүх давуу талууд нь тааламжтай нэмэлтүүдээс илүү байсан.
Бүртгэлийг бүртгэх нэмэлт хэрэгслийг холбох шаардлагагүй тул агент өөрөө лог цуглуулах нь маш тохиромжтой.
Influx нь логуудтай ажиллахад хамгийн тохиромжтой туршлагыг санал болгодог .
Telegraf бол ерөнхийдөө ICK стекийн үлдсэн хэсгийг ашигладаггүй байсан ч хэмжүүр цуглуулах гайхалтай агент юм.
Энэ нь бараг хаана ч хэмжигдэхүүн бичиж чаддаг тул олон хүмүүс үүнийг хялбар болгох үүднээс ELK болон бусад янз бүрийн цагийн цуврал мэдээллийн сангуудтай холбодог.
InfluxDB
InfluxDB нь TICK стекийн гол цөм, тухайлбал хэмжигдэхүүнд зориулсан цагийн цуврал мэдээллийн сан юм.
Хэмжилтээс гадна Influx нь логуудыг хадгалах боломжтой боловч үндсэндээ логууд нь ижил хэмжүүрүүд боловч ердийн тоон үзүүлэлтүүдийн оронд үндсэн функцийг логийн текстийн шугамаар гүйцэтгэдэг.
InfluxDB нь Go дээр бичигдсэн бөгөөд манай (хамгийн хүчирхэг биш) кластер дээрх ELK-тэй харьцуулахад хамаагүй хурдан ажилладаг юм шиг санагддаг.
Influx-ийн гайхалтай давуу талуудын нэг нь бидний маш идэвхтэй ашигладаг өгөгдлийн асуулгад маш тохиромжтой, баялаг API-г агуулсан байх болно.
Сул талууд - $$$ эсвэл томруулах уу?
TICK стек нь бидний олж мэдсэн цорын ганц сул талтай эрхэм ээ. Өшөө илүү.
Төлбөртэй хувилбарт үнэгүй хувилбарт байхгүй юу байдаг вэ?
Бидний ойлгож байгаагаар TICK стекийн төлбөртэй хувилбар болон үнэ төлбөргүй хувилбар хоёрын цорын ганц ялгаа нь масштаблах чадвар юм.
Тухайлбал, та зөвхөн өндөр хүртээмжтэй кластер босгох боломжтой .
Хэрэв та бүрэн хэмжээний HA авахыг хүсч байвал мөнгө төлөх эсвэл таяг ашиглах хэрэгтэй. Олон нийтийн хэд хэдэн шийдэл байдаг - жишээлбэл чадварлаг шийдэл мэт харагддаг, гэхдээ энэ нь үйлдвэрлэлд тохиромжгүй, түүнчлэн бичсэн байна
- NATS-ээр дамжуулан өгөгдөл дамжуулах энгийн шийдэл (үүнийг бас масштаблах шаардлагатай болно, гэхдээ үүнийг шийдэж болно).
Харамсалтай нь, хоёулаа орхигдсон юм шиг байна - шинэ амлалт байхгүй, асуудал бол олон зүйл өөр байх Influx 2.0-ийн шинэ хувилбар удахгүй гарах гэж байна гэж би бодож байна (тухай мэдээлэл байхгүй байна) одоохондоо масштабтай байна).
Албан ёсоор үнэгүй хувилбар байдаг - үнэндээ энэ бол анхдагч HA, гэхдээ зөвхөн тэнцвэржүүлэх замаар,
учир нь бүх өгөгдөл нь ачаалал тэнцвэржүүлэгчийн ард байгаа бүх InfluxDB-д бичигдэх болно.
Түүнд зарим нь бий цэгүүдийг дарж бичихтэй холбоотой болзошгүй асуудлууд, хэмжигдэхүүнүүдийн суурийг урьдчилан бий болгох хэрэгцээ гэх мэт
(энэ нь InfluxDB-тэй хэвийн ажиллах үед автоматаар тохиолддог).
Түүнээс гадна , энэ нь танд хэрэггүй байж болох давхардсан хэмжигдэхүүнүүдэд (боловсруулах болон хадгалах) нэмэлт зардал гэсэн үг боловч тэдгээрийг салгах арга байхгүй.
Виктория хэмжигдэхүүн?
Үүний үр дүнд бид төлбөртэй масштабаас бусад бүх зүйлд TICK стект бүрэн сэтгэл хангалуун байсан ч үлдсэн T_CK бүрэлдэхүүн хэсгүүдийг орхиж, InfluxDB мэдээллийн санг орлож чадах үнэгүй шийдэл байгаа эсэхийг харахаар шийдсэн.
Олон тооны цагийн цуврал мэдээллийн сан байдаг боловч хамгийн ирээдүйтэй нь Victoria Metrics бөгөөд энэ нь хэд хэдэн давуу талтай:
- Наад зах нь үр дүнгийн дагуу хурдан бөгөөд хялбар
- Кластер хувилбар байгаа бөгөөд одоо ч гэсэн сайн тоймууд байдаг
- Тэр тасалж чадна
- InfluxDB протоколыг дэмждэг
Бид Виктория дээр суурилсан бүрэн захиалгат стекийг бүтээх бодолгүй байсан бөгөөд гол найдвар нь үүнийг InfluxDB-ийн орлуулах хэрэгсэл болгон ашиглах явдал байв.
Харамсалтай нь, InfluxDB протоколыг дэмждэг хэдий ч энэ нь боломжгүй, энэ нь зөвхөн хэмжүүр бичихэд зориулагдсан - зөвхөн Prometheus API нь "гадна" байдаг бөгөөд энэ нь Chronograf-ийг тохируулах боломжгүй гэсэн үг юм.
Түүнээс гадна хэмжүүрүүдэд зөвхөн тоон утгуудыг дэмждэг (бид захиалгат хэмжигдэхүүнүүдэд мөрийн утгуудыг ашигласан - энэ талаар дэлгэрэнгүй ).
Мэдээжийн хэрэг, ижил шалтгааны улмаас VM нь Influx шиг бүртгэлийг хадгалах боломжгүй юм.
Түүнчлэн, оновчтой шийдлийг хайж байх үед Виктория хэмжигдэхүүн нь тийм ч алдартай биш байсан, баримт бичиг нь хамаагүй бага, үйл ажиллагаа нь сул байсан гэдгийг тэмдэглэх нь зүйтэй.
(Кластерын хувилбар болон хуваалтын талаархи дэлгэрэнгүй тайлбарыг би санахгүй байна).
Үндсэн сонголт
Үүний үр дүнд бид нисгэгчдийн хувьд ганц InfluxDB зангилаагаар хязгаарлагдахаар шийдсэн.
Ийм сонголт хийх хэд хэдэн үндсэн шалтгаан байсан:
- Бидэнд TICK стекийн бүх функц үнэхээр таалагдсан
- Бид үүнийг аль хэдийн байрлуулж чадсан бөгөөд энэ нь маш сайн ажилласан
- Хугацаа дуусч байгаа бөгөөд бусад сонголтыг туршиж үзэхэд тийм ч их цаг үлдсэнгүй.
- Бид ийм их ачааллыг хүлээж байсангүй
Туршилтын эхний үе шатанд олон скутер байхгүй байсан бөгөөд хөгжүүлэлтийн явцад туршилт хийхэд гүйцэтгэлийн ямар ч асуудал илрээгүй.
Тиймээс бид энэ төслийн хувьд нэг хүн амын шилжилт хөдөлгөөний зангилаа нь томруулах шаардлагагүйгээр хангалттай байх болно гэж шийдсэн (дүгнэлтийг төгсгөлд нь үзнэ үү).
Бид стек болон суурийн талаар шийдсэн - одоо TICK стекийн үлдсэн бүрэлдэхүүн хэсгүүдийн талаар.
Конденсатор
Kapacitor нь TICK стекийн нэг хэсэг бөгөөд мэдээллийн санд орж буй хэмжигдэхүүнийг бодит цаг хугацаанд хянаж, дүрэмд үндэслэн янз бүрийн үйлдэл хийх боломжтой үйлчилгээ юм.
Ерөнхийдөө энэ нь хэвийн бус байдлыг хянах, машин сурах хэрэгсэл болгон байрлуулсан (эдгээр функцүүд эрэлт хэрэгцээтэй байгаа гэдэгт би итгэлгүй байна), гэхдээ үүнийг ашиглах хамгийн түгээмэл тохиолдол бол сэрэмжлүүлэг юм.
Бид үүнийг мэдэгдлийн хувьд ийм байдлаар ашигласан. Бид тодорхой скутер офлайн болсон үед Slack дохиог тохируулсан бөгөөд ухаалаг цэнэглэгч болон дэд бүтцийн чухал бүрэлдэхүүн хэсгүүдэд мөн адил зүйл хийсэн.
Энэ нь асуудалд хурдан хариу өгөх, мөн бүх зүйл хэвийн болсон тухай мэдэгдлийг хүлээн авах боломжтой болсон.
Энгийн жишээ: бидний "хайрцаг"-ыг тэжээх нэмэлт зай эвдэрсэн эсвэл ямар нэг шалтгааны улмаас цэнэггүй болсон; шинийг суулгаснаар хэсэг хугацааны дараа бид скутерийн ажиллагаа сэргэсэн тухай мэдэгдэл хүлээн авах болно.
Influx 2.0 конденсатор нь DB-ийн нэг хэсэг болсон
Хронограф
Би мониторинг хийх олон янзын UI шийдлүүдийг харсан боловч функциональ болон UX-ийн хувьд Chronograf-тай юу ч харьцуулагдахгүй гэж би хэлж чадна.
Бид хачирхалтай нь Графаныг вэб интерфейс болгон TICK стекийг ашиглаж эхэлсэн.
Би түүний функцийг тайлбарлахгүй, хүн бүр ямар ч зүйлийг тохируулах өргөн боломжийг мэддэг.
Гэсэн хэдий ч Grafana нь бүрэн бүх нийтийн хэрэгсэл хэвээр байгаа бол Chronograf нь ихэвчлэн Influx-д зориулагдсан байдаг.
Мэдээжийн хэрэг, үүний ачаар Chronograf нь илүү ухаалаг, тохиромжтой функцийг төлж чаддаг.
Магадгүй Chronograf-тэй ажиллах гол тав тухтай тал нь Explore-ээр дамжуулан InfluxDB-ийнхаа дотор талыг харах боломжтой юм.
Графана нь бараг ижил функцтэй юм шиг санагдаж байна, гэхдээ бодит байдал дээр Chronograf дээр хяналтын самбарыг хулганын хэд хэдэн товшилтоор хийж болно (үүнтэй зэрэгцэн тэнд байгаа дүрслэлийг харна), харин Графана дээр та эрт орой хэзээ нэгэн цагт үүнийг хийх болно. JSON тохиргоог засварлах (мэдээж Chronograf нь таны гараар тохируулсан зураасуудыг байршуулж, шаардлагатай бол JSON болгон засварлахыг зөвшөөрдөг - гэхдээ би тэдгээрийг UI дээр үүсгэсний дараа тэдэнд хэзээ ч хүрч байгаагүй).
Кибана нь хяналтын самбар, тэдгээрийн хяналтыг бий болгох илүү баялаг чадвартай боловч ийм үйлдлийн UX нь маш нарийн төвөгтэй байдаг.
Тохиромжтой хяналтын самбар үүсгэхийн тулд сайн ойлголттой байх шаардлагатай. Хэдийгээр Chronograf хяналтын самбарын ажиллагаа бага боловч тэдгээрийг хийх, тохируулах нь илүү хялбар байдаг.
Хяналтын самбарууд нь харагдахуйц сайхан хэв маягаас гадна Графана эсвэл Кибана дахь хяналтын самбаруудаас ялгаатай биш юм.
Асуулгын цонх дараах байдалтай байна.
InfluxDB мэдээллийн баазын талбаруудын төрлийг мэдэхийн тулд хронограф өөрөө заримдаа Query бичих эсвэл дундаж гэх мэт зөв нэгтгэх функцийг сонгоход автоматаар тусалдаг гэдгийг анхаарах нь чухал юм.
Мэдээжийн хэрэг, Chronograf нь бүртгэлийг үзэхэд аль болох тохиромжтой. Энэ нь дараах байдалтай харагдаж байна.
Анхдагч байдлаар, хүн амын шилжилт хөдөлгөөний бүртгэлүүд нь syslog-г ашиглахад тохирсон байдаг тул тэдгээр нь чухал параметртэй байдаг - ноцтой байдал.
Дээд талд байгаа график нь ялангуяа ашигтай бөгөөд үүн дээр та гарсан алдааг харж, өнгө нь илүү ноцтой байгаа эсэхийг шууд харуулах болно.
Бид хэд хэдэн удаа ийм байдлаар чухал алдаануудыг илрүүлж, сүүлийн долоо хоногийн бүртгэлийг үзэж, улаан өнгийн өргөлтийг олж харсан.
Мэдээжийн хэрэг, ийм алдааны талаар сэрэмжлүүлэг тохируулах нь хамгийн тохиромжтой, учир нь бидэнд үүнийг хийх бүх зүйл байсан.
Бид үүнийг хэсэг хугацаанд асаасан боловч нисгэгчийг бэлтгэх явцад Slack сувгийг "спам" илгээсэн маш олон алдаа (LTE сүлжээ байхгүй гэх мэт системийн алдаанууд) гарч ирсэн. дэндүү их, ямар ч асуудал үүсгэхгүй.маш их ашиг тус.
Зөв шийдэл бол эдгээр төрлийн ихэнх алдааг засах, тэдгээрийн ноцтой байдлыг тохируулах, зөвхөн дараа нь сэрэмжлүүлэг өгөх явдал юм.
Ингэснээр зөвхөн шинэ эсвэл чухал алдаануудыг Slack-д нийтлэх болно. Хугацаа хатуу байсан тул ийм тохируулга хийхэд хангалттай хугацаа байсангүй.
Гэрчлэлт
Chronograf нь OAuth болон OIDC-г баталгаажуулалт болгон дэмждэг гэдгийг дурдах нь зүйтэй.
Энэ нь маш тохиромжтой, учир нь энэ нь танд үүнийг сервертээ хялбархан холбож, бүрэн SSO үүсгэх боломжийг олгодог.
Манай тохиолдолд сервер байсан — Энэ нь хяналтанд холбогдоход ашиглагдаж байсан боловч ижил серверийг скутер болон арын хэсэгт хүсэлтийг баталгаажуулахад ашигладаг байсан.
"Админ"
Миний тайлбарлах сүүлчийн бүрэлдэхүүн хэсэг бол Vue-д бидний өөрөө бичсэн "админ самбар" юм.
Үндсэндээ энэ нь манай мэдээллийн сан, микро үйлчилгээ болон InfluxDB-ийн хэмжүүрийн өгөгдлийг нэгэн зэрэг харуулдаг скутерын мэдээллийг харуулдаг бие даасан үйлчилгээ юм.
Нэмж дурдахад, яаралтай дахин ачаалах эсвэл туслах багийн түгжээг алсаас нээх гэх мэт олон захиргааны функцийг тэнд шилжүүлсэн.
Мөн газрын зураг байсан. Бид Chronograf-ийн оронд Графана-аас эхэлсэн гэж би аль хэдийн дурдсан - учир нь Grafana-д зориулж скутеруудын координатыг үзэх боломжтой плагинуудын газрын зураг байдаг. Харамсалтай нь, Grafana-д зориулсан газрын зургийн виджетүүдийн боломжууд маш хязгаарлагдмал тул координатыг харахаас гадна харуулахын тулд хэдхэн хоногийн дотор газрын зургийн тусламжтайгаар өөрийн вэб програмыг бичих нь илүү хялбар болсон. скутерийн явсан маршрут, газрын зураг дээрх өгөгдлийг шүүх боломжтой байх гэх мэт (бидний энгийн хяналтын самбарт тохируулж чадаагүй бүх функц).
Influx-ийн аль хэдийн дурдсан давуу талуудын нэг бол өөрийн хэмжүүрийг хялбархан үүсгэх чадвар юм.
Энэ нь үүнийг маш олон янзын хувилбарт ашиглах боломжийг олгодог.
Бид тэнд бүх хэрэгтэй мэдээллийг бичихийг оролдсон: батерейны цэнэг, түгжээний байдал, мэдрэгчийн гүйцэтгэл, bluetooth, GPS болон бусад олон эрүүл мэндийн үзлэг.
Бид энэ бүгдийг админ самбар дээр харуулав.
Мэдээжийн хэрэг, бидний хувьд хамгийн чухал шалгуур бол скутерын ажиллах нөхцөл байсан - үнэндээ Influx үүнийг өөрөө шалгаж, "Зангилаа" хэсэгт "ногоон гэрлээр" харуулдаг.
Үүнийг функцээр гүйцэтгэдэг - бид үүнийг хайрцгийнхаа гүйцэтгэлийг ойлгоход ашиглаж, ижил дохиог Slack руу илгээсэн.
Дашрамд хэлэхэд бид скутерүүдийг Симпсоны баатруудын нэрээр нэрлэсэн - тэднийг бие биенээсээ ялгахад маш тохиромжтой байсан.
Ерөнхийдөө энэ нь илүү хөгжилтэй байсан. “Залуус аа, Смитерс үхлээ!” гэх мэт хэллэгүүд байнга сонсогддог байв.
Мөр хэмжигдэхүүн
InfluxDB нь Victoria Metrics-ийн нэгэн адил зөвхөн тоон утгыг хадгалах боломжийг танд олгох нь чухал юм.
Энэ нь тийм ч чухал биш юм шиг санагдаж байна - эцэст нь бүртгэлээс гадна ямар ч хэмжигдэхүүнийг тоо хэлбэрээр хадгалах боломжтой (мэдэгдэж буй мужуудын зураглалыг нэмнэ үү - нэг төрлийн тоолол)?
Манай тохиолдолд мөрийн хэмжүүрүүд маш хэрэгтэй байсан ядаж нэг хувилбар байсан.
Манай "ухаалаг цэнэглэгч" нийлүүлэгч нь гуравдагч этгээд байсан тул бид боловсруулах үйл явц, эдгээр цэнэглэгчээр хангаж чадах мэдээллийг хянах боломжгүй болсон.
Үүний үр дүнд цэнэглэх API нь тийм ч тохиромжтой биш байсан ч гол асуудал нь бид тэдний төлөв байдлыг үргэлж ойлгож чаддаггүй явдал байв.
Эндээс "Influx" аврахаар иржээ. Бид зүгээр л бидэнд ирсэн мөрийн статусыг InfluxDB мэдээллийн сангийн талбарт өөрчлөлтгүйгээр бичсэн.
Хэсэг хугацааны туршид зөвхөн "онлайн" ба "офлайн" гэх мэт утгууд л ирсэн бөгөөд үүний үндсэн дээр манай админ самбар дээр мэдээлэл гарч, Slack руу мэдэгдэл илгээсэн. Гэсэн хэдий ч зарим үед "тасарсан" гэх мэт үнэ цэнэ тэнд гарч эхэлсэн.
Хожим нь тодорхой болсон тул цэнэглэгч тодорхой тооны оролдлогын дараа сервертэй холбогдож чадахгүй бол холболт тасарсаны дараа энэ статусыг нэг удаа илгээсэн.
Тиймээс, хэрэв бид зөвхөн тогтмол утгуудын багцыг ашигласан бол эдгээр өөрчлөлтүүдийг програм хангамжийн зөв цагт олж харахгүй байж магадгүй юм.
Ерөнхийдөө мөрийн хэмжигдэхүүн нь ашиглахад илүү их боломжийг олгодог бөгөөд та тэдгээрт бараг бүх мэдээллийг бичиж болно. Мэдээжийн хэрэг та энэ хэрэгслийг болгоомжтой ашиглах хэрэгтэй.
Ердийн хэмжүүрээс гадна бид InfluxDB дээр GPS-ийн байршлын мэдээллийг бүртгэсэн. Энэ нь манай админ самбар дээрх скутеруудын байршлыг хянахад маш хэрэгтэй байсан.
Үнэндээ бид яг одоо хаана, ямар скутер хэрэгтэй байгааг үргэлж мэддэг байсан.
Энэ нь биднийг скутер хайж байх үед маш их хэрэг болсон (дүгнэлтийг төгсгөлд нь үзнэ үү).
Дэд бүтцийн мониторинг
Скутеруудаас гадна бид бүхэл бүтэн (нэлээд өргөн хүрээтэй) дэд бүтцээ хянах шаардлагатай болсон.
Маш ерөнхий архитектур нь иймэрхүү харагдаж байв.
Хэрэв бид цэвэр хяналтын стекийг тодруулбал дараах байдалтай харагдана.
Бидний үүлэн дотор шалгахыг хүсэж байгаа зүйл бол:
- Мэдээллийн сан
- түлхүүрийн нөмрөг
- Бичил үйлчилгээ
Манай бүх үүлэн үйлчилгээ Кубернетес хотод байрладаг тул түүний төлөв байдлын талаар мэдээлэл цуглуулах нь сайхан байх болно.
Аз болоход Telegraf нь Kubernetes кластерын төлөв байдлын талаар асар олон тооны хэмжигдэхүүнийг цуглуулж чаддаг бөгөөд Chronograf нь нэн даруй үзэсгэлэнтэй хяналтын самбаруудыг санал болгодог.
Бид голчлон pods-ийн гүйцэтгэл, санах ойн зарцуулалтыг хянаж байсан. Унах тохиолдолд Slack-д дохио өгнө.
Kubernetes дахь pods хянах хоёр арга байдаг: DaemonSet болон Sidecar.
Хоёр аргыг хоёуланг нь нарийвчлан тайлбарласан болно .
Бид Telegraf Sidecar ашигласан бөгөөд хэмжүүрээс гадна под лог цуглуулсан.
Манай тохиолдолд гуалинтай тааралдсан. Telegraf нь Docker API-аас лог татах боломжтой хэдий ч бид эцсийн төхөөрөмжүүдтэйгээ нэгдсэн бүртгэлийн цуглуулгатай байхыг хүсч, үүнд зориулж контейнерт зориулсан систем тохируулсан. Магадгүй энэ шийдэл нь үзэсгэлэнтэй биш байсан ч түүний ажлын талаар ямар ч гомдол гараагүй бөгөөд логуудыг Chronograf дээр сайн харуулсан.
Хяналтын хяналт???
Эцэст нь мониторингийн системийн олон жилийн асуулт гарч ирсэн боловч азаар эсвэл харамсалтай нь бидэнд үүнд хангалттай цаг байсангүй.
Хэдийгээр Telegraf нь өөрийн хэмжигдэхүүнийг хялбархан илгээж эсвэл InfluxDB мэдээллийн сангаас ижил Influx эсвэл өөр газар илгээх боломжтой.
үр дүн нь
Туршилтын үр дүнгээс бид ямар дүгнэлт хийсэн бэ?
Хэрхэн хяналт тавих вэ?
Юуны өмнө, TICK стек нь бидний хүлээлтийг бүрэн хангаж, бидний бодож байснаас ч илүү боломжийг олгосон.
Бидэнд хэрэгтэй бүх функцууд байсан. Түүнтэй хийсэн бүх зүйл маань асуудалгүй ажилласан.
Бүтээмж
Үнэгүй хувилбарт TICK стектэй холбоотой гол асуудал бол масштаблах чадваргүй байх явдал юм. Энэ нь бидний хувьд асуудал биш байсан.
Бид яг ачааллын мэдээлэл/тоо цуглуулаагүй ч нэг дор 30 орчим скутерээс мэдээлэл цуглуулсан.
Тэд тус бүр нь гуч гаруй хэмжүүр цуглуулсан. Үүний зэрэгцээ төхөөрөмжүүдийн бүртгэлийг цуглуулсан. Мэдээлэл цуглуулах, илгээх нь 10 секунд тутамд хийгддэг.
Туршилтын долоо хоног хагасын дараа "хүүхэд насны бэрхшээл" -ийн дийлэнх хэсгийг засч, хамгийн чухал асуудлууд аль хэдийн шийдэгдсэн үед бид сервер рүү өгөгдөл илгээх давтамжийг багасгах шаардлагатай болсон гэдгийг тэмдэглэх нь зүйтэй. 30 секунд. Манай LTE SIM картуудын урсгал хурдан алга болж эхэлсэн тул энэ нь зайлшгүй шаардлагатай болсон.
Траффикийн дийлэнх хэсгийг логууд зарцуулсан бөгөөд хэмжүүрүүд өөрсдөө 10 секундын завсарлагатай байсан ч бараг дэмий үрээгүй.
Үүний үр дүнд хэсэг хугацааны дараа бид төхөөрөмж дээрх лог цуглуулах ажлыг бүрэн идэвхгүй болгосон, учир нь байнгын цуглуулгагүйгээр тодорхой асуудлууд аль хэдийн тодорхой байсан.
Зарим тохиолдолд бүртгэлийг үзэх шаардлагатай хэвээр байсан бол бид зүгээр л VPN-ээр WireGuard-ээр холбогддог.
Тусдаа орчин бүр бие биенээсээ тусгаарлагдсан бөгөөд дээр дурдсан ачаалал нь зөвхөн үйлдвэрлэлийн орчинд хамааралтай гэдгийг би нэмж хэлье.
Хөгжүүлэлтийн орчинд бид 10 секунд тутамд мэдээлэл цуглуулдаг тусдаа InfluxDB инстанцыг үүсгэсэн бөгөөд гүйцэтгэлийн асуудалтай тулгараагүй.
TICK - жижиг болон дунд төслүүдэд тохиромжтой
Эдгээр мэдээлэлд үндэслэн би TICK стек нь харьцангуй жижиг төслүүд эсвэл ямар ч өндөр ачаалал хүлээхгүй төслүүдэд тохиромжтой гэж дүгнэж байна.
Хэрэв танд мянга мянган pods эсвэл хэдэн зуун машин байхгүй бол нэг InfluxDB жишээ ч гэсэн ачааллыг сайн даах болно.
Зарим тохиолдолд та Influx Relay-ийг өндөр хүртээмжтэй энгийн шийдэл болгон ашиглахад сэтгэл хангалуун байж болно.
Мэдээжийн хэрэг, "босоо" масштабыг тохируулах, өөр өөр төрлийн хэмжигдэхүүнд өөр өөр серверүүдийг хуваарилахад хэн ч саад болохгүй.
Хэрэв та хяналтын үйлчилгээнд хүлээгдэж буй ачааллын талаар эргэлзэж байгаа эсвэл маш "хүнд" архитектуртай байх нь баталгаатай бол би TICK стекийн үнэгүй хувилбарыг ашиглахыг зөвлөхгүй.
Мэдээжийн хэрэг, энгийн шийдэл бол худалдан авах явдал юм - гэхдээ би өөрөө нарийн ширийн зүйлийг сайн мэдэхгүй тул энд ямар нэгэн байдлаар тайлбар хийж чадахгүй. Үүнээс гадна энэ нь маш үнэтэй бөгөөд жижиг компаниудад тохиромжгүй юм.
Энэ тохиолдолд өнөөдөр би Виктория хэмжигдэхүүн болон Локи ашиглан бүртгэлээр дамжуулан хэмжүүр цуглуулахыг зөвлөж байна.
Үнэн, би Loki/Grafana нь бэлэн TICK-ээс хамаагүй бага тохиромжтой (илүү олон талт шинж чанартай тул) гэдгийг би дахин хэлэх болно, гэхдээ тэдгээр нь үнэ төлбөргүй байдаг.
чухал: энд тайлбарласан бүх мэдээлэл нь Influx 1.8 хувилбарт хамааралтай бөгөөд одоогоор Influx 2.0 гарах гэж байна.
Би үүнийг байлдааны нөхцөлд туршиж үзэх боломж гараагүй бөгөөд сайжруулалтын талаар дүгнэлт хийхэд хэцүү байсан ч интерфейс нь мэдээжийн хэрэг илүү сайжирч, архитектурыг хялбаршуулсан (конденсатор, хронографгүйгээр),
загварууд гарч ирэв ("алуурч онцлог" - ). Гэвч харамсалтай нь одоогоор 2-р хувилбарт бидний эхний хувилбарыг сонгосон гол зүйл байхгүй - бүртгэлийн цуглуулга байхгүй байна.
Энэ функц нь Influx 2.0 дээр гарч ирэх боловч бид эцсийн хугацаа, тэр байтугай ойролцоо хугацааг олж чадсангүй.
IoT платформуудыг яаж хийхгүй байх вэ (одоо)
Эцэст нь туршилтыг эхлүүлсний дараа манай стандартад тохирох өөр хувилбар байхгүй тул бид өөрсдөө бүрэн хэмжээний IoT стекийг угсарсан.
Гэсэн хэдий ч саяхан энэ нь Бета хувилбарт гарсан -Бид төслийг хийж эхлэхэд тэр тэнд байгаагүй нь харамсалтай.
Бид өөрсдийн угсарсан Ansible + TICK + WireGuard дээр суурилсан эцсийн үр дүн болон платформд бүрэн сэтгэл хангалуун байна. Гэхдээ өнөөдөр би IoT платформоо өөрөө бүтээх гэж оролдохоосоо өмнө Balena-г сайтар судалж үзэхийг зөвлөж байна.
Эцсийн эцэст энэ нь бидний хийсэн ихэнх зүйлийг хийж чадах бөгөөд OpenBalena нь үнэ төлбөргүй, нээлттэй эх сурвалж юм.
Энэ нь зөвхөн шинэчлэлтийг хэрхэн илгээхээ мэддэг төдийгүй VPN-г аль хэдийн суулгаж, IoT орчинд ашиглахад тохируулсан байдаг.
Саяхан тэд бүр өөрсдийнхөө хувилбарыг гаргасан , энэ нь тэдний экосистемтэй амархан холбогддог.
Хөөе, алга болсон скутер яах вэ?
Тиймээс "Ральф" нэртэй скутер ул мөргүй алга болжээ.
Бид тэр даруй InfluxDB-ийн GPS хэмжүүрийн өгөгдөл бүхий "админ самбар" дээрх газрын зургийг харахаар гүйв.
Хяналтын мэдээллийн ачаар бид скутер өнгөрсөн өдрийн 21:00 цагийн орчимд зогсоолоос гарч, хагас цаг орчим явж, зарим газар руу явж, Германы зарим байшингийн хажууд өглөөний 5 цаг хүртэл зогсож байсныг бид хялбархан тогтоосон.
Өглөөний 5 цагаас хойш хяналтын мэдээлэл ирээгүй - энэ нь нэмэлт батерейг бүрэн цэнэггүй болгосон, эсвэл халдлага үйлдэгч эцэст нь скутерээс ухаалаг төхөөрөмжийг хэрхэн салгахаа олж мэдсэн гэсэн үг юм.
Гэсэн хэдий ч скутер байсан хаяг руу цагдаа дуудсан хэвээр байна. Скутер тэнд байгаагүй.
Гэсэн хэдий ч тэр байшингийн эзэн өчигдөр орой энэ скутерийг оффисоос гэртээ авчирсан тул үүнийг гайхшруулсан.
Нэг мэдэхэд туслах ажилтны нэг нь өглөө эрт ирж скутерээ аваад нэмэлт батарей нь бүрэн цэнэггүй болсныг хараад (явган) зогсоол руу аваачсан байна. Мөн нэмэлт зай чийгийн улмаас амжилтгүй болсон.
Бид өөрсдөө скутер хулгайлсан. Энэ дашрамд хэлэхэд, хэн, яаж цагдаатай холбоотой асуудлыг шийдсэнийг би мэдэхгүй ч хяналт шалгалт маш сайн ажилласан ...
Эх сурвалж: www.habr.com