This is a translation of the original English documentation page. Help us make it better.

11 ODBCSQLクエリを使用した検出

概要

このタイプのローレベルディスカバリは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を使用する

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

"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