Zabbix пользовательские интервалы не работают

Пользовательские интервалы Zabbix

Доброго времени суток.

В Zabbix нужно сделать так, чтобы один элемент данных начал проверяться только с февраля месяца. Можно это сделать как-то пользовательскими интервалами, не привлекая макросы? Пока что не получилось. По умолчанию можно выставить только день месяца, день недели, час, минута и секунда. Можно сделать первый день каждого месяца. А вот первый день конкретного — уже не удается.

Никто не сталкивался с подобным?

активируй данный итем в фервале месяце…

Нужно, чтобы автоматом…

активируй скриптом по крону в феврале)

Так а сам Zabbix подобных штук не позволяет делать?

ну как бы а зачем такой функционал. ты создаешь айтем, он собирает данные, если данных нет, то их нет… в тригере ты можешь указать проверку даты и времени если надо, мол если нет пинга 5 минут и дата позже 2 января 2020 года и время болше 1.15… тогда тригер сработает

может ты просто не стой стороны подходишь? сформулируй кокнертную задачу.

Да именно в том задача и стоит, как я ее сформулировала.

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

уведомления от определенного элемента данных которого не хочется видеть до февраля месяца.

ставишь в триггере date () > «20210201» и все. тригер не сработает раньше этой даты. кроме триггеров в заббиксе больше нет никаких механизмов реагирования.

Источник

[Zabbix] Как мониторить item только в нужное время?

Поскольку официальный форум Zabbix’а — планета Шелезяка, где отвечают по полгода, спрошу здесь:
Мне нужно мониторить итем с 10 до 23:50, после этого времени я хочу, чтобы данные с агента не собирались.
Я вижу, что в Zabbix есть Flexible intervals. Хорошо, но не буду же я на полном серьёзе указывать, что в период с 23:51 до 09:59 мне нужно задержку в секундах, равную. 36480 секунд!
Неужели Zabbix настолько туп, убог и типично по-русски зануден что ему нельзя даже просто указать расписание для item’а?
В итоге у меня получается следующие flexible interval’ы:

Эм. Есть же «период».

Периоды есть, и они используются для указания во flexible interval’е времени, когда проверка итема будет задержана на N секунд. Проблема в том, что эти N секунд нужно высчитывать, а просто указать период, когда будет «работать» итем — нельзя, кажется. Во всяком случае, я такого не нашёл.
Пока что пришлось вставить в скрипт проверки для zabbix-agent’а проверку и на запуска время тоже, потому что работоспособности flexible interval’а я доверять как-то не склонен.

Эм. это и есть, то что тебе нужно.

Сейчас выставил для проверки: 10 sec at 1-5,10:00-23:59
На выходе:
2011.Oct.03 19:26:22 Up (1)
2011.Oct.03 19:26:12 Up (1)

А если выставить при этом в поле интервала что-то вроде 120 секунд? Просто тогда совершенно непонятно, как соотносятся гибкий и «негибкий» интервалы?

Да, и будет ли итем проверяться за пределами flexible interval’а и с какой периодичностью? Может, он будет проверяться в соотв. с просто «Update interval (in sec)»? Во всяком случае, по факту у меня сейчас проверки

. у меня проверки идут, хотя они не попадают в заданный интервал!

В данном случае значения получаем с понедельника по пятницу с 10:00 до 23:59. С интервалом в 10 секунд.

Посмотри в истории с каким периодом у тебя значения приходят. (обзор -> 500 последних значений)

Источник

Zabbix теряет данные — прерывистый график

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

Через snmpget устройство отвечает всегда, т.е. проблема, скорее всего, на стороне мониторинга.

По ICMP данные приходят непрерывно в тот же заббикс, т.е. проблема, скорее всего, в плоскости SNMP. При этом, по другим хостам, добавленным через те же шаблоны, проблем я не вижу — графики непрерывны.

Кто-нибудь сталкивался с таким поведением?

Не помогло. После активации мониторинга (enable), данные с хоста некоторое время накапливаются, но потом перестают. https://habrastorage.org/webt/ok/bd/kk/okbdkkzeiw8uiaiaxuglrsf35s4.png Фиолетовый график это ifHCInOctets (множитель подобран неверно, но это неважно).

Смотреть графики загрузки poller’ов, очереди.

мб нужно snmp trap добавить ?

