То есть, если я туда буду пушить такое, то потом можно вытягивать метрики из другой метрики, да? # cat /proc/net/sockstat* sockets: used 6820 TCP: inuse 2058 orphan 11 tw 758 alloc 5757 mem 4303 UDP: inuse 12 mem 5 UDPLITE: inuse 0 RAW: inuse 1 FRAG: inuse 0 memory 0 TCP6: inuse 3522 UDP6: inuse 9 UDPLITE6: inuse 0 RAW6: inuse 0 FRAG6: inuse 0 memory 0

Препроцессинг умеет и jsonpath разбирать

в моём случае, это удобнее, чем разгребать строку TCP и её orphan 11 tw 758

спасибо

Препроцессинг умеет и jsonpath разбирать

только вначале нужно чтобы этот json кто-то сделал cat делает только текст

в моём случае, это удобнее, чем разгребать строку TCP и её orphan 11 tw 758

что удобнее? jsonpath использовать?

да

только вначале нужно чтобы этот json кто-то сделал cat делает только текст

sed-всемогущий делает json из файла очень шустро ;)

а как вы json собираетесь делать из cat /proc...

например, так: sed -r 's/^/"/;s/:/":/;s/$/"}/;s/ (orphan|tw|alloc|mem|memory) /", "\1": "/g;s/(inuse|used) /{ "\1": "/' /proc/net/sockstat* | paste -sd, | sed 's/^/{/;s/$/}/'

на вкус и цвет фломастеры разные

(можно и без пайпа, но я не люблю так заморачиваться)

я бы regexp на стороне препроцессинга использовал

и никаких json

https://habrahabr.ru/company/zabbix/blog/337856/ часть 2 почитайте

я бы regexp на стороне препроцессинга использовал

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

ваш случай 2 раза придется же разбирать: 1- на стороне отправки, 2 - на стороне приема мое предложение 1 раз на стороне приема

но повторюсь про фломастеры

в любом случае, я буду обе практики использовать (каждую для своего) спасибо

например, так: sed -r 's/^/"/;s/:/":/;s/$/"}/;s/ (orphan|tw|alloc|mem|memory) /", "\1": "/g;s/(inuse|used) /{ "\1": "/' /proc/net/sockstat* | paste -sd, | sed 's/^/{/;s/$/}/'

Мне кажется так можно сотону вызвать. )) Шутка. На самом деле я просто завидую.

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

иначе будешь ловить в 2 местах проблемы

но каждый как хочет делает

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

А в чем проблема? Можно с прокси чекать доступность сервера Zabbix и вешать на этот триггер зависимости.

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

Ну, можно чекать канал с сервера zabbix.

как ни крути получится задница - ну нет ззависимостей триггеров от топологии

только ручная возня

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

киллер фича нагиоса парент/чайлд кароче

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

кстати да - вариант!

кстати да - вариант!

мне не нравится

все равно костыль

просто звучит круто - апи, разработка etc

ничто не совершенно в этом мире

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

в 4 вроде должно быть

терплю

а еще больше недоумеваю как пришедший из нагиоса в свое время )

по сути что надо

одна галка и одно поле парента

галка включит зависимость от топологии

парент построит топологию

все

дальше вариации

и по топологии автоматом карту строить (нагиос стайл)

Пришедшим из заббикса всегда этого не хватает. Ещё фоап детекшена временами.

нагиоса

Угу

ну да. я считаю что взять классную фичу из другого продукта - это показатель понимания чего хотят пользователи (продукта)

но ждем ждем 4

Я не видел как оно в нагиос сделано и что-то не укладывается, что не так с зависимыми элементами данных.

https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/3/en/dependencies.html

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

просто проникнуться надо

хочешь хосты хочешь сервисы

Чат, привет. Питерские - все заметили массивный флуд с DATA-IX или только мне так повезло?

Утро. Коллеги, направьте в нужную сторону... заббикс стоит в локалке центрального офиса. Мониторим в том числе и филиалы, а там ряд различных железок. Вопрос по зависимостям: как правильно указать зависимость всех от шлюза в интернет? Делать отдельные шаблоны для железок в центральном офисе и для такого же типа железок в филиале?

