Table of Contents
12 Descubrimiento usando 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 del elemento
Las consultas SQL se realizan utilizando un tipo de elemento "Monitor de base de datos". Por lo tanto, la mayoría de las instrucciones en la página de supervisión ODBC se aplican para obtener una regla de descubrimiento "Monitor de base de datos" funcional.
Se pueden utilizar dos claves de elemento en las reglas de descubrimiento "Monitor de base de datos":
db.odbc.discovery[<descripción corta única>,<dsn>,<cadena de conexión>]: este elemento transforma el resultado de la consulta SQL en un array JSON, convirtiendo los nombres de las columnas del resultado de la consulta en nombres de macros de bajo nivel emparejados con los valores de los campos descubiertos. Estas macros pueden utilizarse para crear prototipos de elementos, disparadores, etc. Consulte también: Uso de db.odbc.discovery.
db.odbc.get[<descripción corta única>,<dsn>,<cadena de conexión>]: este elemento transforma el resultado de la consulta SQL en un array JSON, manteniendo los nombres originales de las columnas del resultado de la consulta como nombre de campo en JSON emparejado con los valores descubiertos. En comparación con
db.odbc.discovery[], este elemento no crea macros de bajo nivel en el JSON devuelto, por lo que no es necesario comprobar si los nombres de las columnas pueden ser nombres de macro válidos. Las macros de bajo nivel pueden definirse como un paso adicional si es necesario, utilizando la funcionalidad de macro LLD personalizada con JSONPath apuntando a los valores descubiertos en el JSON devuelto. Consulte también: Uso de db.odbc.get.
Uso de db.odbc.discovery
El siguiente ejemplo demuestra cómo una consulta SQL se transforma en JSON utilizando el descubrimiento de bajo nivel de proxies de Zabbix, basado en una consulta ODBC en la base de datos de Zabbix. Esto es útil para la creación automática de items internos "zabbix[proxy,<name>,lastaccess]" para monitorizar qué proxies están activos.
Comience con la configuración de la regla de descubrimiento:
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 hosts que están monitorizando. El número de hosts puede utilizarse, 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 item "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 un nombre de columna se transformaría 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 soportada, con el mensaje de error detallando el número de columna que causa el problema. Si se desea ayuda adicional, los nombres de columna obtenidos se proporcionan con DebugLevel=4 en el archivo de log 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 una consulta SQL se transforma en un objeto JSON, podemos utilizar la macro {#HOST} en los prototipos de item:
Una vez realizado el descubrimiento, se creará un item para cada proxy:
Usando 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 de descubrimiento de bajo nivel personalizadas en la pestaña Macros de LLD de una regla de descubrimiento usando JSONPath, por ejemplo:
Ahora este macro {#HOST} puede usarse en prototipos de ítem:
