lld нескольких БД oracle

[Alexey.Kuzmin]

Добрый день!
Для одной БД мы настроили и lld, и мониторинг базы.
Насколько я понимаю, в lld должна возвращаться "плоская" строка, например:
{"data": [{"{#DBNAME}": "DB"},{"{#INST_NAME}": "DB" },{"{#TS_NAME}": ["SYSAUX","SYSTEM","USERS"]}]}
Как быть, если на сервере - несколько БД?
Нужно делать несколько экземпляров агента?
Или можно - одним?

[Kos]

Насколько я понимаю, в lld должна возвращаться "плоская" строка,

Не совсем так. Задача LLD - создать набор однотипных объектов (элементов данных, триггеров, графиков), поэтому в json-е возвращается список (массив) неких элементов, на основе которых эти объекты строятся. Каждый элемент массива - набор пар "макрос - значение", чтобы их можно было использовать в прототипах элементов данных/триггеров/графиков.

Для примера, у нас на серверах DB2 используется два правила обнаружения: одно для списка баз данных, другое - для списка tablespace-ов. Соответствующие JSON-ы выглядят так.
Для баз данных:

{ "data":[
 { "{#DBALIAS}":"PL4DB2", "{#DBNAME}":"PL4DB2" }
]}

Для табличных пространств:

{ "data":[
 { "{#TBS_ID}":"PL4DB2:0", "{#DBNAME}":"PL4DB2", "{#TBSID}":"0", "{#TBSNAME}":"SYSCATSPACE" },
 { "{#TBS_ID}":"PL4DB2:1", "{#DBNAME}":"PL4DB2", "{#TBSID}":"1", "{#TBSNAME}":"TEMPSPACE1" },
 { "{#TBS_ID}":"PL4DB2:2", "{#DBNAME}":"PL4DB2", "{#TBSID}":"2", "{#TBSNAME}":"USERSPACE1" },
 { "{#TBS_ID}":"PL4DB2:3", "{#DBNAME}":"PL4DB2", "{#TBSID}":"3", "{#TBSNAME}":"SYSTOOLSPACE" },
 { "{#TBS_ID}":"PL4DB2:4", "{#DBNAME}":"PL4DB2", "{#TBSID}":"4", "{#TBSNAME}":"SYSTOOLSTMPSPACE" },
 { "{#TBS_ID}":"PL4DB2:7", "{#DBNAME}":"PL4DB2", "{#TBSID}":"7", "{#TBSNAME}":"LOGTABLES_32K" },
 { "{#TBS_ID}":"PL4DB2:8", "{#DBNAME}":"PL4DB2", "{#TBSID}":"8", "{#TBSNAME}":"XXXXDATA" },
 { "{#TBS_ID}":"PL4DB2:9", "{#DBNAME}":"PL4DB2", "{#TBSID}":"9", "{#TBSNAME}":"MONITORDATDA" },
 { "{#TBS_ID}":"PL4DB2:10", "{#DBNAME}":"PL4DB2", "{#TBSID}":"10", "{#TBSNAME}":"TBSP4K_DATA" },
 { "{#TBS_ID}":"PL4DB2:11", "{#DBNAME}":"PL4DB2", "{#TBSID}":"11", "{#TBSNAME}":"TBSP4K_IDX" },
 { "{#TBS_ID}":"PL4DB2:12", "{#DBNAME}":"PL4DB2", "{#TBSID}":"12", "{#TBSNAME}":"TBSP4K_ARX" },
 { "{#TBS_ID}":"PL4DB2:13", "{#DBNAME}":"PL4DB2", "{#TBSID}":"13", "{#TBSNAME}":"TBSP4K_TMP" },
 { "{#TBS_ID}":"PL4DB2:14", "{#DBNAME}":"PL4DB2", "{#TBSID}":"14", "{#TBSNAME}":"TBSP4K_SYSTMP" },
 { "{#TBS_ID}":"PL4DB2:15", "{#DBNAME}":"PL4DB2", "{#TBSID}":"15", "{#TBSNAME}":"TBSP8K_DATA" },
 { "{#TBS_ID}":"PL4DB2:16", "{#DBNAME}":"PL4DB2", "{#TBSID}":"16", "{#TBSNAME}":"TBSP8K_IDX" },
 { "{#TBS_ID}":"PL4DB2:17", "{#DBNAME}":"PL4DB2", "{#TBSID}":"17", "{#TBSNAME}":"TBSP8K_ARX" },
 { "{#TBS_ID}":"PL4DB2:18", "{#DBNAME}":"PL4DB2", "{#TBSID}":"18", "{#TBSNAME}":"TBSP8K_TMP" },
 { "{#TBS_ID}":"PL4DB2:19", "{#DBNAME}":"PL4DB2", "{#TBSID}":"19", "{#TBSNAME}":"TBSP8K_SYSTMP" },
 { "{#TBS_ID}":"PL4DB2:20", "{#DBNAME}":"PL4DB2", "{#TBSID}":"20", "{#TBSNAME}":"TBSP16K_DATA" },
 { "{#TBS_ID}":"PL4DB2:21", "{#DBNAME}":"PL4DB2", "{#TBSID}":"21", "{#TBSNAME}":"TBSP16K_IDX" },
 { "{#TBS_ID}":"PL4DB2:22", "{#DBNAME}":"PL4DB2", "{#TBSID}":"22", "{#TBSNAME}":"TBSP16K_ARX" },
 { "{#TBS_ID}":"PL4DB2:23", "{#DBNAME}":"PL4DB2", "{#TBSID}":"23", "{#TBSNAME}":"TBSP16K_TMP" },
 { "{#TBS_ID}":"PL4DB2:24", "{#DBNAME}":"PL4DB2", "{#TBSID}":"24", "{#TBSNAME}":"TBSP16K_SYSTMP" },
 { "{#TBS_ID}":"PL4DB2:25", "{#DBNAME}":"PL4DB2", "{#TBSID}":"25", "{#TBSNAME}":"TBSP32K_DATA" },
 { "{#TBS_ID}":"PL4DB2:26", "{#DBNAME}":"PL4DB2", "{#TBSID}":"26", "{#TBSNAME}":"TBSP32K_IDX" },
 { "{#TBS_ID}":"PL4DB2:27", "{#DBNAME}":"PL4DB2", "{#TBSID}":"27", "{#TBSNAME}":"TBSP32K_ARX" },
 { "{#TBS_ID}":"PL4DB2:28", "{#DBNAME}":"PL4DB2", "{#TBSID}":"28", "{#TBSNAME}":"TBSP32K_TMP" },
 { "{#TBS_ID}":"PL4DB2:29", "{#DBNAME}":"PL4DB2", "{#TBSID}":"29", "{#TBSNAME}":"TBSP32K_SYSTMP" },
 { "{#TBS_ID}":"PL4DB2:30", "{#DBNAME}":"PL4DB2", "{#TBSID}":"30", "{#TBSNAME}":"TBSP32K_LOB" },
 { "{#TBS_ID}":"PL4DB2:31", "{#DBNAME}":"PL4DB2", "{#TBSID}":"31", "{#TBSNAME}":"MONITORING_32K" }
]}

Соответственно, для каждой базы данных из прототипов создаётся свой набор объектов - элементов данных (статус, всевозможные счётчики) и триггеров, а для каждого tablespace-а - свой. При этом при создании каждого такого объекта можно использовать любые предоставляемые этими JSON-ами макросы. Например, чтобы в названии триггера на некорректное состояние tablespace-а сразу указать его имя, ID, а также имя базы данных, к которой он относится.

[Alexey.Kuzmin]

Спасибо.
То есть, мы сначала определяем список БД (первый lld)
Потом для каждой БД делаем свой lld (табличные пространства и т.п.).
При этом, во втором lld мы можем пользоваться результатами первого?
И нужно ли делать в именах items ссылочку на БД (чтобы они были уникальными)?

[Kos]

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

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

Скажем, для базы данных PL4DB2 генерируются такие элементы данных:

ключ                   имя
db2.db.status[PL4DB2]  DB PL4DB2: Database status
db2.db.role[PL4DB2]    DB PL4DB2: Role in HADR
db2.db.lwaits[PL4DB2]  DB PL4DB2: Locks waits
db2.db.locks[PL4DB2]   DB PL4DB2: Locks held currently
[...и т.д.]

и на том же хосте - такие элементы данных для табличных пространств:

ключ                        имя
db2.tbs.detailed[PL4DB2:0]  Tablespace PL4DB2:0 SYSCATSPACE: state as String
db2.tbs.detailed[PL4DB2:1]  Tablespace PL4DB2:1 TEMPSPACE1: state as String
[...]
db2.tbs.size[PL4DB2:0]      Tablespace PL4DB2:0 SYSCATSPACE: size (bytes)
db2.tbs.size[PL4DB2:1]      Tablespace PL4DB2:1 TEMPSPACE1: size (bytes)
[...]
db2.tbs.state[PL4DB2:0]     Tablespace PL4DB2:0 SYSCATSPACE: State as Numeric
db2.tbs.state[PL4DB2:1]     Tablespace PL4DB2:1 TEMPSPACE1: State as Numeric
[...]
db2.tbs.type[PL4DB2:0]      Tablespace PL4DB2:0 SYSCATSPACE: Type
db2.tbs.type[PL4DB2:1]      Tablespace PL4DB2:1 TEMPSPACE1: Type
[...и т.д.]

Имя триггера, для примера, имеет вид:

Database PL4DB2: Tablespace 0 (SYSCATSPACE) has bad state!

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

[Alexey.Kuzmin]

спасибо Вам большое! Появились идеи, буду работать.

[Alexey.Kuzmin]

Сделали так:

1. Определяем список экземпляров, запущенных на сервере, возвращается:
{"inst": [{"{#INST_NAME}": "ONIXDB"},{"{#INST_NAME}": "akdb"}]}

