в оперативной памяти?

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

а последнее значение - это не хистори?

Откуда вообще эта привычка придумывать функционал, а потом удивляться, почему не работает так, как придумалось?

Откуда такое?

сам себе придумал

Откуда вообще эта привычка придумывать функционал, а потом удивляться, почему не работает так, как придумалось?

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

я часто. но прочтения документации или нахождения ошибки у себя ну или бага

главное понять баг это или фича

я часто. но прочтения документации или нахождения ошибки у себя ну или бага

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

не, чаще баги

0 часто означает без ограничения

Разве не всегда так?))

Так ведь нужно понимать контекст, в котором данное значение может интерпретироваться. Без ограничения на хранение? Логичнее, кажется, "не хранить вовсе".

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

Привет! Может быть, у кого-нибудь уже получилось... Нужно собирать внутреннюю статистику (ключи типа zabbix[]) с одного сервера Zabbix на другом сервере Zabbix. Просто настроив агента на второй сервер, этого не добиться. Вот обсуждение того, что требуется: https://www.zabbix.com/forum/showthread.php?t=59144

Привет! Может быть, у кого-нибудь уже получилось... Нужно собирать внутреннюю статистику (ключи типа zabbix[]) с одного сервера Zabbix на другом сервере Zabbix. Просто настроив агента на второй сервер, этого не добиться. Вот обсуждение того, что требуется: https://www.zabbix.com/forum/showthread.php?t=59144

Почему не добиться, а куда агент вообще отдает данные?

Zabbix internal checks не относятся к агенту и им не собираются.

к какому бы агенту не была прикреплена такая метрика, она будет собирать статистику с сервера(прокси), на котором этот агент мониторится.

Пусть пишет в базу первый, читай вторым из базы первого

Пусть пишет в базу первый, читай вторым из базы первого

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

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

Это если проблемы с перфомансом базы, ты ж не уточнил

Это если проблемы с перфомансом базы, ты ж не уточнил

Можно привести массу причин, в результате которых информация не дойдет до базы. Надо как непосредственно с прокси эти метрики вытянуть попробовать.

Или с сервера

какие метрики?

Допустим, zabbix[hosts]

Посмотрел код. Poller, когда встречает такой ключ, даже не обращается к агенту, он сразу запускает процедуту get_value_internal, внутри которой дергает DCget_host_count()

не ради троллинга, зачем этот параметр?

ну зачем его мониторить?

конкретно этот параметр я привел для примера, потому что он самый простой и очевидный

Но вообще, по нему можно посмотреть статистику по количеству хостов в zabbix

не ну можно все заменить костыликом и делать выборки из БД

Утилизацию кэшей или пуллеров ты никак из базы не достанешь

Посмотрел код. Poller, когда встречает такой ключ, даже не обращается к агенту, он сразу запускает процедуту get_value_internal, внутри которой дергает DCget_host_count()

зачем было смотреть код, когда понятно, что эта метрика типа "internal check"?

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

Утилизацию кэшей или пуллеров ты никак из базы не достанешь

почему? история в базе.

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

это про подход "посмотреть в коде"? так ведь это в доке описано.

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

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

насколько я понял, человек прояснил в коде, что для внутренней проверки поллер не обращается к агенту. вот так новость )

почему? история в базе.

История попадает в базу после того, как админ настроил сбор этих внутренних метрик. Если с сервером мониторинга начинаются проблемы (производительности или взаимодействия с базой), в базе новые значения появляться перестанут.

скорее убедился. не вижу ничего плохого

мониторить появление данных в базе?

скорее убедился. не вижу ничего плохого

ничего плохого, но проверять очевидное порой странно

мониторить появление данных в базе?

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

Антон, тебе по существу есть что сказать?

Вот всегда так, как только не по гуглишь, сразу там все есть)))

правильнее будет делать вот так: https://www.zabbix.com/documentation/3.2/manual/config/macros/macro_functions - через regsub и тогда не придется ниче править в php файлах. Тоже поначалу недоумевал, что точки были

Антон, тебе по существу есть что сказать?

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

правильнее будет делать вот так: https://www.zabbix.com/documentation/3.2/manual/config/macros/macro_functions - через regsub и тогда не придется ниче править в php файлах. Тоже поначалу недоумевал, что точки были

А мне не нужно обрезать. Мне нужно чтобы целиком показалось

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

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

Но тут вопрос - а как часто ломается прокси и по каким причинам?

