баг?

Кто-нибудь использует переменные окружения в external checks? Заббикс передает сейчас все аргументы в двойных кавычках в external scripts, поэтому такие переменные раскрываются: [root@localhost]# cat test.bash #!/bin/bash echo $1 [root@localhost]# bash test.bash "$PATH" /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin У кого-нибудь что-нибудь сломается если заббикс будет передавать все в одинарных кавычках? [root@localhost]# bash test.bash '$PATH' $PATH https://support.zabbix.com/browse/ZBX-12963

Всем привет 3.4.3 для хостов есть итем zabbix[host,snmp,available] и на него создан триггер, все из стандартного шаблона так вот на хосте сменили пароль и заббикс не смог достучаться до хоста, в статусе всех item стоит unkonwn user но триггер при этом не горит, да и если смотреть по данным для zabbix[host,snmp,available] то там 1

какой пароль сменили? snmp community?

какой пароль сменили? snmp community?

для пользователя, стандратные шаблоны snmpv2 я переделал под snmpv3 добавлением 3 макросов и изменением элементов данных на snmpv3

Подскажите как правильно мониторить vCenter который крутится на linux applience. Есть у кого то такой опыт? Интересуют именно низкоуровневые метрики с машины, загрузка ЦП, свободное место, память и т.д.

Я правильно понимаю, что единственный способ, это ставить zabbix агента? Нет никакой интеграции?

Вроде автодискавери по api

Подскажите как правильно мониторить vCenter который крутится на linux applience. Есть у кого то такой опыт? Интересуют именно низкоуровневые метрики с машины, загрузка ЦП, свободное место, память и т.д.

Посмотрите штатные шаблоны Template Virt VMware/ Template Virt VMware Guest / Template Virt VMware Hypervisor Возможно там есть то что вам нужно

@rheinx Спасибо за совет. Это мы уже используем. Информации собираемой таким способом недостаточно.

@rheinx Спасибо за совет. Это мы уже используем. Информации собираемой таким способом недостаточно.

тогда можно попробовать добить нужных метрик в Template Virt VMware Guest. Если их гипервизор конечно выдает.

Кстати хорошая идея, посмотрю что можно получить с помощью запросов к api

Кстати хорошая идея, посмотрю что можно получить с помощью запросов к api

ну, а если все же не достаточно, то можно сунуть агента в темплейт виртуалки и настроить авторегистрацию хостов в Zabbix. Тогда при подьеме каждая новая вирта сразу будет попадать в Zabbix

Здоров всем. Есть ли такие кто мониторил фискальники по snmp?) В частности Штрих М

Интересный вызов

mibы есть?

Привет всем. Назрело 2 вопроса. 1. Есть у кого расширенный темплейт для mikrotik wifi (с мониторингом уровней сигнала)? 2. Нагрузку nginx / php-fpm принято мониторить при помощи скриптов ZTC или есть что-то современее?

Кто ж юзера в фискальник пустит...

Это нарушение устава, инструкций и нормативных документов

mibы есть?

Нет конечно)

Кто ж юзера в фискальник пустит...

Так мне ж нужно только read права. Чем нарушения? Я то все реквизиты компании знаю

Лишний вектор атаки

А это дополнительные затраты на сертификацию и пр. Можно даже и не пройти ее

Думаю там и так всё дыряво

Есть кто может ответить на пару вопросов по snmp трапам? Если при этим сам zabbix работает у вас в docker-e тогда вообще отлично)

Для тех, кто не заметил: вышел Zabbix 3.4.5rc1, 3.2.11rc1, 3.0.14rc1 and 2.2.21rc1. Zabbix 3.4.5rc1 с поддержкой Elastic! https://www.zabbix.com/rn3.4.5rc1

Для тех, кто не заметил: вышел Zabbix 3.4.5rc1, 3.2.11rc1, 3.0.14rc1 and 2.2.21rc1. Zabbix 3.4.5rc1 с поддержкой Elastic! https://www.zabbix.com/rn3.4.5rc1

А есть документация по использованию?

Для тех, кто не заметил: вышел Zabbix 3.4.5rc1, 3.2.11rc1, 3.0.14rc1 and 2.2.21rc1. Zabbix 3.4.5rc1 с поддержкой Elastic! https://www.zabbix.com/rn3.4.5rc1

Добавили поддержку elastic в минорном релизе? Странно выглядит. ) Но в целом, наверное будет круто.

Коллеги, привет! А есть ли возможность включить триггер при срабатывании другого триггера?

google trigger dependencies

google trigger dependencies

и будет отправлено только одно оповещение о корне проблемы.

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

Как вариант, через Действие сендером отправить единичку на другой созданный элемент данных и взвести новый триггер

Всем привет помогите у меня какая то чертовщина массово сработали триггеры на {Template App Zabbix Agent:agent.ping.nodata(5m)}=1 практически на всех хостах и данные методом zabbix agent перестали собираться agent.ping Item имеет тип zabbix agent через zabbix_get на сервере все прекрасно снимается # zabbix_get -k agent.ping -s 10.216.131.180 1 но в логах агентов есть вот такое 7374:20171212:065948.326 active check configuration update from [zabbix.server:10051] is working again 7374:20171212:070826.034 active check configuration update from [zabbix.server:10051] started to fail (ZBX_TCP_READ() failed: [4] Interrupted system cal l) service zabbix-server restart и service zabbix-agent restart не помогают рестарт сервера приводит к кратковременному пропаданию триггеров а потом снова жопа в логах сервера при стопе вот такое 26355:20171212:184510.654 Got signal [signal:15(SIGTERM),sender_pid:24469,sender_uid:0,reason:0]. Exiting ... 26355:20171212:184512.681 syncing history data... 26355:20171212:184522.005 syncing history data... 4.866511% 26355:20171212:184532.006 syncing history data... 9.963320% 26355:20171212:184542.005 syncing history data... 15.345901%это вообще что за syncing history data? и почему она идет так долго? Раньше рестарт zabbix-server проходил быстро

Всем привет помогите у меня какая то чертовщина массово сработали триггеры на {Template App Zabbix Agent:agent.ping.nodata(5m)}=1 практически на всех хостах и данные методом zabbix agent перестали собираться agent.ping Item имеет тип zabbix agent через zabbix_get на сервере все прекрасно снимается # zabbix_get -k agent.ping -s 10.216.131.180 1 но в логах агентов есть вот такое 7374:20171212:065948.326 active check configuration update from [zabbix.server:10051] is working again 7374:20171212:070826.034 active check configuration update from [zabbix.server:10051] started to fail (ZBX_TCP_READ() failed: [4] Interrupted system cal l) service zabbix-server restart и service zabbix-agent restart не помогают рестарт сервера приводит к кратковременному пропаданию триггеров а потом снова жопа в логах сервера при стопе вот такое 26355:20171212:184510.654 Got signal [signal:15(SIGTERM),sender_pid:24469,sender_uid:0,reason:0]. Exiting ... 26355:20171212:184512.681 syncing history data... 26355:20171212:184522.005 syncing history data... 4.866511% 26355:20171212:184532.006 syncing history data... 9.963320% 26355:20171212:184542.005 syncing history data... 15.345901%это вообще что за syncing history data? и почему она идет так долго? Раньше рестарт zabbix-server проходил быстро

Такая же фигня была. Ничего не смог сделать. Как-то само отпустило. Но в доках zabbix рекомендовано использовать zabbix[agent, availability] (вроде так)

Я так и сделал. А потом, через некоторое время, вернулся на nodata.

С сервером все нормально? Файрволы ни где не настраивали хитрые?

Лог заббикс сервера бы глянуть еще

Для тех, кто не заметил: вышел Zabbix 3.4.5rc1, 3.2.11rc1, 3.0.14rc1 and 2.2.21rc1. Zabbix 3.4.5rc1 с поддержкой Elastic! https://www.zabbix.com/rn3.4.5rc1

Да ты шо : New Features and Improvements [ZBXNEXT-4002] implemented support for elasticsearch as history storage

Коллеги, привет! А есть ли возможность включить триггер при срабатывании другого триггера?

Да

Да

Подскажи пожалуйста как?:)

Про эластик в 3.4.5. Я так понимаю, что теперь хистори можно будет хранить в эластике. Не обязательно, но как вариант, да?

Подскажи пожалуйста как?:)

А что, зависимые триггеры не подходят?

И что за ситуация? Подробнее.

А что, зависимые триггеры не подходят?

Нуууу, я может и туплю конечно, но суть вот в чем: есть триггер который ловит превышение трафика более 4 мегабит на порту 1, и через саблю применят qos ограничение в 1 мегабит. Так вот, если трафик все равно забивается на 1 мегабит, порт 1 надо выключить.

Я думаю тайминги триггеров поставить побольше

