Год назад мы запустили пилотную версию промо-проекта для децентрализованная аренда электросамокатов .
Изначально проект назывался Road-To-Barcelona, позже он стал Road-To-Berlin (отсюда на скриншотах R2B), а в итоге получил название xRide. Основная идея проекта заключалась в следующем: вместо централизованного сервиса проката автомобилей или самокатов (речь идет о самокатах, они же электромотоциклах, а не самокатах/самокатах) мы хотели сделать платформу для децентрализованной аренды.
О трудностях, с которыми мы столкнулись уже писал ранее .
Изначально проект был ориентирован на автомобили, но из-за сроков, чрезвычайно долгого общения с производителями и огромного количества ограничений по безопасности в качестве пилота были выбраны электросамокаты.
Пользователь устанавливал на телефон приложение iOS или Android, подъезжал к понравившемуся самокату, после чего между телефоном и самокатом устанавливалось одноранговое соединение, происходил обмен ETH и пользователь мог начать поездку, включив самокат через телефон.
По окончании поездки также можно было оплатить поездку с помощью Ethereum из кошелька пользователя на телефоне.
Помимо самокатов, пользователь увидел в приложении «умные зарядные устройства», посетив которые, пользователь мог сам поменять текущий аккумулятор, если он разряжен.
Примерно так выглядел наш пилот, запущенный в сентябре прошлого года в двух немецких городах: Бонне и Берлине.
И вот однажды в Бонне рано утром наша служба поддержки (находящаяся на месте для поддержания самокатов в рабочем состоянии) получила предупреждение: один из самокатов бесследно исчез.
Как его найти и вернуть? В этой статье я расскажу об этом, но сначала — о том, как мы строили собственную IoT-платформу и как мы за ней следили.
Что и зачем мониторить: самокаты, инфраструктуру, зарядные станции?
Итак, что же мы хотели отслеживать в нашем проекте? В первую очередь это сами самокаты – сами по себе электросамокаты довольно дорогие, без достаточной подготовки такой проект не запустить; по возможности нужно собрать как можно больше информации о самокатах: об их местонахождении, уровне заряда и т. д. Кроме того, хотелось бы следить за состоянием собственной ИТ-инфраструктуры — баз данных, сервисов и всего, что им нужно для работы.Также необходимо было следить за состоянием «умных зарядных устройств» на случай, если они сломаются или разрядятся аккумуляторы.
Скутеры
Какими были наши самокаты и что мы хотели о них знать?
Первое и самое важное – это GPS-координаты, поскольку благодаря им мы можем понять, где они находятся и куда движутся.
Дальше идет заряд аккумулятора, благодаря чему мы можем определить, что зарядка самоката подходит к концу и отправить соковыжималку или хотя бы предупредить пользователя.
Конечно, также необходимо проверить, что происходит с нашими аппаратными компонентами:
- блютуз работает?
- сам модуль GPS работает?
- Еще у нас была проблема с тем, что GPS мог отправлять неправильные координаты и зависать, а определить это можно было только путем дополнительных проверок на самокате,
и как можно скорее сообщите в службу поддержки, чтобы решить проблему.
- Еще у нас была проблема с тем, что GPS мог отправлять неправильные координаты и зависать, а определить это можно было только путем дополнительных проверок на самокате,
и как можно скорее сообщите в службу поддержки, чтобы решить проблему.
Аппаратное обеспечение
В чем заключалась наша «железная» часть? Учитывая максимально короткие сроки и необходимость быстрого прототипирования, мы выбрали самый простой вариант реализации и подбора компонентов — Raspberry Pi. Помимо самого Rpi, у нас была кастомная плата (которую мы сами разработали и заказали в Китае, чтобы ускорить процесс сборки финального решения) и набор компонентов — реле (для включения/выключения самоката), считыватель заряда аккумулятора, модем, антенны.
Все это было компактно упаковано в специальный «коробку xRide».
Также следует отметить, что вся коробка питалась от дополнительного павербанка, который, в свою очередь, питался от основного аккумулятора самоката.
Это позволило использовать мониторинг и включать самокат даже после окончания поездки, поскольку основной аккумулятор отключался сразу после поворота ключа зажигания в положение «выключено».
Докер? Обычный Линукс? и развертывание
Вернёмся к мониторингу, итак Raspberry — что мы имеем? Одной из первых вещей, которые мы хотели использовать для ускорения процесса развертывания, обновления и доставки компонентов на физические устройства, был Docker. К сожалению, быстро выяснилось, что Docker на RPi хоть и работает, но имеет много накладных расходов, особенно в плане энергопотребления.Разница при использовании «родной» ОС хоть и не такая сильная, но все же была достаточной, чтобы нас опасаться возможности слишком быстрой потери заряда.
Второй причиной стала одна из наших партнёрских библиотек на Node.js (sic!) — единственном компоненте системы, написанном не на Go/C/C++.
Авторы библиотеки не успели предоставить рабочую версию ни на одном из «родных» языков.
Мало того, что сам узел — не самое элегантное решение для малопроизводительных устройств, так еще и сама библиотека была очень ресурсоёмкой.
Мы поняли, что даже если бы мы захотели, использование Docker было бы для нас слишком накладным.
Выбор был сделан в пользу родной ОС и работы непосредственно под ней.
Операционные системы
В итоге мы снова выбрали самый простой вариант ОС и использовали Raspbian (сборка Debian для Pi).Мы пишем все наше программное обеспечение на Go, поэтому мы также написали на Go основной модуль аппаратного агента в нашей системе.
Именно он отвечает за работу с GPS, Bluetooth, считывание заряда, включение самоката и т.д.
Развертывать
Сразу возник вопрос о необходимости реализации механизма доставки обновлений на устройства (OTA) - как обновлений самого нашего агента/приложения, так и обновлений самой ОС/прошивки (поскольку новые версии агента могут требовать обновления ядра или системные компоненты, библиотеки и т. д.).После довольно длительного анализа рынка выяснилось, что существует довольно много решений для доставки обновлений на устройство.
От относительно простых, в основном ориентированных на обновление/двойную загрузку утилит, таких как swupd/SWUpdate/OSTree, до полноценных платформ, таких как Mender и Balena. В первую очередь мы решили, что нас интересуют комплексные решения, поэтому выбор сразу пал на платформы.
Сама Балена был исключен из-за того, что внутри своего balenaEngine он фактически использует тот же Docker. Но отмечу, что несмотря на это, мы в итоге постоянно пользовались их продуктом.
Балена Этчер для прошивки на SD карты - простая и крайне удобная утилита для этого.
Поэтому в итоге выбор пал на Мендер .
Mender — это полноценная платформа для сборки, доставки и установки прошивок.
В целом платформа выглядит великолепно, но нам потребовалось около полутора недель только для того, чтобы собрать правильную версию нашей прошивки с помощью mender builder. И чем больше мы погружались в тонкости его использования, тем яснее становилось, что для его полноценного развертывания нам понадобится гораздо больше времени, чем у нас было.
Увы, наши сжатые сроки привели к тому, что мы были вынуждены отказаться от использования Mender и выбрать еще более простой.
Анзибль
Самым простым решением в нашей ситуации было использование Ansible. Для начала хватило пары учебников.Суть их заключалась в том, что мы просто подключались с хоста (CI-сервера) по ssh к нашим rasberry и раздавали им обновления.
В самом начале всё было просто — нужно было находиться в одной сети с устройствами, заливка осуществлялась через Wi-Fi. В офисе было просто с десяток тестовых малин, подключенных к одной сети, каждое устройство имело статический IP-адрес, также указанный в Ansible Inventory. Именно Ansible доставил наш агент мониторинга на конечные устройства.
3G/ЛТЕ
К сожалению, этот вариант использования Ansible мог работать только в режиме разработки до того, как у нас появились настоящие скутеры.Потому что самокаты, как вы понимаете, не сидят подключенными к одному Wi-Fi роутеру, постоянно ожидая обновлений по сети.
На самом деле у скутеров вообще не может быть никакой связи, кроме мобильного 3G/LTE (да и то не постоянно).
Это сразу накладывает множество проблем и ограничений, таких как низкая скорость соединения и нестабильная связь.
Но самое главное, что в сети 3G/LTE мы не можем просто полагаться на статический IP-адрес, назначенный сети.
Частично это решается некоторыми поставщиками SIM-карт; существуют даже специальные SIM-карты, предназначенные для IoT-устройств со статическими IP-адресами.
Но у нас не было доступа к таким SIM-картам и мы не могли использовать IP-адреса.
Конечно, были идеи сделать какую-то регистрацию IP-адресов aka service Discovery где-нибудь наподобие Consul, но нам пришлось отказаться от таких идей, так как в наших тестах IP-адрес мог меняться слишком часто, что приводило к большой нестабильности.
По этой причине наиболее удобным способом доставки метрик будет не использование модели pull, когда мы будем обращаться к устройствам за необходимыми метриками, а push, доставляя метрики с устройства непосредственно на сервер.
VPN
В качестве решения этой проблемы мы выбрали VPN – конкретно Wireguard .Клиенты (скутеры) при старте системы подключались к VPN-серверу и имели возможность к ним подключиться.
Этот туннель использовался для доставки обновлений.
Теоретически тот же туннель можно было использовать для мониторинга, но такое соединение было более сложным и менее надежным, чем простой push.
Облачные ресурсы
Наконец, необходимо следить за нашими облачными сервисами и базами данных, поскольку для них мы используем Kubernetes, в идеале, чтобы развертывание мониторинга в кластере было максимально простым.В идеале, используя Шлем , так как для развертывания мы в большинстве случаев его используем.
И, конечно, для мониторинга облака нужно использовать те же решения, что и для самих самокатов.
Данный
Уф, с описанием вроде разобрались, давайте в итоге составим список того, что нам нужно:- Быстрое решение, поскольку мониторинг необходим уже в процессе разработки.
- Объем/количество – необходимо много показателей
- Требуется сбор журналов
- Надежность: данные имеют решающее значение для успеха запуска
- Вы не можете использовать модель pull — вам нужен push
- Нам нужен единый мониторинг не только оборудования, но и облака
Выбор стека
Итак, перед нами встал вопрос выбора стека мониторинга.Прежде всего, мы искали наиболее полное решение «все в одном», которое одновременно покрывало бы все наши требования, но в то же время было достаточно гибким, чтобы адаптировать его использование к нашим потребностям.
Тем не менее, у нас было много ограничений, налагаемых на нас аппаратным обеспечением, архитектурой и сроками.
Существует огромное разнообразие решений для мониторинга, начиная с полноценных систем, таких как Нагиос , глазурь или Заббикс и заканчивая готовыми решениями по управлению автопарком.
Изначально последний казался нам идеальным решением, но у некоторых не было полноценного мониторинга, у других были сильно ограничены возможности бесплатных версий, а третьи просто не покрывали наши «хотелки» или были недостаточно гибкими, чтобы соответствовать нашим сценариям.
Некоторые просто устарели.
Проанализировав ряд подобных решений, мы быстро пришли к выводу, что проще и быстрее будет собрать подобный стек самостоятельно.
Да, это будет немного сложнее, чем развернуть полностью готовую платформу управления автопарком, но нам не придется идти на компромиссы.
Почти наверняка среди всего огромного обилия решений уже есть готовое, которое нас полностью устроило бы, но в нашем случае гораздо быстрее было собрать некий стек самостоятельно и настроить его «под себя», чем тестирование готовой продукции.
При этом мы не стремились сами собрать целую платформу мониторинга, а искали максимально функциональные «готовые» стеки, только с возможностью их гибкой настройки.
(Б)ЛОСЬ?
Первым решением, которое действительно рассматривалось, был всем известный стек ELK. На самом деле его следовало бы назвать BELK, потому что все начинается с Beats. — https://www.elastic.co/what-is/elk-stack
Безусловно, ELK — одно из самых известных и мощных решений в области мониторинга, а тем более сбора и обработки логов.
Мы предполагали, что ELK будет использоваться для сбора логов, а также долгосрочного хранения метрик, полученных от Prometheus. Для визуализации вы можете использовать Grafan. Фактически, новый стек ELK может собирать метрики самостоятельно (metricbeat), а Kibana ещё и отображать их.
Но все же ELK изначально вырос из логов и пока функционал метрик имеет ряд серьезных недостатков:
- Значительно медленнее, чем Прометей
- Интегрируется в гораздо меньшее количество мест, чем Prometheus.
- Для них сложно настроить оповещения
- Метрики занимают много места
- Настроить дашборды с метриками в Kiban гораздо сложнее, чем в Grafan.
Конечно, очень хотелось бы сразу иметь полноценное решение «все в одном», но в случае с metricbeat было слишком много компромиссов.
Да и сам стек ELK имеет ряд непростых моментов:
- Он тяжелый, иногда даже очень тяжелый, если собирать достаточно большой объем данных.
- Его нужно «уметь готовить» — нужно масштабировать, а это сделать нетривиально.
- Урезанная бесплатная версия - в бесплатной версии нет нормального оповещения, и на момент выбора не было аутентификации
Но в то время, когда мы собирались развернуть это решение, оповещений вообще не было.
Возможно, мы могли бы попытаться создать что-нибудь с помощью ElastAlert или других решений сообщества, но мы все же решили рассмотреть другие альтернативы.
Локи – Графана – Прометей
На данный момент хорошим решением может быть построение стека мониторинга исключительно на основе Prometheus в качестве поставщика метрик, Loki для логов, а для визуализации можно использовать тот же Grafana. К сожалению, на момент старта продаж пилота проекта (сентябрь-октябрь 2019) Локи всё ещё находился в бета-версии 0.3-0.4, и на момент начала разработки его нельзя было рассматривать как производственное решение.совсем.
У меня пока нет опыта реального использования Loki в серьёзных проектах, но могу сказать, что Promtail (агент для сбора логов) отлично работает как на «голом железе», так и на подах в кубернетес.
ГАЛОЧКА
Пожалуй, самой достойной (единственной?) полнофункциональной альтернативой стеку ELK сейчас можно назвать только стек TICK — Telegraf, InfluxDB, Chronograf, Kapacitor.
Ниже я опишу все компоненты более подробно, но общая идея такова:
- Телеграф — агент по сбору метрик
- InfluxDB — база данных метрик
- Kapacitor — процессор метрик в реальном времени для оповещений
- Хронограф - веб-панель для визуализации
Следует отметить, что в последней версии Influx 2.0 (бета) Kapacitor и Chronograf стали частью InfluxDB и больше не существуют отдельно.
Телеграф
Телеграф — очень легкий агент для сбора метрик на конечном автомате.
Он может контролировать огромное количество всего, от nginx до серверы Шахтерское ремесло .
У него есть ряд крутых преимуществ:
- Быстрый и легкий (написан на Go)
- Съедает минимальное количество ресурсов
- Отправка метрик по умолчанию
- Собирает все необходимые метрики
- Системные метрики без каких-либо настроек
- Аппаратные метрики, такие как информация от датчиков
- Очень легко добавлять свои собственные показатели.
- Множество плагинов «из коробки»
- Собирает журналы
Сбор логов самим агентом также очень удобен, так как нет необходимости подключать дополнительные утилиты для ведения логов.
Influx предлагает наиболее удобный опыт работы с журналами, если вы используете системный журнал .
Telegraf, как правило, является отличным агентом для сбора метрик, даже если вы не используете остальную часть стека ICK. Многие для удобства пересекают его с ELK и разными другими базами данных временных рядов, поскольку он может записывать метрики практически где угодно.
InfluxDB
InfluxDB — это основное ядро стека TICK, а именно база данных временных рядов для метрик.
Помимо метрик, Influx может хранить и логи, хотя, по сути, логи для него — это те же метрики, только вместо привычных числовых показателей основную функцию выполняет строка текста журнала.
InfluxDB также написан на Go и, кажется, работает намного быстрее по сравнению с ELK на нашем (не самом мощном) кластере.
Одним из крутых преимуществ Influx также можно назвать очень удобный и богатый API для запросов к данным, которым мы очень активно пользовались.
Недостатки — $$$ или масштабирование?
У стека TICK есть только один обнаруженный нами недостаток — он Дорогой .Даже больше.
Что есть в платной версии, чего нет в бесплатной? Насколько нам удалось понять, единственное отличие платной версии стека TICK от бесплатной — это возможности масштабирования.
А именно поднять кластер с Highavailability можно только в Корпоративные версии .
Если вы хотите полноценную ХА, то нужно либо платить, либо использовать какие-то костыли.
Есть пара решений сообщества - например притокдб-ха выглядит как грамотное решение, но написано, что оно не пригодно для производства, как и приток-излив — простое решение с прокачкой данных через NATS (его тоже придется масштабировать, но это решаемо).
Жаль, но оба они похоже заброшены - свежих коммитов нет, предполагаю, что дело в скором выходе новой версии Influx 2.0, в которой многое будет по-другому (нет информации о масштабирование в нем еще нет).
Официально есть бесплатная версия Реле - по сути это примитивный ХА, но только за счет балансировки, поскольку все данные будут записываться во все экземпляры InfluxDB за балансировщиком нагрузки.
У него есть некоторые недостатки как потенциальные проблемы с перезаписью баллов и необходимость заранее создавать базы для метрик (что происходит автоматически при обычной работе с InfluxDB).
Кроме шардинг не поддерживается , это означает дополнительные накладные расходы на повторяющиеся метрики (как на обработку, так и на хранение), которые могут вам не понадобиться, но возможности их разделения нет.
Виктория Метрика?
В итоге, несмотря на то, что стек TICK нас полностью устроил во всем, кроме платного масштабирования, мы решили посмотреть, есть ли какие-нибудь бесплатные решения, способные заменить базу данных InfluxDB, оставив при этом остальные компоненты T_CK.
Баз данных временных рядов очень много, но наиболее перспективной является Victoria Metrics, она имеет ряд преимуществ:
- Быстро и легко, по крайней мере по результатам ориентиры
- Есть кластерная версия, о которой сейчас даже есть хорошие отзывы
- Она может осколки
- Поддерживает протокол InfluxDB.
При этом для метрик поддерживаются только числовые значения (для пользовательских метрик мы использовали строковые значения — подробнее об этом в разделе Панель администратора ).
Очевидно, по той же причине ВМ не может хранить логи, как это делает Influx. Также следует отметить, что на момент поиска оптимального решения Victoria Metrics еще не была так популярна, документации было гораздо меньше, а функционал слабее.
(Подробного описания версии кластера и шардинга не помню).
Выбор базы
В результате было решено, что для пилота мы всё равно ограничимся одной нодой InfluxDB. Для такого выбора было несколько основных причин:- Нам очень понравился весь функционал стека TICK.
- Нам уже удалось его развернуть, и он отлично работал
- Сроки поджимали, а времени на тестирование других вариантов оставалось не так много.
- Мы не ожидали такой большой нагрузки
Поэтому мы решили, что для данного проекта нам будет достаточно одной ноды Influx без необходимости масштабирования (см.
выводы в конце).
Со стеком и базой определились — теперь об остальных компонентах стека TICK.
конденсатор
Kapacitor — часть стека TICK — сервиса, который может отслеживать метрики, поступающие в базу данных, в режиме реального времени и выполнять различные действия на основе правил.
В целом он позиционируется как инструмент отслеживания потенциальных аномалий и машинного обучения (не уверен, что эти функции востребованы), но самый популярный случай его использования более банальный — оповещение.
Вот как мы использовали его для уведомлений.
Мы настроили оповещения Slack, когда конкретный самокат отключался от сети, и то же самое было сделано для интеллектуальных зарядных устройств и важных компонентов инфраструктуры.
Это позволило быстро реагировать на проблемы, а также получать уведомления о том, что все вернулось в норму.
Простой пример: сломался или по каким-то причинам разрядился дополнительный аккумулятор для питания нашей «коробочки»; просто установив новый, через некоторое время мы должны получить уведомление о том, что работоспособность самоката восстановлена.
В Influx 2.0 конденсатор стал частью БД.
Хронограф
Я видел много разных UI-решений для мониторинга, но могу сказать, что с точки зрения функциональности и UX ничто не сравнится с Chronograf. Мы начали использовать стек TICK, как ни странно, с Grafan в качестве веб-интерфейса.
Я не буду описывать его функционал; всем известны его широкие возможности для настройки чего угодно.
Однако Grafana по-прежнему является полностью универсальным инструментом, а Chronograf в основном предназначен для использования с Influx. И конечно, благодаря этому Chronograf может позволить себе гораздо более умный и удобный функционал.
Пожалуй, главное удобство работы с Chronograf в том, что вы можете просмотреть внутренности своей InfluxDB через Explore. Казалось бы, Grafana имеет практически идентичный функционал, но на самом деле настроить дашборд в Chronograf можно в несколько кликов мышкой (попутно просматривая там визуализацию), а в Grafana у вас все равно рано или поздно возникнет редактировать конфигурацию JSON (конечно, Chronograf позволяет загружать настроенные вручную даши и при необходимости редактировать их как JSON - но мне никогда не приходилось их трогать после создания в пользовательском интерфейсе).
У Kibana гораздо более богатые возможности по созданию дашбордов и элементов управления для них, но UX для таких операций очень сложен.
Чтобы создать удобную панель управления, потребуется хорошее понимание.
И хотя функционал дашбордов Chronograf меньше, сделать и настроить их гораздо проще.
Сами дашборды, если не считать приятного визуального стиля, по сути ничем не отличаются от дашбордов в Grafana или Kibana: 
Вот как выглядит окно запроса: 
Важно отметить, среди прочего, что зная типы полей в базе данных InfluxDB, сам хронограф иногда может автоматически помочь вам написать запрос или выбрать правильную функцию агрегирования, например среднее значение.
И конечно, Chronograf максимально удобен для просмотра логов.
Это выглядит так: 
По умолчанию журналы Influx настроены на использование системного журнала и поэтому имеют важный параметр — серьезность.
График вверху особенно полезен; на нем вы можете увидеть возникающие ошибки, а цвет сразу четко показывает, выше ли серьезность.
Пару раз мы таким образом ловили важные баги, заходя на просмотр логов за прошедшую неделю и видя красный всплеск.
Конечно, в идеале было бы настроить оповещения о таких ошибках, благо все для этого у нас уже было.
Мы даже на время включили это, но в процессе подготовки пилота выяснилось, что мы получаем довольно много ошибок (в том числе системных вроде недоступности сети LTE), которыми «спамил» и канал Slack. много, не вызывая никаких проблем.
большая выгода.
Правильным решением было бы обработать большинство ошибок такого типа, настроить для них уровень серьезности и только затем включить оповещения.
Таким образом, в Slack будут публиковаться только новые или важные ошибки.
Времени на такую настройку в условиях сжатых сроков просто не хватило.
Аутентификация
Также стоит отметить, что Chronograf поддерживает аутентификацию OAuth и OIDC. Это очень удобно, так как позволяет легко подключить его к своему серверу и создать полноценный SSO. В нашем случае это был сервер Теги: #iot #Разработка для Интернета вещей #ИТ-инфраструктура #Системное администрирование #DevOps #мониторинг #метрики #influxdb #iot-платформа #influxdata-
Джон Филопон
19 Oct, 24 -
Получите Максимум От Outlook Express
19 Oct, 24 -
Мечта — Социальная Сеть Для Живого Общения.
19 Oct, 24 -
Будильники
19 Oct, 24
