MIRACLE ZBX の保存前処理を使ってみる

これまで筆者は、MIRACLE ZBX の比較的新しいバージョンに追加実装された機能を使用することなく過ごしていました。これではいけない！と思い立ち、今回は保存前処理 (Item Value Preprocessing) にフォーカスして実際に使用してみることにしました。MIRACLE ZBX のバージョンは 5.0.11 です。
実装は過去の記事『Zabbix 3.2 以降の新機能解説（Zabbix 4.0 を見据えて） その 21 - 保存前処理、依存アイテムの設定と処理、ソースコード解説 』に詳しく記載されています。気になった方はそちらを参照してください。

目次

• Ubuntu のバージョン情報を取得する (Agent 経由 )
• Linux のメモリの状態を取得する (SSH 経由 )
• Linux のネットワーク通信状態を取得する (SSH 経由 )
• Linux のネットワーク通信状態を取得する (SSH 経由 , コマンド ip の -j オプションを利用 )

Ubuntu のバージョン情報を取得する (Agent 経由 )

筆者はバージョン名とコードネームとの関係を度忘れして往生することがあります。そのような ( 下らない ) 理由で /etc/os-release から低頻度で情報を収集し、Web Frontend 上で確認できるようにするところから手を付けることにしました。

/etc/os-release

NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

上記ファイルの内容を 1 日 1 回取得し、保存前処理の正規表現を使用して複数のアイテムにデータを格納する形態とします。

まずは元となるアイテムを作成します。正常に動作することが確認できるまでは「ヒストリの保存期間」に短めの日数を設定しても良いと思います。

図 1: 元アイテム 設定例

次に、データを格納するアイテムを作成します。まず、タブ「アイテム」に次の情報を入力します。マスターアイテムには、上記設定例では「os-release」としたアイテムを指定します。入力完了後、ボタン「追加」を押さずにタブ「保存前処理」に移動します。

図 2: 依存アイテム 設定例

「追加」をクリックし、次の情報を入力します。パラメータ内の「()」内の正規表現にマッチしたデータの順番を、最後のテキストボックスに対してバックスラッシュ（\）に添えて入力します。今回はパラメータ内に 1 つだけ用意してあるので、「\1」しか選べませんが。

その後、ボタン「追加」をクリックします。

図 3: 依存アイテム 保存前処理 設定例

他にもアイテムを追加していきます。なお、任意の文字列を指定できる箇所に対しては、設定例を記入しました。

依存アイテム 2 つ目

依存アイテム 2 つ目 保存前処理

依存アイテム 3 つ目

依存アイテム 3 つ目 保存前処理

依存アイテム 3 つ目は、VERSION_CODENAME, UBUNTU_CODENAME のいずれが正しいか筆者には判断がつかなかったため、どちらか一方でも元データにあればデータとして取得できるように記述しました。
以上のように設定することで、下図のようにデータを収集することができました。

図 4: データ収集例 (Ubuntu 20.04.2 LTS)

図 5: データ収集例 (Ubuntu 21.04)

Linux のメモリの状態を取得する (SSH 経由 )

前章では、1 つのテキストファイルに含まれたデータから、同時に複数のアイテムに対して必要とする情報を簡単に収集させることができました。これを前提に考えると、割と簡単にメモリの監視を SSH 経由で実行できるはずです。
今度は /proc/meminfo を読み込むアイテムを作成し、それに対する依存アイテム群を追加します。同ファイルは行数が多いため、引用は割愛します。収集頻度は 10 分毎とし、変動する可能性の小さい項目については保存データ削減の観点から 1 日 1 回のみ収集するように設定します。

元アイテム 1 つ目

/usr/bin/cat /proc/meminfo

元アイテム 2 つ目 (1 つ目と異なる部分だけ抜粋 )

SSH 監視を行う際の注意点

次に、依存アイテム群を作成します。以下、いずれも設定例です。

依存アイテム 1 つ目

依存アイテム 1 つ目 保存前処理

依存アイテム 2 つ目

依存アイテム 2 つ目 保存前処理

依存アイテム 3 つ目

