[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Zabbix: Server <server_name> is unreachable



Павел Марченко <bblrlo@gmail.com> wrote:
> > Вот сейчас смотрю на дашбоард - серверов с проблемой 2. А должно быть - три.
> > ибо один из хостов (gw) за которым находятся хосты host1 & host2 - в дауне,
> > соотвественно host1 и gw - в дауне, про host2 - всё хорошо, за исключением
> > того, что в Hosts->Configuration светится красный квадрат с гордой
> > подсказкой "Get value from agent failed: *** Cannot connect to [[x.x.x.x]:10052]:
> > [4] Interrupted system call". Где алерт-то? И так уже сутки.

> Судя по всему выставлены зависимости тригеров, т.е. если хосты А и Б
> находятся за gw, а gw в дауне, то тригеры на А и Б подниматься не
> будут. Но это если настроено так. Если не настроено, то нужно копать,
Рассказываю. Зависимостей нет. Я еще в здравом уме, чтоб их не делать (да и
нужны они в большей части только для карт).

> айтемы на предмет времени проверки (может там чек раз в сутки, деталей
У host2 был отключен тригер на событие доступности агнета. По каким причиним
- не ясно, но соль не в этом. После его включения (хост недоступен, агент
- тоже) - он так и остался в состоянии UP. Со стороны вебморды - выглядело
красиво: все итемы с этого хоста красные, а этот - зеленый. Интервал опроса
- 5 минут, провисело до утра, состояние не изменилось.

> то не знаю). К слову просто так айтемы не становятся not supported, к
> этому ведет или глобальное изменение конфигурации клиента (ОС
> сменилась), или же неверное изменение конфигурации мониторинга. Во
А у меня - пропадают. на localhost в zabbix_agent есть:
UserParameter=UserP.procmem[*], ps aux |grep $1|grep -v "grep"|awk '{sum+=$$6} END {print sum}'
который после некоторого времени просто переходит в not supported. тихо так
переходит, по партизански. Используется этот итем для монтиоринга
потребляемой zabbix_agetd памяти.

> втором случае виноват не инструмент, а тот кто его в руках держал, ибо
> все изменения обкатывать на тестовой группе нужно.
> Я тоже немало хостов мониторю, но не сталкивался с подобными проблемами.
Руками небось добавлял? Я вот сейчас все прелести Discovery через SNMP
испытываю. Тихий, меееееееедленный ужас. Как оказалось (в 2.0 та-же
ситуация) - утуре дисковер однопоточный. То есть, один хост за один заход.
Они даже event FSM не осилили там написать. Та-же net-snmp успешно умеет
опрашивать сразу десятками хосты, в один момент времени. все остальные
poller'ы - такие-же. 

Пойдем дальше: менджмент сетка для всяких свичей - /19, это 8190 хостов,
на опрос несуществующего хоста тратиться 6-7 секунд времени. Завершиться
процесс часов через 13. Дальше - интересней, по итогам SNMP запроса надо
рассортировать железки по типам и дабвить в разные группы. А тут засада -
оперировать можно только одинм ответом. Тоесть, прийдется писать скрипт,
который будет ходить через json за свежими хостами, и обновлять базу.
Внимание вопрос - где от этого процесса (discovery) хоть какая-то выгода?
Быстрее нарисовать скриптик с nmap+snmpwalk и натрамбовать всё в базу.

> З.Ы. Перешел уже на 2.0.0
Не-не-не, с этим - как с виндой, до первого сервиспака - низзя. Гляжу в
багтрекер и радуюсь, что не побежал апгрейдиться.

PS: на самом деле zabbix хороший пример, что нельзя всё делать на C. Большая
часть задач может быть решена на языках более высокого уровня
(perl/php/python) гораздо эффективней и быстрей. Но - мы имеем то что имеем: 
убогие триггеры, неудобную вебморду, маленькую гибкость. Но - НАХАЛЯВУ!


Reply to: