LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Zabbixによるインフラ監視の全体像

Zabbixインフラ監視とは、オープンソースの統合監視ツールZabbixを使い、サーバー・ネットワーク機器・サービスの稼働状態を一元的に把握する仕組みを指します^*1。Zabbixはサーバー・仮想マシン・アプリケーション・サービス・データベース・ウェブサイト・クラウド・ネットワーク機器といった多様な監視対象を単一の基盤でカバーできる点が特徴です^*1。

Zabbixはポーリング（サーバー側からの能動的な問い合わせ）とトラッピング（エージェント側からの能動的な送信）の両方をサポートしており^*1、監視対象の性質に応じて収集方式を選べます。AGPLv3ライセンスで公開されているため、商用ライセンス費なしで導入できる点も選定理由の一つです^*1。

ただし監視範囲が広いほど、どの機器にどの収集方式を割り当て、どの異常をトリガーとして通知するかという設計判断が増えます。次章以降で収集方式・アラート設計・運用体制の観点を順に整理します。

エージェント監視とエージェントレス監視の違い

サーバーにZabbix agentを導入できる場合と、エージェントを導入できない機器を扱う場合で、採用する収集方式が変わります。この違いを理解することが監視設計の出発点になります。

Zabbix agentによる監視

Zabbix agentはサーバーやアプリケーションにインストールするソフトウェアで、CPU・メモリ・ディスク・プロセスなどのメトリクスを収集します。ポーリング（Zabbix agent）とトラッピング（Zabbix agent active）の両方式に対応しており、監視項目に応じて選択できます^*1。OSへのインストール権限があるサーバー群では、この方式が基本になります。

エージェントレス監視（SNMP・IPMI）

一方、プリンタ・ネットワークスイッチ・ルータ・UPSなど、OSやZabbix agentの完全なセットアップが実現しにくい機器も監視対象になります^*2。こうした機器にはSNMP（Simple Network Management Protocol）による監視を使います。SNMPはUDPプロトコルで動作し、Zabbix serverが機器からOID（Object Identifier、機器内の各データ項目を一意に識別する番号）の値を周期的に取得する仕組みです^*2。SNMPv1・SNMPv2はコミュニティ文字列による認証、SNMPv3はセキュリティ名・認証プロトコル・プライバシープロトコルを組み合わせたより高度な認証に対応します^*2。

サーバーの電源状態やハードウェア温度など、OSが起動していない状態でも把握したい情報にはIPMI（Intelligent Platform Management Interface）監視を使います。IPMIはOSやサーバーの電源状態に依存しない「out-of-band」管理インターフェースで、Zabbixはサーバー側にIPMIサポートを組み込むことでHP iLOやDell iDRACなどIPMI対応ハードウェアの状態を取得できます^*3。

エージェント監視・SNMP・IPMIのいずれを使うかは機器の種類とアクセス可否で決まるため、監視対象台帳を作った上で収集方式を機器ごとに割り当てる設計作業が欠かせません。この割り当てを誤ると、監視すべき機器が漏れたまま運用が始まってしまう恐れがあります。

トリガー・アラート通知の設計

データを収集しても、異常を判定し担当者に伝える仕組みがなければ監視の目的を果たせません。Zabbixではこの判定と通知を「トリガー」と「アクション」という機能で構成します。

トリガーは収集した値に対する論理式で、しきい値超えなどの条件を満たすと問題（PROBLEM）状態に遷移します。トリガー設定にはDependencies（依存関係）タブがあり、複数のトリガー間の依存関係を定義できます^*4。たとえばルータ障害時に配下の全サーバーで警報が同時発生する事象を、依存関係の設定によって整理できます。トリガー式は設定画面で事前にテストし、受信値に対する結果を確認する機能も用意されています^*4。

トリガーが発火した後の通知はアクション機能で条件分岐させます。重要度・時間帯・対象ホストグループごとに通知先を振り分けられるため、深夜のみ当番者へエスカレーションする、といった運用ルールを反映できます。この設計を怠ると、些細な変動でも大量の通知が飛び、担当者が本当に対応すべき警報を見落とすリスクが生じます^*2。