Нуууу, я может и туплю конечно, но суть вот в чем: есть триггер который ловит превышение трафика более 4 мегабит на порту 1, и через саблю применят qos ограничение в 1 мегабит. Так вот, если трафик все равно забивается на 1 мегабит, порт 1 надо выключить.

Т.е. у вас на узле два триггер >4 и >1, но второй должен срабатывать только если сработал первый что ли?

Т.е. у вас на узле два триггер >4 и >1, но второй должен срабатывать только если сработал первый что ли?

Ага:)

Ну как бы зависимые триггеры для этого и сделаны. Только у вас идёт от бОльшего к меньшему, не могу сообразить как сделать...

Ну как бы зависимые триггеры для этого и сделаны. Только у вас идёт от бОльшего к меньшему, не могу сообразить как сделать...

Да я думаю тайминг больше поставить и все)

Не, чё-то не могу такую схему выстроить с помощью зависимостей. )

Всем привет помогите у меня какая то чертовщина массово сработали триггеры на {Template App Zabbix Agent:agent.ping.nodata(5m)}=1 практически на всех хостах и данные методом zabbix agent перестали собираться agent.ping Item имеет тип zabbix agent через zabbix_get на сервере все прекрасно снимается # zabbix_get -k agent.ping -s 10.216.131.180 1 но в логах агентов есть вот такое 7374:20171212:065948.326 active check configuration update from [zabbix.server:10051] is working again 7374:20171212:070826.034 active check configuration update from [zabbix.server:10051] started to fail (ZBX_TCP_READ() failed: [4] Interrupted system cal l) service zabbix-server restart и service zabbix-agent restart не помогают рестарт сервера приводит к кратковременному пропаданию триггеров а потом снова жопа в логах сервера при стопе вот такое 26355:20171212:184510.654 Got signal [signal:15(SIGTERM),sender_pid:24469,sender_uid:0,reason:0]. Exiting ... 26355:20171212:184512.681 syncing history data... 26355:20171212:184522.005 syncing history data... 4.866511% 26355:20171212:184532.006 syncing history data... 9.963320% 26355:20171212:184542.005 syncing history data... 15.345901%это вообще что за syncing history data? и почему она идет так долго? Раньше рестарт zabbix-server проходил быстро

Ставлю на проблемы с ip стеком. Закончились коннекты, переполнение conntrack, итп.

Ставлю на проблемы с ip стеком. Закончились коннекты, переполнение conntrack, итп.

Ставки сделаны. Ставок больше нет

:)

У меня на паре сотен агентов подобные проблемы иногда начали досаждать, пришлось гуглить оптимизацию таймаутов wait-состояний. А недавно перевёл почти весь мониторинг в активный режим, так сразу и коннектов стало меньше, и процессов

Кстати, причина исчерпания коннектов может быть не только в настройках ядра, а ещё в лимитах юзера.

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

Ставлю на проблемы с ip стеком. Закончились коннекты, переполнение conntrack, итп.

я тоже думал на это. но нет # netstat -nap | wc -l 2346коннектов не много врятли они закончились =( я еще думал что проблемы между ДЦ (zabbix в одном ДЦ, сервера в другом) но агент который на сервере запущен, тоже такую же хрень начал городить =( и абсолютно непонятно почему в таком случае zabbix_get для одного ключа нормально работает =(

я тоже думал на это. но нет # netstat -nap | wc -l 2346коннектов не много врятли они закончились =( я еще думал что проблемы между ДЦ (zabbix в одном ДЦ, сервера в другом) но агент который на сервере запущен, тоже такую же хрень начал городить =( и абсолютно непонятно почему в таком случае zabbix_get для одного ключа нормально работает =(

cat /proc/sys/net/netfilter/nf_conntrack_max /proc/sys/net/netfilter/nf_conntrack_count

и всё-таки базу надо смотреть, почему не успевает. База на чём? Что делалось для ускорения работы?

Что показывает dmesg на сервере?

