Zabbix LLDでCatoサイトを自動検出：運用負荷を劇的に削減する監視術【シリーズ第2弾】

2025年6月24日

Cato（ケイト）

サービス資料や
ホワイトペーパーはこちら

はじめに

シリーズ第2回では、前回の「GraphQLをcurlで扱う」に引き続き、CATOのネットワークメトリクスをZabbixと連携するための次のステップとして、Zabbixのローレベルディスカバリ機能を活用する方法について解説します。
Zabbixのローレベルディスカバリの仕組みを把握し、どのようにCATOと連携できるのかについて考えていきましょう。

参考コラム：【Catoの利用方法】CatoのネットワークメトリクスをZabbixで収集する - GraphQL APIを curl で呼び出す方法

Zabbixのローレベルディスカバリ

Zabbixのローレベルディスカバリ（以下 LLD）とは、監視対象ホスト上の様々な要素（ディスク・ファイルシステム等）を検出して、それらに対するアイテム（監視項目）やトリガ（アラート条件）などを自動で登録削除する機能です。

　…と言われてもイメージがつきずらいと思うので、具体例を交えて解説します。

例：ファイルシステムの自動検出

例えば、多くのサーバを監視している現場を考えてみましょう。

様々な役割のサーバがあるので、マウントされているファイルシステムの数や構成は当然異なってくるでしょう。
あるサーバでは「/ (root), /var」等の基本的なマウントポイントしかないのに対し、別のサーバでは更に「/data, /backup」といった追加のマウントポイントがあるかもしれません。

従来の方法では、各サーバのマウントポイントを把握し、手動でファイルシステムごとのアイテム等を設定し、サーバ毎の現状に合わせて設定する必要がありました。

サーバ数が多い場合やマウントポイントの構成が変わる事を考えると、監視設定のテンプレート化もしづらく、管理作業が膨大になってしまい、どうしても設定漏れがでてきてしまうでしょう。

そこで、LLD を使うと、下記のような仕組みで自動化が可能です。

1. ディスカバリルールの設定

Zabbixで標準でサポートされているディスカバリ用のキー「vfs.fs.discovery」を利用して、「マウントされているファイルシステムの一覧を取得する」というディスカバリルールを作成します。

2. プロトタイプの設定

取得されたファイルシステムの一覧から、どのようなアイテム・トリガ等を生成するかについて、設定します。

3. 運用

仮に、あるサーバで新たに「/backup」が追加された場合、以降のディスカバリルール実行時にこの新しいマウントポイントが検出され、設定に従ってアイテム・トリガ等が追加されます。
また、削除されたマウントポイントも、一定期間後に自動的に削除されます。

LLDの仕組み

このようにLLDを使うことで、「検出された要素に対してどのような監視項目を設定するか」というディスカバリルールだけを作っておけば、各ホストの状況に合わせて、自動で監視項目が追加削除されるようになります。

例にも上げた、ディスカバリ用のキー「vfs.fs.discovery」は、下記の様な形式の値が取得できます。
（JSON は整形しています）

[
 { "{#FSNAME}": "/",
   "{#FSTYPE}": "xfs"
  },
 {
   "{#FSNAME}": "/data",
   "{#FSTYPE}": "xfs"
  },

  ...
]

「{#FSNAME} や {#FSTYPE} といった LLD マクロとその値のリスト」となっていますね。

ディスカバリルールでは、LLD マクロを埋め込んだアイテム等を定義しておくと、ルールに基づいた監視項目を生成することができます。

ここで重要な点ですが、「ディスカバリ用のキー」というのは、通常のアイテムのキーと何ら変わりはない、という事です。
キーの返す値 (JSON) が、ディスカバリで使える形式であればよいのです。

つまり、「LLD マクロとその値のリスト」の JSON を返すカスタムアイテムを実装するだけで、任意の要素を LLD の検出対象にすることができます。

CATOのメトリクスについて

さて、ここまでは LLD の仕組みと「検出 → アイテムやトリガの生成」の流れを整理しました。

第１回で述べた通り、CATOの「サイトライセンス」において、「サイト (= 拠点のエッジルータ)」は、契約帯域以上の速度が出ないようになっています。

サイトの利用帯域を把握するために、どのようにLLDとCATOとを組み合わせるかを考えていきます。

LLDで検出対象とする要素

サイトの利用帯域を把握したいので、検出すべき要素は当然「サイト」となるでしょう。
エッジルータが増減した際に、「サイト」毎に、監視項目が追加削除されるようになります。

こちらも第１回で述べたように、APIの entityLookup というクエリを利用して「サイト」の一覧を取得し、結果をLLDで利用できるようなJSONに加工すればよいでしょう。