company_banner

Вернуть пропавший скутер, или история одного IoT мониторинга

Год назад мы запустили пилотную версию промо проекта по децентрализованному прокату электроскутеров.


Изначально проект назывался 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 мог отсылать неверные координаты и "залипать", а определить это можно было только на уровне дополнительных проверок на скутере,
      и нотифицировать поддержку как можно скорее для устранения проблемы

И последнее: проверки софтверной части, начиная с ОС и загрузки процессора, сети и диска, заканчивая уже более специфичными для нас проверками наших собственных модулей (Jolocom, Keycloak).


Hardware



Что же представляла наша "железная" часть?


Учитывая максимально сжатые сроки и необходимость быстрого прототипирования мы выбрали для себя максимально простой для реализации и подбора компонентов вариант — 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 решения, поэтому выбор сразу пал на платформы.


Сама Balena была исключена ввиду того, что фактически использует тот же самый Docker внутри своего balenaEngine.


Но отмечу, что несмотря на это, в конечном итоге мы постоянно использовали их продукт Balena Etcher для флеша прошивок на SD карты — простая и крайне удобная утилита для этого.


Поэтому в итоге выбор пал на Mender. Mender представляет из себя полноценную платформу для сборки, доставки и установки прошивок.


В целом платформа выглядит просто замечательно, но нам потребовалось около полутора недель только на то, чтобы собрать правильную версию нашей прошивки с помощью сборщика mender.
И чем больше мы погружались в тонкости его использования, тем больше становилось ясно, что на полноценное его развертывание нам понадобилось бы сильно больше времени, чем у нас было.


Увы, наши сжатые сроки привели к тому, что мы вынуждены были отказаться от использования Mender и выбрать ещё более простой пусть.


Ansible

Самым простым решением в нашей ситуации оказалось использование 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 — а конкретно Wireguard.


Клиенты (скутеры) на старте системы подключались к VPN серверу и держали возможность подключения к ним. Этот туннель и использовался для доставки обновлений.



В теории, тот же туннель можно было использовать и для мониторинга, но такое подключение было сложнее и менее надежным чем простой push.


Облачные ресурсы


Последнее — необходимо отслеживать наши облачные сервисы и БД, так как для них мы используем Kubernetes, в идеале чтобы разворачивание мониторинга в кластере было максимально простым. В идеале — с использованием Helm, так как для деплоя, мы в большинстве случаев используем его. И, само собой, для мониторинга облака нужно использовать те же решения, что и для самих скутеров.


Дано


Фуф, вроде с описанием разобрались, давайте составим список того, что нам было нужно в итоге:


  • Быстрое решение, так как мониторить необходимо уже во время процесса разработки
  • Объем/количество — нужно множество метрик
  • Сбор логов обязателен
  • Надежность — данные критически важны для успеха запуска
  • Нельзя использовать pull модель — нужен push
  • Нужен единый мониторинг не только железа, но и облака

Конечная картинка выглядела примерно так



Выбор стека


Итак, перед нами встал вопрос выбора стека для мониторинга.


В первую очередь, мы искали наиболее полноценное all-in-one решение, которое одновременно покрывало бы все наши требования, но при этом и было бы достаточно гибким чтобы подогнать его использование под наши нужды. Все-таки, у нас было много ограничений наложенных на нас железом, архитектурой и сроками.


Существует огромное множество решений для мониторинга, начиная полноценными системами вроде Nagios, icinga или zabbix и заканчивая уже готовыми решениями по Fleet management.



Изначально, последние казались идеальным для нас решением, но в одних не было полноценного мониторинга, в других были сильно урезаны возможности бесплатных версий, а третьи просто не покрывали наши "хотелки" или не были достаточно гибкими для подгонки под наши сценарии. Некоторые просто устарели.


После анализа какого-то количества подобных решений мы быстро пришли к выводу, что проще и быстрее будет собрать схожий стек самостоятельно. Да, это будет чуть сложнее чем разворачивание полностью готовой Fleet management платформы, но зато нам не придется идти на компромиссы.


Почти наверняка, во всем огромном обилии решений и есть уже готовое которое полностью бы нам подошло, но в нашем случае значительно быстрее было собрать некий стек самостоятельно и подогнать "под себя", нежели тестировать готовые продукты.


При всем этом, мы не стремились собирать целиковую платформу для мониторинга самостоятельно, а искали максимально функциональные "готовые" стеки, только с возможностью их гибко настраивать.


(B)ELK?


Первое решение, которое реально рассматривалось — широко известный ELK стек.
На самом деле он должен называться BELK, ведь начинается все с Beatshttps://www.elastic.co/what-is/elk-stack



Конечно, ELK это одно из самых известных и мощных решений в области мониторинга, а уж в сборе и обработке логов, так и самое.


Мы подразумевали, что ELK будет использоваться для сбора логов и, так же как долговременное хранилище метрик полученных из Prometheus.


Для визуализации можно использовать Grafan'у.


На самом деле, свежий ELK стек умеет собирать метрики и самостоятельно (metricbeat), Kibana так же умеет показывать их.


Но все-таки изначально ELK вырос из логов и пока функционал метрик имеет ряд серьезных недостатков:


  • Значительно медленнее Prometheus
  • Интегрируется в куда меньшее количество мест чем Prometheus
  • Сложно настроить алертинг по ним
  • Метрики занимают большое количество места
  • Настройка дашбордов с метриками в Kiban'е значительно сложнее Grafan'ы

В общем, метрики в ELK тяжелые и пока не такие удобные как в других решениях, которых сейчас на самом деле значительно больше чем просто Prometheus: TSDB, Victoria Metrics, Cortex итд итп. Конечно, очень бы хотелось иметь сразу полноценное all-in-one решение, но в случае с metricbeat выходило слишком много компромиссов.


Да и у самого ELK стека есть ряд непростых моментов:


  • Он тяжелый, порой даже очень, если у вас собирается довольно большое количество данных
  • Его нужно "уметь готовить" — скалировать его необходимо, но делается это нетривиально
  • Урезанная бесплатная версия — в бесплатной версии нет нормального алертинга, на момент выбора не было и аутентификации

