大学の情報システム環境には、サーバ、ネットワーク機器、無線LAN、仮想化基盤、各種アプライアンスなど、さまざまな機器やサービスが存在します。これらを安定して運用するために欠かせないのが「監視」です。
しかし、監視項目を増やせば増やすほど安心、というわけではありません。通知が多すぎると、本当に重要な障害がその中に埋もれてしまうこともあります。
今回は、大学を中心にZabbixの構築・運用を担当している当社エンジニアの、
インフラエンジニア（マネージャー・Zabbixスペシャリスト）：福田 崇氏
インフラエンジニア：藤本 嵩渡 氏
に、実際の現場でどのように監視項目や通知範囲を決めているのかを聞きました。
「全部監視する」ことが正解ではない
――大学のシステムでは、どこまでを監視対象にするのでしょうか？
まず考えるのは、そのサービスが止まったときに利用者や業務に影響があるかどうかです。
落ちても特に問題にならないサービスまで、すべて監視して通知する必要はありません。一方で、DNSやWebサービスなど、実際に利用されている重要なサービスについては、障害を検知できるようにします。
24時間365日の監視対象とするサービスについても、ベンダー側だけで決めるのではなく、必要に応じて大学側にも確認してもらいながら決めています。
通知が多すぎると「オオカミ少年」になってしまう
――監視項目を増やしておいた方が安心ではないのでしょうか？
必ずしもそうではありません。例えば、普段からメモリ使用率が高いサーバで、毎日のように同じアラートが発生していたとします。
その状態が続くと、「またいつものアラートだ」と通知を見なくなってしまいます。その結果、本当に対応が必要な障害まで見逃してしまう可能性があります。私たちは、検知できないこと以上に、通知が多すぎて“オオカミ少年”になってしまうことの方がリスクになる場合があると考えています。
そのため、不要な監視項目を除外したり、しきい値やマクロを調整したりしながら、実際の運用に合わせて監視内容をチューニングしていきます。
構築時よりも「運用が始まってから」が重要
――Zabbix構築で特に重視していることはありますか？
最初から完璧な監視設定を作ることよりも、実際に運用が始まってから柔軟に調整していくことを大切にしています。
システムを使い始めてみると、
「このアラートは頻繁に発生するけれど問題ない」
「このサービスはもう少し細かく見たい」
といったことが必ず出てきます。
そのため、納品して終わりではなく、運用状況を見ながら監視項目やしきい値を調整していきます。
大学のシステム運用を長く経験しているからこそ、単にZabbixを構築するだけではなく、現場で使いやすい監視環境に育てていくことを重視しています。
ネットワーク機器も「役割」によって監視方法を変える
――ネットワーク機器はどのように監視していますか？
基本的にはSNMPポーリングを利用しますが、すべての機器を同じ設定で監視するわけではありません。
例えばファイアウォールやコアスイッチなどの重要な機器では、CPUやメモリなどのリソースだけでなく、各インターフェースまで細かく監視します。
一方、エッジスイッチや無線LANアクセスポイントでは、利用者のPCがシャットダウンしただけでポートダウンの通知が発生してしまうため、インターフェースについては基本的にアップリンクを中心に監視します。
機器の重要度や役割に応じて、「何を見るか」を変えているということです。
――SNMP Trapも利用するのでしょうか？
基本的にはポーリングを中心にしています。
Trapは障害発生をすぐに受け取れるメリットがありますが、障害が解消したときの扱いなど、運用が複雑になることがあります。
そのため、特殊な事情がある場合を除いて、できるだけポーリングで状態を把握するようにしています。
サーバ、仮想化基盤、アプライアンスで監視方式を使い分ける
――サーバや仮想化基盤の場合はどうでしょうか？
仮想化基盤については、基本的に各ハイパーバイザが提供しているAPIを利用して監視します。
WindowsやLinuxのサーバについてはZabbix Agent 2を基本とし、エージェント監視に加えてICMPによる死活監視も行います。
TCPポートやサービス、プロセスについては、お客様へのヒアリングを行い、本当に監視が必要なものを選定します。
ログ監視については、障害発生を検知することは比較的容易ですが、「いつ正常に戻ったか」を判断するのが難しいケースもあります。そのため、必要性を確認しながら追加しています。
監視テンプレートがない機器も、自分たちで調べる
――専用アプライアンスなども監視できますか？
はい。メーカーからMIBを提供してもらい、既存のZabbixテンプレートがあれば利用します。
テンプレートがない機器の場合には、実際にSNMPで取得できる情報を調べ、その中から監視すべき項目を選定します。
例えばDHCPアプライアンスであれば、CPUやメモリといった一般的な情報だけではなく、取得可能であればDHCPスコープの使用率など、サービスそのものの状態も監視します。
こうした部分はかなり地道な作業ですが、機器やサービスの特徴を理解しながら監視項目を作っていくことも、私たちの強みの一つです。
Zabbixは、若手エンジニアがインフラ全体を学ぶ機会にもなる
――Zabbixの構築は、エンジニア教育という面ではどうでしょうか？
非常に勉強になると思います。
Zabbixそのものだけでなく、Web、データベース、メール通知などにも触れます。
さらに監視対象として、Active Directory、DNS、Webサーバ、ネットワーク機器、iLOやiDRACといったサーバ管理機能、仮想化基盤、各種アプライアンスなど、幅広い技術に関わることになります。
監視システムを構築することで、大学の情報システムがどのような要素から成り立っているのかを自然と理解できるようになります。
当社でも、案件の規模や難易度を見ながら、若手エンジニアがZabbix構築に関わる機会を作っています。
「たくさん監視する」より「必要なものを確実に見る」
Zabbixでは非常に多くの項目を監視できます。
しかし、大切なのは監視項目の数ではありません。
そのシステムにとって何が重要なのかを理解し、必要なものを選び、実際の運用に合わせて調整していくことです。
私たちは、Zabbixというツールを導入することそのものではなく、大学の運用担当者にとって「本当に必要なアラートがきちんと届く監視環境」を作ることを大切にしています。
コメント