Можно использовать вместо nodata (наверно и нужно) что то на подобее {INFO-SNMPv2:zabbix[host,snmp,available].last()}=0 , это пример для SNMP во 2 параметре ключа вставлятся тип подключения

вот от сюда взято

https://i.imgur.com/70vDpc6.png

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

но надо понимать что при недоступности цода или удаленной площадки будет горет тогда только 1 триггер

на практике , не все понимают что если горит только 1 триггер с надписью Ахтунг алерт все пропало цод недоступен =) то все оборудование в нем недоступно и когда вываливается 50 триггеров они реагируют живее

надеюсь это аблеев удалять не будет=)

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

тоесть хост недоступен != хосте недоступен для мониторинга в данном случае

тоесть хост недоступен != хосте недоступен для мониторинга в данном случае

здесь закралась логическая ошибка

ERROR: S client not available

=) в каком месте?

на практике , не все понимают что если горит только 1 триггер с надписью Ахтунг алерт все пропало цод недоступен =) то все оборудование в нем недоступно и когда вываливается 50 триггеров они реагируют живее

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

=) в каком месте?

я процитировал

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

если рассуждать правильно и здраво то эт одно и то же

если нет доверия системе мониторинга - то она не нужна

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

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

Чат, привет. Питерские - все заметили массивный флуд с DATA-IX или только мне так повезло?

Заметили, и не только Питерские

или пример , с заббикса перестает пинговаться хост,а из впна админа он доступен =) и о5 ругается на мониторинг

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

инженер должен понять почему сработал мониторинг и разобраться в проблеме

если инженер говорит что мониторинг лажа - тут нет смысла дальше вести беседу

=) и это правильно , но не вслучае больших энтрепрайзов

или пример , с заббикса перестает пинговаться хост,а из впна админа он доступен =) и о5 ругается на мониторинг

значит что-то не так или с роутингом или с файрволлами или с впном админа или с заббикс-сервером

=) и это правильно , но не вслучае больших энтрепрайзов

какая разница - большая команда или 1 человек. или есть доверие к мониторингу или нет

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

если технари собачатся между собой - то это проблема

и никакие мониторинги не помогут

=) это тоже спорное заявление

зависищее от того что вы имеете не помогут=) кому то помогут,а кому то нет ,я имеюю ввиду этих самых технорей

@UnixGuru привет, ты не знаешь почему zabbix queue начинает расти?

вместе с этим и начинаются пропуски

количество поллеров уже 20 поставил, ситуацию особо не меняет

после рестарта прокси работает некоторое время нормально, потом опять скатывается...

@UnixGuru привет, ты не знаешь почему zabbix queue начинает расти?

дык продебаж, посмотри где скапливаются очереди, какие метрики и тд и тп

@UnixGuru привет, ты не знаешь почему zabbix queue начинает расти?

посмотреть какие метрики задерживаются в Адмиистрирование-Очередь там переключать выпадашку увидите по каким хостам проблемы с получением метрик Фактически это не очередь на входе с уже полученными значениями метрик, это очередь из неполученных метрик

Можно использовать вместо nodata (наверно и нужно) что то на подобее {INFO-SNMPv2:zabbix[host,snmp,available].last()}=0 , это пример для SNMP во 2 параметре ключа вставлятся тип подключения

Бррр. Не совсем понял логику. В изначальном вопросе - есть железка в центре, и есть в филиале. Филиальская должна зависеть от канала в центр, центральная - нет. Для железок придётся делать разные темплейты, в одном указывать зависимость от канала в центр и вешать на железку филиала. Как тут nodata поможет, не пойму..

а можно очистить эту очередь?

Бррр. Не совсем понял логику. В изначальном вопросе - есть железка в центре, и есть в филиале. Филиальская должна зависеть от канала в центр, центральная - нет. Для железок придётся делать разные темплейты, в одном указывать зависимость от канала в центр и вешать на железку филиала. Как тут nodata поможет, не пойму..

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

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

а можно очистить эту очередь?

выкл/вкл метрику или хост повторюсь, это не очередь полученных значений