1.3 基本概念と用語 ​

Zabbixを理解するために必要な基本概念と専門用語

Zabbixの画面を初めて開くと、ホスト、アイテム、トリガーといった見慣れない言葉が次々に出てきて戸惑うかもしれません。ただ、これらの言葉は監視の流れを順番に表したものなので、役割をつかんでしまえば、その後の学習がずっと楽になります。

この章では、Zabbixを理解するうえで土台になる五つの基本概念と、その周辺で必ず目にする用語を説明します。設定画面の操作は第5部以降で扱うため、ここでは「それは何のための部品か」「ほかの部品とどうつながるか」に絞って、できるだけ身近な例で説明します。

核となる5つの基本概念 ​

Zabbixの設定は、大きく五つの部品の組み合わせでできています。監視される側を表すホスト、そこから集める情報を表すアイテム、集めた値から異常を判断するトリガー、異常が起きたときに何をするかを決めるアクション、そしてこれらの設定をまとめて使い回すためのテンプレートです。

たとえば、Webサーバーを監視するとします。このWebサーバーがホストです。そのCPU使用率を1分ごとに取得する設定がアイテムです。使用率が高い状態が5分続いたら問題とみなす条件がトリガーで、問題になったら担当者にメールを送る設定がアクションです。そして同じ設定を別のWebサーバーにも使い回すために雛形にしておくのがテンプレートです。

この対応を頭に置いておくと、以降の説明を「あの例のどの部分か」に置き換えて読めます。まずはこの五つの役割分担を、おおまかに覚えてください。

Host（ホスト）の概念 ​

定義と役割 ​

ホストは、Zabbixで監視したい対象を表す単位です。サーバーやネットワーク機器といった実際の機器に限らず、仮想マシン、アプリケーション、クラウド上のサービスなども、Zabbix上ではホストとして登録して管理します。監視の世界では、物理か仮想かを問わず、何かを監視するにはまずホストを作る、と覚えておくと分かりやすくなります。

ホストは、監視設定の入れ物でもあります。そのホストに対するアイテムやトリガーなどの設定が、ホストにまとめられます。ホストには名前が付き、接続先を示すインターフェース（IPアドレスやDNS名、ポート番号）を設定します。また、多数のホストを管理しやすくするため、ホストグループという分類の枠に所属させます。たとえば「本番環境」「Webサーバー」のように複数の観点で整理できますし、権限の設定もホストグループ単位で行うため、後の運用で重要な役割を果たします。

ホストの種類 ​

ホストとして登録するものには、さまざまな種類があります。主なものを、例とあわせて整理します。

どの種類であっても、Zabbixの中での扱いは共通です。違うのは、使うインターフェースの種類や適用するテンプレートだけです。

ホストの設定要素 ​

ホストを作るときには、まず識別のための名前を決めます。ホスト名は、後から検索や通知で使われる大切な目印です。Zabbixエージェントのアクティブチェックを使う場合は、エージェント側の設定ファイルに書くホスト名と、Zabbix上のホスト名を一致させる必要があります。名前を付けるときは、機器の役割や環境が分かるルールを決めておくと、数が増えたときに混乱しません。

接続先を示すインターフェースには、エージェント、SNMP、IPMI、JMXの四種類があります。ひとつのホストに複数のインターフェースを持たせられるため、同じ機器をエージェントとSNMPの両方で監視することも可能です。たとえば、エージェントは標準のポートである10050番、SNMPは161番を使います。

Item（アイテム）とは ​

定義と機能 ​

アイテムは、ホストから集める個々のデータを定義する設定です。CPU使用率、空きメモリ量、特定のポートの応答、ログの内容など、監視したい指標ひとつひとつがアイテムにあたります。アイテムは、「何を、どうやって、どれくらいの頻度で集めるか」を定めたものと考えると分かりやすくなります。

アイテムには、それを識別するためのキーがあります。キーは、集めるデータの種類を示す文字列です。たとえば、CPUの使用率を表すキーや、ファイルシステムの空き容量を表すキーが、あらかじめ用意されています。このほか、データの型、更新間隔（何秒ごとに取得するか）、履歴を保存する期間、取得後に値を加工する前処理などを設定します。

