12 ODBC SQLクエリを使用した検出

概要

このタイプのローレベルディスカバリはSQLクエリで実行され、その結果はローレベルディスカバリに適したJSONオブジェクトに自動的に変換されます。

アイテムキー

SQLクエリは"データベースモニター"アイテムタイプを使用して実行されます。 したがってODBC監視ページのほとんどの手順は、機能する"データベースモニター"ディスカバリルールを取得するために適用されます。

"データベースモニター"ディスカバリルールでは、次の2つのアイテムキーを使用できます。

  • db.odbc.discovery[<unique short description>,<dsn>,<connection string>] - このアイテムは、SQLクエリ結果をJSON配列に変換し、クエリ結果の列名を検出されたフィールド値とペアになったローレベルディスカバリマクロ名に変換します。 これらのマクロは、アイテム、トリガーなどのプロトタイプの作成に使用できます。 参照: db.odbc.discoveryの使用。

  • db.odbc.get[<unique short description>,<dsn>,<connection string>] - このアイテムは、SQLクエリ結果をJSON配列に変換し、クエリ結果の元の列名を、検出された値とペアになったJSONのフィールド名として保持します。db.odbc.discovery[]と比較すると、このアイテムは返されたJSONにローレベルディスカバリマクロを作成しないため、列名が有効なマクロ名であるかどうかを確認する必要はありません。 ローレベルディスカバリマクロは、必要に応じて追加のステップとして定義できます。カスタムLLDマクロ機能を使用して、返されるJSONで検出された値を指すJSONPathを使用します。参照: using db.odbc.getの使用。

db.odbc.discovery の使用

次の例では、Zabbixデータベースに対する ODBC クエリに基づき、Zabbixプロキシのローレベルディスカバリを使用して、SQL クエリがどのように JSON に変換されるかを示します。 これは、どのプロキシが稼働しているかを監視するための "zabbix[proxy,<name>,lastaccess]" 内部アイテム を自動作成するのに役立ちます。

まず、ディスカバリルールの設定から始めます。

lld\_rule\_odbc.png

必須の入力フィールドには、赤いアスタリスクが付いています。

ここでは、Zabbixデータベースに対する次の直接クエリを使用して、すべてのZabbixプロキシと、それぞれが監視しているホスト数を選択しています。 ホスト数は、たとえば空のプロキシを除外するためのフィルタリングに使用できます。

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)

"db.odbc.discovery[,{$DSN}]" アイテムの内部動作により、このクエリの結果は自動的に次の JSON に変換されます。

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

列名がマクロ名になり、選択された行がそれらのマクロの値になることがわかります。

列名がどのようにマクロ名へ変換されるかが明確でない場合は、上記の例の "COUNT(h2.host) AS count" のように列エイリアスを使用することを推奨します。

列名を有効なマクロ名に変換できない場合、ディスカバリルールは未サポートとなり、エラーメッセージに問題のある列番号が表示されます。 さらに情報が必要な場合は、取得された列名が Zabbixサーバーのログファイルに DebugLevel=4 で出力されます。

$ 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.

これで SQL クエリがどのように JSON オブジェクトへ変換されるかを理解できたので、アイテムのプロトタイプで {#HOST} マクロを使用できます。

item\_prototype\_odbc.png

ディスカバリが実行されると、各プロキシに対してアイテムが作成されます。

discovered\_items\_odbc1.png

db.odbc.getを使用する

db.odbc.get[,{$DSN}]と次の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 |
+---------+-------+
| Japan 1 |     5 |
| Japan 2 |    12 |
| Latvia  |     3 |
+---------+-------+
3 rows in set (0.01 sec)

このJSONが返されます：

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

ご覧のとおりそこにはローレベルディスカバリマクロはありません。 ただしカスタムのローレベルディスカバリマクロは、JSONPathを使用してディスカバリルールのLLDマクロタブで作成できます。次に例を示します。

{#HOST} → $.host

これで、この{#HOST}マクロをアイテムのプロトタイプで使用できるようになりました。

item\_prototype\_odbc.png