​​Хочу немного порассуждать и дать несколько советов из своей практики на тему визуализации мониторинга. Когда я настраиваю систему мониторинга на заказ, меня почти всегда просят сделать красивые и информативные дашборды. Когда дело доходит до практики, оказывается, что никто толком не знает, что на них должно быть. И почти всегда у меня получается убедить, что тратить время и деньги на рисование дашбордов не имеет смысла, если мониторинг делается для удобства эксплуатации системы, а не для того, чтобы было что показать руководству. Визуализация нужна для тех объектов мониторинга, для которых не нужны или не важны триггеры. Поясню на своём примере. У меня есть дашборд с визуализацией техники в квартире. Речь идёт о NAS, общем компьютере, моём тестовом сервере, компьютере сына. Вечером перед сном я обычно открываю дашборд, смотрю, что из техники включено и выключаю. Я не вижу смысла оставлять их включенными ночью. При этом у меня нет никаких триггеров на эту технику. Мне не нужно знать о том, что что-то включилось или выключилось. Ещё один пример, который наблюдал. В Zabbix настроена интеграция со СКУД. Начальник отдела может посмотреть, где находятся его сотрудники, если не видит их в кабинете. Ему показано, кто в какой зоне и когда в неё пришёл. Когда кто-то нужен и его нет на месте, можно быстро посмотреть, на каком он этаже и есть ли он вообще в здании, когда вышел. Это удобно именно в виде дашборда с информацией. И совершенно не нужны триггеры и оповещения по этой теме. А вот всё, что покрывается пороговыми значениями с настроенными триггерами нет никакого смысла визуализировать. Например, в Zabbix есть готовый виджет с топом хостов по загрузке процессора. И какой смысл за всем этим наблюдать, если загрузка не выходит за пороговые значения? Ещё популярны визуализации в виде зелёных и красных блоков или кружков. Зачем они? На эти метрики настроены триггеры и оповещения. Поддержка и так моментально узнает через оповещение о том, что что-то случилось. Исключения бывают для пороговых метрик, если они объединены связями в большие увязанные между собой системы. Например, я делал в Zabbix визуализацию довольно сложной многоконтурной системы охлаждения с кучей различных датчиков (температуры, давления, уровня жидкости и т.д.) и механизмов (помпы, драйкулеры и т.д.). Система была схематично нарисована и основные метрики были выведены на схему, чтобы при срабатывании триггера было видно, в каком именно элементе системы возникла проблема. Ещё пример, когда визуализация нужна, потому что за ней постоянно кто-то наблюдает. Видел в одном ЦОД в комнате инженеров огромный экран на стене с графиком загрузки входящих каналов интернета. Я так понимаю, при виде постоянно возрастающей нагрузки ребята начинают напрягаться ещё до того, как значения дошли до первых пороговых значений. В завершении расскажу случай по другой теме, но с которым столкнулся при настройке мониторинга на днях. Нужно было в триггере уменьшить интервал реакции на проблему. Стоял порог на отсутствие данных в течении 5 минут, изменил на 1 минут. И мониторинг начал тупить и давать очень много ложных срабатываний. В таком виде он стал бесполезен, потому что сильно отвлекает. На что я только не грешил. А оказалось, что опрос метрики делался тоже раз в минуту. Для порога в 5 минут, это нормально, а когда порог стал 1 минута, начались бессистемные ложные срабатывания. Изменил время опроса до 20-ти секунд и порог в минуту стал нормально работать. #мониторинг