Вопрос к инженерам систем мониторинга и DevOps: приоритизация данных в Dashboard?

Question

[juvezi1]

Привет, Хабр! Я проектирую интерфейс мониторинга для парка из 100 беспилотных автомобилей. Столкнулся с вопросом приоритизации данных для оператора.
Машина передает: статус, заряд, тех. неисправности, ошибки софта и локацию.
Вопрос к тем, кто работает с системами мониторинга (флот, сервера, логистика):
Что для вас является „триггером паники“ №1? (Например: резкое падение заряда или потеря связи софтом?)
В какой момент вам удобнее видеть карту, а в какой — сухой лог ошибок?
Какое действие вы бы хотели иметь „под рукой“ (в один клик) при получении критического алерта?
Буду благодарен за примеры из вашего опыта работы с Grafana, Zabbix или проф. системами управления флотом.

Comments

[Василий Банников]

А у вас там рядом нет коллеги-оператора, которому можно этот вопрос адресовать?

Логам на дашборде не место, имхо. Не та плотность информации.

А так раз много однородных объектов мониторинга, то напрашивается:
1. Карта с общим состоянием в виде таблицы из красных-жёлтых-зеленых квадратов. Чтобы сразу увидеть, требует ли что-то внимания.
1б. Если важен уровень заряда, то его тоже можно похожей карте отобразить уровень заряда в моменте, но вместо трёх дискретных цветов - плавное изменение цвета.

2. По нажатию на конкретный квадрат - пусть перекидывает в секцию с графиками всех показателей (уровень заряда, количество/скорость ошибок)
3. Следующий уровень - посмотреть логи по конкретной машине за определённый период.

4. Отдельно наверное ещё есть смысл карту города с местоположением каждой машины отобразить с состоянием (стоит, заведена, едет, на заказе, ждёт заказа, поломка, нет связи, итд, сколько у вас там статусов).
Если статусов очень много, то наверное стоит объединить их в группы.

Не скажу про заббикс, но в графане это реализовать точно можно.

[juvezi1]

Василий Банников, делаю тестовое задание, в котором нужно создать макет сервиса) Бтв и под боком нету ни одного человека, кто в этом разбирается =) плюс очень проблематично чекнуть хоть какие-то похожие сервисы т.к зайти туда анрил(чтобы только посмотреть сам сервис)

Все, что я смогла найти ток инфу с видосов, статей + ИИшка, но в любом случае эт оч мало т.к всегда нужен человек в этом вопросе( Подскажите, можно ли вас поспрашивать на эту тему ? Для меня это правда важно, если для вас это не затруднительно то, буду безумна благодарна любой информации/помощи

[Василий Банников]

juvezi1, попробуйте пойти таким путём:
1. Представьте парк автомобилей как систему.
2. Выпишите, какие изменющиеся во времени характеристики (метрики) у этой системы есть, какие могут произойти сбои, как они будут проявляться в метриках, как эти сбои влияют на бизнес и как должен реагировать на это оператор (сколько времени на реакцию, какие конкретно действия).
3. Спуститесь на уровень ниже: разбейте систему "автопарк" на подсистемы со связами, повторите предыдущие шаги. Связи тоже важны, они тоже могут сбоить.
4. У обязательно думайте о том, какой поток данных будет, если собирать определённую метрику. Нет смысла собирать то, что не позволит сделать никаких новых выводов.

У каждого сбоя/метрики есть свой уровень критичности для бизнеса.

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

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

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

По Grafana в интернете достаточно много ресурсов есть.

[VoidVolker]

делаю тестовое задание, в котором нужно создать макет сервиса) Бтв и под боком нету ни одного человека, кто в этом разбирается =)

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

[Валентин]

делаю тестовое задание, в котором нужно создать макет сервиса)

Нифига себе. Надеюсь, вам за это тестовое заплатят, это че-то как-то чересчур.

Answer 1

[VoidVolker]

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

Для парка авто, я бы сделал карту с иконками автомобилей. Цвет иконки — цвет машины, подписи — уровень заряда, госномер и, если авто разных моделей и марок, то модель и марка. Дополнительно — информация о водителе. Отображаемые параметры должны быть переключаемыми, чтобы можно было вывести только то, что нужно именно сейчас. Можно даже несколько режимов сделать. Цветная надпись "статус авто": например — "поломка", "в ожидании", "выполняет поездку" и т.д. Плюс дополнительные слои карты — пробки и ситуации на дорогах, альтернативные источники (у разных провайдеров карт часто реальность немного отличается), панорамы и т.п. Для диспетчеров можно вывести какие-то дополнительные параметры. Плюс отдельно список автомобилей с поиском и сортировкой по важным параметрам, поиском на карте, а при выборе авто — вся подробная информация.