бредятина какая-то

а хистори полностью что показывает?

Down (0) есть и совпадает с отсутствием связи с агентом?

сервер выключался

ааа

в документации по nodata

Supported value types: any Returns: 1 - if no data received during the defined period of time 0 - otherwise Note that this function will display an error if, within the period of the 1st parameter: - there's no data and Zabbix server was restarted - there's no data and maintenance was completed - there's no data and the item was added or re-enabled

10m

коллеги, прошу не ругаться, только подключился к вашей группе, бо не могу найти ответ на свой вопрос. искал и в этой группе, и в документации Zabbix'а - ну никак. поэтому, прошу хотя бы ткнуть в правильную ссылку, дальше я сам. итак, вопрос архитектурный. нужно мониторить сервера/приложения/... в удаленных сетях, куда нет вообще никакого доступа / и оттуда нет никакого интернета. единственный способ коммуникации - те далекие сервера могут слать письма. т.е. если там поставить Zabbix Agent, то он может слать письма. в них - либо в body, либо в attach (неважно) могут быть оперативные данные мониторинга. значит вопрос состоит в том, может ли такая схема работать? агент заворачивает свои данные в письма, а Zabbix Server эти письма принимает, парсит их и закачивает в базу/обрабатывает/далее по списку. я могу даже "облегчить" задачу Zabbix Server'у - если он вдруг "из коробки" не умеет забирать письма по POP3/IMAP/EWS - я могу свой промежуточный робот накидать, который будет сам забирать письма, доставать из них "полезную нагрузку" и каким-либо удобным методом отдавать данные дальше (вроде сохранять в папочку на диске в CSV/TXT файлы или любом другом удобном виде), чтобы Zabbix Server мог работать с полученными данными как с источником данных. надеюсь, понятно обрисовал задачу. т.е. если перефразировать, в двух словах - может ли Zabbix Agent слать свои данных не по TCP/IP (10050), а в виде писем (протокол SMTP), а Zabbix Server - такие письма принимать и обрабатывать. спасибо заранее и прошу прощения еще раз, если вдруг вопрос сто раз уже обсуждался.

коллеги, прошу не ругаться, только подключился к вашей группе, бо не могу найти ответ на свой вопрос. искал и в этой группе, и в документации Zabbix'а - ну никак. поэтому, прошу хотя бы ткнуть в правильную ссылку, дальше я сам. итак, вопрос архитектурный. нужно мониторить сервера/приложения/... в удаленных сетях, куда нет вообще никакого доступа / и оттуда нет никакого интернета. единственный способ коммуникации - те далекие сервера могут слать письма. т.е. если там поставить Zabbix Agent, то он может слать письма. в них - либо в body, либо в attach (неважно) могут быть оперативные данные мониторинга. значит вопрос состоит в том, может ли такая схема работать? агент заворачивает свои данные в письма, а Zabbix Server эти письма принимает, парсит их и закачивает в базу/обрабатывает/далее по списку. я могу даже "облегчить" задачу Zabbix Server'у - если он вдруг "из коробки" не умеет забирать письма по POP3/IMAP/EWS - я могу свой промежуточный робот накидать, который будет сам забирать письма, доставать из них "полезную нагрузку" и каким-либо удобным методом отдавать данные дальше (вроде сохранять в папочку на диске в CSV/TXT файлы или любом другом удобном виде), чтобы Zabbix Server мог работать с полученными данными как с источником данных. надеюсь, понятно обрисовал задачу. т.е. если перефразировать, в двух словах - может ли Zabbix Agent слать свои данных не по TCP/IP (10050), а в виде писем (протокол SMTP), а Zabbix Server - такие письма принимать и обрабатывать. спасибо заранее и прошу прощения еще раз, если вдруг вопрос сто раз уже обсуждался.

Едрить вы замутили

если правильнее такой вопрос задать на сайте/форуме Zabbix'а - также прошу указать это, больше не буду тут приставать

Offline monitoring zabbix

Какой то