アイテムには、データの取得方法に応じたタイプもあります。監視対象のエージェントに問い合わせるタイプ、SNMPで取得するタイプ、HTTPでWebの応答を取得するタイプ、外部のスクリプトを実行するタイプ、Zabbixが他のアイテムの値から計算するタイプなど、環境に合わせて使い分けます。

データタイプの詳細 ​

アイテムが扱うデータは、型によって保存のされ方や使える機能が変わります。数値には、小数を含むものと整数があります。CPU使用率のように小数が出る値は浮動小数点、プロセス数のように整数のみの値や、容量のように非常に大きな値は符号なし整数を選びます。

文字列や、長い文章を扱うものもあります。システムのバージョン名のような短い文字列には文字型を、ログのように複数行にわたる内容にはログ型やテキスト型を使います。ログ型は、ログファイルを継続的に読み取ってエラー文字列を探すような使い方に向いています。なお、Zabbix 7.0以降ではバイナリ型のアイテムも利用できます。取得する値と型が合っていないと保存に失敗するので、最初に何が返ってくる値なのかを確認することが大切です。

アイテムキーの例 ​

具体的にどのようなキーがあるのか、代表的なものを見てみましょう。エージェントで取得するキーを、用途別に少しだけ紹介します。

system.cpu.util[,user]     # ユーザー時間のCPU使用率
vm.memory.size[available]  # 利用可能なメモリ量
net.tcp.listen[80]         # ポート80で待ち受けているか

システムリソースのキーは、CPUやメモリ、ディスクなどの状態を取得するもので、監視の基本になります。ネットワークのキーは、インターフェースの送受信量やポートの待ち受け状態などを確認します。アプリケーション関連では、Webページの取得やログファイルの監視などのキーがあります。キーの一覧は公式ドキュメントの「Zabbix agent」の項目にまとまっているため、必要なときに探す使い方で十分です。実際には、後述するテンプレートにあらかじめ多くのアイテムが入っているので、キーを一から覚える必要はありません。

前処理ステップ ​

取得した値を、そのまま保存するのではなく、加工してから使いたい場面があります。それを担うのが値の前処理です。たとえば、ネットワークの受信バイト数のように増え続けるカウンターの値は、そのままだと意味を読み取りにくいので、一定時間あたりの変化量（速度）に変換します。

そのほか、単位の変換や、正規表現による文字列の抜き出し、JSONから特定の項目を取り出す処理などが用意されています。前処理は複数を順番に組み合わせられるので、「文字列から数値部分を取り出し、さらに単位を変換する」といった流れも作れます。加工をZabbix側で行えば、監視対象には手を加えずに済みます。

Trigger（トリガー）の役割 ​

定義と目的 ​

トリガーは、アイテムで集めた値が異常かどうかを判断する条件式です。値を集めるだけでは、誰かが画面を見続けない限り異常に気づけません。トリガーがあることで、Zabbixが自動的に値を評価し、条件に当てはまったときに問題として扱えるようになります。

トリガーには状態があります。正常な状態はOK、条件に当てはまって問題が発生している状態はProblemと表示されます。値の取得に失敗するなどして、判定ができない状態はUnknownとして扱われることがあります。状態が変わった時点で、イベントと呼ばれる記録が作られ、これが次のアクションの引き金になります。

トリガー式の構文 ​

トリガー式は、関数と比較演算子を組み合わせて書きます。現在の形式では、対象のホストとアイテムのキーを「/ホスト名/キー」の形式で指定し、関数でどの期間のどんな値を使うかを決めます。たとえば次の式は、「web-server-01のユーザーCPU使用率の5分間の平均が80を超えたら問題」という意味になります。

avg(/web-server-01/system.cpu.util[,user],5m) > 80

昔のバージョンでは波かっこを使った別の書き方でしたが、Zabbix 5.4以降は上のような形式に変わっています。古い解説記事を参照するときは、書き方の違いに注意してください。式の詳細は第4部で取り上げます。

深刻度レベル ​

トリガーには、問題の重要度を示す深刻度を設定します。深刻度は六段階あり、通知の宛先や緊急度を分ける目安になります。

深刻度は、後で説明するアクションの条件に使えます。たとえば、警告までは平日の日中にメールで知らせ、重度以上は夜間でも電話やチャットで担当者に通知する、といった切り分けが可能です。

複雑なトリガー条件 ​