Всем привет помогите у меня какая то чертовщина массово сработали триггеры на {Template App Zabbix Agent:agent.ping.nodata(5m)}=1 практически на всех хостах и данные методом zabbix agent перестали собираться agent.ping Item имеет тип zabbix agent через zabbix_get на сервере все прекрасно снимается # zabbix_get -k agent.ping -s 10.216.131.180 1 но в логах агентов есть вот такое 7374:20171212:065948.326 active check configuration update from [zabbix.server:10051] is working again 7374:20171212:070826.034 active check configuration update from [zabbix.server:10051] started to fail (ZBX_TCP_READ() failed: [4] Interrupted system cal l) service zabbix-server restart и service zabbix-agent restart не помогают рестарт сервера приводит к кратковременному пропаданию триггеров а потом снова жопа в логах сервера при стопе вот такое 26355:20171212:184510.654 Got signal [signal:15(SIGTERM),sender_pid:24469,sender_uid:0,reason:0]. Exiting ... 26355:20171212:184512.681 syncing history data... 26355:20171212:184522.005 syncing history data... 4.866511% 26355:20171212:184532.006 syncing history data... 9.963320% 26355:20171212:184542.005 syncing history data... 15.345901%это вообще что за syncing history data? и почему она идет так долго? Раньше рестарт zabbix-server проходил быстро

А какая версия заббикса? Могу ошибаться, но какой-то баг в 3.4.0 вроде бы был на эту тему.

Всем привет Коллеги, подскажите, пожалуйста, на форуме не нашел ответа После обновления до 3,4 В карте пропали "стрелки" &#8593 В багрепе написано, что поправили Но заставить работать их так и не смог Были у кого такие проблемы ?

и всё-таки базу надо смотреть, почему не успевает. База на чём? Что делалось для ускорения работы?

cat /proc/sys/net/netfilter/nf_conntrack_max 262144у меня не очень много хостов всего 40 штук версия zabbix 3.2.x последняя из официального репозитория ubuntu 16.04 как смотреть базу? что под этим подразумевается?

ну что с ней делалось, кроме apt install?

и в dmesg тоже могут быть ответы

Всем привет! Есть вопрос касательно sla

Мне нужно мониторить sla виртуалок. Я создал родительский элемент "Виртуальные серверы" и в нем дочерние элементы "Имя первой ноды";"Имя второй ноды" и т.д. Допустим потушил одну ноду, во всем списке она стало красной, остальные зеленые. Правильно понимаю, что родительский элемент должен окрасится на 1/20(примерно) красным цветом, а остальное должно быть зеленым?

это период за 7 дней

zabbix 3.4.0

Мне нужно мониторить sla виртуалок. Я создал родительский элемент "Виртуальные серверы" и в нем дочерние элементы "Имя первой ноды";"Имя второй ноды" и т.д. Допустим потушил одну ноду, во всем списке она стало красной, остальные зеленые. Правильно понимаю, что родительский элемент должен окрасится на 1/20(примерно) красным цветом, а остальное должно быть зеленым?

Там не с 0% выводится (с 80 или около того)

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

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

Увидите, почему нет.

Ну а он у меня не показывает. Красит красным все

А как должно быть?

На вашем скрине sla общий 76%, полоска начинается с 80, поэтому все красное.

Появилась запись моего доклада с конференции Highload, я рассказывал о производительности Zabbix: https://www.youtube.com/watch?v=7H9ckAQOI58

Привет, есть проблемка не могу никак решить.. Часто один сервер становится не доступным по мнению zabbix-agent "Zabbix agent on is unreachable for 5 minutes " При этом по RDP можно на нем работать без проблем и ping проходит. Что может повлиять на работу zabbix-agent ?

Народ, с сайта Zabbix скачал шаблон для мониторинга APC симетры. Там есть температурный параметр: Probe temperature Что бы он мог значить?

Привет, есть проблемка не могу никак решить.. Часто один сервер становится не доступным по мнению zabbix-agent "Zabbix agent on is unreachable for 5 minutes " При этом по RDP можно на нем работать без проблем и ping проходит. Что может повлиять на работу zabbix-agent ?

Начать можно с логов агента

Начать можно с логов агента

в логах ничего нет. Поставил debug level 5

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

нет, я 5 поставил сейчас только, жду воспроизведение проблемы

а так при дефолтном не было записей с ошибками..

сколько процессов агента запущено? какой таймаута от агента? какой профиль нагрузки у сервера (случайно не файловый сторадж?)

сколько процессов агента запущено? какой таймаута от агента? какой профиль нагрузки у сервера (случайно не файловый сторадж?)

да файловый, значения по дефолту

avg load посмотрите на нем ? и тюньте агента (увеличивайте таймаут на сервере и агенте, количество агентов увеличивайте)

Привет, есть проблемка не могу никак решить.. Часто один сервер становится не доступным по мнению zabbix-agent "Zabbix agent on is unreachable for 5 minutes " При этом по RDP можно на нем работать без проблем и ping проходит. Что может повлиять на работу zabbix-agent ?

В логах сервера смотри, а не агента