если правильнее такой вопрос задать на сайте/форуме Zabbix'а - также прошу указать это, больше не буду тут приставать

Задавался такой вопрос там. Топикстартер сгинул в неизвестности.

Задавался такой вопрос там. Топикстартер сгинул в неизвестности.

https://www.zabbix.com/forum/showthread.php?t=21717

Этот?

Значит и не один раз задавался

Так, с прокси никогда не работал, но может ли он хранить историю?

Вобщем, ни агент, ни сервер по SMTP не умеют балакать меж собой.

Я предлагаю такой костыль, ставим там zabbix и просто раз в период забираем базу по почте

Чистим и снова в бой

Потом на ориг. заббиксе просто в таблицу вносим

Вобщем, ни агент, ни сервер по SMTP не умеют балакать меж собой.

Сейчас бы значения по smtp собирать

Сук, zabbix-mail-agent

Общается только через почту)

коллеги, прошу не ругаться, только подключился к вашей группе, бо не могу найти ответ на свой вопрос. искал и в этой группе, и в документации Zabbix'а - ну никак. поэтому, прошу хотя бы ткнуть в правильную ссылку, дальше я сам. итак, вопрос архитектурный. нужно мониторить сервера/приложения/... в удаленных сетях, куда нет вообще никакого доступа / и оттуда нет никакого интернета. единственный способ коммуникации - те далекие сервера могут слать письма. т.е. если там поставить Zabbix Agent, то он может слать письма. в них - либо в body, либо в attach (неважно) могут быть оперативные данные мониторинга. значит вопрос состоит в том, может ли такая схема работать? агент заворачивает свои данные в письма, а Zabbix Server эти письма принимает, парсит их и закачивает в базу/обрабатывает/далее по списку. я могу даже "облегчить" задачу Zabbix Server'у - если он вдруг "из коробки" не умеет забирать письма по POP3/IMAP/EWS - я могу свой промежуточный робот накидать, который будет сам забирать письма, доставать из них "полезную нагрузку" и каким-либо удобным методом отдавать данные дальше (вроде сохранять в папочку на диске в CSV/TXT файлы или любом другом удобном виде), чтобы Zabbix Server мог работать с полученными данными как с источником данных. надеюсь, понятно обрисовал задачу. т.е. если перефразировать, в двух словах - может ли Zabbix Agent слать свои данных не по TCP/IP (10050), а в виде писем (протокол SMTP), а Zabbix Server - такие письма принимать и обрабатывать. спасибо заранее и прошу прощения еще раз, если вдруг вопрос сто раз уже обсуждался.

А зачем вам заббикс? Воспользуйтесь monit

А зачем вам заббикс? Воспользуйтесь monit

Но, это же конференция zabbix...

Разве мы не должны его 'продавать'

Едрить вы замутили

а что? обычный case мониторинга конечно - это мониторить свою инфраструктуру / сервера / маршрутизаторы и тд. - это понятно. но есть и другой case (мой случай) - вы вендор (или просто outsource-компания, которая обслуживает своих клиентов). и в мире enterprise это абсолютная норма - что "там" у них, у клиента, все закрыто/перекрыто, достучаться из внешнего мира невозможно. единственный способ коммуникации, который клиент открывает для серверов - они могут слать письма, через корпоративный SMTP сервер, со всеми мыслимыми и немыслимыми spam-проверками, с ограничениями по количеству писем, отправляемых. но в итоге - как-то все равно письма можно высылать

а что? обычный case мониторинга конечно - это мониторить свою инфраструктуру / сервера / маршрутизаторы и тд. - это понятно. но есть и другой case (мой случай) - вы вендор (или просто outsource-компания, которая обслуживает своих клиентов). и в мире enterprise это абсолютная норма - что "там" у них, у клиента, все закрыто/перекрыто, достучаться из внешнего мира невозможно. единственный способ коммуникации, который клиент открывает для серверов - они могут слать письма, через корпоративный SMTP сервер, со всеми мыслимыми и немыслимыми spam-проверками, с ограничениями по количеству писем, отправляемых. но в итоге - как-то все равно письма можно высылать

Да я понял что вы человек подневольный

а что? обычный case мониторинга конечно - это мониторить свою инфраструктуру / сервера / маршрутизаторы и тд. - это понятно. но есть и другой case (мой случай) - вы вендор (или просто outsource-компания, которая обслуживает своих клиентов). и в мире enterprise это абсолютная норма - что "там" у них, у клиента, все закрыто/перекрыто, достучаться из внешнего мира невозможно. единственный способ коммуникации, который клиент открывает для серверов - они могут слать письма, через корпоративный SMTP сервер, со всеми мыслимыми и немыслимыми spam-проверками, с ограничениями по количеству писем, отправляемых. но в итоге - как-то все равно письма можно высылать

Сложно вам придется. Будете писать свой layer

а что? обычный case мониторинга конечно - это мониторить свою инфраструктуру / сервера / маршрутизаторы и тд. - это понятно. но есть и другой case (мой случай) - вы вендор (или просто outsource-компания, которая обслуживает своих клиентов). и в мире enterprise это абсолютная норма - что "там" у них, у клиента, все закрыто/перекрыто, достучаться из внешнего мира невозможно. единственный способ коммуникации, который клиент открывает для серверов - они могут слать письма, через корпоративный SMTP сервер, со всеми мыслимыми и немыслимыми spam-проверками, с ограничениями по количеству писем, отправляемых. но в итоге - как-то все равно письма можно высылать

вам не нужен заббикс

вам нужен репортинг

Может им статистика нужна

входит в репортинг, да

самое смешное что все меньше энтерпрайзов держат локально смтп

кароче кейс так себе как на 2018 год

И еще нужна секретарша, которая с репортинга в заббикс набивать руками будет. Все при деле.

не ну алертовать заббикс может из коробки ж по мейлу

тут не технический вопрос интересен, а сам кейс

Хотя нет, зачем в заббикс. Пусть по запросам анализирует отчеты и выдает справки.

КНДР какой-то кароче

На форуме был вариант круче - заббикс в сети ИСПДН.

если технически рассуждать то достаточно просто при соблюдении форматов писем и шаблонов отправлять на поту куда-то и там разбирать письма парсерами

в общем такое как по мне

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

Была задача, сказали что разрешат нам коннект только к одному порту, к одному хосту, но что мы будем делать им не интересно

1 порта достаточно для всего (ssh)

В итоге поставили openvpn :D

В итоге поставили openvpn :D

ну или так, да

в общем по опыту такое добавляется в контракт и если что падает то вендор сам звонит и говорит что у Хьюстона проблемы

ну или так, да

Но это ОТВЕРСТИЕ в системе безопасности их не волновало

заббикс-агент хорошо может работать из-за ната. а еще есть заббикс-сендер, которому все равно нат или не нат

вам нужен репортинг

ну это у нас есть и так, и много лет уже. я тут призадумался, как бы выйти на следующий уровень так сказать. сейчас мы получаем по почте от клиентов своими тулзами готовые XLSы с отчётами и по дискам, и по утилизации ресурсов и кучу чисто наших метрик из приложений. дальше я мыслю в двух направлениях: если слать не XLS, а CSV - чтобы можно было парсить на нашей стороне и строить графики. а второе - чтобы данные слал не наш костыль, а Zabbix Agent

ну это у нас есть и так, и много лет уже. я тут призадумался, как бы выйти на следующий уровень так сказать. сейчас мы получаем по почте от клиентов своими тулзами готовые XLSы с отчётами и по дискам, и по утилизации ресурсов и кучу чисто наших метрик из приложений. дальше я мыслю в двух направлениях: если слать не XLS, а CSV - чтобы можно было парсить на нашей стороне и строить графики. а второе - чтобы данные слал не наш костыль, а Zabbix Agent

XLS или CSV - не важно

важно понять какое время реакции вас устраивает

SLA ж по сути

а там хоть флоппинет

Вам нужно слать файл для zabbix-sender и потом вгружать его на стороне сервера.