トリガーの条件は、ひとつの値の比較に限りません。複数の条件を論理演算子で組み合わせることもできます。たとえば、CPU使用率が高く、さらに空きメモリも少ないときだけ問題にする、といった条件です。単独では問題にならない値でも、重なると危険な状況を、確実に拾うための工夫です。

また、短い時間と長い時間の両方の平均を使うと、一瞬の急上昇では通知せず、高い状態が続いているときだけ知らせる、といった調整ができます。誤報が多いと、担当者が通知に慣れて見逃すようになるので、条件を工夫して通知の質を保つことが大切です。

Action（アクション）の仕組み ​

定義と機能 ​

アクションは、イベントが発生したときに何をするかを定める設定です。トリガーが問題になったとき、あるいは問題が解決したときに、自動で通知やコマンドの実行を行います。アクションがなければ、問題を検知できても誰にも伝わらないため、トリガーとセットで設定するものと考えてください。

アクションの内容は、大きく通知とリモートコマンドに分かれます。通知は、メールやチャットツール、Webhookなどを使って人に知らせるものです。通知の方法はメディアタイプとして登録し、利用者ごとに宛先を設定します。リモートコマンドは、監視対象でコマンドを実行する機能で、サービスの再起動のような復旧作業を自動化できます。ただし、自動実行は意図しない影響を与えることもあるため、最初は通知だけにして慣れてから使うのが安全です。

通知エスカレーション ​

エスカレーションは、問題が続いている時間に応じて、通知の内容や宛先を段階的に変える仕組みです。たとえば、最初は担当者にメールを送り、15分たっても解決しなければ上長にも知らせ、さらに30分続くときはチーム全体へ通知する、というように設計します。

この仕組みがあると、担当者が気づかなかった場合や対応に手間取っている場合でも、問題が放置されにくくなります。ただし、段階を細かくしすぎると運用が複雑になるので、まずは二段階か三段階程度から始めるとよいでしょう。

条件フィルタリング ​

アクションには、実行する条件を付けられます。どのホストグループのホストか、深刻度がどれ以上か、どのタグが付いているか、といった条件で絞り込めます。たとえば、本番環境のサーバーで、深刻度が重度以上の問題だけを担当者に通知する、という使い方です。

条件を使い分けることで、通知の量を適切に保ち、本当に必要な知らせだけを関係者に届けられます。逆に、条件をまったく付けないと、すべての問題が通知されて見逃しの原因になりかねません。

Template（テンプレート）の活用 ​

定義と目的 ​

テンプレートは、アイテム、トリガー、グラフなどの設定をひとまとめにした雛形です。ホストにテンプレートをリンクすると、そのテンプレートの設定がホストに適用されます。同じ種類の機器を大量に監視する場合、機器ごとに一から設定していては大変ですが、テンプレートがあれば、リンクするだけで同じ監視を開始できます。

テンプレートの利点は、設定の標準化にあります。同種のサーバーが同じ基準で監視されるので、設定の抜けや間違いが減ります。また、テンプレートを修正すれば、リンクしているすべてのホストに変更が反映されるため、しきい値の見直しなども一度の作業で済みます。さらに、監視のノウハウがテンプレートの形で蓄積され、新しい担当者への引き継ぎや教育にも役立ちます。

テンプレートの階層構造 ​

テンプレートは、他のテンプレートをリンクして、設定を引き継げます。たとえば、Linuxの共通の監視項目を持つ土台となるテンプレートを作り、その上にWebサーバー用やデータベース用のテンプレートを重ねる、という使い方ができます。

こうした階層にしておくと、共通の部分は一か所で管理でき、個別の部分だけを各テンプレートで追加すればよくなります。土台を変更すれば、上に重なったテンプレートにも自動で反映されるので、保守がしやすくなります。ただし、階層を深くしすぎると、どの設定がどこから来ているのかが分かりにくくなるため、二、三段程度にとどめるのが無難です。

標準テンプレート ​

Zabbixには、最初から多くの標準テンプレートが用意されています。名前は「Linux by Zabbix agent」のように、対象と取得方法を表す形式になっています。OS向けには、LinuxやWindowsのテンプレートがあり、アプリケーション向けにはApacheやMySQL、PostgreSQLなどが、ネットワーク機器向けには各社のスイッチやルーター用のテンプレートがあります。

