Lld Много параметров

[McLeod095]

Добрый день!
Есть скрипт который выдает заббиксу информацию примерно в таком виде!

{"data":[
{"{#INSTANCENAME}":"PREPROD5"},
{"{#TBSNAME}":"SYSTEM","{#SID}":"PREPROD5"},
{"{#TBSNAME}":"SYSAUX","{#SID}":"PREPROD5"},
{"{#TBSNAME}":"UNDOTBS1","{#SID}":"PREPROD5"},
{"{#TBSNAME}":"AUTH_NEW_DATA","{#SID}":"PREPROD5"},
{"{#TBSNAME}":"CHARGE_ONL_DATA","{#SID}":"PREPROD5"},
{"{#TBSNAME}":"CHARGE_ONL_IDX","{#SID}":"PREPROD5"},
{"{#TBSNAME}":"LOGS","{#SID}":"PREPROD5"},
{"{#TBSNAME}":"SMSNE_NEW","{#SID}":"PREPROD5"}
]}

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

Cannot create item: item with the same key "Oracle[tsfree,{#SID},{#TBSNAME}]" already exists.
Cannot create item: item with the same key "Oracle[tsused,{#SID},{#TBSNAME}]" already exists.
Cannot create item: item with the same key "oracle[activeusercount,{#INSTANCENAME}]" already exists.
Cannot create item: item with the same key "oracle[activeusercount,{#INSTANCENAME}]" already exists.
Cannot create item: item with the same key "oracle[activeusercount,{#INSTANCENAME}]" already exists.
Cannot create item: item with the same key "oracle[activeusercount,{#INSTANCENAME}]" already exists.
Cannot create item: item with the same key "oracle[activeusercount,{#INSTANCENAME}]" already exists.
Cannot create item: item with the same key "oracle[activeusercount,{#INSTANCENAME}]" already exists.
Cannot create item: item with the same key "oracle[activeusercount,{#INSTANCENAME}]" already exists.
Cannot create item: item with the same key "oracle[activeusercount,{#INSTANCENAME}]" already exists.
Cannot create item: item with the same key "oracle[activeusercount,{#INSTANCENAME}]" already exists.
Cannot create item: item with the same key "oracle[activeusercount,{#INSTANCENAME}]" already exists.
Cannot create item: item with the same key "oracle[activeusercount,{#INSTANCENAME}]" already exists.
Cannot create item: item with the same key "oracle[activeusercount,{#INSTANCENAME}]" already exists.
Cannot create item: item with the same key "oracle[activeusercount,{#INSTANCENAME}]" already exists.
Cannot create item: item with the same key "oracle[activeusercount,{#INSTANCENAME}]" already exists.
Cannot create item: item with the same key "oracle[activeusercount,{#INSTANCENAME}]" already exists.
Cannot create item: item with the same key "oracle[activeusercount,{#INSTANCENAME}]" already exists.
Cannot create item: item with the same key "oracle[activeusercount,{#INSTANCENAME}]" already exists.
Cannot create item: item with the same key "oracle[activeusercount,{#INSTANCENAME}]" already exists.
Cannot create item: item with the same key

В чем может быть проблема?

[McLeod095]

Господа!
Может все таки кто-то встречался с таким поведением?
Возникает такое ощущение что заббикс просто пробегается по всем данным и на каждую пару создает элемент данных, при этом даже не смотрит есть необходимое значение или нет.
Сейчас сократил json до

{"data":[
                        {"{#INSTANCENAME}":"PREPROD5"},
                        {"{#TBSNAME}":"SYSTEM","{#SID}":"PREPROD5"},
                        {"{#TBSNAME}":"SYSAUX","{#SID}":"PREPROD5"}
                        ]}

