5.3 自動ディスカバリ ​

手作業による監視設定の限界を解決するZabbixの自動ディスカバリ機能について、初心者にも分かりやすく解説します。複雑な設定に入る前に、まずは「なぜ自動化が必要なのか」「どんな場面で使うべきか」を理解しましょう。

Zabbixの監視は、ホストを登録し、テンプレートをリンクして始めます。台数が少ないうちは手作業で十分ですが、サーバーが日々増減する環境では、登録作業が追いつかなくなります。自動ディスカバリは、この登録作業を、Zabbixに任せるための機能群です。この章では、三種類のディスカバリの違い、導入の進め方、設計と運用の考え方を整理します。画面での設定の細かな手順は、公式ドキュメントの「Discovery」の章と、併せて読んでください。

自動ディスカバリが解決する課題 ​

現代のIT環境では、サーバーやサービスが頻繁に追加・削除・変更されます。クラウドでは、負荷に応じてインスタンスが増減しますし、コンテナでは、サービスの配置が数分で変わることもあります。すべてを手作業で管理するのは現実的ではありません。

手作業運用の問題点 ​

手作業の運用では、サーバーが増えるたびに、担当者がZabbixにホストを登録し、テンプレートを選んで、リンクします。この作業は単純ですが、忙しいと後回しになり、登録が漏れると、そのサーバーは、監視されないまま稼働します。障害が起きても気づけないため、気づいたときには、利用者に影響が出ているという事態になりかねません。

反対に、サーバーを撤去したときに、Zabbix側の設定を消し忘れると、応答しない機器に対する通知が、鳴り続けます。不要な通知が増えると、担当者が通知を軽く見るようになり、本当に重要な通知を、見逃す原因になります。

自動ディスカバリのメリット ​

自動ディスカバリでは、新しい機器が見つかったときの動作を、ルールとして定義しておきます。そのため、誰が作業しても同じ設定が適用され、サーバーの増減に、Zabbixが追従してくれます。

ただし、自動化は万能ではありません。ルールの設計が不適切だと、不要な機器まで登録されるなど、新しい問題も生まれます。この章の後半で、設計の注意点を説明します。

自動ディスカバリの種類と適用場面 ​

Zabbixには、三つの主要なディスカバリ機能があります。それぞれ、発見する対象が違うため、特徴を理解して、使い分けることが大切です。

1. ネットワークディスカバリ ​

ネットワークディスカバリは、指定したIPアドレスの範囲を、Zabbixサーバーが定期的に調べ、応答のある機器を見つける機能です。確認の方法には、ICMPのping、TCPポートへの接続、Zabbixエージェントへの問い合わせ、SNMPなどを指定できます。設定は、データ収集のメニューのディスカバリの画面で、ディスカバリルールとして作成します。

見つかった機器や、サービスの情報は、ディスカバリのイベントとして記録されます。その後、アラートのメニューにある、ディスカバリを対象としたアクションが、このイベントを受けて、ホストの追加や、ホストグループへの所属、テンプレートのリンクを行います。つまり、ルールが見つけて、アクションが登録する、という二段構えです。

適用場面は、物理サーバーやネットワーク機器など、固定のIPアドレスを使う環境です。更新の間隔は、一時間から二十四時間程度とすることが多く、設定は比較的簡単です。一方で、IPアドレスが頻繁に変わる環境では、同じ機器が別の機器として扱われることがあるため、注意が必要です。

2. エージェント自動登録 ​

エージェント自動登録は、監視対象のエージェントが、自分からZabbixサーバーに接続して、登録を求める仕組みです。サーバーの側から探しに行くネットワークディスカバリとは、向きが逆になります。

この仕組みでは、エージェントのアクティブチェックを使います。エージェントの設定ファイルに、サーバーの宛先と、ホストのメタデータ（OSの種類や、役割を示す文字列）を書いておくと、エージェントが初めて接続したときに、サーバーがその情報を受け取ります。サーバー側では、自動登録を対象とするアクションの条件に、このメタデータを使えるため、「メタデータにWebを含むなら、Webサーバー用のテンプレートをリンクする」といった振り分けができます。

クラウドやコンテナの環境では、この方法が威力を発揮します。従来の運用では、新しいインスタンスを起動したあとに、手作業でZabbixへ登録していました。自動登録を使えば、インスタンスのイメージに、エージェントの設定を含めておくだけで、起動した時点で、ホストが登録されて、監視が始まります。台数の増減が、IPアドレスの範囲に左右されないため、動的な環境に向いています。

3. 低レベルディスカバリ（LLD） ​

低レベルディスカバリ（LLD）は、ホストを見つけるのではなく、ホストの内部にある要素を、自動で見つける機能です。たとえば、あるサーバーのファイルシステム、ネットワークインターフェース、CPUのコア、データベースのテーブルなどです。

仕組みは次のとおりです。まず、ディスカバリルールが、見つけたい要素の一覧を取得します。ファイルシステムであれば、/や/varといった名前の一覧です。次に、プロトタイプと呼ばれる雛形（アイテムのプロトタイプ、トリガーのプロトタイプなど）に、見つけた要素の名前を埋め込んで、実際のアイテムやトリガーを作成します。この、要素ごとの名前を受け渡すために、{#FSNAME}のような、LLDマクロが使われます。

標準のテンプレートには、すでにLLDが組み込まれています。Linuxのテンプレートを、ホストにリンクするだけで、ファイルシステムやネットワークインターフェースが自動的に見つかり、監視が始まります。ディスクが追加されたら、次のディスカバリの実行のときに、自動的に監視に加わります。

LLDを使うと、監視対象の中身が変わっても、アイテムやトリガーの設定を、人が追加し直す必要がなくなります。たとえば、サーバーにディスクを増設した場合、従来であれば、新しいディスク用のアイテムとトリガーを、手作業で作る必要がありました。LLDがあれば、次のルールの実行時に、ディスクが見つかり、同じしきい値の監視が、自動で始まります。

また、LLDには、フィルターの機能があります。見つかった要素の中から、条件に合うものだけを監視対象にできるので、たとえば、一時的なファイルシステムや、仮想のインターフェースを除外できます。標準のテンプレートでは、このフィルターが、あらかじめ設定されているため、通常は、そのまま使えます。

LLDの実行間隔は、一時間程度が標準のテンプレートでよく使われます。また、要素が見つからなくなったときの扱いも、ルールで決められます。見つからなくなった要素を、すぐに削除せず、一定の期間は保持する設定が既定で、そのため、一時的に見えなくなっただけで、履歴が失われることを防げます。

導入の優先順位と段階的アプローチ ​

三つの機能を、一度に導入しようとすると、設計が複雑になります。効果を確かめながら、段階的に進めるのが、失敗しにくい進め方です。

レベル1: LLDとネットワークディスカバリから開始 ​

最初のステップとして、まず、標準テンプレートに含まれるLLDを、体験することをおすすめします。ホストにLinuxなどのテンプレートをリンクするだけで、LLDが動きますので、新たな設定は要りません。画面で、自動的にアイテムが作られている様子を確認すると、仕組みの理解が進みます。

次に、ネットワークディスカバリを、小さな範囲で試します。たとえば、検証用のネットワークの、数十個のアドレスだけを対象にして、見つかった結果を画面で確認します。結果が想定どおりなら、アクションによるホストの自動追加を設定し、対象の範囲を、少しずつ広げます。

レベル2: エージェント自動登録 ​

クラウドの自動スケーリングや、コンテナのように、台数が頻繁に変わる環境では、エージェント自動登録を導入します。ネットワークディスカバリでは、短時間で入れ替わる機器への対応が難しいため、この方式のほうが、向いています。

導入の判断基準は、サーバーの追加・削除の頻度です。月に数台増える程度なら、手作業や、ネットワークディスカバリでも対応できます。一方、日に何度も増減する場合は、自動登録を使わないと、運用が成り立ちません。メタデータの付け方のルールを、最初に決めておくことも、重要です。

レベル3: 独自のLLD ​

標準のテンプレートで足りない、アプリケーション固有の要素を自動で見つけたい場合に、独自のLLDを作ります。たとえば、自社のアプリケーションが、複数のインスタンスを動かしていて、その一覧を取得できるコマンドがあるなら、それをディスカバリルールにできます。

これは、三つの中でもっとも高度で、取得した要素の一覧を、決まった形式（JSON）で返す必要があります。まずは、ファイルシステムなどの簡単なものから、仕組みに慣れたうえで、アプリケーション固有のものに進むのがよいでしょう。公式ドキュメントのLLDの章に、書き方の例があります。

設計・運用のベストプラクティス ​

効果的なディスカバリルール設計 ​

ルールの設計で最初に決めるのは、名前のつけ方です。ディスカバリルールや、アクションが増えてくると、どれが何のためのものか、分からなくなります。たとえば、ルールの名前に、対象のネットワークと、実行の間隔を含めておくと、一覧で見分けやすくなります。

自動で作られたホストを、手動で作ったものと見分けるために、専用のホストグループを使う方法も有効です。自動登録されたホストを、いったん専用のグループに入れておけば、内容を確認してから、正式なグループに移す、という運用ができます。

実行の間隔は、環境の変化の速さに合わせます。クラウドのように、変化が速い環境では、短い間隔、物理サーバーのように、ほとんど変わらない環境では、長い間隔にします。短くしすぎると、ネットワークや、サーバーの負荷が上がるため、必要な頻度を見極めてください。

セキュリティとパフォーマンスの考慮 ​

ネットワークディスカバリは、アドレスの範囲を、調べて回る動作をします。そのため、調べる範囲を、必要な範囲に限定することが、セキュリティの基本です。管理していないネットワークまで、調べてしまわないよう、範囲を明確に決めます。また、SNMPで調べる場合は、コミュニティ文字列や認証の情報を、適切に管理してください。

パフォーマンスの面では、ディスカバリの処理を担当するプロセスの数や、タイムアウトの値が、関係します。大きな範囲を、短い間隔で調べると、サーバーに負荷がかかります。業務の時間帯を避けて実行する、範囲を分割するなどの工夫で、影響を抑えられます。サーバーの設定の、ディスカバラーのプロセス数は、必要に応じて調整します。

よくある課題と対策 ​

過剰検出（False Positive）問題 ​

不要な機器まで、検出されてしまう問題は、導入の初期に、よく起こります。原因は、スキャンの範囲が広すぎる、プリンターや一時的な端末のような、監視不要な機器が含まれる、といったものです。

対策は、まず、範囲を、本当に監視したいものだけに絞ることです。次に、アクションの条件で、特定のサービスが見つかった機器だけを登録する、特定のアドレスを除外する、といった絞り込みを行います。複数のルールが、同じ機器を検出して、重複して登録されるときは、ルールを整理して、統合してください。

検出漏れ（False Negative）問題 ​

反対に、見つかるはずの機器が、見つからないこともあります。もっとも多い原因は、ファイアウォールが、サーバーからの確認の通信を、ブロックしていることです。確認に使う、ポートや、プロトコルの通信を、許可する必要があります。

標準的でないポートを使うサービスは、既定のチェックでは見つからないため、確認するポートを、ルールに追加します。また、常時は電源が入っていない機器は、スキャンのタイミングで応答せず、見落とされます。その場合は、ルールの確認の回数や、間隔を見直します。

運用フェーズでの最適化 ​

自動ディスカバリは、設定して終わりではなく、運用しながら、少しずつ改善していくものです。環境は変化し、新しい種類の機器や、サービスが加わるたびに、ルールの見直しが必要になります。

継続的な改善ポイント ​

改善は、検出の結果を確認し、誤検出や漏れの原因を分析し、ルールを調整し、効果を確かめる、という循環で進めます。登録されたホストの数や、種類を、定期的に見ていれば、想定と異なる動きに気づけます。

定期的な見直し項目 ​

見直す項目と頻度の目安は、次のとおりです。環境の変化が速い場合は、頻度を上げてください。

見直しの結果は、ルールの改善に反映するだけでなく、運用のドキュメントとしても残しておくと、担当が変わったときに、引き継ぎやすくなります。

← 前へ: 5.2 テンプレート設計 | 次へ: 5.4 ユーザーとアクセス制御 →