Преди година стартирахме пилотна версия на промоционален проект за .
Първоначално проектът се наричаше Road-To-Barcelona, по-късно се превърна в Road-To-Berlin (оттук и R2B на екранните снимки), а накрая беше наречен xRide.
Основната идея на проекта беше следната: вместо да имаме централизирана услуга за коли или скутери под наем (говорим за скутери, известни още като електрически мотоциклети, а не за тротинетки/скутери), ние искахме да направим платформа за децентрализирано отдаване под наем. За трудностите, които срещнахме .
Първоначално проектът се фокусира върху автомобили, но поради крайни срокове, изключително дълги комуникации с производителите и огромен брой ограничения за безопасност, за пилота бяха избрани електрически скутери.
Потребителят инсталира приложение за iOS или Android на телефона, приближи се до скутера, който хареса, след което телефонът и скутерът установиха peer-to-peer връзка, ETH беше разменен и потребителят можеше да започне пътуването, като включи скутера чрез телефонът. В края на пътуването също беше възможно да платите за пътуването с помощта на Ethereum от портфейла на потребителя на телефона.
В допълнение към скутерите, потребителят видя „умни зарядни устройства“ в приложението, посещавайки които, потребителят може сам да смени текущата батерия, ако е изтощена.
Така най-общо изглеждаше нашият пилот, стартиран през септември миналата година в два германски града: Бон и Берлин.
И тогава, един ден в Бон, рано сутринта, нашият екип за поддръжка (намиращ се на място, за да поддържа скутерите в изправност) беше предупреден: един от скутерите беше изчезнал безследно.
Как да го намеря и върна?
В тази статия ще говоря за това, но първо – за това как изградихме собствена IoT платформа и как я наблюдавахме.
Какво и защо да наблюдаваме: скутери, инфраструктура, зарядни станции?
И така, какво искахме да наблюдаваме в нашия проект?
На първо място, това са самите скутери - самите електрически скутери са доста скъпи, не можете да стартирате такъв проект, без да сте достатъчно подготвени; ако е възможно, искате да съберете възможно най-много информация за скутерите: за тяхното местоположение, ниво на зареждане и т.н.
Освен това бих искал да наблюдавам състоянието на нашата собствена ИТ инфраструктура - бази данни, услуги и всичко необходимо за работата им. Също така беше необходимо да се следи състоянието на „умните зарядни устройства“, в случай че се повредят или изтощят пълните батерии.
Тротинетки
Какви бяха нашите скутери и какво искахме да знаем за тях?
Първото и най-важно нещо са GPS координатите, тъй като благодарение на тях можем да разберем къде са и къде се движат.
Следва зареждането на батерията, благодарение на което можем да определим, че зареждането на скутерите е към края си и да изпратим сокоизстисквачка или поне да предупредим потребителя.
Разбира се, също така е необходимо да проверите какво се случва с нашите хардуерни компоненти:
- bluetooth работи ли
- самия GPS модул работи ли?
- Имахме проблем и с факта, че GPS-ът можеше да изпрати грешни координати и да блокира, а това можеше да се установи само с допълнителни проверки на скутера,
и уведомете поддръжката възможно най-скоро, за да разрешите проблема
- Имахме проблем и с факта, че GPS-ът можеше да изпрати грешни координати и да блокира, а това можеше да се установи само с допълнителни проверки на скутера,
И накрая: проверки на софтуера, като започнем от операционната система и процесора, натоварването на мрежата и диска, завършим с проверки на нашите собствени модули, които са по-специфични за нас (, ).
железария
Каква беше нашата „желязна“ част?
Отчитайки възможно най-краткия срок и необходимостта от бързо прототипиране, избрахме най-лесния вариант за внедряване и подбор на компоненти – Raspberry Pi.
В допълнение към самия Rpi, разполагахме с персонализирана платка (която сами разработихме и поръчахме от Китай, за да ускорим процеса на сглобяване на крайното решение) и набор от компоненти - реле (за включване/изключване на скутера), четец за заряд на батерията, модем, антени. Всичко това беше компактно опаковано в специална “xRide кутия”.
Също така трябва да се отбележи, че цялата кутия се захранваше от допълнителен power bank, който от своя страна се захранваше от основната батерия на скутера.
Това направи възможно използването на мониторинг и включване на скутера дори след края на пътуването, тъй като основната батерия беше изключена веднага след завъртане на ключа за запалване в положение „изключено“.
Докер? Обикновен Linux? и внедряване
Да се върнем към мониторинга, така че Raspberry - какво имаме?
Едно от първите неща, които искахме да използваме, за да ускорим процеса на внедряване, актуализиране и доставяне на компоненти на физически устройства, беше Docker.
За съжаление, бързо стана ясно, че Docker на RPi, въпреки че работи, има много режийни разходи, особено по отношение на консумацията на енергия.
Разликата при използване на „родната“ операционна система, макар и не толкова силна, все пак беше достатъчна, за да внимаваме за възможността от твърде бърза загуба на заряд.
Втората причина беше една от нашите партньорски библиотеки на Node.js (sic!) – единственият компонент на системата, който не беше написан на Go/C/C++.
Авторите на библиотеката нямаха време да предоставят работеща версия на нито един от „родните“ езици.
Не само, че самият възел не е най-елегантното решение за устройства с ниска производителност, но самата библиотека беше много гладна за ресурси.
Осъзнахме, че дори и да искаме, използването на Docker би било твърде голямо натоварване за нас. Изборът беше направен в полза на родната операционна система и работа директно под нея.
OS
В резултат на това ние отново избрахме най-простата опция като ОС и използвахме Raspbian (компилация на Debian за Pi).
Ние пишем целия си софтуер на Go, така че написахме и основния модул на хардуерен агент в нашата система в Go.
Той е този, който отговаря за работата с GPS, Bluetooth, четене на заряда, включване на скутера и т.н.
Разположете
Веднага възникна въпросът за необходимостта от внедряване на механизъм за доставяне на актуализации на устройства (OTA) - както актуализации на самия агент/приложение, така и актуализации на самата ОС/фърмуер (тъй като новите версии на агента може да изискват актуализации на ядрото или системни компоненти, библиотеки и др.) .
След доста дълъг анализ на пазара се оказа, че има доста решения за доставяне на актуализации на устройството.
От сравнително прости, най-вече ориентирани към актуализиране/двойно зареждане помощни програми като swupd/SWUpdate/OSTree до пълноценни платформи като Mender и Balena.
На първо място, решихме, че се интересуваме от решения от край до край, така че изборът веднага падна върху платформи.
Най-много беше изключен поради факта, че всъщност използва същия Docker в своя balenaEngine.
Но отбелязвам, че въпреки това в крайна сметка постоянно използвахме техния продукт за флаш фърмуер на SD карти - проста и изключително удобна програма за това.
Затова в крайна сметка изборът падна . Mender е цялостна платформа за сглобяване, доставка и инсталиране на фърмуер.
Като цяло платформата изглежда страхотно, но ни отне около седмица и половина само да изградим правилната версия на нашия фърмуер с помощта на mender builder.
И колкото повече се потапяхме в тънкостите на използването му, толкова повече ставаше ясно, че за пълното му разгръщане ще ни трябва много повече време, отколкото имахме.
Уви, кратките ни срокове означаваха, че бяхме принудени да се откажем от използването на Mender и да изберем още по-опростен.
Ansible
Най-простото решение в нашата ситуация беше да използваме Ansible. Няколко книги-игри бяха достатъчни, за да започнете.
Тяхната същност беше, че ние просто се свързвахме от хоста (CI сървър) чрез ssh към нашите rasberries и им разпространявахме актуализации.
В самото начало всичко беше просто - трябваше да сте в една и съща мрежа с устройствата, изливането ставаше чрез Wi-Fi.
В офиса имаше просто дузина тестови малини, свързани към една и съща мрежа, всяко устройство имаше статичен IP адрес, също посочен в Ansible Inventory.
Ansible достави нашия агент за наблюдение до крайните устройства
3G / LTE
За съжаление, този случай на използване на Ansible можеше да работи само в режим на разработка, преди да имаме истински скутери.
Тъй като скутерите, както разбирате, не стоят свързани към един Wi-Fi рутер, постоянно чакащи актуализации по мрежата.
В действителност скутерите не могат да имат никаква друга връзка освен мобилна 3G/LTE (и дори тогава не през цялото време).
Това веднага налага много проблеми и ограничения, като ниска скорост на връзката и нестабилна комуникация.
Но най-важното е, че в 3G/LTE мрежа не можем просто да разчитаме на статичен IP адрес, присвоен на мрежата.
Това е частично разрешено от някои доставчици на SIM карти; има дори специални SIM карти, предназначени за IoT устройства със статични IP адреси. Но ние нямахме достъп до такива SIM карти и не можехме да използваме IP адреси.
Разбира се, имаше идеи да се направи някаква регистрация на IP адреси, известна още като откриване на услуги, някъде като Consul, но трябваше да се откажем от такива идеи, тъй като при нашите тестове IP адресът можеше да се променя твърде често, което доведе до голяма нестабилност.
Поради тази причина най-удобната употреба за доставяне на показатели не би била използването на модела на изтегляне, където ще отидем на устройства за необходимите показатели, а натискане, доставяйки показатели от устройството директно на сървъра
VPN
Като решение на този проблем избрахме VPN - конкретно .
Клиентите (скутери) в началото на системата се свързаха с VPN сървъра и успяха да се свържат с тях. Този тунел е използван за доставяне на актуализации.
На теория същият тунел може да се използва за наблюдение, но такава връзка е по-сложна и по-малко надеждна от обикновеното натискане.
Облачни ресурси
И накрая, необходимо е да наблюдаваме нашите облачни услуги и бази данни, тъй като ние използваме Kubernetes за тях, в идеалния случай, така че внедряването на наблюдение в клъстера да е възможно най-лесно. В идеалния случай, използвайки , тъй като за внедряване го използваме в повечето случаи. И, разбира се, за да наблюдавате облака, трябва да използвате същите решения като за самите скутери.
Дадено
Уф, изглежда сме подредили описанието, нека да направим списък на това, от което се нуждаем в крайна сметка:
- Бързо решение, тъй като наблюдението е необходимо още по време на процеса на разработка
- Обем/количество – необходими са много показатели
- Изисква се събиране на регистрационни файлове
- Надеждност - данните са от решаващо значение за успеха на стартирането
- Не можете да използвате модела на изтегляне - имате нужда от натискане
- Имаме нужда от единен мониторинг не само на хардуера, но и на облака
Крайното изображение изглеждаше нещо подобно
Избор на стек
И така, бяхме изправени пред въпроса за избора на стек за мониторинг.
На първо място, ние търсихме най-пълното решение "всичко в едно", което едновременно да покрива всички наши изисквания, но в същото време да бъде достатъчно гъвкаво, за да приспособим използването му към нашите нужди. Все пак имахме много ограничения, наложени ни от хардуер, архитектура и крайни срокове.
Има огромно разнообразие от решения за мониторинг, като се започне с пълноценни системи като , или и завършвайки с готови решения за Fleet management.
Първоначално последното изглеждаше като идеално решение за нас, но някои нямаха пълно наблюдение, други имаха силно ограничени възможности на безплатните версии, а трети просто не покриваха нашите „желания“ или не бяха достатъчно гъвкави, за да паснат на нашите сценарии. Някои просто са остарели.
След като анализирахме редица подобни решения, бързо стигнахме до извода, че би било по-лесно и по-бързо сами да сглобим подобен стек. Да, ще бъде малко по-сложно от внедряването на напълно готова платформа за управление на флота, но няма да се налага да правим компромиси.
Почти сигурно в цялото огромно изобилие от решения вече има готово, което да ни пасне напълно, но в нашия случай беше много по-бързо да сглобим определен стек сами и да го персонализираме „за себе си“, отколкото тестване на готови продукти.
С всичко това не се стремихме сами да сглобим цяла платформа за наблюдение, а търсихме най-функционалните „готови“ стекове, само с възможност за гъвкаво конфигуриране.
(B)ELK?
Първото решение, което всъщност беше разгледано, беше добре познатият стек ELK.
Всъщност трябва да се казва BELK, защото всичко започва с Beats -
Разбира се, ELK е едно от най-известните и мощни решения в областта на мониторинга и още повече в събирането и обработката на логове.
Имахме намерение ELK да се използва за събиране на регистрационни файлове, както и за дългосрочно съхранение на показатели, получени от Prometheus.
За визуализация можете да използвате Grafan.
Всъщност новият стек ELK може да събира показатели независимо (metricbeat), а Kibana също може да ги показва.
Но все пак ELK първоначално израства от регистрационни файлове и досега функционалността на показателите има редица сериозни недостатъци:
- Значително по-бавен от Прометей
- Интегрира се на много по-малко места от Prometheus
- Трудно е да се настроят сигнали за тях
- Метриките заемат много място
- Настройването на табла с показатели в Kiban е много по-сложно, отколкото в Grafan
Като цяло, метриките в ELK са тежки и все още не са толкова удобни, колкото в други решения, от които сега има много повече от просто Prometheus: TSDB, Victoria Metrics, Cortex и т.н., и т.н. Разбира се, наистина бих искал веднага да имам пълноценно решение "всичко в едно", но в случая с metricbeat имаше твърде много компромиси.
И самият стек ELK има редица трудни моменти:
- Това е тежко, понякога дори много тежко, ако събирате доста голямо количество данни
- Трябва да „знаете как да го готвите“ - трябва да го мащабирате, но това не е тривиално
- Съкратена безплатна версия - безплатната версия няма нормално предупреждение и по време на избора не е имало удостоверяване
Трябва да кажа, че наскоро последната точка стана по-добра и в допълнение (включително удостоверяване) самият модел на ценообразуване започна да се променя.
Но по времето, когато щяхме да внедрим това решение, изобщо нямаше предупреждение.
Може би бихме могли да опитаме да създадем нещо, използвайки ElastAlert или други решения на общността, но все пак решихме да обмислим други алтернативи.
Локи - Графана - Прометей
В момента добро решение може да бъде изграждането на стек за мониторинг, базиран изцяло на Prometheus като доставчик на метрики, Loki за регистрационни файлове, а за визуализация можете да използвате същата Grafana.
За съжаление, към момента на стартиране на пилотния продажби на проекта (септември-октомври 19 г.), Loki все още беше в бета версия 0.3-0.4 и към момента на началото на разработката не можеше да се счита за решение за производство изобщо.
Все още нямам опит в действителното използване на Loki в сериозни проекти, но мога да кажа, че Promtail (агент за събиране на трупи) работи чудесно както за голи метал, така и за подове в kubernetes.
ТИК
Може би най-достойната (единствената?) Пълнофункционална алтернатива на стека ELK вече може да се нарече стека TICK - Telegraf, InfluxDB, Chronograf, Kapacitor.
Ще опиша всички компоненти по-долу по-подробно, но общата идея е следната:
- Telegraf - агент за събиране на метрики
- InfluxDB - база данни с показатели
- Kapacitor - процесор за измерване в реално време за предупреждение
- Хронограф - уеб панел за визуализация
За InfluxDB, Kapacitor и Chronograf има официални диаграми на кормилото, които използвахме, за да ги внедрим.
Трябва да се отбележи, че в последната версия на Influx 2.0 (бета), Kapacitor и Chronograf станаха част от InfluxDB и вече не съществуват отделно
Телеграф
е много лек агент за събиране на показатели на държавна машина.
Той може да наблюдава огромно количество от всичко, от до
сървър .
Има редица интересни предимства:
- Бърз и лек (написан на Go)
- Яде минимално количество ресурси
- Push показатели по подразбиране
- Събира всички необходими показатели
- Системни показатели без никакви настройки
- Хардуерни показатели като информация от сензори
- Много е лесно да добавите свои собствени показатели
- Много плъгини от кутията
- Събира трупи
Тъй като push metrics бяха необходими за нас, всички други предимства бяха повече от приятни добавки.
Събирането на регистрационни файлове от самия агент също е много удобно, тъй като няма нужда да свързвате допълнителни помощни програми за регистриране на регистрационни файлове.
Influx предлага най-удобното изживяване за работа с регистрационни файлове, ако използвате .
Telegraf обикновено е страхотен агент за събиране на показатели, дори ако не използвате останалата част от ICK стека.
Много хора го кръстосват с ELK и различни други бази данни с времеви серии за удобство, тъй като той може да записва показатели почти навсякъде.
InfluxDB
InfluxDB е основното ядро на стека TICK, а именно база данни с времеви серии за показатели.
В допълнение към показателите, Influx може също да съхранява регистрационни файлове, въпреки че по същество регистрационните файлове за него са същите показатели, само вместо обичайните цифрови индикатори, основната функция се изпълнява от ред от текст на регистрационния файл.
InfluxDB също е написан на Go и изглежда работи много по-бързо в сравнение с ELK на нашия (не най-мощния) клъстер.
Едно от страхотните предимства на Influx би включвало и много удобен и богат API за заявки за данни, който използвахме много активно.
Недостатъци - $$$ или мащабиране?
Стекът TICK има само един недостатък, който открихме - той скъп. Дори повече.
Какво има платената версия, което няма безплатната?
Доколкото успяхме да разберем, единствената разлика между платената версия на стека TICK и безплатната е възможностите за мащабиране.
А именно, можете да създадете клъстер с висока наличност само в .
Ако искате пълноправен HA, трябва или да платите, или да използвате някои патерици. Има няколко общностни решения - напр изглежда като компетентно решение, но пише, че не е подходящ за производство, както и
- просто решение с изпомпване на данни през NATS (също ще трябва да се мащабира, но това може да бъде решено).
Жалко, но и двете изглеждат изоставени - няма пресни комити, предполагам, че проблемът е скорошното очаквано излизане на новата версия на Influx 2.0, в която много неща ще са различни (няма информация за мащабиране в него още).
Официално има безплатна версия - всъщност това е примитивна HA, но само чрез балансиране,
тъй като всички данни ще бъдат записани във всички екземпляри на InfluxDB зад балансиращото натоварване.
Той има някои като потенциални проблеми с презаписване на точки и необходимостта от създаване на бази за показатели предварително
(което се случва автоматично при нормална работа с InfluxDB).
В допълнение , това означава допълнителни разходи за дублиращи се показатели (както обработка, така и съхранение), които може да не са ви необходими, но няма начин да ги разделите.
Виктория Метрика?
В резултат на това, въпреки факта, че бяхме напълно доволни от стека TICK във всичко, различно от платеното мащабиране, решихме да видим дали има безплатни решения, които биха могли да заменят базата данни InfluxDB, като същевременно оставихме останалите T_CK компоненти.
Има много бази данни с времеви редове, но най-обещаващата е Victoria Metrics, тя има редица предимства:
- Бързо и лесно, поне според резултатите
- Има клъстерна версия, за която вече има дори добри отзиви
- Тя може да къса
- Поддържа InfluxDB протокол
Не възнамерявахме да изградим напълно персонализиран стек, базиран на Victoria, и основната надежда беше, че можем да го използваме като заместител на InfluxDB.
За съжаление, това не е възможно, въпреки факта, че протоколът InfluxDB се поддържа, той работи само за запис на показатели - само API на Prometheus е достъпен „отвън“, което означава, че няма да е възможно да настроите 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 е, че можете да видите вътрешността на вашата InfluxDB чрез Explore.
Изглежда, че Grafana има почти идентична функционалност, но в действителност настройката на таблото за управление в Chronograf може да стане с няколко щраквания на мишката (в същото време гледайки визуализацията там), докато в Grafana все пак рано или късно ще имате за редактиране на JSON конфигурацията (разбира се, Chronograf позволява качване на вашите ръчно конфигурирани даши и редактиране като JSON, ако е необходимо - но никога не ми се е налагало да ги докосвам, след като съм ги създал в потребителския интерфейс).
Kibana има много по-богати възможности за създаване на табла за управление и контроли за тях, но UX за такива операции е много сложен.
Ще е необходимо известно разбиране, за да създадете удобно табло за управление. И въпреки че функционалността на таблата за управление на Chronograf е по-малка, създаването и персонализирането им е много по-лесно.
Самите табла, освен приятния визуален стил, всъщност не се различават по нищо от таблата в Графана или Кибана:
Ето как изглежда прозорецът на заявката:
Важно е да се отбележи, наред с други неща, че знаейки типовете полета в базата данни InfluxDB, самият хронограф понякога може автоматично да ви помогне при писането на заявка или при избора на правилната функция за агрегиране като средна стойност.
И разбира се, Chronograf е възможно най-удобен за преглед на дневници. Изглежда така:
По подразбиране регистрационните файлове на Influx са пригодени да използват syslog и следователно имат важен параметър - сериозност.
Графиката в горната част е особено полезна; на нея можете да видите грешките, които се появяват, а цветът веднага показва ясно дали сериозността е по-висока.
Няколко пъти хванахме важни грешки по този начин, като отидем да прегледаме регистрационните файлове за последната седмица и видяхме червен шип.
Разбира се, в идеалния случай би било да настроим предупреждения за такива грешки, тъй като вече разполагаме с всичко за това.
Дори го включихме за известно време, но в процеса на подготовка на пилота се оказа, че получаваме доста грешки (включително системни като недостъпност на LTE мрежата), които „спамят“ и Slack канала много, без да създава проблеми. голяма полза.
Правилното решение би било да се справите с повечето от тези видове грешки, да коригирате сериозността за тях и едва след това да активирате предупреждението.
По този начин само нови или важни грешки ще бъдат публикувани в Slack. Просто нямаше достатъчно време за такава настройка предвид кратките срокове.
заверка
Също така си струва да се спомене, че Chronograf поддържа OAuth и OIDC като удостоверяване.
Това е много удобно, тъй като ви позволява лесно да го прикачите към вашия сървър и да създадете пълноправен SSO.
В нашия случай сървърът беше — използван е за свързване с мониторинг, но същият сървър е използван и за удостоверяване на скутери и заявки към задния край.
„Администратор“
Последният компонент, който ще опиша, е нашият собственоръчен „административен панел“ във Vue.
По принцип това е просто самостоятелна услуга, която показва информация за скутери от нашите собствени бази данни, микроуслуги и данни за показатели от InfluxDB едновременно.
Освен това много административни функции бяха преместени там, като аварийно рестартиране или дистанционно отваряне на ключалка за екипа за поддръжка.
Имаше и карти. Вече споменах, че започнахме с Grafana вместо Chronograf - защото за Grafana са налични карти под формата на плъгини, на които можем да видим координатите на скутери. За съжаление, възможностите на картографските уиджети за Grafana са много ограничени и в резултат на това беше много по-лесно да напишете свое собствено уеб приложение с карти за няколко дни, за да не само виждате координатите в момента, но и да показвате маршрута, изминат от скутера, да можете да филтрирате данните на картата и т.н. (цялата тази функционалност, която не можахме да конфигурираме в обикновено табло за управление).
Едно от вече споменатите предимства на Influx е възможността лесно да създавате свои собствени показатели.
Това му позволява да се използва за огромно разнообразие от сценарии.
Опитахме се да запишем цялата полезна информация там: заряд на батерията, състояние на заключване, работа на сензора, bluetooth, GPS и много други проверки на здравето.
Показахме всичко това в админ панела.
Разбира се, най-важният критерий за нас беше експлоатационното състояние на скутера - всъщност Influx сам проверява това и го показва със „зелени светлини“ в раздела Възли.
Това се прави от функцията — използвахме го, за да разберем ефективността на нашата кутия и да изпратим същите тези сигнали на Slack.
Между другото, кръстихме скутерите на имената на герои от Семейство Симпсън - беше толкова удобно да ги различаваме един от друг
И като цяло така беше по-забавно. Постоянно се чуваха фрази като „Момчета, Смитърс е мъртъв!“.
Стрингови показатели
Важно е, че InfluxDB ви позволява да съхранявате не само числови стойности, какъвто е случаят с Victoria Metrics.
Изглежда, че това не е толкова важно - в края на краищата, освен регистрационни файлове, всякакви показатели могат да се съхраняват под формата на числа (просто добавете картографиране за известни състояния - един вид enum)?
В нашия случай имаше поне един сценарий, при който низовите показатели бяха много полезни.
Просто така се случи, че доставчикът на нашите „интелигентни зарядни устройства“ беше трета страна, ние нямахме контрол върху процеса на разработка и информацията, която тези зарядни устройства можеха да предоставят.
В резултат на това API за таксуване беше далеч от идеалния, но основният проблем беше, че не винаги можехме да разберем тяхното състояние.
Тук Influx дойде на помощ. Просто написахме статуса на низа, който дойде при нас в полето на базата данни InfluxDB без промени.
За известно време там стигнаха само стойности като „онлайн“ и „офлайн“, въз основа на които информацията се показваше в нашия административен панел и известията бяха изпратени до Slack. Въпреки това, в един момент там също започнаха да се появяват стойности като „прекъснат“.
Както се оказа по-късно, този статус се изпраща веднъж след загуба на връзка, ако зарядното устройство не може да установи връзка със сървъра след определен брой опити.
По този начин, ако използваме само фиксиран набор от стойности, може да не видим тези промени във фърмуера в подходящия момент.
И като цяло низовите показатели предоставят много повече възможности за използване, можете да записвате практически всяка информация в тях. Въпреки че, разбира се, вие също трябва да използвате този инструмент внимателно.
В допълнение към обичайните показатели, записахме и GPS информация за местоположението в InfluxDB. Това беше невероятно полезно за наблюдение на местоположението на скутери в нашия администраторски панел.
Всъщност винаги сме знаели къде и кой скутер е в момента, в който имаме нужда.
Това ни беше много полезно, когато търсихме скутер (вижте заключенията в края).
Мониторинг на инфраструктурата
Освен самите скутери, трябваше да наблюдаваме и цялата ни (доста обширна) инфраструктура.
Една много обща архитектура изглеждаше така:
Ако подчертаем стека за чист мониторинг, той изглежда така:
Това, което бихме искали да проверим в облака, е:
- Данни на Guide-Bulgaria.com
- ключодържател
- Микроуслуги
Тъй като всички наши облачни услуги се намират в Kubernetes, би било хубаво да събираме информация за състоянието му.
За щастие, Telegraf извън кутията може да събере огромен брой показатели за състоянието на клъстера Kubernetes, а Chronograf веднага предлага красиви табла за управление за това.
Основно наблюдавахме производителността на подовете и потреблението на памет. В случай на падане, сигнали в Slack.
Има два начина за проследяване на подове в Kubernetes: DaemonSet и Sidecar.
И двата метода са описани подробно .
Използвахме Telegraf Sidecar и в допълнение към показателите събрахме регистрационни файлове на pod.
В нашия случай трябваше да се занимаваме с трупите. Въпреки факта, че Telegraf може да изтегля регистрационни файлове от Docker API, ние искахме да имаме единна колекция от регистрационни файлове с нашите крайни устройства и конфигурирахме syslog за контейнери за това. Може би това решение не беше красиво, но нямаше оплаквания относно работата му и регистрационните файлове се показваха добре в Chronograf.
Монитор мониторинг???
В крайна сметка възникна вековният въпрос за мониторинга на системите за мониторинг, но за щастие или за съжаление просто нямахме достатъчно време за това.
Въпреки че Telegraf може лесно да изпраща свои собствени показатели или да събира показатели от базата данни на InfluxDB за изпращане до същия Influx или някъде другаде.
Данни
Какви изводи направихме от резултатите от пилотния проект?
Как можете да правите мониторинг?
На първо място, стекът TICK напълно оправда очакванията ни и ни даде дори повече възможности от това, което първоначално очаквахме.
Цялата функционалност, от която се нуждаехме, беше налице. Всичко, което направихме с него, работи без проблеми.
продуктивност
Основният проблем със стека TICK в безплатната версия е липсата на възможности за мащабиране. Това не беше проблем за нас.
Не събрахме точни данни/цифри за натоварването, но събрахме данни от около 30 скутера наведнъж.
Всеки от тях събра повече от три дузини показатели. В същото време бяха събрани регистрационни файлове от устройствата. Събирането и изпращането на данни се извършва на всеки 10 секунди.
Важно е да се отбележи, че след седмица и половина от пилота, когато по-голямата част от „детските проблеми“ бяха коригирани и най-важните проблеми вече бяха решени, трябваше да намалим честотата на изпращане на данни към сървъра 30 секунди. Това стана необходимо, защото трафикът на нашите LTE SIM карти започна бързо да изчезва.
По-голямата част от трафика беше консумиран от регистрационни файлове; самите показатели, дори и с интервал от 10 секунди, практически не го губеха.
В резултат на това след известно време напълно деактивирахме събирането на регистрационни файлове на устройства, тъй като специфичните проблеми вече бяха очевидни дори без постоянно събиране.
В някои случаи, ако прегледът на регистрационните файлове все още беше необходим, ние просто се свързвахме чрез WireGuard чрез VPN.
Ще добавя също, че всяка отделна среда беше отделена една от друга и описаното по-горе натоварване беше от значение само за производствената среда.
В средата за разработка създадохме отделен екземпляр на InfluxDB, който продължи да събира данни на всеки 10 секунди и не срещнахме проблеми с производителността.
TICK - идеален за малки и средни проекти
Въз основа на тази информация бих заключил, че стекът TICK е идеален за относително малки проекти или проекти, които определено не очакват HighLoad.
Ако нямате хиляди подове или стотици машини, дори един екземпляр на InfluxDB ще се справи добре с натоварването.
В някои случаи може да сте доволни от Influx Relay като примитивно решение за висока достъпност.
И, разбира се, никой не ви спира да настроите „вертикално“ мащабиране и просто да разпределите различни сървъри за различни типове показатели.
Ако не сте сигурни за очакваното натоварване на услугите за наблюдение или е гарантирано, че имате/ще имате много „тежка“ архитектура, не бих препоръчал използването на безплатната версия на стека TICK.
Разбира се, просто решение би било закупуването - но тук не мога да коментирам по някакъв начин, тъй като аз самият не съм запознат с тънкостите. Освен факта, че е много скъпо и определено не е подходящо за малки фирми.
В този случай днес бих препоръчал да погледнете към събиране на показатели чрез Victoria Metrics и регистрационни файлове с помощта на Loki.
Вярно, отново ще направя уговорката, че Loki/Grafana са много по-малко удобни (поради по-голямата им гъвкавост) от готовите TICK, но са безплатни.
Важно е: цялата описана тук информация се отнася за версия Influx 1.8, в момента Influx 2.0 е на път да бъде пуснат.
Въпреки че не съм имал възможност да го пробвам в бойни условия и е трудно да се направят изводи за подобрения, интерфейсът определено е станал още по-добър, архитектурата е опростена (без кондензатор и хронограф),
появиха се шаблони („убийствена функция“ - ). Но, за съжаление, в момента версия 2 го няма основното нещо, за което избрахме първата версия - няма събиране на логове.
Тази функционалност ще се появи и в Influx 2.0, но не можахме да намерим крайни срокове, дори и приблизителни.
Как да не правим IoT платформи (сега)
В крайна сметка, след като стартирахме пилота, ние сами сглобихме собствения си пълноценен IoT стек, при липса на алтернатива, подходяща за нашите стандарти.
Въпреки това, наскоро е наличен в бета версия — Жалко, че я нямаше, когато започнахме да правим проекта.
Напълно сме доволни от крайния резултат и платформата, базирана на Ansible + TICK + WireGuard, която сглобихме сами. Но днес бих препоръчал да разгледате по-отблизо Balena, преди да опитате сами да изградите своя собствена IoT платформа.
Защото в крайна сметка може да направи повечето от това, което направихме ние, а OpenBalena е безплатна и с отворен код.
Той вече знае как не само да изпраща актуализации, но и VPN вече е вграден и пригоден за използване в IoT среда.
И съвсем наскоро те дори пуснаха своите , който лесно се свързва с тяхната екосистема.
Хей, какво ще кажете за изчезналия скутер?
Така скутерът "Ралф" изчезна безследно.
Веднага хукнахме да погледнем картата в нашия „административен панел“ с данни за GPS показатели от InfluxDB.
Благодарение на данните от мониторинга лесно установихме, че скутерът е тръгнал от паркинга около 21:00 миналия ден, карал е около половин час до някаква зона и е бил паркиран до 5 сутринта до някаква немска къща.
След 5 часа сутринта не бяха получени никакви данни за наблюдение - това означаваше, че или допълнителната батерия е напълно разредена, или нападателят най-накрая е разбрал как да премахне интелигентния хардуер от скутера.
Въпреки това полицията все пак била извикана на адреса, където се намирал скутерът. Скутера го нямаше.
Собственикът на къщата обаче също беше изненадан от това, тъй като той всъщност се прибра с този скутер от офиса снощи.
Както се оказа, един от служителите по поддръжката пристигна рано сутринта и взе скутера, като видя, че допълнителната му батерия е напълно разредена и го закара (пеша) на паркинга. И допълнителната батерия отказа от влага.
Откраднахме скутера от себе си. Между другото, не знам как и кой тогава разреши проблема с полицейския случай, но наблюдението работи перфектно...
Източник: www.habr.com