依存アイテム 3 つ目 保存前処理

依存アイテム 4 つ目

依存アイテム 4 つ目 保存前処理

これらの設定を Ubuntu 20.04, MIRACLE LINUX 8.0 のホストに設定したところ、下図のように正常に監視できるようになりました。
アイテム数が設定例より多いのですが、これは筆者に必要があって追加設定した結果です。HugePage size, HugePages Total は meminfo (interval:24h) を、HugePages Free, HugePage size, HugePages Rsvd, HugePages Surp は meminfo をマスターアイテムとしています。

図 6: メモリ関連データ収集例

過去のバージョンでは各アイテムの収集時、個別に SSH で接続する必要がありました。その頃と比較すると隔世の感を覚えます。

Linux のネットワーク通信状態を取得する (SSH 経由 )

保存前処理は正規表現にとどまらず、他にも様々な機能を有しています。今度はコマンド実行結果を利用したローレベルディスカバリ、JSON による監視データの纏め取得を設定してみます。
まず、纏め取得を行うための元アイテムを作成します。今回はコマンド ip -s link show の結果をコマンド awk で JSON に加工する方法を採りました。
コマンド awk を選択したのは、どの環境でも大抵は利用可能と考えられるからです。冗長になっているのは可読性を上げるため ... と、筆者がパズルを苦手としているからです ( お恥ずかしい )。
もちろん /proc/net/dev を JSON に加工して JSONPath を利用する方法、テキストをそのまま取得して正規表現を利用する方法、またはコマンド ip の実行結果を JSON で得る方法 ( 後述します ) も採りうると思います。

元アイテム

/usr/sbin/ip -s link show | /usr/bin/awk '
BEGIN {print "["}
{
    if ($1 ~ /^[0-9]+:$/)
    {
        if ($1 != "1:")
        {
            print "    ,"
        }
        sub(/.$/,"",$1); print "    {\n        \"id\":\""$1"\","
        sub(/.$/,"",$2); print "        \"device\":\""$2"\","
        rxline = NR + 3; 
        txline = NR + 5 
    }
    {
        if (NR == rxline)
        {
            print \
            "        \"rx_bytes\":"$1\
            ",\n        \"rx_packets\":"$2\
            ",\n        \"rx_errors\":"$3\
            ",\n        \"rx_dropped\":"$4\
            ",\n        \"rx_overrun\":"$5\
            ",\n        \"rx_mcast\":"$6","
        };
        if (NR == txline)
        {
            print \
            "        \"tx_bytes\":"$1\
            ",\n        \"tx_packets\":"$2\
            ",\n        \"tx_errors\":"$3\
            ",\n        \"tx_dropped\":"$4\
            ",\n        \"tx_overrun\":"$5\
            ",\n        \"tx_mcast\":"$6"\n    }"
        }
    }
} END {print "]"}'

図 7: 元アイテム 設定例

上図設定例では、予め公開鍵ファイル , 秘密鍵ファイルをマクロとして定義しています。
上記「実行するスクリプト」を監視対象で実行すると、次のような結果を得られます。よって上述のアイテムに依存し、保存前処理の JSONPath を利用して値を取得するアイテムを作成すればよい ... のですが、ネットワークデバイス名は環境に依存します。そのためローレベルディスカバリを使用して、自動的にアイテムを作成することにします。

実行するスクリプト の実行結果

[
    {
        "id":"1",
        "device":"lo",
        "rx_bytes":44192,
        "rx_packets":518,
        "rx_errors":0,
        "rx_dropped":0,
        "rx_overrun":0,
        "rx_mcast":0,
        "tx_bytes":44192,
        "tx_packets":518,
        "tx_errors":0,
        "tx_dropped":0,
        "tx_overrun":0,
        "tx_mcast":0
    }
    ,
    {
        "id":"2",
        "device":"eth0",
        "rx_bytes":144131420,
        "rx_packets":193490,
        "rx_errors":0,
        "rx_dropped":0,
        "rx_overrun":0,
        "rx_mcast":52188,
        "tx_bytes":14540616,
        "tx_packets":118865,
        "tx_errors":0,
        "tx_dropped":0,
        "tx_overrun":0,
        "tx_mcast":0
    }
]

次に、ディスカバリルールを作成します。

ディスカバリルール

/usr/sbin/ip link show | /usr/bin/awk '
BEGIN {print "["}
{
    if ($1 ~ /^[0-9]+:/)
    {
        if ($1 != "1:")
        {
            print "    ,";
        }
    	sub(/.$/,"",$2);\
    	print "    {\n        \"{#IFNAME}\":\"" $2 "\"\n    }"
    }
}
END {print "]"}'

図 8: ディスカバリルール 設定例

ディスカバリルールの 実行するスクリプト の実行結果

[
    {
        "{#IFNAME}":"lo"
    }
    ,
    {
        "{#IFNAME}":"eth0"
    }
]

監視対象外のネットワークデバイスに対するアイテムを自動生成しないよう、タブ「フィルター」にも設定が必要です。次の設定例で、lo, virbr0, virbr0-nic を監視対象から外すことが可能となります。

フィルター

図 9: ディスカバリルール フィルター 設定例

続いて、続いてディスカバリルールに対して「アイテムのプロトタイプ」を追加します。

アイテムのプロトタイプ 1 つ目

図 10: ディスカバリルール アイテムのプロトタイプ 設定例

アイテムのプロトタイプ 1 つ目 保存前処理

JSONPath 記述時の注意点

図 11: ディスカバリルール アイテムのプロトタイプ 保存前処理 設定例

以下、相違のある部分のみ抜粋します。

アイテムのプロトタイプ 2 つ目

アイテムのプロトタイプ 2 つ目 保存前処理

アイテムのプロトタイプ 3 つ目

アイテムのプロトタイプ 3 つ目 保存前処理

アイテムのプロトタイプ 4 つ目

アイテムのプロトタイプ 4 つ目 保存前処理

アイテムのプロトタイプ 5 つ目

アイテムのプロトタイプ 5 つ目 保存前処理

アイテムのプロトタイプ 6 つ目

アイテムのプロトタイプ 6 つ目 保存前処理

ディスカバリルールによってアイテムが作成され 2 回以上データが収集されると、下図のように最新データに表示されるようになります。

図 12: ネットワーク関連データ収集例

Linux のネットワーク通信状態を取得する (SSH 経由 , コマンド ip の -j オプションを利用 )

前章ではコマンド ip の実行結果をコマンド awk に渡して JSON 化していましたが、コマンド ip にオプション -j を渡せば JSON 形式で結果を得ることが可能です。

元アイテム

ip -s -j link show

図 13: 元アイテム 設定例

実行するスクリプト の実行結果
(JSON を整形して可読性を上げるため -p オプションを追加 )

$ ip -s -j -p link show
[ {
        "ifindex": 1,
        "ifname": "lo",
        "flags": [ "LOOPBACK","UP","LOWER_UP" ],
        "mtu": 65536,
        "qdisc": "noqueue",
        "operstate": "UNKNOWN",
        "linkmode": "DEFAULT",
        "group": "default",
        "txqlen": 1000,
        "link_type": "loopback",
        "address": "00:00:00:00:00:00",
        "broadcast": "00:00:00:00:00:00",
        "stats64": {
            "rx": {
                "bytes": 8066,
                "packets": 102,
                "errors": 0,
                "dropped": 0,
                "over_errors": 0,
                "multicast": 0
            },
            "tx": {
                "bytes": 8066,
                "packets": 102,
                "errors": 0,
                "dropped": 0,
                "carrier_errors": 0,
                "collisions": 0
            }
        }
    },{
        "ifindex": 2,
        "ifname": "eth0",
        "flags": [ "BROADCAST","MULTICAST","UP","LOWER_UP" ],
        "mtu": 1500,
        "qdisc": "mq",
        "operstate": "UP",
        "linkmode": "DEFAULT",
        "group": "default",
        "txqlen": 1000,
        "link_type": "ether",
        "address": "xx:xx:xx:xx:xx:xx",
        "broadcast": "ff:ff:ff:ff:ff:ff",
        "stats64": {
            "rx": {
                "bytes": 917072,
                "packets": 787,
                "errors": 0,
                "dropped": 0,
                "over_errors": 0,
                "multicast": 249
            },
            "tx": {
                "bytes": 46839,
                "packets": 512,
                "errors": 0,
                "dropped": 0,
                "carrier_errors": 0,
                "collisions": 0
            }
        }
    } ]

次に、ディスカバリルールを作成します。

ディスカバリルール

ip -j link show

図 14: ディスカバリルール 設定例

実行するスクリプト の実行結果
(JSON を整形して可読性を上げるため -p オプションを追加 )

$ ip -j -p link show
[ {
        "ifindex": 1,
        "ifname": "lo",
        "flags": [ "LOOPBACK","UP","LOWER_UP" ],
        "mtu": 65536,
        "qdisc": "noqueue",
        "operstate": "UNKNOWN",
        "linkmode": "DEFAULT",
        "group": "default",
        "txqlen": 1000,
        "link_type": "loopback",
        "address": "00:00:00:00:00:00",
        "broadcast": "00:00:00:00:00:00"
    },{
        "ifindex": 2,
        "ifname": "eth0",
        "flags": [ "BROADCAST","MULTICAST","UP","LOWER_UP" ],
        "mtu": 1500,
        "qdisc": "mq",
        "operstate": "UP",
        "linkmode": "DEFAULT",
        "group": "default",
        "txqlen": 1000,
        "link_type": "ether",
        "address": "xx:xx:xx:xx:xx:xx",
        "broadcast": "ff:ff:ff:ff:ff:ff"
    } ]

監視対象外のネットワークデバイスに対するアイテムを自動生成しないよう、タブ「フィルター」にも設定が必要です。次の設定例で、lo, virbr0, virbr0-nic を監視対象から外すことが可能となります。

フィルター

図 15: ディスカバリルール フィルター 設定例

続いて、続いてディスカバリルールに対して「アイテムのプロトタイプ」を追加します。

アイテムのプロトタイプ 1 つ目

図 16: ディスカバリルール アイテムのプロトタイプ 設定例

前章とは異なり、構造化された JSON を対象として JSONPath を設定することになります。元アイテムの「実行するスクリプト の実行結果」と突き合わせて確認してください。
キー ifname が {#IFNAME} と一致する対象から、stats64 の下の tx の下の errors の値を数値として抜きだす必要があります。そのため、保存処理前の JSONPath にはこれらを . で繋いだ結果で指定することになります。

アイテムのプロトタイプ 1 つ目 保存前処理

図 17: ディスカバリルール アイテムのプロトタイプ 保存前処理 設定例

以下、相違のある部分のみ抜粋します。

アイテムのプロトタイプ 2 つ目

アイテムのプロトタイプ 2 つ目 保存前処理

アイテムのプロトタイプ 3 つ目

アイテムのプロトタイプ 3 つ目 保存前処理

アイテムのプロトタイプ 4 つ目

アイテムのプロトタイプ 4 つ目 保存前処理

アイテムのプロトタイプ 5 つ目

アイテムのプロトタイプ 5 つ目 保存前処理

アイテムのプロトタイプ 6 つ目

アイテムのプロトタイプ 6 つ目 保存前処理

ディスカバリルールによってアイテムが作成され 2 回以上データが収集されると、下図のように最新データに表示されるようになります。

図 18: ネットワーク関連データ収集例

保存前処理の JSONPath は多少の癖を感じつつも、使い出のある機能であることが実感できました。様々な場面で応用が効くのではないでしょうか。是非お試しください。

本記事に関連するリンク

• Zabbix ベースのシステム統合監視 MIRACLE ZBX
  

< 前の記事へ

Zabbix 3.2以降の新機能解説（Zabbix 4.0を見据えて） その21 - 保存前処理、依存アイテムの設定と処理、ソースコード解説

次の記事へ >

MIRACLE ZBX 6.0 からデータベースのバージョンに制約があります