Не удалось отправить запрос ошибочный тип элемента данных zabbix

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

Profile picture for user Олег

Zabbix

Заново переписал скрипт мониторинга срока действия домена. Это вторая версия. Главной целью было снизить нагрузку на агент, чтобы данные отдавались моментально. Дополнительно появились новые триггеры, отслеживающие частоту проверок.

Мониторинг пригодится всем администраторам и владельцам доменов, чтобы не упустить момент оплаты.

Ссылки

Первая версия скрипта мониторинга срока действия домена:

Zabbix — срок действия домена

Третья версия скрипта мониторинга срока действия домена:

Zabbix — срок действия домена 3

Подготовка

Для проверки срока действия домена нам понадобится утилита whois (у меня Ubuntu):

apt-get install whois

Скрипты

Мониторинг у меня находится на самом заббикс-сервере. Создаём следующую структуру каталогов:

zabbix

В директории /usr/lib/zabbix/externalscripts создадим папку domain_expire с содержимым:

  • data — директория, пока пустая. Наполняться будет автоматически.
  • domain_list.txt — файл содержит список доменов, для которых нужно проверять срок действия. В одной строке один домен, например:
    domain1.ru
    domain2.com
    www.domain3.ru
    internet-lab.ru
    домен.рф

    Кириллические домены поддерживаются!

  • domain_check.sh — этот скрипт вызывается из заббикс-агента пользовательскими переменными. Без параметра он выводит JSON со списком доменов для автообнаружения. С доменом в качестве параметра возвращает количество дней до окончания срока действия домена, домен должен быть в списке domain_list.txt.
  • domain_cron.sh — этот скрипт вызывается в cron раз в шесть часов и обновляет информацию о всех доменах из списка.
  • domain_miss.sh — этот скрипт вызывается из заббикс-агента пользовательскими переменными. С доменом в качестве параметра возвращает количество дней, прошедших с момента последнего обновления данных кроном. Помогает вызвать триггер с предупреждением, если crontab перестанет работать или по какой-то причине перестанет обрабатываться домен в скрипте.

Содержимое domain_check.sh:

#!/bin/bash

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

# получаем имя домена
DOMAIN=$1

#если домен не передан - выводим массив для автообнаружения
if [[ $DOMAIN = "" ]]; then
    # список доменов
    LISTPATH="/usr/lib/zabbix/externalscripts/domain_expire/domain_list.txt"

    #заполняем массив из файла и выводим в JSON
    readarray DOMAINLIST < $LISTPATH
    if ((${#DOMAINLIST[*]}>0)); then
        echo "{"
        echo "  "data": ["
        for ((a=0; a < ${#DOMAINLIST[*]}; a++))
        do
            x=${DOMAINLIST[$a]};
            x=${x//[[:space:]]/};
            echo "    {"
            echo "      "{#DOMAIN}": "${x}""
            if ((a+1 < ${#DOMAINLIST[*]})); then
                echo "    },"
            else
                echo "    }"
            fi
        done
        echo "  ]"
        echo "}"
    fi
else
    #если домен передан - работаем

    #файл
    DATAPATH="/usr/lib/zabbix/externalscripts/domain_expire/data/"
    FILEPATH="${DATAPATH}${DOMAIN}"

    if [ -e $FILEPATH ]; then
        CURRENTDATE=`LANG=en_EN TZ=GMT date +"%b %d %R:%S %Y %Z"`
        EXPDATE=`cat $FILEPATH | grep "ExpDate" | cut -d'=' -f2`
        if [[ $EXPDATE == "" ]]; then
            echo "-1"
        else
            DIFFDAYS=`echo $(( ($(date -d "$EXPDATE" +"%s")-$(date -d "$CURRENTDATE" +"%s"))/86400 ))`
            echo "$DIFFDAYS"
        fi
    else
        echo "-1"
    fi
fi

Содержимое domain_cron.sh:

#!/bin/bash

# Создаёт файлы доменов с текущей датой и датой протухания домена

# переменные
LISTPATH="/usr/lib/zabbix/externalscripts/domain_expire/domain_list.txt"
DATAPATH="/usr/lib/zabbix/externalscripts/domain_expire/data/"
CURRENTDATE=`LANG=en_EN TZ=GMT date +"%b %d %R:%S %Y %Z"`

#заполняем массив из файла
readarray DOMAINLIST < $LISTPATH
if ((${#DOMAINLIST[*]}>0)); then
    for ((a=0; a < ${#DOMAINLIST[*]}; a++))
    do
        DOMAIN=${DOMAINLIST[$a]};
        DOMAIN=${DOMAIN//[[:space:]]/};

        # получаем имя зоны
        ZONE=`echo $DOMAIN | sed 's/./ /' | awk '{ print $2 }'`

        # получаем дату протухания домена
        case "$ZONE" in
            ru|net.ru|org.ru|pp.ru|рф)
            DATE=`whois $DOMAIN | grep paid-till | awk '{ print $2 }' | sed 's/./-/g'`
            ;;
            spb.ru|msk.ru)
            DATE=`whois -h whois.flexireg.net $DOMAIN | grep "Registry Expiry Date:" | sed 's/Registry Expiry Date: //g;s/T/ /g' | awk '{ print $1 }'`
            ;;
            shop)
            DATE=`whois -h whois.tucows.com $DOMAIN | grep "Registrar Registration Expiration Date:" | sed 's/Registrar Registration Expiration Date: //g;s/T/ /g' | awk '{ print $1 }'`
            ;;
            re)
            DATE="$(whois $DOMAIN | awk '/[Ee]xpir.*[Dd]ate:/ || /[Tt]ill:/ || /expire/ {print $NF; exit;}')"
            ;;
            tw)
            DATE=`whois $DOMAIN | grep "Record expires on" | awk '{ print $4 }' | sed 's/./-/g'`
            ;;
            org|com|net)
            DATE=`whois $DOMAIN | grep "Registry Expiry Date:" | sed 's/Registry Expiry Date: //g;s/T/ /g' | awk '{ print $1 }'`
            ;;
            *)
            DATE="$(whois $DOMAIN | awk '/[Ee]xpir.*[Dd]ate:/ || /[Tt]ill:/ || /expire/ {print $NF; exit;}')"
        esac

        VALIDDATE=`LANG=en_EN TZ=GMT date -d"$DATE" +"%b %d %R:%S %Y %Z" > /dev/null 2>&1; echo $?`
        EXPDATE=`LANG=en_EN TZ=GMT date -d"$DATE" +"%b %d %R:%S %Y %Z"`

        #если получили дату
        if [[ $VALIDDATE == 0 ]]; then
            FILEPATH="${DATAPATH}${DOMAIN}"
            touch $FILEPATH
            echo "CheckDate=$CURRENTDATE" > $FILEPATH
            if [[ $EXPDATE != "" ]]; then
                echo "ExpDate=$EXPDATE" >> $FILEPATH
            fi
        fi

    done
fi

Содержимое domain_miss.sh:

#!/bin/bash

# выводит сколько дней назад проверялся домен

# получаем имя домена
DOMAIN=$1

#если домен передан - работаем
if [ $DOMAIN != "" ]; then

        #файл
        DATAPATH="/usr/lib/zabbix/externalscripts/domain_expire/data/"
        FILEPATH="${DATAPATH}${DOMAIN}"

        if [ -f $FILEPATH ]; then
            CURRENTDATE=`LANG=en_EN TZ=GMT date +"%b %d %R:%S %Y %Z"`
            CHECKDATE=`cat $FILEPATH | grep "CheckDate" | cut -d'=' -f2`
            DIFFDAYS=`echo $(( ($(date -d "$CURRENTDATE" +"%s")-$(date -d "$CHECKDATE" +"%s"))/86400 ))`
            echo "$DIFFDAYS"
        else
            echo "-1"
        fi
else
    #ошибка
    echo "-1"
fi

Примечания к скриптам

В коде скриптов есть путь вида usr/lib/zabbix/externalscripts/, если у вас другие пути — нужно будет изменить.

CURRENTDATE=`LANG=en_EN TZ=GMT date +"%b %d %R:%S %Y %Z"`

Это получение текущей даты.

  • TZ=GMT — переводит дату в формат GMT
  • LANG=en_EN — устанавливает язык
  • «%b %d %R:%S %Y %Z» — формат даты вида: Jun 14 03:59:01 2019 GMT

Crontab

В крон добавляем расписание, срабатывает раз в шесть часов:

* */6 * * * /usr/lib/zabbix/externalscripts/domain_expire/domain_cron.sh >/dev/null 2>&1

Перезапускаем крон:

service cron restart

Скрипт должен выполниться и папка data заполнится файлами с названиями доменов. Если не выполнится — запустите domain_cron.sh сами, а потом разбирайтесь, что там с кроном.

Пример содержимого файлов на примере домена internet-lab.ru.

root@zabbix:/usr/lib/zabbix/externalscripts/domain_expire/data# pwd
/usr/lib/zabbix/externalscripts/domain_expire/data

root@zabbix:/usr/lib/zabbix/externalscripts/domain_expire/data# ll | grep internet
-rw-r--r-- 1 root root   69 июн 14 06:59 internet-lab.ru

root@zabbix:/usr/lib/zabbix/externalscripts/domain_expire/data# cat internet-lab.ru
CheckDate=Jun 18 09:59:01 2019 GMT
ExpDate=Feb 20 09:55:45 2020 GMT

Внутри файлов пишется две даты. Дата проверки в формате GMT.

CheckDate=Jun 18 09:59:01 2019 GMT

Дата истечения домена (если удалось определить) в формате GMT:

ExpDate=Feb 20 09:55:45 2020 GMT

Zabbix агент

Теперь нужно настроить заббикс-агент, чтобы он отдавал данные серверу. Убеждаемся, что в /etc/zabbix/zabbix_agentd.conf есть настройка:

Include=/etc/zabbix/zabbix_agentd.conf.d/

Переходим в папку /etc/zabbix/zabbix_agentd.conf.d/, создаём файл domain_expire.conf с содержимым:

UserParameter=domain_expire.check[*],/usr/lib/zabbix/externalscripts/domain_expire/domain_check.sh $1
UserParameter=domain_expire.miss[*],/usr/lib/zabbix/externalscripts/domain_expire/domain_miss.sh $1
UserParameter=domain_expire.list,/usr/lib/zabbix/externalscripts/domain_expire/domain_check.sh
  • domain_expire.list — список доменов в JSON для автообнаружения.
  • domain_expire.check[*] — дней до окончания срока действия домена (float, потому как может возвращать «-1»).
  • domain_expire.miss[*] — сколько дней назад была проверка. В идеале должно быть 0, иначе нужно разбираться.

Перезапускаем агент:

service zabbix-agent restart

Zabbix шаблон

Ставим на сервер шаблон и привязываем к заббикс-серверу. Шаблон я уже набросал.

Скачать шаблон: zbx_domain_expire.xml

zabbix

В шаблоне одно приложение:

zabbix

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

zabbix

Два прототипа элементов данных:

zabbix

Семь прототипов триггеров:

zabbix

Log inSkip to main contentSkip to sidebar

Uploaded image for project: 'ZABBIX BUGS AND ISSUES'

  1. ZABBIX BUGS AND ISSUES
  2. ZBX-19109
    XMLWordPrintable

Details


    • Type:


      Problem report

    • Status:

      Closed


    • Priority:


      Trivial

    • Resolution:

      Fixed


    • Affects Version/s:



      5.2.4

    • Fix Version/s:



      None


    • Component/s:


      None

    Description

      Установили Template Tel Asterisk by HTTP: Asterisk: Get stats: SIP peers discovery шаблон
      но не отрабатывает обнаружение SIP peers discovery. Ошибка Не удалось отправить запрос
      Не удалось отправить запрос: ошибочный тип правила обнаружения.

      Attachments

        Activity

          People

            Votes:
            0

            Vote for this issue

            Watchers:

            1

            Start watching this issue

            Dates

              Created:

              2021 Mar 10 12:32
              Updated:

              2021 Mar 10 17:29
              Resolved:

              2021 Mar 10 17:29

              Содержание

              1. Ответы (1)
              2. четверг, 19 октября 2017 г.
              3. В системе мониторинга Zabbix элемент данных vfs.file.exists[] отображает статус «не поддерживается»
              4. 3 комментария:
              5. Введение
              6. Немного истории
              7. Как всё выглядит теперь
              8. Подготовка
              9. Настройка хоста
              10. Заключение

              401 просмотра

              1 ответ

              7 Репутация автора

              Я использую Zabbix 3.2 для более чем 100 виртуальных машин (Windows, Linux, Mac), и я добавил скрипт для всех виртуальных машин Windows. Сценарий является локальным для каждой виртуальной машины, и agentd.conf имеет:

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

              Когда я перехожу к пунктам «Предметы», присутствует красный «i», статус «Не поддерживается», а над красным «i» говорится:

              Полученное значение [В настоящее время к этому удаленному компьютеру нельзя устанавливать больше соединений, поскольку количество подключений, которое может принять компьютер, уже существует] не подходит для типа значения [Числовой (без знака)] и типа данных [Десятичный].

              Я нахожу это очень странным, поскольку локально наблюдать за виртуальной машиной и не использовать RDP. Я пытался использовать общую папку и иметь сценарий в 1 месте. Это явно не сработало, поэтому я делаю это локально.

              В журнале написано «old_random_var не поддерживается». Это еще один параметр, который работает в zabbix, но предоставляет этот журнал. Еще раз, этот old_var совершенно не связан с var.

              Использование zabbix_get говорит о том, что элемент не поддерживается.

              Любой совет будет принята с благодарностью.

              E: Интересное дополнение, из всех узлов, оно работает примерно в 20 случайных, а не в других. В этих узлах нет НИЧЕГО уникального. Совершенно случайно.

              Ответы (1)

              плюса

              3091 Репутация автора

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

              Данный блог был создан как дублирование моей странички www.bubnov.su, но без всяких личных материалов – только то, что касается IT

              четверг, 19 октября 2017 г.

              В системе мониторинга Zabbix элемент данных vfs.file.exists[] отображает статус «не поддерживается»

              3 комментария:

              А триггер ты какой настроил под проверку файла?

              Триггер из ленности настроил «On change» – под мою задачу хватает. хотя по идее, да, надо глубже было копнуть =)

              Введение

              Немного истории

              Для меня описанный функционал был важен в связи с тем, что на нашем предприятии используется несколько СХД от HP, а именно HP MSA 2040/2050, метрики с которых снимаются запросами к их XML API с использованием Python-скрипта.

              В самом начале, когда встала задача наблюдения за обозначенным оборудованием и был найден вариант с использованием API, выяснилось, что в самом простом случае, чтобы узнать, скажем, состояние здоровья одного компонента СХД, требовалось сделать два запроса:

              • Запрос токена аутентификации (session key);
              • Сам запрос, возвращающий информацию по компоненту.

              Теперь представьте, что хранилище состоит из 24 дисков (а может и больше), двух блоков питания, пары контроллеров, вентиляторов, нескольких дисковых пулов и пр. — умножаем всё это на 2 и получаем более 50 элементов данных, что равно стольким же запросам к API при ежеминутных проверках. Если попробовать пойти по такому пути, API быстро «ложится», а ведь мы говорим только о запросе «здоровья» компонентов, не учитывая остальные возможные и интересные метрики — температура, наработка на часы для жестких дисков, скорость вращения вентиляторов и т.д.

              Первым решением, которое я сделал чтобы разгрузить API, еще до выхода Zabbix версии 3.4, было создание кэша для получаемого токена, значение которого записывалось в файл и хранилось N-минут. Это позволило снизить количество обращений к API ровно в два раза, однако, ситуацию сильно не изменило — что-то помимо состояния здоровья получать было проблематично. Примерно в это время я посетил Zabbix Moscow Meetup 2017, устроенный компанией Badoo, где и узнал о упомянутом выше функционале зависимых элементов данных.

              Скрипт был доработан до возможности отдавать подробные JSON объекты, содержащие интересующую нас информацию по различным компонентам хранилища и вывод его стал выглядеть примерно так вместо одиночных строковых или числовых значений:

              Это пример с отдаваемыми данными по всем дискам хранилища. По остальным компонентам картина схожая — ключом является ID компонента, а значением — объект JSON, содержащий нужные метрики.

              Всё было хорошо, но быстро всплыли нюансы, описанные в начале статьи — все зависимые метрики приходилось создавать и обновлять вручную, что было довольно мучительно (порядка 300 метрик на одну СХД плюс триггеры и графики). Нас могло бы спасти LLD, но тут, при создании прототипа, оно не позволяло нам указывать в качестве родительского айтема тот, что не был создан самим правилом, а грязный хак с созданием фиктивного айтема через LLD и подменой его itemid в БД на нужный, ронял сервер Zabbix. В багтрекере Zabbix быстро появились упомянутые фичреквесты, что указывало на то, что данный функционал важен не только мне.

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

              Как всё выглядит теперь

              Для демонстрации новых возможностей Zabbix мы возьмем:

              • СХД HPE MSA 2040 доступную по протоколу HTTP/HTTPS;
              • Сервер Zabbix 4.0alpha9, установленный из официального репозитория на CentOS 7.5.1804;
              • Скрипт, написанный на Python третьей версии и предоставляющий нам возможность обнаруживать компоненты СХД (LLD) и возвращать данные в формате JSON для парсинга на стороне сервера Zabbix с использованием JSON Path.

              Родительский элемент данных будет представлять собой «внешнюю проверку» (external check), вызывающую скрипт с необходимыми аргументами и хранить полученные данные как текст.

              Подготовка

              Python-скрипт устанавливается в соответствии с документацией и имеет в зависимостях Python библиотеку «requests». Если у вас RHEL-based дистрибутив, установить её можно с помощью пакетного менеджера yum:

              Или с помощью pip:

              Протестировать работу скрипта можно из оболочки, запросив, например, данные LLD о дисках:

              Настройка хоста

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

              Имя — указываем произвольно;
              Тип — внешняя проверка;
              Ключ — вызов скрипта с нужными параметрами (см. документацию скрипта на GitHub);
              Тип информации — текст;
              Интервал обновления — в примере используется пользовательский макрос <$UPDATE>, разворачивающийся в значение «1m»;
              Период хранения истории — один день. Думаю, что хранить родительский элемента данных дольше смысла не имеет.
              Проверяем последние данные по созданному элементу:

              Приходит JSON, значит всё сделано правильно.

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

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

              Имя — указываем произвольно;
              Тип — зависимый. В качестве родительского элемента данных выбираем соответствующий созданный ранее элемент;
              Ключ — проявим фантазию, но нужно учесть, что каждый ключ должен быть уникальным, поэтому включим в него макрос LLD;
              Тип информации — в данном случае числовой;
              Период хранения истории — в примере это пользовательский макрос, указывается по вашему усмотрению;
              Период хранения трендов — опять же, пользовательский макрос;

              Так же я добавил прототип «Приложения» — к нему можно удобно привязывать метрики, относящиеся к одному компоненту.

              На вкладке «Препроцессинг» создадим шаг типа «JSON Path» с правилом, извлекающим показания температуры:

              Выражение шага выглядит так: $[‘<#DISK.ID>’][‘temperature’]

              Обратите внимание, что теперь в выражении можно использовать макросы LLD, что не просто значительно упрощает нам работу, но и вообще дает проделывать подобные штуки довольно просто (раньше вас бы направили в Zabbix API).

              Далее, по аналогии с температурой, создадим оставшиеся прототипы элементов данных:

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

              Ждем пока обновится конфигурационный кэш или толкаем его обновление вручную:

              После этого можно воспользоваться еще одной крутейшей «фишкой» версии 4.0 — кнопкой «Check now» для запуска созданных правил LLD:

              У меня получился следующий результат:

              Заключение

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

              Спасибо, что читали, ссылки на используемые материалы, а там же на актуальный шаблон для HPE MSA P2000G3/2040/2050 можно найти ниже.

              Понравилась статья? Поделить с друзьями:
            • Не удалось перевести страницу ошибка
            • Не удалось отправить запрос ошибочный тип правила обнаружения
            • Не удалось отформатировать выбранный раздел ошибка 0x8004242d при установке
            • Не удалось отменить подписку на хештег как исправить
            • Не удалось отформатировать выбранный диск ошибка 0x80070057