Este tipo de descubrimiento de bajo nivel se realiza usando consultas SQL, cuyos resultados se transforman autom¨¢ticamente en un objeto JSON adecuado para descubrimiento de bajo nivel.
Las consultas SQL se realizan utilizando un tipo de m¨¦trica "Monitor de base de datos". Por lo tanto, la mayor¨ªa de las instrucciones en la p¨¢gina monitoreo ODBC se aplican para obtener una regla de descubrimiento de "Monitor de base de datos" que funcione.
Se pueden utilizar dos claves de m¨¦tricas en las reglas de descubrimiento del "monitor de base de datos":
db.odbc.discovery[<descripci¨®n ¨²nica corta>,<dsn>,<cadena de conexi¨®n>] - esta m¨¦trica transforma el resultado de la consulta SQL en una matriz JSON, convirtiendo los nombres de columnas del resultado de la consulta en una macro de descubrimiento de bajo nivel con los nombres emparejados con los valores de campo descubiertos. Estas macros pueden ser utilizadas para crear prototipos de m¨¦tricas, iniciadores, etc. Ver tambi¨¦n: Usando db.odbc.discovery.
db.odbc.get[<descripci¨®n corta ¨²nica>,<dsn>,<cadena de conexi¨®n>] - esta m¨¦trica transforma el resultado de la consulta SQL en una matriz JSON, manteniendo los nombres de columnas originales del resultado de la consulta como nombre de campo en JSON emparejado con los valores descubiertos. En comparaci¨®n con db.odbc.discovery[]
, esta m¨¦trica no crea macros de descubrimiento de bajo nivel en el JSON devuelto, por lo tanto no es necesario comprobar si los nombres de las columnas pueden ser nombres de macro v¨¢lidos. Las macros de descubrimiento de bajo nivel se pueden definir como un paso adicional seg¨²n sea necesario, utilizando la funcionalidad macro LLD personalizada con JSONPath apuntando a los valores descubiertos en el JSON devuelto. Consulte tambi¨¦n: Usando db.odbc.get.
Como ejemplo pr¨¢ctico para ilustrar c¨®mo se transforma la consulta SQL. en JSON, consideremos el descubrimiento de bajo nivel de proxies Áú»¢¶Ä²© mediante la ejecuci¨®n de una consulta ODBC en la base de datos Áú»¢¶Ä²©. Esto es ¨²til para la creaci¨®n autom¨¢tica de las m¨¦tricas internas "zabbix[proxy,<nombre>,lastaccess]" para monitorear qu¨¦ proxies est¨¢n vivos.
Comencemos con la configuraci¨®n de la regla de descubrimiento:
Todos los campos de entrada obligatorios est¨¢n marcados con un asterisco rojo.
Aqu¨ª, se utiliza la siguiente consulta directa en la base de datos Áú»¢¶Ä²© para seleccionar todos los proxies de Áú»¢¶Ä²©, junto con el n¨²mero de equipos que se supervisan. El n¨²mero de equipos se puede utilizar, por ejemplo, para filtrar servidores proxy vac¨ªos:
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;
+---------+-------+
| host | count |
+---------+-------+
| Jap¨®n 1 | 5 |
| Jap¨®n 2 | 12 |
| Letonia | 3 |
+---------+-------+
3 filas en conjunto (0,01 seg)
Por el funcionamiento interno de la m¨¦trica "db.odbc.discovery[,{$DSN}]", el resultado de esta consulta se transforma autom¨¢ticamente en el siguiente JSON:
[
{
"{#HOST}": "Jap¨®n 1",
"{#COUNT}": "5"
},
{
"{#HOST}": "Jap¨®n 2",
"{#COUNT}": "12"
},
{
"{#HOST}": "Letonia",
"{#COUNT}": "3"
}
]
Se puede ver que los nombres de las columnas se convierten en nombres de macros y las filas seleccionadas. se convierten en los valores de estas macros.
Si no es obvio c¨®mo se transformar¨ªa el nombre de una columna en un nombre de macro, se sugiere utilizar alias de columna como "COUNT(h2.host) AS count" en el ejemplo anterior.
En caso de que un nombre de columna no se pueda convertir en un nombre de macro v¨¢lido, la regla de descubrimiento deja de ser compatible y el mensaje de error detalla el n¨²mero de columna infractor. Si se desea ayuda adicional, los nombres de las columnas se proporcionan en DebugLevel=4 en el archivo de registro del servidor Áú»¢¶Ä²©:
$ grep db.odbc.discovery /tmp/zabbix_server.log
...
23876:20150114:153410.856 En la 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 EN (5, 6) GROUP BY h1.host;'
23876:20150114:153410.860 columna db_odbc_discovery()[1]:'host'
23876:20150114:153410.860 columna db_odbc_discovery()[2]:'COUNT(h2.host)'
23876:20150114:153410.860 Fin de db_odbc_discovery():NOTSUPPORTED
23876:20150114:153410.860 Error del elemento [servidor Áú»¢¶Ä²©:db.odbc.discovery[proxies,{$DSN}]]: no se puede convertir el nombre de la columna n.? 2 en macro.
Ahora que entendemos c¨®mo se transforma una consulta SQL en un objeto JSON, podemos usar la macro {#HOST} en prototipos de m¨¦tricas:
Una vez realizado el descubrimiento, se crear¨¢ una m¨¦trica para cada proxy:
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.proxy_hostid WHERE h1.status IN (5, 6) GROUP BY h1.host;
+---------+-------+
| host | count |
+---------+-------+
| Jap¨®n 1 | 5 |
| Jap¨®n 2 | 12 |
| Letonia | 3 |
+---------+-------+
3 filas en conjunto (0,01 seg)
se devolver¨¢ este JSON:
[
{
"host": "Jap¨®n 1",
"count": "5"
},
{
"host": "Jap¨®n 2",
"count": "12"
},
{
"host": "Letonia",
"count": "3"
}
]
Como puede ver, all¨ª no hay macros de descubrimiento de bajo nivel. Sin embargo, se pueden crear macros de descubrimiento personalizadas de bajo nivel en la pesta?a de macros LLD de una regla de descubrimiento usando JSONPath, por ejemplo:
Ahora esta macro {#HOST} se puede utilizar en prototipos de m¨¦tricas: