Ad Widget

**Kos** · 06-04-2022, 13:31

Originally posted by csr

Просьба разъяснить текущую ситуацию с подходом к проблемам при получении данных и их последующему анализу.

На текущий момент, если заббикс не может получить данные (в информации может стоять, например, "The system cannot find the path specified." или "Возвращаемые данные отсутствуют.") то никакая "ошибка" не возникает. Получается, что элемент не содержит данные и триггер, обрабатывающий данный элемент, не срабатывает.

Аналогичная ситуация, когда элемент данных получил не то, что ожидалось и триггер не может быть вычислен (информация по триггеру, например, "Cannot evaluate function").

У меня в голове не укладывается, как такое может быть, что если система мониторинга не получила данные или не смогла их обработать - она никак об этом не сообщает!? Как говорится, ведь "что-то пошло не так", а мониторинг для этого и существует, чтобы показывать не штатные ситуации.

В Zabbix-е есть понятие "unsupported state" у элемента данных (item) и "unreachable host" у хоста.

Если какой-то хост вообще не отвечает на запросы - то сам хост считается недостижимым (unreachable), т.е. нерабочим; и на какое-то время его опрос прекращается, дабы не расходовать понапрасну ресурсы сервера Zabbix. Такое поведение описано в документации (ссылка).

Если же хост доступен, но не может вернуть корректное значение конкретной метрики (как в приведённых Вами примерах), то сам элемент данных считается "неподдерживаемым" (unsupported).
С такими элементами данных несколько сложнее, поскольку конкретные триггеры для них не срабатывают.
В веб-интерфейсе они отображаются красной пометкой справа, при наведении мышкой на которую зачастую виден текст ошибки, мешающей эту метрику собрать.
Про unsupported items в документации сказано вскользь (ссылка), и до недавнего времени их как-то отслеживать было следующим образом:

контролировать служебную метрику Zabbix zabbix[host,,items_unsupported] для каждого хоста (ссылка);
настраивать уведомления на внутренние события (ссылка).

В последних версиях (начиная с 5.2) можно обрабатывать такие вещи через препроцессинг на уровне отдельного элемента данных. Например, в случае получения ошибки, при которой элемент данных переходит в неподдерживаемое состояние, можно при помощи шага препроцессинга "Check for not supported value" (ссылка) принудительно заменить значение на какое-либо заведомо невозможное; после чего сделать триггер, который будет сравнивать с этим значением и выводит соответствующее сообщение.

Нет штатных дашбордов/отчетов, чтобы видеть текущие "неопределенные" элементы и триггеры.

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

Это не совсем так. Идёте в меню Configuration -> Hosts, жмёте на ссылку "Items" напротив нужного хоста, после чего в фильтре (который можно открыть/скрыть кнопкой справа вверху) можно выбрать "State" = "Not supported" (по умолчанию выбрано "All").
В итоге получите все неподдерживаемые элементы данных по конкретному хосту.
Более того, если при этом в фильтре очистить поле "Hosts" (убрать имя хоста вообще), то получите перечень вообще всех неподдерживаемых элементов данных по всем хостам.

**csr** · 08-04-2022, 11:11

Спасибо за ответ

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

Раньше я работал с нагиосом. Там все просто - или получили значение метрики и она вызвала алерт или не получили (из-за деления на 0, например) и увидели исключение. Т.е. мы уверены, что у нас все хорошо, согласно метрикам или, если метрику не смогли получить/обработать - видим ошибки. Вхождение в нагиос было согласно его "уставам" и best practices

С заббиксом начал работу аналогично, согласно "канонам". Например: windows/linux машины - агент2, шаблон с активными проверками, настройка шаблонов согласно их макросам. Создание своих шаблонов.

Что стало не понятно в принципе - внутренние ошибки заббикса не считаются проблемой. У меня это не укладывается в голове, как ошибка получения значения (или его обработки) на основании которой должен сработать важный триггер априори не считается ошибкой?! Почему нет хотя бы других видов ошибок, вида "внутренняя ошибка" или что-то подобное?! Хотя такие ошибки можно однозначно классифицировать "чрезвычайные", ведь за неми могут быть и не сработавший триггер, сообщающий о критическом инциденте! Почему так сделано? Может стоит это выносить на "голосование"? Или я один такой "непонятливый"

?

контролировать служебную метрику Zabbix zabbix[host,,items_unsupported] для каждого хоста (ссылка);

Сделал шаблон, добавил ко всем базовым шаблонам. Работает. Большое спасибо. Часть "боязни" что-то пропустить ушло

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

