DM
ну моя мысль в том, что есть некий другой агент (не важно, на этой тачке или на другой) с аналогичным конфигом, но без твоих юзерпараметров, который пытается слать данные на этот хост.
на самом деле самое логичное объяснение, но не подходит
Size: a a a
2020 January 15
s
ну моя мысль в том, что есть некий другой агент (не важно, на этой тачке или на другой) с аналогичным конфигом, но без твоих юзерпараметров, который пытается слать данные на этот хост.
С тем же айпи?
TU
С тем же айпи?
ну в порядке бреда: сделай текстовый айтем с типом активный агент, который читает конфиг агента)
TU
С тем же айпи?
а пофиг на ип. только конфиг (точнее, хостнейм в нем) важен. активный агент же.
TU
мож кто-то именно сегодня разворачивал сервак и скопировал конфиг с этого, забыв поменять все, что нужно
s
Мне что-то кажется это какая-то дичь. Любой левый демон на рандомной тачке, да даже не демон, а скрипт мб вообще, имея адрес заббикс-сервера, и хостнейм жертвы может просто засылать данные в заббикс? Сорс айпи не чекается?
TU
Мне что-то кажется это какая-то дичь. Любой левый демон на рандомной тачке, да даже не демон, а скрипт мб вообще, имея адрес заббикс-сервера, и хостнейм жертвы может просто засылать данные в заббикс? Сорс айпи не чекается?
проверить надо, но, вроде, не чекается.
оно ж аналогично заббикс сендеру работает.
оно ж аналогично заббикс сендеру работает.
DM
мож кто-то именно сегодня разворачивал сервак и скопировал конфиг с этого, забыв поменять все, что нужно
Кроме меня некому
s
проверить надо, но, вроде, не чекается.
оно ж аналогично заббикс сендеру работает.
оно ж аналогично заббикс сендеру работает.
Вот не думаю, что пропустит. Для чего тогда сделаны галки allow trapper с отдельным acl даже.
DM
А чем оличается активный агент от обычного? А то у меня как раз только итемы с активным агентом так себя ведут
TU
А чем оличается активный агент от обычного? А то у меня как раз только итемы с активным агентом так себя ведут
к обычному сервер/прокси сами обращаются, говорят, че проверить и получают результат.
активный забирает с сервера/прокси список проверок, а потом сам чекает и высылает результаты.
активный забирает с сервера/прокси список проверок, а потом сам чекает и высылает результаты.
DM
к обычному сервер/прокси сами обращаются, говорят, че проверить и получают результат.
активный забирает с сервера/прокси список проверок, а потом сам чекает и высылает результаты.
активный забирает с сервера/прокси список проверок, а потом сам чекает и высылает результаты.
Спасибо, тогда вопрос. Это вкусовщина получается? Или есть практическая разница какая то, что использовать?
TU
Спасибо, тогда вопрос. Это вкусовщина получается? Или есть практическая разница какая то, что использовать?
на сколько помню (а я оч давно задавался этим вопросом), активный приоритетнее. меньше нагрузка на сеть и всякое такое.
TU
но меня вредно слушать, я часто ошибаюсь :D
DM
но меня вредно слушать, я часто ошибаюсь :D
Ты же - guru, не придумывай
TU
Ты же - guru, не придумывай
все забывается со временем)
2020 January 16
OK
Если это чем-то поможет, могу подсказать, почему zabbix_get возвращает результат. Он выполняет пассивную, а не активную проверку с тем же самым юзерпараметром. А что за беда случилась с активными проверками - вопрос. Кстати, busy trapper processes - как обычно?
s
Спасибо, тогда вопрос. Это вкусовщина получается? Или есть практическая разница какая то, что использовать?
При активных проверках сравнительно меньшая нагрузка на сеть сервера, плюс возможность мониторить хосты, находящиеся за Nat. Т. К. В этом случае соединение инициализирует наблюдаемый хост, и заббикс серверу нужно знать только айпи. И вроде как, при не соответствии, @lint_deezy, таки игнорирует такие источники
s
Или нет?
TU
Если это чем-то поможет, могу подсказать, почему zabbix_get возвращает результат. Он выполняет пассивную, а не активную проверку с тем же самым юзерпараметром. А что за беда случилась с активными проверками - вопрос. Кстати, busy trapper processes - как обычно?
ну usupported item key однозначно говорит о том, что ключа нет в конфиге.
мое предположение выше именно на этом стоится.
маловероятно, что агент "теряет" конфиг, а потом снова откуда-то его берет, ибо он в памяти с момента запуска агента.
мое предположение выше именно на этом стоится.
маловероятно, что агент "теряет" конфиг, а потом снова откуда-то его берет, ибо он в памяти с момента запуска агента.