Бир жыл мурун биз промо-долбоордун пилоттук версиясын ишке киргиздик .
Башында, долбоор Road-To-Barselona деп аталып, кийинчерээк ал Road-To-Berlin (скриншоттордо R2B) болуп калды, аягында ал xRide деп аталды.
Долбоордун негизги идеясы бул болду: борборлоштурулган унаа же скутерди ижарага берүү кызматынын ордуна (биз скутерлер, ака электр мотоциклдери жөнүндө айтып жатабыз, кикскутер/скутер эмес) биз борбордон ажыратылган ижара үчүн аянтча түзгүбүз келди. Биз кабылган кыйынчылыктар жөнүндө .
Башында, долбоор унааларга багытталган, бирок мөөнөттөрү, өндүрүүчүлөр менен өтө узак байланыш жана коопсуздук чектөөлөр зор саны, электр скутерлер пилоттук үчүн тандалып алынган.
Колдонуучу iOS орноткон же Android Телефон тиркемесин колдонуп, колдонуучу өзүнө жаккан скутерге кайрылган. Телефон менен скутер теңтуштар аралык байланыш түзүп, ETH алмашылган жана колдонуучу телефон аркылуу скутерди күйгүзүү менен сапарды баштай алган. Сапар аяктагандан кийин, төлөмдү колдонуучунун телефон капчыгынан Ethereum аркылуу да жүргүзүүгө болот.
Скутерден тышкары, колдонуучу тиркемеде "акылдуу заряддоочу түзүлүштөрдү" көрдү, ага кирип колдонуучу учурдагы батарейканы аз болсо, өзү алмаштыра алат.
Бул биздин учкучубуз өткөн жылдын сентябрь айында Германиянын эки шаарында: Бонн жана Берлинде ишке киргизилген.
Анан бир күнү, Бонндо, таң эрте, биздин колдоо тобубузга (скутерлерди иштөө тартибинде кармоо үчүн сайтта жайгашкан) эскертүү берилди: скутерлердин бири изи жок жоголуп кетти.
Кантип таап, кайра кайтарса болот?
Бул макалада мен бул жөнүндө сүйлөшөм, бирок биринчиден - биз өзүбүздүн IoT платформабызды кантип курганыбыз жана аны кантип көзөмөлдөгөнүбүз жөнүндө.
Эмне жана эмне үчүн мониторинг жүргүзүү керек: мотороллер, инфраструктура, заряддоо станциялары?
Ошентип, биз долбоордо эмнени көзөмөлдөгүбүз келди?
Биринчиден, бул скутерлердин өздөрү - электр скутерлери абдан кымбат, мүмкүн болсо, жетиштүү даярданбай туруп, мындай долбоорду ишке киргизүү мүмкүн эмес, сиз скутерлер жөнүндө мүмкүн болушунча көбүрөөк маалымат топтогуңуз келет: алардын жайгашкан жери, заряддын деңгээли жөнүндө , жана башкалар.
Мындан тышкары, мен өзүбүздүн IT-инфраструктурабыздын абалына мониторинг жүргүзүүнү каалайт элем - маалымат базалары, кызматтар жана алардын иштеши үчүн зарыл болгон нерселердин бардыгы. Ошондой эле "акылдуу заряддагычтардын" абалына, эгер алар бузулуп калса же толук батарейкалары түгөнүп калса, мониторинг жүргүзүү зарыл болгон.
Скутерлер
Биздин скутерлер эмне болгон жана алар жөнүндө эмнени билгибиз келди?
Биринчи жана эң негизгиси - бул GPS координаттары, анткени алардын аркасында алар кайда жана кайда көчүп жатканын түшүнө алабыз.
Андан кийин батареянын заряды турат, анын аркасында скутерлердин заряды аяктап баратканын аныктап, шире сыггычты жөнөтүп же жок дегенде колдонуучуну эскерте алабыз.
Албетте, биздин Аппараттык компоненттер менен эмне болуп жатканын текшерүү керек:
- bluetooth иштейби?
- GPS модулу өзү иштейби?
- Ошондой эле бизде GPS туура эмес координаттарды жөнөтүп, тыгылып калышы мүмкүн болгон көйгөй болгон жана муну скутерде кошумча текшерүүлөр менен гана аныктоого болот,
жана маселени чечүү үчүн мүмкүн болушунча тезирээк колдоону билдириңиз
- Ошондой эле бизде GPS туура эмес координаттарды жөнөтүп, тыгылып калышы мүмкүн болгон көйгөй болгон жана муну скутерде кошумча текшерүүлөр менен гана аныктоого болот,
Акырында: программалык камсыздоону текшерүү, ОС жана процессордон баштап, тармактын жана дисктин жүктөөсүнөн баштап, бизге көбүрөөк мүнөздүү болгон өзүбүздүн модулдарыбызды текшерүүгө чейин (, ).
Hardware
Биздин "темир" бөлүгүбүз кандай болгон?
Эң кыска мөөнөттү жана тез прототиптөө зарылдыгын эске алып, биз ишке ашыруунун жана компоненттерди тандоонун эң оңой вариантын - Raspberry Piди тандап алдык.
Rpi өзүнөн тышкары, бизде ыңгайлаштырылган такта (акыркы чечимди чогултуу процессин тездетүү үчүн Кытайдан өзүбүз иштеп чыгып, буйрутма бергенбиз) жана компоненттердин топтому - реле (скутерди күйгүзүү/өчүрүү үчүн), батареяны заряддоочу, модем, антенналар. Мунун баары атайын “xRide кутучасына” компакттуу пакеттелген.
Ошондой эле белгилеп кетүү керек, бүт кутуча кошумча кубаттуулук банкынан, ал өз кезегинде скутердин негизги аккумуляторунан кубатталган.
Бул мониторингди колдонууга жана сапар аяктагандан кийин да скутерди күйгүзүүгө мүмкүндүк берди, анткени от алдыруу ачкычын "өчүрүү" абалына бургандан кийин дароо негизги батарея өчүрүлгөн.
Docker? Жөнөкөй Linux? жана жайылтуу
Мониторингге кайрылып көрөлү, анда малина - бизде эмне бар?
Компоненттерди физикалык түзүлүштөргө жайылтуу, жаңыртуу жана жеткирүү процессин тездетүү үчүн биз колдонгубуз келген биринчи нерселердин бири Docker болду.
Тилекке каршы, Docker on RPi иштегенине карабастан, көп чыгымга ээ экени, айрыкча энергия керектөө жагынан айкын болду.
"Түпкүлүктүү" OS колдонуудагы айырма анчалык күчтүү болбосо да, зарядды өтө тез жоготуп алуу мүмкүнчүлүгүнөн сак болушубуз үчүн жетиштүү болду.
Экинчи себеп Node.js (sic!) боюнча биздин өнөктөш китепканалардын бири болгон - системанын Go/C/C++ тилинде жазылбаган жалгыз компоненти.
Китепкананын авторлору «эне» тилдердин биринде да жумушчу версиясын берүүгө үлгүрүшкөн эмес.
Түйүндүн өзү аз өндүрүмдүүлүгү бар түзмөктөр үчүн эң элеганттуу чечим эмес, бирок китепкананын өзү ресурстарга абдан муктаж болгон.
Биз кааласак дагы, Dockerди колдонуу биз үчүн өтө эле ашыкча чыгым болорун түшүндүк. Тандоо жергиликтүү OS пайдасына жасалган жана түздөн-түз анын астында иштеген.
OS
Акырында, ОС катары биз кайрадан эң жөнөкөй вариантты тандап, Raspbian (build) колдондук. Debian Пи үчүн).
Биз бардык программаларыбызды Go'до жазабыз, ошондуктан Go'до системабыздагы негизги аппараттык агент модулун да жаздык.
Ал GPS, Bluetooth менен иштөө, зарядды окуу, скутерди күйгүзүү ж.б.у.с. үчүн жооптуу.
Жайгаштыруу
Түзмөктөргө жаңыртууларды жеткирүү механизмин (OTA) ишке ашыруу зарылдыгы жөнүндө суроо дароо пайда болду - биздин агенттин/тиркеменин өзүнө жаңыртуулар да, ОС/микропрограмманын өзүнө да жаңыртуулар (анткени агенттин жаңы версиялары ядронун жаңыртууларын талап кылышы мүмкүн) же система компоненттери, китепканалар ж.б.) .
Рыноктун узак талдоосунан кийин, түзмөккө жаңыртууларды жеткирүү үчүн көптөгөн чечимдер бар экени белгилүү болду.
Салыштырмалуу жөнөкөй, негизинен swupd/SWUpdate/OSTree сыяктуу жаңыртуу/кош жүктөөгө багытталган утилиталардан Мендер жана Балена сыяктуу толук кандуу платформаларга чейин.
Биринчиден, биз акырына чейин чечимдерге кызыкдарбыз деп чечтик, ошондуктан тандоо дароо аянтчаларга түштү.
өзү чындыгында balenaEngine ичинде ошол эле Докерди колдонгондугуна байланыштуу алынып салынган.
Бирок, мен буга карабастан, биз алардын продуктуну дайыма колдонуу менен аяктады деп белгилешет SD карталарында флеш микропрограммасы үчүн - бул үчүн жөнөкөй жана өтө ыңгайлуу.
Ошондуктан, акырында тандоо түшүп калды . Mender - бул микропрограмманы чогултуу, жеткирүү жана орнотуу үчүн толук платформа.
Жалпысынан платформа сонун көрүнөт, бирок мендер куруучу аркылуу микропрограммабыздын туура версиясын курууга бир жарым жумадай убакыт кетти.
Ал эми биз аны колдонуунун татаалдыктарына канчалык терең аралашкан сайын, аны толугу менен жайылтуу үчүн бизге караганда көбүрөөк убакыт керек экени айкын болду.
Тилекке каршы, биздин кыска мөөнөттөр Мендерди колдонуудан баш тартууга жана андан да жөнөкөйүн тандоого мажбур болдук.
Ansible
Биздин кырдаалда эң жөнөкөй чечим Ansible колдонуу болду. Баштоо үчүн бир нече окуу китептери жетиштүү болду.
Алардын маңызы биз жөн гана хосттон (CI серверинен) ssh аркылуу биздин малинага туташып, аларга жаңыртууларды тараттык.
Башында баары жөнөкөй эле - сиз түзмөктөр менен бир тармакта болушуңуз керек болчу, куюу Wi-Fi аркылуу жүргүзүлдү.
Кеңседе бир эле тармакка туташкан ондогон тесттик малина бар болчу, ар бир аппараттын Ansible Inventory-да көрсөтүлгөн статикалык IP дареги бар.
Биздин мониторинг агентибизди акыркы түзмөктөргө жеткирген Ansible болду
3G / LTE
Тилекке каршы, Ansible үчүн бул колдонуу учуру бизде скутерлерге ээ болгонго чейин иштеп чыгуу режиминде гана иштей алган.
Анткени скутерлер, сиз түшүнгөндөй, бир Wi-Fi роутерге туташып отурушпайт, дайыма тармак аркылуу жаңыртууларды күтүп турушат.
Чындыгында, скутерлерде мобилдик 3G/LTEден башка эч кандай байланыш болушу мүмкүн эмес (жана ошондо да ар дайым эмес).
Бул дароо байланыштын төмөн ылдамдыгы жана туруксуз байланыш сыяктуу көптөгөн көйгөйлөрдү жана чектөөлөрдү киргизет.
Бирок эң негизгиси 3G/LTE тармагында биз жөн гана тармакка дайындалган статикалык IPге ишене албайбыз.
Бул жарым-жартылай кээ бир SIM-карта провайдерлери тарабынан чечилет, ал тургай статикалык IP даректери бар IoT түзмөктөрү үчүн атайын SIM карталары бар. Бирок бизде андай сим-карталарга мүмкүнчүлүк болгон эмес жана IP даректерди колдоно алган жокпуз.
Албетте, Консул сыяктуу бир жерде IP даректерди каттоонун кандайдыр бир түрүн жасоо идеялары бар болчу, бирок биз мындай идеялардан баш тартууга туура келди, анткени биздин тесттерибизде IP дарек өтө тез-тез өзгөрүп кетиши мүмкүн, бул чоң туруксуздукка алып келди.
Ушул себептен улам, метрикаларды жеткирүү үчүн эң ыңгайлуу колдонуу бул тартуу моделин колдонуу эмес, анда биз керектүү көрсөткүчтөр үчүн түзмөктөргө барабыз, бирок көрсөткүчтөрдү түзмөктөн түздөн-түз серверге жеткирип турабыз.
VPN
Бул маселени чечүү үчүн биз VPNди тандадык - өзгөчө .
Системанын башталышында кардарлар (скутерлер) VPN серверине туташып, аларга туташа алышкан. Бул туннель жаңыртууларды жеткирүү үчүн колдонулган.
Теориялык жактан алганда, ошол эле туннелди мониторинг жүргүзүү үчүн колдонсо болот, бирок мындай байланыш жөнөкөй түртүүгө караганда татаалыраак жана анча ишенимдүү эмес.
Булут ресурстары
Акырында, булут кызматтарыбызды жана маалымат базаларыбызды көзөмөлдөө керек, анткени биз алар үчүн Kubernetes колдонобуз, эң жакшысы кластерде мониторингди орнотуу мүмкүн болушунча жөнөкөй. Идеалында, колдонуу , жайылтуу үчүн биз аны көпчүлүк учурларда колдонобуз. Жана, албетте, булутту көзөмөлдөө үчүн, скутерлердин өздөрүнө окшош чечимдерди колдонуу керек.
Берилген
Фу, биз сыпаттаманы иреттеп алдык окшойт, аягында бизге керектүү нерселердин тизмесин түзөлү:
- Тез чечим, анткени иштеп чыгуу процессинде мониторинг жүргүзүү зарыл
- Көлөмү/саны – көптөгөн көрсөткүчтөр керек
- Журнал чогултуу талап кылынат
- Ишенимдүүлүк - маалыматтар ийгиликтүү ишке киргизүү үчүн абдан маанилүү
- Тартуу моделин колдоно албайсыз - сизге түртүү керек
- Бизге аппараттык гана эмес, булуттун да бирдиктүү мониторинги керек
Акыркы сүрөт ушул сыяктуу көрүндү
Стек тандоо
Ошентип, биз мониторинг стек тандоо суроого туш болдук.
Биринчиден, биз бир эле учурда биздин бардык талаптарыбызды камтый турган, бирок ошол эле учурда аны колдонууну биздин муктаждыктарыбызга ылайыкташтыруу үчүн жетиштүү ийкемдүү болгон эң толук чечимди издеп жатканбыз. Ошентсе да, бизде аппараттык камсыздоо, архитектура жана мөөнөттөр боюнча көптөгөн чектөөлөр болгон.
сыяктуу толук кандуу системалардан баштап, көптөгөн мониторинг чечимдери бар , же жана Флотту башкаруу үчүн даяр чечимдер менен аяктайт.
Башында, акыркы биз үчүн идеалдуу чечим болуп көрүнгөн, бирок кээ бирлери толук мониторингге ээ болгон эмес, башкалардын акысыз версияларынын мүмкүнчүлүктөрү чектелүү болгон, ал эми башкалары жөн эле биздин "каалоолорду" камтыган эмес же биздин сценарийлерибизге ылайыктуу ийкемдүү эмес. Кээ бирлери жөн эле эскирип калган.
Бир катар окшош чечимдерди талдап чыккандан кийин, биз ушуга окшош стекти өзүбүз чогултуу оңой жана тезирээк болот деген тыянакка келдик. Ооба, бул толугу менен даяр Флотту башкаруу платформасын жайылтууга караганда бир аз татаалыраак болот, бирок биз компромисске барбашыбыз керек.
Албетте, чечимдердин бардыгында бизге толугу менен ылайыктуу даяр болгон, бирок биздин учурда белгилүү бир стекти өз алдынча чогултуу жана аны "өзүбүз үчүн" ыңгайлаштыруу алда канча тезирээк болду. даяр буюмдарды сыноо.
Ушунун бардыгы менен биз бүтүндөй мониторинг платформасын өзүбүз чогултууга умтулган жокпуз, бирок аларды ийкемдүү конфигурациялоо мүмкүнчүлүгүнө ээ болгон эң функционалдык "даяр" стектерди издедик.
(B)ELK?
Иш жүзүндө каралган биринчи чечим белгилүү ELK стек болчу.
Негизи БЕЛК деп аташ керек, себеби баары Битстен башталат -
Албетте, ELK - бул мониторинг чөйрөсүндөгү эң белгилүү жана күчтүү чечимдердин бири, андан да көбүрөөк журналдарды чогултуу жана иштетүү.
Биз ELK журналдарды чогултуу жана Prometheus алынган метрикаларды узак мөөнөттүү сактоо үчүн колдонулат деп ойлогонбуз.
Визуалдаштыруу үчүн сиз Grafan колдоно аласыз.
Чынында, жаңы ELK стек метрикаларды өз алдынча чогулта алат (metricbeat) жана Kibana да аларды көрсөтө алат.
Бирок, ошентсе да, ELK адегенде журналдардан өсүп чыккан жана ушул убакка чейин метрикалардын функционалдуулугу бир катар олуттуу кемчиликтерге ээ:
- Прометейге караганда кыйла жайыраак
- Прометейге караганда бир топ азыраак жерлерге интеграцияланат
- Алар үчүн эскертүүлөрдү орнотуу кыйын
- Метрикалар көп орун ээлейт
- Кибанда метрикалар менен башкаруу такталарын орнотуу Графанга караганда алда канча татаал
Жалпысынан алганда, ELKдеги метрикалар оор жана башка чечимдердегидей ыңгайлуу эмес, алардын ичинен азыр Prometheus эмес: TSDB, Victoria Metrics, Cortex ж.б.у.с. Албетте, мен дароо толук кандуу бардыгы бир чечимге ээ болгум келет, бирок metricbeat учурунда компромисстер өтө көп болчу.
Ал эми ELK стекинин өзүндө бир катар оор учурлар бар:
- Эгер сиз бир кыйла чоң көлөмдөгү маалыматтарды чогултсаңыз, ал оор, кээде өтө оор
- Сиз аны "кантип тамак жасаганды билишиңиз" керек - аны масштабдашыңыз керек, бирок бул маанилүү эмес
- Акысыз версиясы өчүрүлгөн - бекер версияда кадимки эскертүүлөр жок жана тандоо учурунда аутентификация болгон эмес.
Мен акыркы пункт жакшыраак жана кошумча болуп калды деп айтышым керек (анын ичинде аутентификация) баа моделинин өзү өзгөрө баштады.
Бирок биз бул чечимди колдоно турган кезде, эч кандай эскертүү болгон эмес.
Балким, биз ElastAlert же башка жамааттык чечимдерди колдонуп бир нерсе курууга аракет кылмакпыз, бирок биз дагы эле башка альтернативаларды карап көрүүнү чечтик.
Локи - Графана - Прометей
Азыркы учурда, жакшы чечим прометейге негизделген мониторинг стекти метрика провайдери катары, журналдар үчүн Loki жана визуализация үчүн ошол эле Grafana колдоно аласыз.
Тилекке каршы, долбоордун пилоттук сатуусу башталган учурда (19-жылдын сентябрь-октябрь айлары), Loki дагы эле 0.3-0.4 бета версиясында болчу жана иштеп чыгуунун башталышында аны өндүрүштүк чечим катары кароого мүмкүн эмес болчу. таптакыр.
Менде олуттуу долбоорлордо Loki колдонуу боюнча тажрыйбам жок, бирок Promtail (журналдарды чогултуу боюнча агент) кубернеттерде жылаңач металлда да, бактарда да сонун иштейт деп айта алам.
ТИК
Балким, ELK стекине эң татыктуу (жалгыз?) толук функционалдык альтернатива азыр бир гана TICK стек деп атоого болот - Telegraf, InfluxDB, Chronograf, Kapacitor.
Мен төмөндө бардык компоненттерди кененирээк сүрөттөп берем, бирок жалпы идея бул:
- Telegraf - көрсөткүчтөрдү чогултуу үчүн агент
- InfluxDB - метрикалык маалымат базасы
- Kapacitor - эскертүү үчүн реалдуу убакыт метрикалык процессору
- Chronograf - визуализация үчүн веб панели
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 жаңы версиясынын жакында күтүлүп жаткан релизинде, анда көп нерселер башкача болот (жөнүндө эч кандай маалымат жок) аны масштабдоо дагы).
Расмий түрдө акысыз версиясы бар - чындыгында, бул примитивдүү ГА, бирок баланстоо аркылуу гана,
анткени бардык маалыматтар жүк балансынын артындагы бардык InfluxDB инстанцияларына жазылат.
Анын кээ бирлери бар упайларды кайра жазуу менен мүмкүн болуучу көйгөйлөр жана алдын ала метрика үчүн негиздерди түзүү зарылчылыгы сыяктуу
(бул InfluxDB менен кадимки иштөө учурунда автоматтык түрдө болот).
Анын үстүнө , бул сизге кереги жок болушу мүмкүн болгон кайталанма метрикаларга (иштетүү жана сактоо) кошумча чыгымдарды билдирет, бирок аларды бөлүүгө эч кандай жол жок.
Victoria Metrics?
Натыйжада, биз акы төлөнүүчү масштабдан башка бардык нерседе TICK стекине толугу менен канааттанганыбызга карабастан, калган T_CK компоненттерин калтырып, InfluxDB маалымат базасын алмаштыра турган акысыз чечимдер бар-жокпу көрүүнү чечтик.
Убакыт серияларынын маалымат базалары көп, бирок эң келечектүүсү - Victoria Metrics, анын бир катар артыкчылыктары бар:
- Тез жана жеңил, жок эле дегенде, жыйынтыгы боюнча
- Кластердик версиясы бар, ал жөнүндө азыр жакшы сын-пикирлер бар
- Ал сындырып алат
- InfluxDB протоколун колдойт
Биз Викториянын негизинде толугу менен ыңгайлаштырылган стек курууну ойлогон эмеспиз жана негизги үмүт аны InfluxDB үчүн тамчы алмаштыруучу катары колдоно алабыз деп ойлогонбуз.
Тилекке каршы, бул мүмкүн эмес, InfluxDB протоколу колдоого алынганына карабастан, ал метрикаларды жазуу үчүн гана иштейт - Prometheus API гана "сырттан" жеткиликтүү, демек, ага Chronograf орнотуу мүмкүн эмес.
Мындан тышкары, көрсөткүчтөр үчүн сандык маанилер гана колдоого алынат (биз ыңгайлаштырылган көрсөткүчтөр үчүн сап маанилерин колдондук - бул бөлүмдө көбүрөөк ).
Албетте, ошол эле себептен улам, VM Influx сыяктуу журналдарды сактай албайт.
Ошондой эле, оптималдуу чечимди издөө учурунда Victoria Metrics анча популярдуу эмес экенин белгилей кетүү керек, документтер бир топ азыраак жана функционалдуулугу начарраак болчу.
(Мен кластердик версиянын деталдуу сүрөттөлүшүн жана сындырууну эстей албайм).
Негизги тандоо
Натыйжада, пилот үчүн биз дагы эле бир InfluxDB түйүнү менен чектелебиз деп чечтик.
Бул тандоо үчүн бир нече негизги себептер бар эле:
- Бизге TICK стекинин бардык функциялары абдан жакты
- Биз буга чейин аны жайгаштырууга жетиштик жана ал абдан жакшы иштеди
- Мөөнөтү бүтүп, башка варианттарды сынап көрүү үчүн көп убакыт калган жок.
- Мындай оор жүктү күткөн эмеспиз
Пилоттун биринчи фазасы үчүн бизде көптөгөн скутерлер болгон эмес жана иштеп чыгуу учурундагы тестирлөө эч кандай майнаптуулук көйгөйлөрүн көрсөткөн эмес.
Ошондуктан, биз бул долбоор үчүн бир Influx түйүнү масштабдоону талап кылбастан, бизге жетиштүү болот деп чечтик (аягында корутундуларды караңыз).
Биз стекти жана базаны чечтик - эми TICK стекинин калган компоненттери жөнүндө.
Конденсатор
Kapacitor - бул TICK стекинин бир бөлүгү, бул кызмат реалдуу убакытта маалымат базасына кирген метрикага көз салып, эрежелердин негизинде ар кандай аракеттерди жасай алат.
Жалпысынан алганда, ал потенциалдуу аномалияларды көзөмөлдөө жана машинаны үйрөнүү үчүн курал катары жайгаштырылган (мен бул функциялар суроо-талапка ээ экенине ишенбейм), бирок аны колдонуунун эң популярдуу учуру - эскертүү.
Биз аны эскертмелер үчүн ушундайча колдондук. Белгилүү бир скутер оффлайн режимине өткөндө Slack эскертүүлөрүн орноттук, ошондой эле акылдуу кубаттагычтар жана маанилүү инфраструктура компоненттери үчүн да жасалды.
Бул көйгөйлөргө тез арада жооп берүүгө, ошондой эле баары калыбына келгендиги жөнүндө эскертмелерди алууга мүмкүндүк берди.
Жөнөкөй мисал: биздин "кутубузду" кубаттандыруу үчүн кошумча батарейка бузулуп калды же кандайдыр бир себептерден улам жаңысын орнотуу менен кубаты түгөнүп калды, бир аз убакыт өткөндөн кийин биз скутердин иштеши калыбына келтирилгендиги жөнүндө билдирүү алышыбыз керек;
Influx 2.0 Kapacitor DB бөлүгү болуп калды
Хронограф
Мониторинг үчүн көптөгөн ар кандай UI чечимдерин көрдүм, бирок функционалдуулук жана UX жагынан Chronograf менен эч нерсе салыштырылбайт деп айта алам.
Биз TICK стекин, таң калыштуусу, Grafan менен веб-интерфейс катары колдоно баштадык.
Мен анын функционалдуулугун сүрөттөбөй эле коёюн, анын ар бир нерсени орнотуу үчүн кеңири мүмкүнчүлүктөрү бар.
Бирок, Grafana дагы эле толугу менен универсалдуу аспап болуп саналат, ал эми Chronograf негизинен Influx менен колдонуу үчүн иштелип чыккан.
Жана, албетте, мунун аркасында, Chronograf алда канча акылдуу же ыңгайлуу функцияларды бере алат.
Балким, Chronograf менен иштөөнүн негизги ынгайлуулугу, сиз Explore аркылуу InfluxDBтин ичин көрө аласыз.
Графана дээрлик бирдей функцияга ээ окшойт, бирок чындыгында, Chronograph'та аспаптар тактасын орнотуу чычканды бир нече чыкылдатуу менен (ошол эле учурда ал жердеги визуализацияны карап) жасалса болот, ал эми Графанада сизде эртеби-кечпи JSON конфигурациясын түзөтүү үчүн (албетте Chronograf кол менен конфигурацияланган дашаларды жүктөөгө жана керек болсо аларды JSON катары түзөтүүгө мүмкүндүк берет - бирок мен аларды UIде жараткандан кийин аларга эч качан тийбешим керек болчу).
Кибана башкаруу панелдерин жана алар үчүн башкаруу элементтерин түзүү үчүн алда канча бай мүмкүнчүлүктөргө ээ, бирок мындай операциялар үчүн UX абдан татаал.
Ыңгайлуу панелди түзүү үчүн жакшы түшүнүү керек. Chronograf панелдеринин функционалдуулугу азыраак болсо да, аларды жасоо жана ыңгайлаштыруу бир топ жөнөкөй.
Куралдар такталарынын өздөрү жагымдуу визуалдык стилден тышкары, чындыгында Графана же Кибанадагы панелдерден эч кандай айырмаланбайт:
Суроо терезеси ушундай көрүнөт:
Белгилей кетчү нерсе, InfluxDB маалымат базасындагы талаалардын түрлөрүн билүү, хронографтын өзү кээде автоматтык түрдө Суроо жазууда же орточо сыяктуу туура топтоо функциясын тандоодо жардам бере алат.
Жана, албетте, Chronograf журналдарды көрүү үчүн мүмкүн болушунча ыңгайлуу. Бул төмөнкүдөй көрүнөт:
Демейки боюнча, Influx журналдары syslog колдонууга ылайыкташтырылган жана ошондуктан алар маанилүү параметрге ээ - катаалдуулук.
Жогорудагы график өзгөчө пайдалуу, анда сиз пайда болгон каталарды көрө аласыз жана катуулугу жогору болсо, түс дароо ачык көрсөтөт.
Бир нече жолу биз маанилүү мүчүлүштүктөрдү ушинтип кармап, акыркы жумадагы журналдарды карап чыгып, кызыл шишикти көрдүк.
Албетте, идеалдуу түрдө мындай каталар үчүн эскертүүлөрдү орнотуу болмок, анткени бизде бул үчүн бардыгы болгон.
Биз муну бир аз убакытка күйгүздүк, бирок пилотту даярдоо процессинде биз бир топ каталарды (анын ичинде LTE тармагынын жеткиликсиздиги сыяктуу системалык каталарды) алып жатканыбыз белгилүү болду, алар Slack каналын да "спам" кылып жиберишти. көп, эч кандай чоң пайда алып келбейт.
Туура чечим бул каталардын көпчүлүгүн чечип, алардын катаалдыгын тууралап, андан кийин гана эскертүүнү иштетүү болот.
Ошентип, Slack'ке жаңы же маанилүү каталар гана жайгаштырылат. Мөөнөттөрү катуу болгондуктан, мындай орнотууга убакыт жетишсиз болгон.
тастыктоо
Ошондой эле Chronograf аутентификация катары OAuth жана OIDCди колдой турганын белгилей кетүү керек.
Бул абдан ыңгайлуу, анткени аны сервериңизге оңой тиркөөгө жана толук кандуу SSO түзүүгө мүмкүндүк берет.
Биздин учурда, сервер болгон — ал мониторингге туташуу үчүн колдонулган, бирок ошол эле сервер скутерлерди жана арткы тарапка суроо-талаптарды текшерүү үчүн да колдонулган.
"Админ"
Мен сүрөттөп бере турган акыркы компонент - бул Vueдеги өз алдынча жазылган "администратордук панелибиз".
Негизинен бул жөн гана өз алдынча кызмат, ал биздин жеке маалымат базаларыбыздан, микросервистерден жана InfluxDBден алынган метрика маалыматтарынан скутер маалыматын бир эле учурда көрсөтөт.
Мындан тышкары, ал жакка шашылыш түрдө кайра жүктөө же колдоо тобу үчүн кулпуну алыстан ачуу сыяктуу көптөгөн административдик функциялар көчүрүлдү.
Ошондой эле карталар бар болчу. Мен Chronograf ордуна Grafana менен баштаганыбызды айтып өттүм, анткени Grafana үчүн карталар плагиндер түрүндө жеткиликтүү, алардан скутерлердин координаттарын көрө алабыз. Тилекке каршы, Grafana үчүн карта виджеттеринин мүмкүнчүлүктөрү өтө чектелүү жана натыйжада, учурда координаттарды гана көрүп тим болбостон, ошондой эле көрсөтүү үчүн бир нече күндүн ичинде карталар менен өз веб тиркемеңизди жазуу бир топ жеңил болду. скутер басып өткөн маршрут, картадагы маалыматтарды чыпкалай алуу ж.
Influx'тун буга чейин айтылган артыкчылыктарынын бири - бул өзүңүздүн метрикаңызды оңой түзүү мүмкүнчүлүгү.
Бул ар кандай сценарийлер үчүн колдонууга мүмкүндүк берет.
Биз ал жерде бардык пайдалуу маалыматты жаздырууга аракет кылдык: батареянын заряды, кулпу абалы, сенсордун иштеши, bluetooth, GPS жана башка көптөгөн ден соолук текшерүүлөрү.
Мунун баарын биз администратор панелинде көрсөттүк.
Албетте, биз үчүн эң маанилүү критерий скутердин иштөө абалы болду - чындыгында, Influx муну өзү текшерет жана аны түйүндөр бөлүмүндө "жашыл жарыктар" менен көрсөтөт.
Бул функция тарабынан жасалат — биз аны кутубуздун иштешин түшүнүү жана ошол эле эскертүүлөрдү Slackке жөнөтүү үчүн колдондук.
Баса, биз скутерлерди Симпсондогу каармандардын атынан атадык – аларды бири-биринен айырмалоо абдан ыңгайлуу болду.
Жана жалпысынан бул жол менен кызыктуураак болду. «Балдар, Смитерс өлдү!» деген сыяктуу фразалар тынымсыз угулуп турду.
Сап көрсөткүчтөрү
InfluxDB сизге Victoria Metrics сыяктуу сандык маанилерди гана эмес, сактоого мүмкүндүк бергени маанилүү.
Бул анчалык деле маанилүү эместей сезилет - логдордон тышкары, ар кандай метрика сандар түрүндө сакталышы мүмкүн (жөн гана белгилүү мамлекеттер үчүн картаны кошуңуз - энумдун бир түрү)?
Биздин учурда, жок эле дегенде, бир сценарий бар болчу, анда сап көрсөткүчтөрү абдан пайдалуу.
Биздин "акылдуу кубаттагычтарыбызды" жеткирүүчү үчүнчү тарап болгондуктан, биз иштеп чыгуу процессин жана бул заряддагычтар бере турган маалыматты көзөмөлдөй алган жокпуз.
Натыйжада, заряддоо API идеалдуу эмес, бирок, негизги көйгөй, биз дайыма эле алардын абалын түшүнө алган эмес.
Бул жерде Influx жардамга келди. Биз жөн гана өзгөрүүсүз InfluxDB маалымат базасы талаасына бизге келген сап статусун жаздык.
Бир нече убакыттан бери "онлайн" жана "офлайн" сыяктуу баалуулуктар гана ал жерге келди, анын негизинде биздин администратор панелибизде маалымат көрсөтүлүп, Slack'ке эскертмелер жөнөтүлдү. Бирок, кандайдыр бир учурда, "ажыратылган" сыяктуу баалуулуктар да пайда боло баштады.
Кийинчерээк белгилүү болгондой, заряддагыч белгилүү сандагы аракеттерден кийин сервер менен байланыш түзө албаса, бул статус байланыш үзүлгөндөн кийин бир жолу жөнөтүлгөн.
Ошентип, эгерде биз белгиленген баалуулуктардын топтомун гана колдонсок, анда биз бул өзгөрүүлөрдү микропрограммада өз убагында көрө албай калышыбыз мүмкүн.
Жана жалпысынан, саптык көрсөткүчтөр колдонуу үчүн көбүрөөк мүмкүнчүлүктөрдү берет, аларда дээрлик бардык маалыматты жаздыра аласыз; Бирок, албетте, сиз да кылдаттык менен бул куралды колдонуу керек.
Кадимки көрсөткүчтөрдөн тышкары, биз InfluxDBде GPS жайгашкан жер маалыматын жаздык. Бул биздин администратор панелибиздеги скутерлердин жайгашкан жерин көзөмөлдөө үчүн абдан пайдалуу болду.
Чынында, биз ар дайым бизге керектүү учурда кайда жана кайсы скутер экенин билчүбүз.
Бул биз үчүн скутер издеп жүргөндө абдан пайдалуу болду (аягында корутундуларды караңыз).
Инфраструктуранын мониторинги
Скутерлердин өзүнөн тышкары, биз бүткүл (бир кыйла кеңири) инфраструктурабызды көзөмөлдөшүбүз керек болчу.
Абдан жалпы архитектура мындай көрүндү:
Эгерде биз таза мониторинг стекин бөлүп көрсөк, ал төмөнкүдөй көрүнөт:
Булуттан эмнени текшергибиз келет:
- Маалыматтар базасы
- клавиатура
- Микросервистер
Биздин бардык булут кызматтары Кубернетесте жайгашкандыктан, анын абалы жөнүндө маалымат чогултуу жакшы болмок.
Бактыга жараша, кутудан чыккан Telegraf Kubernetes кластеринин абалы жөнүндө көп сандагы көрсөткүчтөрдү чогулта алат жана Chronograf бул үчүн дароо кооз панелдерди сунуштайт.
Биз негизинен поддондордун иштешине жана эстутумдун сарпталышына мониторинг жүргүздүк. Жыгылган учурда, Slack'те эскертет.
Kubernetes'те подсказкаларды көзөмөлдөөнүн эки жолу бар: DaemonSet жана Sidecar.
Эки ыкма тең майда-чүйдөсүнө чейин сүрөттөлгөн .
Биз Telegraf Sidecar колдондук жана метрикадан тышкары, под журналдарды чогулттук.
Биздин учурда, биз журналдар менен тиштеп керек болчу. Telegraf Docker API'ден журналдарды чыгара алганына карабастан, биз акыркы түзмөктөрүбүз менен журналдардын бирдиктүү коллекциясына ээ болгубуз келди жана бул үчүн контейнерлер үчүн конфигурацияланган сислог. Балким, бул чечим сулуу эмес, бирок анын иши боюнча эч кандай даттануулар болгон эмес жана журналдар Chronograf жакшы көрсөтүлгөн.
Монитор мониторинг???
Акыр-аягы, мониторинг системалары боюнча эски суроо пайда болду, бирок, бактыга жараша, же тилекке каршы, бизде бул үчүн жетиштүү убакыт болгон жок.
Telegraf өзүнүн көрсөткүчтөрүн оңой эле жөнөтө алат же InfluxDB маалымат базасынан көрсөткүчтөрдү ошол эле Influxка же башка жерге жөнөтүү үчүн чогулта алат.
табылгалары
Учкучтун жыйынтыгынан кандай тыянак чыгардык?
Кантип мониторинг жүргүзө аласыз?
Биринчиден, TICK стек биздин күтүүлөрүбүздү толугу менен актады жана башында биз күткөндөн да көбүрөөк мүмкүнчүлүктөрдү берди.
Бизге керектүү бардык функциялар бар болчу. Аны менен кылган бардык нерсебиз көйгөйсүз иштеди.
кирешелүүлүк
Акысыз версиядагы TICK стекинин негизги көйгөйү - масштабдоо мүмкүнчүлүктөрүнүн жоктугу. Бул биз үчүн көйгөй болгон жок.
Биз так жүктөө маалыматтарын/цифраларын чогулткан жокпуз, бирок бир эле учурда 30га жакын скутерден маалыматтарды чогулттук.
Алардын ар бири уч мицден ашык миц метрди чогултту. Ошол эле учурда аппараттардын журналдары чогултулган. Маалыматтарды чогултуу жана жөнөтүү ар бир 10 секундада болуп турду.
Пилоттук бир жарым жумадан кийин, "балалык көйгөйлөрдүн" басымдуу бөлүгү оңдолуп, эң маанилүү көйгөйлөр чечилгенден кийин, серверге маалыматтарды жөнөтүү жыштыгын төмөндөтүүгө туура келгенин белгилей кетүү маанилүү. 30 секунд. Бул биздин LTE SIM карталарыбыздагы трафик тез эле жок боло баштагандыктан зарыл болуп калды.
Трафиктин негизги бөлүгүн логдор керектеген, ал тургай, 10 секунддук интервал менен, иш жүзүндө аны текке кетирген эмес.
Натыйжада, бир нече убакыт өткөндөн кийин, биз түзмөктөрдө журналдарды чогултууну толугу менен өчүрүп койдук, анткени белгилүү бир көйгөйлөр дайыма чогултулбаса да ачык эле көрүнүп турган.
Айрым учурларда, эгер журналдарды көрүү дагы эле зарыл болсо, биз жөн гана байланыш аркылуу туташтык WireGuard VPN аркылуу.
Мен ошондой эле ар бир өзүнчө чөйрө бири-биринен бөлүнгөнүн жана жогоруда сүрөттөлгөн жүк өндүрүш чөйрөсүнө гана тиешелүү экенин кошумчалайм.
Иштеп чыгуу чөйрөсүндө биз ар бир 10 секунд сайын маалыматтарды чогултууну уланткан өзүнчө InfluxDB инстанциясын көтөрдүк жана биз эч кандай майнаптуулук көйгөйлөрүнө туш болгон жокпуз.
TICK - чакан жана орто долбоорлор үчүн идеалдуу
Бул маалыматтын негизинде, мен TICK стек эч кандай HighLoad күтпөгөн салыштырмалуу чакан долбоорлор же долбоорлор үчүн идеалдуу деген тыянак чыгарат элем.
Эгер сизде миңдеген поддондор же жүздөгөн машиналар жок болсо, бир InfluxDB үлгүсү да жүктү жакшы көтөрөт.
Кээ бир учурларда, сизди Influx Relay примитивдүү High Availability чечими катары канааттандырышы мүмкүн.
Жана, албетте, эч ким сизге "вертикалдуу" масштабды орнотууга жана жөн гана метрикалардын ар кандай түрлөрү үчүн ар кандай серверлерди бөлүштүрүүгө тоскоолдук кылбайт.
Эгерде сиз мониторинг кызматтарына күтүлгөн жүктөмдү билбесеңиз, же сизде өтө "оор" архитектурага ээ болууга кепилдик берилсе, мен TICK стекинин акысыз версиясын колдонууну сунуш кылбайм.
Албетте, жөнөкөй чечим сатып алуу болот - бирок бул жерде мен эч кандай комментарий бере албайм, анткени мен өзүм кылдаттык менен тааныш эмесмин. Мындан тышкары, бул абдан кымбат жана чакан компаниялар үчүн ылайыктуу эмес.
Бул учурда, бүгүн, мен Loki аркылуу Victoria Metrics жана журналдар аркылуу метрикаларды чогултууну сунуштайм.
Ырас, мен дагы бир жолу эскертем, 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тен кийин эч кандай мониторинг маалыматы алынган жок — бул кошумча батареянын заряды түгөнүп калганын, же чабуулчу акыры скутерден акылдуу жабдыкты кантип алып салуу керектигин түшүнгөн.
Ага карабай, скутер жайгашкан дарекке полиция дагы эле чакырылган. Скутер ал жерде жок болчу.
Бирок, үйдүн ээси да буга таң калды, анткени ал чындыгында кечээ кечинде кеңседен үйгө скутер менен келген.
Маалым болгондой, колдоо көрсөтүүчү кызматкерлердин бири эртең менен эрте келип, скутерди көтөрүп, анын кошумча аккумулятору толук түгөнүп калганын көрүп, аны (жөө) унаа токтотуучу жайга алып кеткен. Ал эми кошумча батарея нымдуулуктан улам иштебей калды.
Скутерди өзүбүздөн уурдап алдык. Баса, милициянын иши боюнча маселени кантип, анан ким чечкенин билбейм, бирок мониторинг эң сонун иштеген...
Source: www.habr.com
