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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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


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


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


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


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

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


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

для функционала по децентрализованной аутентификации


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

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

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

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

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

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

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

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