Пробовал раньше, но или я не разобрался или там творится треш. Сообщений очень много, пропустить что-то важно - элементарно. А главное - оповещение, это не то, на что смотрят админы. Они смотрят на результат - ошибки в дашборде.

В итоге получите все неподдерживаемые элементы данных по конкретному хосту.

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

А что делать с макросами, у которых состояние "unknown" (Cannot evaluate function avg(/Zabbix server/zabbix[process,java poller,avg,busy],10m): item is not supported)?

**Kos** · 08-04-2022, 11:49

Originally posted by csr

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

А что делать с макросами, у которых состояние "unknown" (Cannot evaluate function avg(/Zabbix server/zabbix[process,java poller,avg,busy],10m): item is not supported)?

Ну добавьте в прототип айтема, возвращающего процент заполненности диска, шаг препроцессинга, который бы в случае not supported state принудительно бы заменял значение на "-1". И прототип триггера, который бы реагировал на значение меньше нуля и кричал о пропаже диска.

Про макросы, честно говоря, не понял.

**csr** · 08-04-2022, 12:09

Ну добавьте в прототип айтема, возвращающего процент заполненности диска, шаг препроцессинга, который бы в случае not supported state принудительно бы заменял значение на "-1". И прототип триггера, который бы реагировал на значение меньше нуля и кричал о пропаже диска.

Технически я понимаю (хотя еще слаб в заббиксе), что надо сделать. Я другого не понимаю - я один такой, который не верит в надежность мониторинга от заббикса, когда что-то может пропадать, а в алертах это не покажется? Может мне надо идеологический подход менять или надо менять все стандартные шаблоны, где зарыты мины пропадания наблюдаемого объекта без сообщения о нем? Или это считается нормой?

Про макросы, честно говоря, не понял.

Есть стандартный шаблон сервера заббикс. Сейчас макрос выглядит так:

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

Прошу понять меня правильно - я не занудствую и не "бухчу" на заббикс, я просто не понимаю описанную мной проблему и не понимаю, почему никто ей не озабочен, почему стандартные шаблоны позволяют чему-то пропадать или не работать без соответствующих алертов.

**Kos** · 08-04-2022, 14:24

Originally posted by csr

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

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

Пример, который Вы привели (со сбором данных о дисках), построен на базе технологии LLD (низкоуровневого обнаружения).
Сам принцип LLD: создавать нужные однотипные объекты в Zabbix-е (элементы данных, а также триггеры и графики для них) только для тех вещей, которые есть в наличии и нужны для мониторинга (а при необходимости - удалять). Т.е. фокус на том, чтобы не заставлять админа создавать всё это руками, а как-то автоматизировать; а не на том, чтобы контролировать их количество.
Предположим, на одной машине есть только диск C:, а на другой - ещё десяток других логических дисков; при использовании стандартного шаблона для каждого из них будет контролироваться используемое место. Но не будет контролироваться изменение списка этих дисков. Скажем, если дискаверинг отработал в тот момент, когда у меня была вставлена флешка, то будет обнаружен ещё один логический диск; а после вынимания флешки - сначала элементы данных, относящиеся к этому диску, перейдут в состояние "not supported", а потом - будут удалены. И, наверное, это считается нормальным поведением.

Originally posted by csr

Есть стандартный шаблон сервера заббикс. Сейчас макрос выглядит так:

Понятно. Только это не макрос. Это в Zabbix-е называется "триггер".
Да, он перейдёт в состояние "unknown", поскольку не могут быть обработаны данные для элемента данных, который в нём использован.
При желании их тоже можно все найти по соответствующему фильтру.
Автоматически - не уверен; наверное, нельзя; но тут важнее отслеживать причину (элементы данных), а не следствие (триггер).

**Semiadmin** · 08-04-2022, 14:58

Originally posted by csr

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

Немного поделюсь опытом. Была такая же проблема, решали ее прототипом триггера с nodata, благо с версии 3.2 эта функция работает с неподдерживаемыми айтемами. Но сие было чревато ложными срабатываниями, ибо отсутствие данных о диске от агента не обязательно есть следствие отсутствия диска.
С появлением в агенте 5.4.5 ключа vfs.fs.get перешли на мониторинг через прототипы зависимых от него айтемов, и в случае отсутствия в полученном JSON ранее обнаруженного диска через обработку ошибки препроцессинга ставим total size = 0. И прототип триггера на это дело.

**csr** · 08-04-2022, 17:20

Макрос - описался, конечно

