Рік тому ми запустили пілотну версію промо проекту з .
Спочатку проект називався Road-To-Barcelona, пізніше став Road-To-Berlin (звідси зустрічаються на скріншотах R2B), а в результаті взагалі був названий xRide.
Основна ідея проекту була в наступному: замість того, щоб мати централізований сервіс прокату автомобілів або скутерів (йдеться про скутери aka електро-мотоцикли, а не kickscooter/самокати) ми хотіли зробити платформу для децентралізованої оренди. Про труднощі з якими ми зіткнулися .
Спочатку проект орієнтувався на автомобілі, але через терміни, вкрай довгі спілкування з виробниками та величезну кількість обмежень з безпеки, для пілота були обрані електричні скутери.
Користувач встановлював iOS або Android додаток на телефон, підходив до скутера, що йому сподобався, після чого телефон і скутер встановлювали peer-to-peer з'єднання, відбувався обмін ETH і користувач міг почати поїздку включивши скутер через телефон. Після завершення поїздки так само можна було здійснити оплату поїздки за рахунок Ethereum з гаманця користувача на телефоні.
Крім скутерів, користувач бачив у додатку "розумні зарядки", відвідавши яку користувач міг сам змінити поточну батарею, якщо вона розрядилася.
Так і виглядав наш пілот, запущений у вересні минулого року в двох містах Німеччини: Бонн і Берлін.
І ось, одного разу, в Бонні, рано-вранці наша команда підтримки (що знаходиться в локації для підтримки скутерів у працездатному стані) була піднята по тривозі: один із скутерів безвісти зник.
Як його знайти та повернути?
У цій статті я розповім про це, але спершу про те, як ми побудували нашу власну IoT платформу і як ми здійснювали моніторинг над нею.
Що й навіщо моніторити: скутери, інфраструктура, заряджання?
Отже, що ж ми хотіли моніторити у нашому проекті?
Насамперед це самі скутери — електроскутери самі по собі досить дорогі, не можна запускати такий проект, не будучи достатньо підготовленими, по можливості хочеться збирати якомога більше інформації про скутери: про їхнє місце розташування, рівень заряду, тощо.
Крім цього, хотілося б відстежувати стан нашої власної IT інфраструктури – бази, сервіси та все, що їм необхідно для роботи. Потрібно було відслідковувати і стан "розумних зарядок", якщо вони зламалися або в них скінчилися повні батареї.
Скутери
Що ж собою представляли наші скутери і що ми хотіли про них знати?
Перше, і найважливіше — GPS координати, оскільки завдяки їм ми можемо розуміти, де вони перебувають і куди рухаються.
Далі - заряд батареї, завдяки йому ми можемо визначати, що зарядка скутерів добігає кінця і відправити juicer'а або хоча б попередити користувача.
Звичайно, необхідно також перевіряти, що відбувається з нашими Hardware компонентами:
- чи працює Bluetooth?
- чи працює сам GPS модуль?
- так само у нас була проблема з тим, що GPS міг відсилати невірні координати та "залипати", а визначити це можна було лише на рівні додаткових перевірок на скутері.
та нотифікувати підтримку якнайшвидше для усунення проблеми
- так само у нас була проблема з тим, що GPS міг відсилати невірні координати та "залипати", а визначити це можна було лише на рівні додаткових перевірок на скутері.
І останнє: перевірки софтверної частини, починаючи з ОС та завантаження процесора, мережі та диска, закінчуючи вже більш специфічними для нас перевірками наших власних модулів (, ).
апаратні засоби
Що ж уявляла наша "залізна" частина?
Враховуючи максимально стислі терміни та необхідність швидкого прототипування, ми вибрали для себе максимально простий для реалізації та підбору компонентів варіант – Raspberry Pi.
Крім самого Rpi, ми мали кастомну борду (які ми самі розробили та замовляли в Китаї для прискорення процесу складання кінцевого рішення) та набір компонентів — реле (для включення/вимкнення скутера), зчитувач заряду батареї, модем, антени. Все це було компактно укомплектовано спеціальну коробочку "xRide box".
Слід також зазначити, що вся коробочка харчувалася додатковим павербанком, який, у свою чергу, харчувався від основної батареї скутера.
Це дозволяло використовувати моніторинг і вмикати скутер, навіть після закінчення поїздки, оскільки основна батарея вимикалася відразу після повороту ключа запалювання в положення "off".
Docker? Plain linux? і деплой
Повернемося до моніторингу, тож Raspberry — що ж ми маємо?
Одна з перших речей ми хотіли використовувати для прискорення процесу деплою, оновлення і доставки компонентів на фізичні пристрої був Docker.
На жаль, досить швидко стало зрозуміло, що Docker на RPi хоч і працює, але дає досить багато накладних витрат, зокрема з енергоспоживання.
Різниця з використанням "нативної" ОС нехай і не була настільки сильною, але все ж таки достатньою щоб ми побоювалися можливості занадто швидкої втрати заряду.
Другою причиною стала одна з бібліотек наших партнерів на Node.js (sic!) єдиний компонент системи, який не був написаний на Go/C/C++.
Автори бібліотеки не встигли вчасно надати робочу версію будь-якою з "нативних" мов.
Мало того, що нода сама по собі не є найелегантнішим рішенням для низькопродуктивних девайсів, так ще й сама бібліотека була дуже ненажерлива за ресурсами.
Ми зрозуміли, що при всьому бажанні використання Docker для нас буде надто великим оверхедом. Було зроблено вибір на користь нативної OS та роботи під нею безпосередньо.
OS
У результаті, як ОС ми, знову ж таки, обрали найпростіший варіант і використовували Raspbian (складання Debian для Pi).
Весь наш софт ми пишемо на Go, тому і основний hardware-агент модуль у нашій системі ми також написали на Go.
Саме він відповідає за роботу з GPS, Bluetooth, зчитування заряду, включення скутера, ітд.
Деплой
Тут же постало питання про необхідність реалізації механізму доставки оновлень на девайси (OTA) - як оновлень самого нашого агента/додатки, так і оновлення самої ОС/"прошивки" (оскільки нові версії агента могли вимагати оновлень ядра або компонентів системи, бібліотек тощо) .
Після досить довгого аналізу ринку з'ясувалося, що існує чимало рішень для доставки оновлень на девайс.
Від відносно простих утиліт, здебільшого орієнтованих на оновлення/dual-boot на кшталт swupd/SWUpdate/OSTree до повноцінних платформ на кшталт Mender та Balena.
Насамперед ми вирішили, що нас цікавлять саме end-to-end рішення, тому вибір одразу впав на платформи.
Сама була виключена через те, що фактично використовує той же Docker всередині свого balenaEngine.
Але зазначу, що незважаючи на це, зрештою ми постійно використовували їхній продукт для флешу прошивок на SD карти - проста і вкрай зручна утиліта для цього.
Тому в результаті вибір ліг на . Mender являє собою повноцінну платформу для збирання, доставки та встановлення прошивок.
Загалом платформа виглядає просто чудово, але нам знадобилося близько півтора тижня тільки на те, щоб зібрати правильну версію нашої прошивки за допомогою збирача mender.
І чим більше ми поринали в тонкощі його використання, тим більше ставало ясно, що на повноцінне його розгортання нам знадобилося б значно більше часу, ніж ми мали.
На жаль, наші стислі терміни призвели до того, що ми змушені були відмовитися від використання Mender і вибрати ще простіший нехай.
Неможливо
Найпростішим рішенням у нашій ситуації виявилося використання Ansible. Пари playbook'ів для початку було цілком достатньо.
Суть їх зводилася до того, що ми просто підключалися з хоста (CI сервер) по ssh до наших розбері та розливали на них оновлення.
На самому початку все було просто — потрібно було перебувати в єдиній мережі з пристроями, розливання йшло через Wi-Fi.
В офісі просто знаходилося десяток тестових малинок, підключених до однієї мережі, кожен пристрій мав статичну IP адресу так само вказану в Ansible Inventory.
Саме Ansible доставляв наш моніторинг-агент на кінцеві пристрої
3G / LTE
На жаль, такий варіант використання Ansible міг працювати тільки в режимі розробки, поки ми ще не мали реальних скутерів.
Тому що скутери, як ви розумієте, не стоять підключені до одного Wi-Fi роутера постійно чекаючи оновлення по мережі.
Насправді у скутерів взагалі не може бути ніякого з'єднання крім мобільного 3G/LTE (і то не завжди).
Це накладає відразу багато проблем та обмежень, на кшталт низької швидкості з'єднання та нестабільного зв'язку.
Але найголовніше — в мережі 3G/LTE ми не можемо просто сподіватися на статичний IP присвоєний в мережі.
Це частково вирішується деякими провайдерами SIM карт, є навіть спеціальні сімки, призначені для IoT пристроїв зі статичними IP адресами. Але ми не мали доступу до таких SIM карток і не могли використовувати IP адреси.
Звичайно, були ідеї робити якусь реєстрацію IP адрес aka service discovery десь на зразок Consul, але від подібних ідей довелося відмовитися, так як у нас в тестах IP адрес міг змінюватися занадто часто, що призводило до великої нестабільності роботи.
З цієї причини найбільш зручне використання для доставки метрик було б не з використанням pull моделі, де ми ходили б за потрібними метриками на пристрої, а push з доставкою метрик з пристрою безпосередньо на сервер.
VPN
Як вирішення цієї проблеми ми вибрали VPN — а саме .
Клієнти (скутери) на старті системи підключалися до сервера VPN і тримали можливість підключення до них. Цей тунель використовувався для доставки оновлень.
Теоретично, той же тунель можна було використовувати і для моніторингу, але таке підключення було складніше і менш надійним, ніж простий push.
Хмарні ресурси
Останнє — необхідно відстежувати наші хмарні сервіси та БД, тому що для них ми використовуємо Kubernetes, в ідеалі, щоб розгортання моніторингу в кластері було максимально простим. В ідеалі – з використанням , так як для деплою, ми здебільшого використовуємо його. І, само собою, для моніторингу хмари потрібно використовувати ті ж самі рішення, що й для самих скутерів.
дано
Фуф, ніби з описом розібралися, давайте складемо список того, що нам було потрібно в результаті:
- Швидке рішення, тому що моніторити необхідно вже під час процесу розробки
- Об'єм/кількість — потрібна безліч метрик
- Збір логів обов'язковий
- Надійність – дані критично важливі для успіху запуску
- Не можна використовувати pull модель - потрібен push
- Потрібен єдиний моніторинг не лише заліза, а й хмари
Кінцева картинка виглядала приблизно так
Вибір стеку
Отже, перед нами постало питання вибору стека для моніторингу.
В першу чергу, ми шукали найбільш повноцінне all-in-one рішення, яке одночасно покривало всі наші вимоги, але при цьому і було б досить гнучким щоб підігнати його використання під наші потреби. Все-таки, у нас було багато обмежень накладених на нас залізом, архітектурою та термінами.
Існує безліч рішень для моніторингу, починаючи повноцінними системами на кшталт , або і закінчуючи вже готовими рішеннями щодо Fleet management.
Спочатку останні здавалися ідеальним для нас рішенням, але в одних не було повноцінного моніторингу, в інших були сильно урізані можливості безкоштовних версій, а треті просто не покривали наші "хотілки" або не були досить гнучкими для підгонки під наші сценарії. Дехто просто застарів.
Після аналізу якоїсь кількості подібних рішень ми швидко дійшли висновку, що простіше і швидше буде зібрати подібний стек самостійно. Так, це буде трохи складніше, ніж розгортання повністю готової Fleet management платформи, але нам не доведеться йти на компроміси.
Майже напевно, у всій великій кількості рішень і є вже готове яке цілком би нам підійшло, але в нашому випадку значно швидше було зібрати якийсь стек самостійно і підігнати "під себе", ніж тестувати готові продукти.
При цьому, ми не прагнули збирати цілу платформу для моніторингу самостійно, а шукали максимально функціональні "готові" стеки, тільки з можливістю їх гнучко налаштовувати.
(B) ELK?
Перше рішення, яке реально розглядалося, — широко відомий ELK стек.
Насправді він має називатися BELK, адже починається все з Beats -
Звичайно, ELK це одне з найвідоміших і найпотужніших рішень у галузі моніторингу, а вже в зборі та обробці логів, так і саме.
Ми мали на увазі, що ELK буде використовуватися для збору логів і, так само як довготривале сховище метрик, отриманих з Prometheus.
Для візуалізації можна використовувати Grafan'у.
Насправді, новий ELK стек вміє збирати метрики і самостійно (metricbeat), Kibana так само вміє показувати їх.
Але все-таки спочатку ELK виріс із ліг і поки функціонал метрик має ряд серйозних недоліків:
- Значно повільніше Prometheus
- Інтегрується у значно меншу кількість місць ніж Prometheus
- Складно налаштувати алертинг за ними
- Метрики займають велику кількість місця
- Налаштування дашбордів з метриками в Kiban'і значно складніше Grafan'и
Загалом, метрики в ELK важкі і поки що не такі зручні як в інших рішеннях, яких зараз насправді значно більше ніж просто Prometheus: TSDB, Victoria Metrics, Cortex і т.д. Звичайно, дуже хотілося б мати відразу повноцінне all-in-one рішення, але у випадку з metricbeat виходило занадто багато компромісів.
Та й у самого ELK стека є низка непростих моментів:
- Він важкий, часом дуже, якщо у вас збирається досить велика кількість даних
- Його потрібно "вміти готувати" - скалювати його необхідно, але робиться це нетривіально
- Урізана безкоштовна версія - у безкоштовній версії немає нормального алертингу, на момент вибору не було і аутентифікації
Треба сказати, що останнім часом з останнім пунктом стало краще і крім (У тому числі автентифікація) почала змінюватися сама модель прайсингу.
Але на момент, коли ми збиралися розгортати це рішення, алертингу не було зовсім.
Можливо, можна було спробувати зібрати щось із використанням ElastAlert або інших community рішень, але все ж таки вирішили розглянути інші альтернативи.
Loki - Grafana - Prometheus
На даний момент непоганим рішенням може бути складання стека моніторингу на основі суто Prometheus як постачальника метрик, Loki для логів, а для візуалізації можна використовувати ту саму Grafana.
На жаль, на момент старту прода пілота проекту (вересень-жовтень 19ого року) Loki ще перебував у бета версії 0.3-0.4, а на момент старту розробки взагалі не міг розглядатися як produtcion рішення.
Я поки що не маю досвіду реального використання Loki у серйозних проектах, але можу сказати, що Promtail (агент для збору логів) чудово працює як для bare-metal, так і для подів у kubernetes.
ТИК
Мабуть, найбільш гідною (єдиною?) Повнофункціональною альтернативою ELK стеку зараз можна назвати тільки TICK стек - Telegraf, InfluxDB, Chronograf, Kapacitor.
Я опишу всі компоненти нижче докладніше, але загалом ідея така:
- Telegraf - агент для збирання метрик
- InfluxDB - база даних метрик
- Kapacitor - обробник метрик в реальному часі для аллертингу
- Chronograf — веб-панель для візуалізації
Для InfluxDB, Kapacitor і Chronograf є офіційні helm чарти, які ми використовували для їхнього розгортання.
Слід зазначити, що у свіжій версії Influx 2.0 (beta) Kapacitor та Chronograf стали частиною InfluxDB і більше не існують окремо
Телеграф
— це дуже легковажний агент для збирання метрик на кінцевій машині.
Він вміє моніторити величезну кількість всього, від до
сервера .
У нього є низка класних переваг:
- Швидкий та легкий (написаний на Go)
- Їсть мінімальну кількість ресурсів
- Push метрик за замовчуванням
- Збирає всі необхідні метрики
- Системні метрики без будь-яких налаштувань
- Хардварні метрики на кшталт інформації з датчиків
- Дуже легко додавати власні метрики
- Багато плагінів "з коробки"
- Збирає логи
Так як push метрик був для нас необхідний, решта переваг була більш ніж приємними доповненнями.
Складання логів самим агентом так само дуже зручна, так як немає необхідності підключати додаткові утиліти для тейлінгу логів.
Influx пропонує максимально зручний досвід роботи з логами якщо ви використовуєте .
Telegraf взагалі відмінний агент для складання метрик, навіть якщо ви не використовуєте весь решту ICK стек.
Багато хто схрещує його і з ELK і з різними іншими time-series базами за зручністю, тому що він вміє писати метрики майже куди завгодно.
InfluxDB
InfluxDB - основне ядро TICK стека, а саме time-series база даних для метрик.
Крім метрик Influx також може зберігати і логи, хоча, по суті логи для нього це лише такі ж метрики, тільки замість звичайних числових показників основну функцію несе рядок тексту лога.
InfluxDB теж написаний на Go і працює, за відчуттями, значно швидше, порівняно з ELK на нашому (не найпотужнішому) кластері.
До крутих переваг Influx я б також відніс дуже зручне і багате API для запитів до даних, які ми дуже активно використовували.
Недоліки - $$$ або скалірування?
У TICK стека є лише один виявлений нами недолік - він дорогий. Навіть дуже.
А що є у платній версії, чого немає у безкоштовній?
Наскільки нам вдалося зрозуміти, єдине, чим відрізняється платна версія TICK стека від безкоштовної — можливості скалірування.
А саме - підняти кластер з High availability можна тільки в .
Хочете повноцінне HA - потрібно або платити, або городити якісь милиці. Є пара рішень спільноти - наприклад схоже на грамотне рішення, але написано що не підходить для продакшена, а також
- Просте рішення з прокачуванням даних через NATS (його теж доведеться скалювати, але це можна вирішити).
Шкода, але обидва вони, схоже, занедбані — немає свіжих коммітів, припускаю, що справа в найближчому майбутньому виході нової версії Influx 2.0 в якій багато буде інакше (поки інформації про скалювання в ній немає).
Офіційно для безкоштовної версії існує - фактично це примітивне HA, але тільки через балансування,
оскільки всі дані будуть писатися в усі інстанси InfluxDB за load balancer'ом.
У нього є деякі на кшталт потенційних проблем із перезаписом точок та необхідності створювати бази для метрик заздалегідь
(що при звичайній роботі з InfluxDB відбувається автоматично).
До того ж Це означає додаткові накладні витрати на дупліковані метрики (і обробка та зберігання), які могли бути непотрібними, але розділити їх можливості немає.
Victoria Metrics?
У результаті, незважаючи на те, що у всьому крім платного скалювання TICK стек нас повністю влаштовував, ми вирішили подивитися чи немає безкоштовних рішень, якими можна замінити InfluxDB базу, залишивши при цьому інші компоненти T_CK.
Time-series баз чимало, але найбільше подає надії - Victoria Metrics, у неї цілий ряд плюсів:
- Швидка та легка, принаймні за результатами
- Є кластерна версія, про яку зараз навіть є хороші відгуки
- Вона можеш шардуватися
- Підтримує InfluxDB протокол
Ми не збиралися будувати повністю кастомний стек на основі Victoria і основна надія була на те, що ми зможемо скористатися нею як заміною drop-in для InfluxDB.
На жаль, це неможливо, незважаючи на те, що підтримується протокол InfluxDB, це працює тільки для запису метрик - "назовні" доступно тільки Prometheus API, а отже, нацькувати Chronograf на неї не вийде.
Більше того, для метрик підтримуються лише числові значення (ми використовували рядкові значення для кастомних метрик — про це у розділі ).
Очевидно, що з тієї ж причини VM не може зберігати логи, як це робить Influx.
Також, слід зазначити, що на момент пошуку оптимального рішення Victoria Metrics ще не була такою популярною, документація була значно меншою і функціонал був слабшим.
(Не пригадую докладного опису кластерної версії та шардування).
Вибір бази
В результаті було прийнято рішення, що для пілота ми все ж таки обмежимося одиночною нодою InfluxDB.
Основних причин такого вибору було кілька:
- Нам дуже подобався функціонал TICK стека цілком
- Ми вже встигли його розгорнути і воно чудово працювало
- Терміни стискали і не залишалося багато часу тестувати інші варіанти
- У нас не очікувалося такого великого навантаження
Скутерів у нас для першої фази пілота було не так багато, і тестування під час розробки не виявило жодних проблем із продуктивністю.
Тому ми вирішили, що для даного проекту нам цілком вистачить і одна нода Influx без необхідності скалювання (cм висновки в кінці).
Зі стеком і базою вирішили — тепер про решту компонентів TICK стеку.
Kapacitor
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 якщо потрібно - але мені ніколи не доводилося їх чіпати після створення на UI).
У Kibana набагато багатші можливості по створенню дашбордів і контролів для них, але і UX для таких операцій дуже складний.
Потрібно непогано розібратися, щоб створити собі зручний дашборд. І хоча функціонал дашбордів у Chronograf менший, робити і налаштовувати їх значно простіше.
Самі дашборди, крім приємного візуального стилю, фактично нічим від дашбордів у Grafana чи Kibana не відрізняються:
Так виглядає те саме вікно запитів:
Важливо, крім іншого, знаючи типи полів у базі InfluxDB хронограф іноді сам може автоматично допомагати вам з написанням Query або вибором правильної функції агрегації типу mean.
Ну і звичайно, Chronograf максимально зручний для перегляду логів. Виглядає це так:
За замовчуванням Influx логів заточує під використання syslog і тому в них є важливий параметр - severity.
Особливо корисний графік зверху, на ньому можна побачити помилки, що виникають, і кольором відразу чітко видно якщо severity вищий.
Кілька разів таким чином ми ловили важливі баги, зайшовши в перегляд логів за останній тиждень і побачивши червоний спайк.
Звичайно, в ідеалі було б настроїти алертинг на такі помилки, благо у нас уже було все для цього.
Ми навіть на якийсь час включали це, але, в процесі підготовки пілота з'ясувалося, що у нас виникає досить багато помилок (у тому числі системних на кшталт недоступності LTE мережі), які надто сильно "спам'ятають" у Slack канал, при цьому не несучи великої користі.
Правильним рішенням було б опрацювати більшість подібних типів помилок, налаштувати для них severity і вже потім включити алертинг.
Таким чином, у Slack потрапляли б тільки нові або важливі помилки. На такий сетап банально забракло часу в умовах стислих термінів.
аутентифікація
Окремо варто згадати те, що Chronograf підтримує OAuth і OIDC як аутентифікацію.
Це дуже зручно, тому що дозволяє легко прикрутити його до вашого сервера та зробити повноцінне SSO.
У нашому випадку – сервером був — він використовувався для підключення до моніторингу, але при цьому сервер використовувався і для аутентифікації скутерів і запитів на back-end.
"Адмінка"
Останній компонент, який я опишу - це наша самописна "адмінка" на Vue.
Загалом це просто окремий сервіс, який відображає інформацію про скутери одночасно з наших власних баз даних, мікросервісів та дані метриків з InfluxDB.
Крім того, туди було винесено багато адміністративних функцій, на кшталт екстреного перезавантаження або віддаленого відкриття замку для команди підтримки.
Також там були карти. Я вже згадував, що ми починали з Grafana замість Chronograf — тому що для Grafana у вигляді плагінів доступні карти, на яких можна було дивитися координати скутерів. На жаль, можливості віджетів карт для Grafana дуже обмежені, і в результаті було набагато простіше за кілька днів написати свій власний веб-додаток з картами, для того щоб не тільки бачити координати в даний момент, але і відображати маршрут, пройдений скутером, вміти фільтрувати дані на карті, ітд (весь той функціонал, який ми не змогли б налаштувати у простому дашборді).
Один із вже згаданих плюсів Influx – можливість легко створювати свої власні метрики.
Це дозволяє використовувати його для величезної кількості сценаріїв.
Ми намагалися записувати туди всю корисну інформацію: заряд батареї, стан замку, працездатність датчиків, bluetooth, GPS, багато інших healthcheck'ів.
Все це ми й відбивали на адмін панелі.
Звичайно, найголовнішим критерієм для нас був стан роботи скутера - фактично Influx перевіряє це сам і показує в розділі Nodes "зеленими лампочками".
Робиться це функцією — ми використовували її ж для розуміння працездатності нашої коробочки та відсилання тих самих алертів у Slack.
До речі, ми називали скутери на ім'я персонажів із Сімпсонів — так їх було зручно відрізняти один від одного
Та й взагалі так було веселіше. Постійно звучали фрази на кшталт "Хлопці - Смітерс помер!"
Строкові метрики
Важливо, що InfluxDB дозволяє зберігати не тільки числові значення, як у Victoria Metrics.
Здавалося б, це не так важливо — адже якщо не рахувати ліг, будь-які метрики можна зберігати у вигляді чисел (лише додати мапінг для відомих станів — свого роду enum)?
У нашому випадку був як мінімум один сценарій, коли рядкові метрики були дуже корисні.
Так вийшло, що постачальник наших "розумних зарядок" був стороннім, ми не мали ніякого контролю над процесом розробки та інформацією, яку ці зарядки можуть постачати.
В результаті API зарядок було далеко від ідеалу, але основною проблемою було те, що ми не завжди могли зрозуміти їхній стан.
Тут на допомогу прийшов Influx. Ми записували приходящий нам рядковий status в полі бази InfluxDB без змін.
Якийсь час туди потрапляли лише значення виду "online" та "offline", на основі чого у нас в адмінці відображалася інформація, а в Slack надходили повідомлення. Однак у якийсь момент туди стали потрапляти також значення виду "disconnected".
Як пізніше з'ясувалося, цей статус надсилався одноразово після втрати зв'язку, якщо зарядка не могла встановити з'єднання із сервером після якоїсь кількості спроб.
Таким чином, якби ми використовували лише фіксований набір значень, ми могли б не побачити цих змін у прошивці в потрібний момент часу.
Та й взагалі, рядкові метрики дають значно більше можливостей для використання, записувати в них можна практично будь-яку інформацію. Хоча, звичайно, використовувати цей інструмент також потрібно акуратно.
Крім звичайних метрик, ми також записували в InfluxDB інформацію про GPS локації. Це було неймовірно зручно для моніторингу місцезнаходження скутерів у нашій адмінській панелі.
Фактично ми завжди знали де і який скутер був у потрібний нам момент часу.
Дуже сильно нам це стало в нагоді, коли ми розшукували скутер (дивися висновки в кінці).
Моніторинг інфраструктури
Крім самих скутерів, нам необхідно було моніторити і всю нашу (досить велику) інфраструктуру.
Дуже узагальнена архітектура виглядала приблизно так:
Якщо виділити чисто стек моніторингу, він виглядає так:
З того, що ми хотіли б перевіряти у хмарі, це:
- Бази даних
- Плащ-ключ
- Мікросервіси
Оскільки всі наші хмарні послуги знаходяться в Kubernetes, то було б непогано збирати інформацію і про його стан.
На щастя, Telegraf "з коробки" може збирати величезну кількість метриків про стан Kubernetes кластера, а Chronograf відразу пропонує для цього гарні дашборди.
Ми стежили в основному за працездатністю подів та споживанням пам'яті. У разі падіння – алерти у Slack.
Для відстеження подів у Kubernetes є два шляхи: DaemonSet та Sidecar.
Обидва способи докладно описані .
Ми використовували Telegraf Sidecar і, крім метрик, збирали логи подів.
У нашому випадку з логами довелося повозиться. Незважаючи на те, що Telegraf вміє витягувати логи з Docker API, ми хотіли мати однакове збирання логів з нашими кінцевими пристроями і налаштовували для цього syslog для контейнерів. Можливо, це рішення не було красивим, але нарікань у його роботі не було і логи добре відображалися у Chronograf'e.
Моніторити моніторинг?
Зрештою постало споконвічне питання моніторингу систем моніторингу, але на щастя, чи, на жаль, на це у нас просто не вистачило часу.
Хоча Telegraf легко вміє відправляти власні метрики або збирати метрики InfluxDB бази для відправки або в той же Influx, або кудись ще.
Висновки
Які висновки ми зробили за результатами пілота?
Як можна робити моніторинг
Насамперед — TICK стек повністю виправдав наші очікування, і дав нам навіть більше можливостей, аніж ті, на які ми розраховували спочатку.
Весь функціонал, який нам був необхідний, був присутній. Все, що ми з ним робили — працювало без проблем.
Продуктивність
Основна проблема TICK стеку в безкоштовній версії - відсутність можливостей зі скалювання. Для нас це не стало проблемою.
Ми не збирали точних даних/цифр про навантаження, але ми збирали дані з приблизно 30 скутерів одночасно.
Кожен із них збирав понад три десятки метрик. Одночасно збиралися логи із пристроїв. Збір та відправлення даних відбувалися кожні 10 секунд.
Важливо відзначити, що через півтора тижні пілота, коли основну масу "дитячих болячок" вдалося виправити і найважливіші проблеми вже було вирішено, нам довелося знизити частоту відправлення даних на сервер до 30 секунд. Це стало необхідно, тому що трафік на наших картах LTE почав швидко танути.
Основну масу трафіку з'їдали логи, самі метрики навіть із 10-секундним інтервалом практично не витрачали його.
У результаті, ще через якийсь час ми зовсім відключили збір логів на пристроях, оскільки конкретні проблеми вже були очевидні і без постійного збору.
У деяких випадках, якщо перегляд логів все ж таки був необхідний - ми просто підключалися через WireGuard по VPN.
Ще додам, що кожен окремий environment у нас був відокремлений один від одного, і вищеописане навантаження було актуальним тільки для продакшен середовища.
У середовищі розробників у нас був піднятий окремий інстанс InfluxDB, який продовжував збирати дані раз на 10 секунд і ми не уткнулися в будь-які проблеми з продуктивністю.
TICK - ідеально для невеликих-середніх проектів
На основі цієї інформації я зробив би висновок, що TICK стек ідеально підходить для відносно невеликих проектів або проектів, у яких точно не очікується будь-якого HighLoad.
Якщо у вас немає тисяч подів або сотень машин - навіть один інстанс InfluxDB чудово впорається з навантаженням.
У деяких випадках вас може влаштувати Influx Relay як примітивне рішення щодо High Availability.
І, само собою, ніхто не заважає вам налаштовувати "вертикальне" скалірування та просто виділити різні сервери під різні типи метрик.
Якщо ж ви не впевнені в очікуваному навантаженні на сервіси моніторингу, або у вас гарантовано є/буде дуже "важка" архітектура - безкоштовну версію стека TICK використовувати я б не порекомендував.
Звичайно, простим рішенням було б придбання — але тут я не можу якось прокоментувати, бо сам не знайомий із тонкощами. Крім того, це дуже дорого і точно не підійде для дрібних компаній.
У такому разі, на сьогоднішній день, я б порекомендував подивитися у бік збору метрик через Victoria Metrics та логів за допомогою Loki.
Щоправда, знову обмовлюся, що Loki/Grafana значно менш зручні (через свою більшу універсальність) ніж готовий TICK, зате вони безкоштовні.
Важливо: вся описана тут інформація актуальна для версії Influx 1.8, зараз ось-ось має вийти в реліз Influx 2.0.
Поки не довелося спробувати його в бойових умовах і складно робити висновки про поліпшення, ще краще став інтерфейс, спростилася архітектура (без kapacitor і chronograf),
з'явилися темплейти ("кілер фіча") ). Але, на жаль, зараз у версії 2 немає ключової речі, за якою ми вибрали першу версію — немає збирання логів.
Цей функціонал у Influx 2.0 теж з'явиться, але будь-яких термінів, навіть зразкових, знайти не вдалося.
Як не потрібно робити IoT платформи (тепер)
Зрештою, запустивши пілот ми самі зібрали свій повноцінний IoT стек, через відсутність відповідної за нашими мірками альтернативи.
Однак, з недавнього часу у Beta версії доступна — шкода її не було, коли ми починали робити проект.
Кінцевий результат та платформа на основі Ansible + TICK + WireGuard, яку ми зібрали самостійно нас повністю влаштовує. Але на сьогоднішній день, я б порекомендував уважніше подивитися на Balena, перш ніж намагатися зібрати свою IoT платформу самим.
Тому що, зрештою, вона вміє робити більшу частину того, що ми робили, при цьому OpenBalena безкоштовна, а код відкритий.
Воно вже вміє не просто розсилати оновлення, а й VPN там уже вшитий і заточений під використання в середовищі IoT.
А зовсім недавно — вони взагалі випустили свою , яка легко підключається до їхньої екосистеми.
Гей, а що зі зниклим скутером?
Отже скутер, "Ральф", безвісти зник.
Ми відразу побігли дивитися карту в нашій "адмінці", з даними GPS метрик з InfluxDB.
Завдяки даним моніторингу, ми легко визначили, що паркування скутер залишив близько 21:00 минулого дня, проїхав десь півгодини до якогось району і був запаркований до 5-ї ранку поряд з якимсь німецьким будинком.
Після 5-ї ранку даних моніторингу не надходило - це означало або повний розряд додаткової батареї, або зловмисник здогадався витягнути розумну начинку зі скутера.
Незважаючи на це, за тією адресою, де знаходився скутер, все ж таки була викликана поліція. Скутера там не було.
Однак власник будинку теж був здивований, оскільки він дійсно вчора ввечері приїхав на цьому скутері з офісу додому.
Як з'ясувалося, один із співробітників підтримки приїхав рано-вранці і забрав скутер, побачивши, що в нього повністю розрядилася додаткова батарея і повіз його (пішки) на паркування. А додаткова батарея вийшла з ладу через попадання вологи.
Ми вкрали скутер у себе. Не знаю, до речі, як і хто потім розрулював питання у поліції, але моніторинг відпрацював відмінно…
Джерело: habr.com