по опыту и общению вообще сам заббикс ломается в 2 случаях - кто-то полез или что-то померло из железа

Хорошо, опишу конкретный пример. Приходите вы утром на работу и видите, что весь мониторинг у вас лежит. В базе куча блокировок, на всех проксях скопились очереди. И вот вы хотите посмотреть, а с чего все началось, но на графиках внутреннего мониторинга пусто (может быть, синхеры не справились, может, проблема отсутствия данных в загруженности пуллеров, может кэши переполнились и т.д.), данные не собираются, так как мониторинг лежал все время.

А мне не нужно обрезать. Мне нужно чтобы целиком показалось

А оно и будет целиком и даже больше и показываться будет нормально. Вот на примере я собираю траппером с железок, и когда делал стандартный {ITEM.LASTVALUE} оно естественно все не умещалось. Решил вот таким способом: {{ITEM.VALUE}.regsub("link(\w+) (.*) (Oper.*)", "Interface \2 \1 (\3)")} on {HOSTNAME}

А оно и будет целиком и даже больше и показываться будет нормально. Вот на примере я собираю траппером с железок, и когда делал стандартный {ITEM.LASTVALUE} оно естественно все не умещалось. Решил вот таким способом: {{ITEM.VALUE}.regsub("link(\w+) (.*) (Oper.*)", "Interface \2 \1 (\3)")} on {HOSTNAME}

Спасибо. Попробую. ;)

Спасибо. Попробую. ;)

Не за что

Хорошо, опишу конкретный пример. Приходите вы утром на работу и видите, что весь мониторинг у вас лежит. В базе куча блокировок, на всех проксях скопились очереди. И вот вы хотите посмотреть, а с чего все началось, но на графиках внутреннего мониторинга пусто (может быть, синхеры не справились, может, проблема отсутствия данных в загруженности пуллеров, может кэши переполнились и т.д.), данные не собираются, так как мониторинг лежал все время.

не надо на утро, сразу смотрю в "пейджер". что мешает мониторить каналы к прокси, БД на прокси, нагрузку на прокси-хостах? поделать многоуровневые триггеры (50% 70% 95%)

Хорошо, опишу конкретный пример. Приходите вы утром на работу и видите, что весь мониторинг у вас лежит. В базе куча блокировок, на всех проксях скопились очереди. И вот вы хотите посмотреть, а с чего все началось, но на графиках внутреннего мониторинга пусто (может быть, синхеры не справились, может, проблема отсутствия данных в загруженности пуллеров, может кэши переполнились и т.д.), данные не собираются, так как мониторинг лежал все время.

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

+

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

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

надо упреждать

ERROR: S client not available

Не за что

Работает. И не нужно ковырять файлы. {{ITEM.LASTVALUE}.regsub("(.*)", \1)}

Работает. И не нужно ковырять файлы. {{ITEM.LASTVALUE}.regsub("(.*)", \1)}

Здорово!!! Рад, что смог помочь!

@sperr0w ну надо тогда патчить сервер ?

@sperr0w ну надо тогда патчить сервер ?

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

Я то думал, что это уже было в Симсонах -_-

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

нужен прокси для проксирования элементов данных с прокси ;)

Доброго дня Есть прототип графика и этот прототип создается на каждый прототип элемента данных. Можно ли создать график который будет содержать все прототипы элементов данных?

вот как на этом графике но он создан из последних данны

Доброго дня Есть прототип графика и этот прототип создается на каждый прототип элемента данных. Можно ли создать график который будет содержать все прототипы элементов данных?

https://support.zabbix.com/browse/ZBXNEXT-927

https://support.zabbix.com/browse/ZBXNEXT-927

Спасибо, проголосую

?

Не голосовал

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

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

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

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

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

Кто проверит проверяющего

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

Вопрос касается детальных внутренних проверок лишь

ЖУЖ - журнал учёта журналов

дадада!

Кто проверит проверяющего

проверяющий проверяющего?

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

Проблема больше надуманная

Приветствую товарищи! Я правильно понимаю, чтобы zabbix агент по умолчанию брал свой конфиг отличный от дефолтного, нужно его собрать из исходников с префиксом —sysconfigdir?

Имел в виду отличную директорию

Для запуска как демона? Можно же просто свой инит скрипт сделать с указанием конфига

Проще будет

ключ -c вроде

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

И что говорили? Почему не голосовал?