通知の粒度設計には、しきい値の妥当性検証・重要度分類・依存関係の整理という3つの作業が伴います。これらは監視対象が増えるほど工数がかかり、運用開始後も継続的な見直しが必要になる領域です。

テンプレートとダッシュボードの活用

監視対象が数十台・数百台規模になると、ホストごとに監視項目を個別設定する運用は現実的ではありません。ここで使うのがテンプレート機能です。

テンプレートは、アイテム（監視項目）・トリガー・グラフなどの監視設定をまとめて定義し、複数ホストへ一括で適用できる仕組みです^*5。テンプレート作成では、まず一般パラメータを定義してテンプレート本体を作り、そこにアイテムやトリガーなどのエンティティを追加します^*5。タグタブでテンプレートレベルのタグを設定すると、このテンプレートを継承した全ホストの問題にそのタグが付与されるため、障害発生時の分類・検索が容易になります^*5。同種のサーバー群（Webサーバー、DBサーバーなど)に同一テンプレートを適用すれば、監視項目の抜け漏れや設定差異を防げます。

収集したデータの可視化にはダッシュボード機能を使います。ダッシュボードは複数のウィジェットで構成され、ウィジェットはサマリー・マップ・グラフ・時計など、それぞれ異なる種類の情報を表示します^*6。1画面には1つのダッシュボードのみ表示されますが、複数のダッシュボードページを用意してスライドショー形式で順に回すことも可能です^*6。テンプレート単位でもダッシュボードを構成でき、この場合はホスト関連パラメータを個別指定せず、テンプレートを継承したホストのデータを自動的に表示します^*6。

トリガーの状態を一覧化する「トリガー概要」ウィジェットでは、ホストグループ単位で問題状態を色分け表示でき、重要度に応じた色でPROBLEM状態のブロックが表示されます^*7。障害対応の初動でどのホスト群に問題が集中しているかを素早く把握する用途に向いています。

商用監視ツール・SaaS監視との使い分け

Zabbixインフラ監視を検討する際、商用の統合監視ツールやSaaS型監視サービスとの違いを整理しておく必要があります。判断を誤ると、導入後に監視対象と要件がずれてしまう恐れがあります。

Zabbixはサーバー・ネットワーク機器・サービスといったインフラ層の稼働監視を主眼に置くツールです^*1。これに対し、アプリケーションのAPM（Application Performance Monitoring）やオブザーバビリティ製品は、コード実行のトレース・分散トランザクションの追跡といったアプリケーション内部の挙動可視化を主眼とします。両者は監視対象の階層が異なるため、片方を導入すれば他方が不要になるという関係ではありません。インフラの生死・リソース状況を把握する基盤としてZabbixを置き、アプリケーション内部の性能分析が必要な場合はAPM/オブザーバビリティ製品を別に組み合わせる構成が実務上の整理になります。

SaaS型の監視サービスは、監視基盤自体の運用・保守をサービス提供側が担う点が特徴です。Zabbixはオープンソースであり、サーバー・データベースの構築・保守・バージョンアップ作業を利用者側が担う前提になります^*1。監視対象が変化する頻度、社内に保守体制を置けるかどうかが選定の分岐点になります。

比較軸を表に整理すると次のようになります。

オンプレ・大規模環境での自前運用と可用性

Zabbixをオンプレミス環境で自前運用する場合、監視対象台数の増加に応じてZabbix server自体の可用性設計が課題になります。監視基盤が停止すれば、その間の障害検知そのものができなくなるためです。

この課題に対応するため、Zabbix serverには高可用性（HA）のオプトイン機能が用意されています^*8。複数のZabbix serverをクラスターのノードとして稼働させ、1つのアクティブノードが稼働し他のノードはスタンバイとして待機する構成です^*8。アクティブノードが正常にシャットダウンした場合は5秒程度で別ノードへ切り替わり、予期しない停止の場合はフェイルオーバー遅延（既定1分、10秒から15分の範囲で設定可能）に約5秒を加えた時間で引き継がれます^*8。このHA機能はZabbix serverを対象としたもので、Zabbix proxyには別の仕組みが用意されています^*8。