Надо сказать, что в последнее время с последним пунктом стало получше и помимо вывода в open-source X-pack (в том числе аутентификация) начала меняться сама модель прайсинга.


Но на момент, когда мы собирались разворачивать это решение, алертинга не было совсем.
Возможно, можно было попробовать собрать что-то с использованием ElastAlert или других community решений, но все же решили рассмотреть другие альтернативы.


Loki — Grafana — Prometheus


На данный момент неплохим решением может быть сборка стека мониторинга на основе чисто Prometheus как поставщика метрик, Loki для логов, а для визуализации можно использовать все ту же Grafana.


К сожалению, на момент старта прода пилота проекта (сентябрь-октябрь 19ого года) Loki ещё находился в бета версии 0.3-0.4, а на момент старта разработки и вовсе не мог рассматриваться как produtcion решение.


Я пока не имею опыта реального использования Loki в серьезных проектах, но могу сказать, что Promtail (агент для сбора логов) здорово работает как для bare-metal, так и для подов в kubernetes.


TICK


Пожалуй, наиболее достойной (единственной?) полнофункциональной альтернативой ELK стеку сейчас можно назвать только TICK стек — Telegraf, InfluxDB, Chronograf, Kapacitor.



Я опишу все компоненты ниже более подробно, но в целом идея такая:


  • Telegraf — агент для сборки метрик
  • InfluxDB — база данных метрик
  • Kapacitor — обработчик метрик в реальном времени для алертинга
  • Chronograf — веб панель для визуализации

Для InfluxDB, Kapacitor и Chronograf есть официальные helm чарты, которые мы использовали для их разворачивания.


Надо отметить, что в свежей версии Influx 2.0 (beta) Kapacitor и Chronograf стали частью InfluxDB и больше не существуют отдельно


Telegraf



Telegraf — это очень легковесный агент для сбора метрик на конечной машине.


Он умеет мониторить огромное количество всего, от nginx до
сервера minecraft.


У него есть ряд классных преимуществ:


  • Быстрый и легкий (написан на Go)
    • Ест минимальное количество ресурсов
  • Push метрик по умолчанию
  • Собирает все необходимые метрики
    • Системные метрики без каких-либо настроек
    • Хардварные метрики вроде информации с датчиков
    • Очень легко добавлять собственные метрики
  • Много плагинов "из коробки"
  • Собирает логи

Так как push метрик был для нас необходим, все остальные преимущества были более чем приятными дополнениями.


Сборка логов самим же агентом так же очень удобна, так как нет необходимости подключать дополнительные утилиты для тейлинга логов.


Influx предлагает максимально удобный опыт работы с логами если вы используете syslog.


Telegraf вообще отличный агент для сборки метрик, даже если вы не используете весь остальной ICK стек.


Многие скрещивают его и с ELK и с различными другими time-series базами по удобству, так как он умеет писать метрики почти куда угодно.


InfluxDB



InfluxDB — основное ядро TICK стека, а именно time-series база данных для метрик.
Помимо метрик Influx также может хранить и логи, хотя, по сути логи для него это всего лишь такие же метрики, только вместо обычных числовых показателей основную функцию несет строка текста лога.


InfluxDB тоже написан на Go и работает, по ощущениям, значительно быстрее в сравнении с ELK на нашем (не самом мощном) кластере.


К одним из крутых преимуществ Influx я бы также отнес очень удобное и богатое API для запросов к данным, которые мы очень активно использовали.


Недостатки — $$$ или скалирование?

У TICK стека есть только один обнаруженный нами недостаток — он дорогой. Даже очень.


А что есть в платной версии, чего нет в бесплатной?


Насколько нам удалось понять, единственное чем отличается платная версия TICK стека от бесплатной — возможности скалирования.


А именно — поднять кластер с High availability можно только в Enterprise версии.


Хотите полноценное HA — нужно либо платить, либо городить какие-нибудь костыли. Есть пара решений сообщества — например influxdb-ha похоже на грамотное решение, но написано что не подходит для продакшена, а так же
influx-spout — простое решение с прокачкой данных через NATS (его тоже придется скалировать, но это решаемо).


Жаль, но оба они, похоже, заброшены — нет свежих коммитов, предположу, что дело в скором ожидаемом выходе новой версии Influx 2.0 в которой многое будет иначе (пока информации о скалировании в ней нет).


Официально для бесплатной версии существует Relay — фактически это примитивное 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


Chronograf



Я повидал много различных 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.


В нашем случае — сервером был Keycloak — он использовался для подключения к мониторингу, но при этом тот же сервер использовался и для аутентификации скутеров и запросов на back-end.


“Админка”


Последний компонент, который я опишу — это наша самописная "админка" на Vue.
В целом это просто отдельный сервис, который отображает информацию о скутерах одновременно из наших собственных баз данных, микросервисов и данные метрик из InfluxDB.


Помимо того, туда были вынесены многие административные функции, вроде экстренной перезагрузки или удаленного открытия замка для команды поддержки.


Также там были карты. Я уже упоминал, что начинали мы с Grafana вместо Chronograf — потому что для Grafana в виде плагинов доступны карты, на которых можно было смотреть координаты скутеров. К сожалению, возможности виджетов карт для Grafana очень ограничены, и в результате было гораздо проще за несколько дней написать свое собственное веб приложение с картами, для того чтобы не только видеть координаты в данный момент, но и отображать пройденный скутером маршрут, уметь фильтровать данные на карте, итд (весь тот функционал, который мы не смогли бы настроить в простом дашборде).


Один из уже упомянутых плюсов Influx — возможность легко создавать свои собственные метрики.
Это позволяет использовать его для огромного множества сценариев.


Мы старались записывать туда всю полезную информацию: заряд батареи, состояние замка, работоспособность датчиков, bluetooth, GPS, множество других healthcheck'ов.
Все это мы и отображали на админ панели.


Конечно, самым главным критерием для нас было состояние работы скутера — фактически Influx проверяет это сам и показывает в разделе Nodes "зелеными лампочками".


Делается это функцией deadman — мы использовали ее же для понимания работоспособности нашей коробочки и отсылки тех самых алертов в Slack.


Кстати, мы называли скутеры по именами персонажей из Симпсонов — так их было удобно отличать друг от друга