В итоге все равно вижу те же самые ошибки.
При этом есть прототипы элементов данных с таким ключем
oracle[strapply_applytime,{#SID},{#REPLICATION}]
В итоге создается автоматом вот такой элемент данных
oracle[strapply_applytime,PREPROD5,{#REPLICATION}]
подозреваю что это из-за совпадения макрос {#SID}
но все же.

[Jimson]

Тут сложно что то коментировать, так как показанное больше смахивает на бред. Что вы хотите сделать не понятно.
Во втором сообщении у вас три "объекта" в json, при этом для первого объекта определен только {#instancename}, а для двух других {#tbsname} и {#sid}. Для каждого из "объектов" сервер попытается создать полный комплект элементов данных, триггеров и графиков на основании прототипов закрепленных за рассматриваемым правилом lld.
Чтобы у сервера получилось создать все выше перечисленное вы должны обеспечить уникальность названий этих сущностей, а так же уникальность ключа элементов данных. Так, например, использовать только {#sid} нельзя, так как он не уникален для коллекции "объектов".
Что вы хотите от "объекта" для которого определен только "{#instancename}" и почему у вас при этом в ключах элементов данных используются {#instancename} и {#sid} я категорически не понимаю.
Возможно вы не понимаете логику работы lld.

[McLeod095]

Тут сложно что то коментировать, так как показанное больше смахивает на бред. Что вы хотите сделать не понятно.
Во втором сообщении у вас три "объекта" в json, при этом для первого объекта определен только {#instancename}, а для двух других {#tbsname} и {#sid}. Для каждого из "объектов" сервер попытается создать полный комплект элементов данных, триггеров и графиков на основании прототипов закрепленных за рассматриваемым правилом lld.
Чтобы у сервера получилось создать все выше перечисленное вы должны обеспечить уникальность названий этих сущностей, а так же уникальность ключа элементов данных. Так, например, использовать только {#sid} нельзя, так как он не уникален для коллекции "объектов".
Что вы хотите от "объекта" для которого определен только "{#instancename}" и почему у вас при этом в ключах элементов данных используются {#instancename} и {#sid} я категорически не понимаю.
Возможно вы не понимаете логику работы lld.

Ну почему же!
Я понимаю логику работы lld, и понимаю что заббикс пытается создать для каждого объекта необходимые элементы.
Есть необходимость создать мониторинг БД Oracle. Но тк есть ситуации когда на одном хосте есть несколько инстансов и в каждом инстансе надо следить за размером tablesapce и репликаций, то получается что надо 3 lld правила, но два тогда зависят от первого. Вот и хочется все запихнуть в одно правило lld и уже рулить оттуда, сейчас пытаюсь разрулить через фильтры, но есть ощущение что не получится.

[Jimson]

получается что надо 3 lld правила, но два тогда зависят от первого. Вот и хочется все запихнуть в одно правило lld и уже рулить оттуда, сейчас пытаюсь разрулить через фильтры, но есть ощущение что не получится.

Вы считаете это достаточная постановка вопроса для того что бы получить совет/помощь от комьюнити? Я вот вообще нихера не понял. Объясните задачу на примерах, на конкретных примерах.

[McLeod095]

Ну вроде как задачу то решил.
Да сначала немного нахимичил, но в итоге результата добился.
Ситуация.
Есть хост, на котором запущено два инстанса Oracle. Все вроде просто. Создаем два одинаковых шаблона для каждого инстанса и начинаем мониторить то что нам надо. Возникает задача мониторить еще и место в tablespace. Ну вроде ничего сложного, включаем lld и вперед, но уже надо править два шаблона вместо одного. Не совсем интересно. Ну и дальше также возникает необходимость мониторить и репликации, которые также заводим через lld. Упас, опять второй шаблон надо править. Ну, а дальше, надо же мониторить и другой хост с ораклом, на котором имя инстанса уже другое. Ну и тут понимаем что хостов то все больше и больше, и даже через макросы заниматься таким извратом уже не совсем удобно. Вот и пришлось делать универсальный шаблон оракла.
Пришел к тому что сейчас генерится файл с json для правил lld
ну и правила lld для обнаружения
инстансов
tablespace
репликаций
которые через фильтры берут только то что им надо
пример json

{"data":[
{"{#INSTANCE}":"PREPROD5","{#TYPE}":"INSTANCENAME"}
,{"{#INSTANCE}":"PREPROD5","{#TYPE}":"TBSNAME","{#TBSNAME}":"SYSTEM"}
,{"{#INSTANCE}":"PREPROD5","{#TYPE}":"TBSNAME","{#TBSNAME}":"SYSAUX"}
.
.
.
.
.
,{"{#INSTANCE}":"PREPROD5","{#TYPE}":"TBSNAME","{#TBSNAME}":"Z"}
]}

ну и код который это все генерит

                if [ -e ${PID_FILE} ]; then
                        echo 0
                        exit 0
                fi
                (
                        echo $BASHPID > $PID_FILE
                        cd /
                        exec > $LOG
                        exec 2> $LOG
                        exec < /dev/null

                        set -o monitor
                        trap "rm -f ${PID_FILE}; exit 0;" TERM KILL EXIT INT SIGKILL SIGINT
                        START=${SECONDS}
                        DISCOVERY_START_TIME=${SECONDS}
                        DISCOVERY="{\"data\":[\n";
                        F=""
                        for instance in $(grep -v "#" /etc/oratab | grep ":Y" | cut -d ":" -f 1); do
                                DISCOVERY+="${F}{\"{#INSTANCE}\":\"${instance}\",\"{#TYPE}\":\"INSTANCENAME\"}\n"
                                F=","
                                for tbs in $(echo "select tablespace_name from dba_tablespaces where status not in ('READ ONLY','OFFLINE') and contents <> 'TEMPORARY';" | ORACLE_SID=${instance} sqlplus -s /nolog @/etc/zabbix/bin/cont.sql); do
                                        DISCOVERY+="${F}{\"{#INSTANCE}\":\"${instance}\",\"{#TYPE}\":\"TBSNAME\",\"{#TBSNAME}\":\"${tbs}\"}\n"
                                done
                                REPLICATIONS=$(echo "select distinct apply_name from dba_apply_progress;" | ORACLE_SID=${instance} sqlplus -s /nolog @/etc/zabbix/bin/cont.sql 2>/dev/null)
                                ret=$?
                                if [ "${ret}" == "0" ]; then
                                        for replication in ${REPLICATIONS}; do
                                                DISCOVERY+="${F}{\"{#INSTANCE}\":\"${instance}\",\"{#TYPE}\":\"REPLICATION\",\"{#REPLICATION}\":\"${replication}\"}\n"
                                        done
                                fi
                        done
                        DISCOVERY+="]}"
                        DISCOVERY_STOP_TIME=$(($SECONDS-$DISCOVERY_START_TIME))
                        ${ZBX} -k "Oracle[discovery]" -o "${DISCOVERY}" >/dev/null 2>&1
                        ${ZBX} -k "Oracle[tsdiscovery]" -o "${DISCOVERY}" >/dev/null 2>&1
                        ${ZBX} -k "Oracle[repldiscovery]" -o "${DISCOVERY}" >/dev/null 2>&1
                        echo -e "${DISCOVERY}"
                ) &

                sleep 1
                echo ${SECONDS}
                exit 0

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

Спасибо за внимание!

[Jimson]

{"data":[
{"{#INSTANCE}":"PREPROD5","{#TYPE}":"INSTANCENAME"}
,{"{#INSTANCE}":"PREPROD5","{#TYPE}":"TBSNAME","{#TBSNAME}":"SYSTEM"}
,{"{#INSTANCE}":"PREPROD5","{#TYPE}":"TBSNAME","{#TBSNAME}":"SYSAUX"}

Ну в таком виде json выглядит уже более осознанно при условии что вы будете фильтрами делать выборку по полю {#TYPE}.

[McLeod095]

Ну в таком виде json выглядит уже более осознанно.

Я изначально понадеялся на заббикс и на то что если он не увидит объект который указан в прототипе элемента данных то он и не будет пытаться создать элемент данных, а получается что он даже не смотрит есть необходимый объект или нет. Если посмотреть на первую версию json, то я там как раз это и понял. То есть если даже заббикс не находит {#TBSNAME} в объекте json то он не пытается пропустить создание элемента данных, а создает его с ключом Oracle[{#TBSNAME}] и тд. Ну и встречая снова объект где нет данного параметра он опять пытается создать элемент с ключом Oracle[{#TBSNAME}], а он уже существует. В итоге получаем что второй раз правило lld уже не работает тк после первого раза оно завершилось с ошибками.

[Jimson]

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