大規模環境ではZabbix proxyを拠点ごとに配置し、Zabbix serverへのデータ集約を分散させる構成も検討対象になります。監視対象が数千台規模になると、データベースのパフォーマンスチューニング・履行データの保存期間設計・ネットワーク帯域の見積もりなど、構築時点で決めるべき項目が増えます。

自前運用を選ぶ場合、次のような専門知識と工数が必要になります。第一に、Linux/Windowsサーバー構築とデータベース（MySQLやPostgreSQL等）の運用知識です。第二に、SNMP・IPMIといった機器固有プロトコルの設定経験です。第三に、HA構成やバックアップ・リストア手順を含めた運用継続の設計力です。これらを兼ね備えた担当者を確保できない場合、構築段階で設計の不備が生じ、本番運用後に監視漏れや誤検知の頻発という形で表面化する恐れがあります。

構築を内製するか外注するかの判断軸

Zabbix監視基盤の構築を内製するか外部パートナーに委託するかは、体制・工数・継続保守の3点から判断します。

内製する場合、監視対象の洗い出し・収集方式の選定・トリガー設計・テンプレート整備・HA構成までを社内の担当者が一貫して担う必要があります。担当者が異動・退職した際に設計思想が引き継がれず、監視ルールが形骸化するリスクも見落とせません。とくにトリガーのしきい値やアクションの通知条件は、業務知識と監視対象システムの特性を理解した上でチューニングし続ける作業であり、属人化しやすい領域です。

外部パートナーに委託する場合、構築時の設計（監視対象台帳の整理、収集方式の割り当て、テンプレートの標準化）と、運用開始後の保守（しきい値の見直し、機器追加時のテンプレート適用、バージョンアップ対応）を分けて依頼範囲を決めるのが実務的です。委託先には、Zabbix自体の設定スキルに加え、SNMP・IPMIなど接続先機器のプロトコル知識、サーバー・ネットワークの基盤知識を兼ね備えているかどうかを確認する必要があります。

内製と外注の違いを一言でまとめると、内製は初期投資を抑えつつ知見の蓄積と継続保守の負荷を自社が背負う形になり、外注は構築・保守の専門性を確保しつつ委託先との仕様共有・引き継ぎ体制を整える必要がある形になります。どちらを選ぶにしても、監視対象の増減や組織変更に耐えられる運用体制を事前に描いておくことが欠かせません。

まとめ：Zabbixインフラ監視基盤構築の3つの判断軸

本稿ではZabbixによるインフラ監視基盤の構築について、収集方式・アラート設計・運用体制の観点から整理しました。要点を3つに集約すると次の通りです。第一に、サーバーにはエージェント監視、ネットワーク機器などにはSNMP・IPMIによるエージェントレス監視を機器の特性に応じて選び分ける必要があります。第二に、トリガー・テンプレート・ダッシュボードを組み合わせ、監視対象の増加に耐える設計にすることが運用の実効性を左右します。第三に、アプリケーションのAPM/オブザーバビリティとは監視対象の階層が異なるため、目的に応じて別に組み合わせる判断が求められます。この3点を踏まえた上で、内製か外注かは体制と継続保守の負荷から検討するとよいでしょう。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Zabbix「Introduction – What is Zabbix」Zabbix Documentation
2. *2　出典：Zabbix「SNMP items」Zabbix Documentation
3. *3　出典：Zabbix「IPMI agent」Zabbix Documentation
4. *4　出典：Zabbix「Configuring a trigger」Zabbix Documentation
5. *5　出典：Zabbix「Configuring a template」Zabbix Documentation
6. *6　出典：Zabbix「Dashboards」Zabbix Documentation
7. *7　出典：Zabbix「Trigger overview」Zabbix Documentation
8. *8　出典：Zabbix「High availability」Zabbix Documentation

Tweet