2. Получаем информацию о каждом экземпляре через UserParameter:
UserParameter=dbinfo[*],/etc/zabbix/zabbix_agentd_alt.d/dbinfo.sh $1
На сервере он прописан ItemPrototype, как
dbinfo[{#INST_NAME},--json]

Никакие данные на сервер не приходят.
Хотя, тесты работают:
zabbix_agentd -c /u01/zabbix_agentd_alt.conf -t dbinfo[ONIXDB]
dbinfo[ONIXDB] [t|{"dbinfo": [ {"inst[ONIXDB,name]}": "ONIXDB"} ]}]

Что я делаю не так?
Как найти ошибки в настройках?
В логе агента не нашёл каких-то явных ошибок.

[Semiadmin]

Что я делаю не так?
Как найти ошибки в настройках?
В логе агента не нашёл каких-то явных ошибок.

Насколько я понимаю, неправильный с точки зрения Заббикса json.
В начале вместо "inst": д.б. "data":

[Alexey.Kuzmin]

По-порядку:
1. UserParameter=inst,.....
2. Discovery rule - inst
3. Возвращаемый массив должен быть:
{"data": [{"{#INST_NAME}": ONIXDB},{"{#INST_NAME}": akdb}]}
- да?

[Semiadmin]

Да, только на сей раз нет кавычек у найденных имен инстансов.

[Alexey.Kuzmin]

. .

[Kos]

2. Получаем информацию о каждом экземпляре через UserParameter:

UserParameter=dbinfo[*],/etc/zabbix/zabbix_agentd_alt.d/dbinfo.sh $1

На сервере он прописан ItemPrototype, как

dbinfo[{#INST_NAME},--json]

Судя по прототипу, скрипту передаются два параметра. Но в конфиге, где прописан UserParameter, ему передаётся только первый.

Хотя, тесты работают:

zabbix_agentd -c /u01/zabbix_agentd_alt.conf -t dbinfo[ONIXDB]
dbinfo[ONIXDB] [t|{"dbinfo": [ {"inst[ONIXDB,name]}": "ONIXDB"} ]}]

Не очень понятно, какого ответа Вы ожидаете. Я обычно проверяю командой zabbix_get со стороны Zabbix-сервера.

[Alexey.Kuzmin]

Спасибо большое!
Я думал, правильно ставить запятую:
dbinfo[{#INST_NAME}, --json]

Работает нормально без неё:
dbinfo[{#INST_NAME} --json]

Находит две БД и по каждой БД собирает информацию.

Спасибо!

[Alexey.Kuzmin]

Теперь ситуация такая:
1.Item prototype:
Name {#INST_NAME} dbinfo
Prototype: dbinfo[{#INST_NAME} --json]
2. Массивы данных получаются для каждой БД:
{"dbinfo{akdb}": {"instname": "akdb"} }
{"dbinfo{ONIXDB}": {"instname": "ONIXDB"} }

Как теперь создать item с instname?
Делаю так:
Key: inst[{#INST_NAME},name]
Preprocessing: $.dbinfo{"{#INST_NAME}"}.instname

Что-то делаю не так: не заполнятся items.

Уже сломал голову :-(

[Kos]

Сдаётся мне, что-то Вы недоговариваете...

Сейчас протру свой хрустальный шар и попробую в него заглянуть

Так, судя по упоминанию препроцессинга, похоже, что у Вас Zabbix v3.4.

Далее, видимо, Вы пытаетесь использовать dependent items.

При этом всё это совмещаете в правилах LLD.

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

Дальше мой хрустальный шар меркнет, становится трудно разобрать.
Смутно видится, что в прототипах одних LLD используются макросы, которых в данном правиле LLD просто нет; но в этом я уже не уверен. Ещё смутно кажется, что само правило обнаружения возвращает JSON не в том формате, как это ожидается для LLD (где должен иметься один элемент "data" с массивом пар "макрос"="значение"); и эту проблему Вы пытаетесь решить с помощью препроцессинга.
Но на этом, к сожалению, мои телепатические способности ограничиваются

Возможно, я не прав; но тогда распишите, пожалуйста, подробнее свои правила LLD. По каждому из них: как оно определено, пример JSON-а для его работы, как определены прототипы, что работает, а где не работает - что ожидается и что происходит на самом деле.

[Alexey.Kuzmin]

1. Да, Zabbix 3.4.4.
2. Да, есть один массив, который получается с агента:
dbinfo[{#INST_NAME} --json] - Text
Пример: {"dbinfo[akdb]": {"instname": "akdb" }}
3. Зависимый элемент:
inst[name]
Key: instname[{#INST_NAME}]
Master Item: {#INST_NAME} dbinfo: dbinfo[{#INST_NAME} --json]
(массив и п.2)
Preproccessing: JSON Path $.dbinfo.instname
Тут есть неуверенность. Наверное, надо писать
$.dbinfo[akdb].instname,
но тогда нужно использовать макрос (он на этом этапе уже
определён?)
4. lld, key - inst:
UserParameter=inst,/etc/zabbix/zabbix_agentd_alt.d/inst.sh
возвращает
{"data": [{"{#INST_NAME}": "ONIXDB"},{"{#INST_NAME}": "akdb"}]}

Где-то есть ошибка, и я не могу её понять...