Да и вообще так было веселее. Постоянно звучали фразы вроде "Ребята — Смитерс умер!"



Строковые метрики


Важно, что InfluxDB позволяет хранить не только числовые значения, как в случае с Victoria Metrics.


Казалось бы, это не так важно — ведь если не считать логов, любые метрики можно хранить в виде чисел (всего лишь добавить маппинг для известных состояний — своего рода enum)?


В нашем случае, был как минимум один сценарий, когда строковые метрики были очень полезны.
Так уж получилось, что поставщик наших "умных зарядок" был сторонним, мы не имели никакого контроля над процессом разработки и информацией, которую эти зарядки могут поставлять.


В результате API зарядок было далеко от идеала, но основной проблемой было то, что мы не всегда могли понять их состояние.


Тут на помощь и пришел Influx. Мы просто-напросто записывали приходящий нам строковый status в поле базы InfluxDB без изменений.


Какое-то время туда попадали только значения вида "online" и "offline", на основе чего у нас в админке отображалась информация, а в Slack приходили уведомления. Однако в какой-то момент туда стали попадать так же значения вида "disconnected".


Как позже выяснилось, этот статус высылался однократно после потери связи, если зарядка не могла установить соединение с сервером после какого-то количества попыток.


Таким образом, если бы мы использовали только фиксированный набор значений — мы могли бы не увидеть этих изменений в прошивке в нужный момент времени.


Да и вообще, строковые метрики дают куда больше возможностей для использования, записывать в них можно фактически любую информацию. Хотя, конечно, использовать этот инструмент тоже нужно аккуратно.



Помимо обычных метрик, мы так же записывали в InfluxDB информацию о GPS локации. Это было невероятно удобно для мониторинга местонахождения скутеров в нашей админской панели.
Фактически, мы всегда знали где и какой скутер был в нужный нам момент времени.


Очень сильно нам это пригодилось, когда мы разыскивали скутер (смотри выводы в конце).


Мониторинг инфраструктуры


Помимо самих скутеров, нам было необходимо мониторить и всю нашу (довольно обширную) инфраструктуру.


Очень обобщенная архитектура выглядела примерно так:



Если выделить чисто стек мониторинга, то он выглядит следующим образом:



Из того что мы хотели бы проверять в облаке, это:


  • Базы данных
  • Keycloak
  • Микросервисы

Так как все наши облачные сервисы находятся в 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 SIM картах начал быстро таять.


Основную массу трафика съедали логи, сами метрики даже с 10и-секундным интервалом практически не тратили его.


В итоге, спустя ещё какое-то время мы совсем отключили сбор логов на устройствах, так как конкретные проблемы уже были очевидны и без постоянного сбора.


В некоторых случаях, если просмотр логов все же был необходим — мы просто подключались через WireGuard по VPN.


Ещё добавлю, что каждый отдельный environment у нас был отделен друг от друга, и вышеописанная нагрузка была актуальна только для продакшен среды.


В среде разработчиков у нас был поднят отдельный инстанс InfluxDB который продолжал собирать данные раз в 10 секунд и мы не уткнулись в какие-либо проблемы с производительностью.


TICK — идеально для небольших-средних проектов

На основе этой информации я бы сделал вывод, что TICK стек идеально подходит для относительно небольших проектов или проектов, у которых точно не ожидается какого-либо HighLoad.


Если у вас нет тысяч подов или сотен машин — даже один инстанс InfluxDB прекрасно справится с нагрузкой.


В некоторых случаях вас может устроить Influx Relay как примитивное решение по High Availability.


И, само собой, никто не мешает вам настраивать "вертикальное" скалировние и просто выделить различные сервера под различные типы метрик.


Если же вы не уверены в ожидаемой нагрузке на сервисы мониторинга, или у вас гарантированно есть/будет очень "тяжелая" архитектура — бесплатную версию TICK стека использовать я бы не порекомендовал.


Конечно, простым решением было бы приобретение InfluxDB Enterprise — но тут я не могу как-то прокомментировать, так как сам не знаком с тонкостями. Кроме того, что это очень дорого и точно не подойдет для мелких компаний.


В таком случае, на сегодняшний день, я бы порекомендовал посмотреть в сторону сбора метрик через Victoria Metrics и логов с помощью Loki.


Правда, снова оговорюсь, что Loki/Grafana значительно менее удобны (в виду своей большей универсальности) чем готовый TICK, но зато они бесплатны.


Важно: вся описанная здесь информация актуальна для версии Influx 1.8, в данный момент вот-вот должен выйти в релиз Influx 2.0.


Пока не довелось попробовать его в боевых условиях и сложно делать выводы об улучшениях, точно еще лучше стал интерфейс, упростилась архитектура (без kapacitor и chronograf),
появились темплейты ("киллер фича" — можно отслеживать игроков в Fortnite и получать нотификации когда твой любимый игрок выигрывает партию). Но, к сожалению, в данный момент в версии 2 нет ключевой вещи, по которой мы выбрали первую версию — нет сбора логов.


Этот функционал в Influx 2.0 тоже появится, но каких-либо сроков, даже примерных, найти не удалось.


Как не нужно делать IoT платформы (теперь)


В конце концов, запустив пилот мы сами собрали свой полноценный IoT стек, за неимением подходящей по нашим меркам альтернативы.


Однако, с недавнего времени в Beta версии доступна OpenBalena — жаль ее не было когда мы начинали делать проект.


Конечный результат и та платформа на основе Ansible + TICK + WireGuard, которую мы собрали самостоятельно нас полностью устраивает. Но на сегодняшний день, я бы порекомендовал внимательней посмотреть на Balena прежде чем пытаться собрать свою IoT платформу самим.


Потому что, в конечном итоге она умеет делать большую часть того, что мы делали, при этом OpenBalena бесплатна, а код открыт.


Оно уже умеет не просто рассылать обновления, но и VPN там уже вшит и заточен под использование в IoT среде.


А совсем недавно — они и вовсе выпустили свою Hardware, которая легко подключается в их экосистему.


Эй, а что с пропавшим скутером?


Итак скутер, "Ральф", бесследно исчез.