UPD. Полностью удалил хост из заббикса и создал его снова. Данные пошли. Прошла ночь. Утром обрыв: https://habrastorage.org/webt/ha/hz/kl/hahzklkzwhvwab9eneui-oknj-y.png

Ну, в списке «Queue of items to be updated — Detailes» этого хоста нет. Это значит, что проверка отрабатывает без задержек?

Черт, а действительно Zabbix unreachable poller processes more than 75% busy

О, эта вечное SNMP + Zabbix равно любовь.

1. Посмотри очередь. Бывает, что эта дурилка встает на каком-то одном ключе и перестает опрашивать все остальные ключи на хосте, при свободных поллерах. Отличался этим ключ типа ntptime. 2. Подними до приличных цифр обычные поллеры, unreachable поллеры и snmp-трапперы, если используешь. У меня сейчас стартует 100 unreachable на

20 хостов*30 ключей. 3. Проверь, нет ли пересечений в авторизации у хостов: одинаковые ключи, одинаковые имена, одинаковые SNMP Engine ID. Оно какое-то время работает, потом внезапно помирает при таком мерже. 4. Посмотри, нет ли в логах сообщений про недоступность хостов по SNMP. Если их много, то это косвенно похоже на п.3. Сделай маленький тайм-аут переопроса, помониторь ситуацию.

Я вот смотрю на нее (в первый раз) и не знаю, нормально это или нет, лол. В пиках бывает и по 12к. Но судя по статистике, сейчас с очередью все относительно нормально https://habrastorage.org/webt/7z/bg/ex/7zbgexav1cpbykcpjcuvp1o3dy4.png

У меня сейчас стартует 100 unreachable на

А есть какая-нибудь методика по расчету количества потоков? В зависимости от железа и количества хостов. Или методом тыка?

• StartPollers=40
• StartPollersUnreachable=20
• StartPingers=50
• StartDiscoverers=20
• StartHTTPPollers=20
• StartTimers=20
• StartEscalators=20
• CacheSize=512M
• HistoryCacheSize=128M
• HistoryIndexCacheSize=64M
• TrendCacheSize=32M
• ValueCacheSize=64M
• Timeout=30
• LogSlowQueries=3000

Посмотри, нет ли в логах сообщений про недоступность хостов по SNMP

Просто вагон и маленькая тележка ошибок про несоответствие имени хоста в агенте и на сервере

1927:20180720:101449.560 cannot send list of active checks to «10.46.45.138»: host [VDB2-187700] not found

Я правильно понимаю, что они не особо важны? А про SNMP нет.

NVPS 710 для новичка не мало, это нагрузка на БД. Очереди должны быть почти всегда на нуле, либо запоздание не больше 10 секунд. Тут определённо проблемы с производительностью, с таким NVPS тут нужно железо по приличнее и хороший тюнинг БД.

Ошибки из-за некорректных имён надо исправлять. Лучше использовать авторегистрацию хостов. Для снижения нагрузки на zabbix сервер хорошо использовать активные проверки и прокси.

Выкручивание poller’ов не всегда хорошо. В качестве отправной точки предлагаю посмотреть видео от инженера тех.поддержки zabbix https://www.youtube.com/watch?v=BglZLJQOEa0 где разбираются типичные проблемы.

Я вот смотрю на нее (в первый раз) и не знаю, нормально это или нет, лол

Главное — чтобы не было бесконечно зависающих ключей, по которым не приходят данные. Если увидел какие-то ключи в очереди, проверь приход данных по ним в latest data. Может быть, там и нет ничего.

А есть какая-нибудь методика по расчету количества потоков?

И смотри графики zabbix gathering и zabbix perfomance.

Просто вагон и маленькая тележка ошибок про несоответствие имени хоста в агенте и на сервере

Вот они вроде бы и не влияют ни на что, т.к. у тебя не эктивчекс, а snmp, но как показала практика, отнимают время у поллеров. Лучше наведи в этом деле порядок, как верно советуют, через автодискавери.

В общем, судя по состоянию процессов, Zabbix был изначально сконфигурирован неправильно. Например, unreachable poller были всегда забиты на 100%, обычных поллеров тоже иногда не хватало.

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

В общем, было 20 unreachable poller. При этом, почему-то крайне медленных:

Насколько нормальна ситуация, когда поллер got 1 values in 60 sec?

Я увеличил количество unreachable poller с 20 до 60 (ну да, разогнался) и перезапустил сервис. Нагрузка на ядра заметно возросла. Если раньше в логе не было медленных запросов, то теперь проскакивают. Полагаю, что теперь не справляется база.

Не понимаю одного: почему с измененным количеством unreachable poller, они все равно остаются медленными. Буду рад, если кто-нибудь объяснит логику процесса

Источник

Как настроить получение значений по расписанию в Zabbix?

Хочу настроить получение значения по расписанию в Zabbix, но не получается.
Чтобы было понятнее, я хочу получать метрики, сколько страниц распечатано на принтере с начала текущего дня и с начала текущего месяца.
Общее количество распечатанных страниц получать я умею, получаю его по стандартному расписанию раз в 10 минут (Update interval: 10m). Чтобы получить данные на начало дня и на начало месяца, я создаю ещё два элемента с пользовательскими интервалами по расписанию md/1 (начало дня) и md1 (начало месяца); Update interval оставляю 1m (убрать его нельзя, это обязательное поле), но Zabbix c такими установками обновляет данные по элементу каждую минуту.
Подскажите, пожалуйста, как правильно решить мою задачу?

1 ответ 1

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками zabbix или задайте свой вопрос.

Похожие

Подписаться на ленту

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

дизайн сайта / логотип © 2021 Stack Exchange Inc; материалы пользователей предоставляются на условиях лицензии cc by-sa. rev 2021.10.15.40479

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

Источник

Zabbix 3.4: Макросы в интервалах времени

Привет. Продолжаем освещать нововведения Zabbix 3.4. Сегодня поговорим об использовании макросов в интервалах обновления и других временных периодах.

Пару слов о макросах

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

Интервалы обновления и хранения истории

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

Обновления каждой метрики также могут быть «гибкими»(см. Пользовательские интервалы), а значит происходить по определенному расписанию («раз в сутки ночью» или «в 9:00 утра в будни»).

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

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

Варианты использования

Интервалы обновления и длительность хранения собранных данных

Во-первых, интервалы обновления метрик (как обычные, так и пользовательские интервалы), о которых сказано выше, теперь поддерживают пользовательские макросы. Во-вторых, использовать макросы можно и в интервалах хранения истории и трендов. В итоге это выглядит вот так:

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

В общем, для интервалов обновлений можно создать небольшой глобальный набор макросов, которые затем использовать по умолчанию для всех новых элементов данных, в зависимости от их типа и важности. Например:

Это позволит не тратить каждый раз время на обдумывание «я хочу собирать эту метрику раз в 60 или раз в 61 секунду? или может раз в 5 минут будет достаточно?», а просто использовать принятые на вашем сервере и проекте правила по сбору и хранению элементов данных, зафиксированные в глобальных макросах. Хотя, возможно, такой вариант подойдет не всем 🙂

В низкоуровневом обнаружении

Поддерживается и контекст макросов, что может быть очень полезно, например, при LLD.
Представьте, что мы собираем трафик сетевых интерфейсов на множестве устройств. Чтобы не нагружать Zabbix, мы бы хотели сделать следующим образом:

• ключевые интерфейсы, транки и прочие аплинки — забирать данные раз в 1 минуту, хранить историю 30 дней, а тренды 1 год.
• остальные интерфейсы — опрашивать раз в 5 минут, хранить историю 3 дня, а тренды 1 месяц.

Затем используем их в прототипе элемента данных интерфейса, но уже с контекстом (в данном случае это будет имя интерфейса ifName):

Уже на уровне узла сети укажем новое значение макроса с контекстом для ключевого интерфейса (для примера возьмем Gi0/0.114):

Теперь посмотрим частоту обновления и время хранения для различных интерфейсов в «Последних данных». Как видно, у нашего очень важного Gi0/0.114 теперь свои правила хранения и сбора:

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

Где еще?

А еще макросы теперь можно применять в других ситуациях, где нужно было указывать время или период. Например, в действиях:

или указать через макрос время доступности инженера для автоматических уведомлений:

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

В итоге

Новые возможности макросов в 3.4 открывают парочку неплохих возможностей: с одной стороны — для более тонкой настройки (для LLD), а с другой стороны — для централизации и управления временем опроса и хранения. И кстати, в интервалах времени появилась поддержка суффиксов s,m,h,d,w — мелочь, а удобно 🙂

Источник