Про LLD это понятно, но "пропажа" обнаруженного должна хоть как-то оповещаться. Хоть со статусом "Not classified". Но опять-таки, LLD это частный случай. Общий это то, что при ошибках ничего не сообщается.
Пример с триггером показателен. Кто-то выключил элемент данных и триггер перестал считаться. Кто выключал, возможно, и не знал, что что "что-то сломается" и визуально, по дашборду, ничего не сломалось. Опять-таки, официальные шаблоны сделаны так, что "пропажа" считается не важной. Мы мониторим сервисы, что те, кто в автомате должен быть запущен. А какой-то сервис взяли и удалили. И мы считаем, что ничего не случилось.

Может стоит это добавить в zbxnext или народ не поймет и не поддержит? Имхо, на текущий момент, из коробки, это некорректное отношение к внутренним ошибкам со стороны заббикса. Мониторинг сам себя не мониторит

**csr** · 08-04-2022, 17:23

Originally posted by Semiadmin

Немного поделюсь опытом. Была такая же проблема, решали ее прототипом триггера с nodata,

Спасибо за то, что делитесь решением. Но у меня в голове не укладывается общий подход. Про диски это частности. Тоже самое с сетевыми интерфейсами, службами и пр. Всем, что работает через LLD, да и вообще. Мы так потеряли немного данных, когда скрипт, который запускал агент заббикса просто перестал работать. Заббикс подло промолчал

**csr** · 22-04-2022, 10:32

Комрады, а можно как-то получать алерты при пропаже не обнаружываемых lld элементов?

Когда в айтемсах желтый значек, а в описании что-то подобное: "The item is not discovered anymore and will be deleted in 29d 22h 53m (on 05/22/2022 at 09:45 AM)."?

Такое состояние не является "not supported" и не отлавливается ни фильтром через веб, ни zabbix[host,,items_unsupported]

**Semiadmin** · 22-04-2022, 12:12

Боюсь, что в общем виде - только через API. Искать айтемы с ненулевым значением свойства ts_delete.

**csr** · 27-10-2023, 11:51

Решил вернуться к данной теме и столкнулся со следующим.

Могу получить список всех значений айтемов. Вижу свойство "ts_delete", но не могу получить значения, у которых это свойство не равно нулю.

Пример запроса (в данном случае ищу наоборот - айтемы с нулевыми значениями)

Code:

{
  "jsonrpc": "2.0",
  "method": "item.get",
  "params": {
    "host": "hostname",
    "output": [
      "name"
    ],
    "selectItemDiscovery": [
      "ts_delete"
    ],
    "filter": {
      "ts_delete": "0"
    }
  },
  "auth": "'$session'",
  "id": 1
}

Но все-равно получаю все айтемы - с нулевыми и не нулевыми значениями.

И объясните плз, почему фильтр не работает,

"Accepts an array, where the keys are property names, and the values are either a single value or an array of values to match against."

Я фильтрую по свойству элемента, ведь ts_delete это свойство или нет?

Что я делаю не так?

**Kos** · 27-10-2023, 14:51

Originally posted by csr

Решил вернуться к данной теме и столкнулся со следующим.

Возвращаясь к теме через полтора года, желательно указывать версию Zabbix, с которой работаете.
Так что отвечаю, основываясь на документации к текущей LTS-версии (6.0), ссылка.

Originally posted by csr

Я фильтрую по свойству элемента, ведь ts_delete это свойство или нет?
Что я делаю не так?

Не знаю, вы не привели примера того, что вам возвращается и в каком виде.
Могу предположить, что фильтрация не работает, т.к. вы задаёте фильтр на уровне объекта класса item, а у него такого атрибута как ts_delete просто нет.
Этот атрибут есть у связанного с ним объекта класса itemDiscovery.
Другая версия - возможно, не соответствует тип (у вас указан текстовый, т.е. строка в кавычках, а у свойства ts_delete тип - timestamp).

**csr** · 27-10-2023, 15:33

желательно указывать версию]

6.4.7

Не знаю, вы не привели примера того, что вам возвращается и в каком виде.

записи вида:
{"itemid":"51222","name":"Ds: Total space","itemDiscovery":{"ts_delete":"1700665277"}}

Этот атрибут есть у связанного с ним объекта класса itemDiscovery.

я тоже предположил, что фильтр работает только на объект item, но считал, что ts_delete это все-таки свойство самого объекта item.

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

можно как-то наложить фильтр на itemDiscovery? Или только путем перебора?

**Kos** · 27-10-2023, 16:24

Originally posted by csr

можно как-то наложить фильтр на itemDiscovery? Или только путем перебора?

Увы, точнее не скажу.
Как минимум, можно использовать фильтр

Code:

"flags": 4

(чтобы отбирать только элементы данных, созданные механизмом LLD).
Боюсь, что в худшем случае дальше фильтровать придётся руками...

Ad Widget

Получение данных о проблемных триггерах

Получение данных о проблемных триггерах

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment