Áú»¢¶Ä²©

11 Descoberta usando consultas ODBC SQL

Vis?o geral

Este tipo de baixo n¨ªvel discovery ¨¦ feito usando SQL consultas, cujos resultados s?o transformados automaticamente em um objeto JSON adequado para descoberta de baixo n¨ªvel.

Chave do item

As consultas SQL s?o executadas usando um tipo de item "Monitor de banco de dados". Portanto, a maioria das instru??es sobre ODBC monitoramento se aplicam em para obter uma regra de descoberta "Monitor de banco de dados" funcional.

Duas chaves de item podem ser usadas nas regras de descoberta do "Monitor de banco de dados":

• db.odbc.discovery[<curto exclusivo descri??o>,<dsn>,<string de conex?o>] - este item transforma o resultado da consulta SQL em um array JSON, tornando o nomes de coluna do resultado da consulta na macro de descoberta de baixo n¨ªvel nomes emparelhados com os valores de campo descobertos. Essas macros podem ser usado na cria??o de prot¨®tipos de itens, gatilhos, etc. Veja tamb¨¦m: Usando db.odbc.discovery.

• db.odbc.get[<curto exclusivo descri??o>,<dsn>,<string de conex?o>] - este item transforma o resultado da consulta SQL em um array JSON, mantendo a nomes de colunas originais do resultado da consulta como um nome de campo em JSON emparelhado com os valores descobertos. Comparado com db.odbc.discovery[], este item n?o cria uma descoberta de baixo n¨ªvel macros no JSON retornado, portanto, n?o h¨¢ necessidade de verificar se os nomes das colunas podem ser nomes de macros v¨¢lidos. A descoberta de baixo n¨ªvel macros podem ser definidas como uma etapa adicional conforme necess¨¢rio, usando o LD personalizado macro funcionalidade com JSONPath apontando para os valores descobertos no retornou JSON. Veja tamb¨¦m: Usando db.odbc.get.

Usando db.odbc.discovery

Como exemplo pr¨¢tico para ilustrar como a consulta SQL ¨¦ transformada em JSON, vamos considerar a descoberta de baixo n¨ªvel de proxies Áú»¢¶Ä²© por realizando uma consulta ODBC no banco de dados Áú»¢¶Ä²©. Isso ¨¦ ¨²til para cria??o autom¨¢tica de "zabbix[proxy,<name>,lastaccess]" itens internos para monitorar quais proxies est?o vivos.

Vamos come?ar com a configura??o da regra de descoberta:

Todos os campos de entrada obrigat¨®rios est?o marcados com um asterisco vermelho.

Aqui, a seguinte consulta direta no banco de dados Áú»¢¶Ä²© ¨¦ usada para selecionar todos os proxies Áú»¢¶Ä²©, juntamente com o n¨²mero de hosts que eles s?o monitoramento. O n¨²mero de hosts pode ser usado, por exemplo, para filtrar proxies vazios:

mysql> SELECT h1.host, COUNT(h2.host) AS count FROM hosts h1 LEFT JOIN hosts h2 ON h1.hostid = h2.proxy_hostid WHERE h1.status IN (5, 6) GROUP BY h1.host;
       +---------+-------+
       | anfitri?o | contar |
       +---------+-------+
       | Jap?o 1 | 5 |
       | Jap?o 2 | 12 |
       | Let?nia | 3 |
       +---------+-------+
       3 linhas em conjunto (0,01 seg)

Pelo funcionamento interno do item "db.odbc.discovery[,{$DSN}]", o resultado desta consulta ¨¦ transformado automaticamente no seguinte JSON:

[
           {
               "{#HOST}": "Jap?o 1",
               "{#COUNT}": "5"
           },
           {
               "{#HOST}": "Jap?o 2",
               "{#COUNT}": "12"
           },
           {
               "{#HOST}": "Let?nia",
               "{#COUNT}": "3"
           }
       ]

Pode-se ver que os nomes das colunas se tornam nomes de macros e linhas selecionadas tornam-se os valores dessas macros.

$ grep db.odbc.discovery /tmp/zabbix_server.log
        ...
        23876:20150114:153410.856 Na consulta db_odbc_discovery():'SELECT h1.host, COUNT(h2.host) FROM hosts h1 LEFT JOIN hosts h2 ON h1.hostid = h2.proxy_hostid WHERE h1.status IN (5, 6) GROUP BY h1.host;'
        23876:20150114:153410.860 db_odbc_discovery() coluna[1]:'host'
        23876:20150114:153410.860 db_odbc_discovery() coluna[2]:'COUNT(h2.host)'
        23876:20150114:153410.860 Fim de db_odbc_discovery():NOTSUPPORTED
        23876:20150114:153410.860 Item [Áú»¢¶Ä²© server:db.odbc.discovery[proxies,{$DSN}]] erro: N?o ¨¦ poss¨ªvel converter o nome da coluna n? 2 em macro.

Agora que entendemos como uma consulta SQL ¨¦ transformada em um JSON objeto, podemos usar a macro {#HOST} em prot¨®tipos de itens:

Depois que a descoberta for realizada, um item ser¨¢ criado para cada proxy:

Usando db.odbc.get

Usando db.odbc.get[,{$DSN}] e o seguinte exemplo SQL:

mysql> SELECT h1.host, COUNT(h2.host) AS count FROM hosts h1 LEFT JOIN hosts h2 ON h1.hostid = h2.proxy_hostid WHERE h1.status IN (5, 6) GROUP BY h1.host;
       +---------+-------+
       | anfitri?o | contar |
       +---------+-------+
       | Jap?o 1 | 5 |
       | Jap?o 2 | 12 |
       | Let?nia | 3 |
       +---------+-------+
       3 linhas em conjunto (0,01 seg)

este JSON ser¨¢ retornado:

[
           {
               "host": "Jap?o 1",
               "contar": "5"
           },
           {
               "host": "Jap?o 2",
               "contar": "12"
           },
           {
               "host": "Let?nia",
               "contar": "3"
           }
       ]

Como voc¨º pode ver, n?o h¨¢ macros de descoberta de baixo n¨ªvel. No entanto, macros de descoberta de baixo n¨ªvel personalizadas podem ser criadas no LLD macros de um regra de descoberta usando JSONPath, por exemplo:

{#HOST} ¡ú $.host

Agora esta macro {#HOST} pode ser usada em prot¨®tipos de itens: