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

概要

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

アイテムキー

SQLクエリは、「Database monitor」アイテムタイプを使用して実行されます。
そのため、動作する「Database monitor」ディスカバリルールを作成するには、ODBC監視ページの手順のほとんどが適用されます。

「Database monitor」ディスカバリルールでは、次の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内に低レベルディスカバリマクロを作成しないため、列名が有効なマクロ名になり得るかどうかを確認する必要はありません。
    低レベルディスカバリマクロは、必要に応じて追加の手順として定義できます。返されたJSON内の検出済み値を指すJSONPathを使用して、カスタムLLDマクロ機能を利用します。
    参照: db.odbc.getの使用。

db.odbc.discovery の使用

SQLクエリがどのようにJSONに変換されるかを示す実用的な例として、Zabbixデータベースに対してODBCクエリを実行し、Zabbixプロキシのローレベルディスカバリを考えてみましょう。
これは、どのプロキシが稼働しているかを監視するための "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

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

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

この JSON が返されます。

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

ご覧のとおり、low-level discovery マクロは含まれていません。 ただし、JSONPath を使用して、discovery rule の LLD macros タブでカスタム low-level discovery マクロを作成できます。たとえば、次のようにします。

{#HOST} → $.host

これで、この {#HOST} マクロをアイテムプロトタイプで使用できます。

item\_prototype\_odbc.png