да :)

в правилах обнаружения

Ну я сейчас не помню где там оно

Но можно и раз в час

Спасибо, я тогда подожду, а почему я ручками не могу тож самое сделать?

Спасибо, я тогда подожду, а почему я ручками не могу тож самое сделать?

Ты знаешь все оиды температурных датчиков наизусть?

Корзины трёх типов есть

G1 g2 g3

Ты знаешь все оиды температурных датчиков наизусть?

понял, жду)

Ребят , заббикс из коробки умеет читать логи ?

умеет

можно его в качестве внешнего сервера логирования использовать ?

умеет

это потом в последних данных просматриать ?

ELK

Уже читаю, спачибо

Graylog

Zabbix несколько для другого предназначен просто и это неправильное применение технологий. Он умеет смотреть в логи и находить там то что интересует и если надо считать или алертовать

Zabbix несколько для другого предназначен просто и это неправильное применение технологий. Он умеет смотреть в логи и находить там то что интересует и если надо считать или алертовать

и я так понимаю он агентом дергает данные )

он активным агентом следит

ну вот )) а мне свитчи мониторить , спасибо за ответ )

посмотри в сторону SNMP Trap

Что-то я в растерянности. Подтолкните, куда посмотреть можно. Две прокси стоят, ни с того, ни с сего, начали триггеры по хостам на них срабатывать. Посмотрел логи, там собственно записи, что подключение на сервер не установлено по таймауту [110] Connection timed out и потом сразу сообщение, что подключение восстановлено. Сервер и прокси 3.4.8, с сетью никаких проблем нет (еще куча активных агентов без проблем цепляются к серверу), в логах на сервере никаких ошибок не проскакивает.

Собственно проблема таки оказалась в сети, у провайдера датацентра в точке обмена траффиком на одной из железок ИНОГДА не пролетают TCP пакеты. Обожаю такие глюки...

Привет всем в этом чатике

Настроил алерт для мониторинга кол-ва процессов PostgreSQL / PgBouncer

PostgreSQL {Template DB PostgreSQL:proc.num[,postgres,sleep,(postgres: |pgsql)].last()}+{Template DB PostgreSQL:proc.num[,postgres,run,(postgres: |pgsql)].last()}+{Template DB PostgreSQL:proc.num[,postgres,disk,(postgres: |pgsql)].last()}<1 PgBouncer {Template DB PostgreSQL - PgBouncer:proc.num[,pgbouncer,sleep,pgbouncer.*-d.*pgbouncer.ini].count(180,1,"ge")}+{Template DB PostgreSQL - PgBouncer:proc.num[,pgbouncer,run,pgbouncer.*-d.*pgbouncer.ini].count(180,1,"ge")}+{Template DB PostgreSQL - PgBouncer:proc.num[,pgbouncer,disk,pgbouncer.*-d.*pgbouncer.ini].count(180,1,"ge")}<1

с PostgreSLQ все ок, а вот PgBouncer ложно алертит (причем может раз в неделю днем триггернуть, а может раз 5 за ночь)

Zabbix 3.4 (CentOS 7), PgBouncer 1.7.2 (RHEL 7)

есессно, вот это читал: https://www.zabbix.com/documentation/3.4/ru/manual/appendix/items/proc_mem_num_notes

с PostgreSLQ все ок, а вот PgBouncer ложно алертит (причем может раз в неделю днем триггернуть, а может раз 5 за ночь)

Не используй proc.num, если не можешь отдебажить. Просто создай айтем с UserParameter или system.run, который будет делать почти то же самое – pgrep -f, тогда сможешь раскопать.

А вообще можно создать действие на триггер, которое сделает ps aux в момент алерта, узнаешь, что в данный момент происходит на сервере и почему твоя формула не работает.

Сделать проверку проверки - воркэранд интересный, но звучит ужасно

Вопрос такой: кто как мониторит запущенные процессы в Zabbix на никсах?

Не используй proc.num, если не можешь отдебажить. Просто создай айтем с UserParameter или system.run, который будет делать почти то же самое – pgrep -f, тогда сможешь раскопать.

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

Вопрос такой: кто как мониторит запущенные процессы в Zabbix на никсах?

ни как не мониторим...зайдете себе вопрос, а оно вообще надо ли?)

Сделать проверку проверки - воркэранд интересный, но звучит ужасно

Чем ужасно? Если для этого придумали методы из коробки

я наивно думал, что для этого есть proc.num

Вопрос такой: кто как мониторит запущенные процессы в Zabbix на никсах?

А мониторить что именно? Я мониторю процессы ntpd, cron, sshd и что-то там ещё с помощью этого же proc.num.

я наивно думал, что для этого есть proc.num

Если ты не можешь сам ответить на вопрос, почему так происходит – значит он тебе не нужен. Никто не полезет на твой сервер проверять, почему proc.num не матчит название процесса.

у нас кстати на парочке хостов имеется proc.num и они успешно работают

у нас кстати на парочке хостов имеется proc.num и они успешно работают

proc.num["nginx"] – такого рода? proc.num[,pgbouncer,run,pgbouncer.*-d.*pgbouncer.ini] - достаточно один раз чихнуть и оно заалертит

proc.num["nginx"] – такого рода? proc.num[,pgbouncer,run,pgbouncer.*-d.*pgbouncer.ini] - достаточно один раз чихнуть и оно заалертит

Поэтому у меня в основном стоит алерт на последние 3 неудачи подряд. Функция count, но скорее всего есть иные более изящные решения.

Поэтому у меня в основном стоит алерт на последние 3 неудачи подряд. Функция count, но скорее всего есть иные более изящные решения.

Обычно такое случается, когда процесс меняет заголовок ?

Поэтому у меня в основном стоит алерт на последние 3 неудачи подряд. Функция count, но скорее всего есть иные более изящные решения.

А в чем разница между 1 и 3 неудачами?

proc.num["nginx"] – такого рода? proc.num[,pgbouncer,run,pgbouncer.*-d.*pgbouncer.ini] - достаточно один раз чихнуть и оно заалертит

proc.num[frmweb,ora10gas]

где ora10gas это имя пользователя

frmweb это имя процесса

помоему вида proc.num[nginx] работать не будет, надо пробовать писать proc.num[nginx,(тут запятая)]

А в чем разница между 1 и 3 неудачами?

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

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

это как обновился просто?

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

лучше логи анализировать все же, это более верный способ

это как обновился просто?

Ссш новый пришёл утром в 6 утра и перезапустился :) Секунду его может не быть. И сотня серверов тебе будет рада об этом сказать :))

у нас ссш сам не обновляется

на время деплоя или апгрейда хосты ставятся в мейнтенанс

лучше логи анализировать все же, это более верный способ

Каждый сам для себя решает. Мне нужно знать, работает ли ссш или нет к примеру. Или инсинк синхронизатор для гугл драйва. Или exim. Или ldap. Продолжайте сами :)

новый ссш утром? Без ведома админа? Вот это поворот..

на время деплоя или апгрейда хосты ставятся в мейнтенанс

Ну вот, ситуации разные, я свою описал.

Каждый сам для себя решает. Мне нужно знать, работает ли ссш или нет к примеру. Или инсинк синхронизатор для гугл драйва. Или exim. Или ldap. Продолжайте сами :)

помоему это работа systemd по современным реалиям

помоему это работа systemd по современным реалиям

по-твоему

Это стало недавно современным :)) Да и какая разница накосячил системды или нет - надо понимать работает ли процесс или нет. Мы как-то вышли за рамки обсуждения и обсуждаем кто лучше - блондинки или брюнетки ;)

рыжие)

по-твоему

я и написал, что по-моему

я и написал что по-твоему

Это стало недавно современным :)) Да и какая разница накосячил системды или нет - надо понимать работает ли процесс или нет. Мы как-то вышли за рамки обсуждения и обсуждаем кто лучше - блондинки или брюнетки ;)

работает процесс само по себе ничего не значит

надо дергать сервис

Ты знаешь все оиды температурных датчиков наизусть?

Спасибо, все появилось,просто супер, теперь еще по циске найти и настроить)

ERROR: S client not available

С systemd и Zabbix тогда не нужен :)

системд не панацея

работает процесс само по себе ничего не значит

Это уже дальнейшие дебри, согласен. Я ещё прослушивание портов проверяю ;)

и прослушивание ничего не значит ;)

все зависит от целей, но мониторить базовые процесс, нах-нах лишнию работу себе делать

надо проверять работает сервис или нет :)

и прослушивание ничего не значит ;)

?

системд не панацея

как и заббикс собственно.

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

процессы лучше мониторить через логи, это куда более верное решение и заббикс для этого, скажем прямо, не подходит

Посмотрите последних мстителей, и поймёте что с камнем реальности вообще НИЧЕГО-НИЧЕГО ничего не значит :))

Посмотрите последних мстителей, и поймёте что с камнем реальности вообще НИЧЕГО-НИЧЕГО ничего не значит :))

посмотри, ага )))

может еще Русалочку посмотреть? ;)

процессы лучше мониторить через логи, это куда более верное решение и заббикс для этого, скажем прямо, не подходит

через встроенный мониторинг в сам процесс

процессы лучше мониторить через логи, это куда более верное решение и заббикс для этого, скажем прямо, не подходит

Как это? Процесс упал и не написал в логи. Системды тоже молчит. Юзеры звонят жалуются, а ты такой "у меня в логах все нормально!"

Как это? Процесс упал и не написал в логи. Системды тоже молчит. Юзеры звонят жалуются, а ты такой "у меня в логах все нормально!"

процесс упал и не написал - плохой процесс

Как это? Процесс упал и не написал в логи. Системды тоже молчит. Юзеры звонят жалуются, а ты такой "у меня в логах все нормально!"

1. долгое время не писал в логи - уже странно 2.systemd знает что процесс жив/мертв и будет его стартовать сам при необходимости

процесс упал и не написал - плохой процесс

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

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

нема никаких мушкетеров. просто опыт

техническую сторону мы не обсудили до конца

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

Прошу прощения, хотел написать "имеет право на жизнь" :))

1. долгое время не писал в логи - уже странно 2.systemd знает что процесс жив/мертв и будет его стартовать сам при необходимости

скажите, как часто вам помогал перезапуск процессов самим системд?

1. долгое время не писал в логи - уже странно 2.systemd знает что процесс жив/мертв и будет его стартовать сам при необходимости

П1 я также реализовал для некоторых процессов, все верно.

и приведите пример

П1 я также реализовал для некоторых процессов, все верно.

по п.1 потенциально (и на практике так и было) когда все хорошо и процесс ничего не пишет в лог то появляются ложные срабатывания

скажите, как часто вам помогал перезапуск процессов самим системд?

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

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

по п.1 потенциально (и на практике так и было) когда все хорошо и процесс ничего не пишет в лог то появляются ложные срабатывания

Я поставил большой интервал, но достаточный ;) из опыта.

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

то есть на самом деле системд ничего не перезапускает?

а все базовые службы успешно отрабатываются через systemd

то есть на самом деле системд ничего не перезапускает?

бывает и проблем с этим нет