Согласен, исходя из истории фри, да и в целом исходя из портов. Кажется в линукс старались стандартизировать /usr/src под сборку, но получилось кто во что горазд, /opt, /mnt, и так далее.
В общем спасибо за отклик

👌👌👌

В линуксах по сути тоже самое почти во всех дистрах. То что установлено штатным средствами обычно живёт в /usr (тоже самое что и пакеты во фре), а то что через configure make install без явного задания префикса в /usr/local (аналог портов во фре).

Коллеги, нужна помощь. Проверяю прокси сервер haproxy с помощью пассивных проверок. Итемы генерируется скриптом на python. При проверке локально значение получается практически мгновенно. При запуске zabbix_get с сервера время ожидания 5 секунд. Самое странное - это резкая нагрузка на poller. То есть 1 включенный сервер генерирует четверть суммарной нагрузки. При этом performance счетчик вырастает на 5. Увеличение количества счетчиков в zabbix на итоговый результат влияет мало.

Утречка. Раньше такого не было, в новых версиях куча информационных триггеров сама не закрывается, внутри написано “Ack to close”. Никого больше не напрягает? Мне вот, как тому, кто настраивает мониторинг, совсем не хочется ходить и закрывать алерты на проде. Да и рассказывать раз в полгода тем, кто обновляет операционки, как это делать — тоже. Понимаю, что я волен делать что хочу и как хочу, но стоковые триггеры на то и стоковые, чтобы удовлетворять большинство. А меньшинство — может и кастомизировать. Вот хочу понять, я один такой, кому неудобно?

1. Дебаг логи на агенте в помощь — 5 левел
2. Сжатие включено?
3. Объём айтемов получаемых какой? Может там мегабайт целый — вот оно и перекачивается сто лет.

Поллер нагружается потому, что ждёт ответа агента, это норм. Вопрос тут в том, почему долго отвечает агент.

Подскажите плз. Стоит версия 5.0.2 в обнаружении отображаются все узлы, однако те узлы, что опрашиваются через прокси отображаются только по IP

Зависит не от уровня триггера, а от самого триггера. Если 100% требуется ручная проверка инцидента то ask to close это норм.

В новом заббиксе есть из коробки шаблон для хапрокси

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

В тех шаблонах, о которых говорит Илья это обновление ОС, скорость порта стала ниже, чем была

Не один.
Ack to close представляется логичным поведением, но закрывать таки задалбывает, это да. Народ пообновляет ОС, или модуль какой в железке заменят, а эти триггеры висят неделями.

Я бы ещё может макрос сделал, типа, если хочешь, чтобы само открывалось/закрывалось — правь этот макрос.
Лукс лайк э джоб фор интегратион тим! @AlexL2 ? :))

Да, я про это же и говорю — они внедрили эту схему как “бест практис” во всех дефолтных шаблонах.

Если наберём 50 голосующих, а перевес будет в сторону автоматики — поставлю задачу

1. Смотрел. Под рукой нет, но в целом результат 0.00... условно время ответа
2. Тут можно поподробнее?
3. Не смотрел. Но вряд ли большой. Все ответы переведены в 0 или 1 при передаче.
Единственное, что точно знаю - был перезапуск системы перед этим. До этого нагрузки не было
Версия сервера 4.2

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

Звучит не очень

Товарищи, а что у нас в образах докера, новая переменная среды для фронта - DB_SERVER_TYPE? По-моему раньше не было