Opened 8 years ago
Last modified 5 years ago
#88 new enhancement
Цвет блока в зависимости от аварии
| Reported by: | andrei | Owned by: | vlad |
|---|---|---|---|
| Priority: | minor | Milestone: | 2 очередь |
| Component: | 3U-Supervisor | Keywords: | |
| Cc: | san |
Description
В Алмазном просили изменение состояния датчиков не выводить как красную аварию с годзилой, ибо все пугаются и думают что связь пропала.
Предложение: при срабатывании датчиков блоки не красными делать, а, например, синими.
Ну и интерфейс выбора звука надо какой-то прикрутить (это уже от меня))
Change History (6)
comment:1 by , 7 years ago
| Milestone: | Исправление багов, добавление полезностей → 2 очередь |
|---|
follow-up: 6 comment:3 by , 5 years ago
Такой механизм уже заложен в мониторинг: у аварий есть две градации: "срочная" и "не срочная".
Не срочные аварии отображаются в веб-интерфейсе жёлтым цветом, но при этом выводятся на внешний ALARM и пищат буззером. В чём их смысл сейчас не понятно.
В супервизоре сделано так же (это было частью начального ТЗ): любые аварии (срочные и не срочные) выводятся как АВАРИИ, подсвечивая блок красным цветом (в логе аварий внизу окна программы не срочные отображены жёлтым).
comment:5 by , 5 years ago
В чём их смысл сейчас не понятно.
Очевидно же :
"срочная" и "не срочная"
В протоколе передачи аварий, заложена градация аварий по срочности (на самом деле не две, а целый байт). В ТЗ на вебморду тоже изначально сказано любые аварии выводить на общую.
Правильно этот тикет решить так:
- На плате с датчиками реализовать настройку срочности аварий.
- В супервизоре аварии со значением срочности >2 отображать "по другому"
Через задницу этот тикет можно решить так:
- В супервизоре добавить настройку масок конкретных аварий, при установке маски - авария отображается по другому
comment:6 by , 5 years ago
Replying to vlad:
В чём их смысл сейчас не понятно.
Я могу пояснить.
Представь себе компьютер. Допустим, это сервер, выполняющий какие-то важные функции. И в один прекрасный день он пропадает из сети. Естественно, при этом он перестает выполнять свои функции. Обслуживающий персонал должен немедленно бежать и как-то исправлять ситуацию. Это - срочная авария (или иными словами - авария с высоким приоритетом).
А представь немного другую ситуацию. Ты мониторишь в своем сервере размер свободной памяти, и в один прекрасный день он снижается ниже заданного порога (допустим, меньше 500 Мб). При этом ничего не сломалось, память пока еще есть, и все продолжает работать. Возможно, это просто временное увеличение нагрузки на сервер, и скоро размер свободной памяти сам вернется к своему обычному значению, и тебе ничего не надо делать. А может быть надо подкрутить настройки, чтобы сервер более экономно использовал память. А может надо неспеша докупить еще памяти и, как будет возможность, добавить... Это - несрочная авария (авария с низким приоритетом).
На самом деле градаций приоритета аварий может быть больше двух. Представь себе, что в твоем сервере работает массив RAID1, и один из HDD в нем вышел из строя. Отказа сервера при этом нет, он продолжает работать на оставшемся HDD, однако ты должен бежать и менять вышедший из строя HDD на исправный, потому что иначе при отказе второго откажет весь сервер. Это - авария со средним приоритетом.
В идеале, в системе мониторинга количество приоритетов аварий и их параметры (название/цвет/звук и т.п.) должны настраиваться.
Milestone renamed