мониторинг логов

[Sour]

После обновления с 1.8 на 2.0 не могу никак настроить мониторинг логов linux. Перенес шаблоны с 1.8 и сюрприз: ZBX_NOTSUPPORTED.

Вот тестовая ситуация:
Агент и Сервер на одной машине.
Cоздаю файл /tmp/2.log от пользователя zabbix. Пишу в него несколько строчек.
Добавляю итем в zabbix: Zabbix агент (активный), ключ log[/tmp/2.log], Тип журнал - ZBX_NOTSUPPORTED
Другие активные проверки работают.
Права на файл -rw-rw-r-- 1 zabbix zabbix , захожу в систему под юзером zabbix - свободно читаю этот файл.

В конфигах значения SourceIP= и ServerActive= на агенте идентичны с ip интерфейса агента в базе сервера.

Уверен, что не замечаю какую-то мелочь, но все, что приходит на ум, перепроверил. Где может быть загвоздка?

[zalex_ua]

Вы ничего не упомянули о парамере Hostname, он совпадает ?
http://www.zabbix.com/documentation/.../zabbix_agentd

Включайте агента в режиме DebugLevel=4 и изучайте что происходит.

[Sour]

да, hostname совпадает, иначе бы не работали другие итемы. по Вашему совету поковырялся в логах, вот что происходит:

Добавляю пару строчек в лог.
Убираю статус Не поддерживается у итема.
zabbix_agentd.log:

6803:20120710:104636.732 refresh_active_checks('192.168.10.240',10051)
6803:20120710:104636.734 Got [{
"response":"success",
"data":[
{
"key":"log[\/tmp\/2.log]",
"delay":30,
"lastlogsize":161,
"mtime":0}]}]
6803:20120710:104636.734 In add_check() key:'log[/tmp/2.log]' refresh:30 lastlogsize:161 mtime:0
6803:20120710:104636.735 In process_log() filename:'/tmp/2.log' lastlogsize:161
6803:20120710:104636.735 In process_value() key:'zbx-Main:log[/tmp/2.log]' value:'1sdfsdfsdfsdfsdf'
6803:20120710:104706.748 In process_log() filename:'/tmp/2.log' lastlogsize:178
6803:20120710:104736.760 In process_log() filename:'/tmp/2.log' lastlogsize:178
6803:20120710:104806.772 In process_log() filename:'/tmp/2.log' lastlogsize:178
6803:20120710:104836.783 refresh_active_checks('192.168.10.240',10051)
6803:20120710:104836.784 Got [{
"response":"success",
"data":[
{
"key":"log[\/tmp\/2.log]",
"delay":30,
"lastlogsize":178,
"mtime":0}]}]
6803:20120710:104836.784 In add_check() key:'log[/tmp/2.log]' refresh:30 lastlogsize:178 mtime:0
6803:20120710:104836.785 In process_log() filename:'/tmp/2.log' lastlogsize:178
6803:20120710:104906.015 In process_log() filename:'/tmp/2.log' lastlogsize:178
6803:20120710:104936.027 In process_log() filename:'/tmp/2.log' lastlogsize:178
6803:20120710:105006.038 In process_log() filename:'/tmp/2.log' lastlogsize:178

в это время на сервере zabbix_server.log

7401:20120710:104643.317 item [zbx-Main:log[/tmp/2.log]] became not supported: ZBX_NOTSUPPORTED
7401:20120710:104643.325 item [zbx-Main:log[/tmp/2.log]] became supported
7399:20120710:104843.421 item [zbx-Main:log[/tmp/2.log]] became not supported: ZBX_NOTSUPPORTED

Получается, из лога считываются данные, но затем, если в лог не поступает новых данных, в течение пары минут итем переходит в "Не поддерживается".

[zalex_ua]

Как насчет двух (или более) хостов в сети с одинаковым hostname ?

[Sour]

нет, к сожалению

mysql> select hostid from hosts where host="zbx-main";
+-----------------+
| hostid |
+-----------------+
| 100100000010084 |
+-----------------+
1 row in set

[zalex_ua]

Как насчет двух (или более) хостов в сети с одинаковым hostname ?

нет, к сожалению

Я же говорю - В СЕТИ, а не в базе данных.

[Sour]

действительно, в сети осталась старая нода с тем же именем (забыл выключить, когда переносил мониторинг на 2.0), правда агент на ней был настроен на левый ip.
Премного благодарен! Выключил - проблема исчезла.

Интересен вопрос - почему она мешала, если в конфиге агента был server= ip в фактически недостижимой ему сети, а новый сервер обращается к наблюдаемому хосту по ip?

[zalex_ua]

Интересен вопрос - почему она мешала, если в конфиге агента был server= ip в фактически недостижимой ему сети, а новый сервер обращается к наблюдаемому хосту по ip?

При активных проверках только агент обращается к серверу.
Но и сервер должен знать куда отвечать в переделах tcp сессии, тоесть марщрутизация должна быть.
Скорее всего старый забытый агент (нода по вашему) могла достучаться до сервера.