Мы сразу побежали смотреть карту в нашей "админке", с данными GPS метрик из InfluxDB.


Благодаря данным мониторинга, мы легко определили, что парковку скутер покинул около 21:00 прошлого дня, проехал где-то полчаса до какого-то района и был запаркован до 5и утра рядом с каким-то немецким домом.


После 5и утра данных мониторинга не поступало — это означало либо полный разряд дополнительной батареи, либо злоумышленник догадался-таки извлечь умную начинку из скутера.
Несмотря на это, по тому адресу, где находился скутер все же была вызвана полиция. Скутера там не оказалось.


Однако владелец дома тоже был этому удивлен, так как он действительно вчера вечером приехал на этом скутере из офиса домой.


Как выяснилось, один из сотрудников поддержки приехал рано утром и забрал скутер, увидев, что у него полностью разрядилась дополнительная батарея и повез его (пешком) на парковку. А дополнительная батарея вышла из строя из-за попадания влаги.


Мы украли скутер сами у себя. Не знаю, кстати, как и кто потом разруливал вопрос с делом в полиции, но мониторинг отработал отлично...

Комментарии 74

    +1

    Интересно было бы узнать чем именно вам не подошёл Заббикс. У них сейчас есть Заббикс Агент 2, написанный на Go. К нему можно прикручивать собственные плагины и в целом есть где развернуться.

      0
      Был опыт работы с Zabbix в более стандартных сценариях, но это было относительно давно (может быть и неправильно было принимать решение на основе давней информации, но времени тестировать свежие версии не было).

      В целом, никаких особых проблем с ним не возникало, разве что его настройка и интерфейс далеко не всегда просты для понимания. Да и изначально рассматривались более современные решения, а в частности про Агент 2 даже и не знал. Посмотрю что там свежего появилось, спасибо.
      +1
      >но мониторинг отработал отлично…

      отлично бы он отработал, если факт «техобслуживания» был бы его составной частью
        0

        Тоже зашёл написать, что если бы в логах была запись "скутер Х взят на заправку Ивановым", то этих проблем бы не было

        +3
        Какже все любят всё усложнять, пытаясь себе чтото облегчить.
        Raspberry там, где хватило бы даже ардуины (Ну или STM32, если надо ресурсов поболее).
        А для обновления софта можно было и APT использовать с собственным репозиторием, закрытым приватным ключом. Да, это не так модно, но зато проверено временем и… Оно просто работает.
          +1
          Не совсем понимаю ваш поинт. Для ардуины, в нашем случае, пришлось бы писать довольно много обвязок и кода. Я не углублялся в детали, но вообще наш Go «агент» на Raspberry делал очень много всего, а как на ардуине могла работать библиотека на Node.js мне вообще не ясно.

          Обновления мы доставляли именно deb пакетами, просто вместо APT использовали Ansible, что было удобно. А в качестве репозитория мы использовали уже развернутый ранее Nexus. На мой взгляд, в данном контексте выбор тулы для доставки пакетов мало что меняет.
            +4
            а как на ардуине могла работать библиотека на Node.js мне вообще не ясно


            Чтобы опрашивать несколько датчиков и передавать показания на сервер (функционал точно как у метеостанции на ардуине ;) ), можно обойтись и без node.js.
              –5
              а можно еще и перфокарты вспомнить
                +5

                Можно. Ваша система позволяет масштабирование на 100500 узлов, да. Со стороны серверов. Но raspberry (достаточно дорогая и много кушающая), да в мобильной системе, где вибрации и перепады температуры — так себе идея.

                  –2

                  Не мешайте коллегам осваивать бюджеты!
                  Вы что по длине статьи не видете, что им платят построчно)

                    0
                    Вся эта система — это прям эталонный пример как делать не нужно. Я бы даже сказал что они старательно хотят собрать все возможные грабли. Ну ок, хотят они использовать полноценный linux, но почему тогда не выбрать что-то с emmc, зачем брать самый худший вариант — microsd?
                      +3
                      Потому что дохлая карточка меняется элементарно, а emmc нужно паять? И это пилот, где нужно быстро протестить, а не сделать на века.
                        0
                        Это не пилот, автор тут же в комментариях пишет что это готовый модуль.
                        Да и как вы себе это представляете? Пилить весь проект на Raspberry Pi, собрать все подводные камни, а потом перейти на другие платы, где память распаяна, и снова собирать все подводные камни? Ну бред же, никто так не делает.

                        Про сдохшую emmc ерунда, что бы она сдохла от износа её прям очень старательно нужно насиловать на запись, что в embedded даже на этапе разработки сложно достичь. Вот для примера у нас ни на одной плате ещё не умирала emmc, а вот microsd выкинуто немало. С microsd ещё часто бывает что они начинают отваливаться и терять данные когда нагреваются выше 40 градусов, притом без разницы китай это за 250 рублей или «индустриальная» карта от именитых брендов. Ну и проблема что «контакт с картой» пропал и нужно её переподключить раз в год у вас точно возникнет, для embedded это неприемлемо.
                          0
                          Год назад мы запустили пилотную версию промо проекта по децентрализованному прокату электроскутеров.

                          Вроде как пилот. Поэтому я и оцениваю со стороны скорости разработки. С моей точки зрения будет вполне разумным разработать новую платформу для массового внедрения с учётом накопленного опыта. Да, часть граблей придётся собрать заново, но это лучше и быстрее, чем разработать сложную систему на МК, а потом её переделывать.
                            +1
                            Что за «готовый модуль» и где об этом была речь? Про то, что проект пилотный написано в первой строке поста.
                            Прочитав который вы бы поняли, что у нас не возникало каких-либо проблем с MicroSD, и стореджем вообще. Причем тут emmc и какую проблему он бы для нас решил, не ясно.

                            Концепция MVP предполагает, что сначала вам нужно проверить саму идею продукта, обкатать ее, и даже, возможно, полностью от не отказаться. Такие проекты никогда не делаются в Enterprise режиме с планированием на годы вперед. Нужно сделать что-то быстро, оценить результаты, и позже уже делать на их основе полноценное решение.

                            Я все еще считаю, что Raspberry для подобного прототипирования — почти идеальная платформа — в случае чего нужную плату можно купить в любом электронном ларьке Берлина вроде Conrad. Она позволяет сэкономить массу времени именно на этапе начальной разработки. Конечно, никто не предполагает использовать Raspberry для реального продакшен решения, которое будет на дорогах всей страны. Но пока, к сожалению, об этом и речь не идет.
                              0
                              > в любом электронном ларьке Берлина вроде Conrad
                              Так «ларёк» с годовым оборотом в более чем 1 млрд евро еще никто не обзывал :)
                  +2
                  А зачем там нода?
                  От девайса что требовалось? Опрос датчиков, передача данных на серер, управление парой релюшек и лампочек. Причем энергопотребление на первом месте стоит.
                  Код вам и так и так писать надо, но не забываем, что есть куча готовых библиотек, что сильно упрощает задачу.
                  К томуже микроконтроллер можно вообще держать в режиме глубокого сна, пробуждая только по таймеру или прерываниям, что сводит его энергопотребление к совсем смешным значениям.
                  Да и как подметили ниже — микроконтроллеры более стойки к перепадам температур, что тоже важно.
                    0
                    Да никто и не спорит, что микроконтроллер справился бы лучше. Но он не осуществлял бы и половины логики которую необходимо было реализовать, а разработка полноценного контроллера под наши задачи отняла бы массу времени, у нас его просто не было.

                    Помимо прочего, там было довольно много криптографии и работы с ETH сетью. Вся идея решения была в подготовке базы для того, чтобы использовать ее в будущем полностью децентрализовано. К сожалению не для всего есть децентрализованные решения, но мы старались использовать их по минимуму.
                      +1

                      Э-э-э, простите, но нахера нужна децентрализованная база в сервисе проката скутеров?

                        +2
                        Распберри как платформа для быстрого прототипирования — вполне неплохой выбор. Разумный баланс между скоростью разработки и стоимостью конечного устройства. Проблемы могут начаться, когда вам потребуется произвести 10 000 устройств. Во-первых, будет дорого, во-вторых, не факт, что нужное количество плат воообще производится. Здесь уже есть смысл переходить на микроконтроллеры.
                        0
                        *мурлыкает под нос* ASN.1…
                      0
                      Действительно.
                      Со всеми поставленными задачами может справиться nrf52840, BLE уже на борту.
                      Связь делается через внешний 3G/LTE модуль, через LoRa, или что-то еще.
                      Кстати у нордика недавно новая платформа подоспела nRF9160 — Low power SiP with integrated LTE-M/NB-IoT modem and GPS. Платформа практически для смарт-часов. Отличный вариант для этой штуки.
                      +1
                      Кажется, я недостаточно хорошо раскрыл это в статье — но Node.js использовали не мы, а наши партнеры. Использовался он для функционала по децентрализованной аутентификации на основе DID en.wikipedia.org/wiki/Decentralized_identifiers в качестве библиотеки.

                      Мы не могли отказаться от ее использования или переписать самостоятельно, а альтернатив ей на тот момент не существовало.
                        –2
                        Почему «Не могли»? Вас сроки поджимали? Людей не хватало?
                          –1
                          Хмм… А почему «Минуса»?
                          Я реально не понимаю, когда компания говорит «Не можем». Это не причина.
                          Нет денег / нет времени / нет специалистов (знаний) — это причина. Хотя, на самом деле, всё упирается исключительно в деньги.
                            –1

                            Короткий ответ: отчасти и то и другое, но основное, как я и написал выше — отсутствие альтернатив.


                            Длинный ответ:


                            Проблемы, с которым мы столкнулись, также описаны в первом посте о проекте, ссылка на который есть в статье.
                            Основная идея была в децентрализации, и несмотря на то, что далеко не все компоненты системы сразу удалось сделать децентрализованными, мы к этому стремились, по крайней мере в части ядра платформы.
                            Самую ключевую роль в ней играли смарт контракты, DID, Verifiable Credentials и, собственно, сам Ethereum.
                            Скутер сам общался с клиентом, без посредников. Деньги с кошелька пользователя так же списывались децентрализовано, с использованием контрактов.


                            Для всей этой логики, помимо нашего собственного функционала, необходимо было иметь массу "обвязки", вроде децентрализованной аутентификации, подписи транзакций Ethereum и валидации сигнатур Verifiable Credential'ов, которые были выписаны тем или иным DID (которые тоже нужно было верифицировать). Для всего этого также необходимо много криптографии. Мы выбрали партнера — компанию Jolocom, с которым успешно работали ранее, и у которых есть готовая библиотека для большинства вышеописанного. К сожалению, им не удалось в срок завершить имплементацию подобной библиотеки на каком-либо низкоуровневом языке, а подобных решений "на рынке" на тот момент не существовало вовсе.


                            Писать подобную библиотеку самим (например на Go) означало бы в несколько раз увеличить сроки разработки пилота, что было попросту невозможно (банально скутеры востребованы только пока на улице еще не слишком холодно, запуск и так был сдвинут с лета на осень, но зимой мы запускаться не могли).
                            В итоге, мы были вынуждены использовать то что есть — Node.js


                            Я надеюсь, что после этого пояснения, вопросов о том почему мы его все-таки использовали больше не возникнет. Это была критически важная для сути пилота функциональность, и у нас не было альтернативных вариантов.

                              0

                              "Скутер сам общался с клиентом, без посредников. Деньги с кошелька пользователя так же списывались децентрализовано, с использованием контрактов."


                              Спасибо, теперь понятно почему, но непонятно зачем ;) Телеметрия собирается централизовано и online; обновления рассылаются централизовано; зачем ещё один сложный и интересный механизм?

                                0
                                Криптобудущее, р-р-ря!
                            +2
                            для функционала по децентрализованной аутентификации


                            А зачем в этой схеме нужна децентрализованная аутентификация, если внутри ansible и ssh?
                            +9
                            Наворотили кучу мониторига, всякие модные базы и сервисы… А простая операция «Техобслуживание» вызвала панику, полицию, в общем заставила потратить время многих людей. Почему не была написана методичка по такой простой процедуре? Почему сотрудник «просто взял устройство», не предупредив никого, даже по телефону?
                            Раздолбайство и недальновидность (не предусмотрели такой простой и, самое главное, вполне себе очевидный и нередкий сценарий) — вот как это называется.
                              +4
                              Похоже, что никто не хотел по настоящему решать проблему. Это такой хакатон, который затянулся. Делаем, потому что можем и потому что прикольно. Иначе бы упростили архитектуру, использовали более простое решение для передачи данных с датчиков, подумали бы что будет, если злоумышленник просто оторвет коробочку с антенкой (xRide box), продумали различные сценарии поведения при угоне и т.д.
                                0
                                В целом вы правы, хотя я бы не был так категоричен, с учетом сроков. Методичка существовала и для саппорт команды, и даже для потенциальных пользователей.

                                Вообще, для этого не нужна была какая-то поддержка в системе мониторинга, у нас просто был Slack канал, где саппорт мог отписаться в случае необходимости ремонта скутера. Коллега, забравший скутер, не смог этого сделать из-за разрядки мобильного (и забрал скутер не подумав о последствиях). Мне кажется, предусмотреть этот сценарий было непросто. Для нас был однократным — больше не повторялось.
                                  0
                                  Вот еще одна проблема — питание системы мониторинга. Оно должно быть независимо от основоного аккумулятора. Тогда такое досадное совпадение (села батарея в телефоне, скутере и в мониторинге) не случится.
                                    0
                                    В статье же написано что у RPi есть своя отдельная батарейка, просто она померла раньше времени.
                                0

                                Из всего рассмотренного вы выбрали kapacitor? Это же самый ужас из всего, что кто-либо когда-либо писал. Код на kapacitor'е невозможно отлаживать.


                                Я просто оставлю это тут. https://medium.com/opsops/hammering-nails-into-kapacitor-coffin-8ebb13f8e427

                                  0
                                  Спасибо, почитаю — но у нас не было необходимости в поиске альтернатив, так как мы, видимо, использовали его для относительно простых вещей. Фактически, мы его и не конфигурировали почти никак. Slack оповещения легко настроили и забыли, так что заменять его не планировали.
                                    0

                                    А как вы проверяете, что у вас мониторинг работает? У прометеуса есть режим тестирования алертов. А у kapacitor — ничего. И скрытый state, который (может быть) на что-то влияет. А может и нет. И методов проверить у вас никаких.

                                      0
                                      Мы проверяли это только один раз, когда включали Slack оповещения. Оно пришло, когда мы выключили Raspberry. С тех пор работало и больше мы туда не лезли. Я понимаю, что у капаситора есть некие недостатки, но мы с ними не сталкивались.
                                  0

                                  Вопрос: а почему тяжеловесный и медленный Balena Etcher, а не rufus, к примеру?

                                    0
                                    Медленный — не заметил. Возможно, у нас образы были не особо большие, но прошивались они достаточно быстро. Про тяжеловесность — 100-метровый экзешник, это конечно, не супер, но учитывая что скачан он был когда-то один раз на старте проекта, про это и вовсе никто не вспоминал.
                                    В общем, Etcher мне кажется максимально «тупым» и удобным инструментом для своей задачи, поиск альтернатив нам не требовался, так как он всем устраивал.
                                      0
                                      А почему ваш лёгкий и быстрый rufus такой не толерантный и не поддерживает другие ОС, как это делает та же Balena?
                                        0
                                        Ну, честно говоря rufus не мой, не я его разработчик. Вопрос скорее следует адресовать ему, не мне. Про поддержку Balena Etcher «других ос» — она есть на бумаге, но довольно хрупкая: на половине тестовых конфигураций этчер либо зависал на “Starting”, либо выдавал “something went wrong” в конце под *nix. Видимо, это такая плата за кроссплатформенность.
                                          0
                                          Возможно вы что-то делаете не так, поскольку я Etcher'ом пользуюсь и на *nix системах и на macos и не испытываю трудностей.
                                            0

                                            "… ничего не знаю, у меня вот точно такая же нога, и она не болит!"
                                            Не думаю что проблема в том что у нашего IT-департамента руки растут не оттуда. Скорее всего вам повезло, а нам — нет. Просто сходите на форум этчера и посмотрите какие у людей возникают проблемы, и убедитесь что многие из них — реальные проблемы, а не ошибки пользователя. Возможно сейчас этчер вылизан до блеска, но год назад пользоваться им было больно.

                                        0
                                        А почему rufus, а не dd?
                                        +3
                                        Ужасный, отвратительный оверинжиниринг. Вы говорите о MVP, но ради мониторинга 30(!) скутеров строите систему, которая начинает складываться под своей сложностью. Зачем вам кластер с High availability? Зачем автоматическая раскатка обновлений? Нафига нужны промышленные решения для сбора метрик?
                                        Вы либо крестик снимите, либо трусы наденьте — или заявляя, что это MVP, сделать минимально-рабочую систему, не закладываясь на ситуацию «ну вооот, у нас когда-то же будет не 30, а 30000 скутеров, тогда и пригодится», и тогда половина всего это не нужно, или сказать, что все-таки фигачим на перспективу, и не пытаться подстроиться под решения на готовом ПО, а просто взять и написать свой сервер, благо с таким функционалом его написать можно за неделю, взяв какой-нибудь эластик для долговременного хранения логов и поиска по ним.
                                          0
                                          А вот в микроблоге у себя вы эту статью назвали более интересным словом. Ну окей.
                                            +1
                                            В более тесных каналах повидавших разное разработчиков эта статья многочисленно разбиралась таким образом, что микробложные выражения уважаемого vvzvlad были даже комплиментами.
                                              +1
                                              А надо было разбирать в комментах к статье. Который раз наблюдаю дико забавную ситуацию: разработчики в атмосфере любви и единогласия в личных микроблогах обсуждают статью в негативных тонах, но на «Хабре» критиковать в комментах и защищать свою критику стесняются.
                                                +2
                                                Это так называемый феномен «обратной токсичности».

                                                На этом ресурсе за объективную критику, выражаемую определённым небольшим компетентным процентом пользователей, можно получить субъективные оценки от большого, некомпетентного, но очень активного и неуважительного процента.

                                                Поэтому уважающие себя компетентные разработчики действительно объективную критику дают там, где они контролируют токсичность среды сами.

                                                Такие дела.
                                                  0
                                                  Тем не менее вы это отвечаете в треде, где в ответ на vvzvlad не набросились и не съели его. Да и не он один: тут почти все комменты ругают избыточность технических решений. Какого-то некомпетентного большинства я просто не вижу.
                                                    0
                                                    Во-первых, статья отлежалась и всё отгремело.
                                                    Во-вторых, даже в ответ на конструктивную критику автор отстреливается из штурмгевера.
                                                    Смысл?
                                                    Более того, минусов уважаемому vvzvlad уже насовали и баланс он держит благодаря наплыву тех, кто с ним солидарен. Вероятно, если будет хайп-два, то «РРРЯ» будет более сильным.

                                                    «Если не видите, то его нет».
                                                      +2
                                                      статья отлежалась и всё отгремело.
                                                      Тут уже с первых комментариев только критика. Любви и обожания лично я не вижу.
                                                      автор отстреливается из штурмгевера
                                                      Откуда вы знаете, что минусует конкретно он? Если такая уверенность есть, ну минусуйте в ответ.
                                                      он держит благодаря наплыву тех, кто с ним солидарен
                                                      Вероятно, если будет хайп-два
                                                      Да просто свою точку зрения он изложил грамотно и всё подробно обосновал. Это не просто эмоции «мне не нравится, уносите»: указаны конкретные точки, где масштабирование будет затруднено.
                                                        0
                                                        Я лишь отметил, что его начали есть. Какая разница, автор или нет?
                                                        Мне быть съеденным не хочется, поэтому я буду критиковать в другом месте.
                                                          +1
                                                          Эй, я все еще тут!
                                                            0
                                                            Стало быть, пронесло.
                                                              0
                                                              Но на самом деле, я скорее за то, что и правда повезло: вот тут видно, что происходит с комментарием не совсем в духе мнения партии.
                                                                0

                                                                Там проблема не с "мнением партии", а со странной трактовкой фактов. Подробнее уже ответили в той ветке.

                                            0

                                            Сказал бы, что с вами не согласен, но вижу что вы даже не прочитали статью:


                                            1. Мы не делали кластер с HA, потому что для пилота и нашего небольшого количества скутеров нам вполне хватило одного инстанса InfluxDB, именно об этом и написано в разделе про Influx.
                                            2. Обновления были совершенно необходимы, чтобы банально не бегать каждый раз по всему городу за скутерами, дабы установить на них последнюю версию софта/агента/драйверов которые, даже за время пилота, обновлялись многократно
                                            3. Что значит "зачем промышленные решения"? TICK промышленный? Тогда почему вы предлагаете еще более монструозный эластик как решение? (и ведь про него тоже есть в статье)

                                            Говоря об MVP — мне кажется, то что "делаем на перспективу" очевидным. В этом вся его суть — нет смысла делать пилот, если изначально нет надежд на развитие продукта.


                                            И конечно, делать их нужно быстро и "чтобы работало". Но если качественная реализация, которую после MVP переделывать не придется, реализуется быстро — почему бы не сделать сразу?

                                              +5
                                              Да нет, почему же. Прочитал.
                                              У вас половина статьи про выбор стека для обеспечения HA, и потом где-то в конце «а, ну кстати и одного InfluxDB хватает, оказывается». Да блин, а нафига было тратить кучу времени и вообще думать в сторону HA и ынтерпзайзного TICK? То, что одного инстанса хватит — можно было оценить примерно за пять минут, умножив 30 скутеров на количество метрик в секунду.
                                              Обновлять было необходимо приложение, а не систему. Для обновления приложения хватило бы apt-get upgrade you_program по крону или через условные systemd/Timers или напрямую бинарник из репы гита. Это делается примерно за 2 чд, а у вас ушло полторы недели на подбор сервиса, в котором есть все, разве что гусей не насилуют, и в конце-концов, вы еще и выкинули наработки, потому что не смогли использовать.

                                              Не надо «делать на перспективу», это оборачивается вот такими штуками — когда на каждую мелочь сначала неделю команда пытается продумать все возможные требования, а потом еще неделю героически решает несуществующие проблемы, что кратно увеличивает срок разработки. Сделали первую версию, поработали, если выжили — выкинули 7чд, сделали за такой же срок новую версию. Эластик монструозный и много жрет памяти, но какая разница, если у вас 30 скутеров? Вертикальным масштабированием это число скейлится примерно до 500, а там либо шах, либо ишак — или стартап сдохнет, или станет понятно, что модель рабочая, появятся новые требования, и можно будет осознанно написать новые требования к системе и что-то сделать на их основе новое. Вы раньше на трафик наткнулись, чем на ограничения по ресурсам сервера.
                                              После MVP систему приходится переделывать, в этом и суть: там не зря стоит слово «минимальный». Все равно в ходе эксплуатации появляются новые требования. Не надо писать ничего сверх того, что необходимо для работы, это позволяет проверять гипотезы быстро и без особых затрат — в том числе потому, что сделанное стоит недорого, и его можно легко выбросить и переделать, как только возникла в этом нужда. А как только вы тратите 150чд на проект, вы уже не можете переделывать это каждый раз — вам жалко усилий, кода, времени, денег, а ненужная тяжесть системы уже тянет вас на дно, накладывая обязательства по поддержке и использованию этого кода.
                                              Про то, что «реализуется быстро» я честно говоря, не понял — половина статьи это нытье про то, что мало времени. Если ты чувствуете за спиной дыхание дедлайна — это значит, вы реализуете проект недостаточно быстро, либо сами сроки разработки были оценены неверно. И несмотря на то, что было мало времени, вы все равно напихивали и напихивали в стек ненужных сервисов, пытаясь сделать красиво и на века, хотя там хватило бы скрипта на питоне, который бы пихал данные в ES, и некоторой обвязки для его нормальной работы.
                                              Оставшееся время стоило потратить на более внятные алерты, чтобы не возникало ситуации «аккумулятор сел, а мы даже не знали, что он сел, потому что были озабочены HA, а не снятием состояния батареи».
                                                –3

                                                Опять вы со своим эластиком и масштабированием. Мы не занимались масштабированием и нам не нужен был эластик, просто потому что он значительно сложнее, тяжелее и медленнее TICK.


                                                Комментировать возможности обновления скутеров в виде крон джобы я даже не буду. И да, мы обновляли и систему в том числе.


                                                Но вы бы, конечно, сделали все то же самое с эластиком на питоне и за неделю. Что же, успехов вам. Только не забывайте вовремя сообщать о подобных своих достижениях в твиттере.

                                                  +1
                                                  Я ожидал более конструктивного диалога, а не обиды. Жаль.
                                                    0

                                                    Ничего вы не ожидали, если хотите конструктив — то будьте добры и сами писать по делу.


                                                    На самом деле, то что проект оверинженирен само по себе чистая правда, только вот кроется это вовсе не в масштабировании или доставке обновлений.


                                                    Без регулярных удаленных обновлений софта было бы крайне некомфортно проходить даже пилотную фазу. Конкретно пакеты именно через apt и доставлялись, только делалось это не по крону, а по событию от анзибла. Ничего сверх-сложного тут нет, оно работает и стабильно.


                                                    А про мониторинг — я пытался описать максимально подробно свой опыт использования стека — авось кому понадобится, а может быть кто-то захочет и скалировать его для своих задач (и не сможет этого сделать). Специально обрисовал видимые нами недостатки, альтернативы, чтобы кто-то мог спроецировать свои требования в будущем.


                                                    Тот же эластик, как мне кажется, уже морально устарел и описанные в статье альтернативы его прекрасно заменяют. Отмечу, кстати, что скалирование эластика — весьма себе непростая задача, даже для вполне прокачанных девопсов.


                                                    С ВПНом можно было бы поступить гораздо проще (отказаться от WireGuard), имей мы доступ к симкам для которых были бы доступны готовые профили OpenVPN aka 1nce — но на тот момент у нас их просто не было.


                                                    В чем действительно была проблема данного проекта — так в изначальной идее децентрализованного проката, но вы ведь об этом даже не подумали. А тут и кроется основной недостаток любой подобной платформы — что бы ни было внутри, эфир, DIDы итд — все это должно одновременно быть анонимным и децентрализованным (как условные криптовалюты), но при этом отвечать нормам и правилам того или иного государства.


                                                    Как сделать децентрализованный анонимный прокат, который можно будет при этом проводить по немецким законам? Как не следить за пользователями, за которым по закону нельзя следить, но при этом не потерять возможности контроля над скутерами?


                                                    Такие вопросы я вижу конструктивными.

                                                      0
                                                      А я правильно понимаю, что вы сделали всё, чтобы нарушить немецкое законодательство?
                                                        0

                                                        Наоборот. Благодаря тому, что данные были действительно анонимизированы, мы смогли собирать со скутеров всю информацию в рамках закона. В эфире пользователи не имели никакой персонализации кроме совершенно случайных публичных ключей.

                                                          0
                                                          Я про косвенную деанонимизацию клиента. Вроде, в свете современного акта, регулирующего обмен криптовалютой, говорится, что данные, не связанные с финансовой стороной вопроса, регулируются внешним законодательством.

                                                          Технически, с точки зрения криптоакта это, конечно, анонимизированные данные. Но, с позиции DPA, связанный с криптоактом кортеж данных (телеметрия, например), приводящий к деанонимизации, может сыграть злую шутку.

                                                          У вас логи на оконечных устройствах шифровались? И применялись организационно-технические меры для предотвращения атак на сами устройства?
                                                            0

                                                            Надо отметить — на самих устройствах мы не имели права собирать какие-либо данные, которые могли бы быть связаны с пользователем. Это касается персонификации, местоположения, итд.


                                                            Все операции были эфир транзакциями и по определению были публичны, другое дело, что шифровать их нужды не было, так как там не было данных, которые могли нарушать закон. Мы довольно долго проводили аудит этой темы и GDPR с legal отделом, так что в этом проблем не было.


                                                            Логи с устройств мы тоже не собирали, по тем же причинам — для нас телефоны были только устройствами которые могли запрашивать у скутера информацию напрямую и отправлять в эфир сеть какие-то транзакции.

                                                              0
                                                              Ну, я задал два вопроса и ответа на них не увидел.
                                                              Имели право или нет — это вопрос второго плана.
                                                              А вот собирали или нет — вопрос первого.
                                                              Собственно, по причине существования плавно обойденных моментов (на фоне довольно детальной и избыточной проработки технического вопроса в формате некоего «руководства к действию для тех, кто пойдёт таким путём») ваша статья и вызвала неоднозначный, резкий, и непубличный выброс метана в закрытых сообществах (если вы икали последние пару дней, то да, причина тут).
                                                                +1

                                                                Само собой, мы собирали только те данные, которые могли собирать по закону — потому телефоны мы никак и не мониторили.

                                                        0
                                                        > Без регулярных удаленных обновлений софта было бы крайне некомфортно проходить даже пилотную фазу.

                                                        Пилотная фаза в терминологии ГОСТ 34.601-90 — это «проведение необходимых научно-исследовательских работ» или «проведение опытной эксплуатации»?

                                                        > Такие вопросы я вижу конструктивными.

                                                        Но ни один из них вы в статье не осветили, а вместо этого погрузились в бессмысленные технические детали.
                                                          +1
                                                          А ГОСТ на МВП вы не подскажете?
                                                            –1
                                                            Можно использовать говно и палки, точнее, ГОСТ 26074-84 и ГОСТ 8486-86.
                                                          0
                                                          Ничего вы не ожидали,

                                                          А, да, простите, вам лучше знать, чего я ожидал, а чего не ожидал. Подскажете, куда я ключи от гаража дел, вторую неделю найти не могу?
                                                +1
                                                > Распределённая система
                                                > Скутер сам списывает криптовалюту со счетов клиентов
                                                > Централизованный мониторинг координат
                                                > Систему построили так, что бы в любой момент можно было поменять что угодно без ведома клиентов
                                                > Клиенты оставляют скутеры у себя под домом

                                                Ну, нормально, добротный такой криптостартап, 10 инвестиций из 10.

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                Самое читаемое