Вам нужно слать файл для zabbix-sender и потом вгружать его на стороне сервера.

ну это называется а давайте прикрутим сюда заббикс

заббикс - система мониторинга

Это называется - ответ на вопрос. Человек спросил - как, я ответил.

использоать его в качестве транспорта файлов смысла нет. есть более правильные способы передачи информации в вие файла

Дискутировать о необходимости такого способа нужно не со мной

Так, с прокси никогда не работал, но может ли он хранить историю?

Прокси хранит инфу в пределах временнОго буфера (например 1 час). В конфиге настройка

ERROR: S client not available

Дискутировать о необходимости такого способа нужно не со мной

я дискутирую с автором варианта решения

Прокси хранит инфу в пределах временнОго буфера (например 1 час). В конфиге настройка

Можно инфу с буфера вытянуть?

Во внешнюю систему? Да, она в бд прокси хранится

Можно инфу с буфера вытянуть?

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

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

А там вообще связи нет

а почта?

;)

А как тогда данным попадать в систему? И как прокси обращаться к серверу чтобы получить список метрик? (Или наоборот)

Нужно вытаскивать данные, сжимать, отправлять по smtp, принимать, вставлять в буфер настоящего прокси, добавлять в заббикс

А как тогда данным попадать в систему? И как прокси обращаться к серверу чтобы получить список метрик? (Или наоборот)

Ну как-то передать один раз

На кой там вообще прокси тогда?

Ну как-то передать один раз

Один раз в сутки? Ну копи сбор метрик а сутки, потом бд прокси выливаешь вовне

Нужно вытаскивать данные, сжимать, отправлять по smtp, принимать, вставлять в буфер настоящего прокси, добавлять в заббикс

простите, но нет

ну это у нас есть и так, и много лет уже. я тут призадумался, как бы выйти на следующий уровень так сказать. сейчас мы получаем по почте от клиентов своими тулзами готовые XLSы с отчётами и по дискам, и по утилизации ресурсов и кучу чисто наших метрик из приложений. дальше я мыслю в двух направлениях: если слать не XLS, а CSV - чтобы можно было парсить на нашей стороне и строить графики. а второе - чтобы данные слал не наш костыль, а Zabbix Agent

Какие объемы там? Одна метрика, восемь, ... ? NVPS какой, словом?

Один раз в сутки? Ну копи сбор метрик а сутки, потом бд прокси выливаешь вовне

Ну вот я так и предлагаю, но с прокси не работал от слова вообще, поэтому пишу с дивана

Ну вот я так и предлагаю, но с прокси не работал от слова вообще, поэтому пишу с дивана

Будет работать, если все правильно сделать, имхо

в общем одни костыли меняем на другие, более современные

Тут видится такое решение: в закрытой системе ставится tcp-server, который ловит от активного агента все входящие данные и сваливает их в свой буфер. Периодически шлет по известном адресу. С известного адреса их забирает другой демон и, притворяясь zabbix_sender, тупо вливает их в сервер. В обратную сторону что-то подобное изобразить.

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

никакого канала связи нет кроме смтп - из постановки

Будет работать, если все правильно сделать, имхо

@shane54

хотите заббикс - парсинг метрик и их импорт в мониторинг

хотите агентов на серверах? ставьте локальный заббикс-сервер или требуйте канал связи для мониторинга, в том числе проактивного

хотите агентов на серверах? ставьте локальный заббикс-сервер или требуйте канал связи для мониторинга, в том числе проактивного

Можно и без канала

и не надо идти на поводу в 2018 году про "нет канала". нет канала - нет мониторинга как по мне

Можно и без канала

можно агент и на лупбеке запустить и файрволлом закрыть

Базу опустошать раз в сутки, а дамп отправлять по почте

ну повоюете с айди и с ключами и с уникальностью записей

с дивана все просто, да

Щас бы в воскресенье, в одиннадцать часов обсуждать zabbix

с дивана все просто, да

Конечно, пока не встал

обсуждать когда удобно можно