標準テンプレートをそのまま使うだけでも、基本的な監視をすぐに始められます。もし内容を変えたい場合は、標準のものを直接編集せずに、複製したものやリンクした別のテンプレートで調整するのが一般的です。バージョンアップ時に、標準テンプレートが更新される可能性があるためです。

その他の重要な概念 ​

五つの基本概念のほかにも、Zabbixの画面や資料で頻繁に登場する用語があります。ここでは代表的なものを説明します。

Event（イベント） ​

イベントは、Zabbixの中で起きた出来事の記録です。もっとも多いのは、トリガーが正常から問題に、あるいは問題から正常に変わったことを示すトリガーイベントです。ほかに、ネットワークディスカバリで新しい機器が見つかったときのディスカバリイベントや、エージェントが自分から登録を求めてきたときの自動登録イベント、システムの内部状態が変わったときの内部イベントなどがあります。

アクションは、このイベントを受けて動作します。つまり、「値が取れた、トリガーが判定した、イベントができた、アクションが動いた」という流れで監視が進みます。

Problem（問題） ​

問題は、いま解決していない状況のことで、画面上では、現在の問題の一覧として見られます。トリガーがProblem状態になると問題が作られ、OKに戻ると解決済みとして扱われます。

問題には、担当者が確認したことを記録する承認（アクノレッジ）の機能があります。誰かが対応中だと分かれば、他の担当者が重複して対応するのを避けられます。メッセージを添えたり、深刻度を変更したり、手動で問題を閉じたりすることもできます。

Dashboard（ダッシュボード） ​

ダッシュボードは、監視の状況を見るための画面で、ウィジェットを組み合わせて作ります。グラフ、現在の問題の一覧、マップ、時計や表示用のテキストなどのウィジェットを配置し、必要な情報をひと目で確認できるようにします。ホストグループやタグで表示を絞り込んだり、一定の間隔で自動更新したりすることも可能です。

Discovery（ディスカバリ） ​

ディスカバリは、監視対象を自動的に見つけて登録する機能の総称です。ネットワークディスカバリは、指定したIPアドレスの範囲を調べて、応答のある機器を見つけます。自動登録は、エージェントのほうからZabbixサーバーへ登録を求める仕組みです。低レベルディスカバリ（LLD）は、ホストの中のファイルシステムやネットワークインターフェースなどを自動で見つけて、アイテムやトリガーを作ります。いずれも第5部の「自動ディスカバリ」で詳しく扱います。

基本概念の関係図 ​

ここまでの用語がどうつながるかを、図で確認しましょう。

ホストには、アイテムの設定が含まれます。テンプレートは、ホストにリンクして、まとめて設定を適用します。アイテムが集めた値をトリガーが評価し、状態が変わるとイベントが作られます。そのイベントを受けて、アクションが通知やコマンドを実行します。この流れが、Zabbixによる監視の基本形です。

学習のポイント ​

最後に、これらの概念を効率よく身につけるための進め方を述べます。

段階的理解 ​

最初のステップは、ホスト、アイテム、トリガーの関係を理解することです。ここが分かれば、値を集めて異常を判断するという監視の核心がつかめます。次に、アクションによる通知の仕組みを理解し、問題が人に伝わるまでの流れを完成させます。

そのあとで、テンプレートによる設定の使い回しを学ぶと、台数が増えても管理しやすくなる理由が分かります。最後に、ディスカバリのような自動化の機能を学べば、大規模な環境にも対応できる監視が作れます。この順序で進めるのが、無理なく理解を積み上げられる道筋です。

実践的なアプローチ ​

学ぶときは、いきなり大規模に始めず、一、二台のサーバーで動かしてみるのがおすすめです。実際に画面を操作して値が集まる様子を見ると、用語が具体的なイメージと結びつきます。慣れてきたら、監視対象や項目を少しずつ増やし、通知の設定を試して、手作業の確認をアクションに置き換えていきます。

さらに、同じ設定を繰り返し使う場面が出てきたら、テンプレートにまとめて標準化を進めます。学習用の環境は、第3部で説明するインストールの手順に沿って、仮想マシンやコンテナ上に用意するとよいでしょう。

参考リンク

• Zabbix用語集
• Zabbixアーキテクチャ

← 前へ: 1.2 Zabbixの主要メリット | 目次に戻る →