12 Descubrimiento mediante consultas SQL ODBC

Descripción general

Este tipo de descubrimiento de bajo nivel se realiza mediante consultas SQL, cuyos resultados se transforman automáticamente en un objeto JSON adecuado para el descubrimiento de bajo nivel.

Clave de item

Las consultas SQL se realizan mediante un tipo de item "Database monitor". Por lo tanto, la mayoría de las instrucciones de la página monitorización ODBC se aplican para obtener una regla de descubrimiento "Database monitor" funcional.

Se pueden usar dos claves de item en las reglas de descubrimiento "Database monitor":

  • db.odbc.discovery[<descripción corta única>,<dsn>,<cadena de conexión>] - este item transforma el resultado de la consulta SQL en un array JSON, convirtiendo los nombres de columna del resultado de la consulta en nombres de macros de descubrimiento de bajo nivel emparejados con los valores de los campos descubiertos. Estas macros pueden utilizarse para crear prototipos de item, trigger, etc. Véase también: Uso de db.odbc.discovery.

  • db.odbc.get[<descripción corta única>,<dsn>,<cadena de conexión>] - este item transforma el resultado de la consulta SQL en un array JSON, conservando los nombres de columna originales del resultado de la consulta como nombres de campo en JSON emparejados con los valores descubiertos. En comparación con db.odbc.discovery[], este item no crea macros de descubrimiento de bajo nivel en el JSON devuelto, por lo tanto no es necesario comprobar si los nombres de columna pueden ser nombres de macro válidos. Las macros de descubrimiento de bajo nivel pueden definirse como un paso adicional según sea necesario, utilizando la funcionalidad de macro LLD personalizada con JSONPath que apunte a los valores descubiertos en el JSON devuelto. Véase también: Uso de db.odbc.get.

Uso de db.odbc.discovery

Como ejemplo práctico para ilustrar cómo la consulta SQL se transforma en JSON, consideremos el descubrimiento de bajo nivel de proxies de Zabbix realizando una consulta ODBC en la base de datos de Zabbix. Esto es útil para la creación automática de elementos internos "zabbix[proxy,<nombre>,lastaccess]" para monitorizar qué proxies están activos.

Comencemos con la configuración de la regla de descubrimiento:

lld\_rule\_odbc.png

Todos los campos obligatorios están marcados con un asterisco rojo.

Aquí, se utiliza la siguiente consulta directa en la base de datos de Zabbix para seleccionar todos los proxies de Zabbix, junto con el número de equipos que están monitorizando. El número de equipos puede usarse, por ejemplo, para filtrar proxies vacíos:

mysql> SELECT h1.host, COUNT(h2.host) AS count FROM hosts h1 LEFT JOIN hosts h2 ON h1.hostid = h2.proxyid WHERE h1.status IN (5, 6) GROUP BY h1.host;
+---------+-------+
| host    | count |
+---------+-------+
| Japan 1 |     5 |
| Japan 2 |    12 |
| Latvia  |     3 |
+---------+-------+
3 rows in set (0.01 sec)

Por el funcionamiento interno del elemento "db.odbc.discovery[,{$DSN}]", el resultado de esta consulta se transforma automáticamente en el siguiente JSON:

[
    {
        "{#HOST}": "Japan 1",
        "{#COUNT}": "5"
    },
    {
        "{#HOST}": "Japan 2",
        "{#COUNT}": "12"
    },
    {
        "{#HOST}": "Latvia",
        "{#COUNT}": "3"
    }
]

Se puede observar que los nombres de las columnas se convierten en nombres de macro y las filas seleccionadas se convierten en los valores de estas macros.

Si no es obvio cómo se transformará un nombre de columna en un nombre de macro, se recomienda utilizar alias de columna como "COUNT(h2.host) AS count" en el ejemplo anterior.

En caso de que un nombre de columna no pueda convertirse en un nombre de macro válido, la regla de descubrimiento pasa a no estar soportada, mostrando un mensaje de error que detalla el número de columna problemático. Si se desea ayuda adicional, los nombres de las columnas obtenidas se proporcionan con DebugLevel=4 en el archivo de registro del servidor Zabbix:

$ grep db.odbc.discovery /tmp/zabbix_server.log
 ...
 23876:20150114:153410.856 In db_odbc_discovery() query:'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() column[1]:'host'
 23876:20150114:153410.860 db_odbc_discovery() column[2]:'COUNT(h2.host)'
 23876:20150114:153410.860 End of db_odbc_discovery():NOTSUPPORTED
 23876:20150114:153410.860 Item [Zabbix server:db.odbc.discovery[proxies,{$DSN}]] error: Cannot convert column #2 name to macro.

Ahora que entendemos cómo se transforma una consulta SQL en un objeto JSON, podemos usar la macro {#HOST} en prototipos de elementos:

item\_prototype\_odbc.png

Una vez realizado el descubrimiento, se creará un elemento para cada proxy:

discovered\_items\_odbc1.png

Uso de db.odbc.get

Usando db.odbc.get[,{$DSN}] y el siguiente ejemplo de SQL:

mysql> SELECT h1.host, COUNT(h2.host) AS count FROM hosts h1 LEFT JOIN hosts h2 ON h1.hostid = h2.proxyid WHERE h1.status IN (5, 6) GROUP BY h1.host;
+---------+-------+
| host    | count |
+---------+-------+
| Japan 1 |     5 |
| Japan 2 |    12 |
| Latvia  |     3 |
+---------+-------+
3 rows in set (0.01 sec)

se devolverá este JSON:

[
    {
        "host": "Japan 1",
        "count": "5"
    },
    {
        "host": "Japan 2",
        "count": "12"
    },
    {
        "host": "Latvia",
        "count": "3"
    }
]

Como puede ver, no hay macros de descubrimiento de bajo nivel allí. Sin embargo, se pueden crear macros personalizadas de descubrimiento de bajo nivel en la pestaña Macros LLD de una regla de descubrimiento usando JSONPath, por ejemplo:

{#HOST} → $.host

Ahora esta macro {#HOST} puede usarse en prototipos de item:

item\_prototype\_odbc.png