Zabbixの監視設定

Contents


Zabbixの監視設定について説明します。初心者の方は、ホスト、アイテム、テンプレートの概念を理解しましょう。慣れてくれば、次はトリガー、アクションについて覚えましょう。

このページを最後までお読み頂くと、既存のテンプレートを利用するのではなく、業務要件に合わせて自作テンプレートを作成する事ができるようになると思います。

上級者ならば、Zabbixトラッパーの利用などの負荷軽減策の話題も興味あると思いますが、本サイトでは負荷軽減策のような上級者向けのコンテンツは取り扱いません。

Zabbix 用語説明

どのような統合監視ツールを使用しても、ツール特有の用語の理解は避けて通れません。以下、Zabbix特有の用語についてまとめます。初心者は、ホスト、アイテム、テンプレートについて理解するようにしましょう。

用語説明
ホスト監視対象の機器の意味です。Linuxサーバ、Windowsサーバ、ネットワーク機器などが該当します。
アイテム監視項目の意味です。ping死活監視、メモリリソース監視、ログ監視などが該当します。
テンプレート複数の監視項目をまとめた設定です。通常はホスト1台1台に対して監視設定を行うのは非常に手間ですので、テンプレートを用いて設定を省力化します。
トリガーアラートの設定です。例えば、ディスク残量量が20%を下回るとアラートを発報するよう設定ができます。
アクショントリガーによるアラート発報時に、自動的に行う動作です。メール通知、チャット通知などを行う事が多いでしょう。

なお、上記説明は初心者向け説明で正確な定義ではございません。正確な定義を説明すると混乱を招きそうなので、敢えて分かりやすさ重視の言葉を採用しております。

監視設定作成手順

監視設定を行う具体的な手順について説明します。何をどのように監視すべきかは後程詳しく説明します。まずは、基本的な操作について理解して下さい。

監視設定 – ホストの作成

まずは監視対象のホストを定義する必要があります。

「設定」タブの「ホスト」を押下します。その後、画面上部の「ホストの作成」を押下します。

zabbix_opeartion_monitoring_001

「ホスト」タブについて、ホスト名、所属グループ、IPアドレスの3つを入力します。この3つが最低限の入力項目です。入力が完了しましたら、「保存」を押下します。

所属グループは任意のグループで差し支えございませんが、何か分かりやすい名前のグループに属した方が後々のメンテナンスが楽になるでしょう。

zabbix_opeartion_monitoring_002

上記手順によってホストが作成された事を確認します。

zabbix_opeartion_monitoring_003

監視設定 – テンプレートの作成

監視項目の雛形となるテンプレートを作成します。監視項目はホストに対して直接設定する事もできますが、テンプレートに対して監視項目を定義した方が効率的な事が多いです。

「設定」タブの「テンプレート」を押下します。その後、画面上部の「テンプレートの作成」を押下します。

zabbix_opeartion_monitoring_004

「テンプレート」タブについて、テンプレート名、所属グループの2つを入力します。この2つが最低限の入力項目です。

zabbix_opeartion_monitoring_005

上記の入力が完了しましたら、画面を下へスクロールさせて「保存」を押下します。

zabbix_opeartion_monitoring_006

上記手順によってテンプレートが作成された事を確認します。

zabbix_opeartion_monitoring_007

監視設定 – アイテムの作成

Zabbixは監視項目の事をアイテムと呼びます。アイテム(監視項目)は、ホストに対して設定する事もできますし、テンプレートに対して設定する事もできます。以下、テンプレートに対してアイテム(監視項目)を設定する方法について説明します。

「設定」タブの「テンプレート」を押下します。その後、当該のテンプレートを押下します。

zabbix_opeartion_monitoring_008

「アイテム」「アイテムの作成」の順に押下します。

zabbix_opeartion_monitoring_009

「名前」欄に監視項目の名前を入力して下さい。その後、「キー」欄の「選択」を押下します。

zabbix_opeartion_monitoring_010

「アイテムキー」とは監視項目を値です。デフォルトインストールの時点で、多くの統合監視ツールが監視処理を行うスクリプトが組み込まれているのと同様に、Zabbix Agentも監視処理が予め実装されております。予め実装されている監視処理を以下の画面から選ぶ事ができます。

ロードアベレージを取得する「system.cpu.load[<cpu>,<mode>]」を例に挙げて説明します。「system.cpu.load[<cpu>,<mode>]」を押下して下さい。

zabbix_opeartion_monitoring_011

「system.cpu.load[<cpu>,<mode>]」の<cpu>, <mode>の部分は引数です。この引数にどのような値を与えるべきかはZabbixのマニュアルを適宜参照します。

<cpu>, <mode>については省略可能な引数ですので、キー欄を「system.cpu.load[,]」と修正します。

zabbix_opeartion_monitoring_012

ロードアベレージは整数ではなく小数の値を返すので、「データ型」を数値(浮動小数)に変更します。

zabbix_opeartion_monitoring_013

画面下の方へスクロールさせて、「保存」を押下します。

zabbix_opeartion_monitoring_014

上記の操作によって、監視項目(アイテム)が作成された事を確認します。

zabbix_opeartion_monitoring_015

監視設定 – ホストとテンプレートの紐付

ホストとテンプレートを紐づける事によって監視が開始されます。紐付の設定は、ホスト設定画面でもテンプレート設定画面でも、どちらからでも操作可能です。以下、テンプレート設定画面からの紐付操作を説明します。

「設定」タブの「テンプレート」を押下します。その後、当該のテンプレートを押下します。

zabbix_opeartion_monitoring_016

「テンプレート」タブにおいて、「グループ」欄を当該のホストが所属するグループに変更します。

zabbix_opeartion_monitoring_017

テンプレートと紐づけたいホストを選択した状態で、「<<」ボタンを押下します。

zabbix_opeartion_monitoring_018

画面下の方へスクロールさせ、「保存」を押下します。

zabbix_opeartion_monitoring_019

「次にリンク」列に、紐づけたホストが記入されている事を確認します。

zabbix_opeartion_monitoring_020

監視設定 – 動作確認

監視が行われているかどうかを確認します。

「監視データ」タブの「最新データ」を押下します。「最新のチェック」「最新の値」欄に時刻と監視結果が表示されている事を確認します。

zabbix_opeartion_monitoring_021

次に「グラフ」を押下します。

zabbix_opeartion_monitoring_022

以下のように「グラフ」が作成されている事を確認します。

zabbix_opeartion_monitoring_023

監視設定 – トラブルシューティング

監視結果が何も表示されない場合

以下のように、「値が存在しません」と、監視結果が何も表示されない場合もあるかもしれません。

このような場合は、切り分けのために「ヒストリがないアイテムを表示」にチェックを入れ「フィルター」を押下します。

zabbix_opeartion_monitoring_024

「ヒストリがないアイテムを表示」する事によって、

  • そもそも監視が開始されていないのか
  • 監視を試みたものの正常に値を取得できないのか

を切り分ける事ができます。

「ヒストリがないアイテムを表示」しても、何も表示されない場合は、

  • ホストとテンプレートの紐付を失念している
  • アイテム(監視項目)が無効化されている
  • Zabbix Agentへの疎通不能

等の可能性が考えられます。

テンプレートの一覧画面で、「次にリンク」列から、確かにホストとテンプレートが紐づけられている事を確認します。

zabbix_opeartion_monitoring_025

アイテム(監視項目)設定画面で、「ステータス」欄が有効になっている事を確認します。

zabbix_opeartion_monitoring_026

Zabbix Agentに疎通可能かどうかは、ホスト一覧の画面で「エージェントの状態」列を確認します。緑色ならば疎通可能な状態を表し、赤色は疎通不能な状態を表します。

zabbix_opeartion_monitoring_027

データ型に誤りがある場合 (「情報」欄に×と表示される場合)

「情報」欄に×と表示される場合は、「×」にカーソルを合わせて下さい。するとエラーメッセージが表示されます。

以下のようなエラーメッセージが表示される場合は、データ型に誤りがある可能性があります。

zabbix_opeartion_monitoring_028

例えば、小数を返すデータであるのにも関わらずデータ型が整数の場合はエラーとなります。この設定例の場合は、ロードアベレージなので小数を返します。もし、データ型がデフォルトの整数に設定されている場合はエラーとなります。

アイテム(監視項目)の設定画面で、データ型と実際の値が一致している事を確認します。

zabbix_opeartion_monitoring_029

メール通知設定手順

メール通知設定を行う具体的な手順について説明します。

メール通知設定 – トリガー設定

アラートをメール通知するには、まずトリガーを定義する必要があります。

「設定」タブの「テンプレート」を押下します。その後、当該のテンプレートを押下します。

zabbix_opeartion_alert_001

「トリガー」「トリガーの作成」の順に押下します。

zabbix_opeartion_alert_002

「名前」欄に何か分かりやすい名前を入れます。この値は、人間がよく見る値なので、人間が分かりやすい名前をつけると良いでしょう。英語が苦手なプロジェクトメンバーが多い環境ならば、日本語を使用するのも良い案かと思います。

なお、「名前」欄には、マクロを呼ばれる変数を使用する事ができます。例えば、以下スクリーンショットの{HOST.NAME}にはホスト名が格納されます。

zabbix_opeartion_alert_003

次にアラートを発報するかどうかの条件を定義します。「追加」ボタンを押下します。

zabbix_opeartion_alert_004

「グループ」「ホスト」をプルダウンから選択し、トリガーを設定する「テンプレート」を選択します。この時に発生しやすい操作ミスが、適用対象を「ホスト」とするか「テンプレート」とするかの操作誤りです。「ホスト」に対してトリガーを適用すると1台のホストに対して監視が有効になります。一方、「テンプレート」に対してトリガーを適用するとテンプレートを適用した全ホストに対して監視が有効になります。

「グループ」「ホスト」の選択が完了しましたら、アイテム(監視項目)を押下します。

zabbix_opeartion_alert_006

多くの統合監視ツールは閾値に関する細かなチューニングが可能です。例えば、「ロードアベレージが6.0を超過したら」のような単純な閾値設定にすると、ちょっとした高負荷処理やバッチ処理が発生する毎にメールが発生し、運用担当者のSAN値(TRPGに由来する言葉で、心の「正常性」を指します)を下げます。

メールが頻発しないように、「ある一定期間連続で負荷が高い状態であったならば」メールを送信するように設定しましょう。「関数」欄として、「期間Tの値の最小値 > N」を選択します。

なお、どのような関数を選ぶべきかは、慣れが必要です。私は、Xymon, Nagiosの経験した後にZabbixを経験しましたが、この「関数」の扱い方に慣れるのには時間がかかりました。

zabbix_opeartion_alert_007

「最新の(T)」「N」に適切な値を入力します。以下スクリーンショットの設定例の場合は、3回連続でロードアベレージが0.2を超過する場合にアラートを発報するようになっています。

設定が完了しましたら、「挿入」を押下します。

zabbix_opeartion_alert_008

アラートの深刻度(servility)を定義します。「深刻度」欄を押下します。

zabbix_opeartion_alert_009

「保存」を押下します。

zabbix_opeartion_alert_010

「監視データ」タブ「トリガー」を押下し、トリガーが実行されている事を確認します。

zabbix_opeartion_alert_011

障害発生時ならば、「監視データ」タブ「ダッシュボード」を押下する事で、障害を確認できるようになりました。

zabbix_opeartion_alert_012

メール通知設定 – アクションなどの定義

トリガーとアクションを紐づける事によって、障害発生時にメール送信やチャット通知を行う事ができます。トリガーとアクションの紐付手順は、かなり複雑で以下3ステップを踏む必要があります。

  • メディアタイプの定義
  • ユーザとメディアタイプの紐付
  • アクションの定義
メール通知設定 – メディアタイプの定義

「管理」タブの「メディアタイプ」を押下します。「Email」というデフォルト設定が存在しますので、このデフォルト設定を利用して設定を行います。「Email」を押下します。

zabbix_opeartion_alert_013

「SMTP サーバ」「SMTP helo」「送信元メールアドレス」を入力し、「保存」を押下します。

zabbix_opeartion_alert_014

メール通知設定 – ユーザとメディアタイプの定義

「管理」タブの「ユーザ」を押下します。メディアタイプと紐づけるユーザを押下して下さい。

zabbix_opeartion_alert_015

「メディア」タブを選択し、「追加」を押下します。

zabbix_opeartion_alert_016

「タイプ」はEmailを選択し、「送信先」にアラートメールを送信したい宛先メールアドレスを指定します。設定完了後に、「追加」を押下して下さい。

なお、夜間のバッチ処理などでメールが頻発する場合は、「有効な時間帯」「指定した深刻度の時に使用」の値をチューニングする事でメールの量を調節する事ができます。

zabbix_opeartion_alert_017

「保存」を押下します。

zabbix_opeartion_alert_018

メール通知設定 – アクションの定義

「設定」タブの「アクション」を押下します。

デフォルト設定で「Report problems to Zabbix Administrators」と呼ばれるアクションが定義されていますので、この設定を利用します。デフォルトの状態では無効化されていますので、「無効」を押下して有効無効を切りかえります。

zabbix_opeartion_alert_019

ステータス欄が「有効」と表示されている事を確認します。

zabbix_opeartion_alert_020

このデフォルト設定は、「Zabbix Administrators」グループに対してアクションを行いますので、前述の

「ユーザとメディアタイプの紐付」でZabbix Administratorsに属するユーザに対して、メール通知を行っていれば、以上の設定でメール送付が行われるようになります。

メール通知設定 – メール送付の動作確認

アクションを頻繁に発生させ、動作確認しやすいようにします。「トリガー」の設定画面で、閾値を小さ目に設定し、「障害イベントを継続して生成」にチェックを入れます。

zabbix_opeartion_alert_021

「監視データ」タブの「トリガー」を押下します。「トリガー」が実行されている事を確認します。

zabbix_opeartion_alert_022

「監視データ」タブ「イベント」を押下します。「アクション」欄に正常と表示され、アクションが実行されている事を確認します。

zabbix_opeartion_alert_023

Zabbixサーバの/var/log/maillogを確認し、正常にメール転送されている事を確認します。「Message accepted for delivery」の文字列を確認して下さい。

実際にメール転送されている事を確認します。

zabbix_opeartion_alert_024

監視項目の具体的な実装

Zabbix 2.2以上では、便利である程度使い物になる便利な監視テンプレートが備わっています。それほど高いサービスレベルが求められないのならば、デフォルト設定を利用し実装工数を抑える方針を採用しても良いかもしれません。

しかし、デフォルト設定のテンプレートでは、明らかに役不足の場合もあるでしょう。そのような場合は、監視項目をポチポチとGUIを使用して設定しなければなりません(Linuxのvim, sed文化で育った人には、このGUIポチポチ作業は相当の苦痛です)。

Ping監視、ポート監視、リソース監視、ログ監視など監視項目別に具体的な実装方法を説明します。

Ping監視

Ping監視はデフォルト設定の「Template ICMP Ping」に備わっています。このテンプレートはそのまま利用しても良いかもしれませんが、敢えて「Template ICMP Ping」を利用しない人のために、Ping監視の方法を説明します。

アイテム作成の画面で、タイプは「シンプルチェック」、キーは「icmpping」として下さい。タイプのデフォルト設定は「Zabbixエージェント」ですが、これはZabbixエージェントが値を返す監視手法です。「シンプルチェック」は監視サーバから監視対象にパケットを送りつけて監視する監視手法です。

zabbix_monitoring_ping_001

トリガーの設定画面では「期間Tの値の最大値 = N」を選んでください。

icmppingは成功が1を、失敗が0を返します。以下スクリーンショットのように設定する事で、3回連続でpingに失敗した場合のみアラートが発報されます。3回連続pingに失敗した場合は最大値は0ですので、トリガーの条件がTRUEとなります。逆に言えば、3回のうち1回でも成功した場合は最大値は1になりますので、トリガーはFALSEになります。

zabbix_monitoring_ping_002

ポート監視 / Layer 7 疎通確認

net.tcp.serviceというアイテムを利用してポート監視またはLayer 7 疎通確認を実装します。net.tcp.servicesの引数は以下のようになります。

第一引数serviceは、通信の種別を表す必須パラメータです。serviceに指定可能な値は、ssh, ntp, ldap, smtp, ftp, http, pop, nntp, imap, tcp, https, telnetのいずれかです。httpのようにZabbixが想定しているプロトコルならば、アイテムを「net.tcp.service[http,,80]」として下さい。

zabbix_monitoring_tcp_001

以下のような要件の場合は、第一引数にtcpを指定します。

  • Zabbixが想定していないアプリケーションを監視する(第一引数に指定可能なssh, ntp, ldap, smtp, ftp, http, pop, nntp, imap, https, telnet以外のアプリケーションを監視する)
  • Layer 7の疎通確認ではなく、TCPレベルの疎通確認(ポート監視)を行いたい

例えばTCP 3306を使用するMySQLの場合ならば、アイテムを「net.tcp.service[tcp,,3306]」と指定します。

zabbix_monitoring_tcp_002

トリガーの設定画面では「期間Tの値の最大値 = N」を選んでください。

net.tcp.serviceは成功が1を、失敗が0を返します。以下スクリーンショットのように設定する事で、3回連続で疎通に失敗した場合のみアラートが発報されます。3回連続で疎通に失敗した場合は最大値は0ですので、トリガーの条件がTRUEとなります。逆に言えば、3回のうち1回でも成功した場合は最大値は1になりますので、トリガーはFALSEになります。

zabbix_monitoring_tcp_003

説明を省略しましたが、net.tcp.service[service,<ip>,<port>]の第二引数<ip>は、省略するとホスト設定画面で定義したIPアドレスになります。メンテナンス性を考え、基本的には、第二引数<ip>は省略した方が良いでしょう。<ip>を明示的に指定する必要があるのは、ホストで指定したIPアドレス以外の監視を行いたい等の特殊要件のみです。IP明示指定が必要となる要件例は以下の通りです。

  • ホストで指定しているIPアドレスはサービス用途のセグメントであるのに対し、メンテナンス用のセグメント経由のみしか認めないアプリケーションが存在する。
  • サービス用途セグメントとメンテナンス用途のセグメントの2種類の通信経路で監視を行いたい。
  • ホストで指定しているIPアドレスではなく、敢えて、セカンダリアドレスを監視したい。

リソース監視

ディスクリソース監視

ディスクリソースの監視は、Zabbixデフォルト設定のテンプレート「Template OS Linux」「Template OS Windows」を利用すると良いでしょう。このテンプレートは、ローレベルディスカバリ(low level discovery)という仕組みを用いて、ディスクの種類を動的に取得してくれます。

ローレベルディスカバリは学習コストが高いので、まずはデフォルト設定を観察してローレベルディスカバリの仕組みを理解して下さい。慣れてきたら、ローレベルディスカバリの自力実装に挑戦してみるのも良いでしょう(ただし、再発名した車輪を本番導入しないように注意)。

テンプレート「Template OS Linux」「Template OS Windows」のいずれかを押下し、その後、「ディスカバリルール」を押下します。この画面の「mounted filesystem discovery」がディスク監視の設定になります。

zabbix_monitoring_resource_disk_001

監視項目を追加したい場合は「アイテムのプロトタイプ」を、監視閾値を変更したい場合は「トリガーのプロトタイプ」を変更します。

zabbix_monitoring_resource_disk_002

おそらく、ディスクリソースの閾値は運用の現場によって異なると思いますので、ディスク閾値を変更してみましょう。「トリガーのプロトタイプ」「トリガー名」の順に押下する事で、閾値変更画面に遷移する事ができます。

zabbix_monitoring_resource_disk_003

条件式の数値の部分を適宜変更する事で、ディスクリソース監視の閾値を変更できます。

zabbix_monitoring_resource_disk_004

メモリリソース監視 Linuxの場合

Zabbixはアイテム「vm.memory.size」を使用して、メモリの監視を行う事ができます。vm.memory.sizeには以下のような多数のパラメタを設定する事ができます(Zabbix 2.2 日本語マニュアルより引用)。

パラメタ意味
total使用可能な物理メモリの合計
freeメモリを必要とするどんな項目に対しても使用できるメモリ
active現在使用されている、または最近使用されたメモリで、RAMにあるもの
inactive使用されていないメモリ
wired常にRAMにあると示されているメモリ。このメモリはディスクには移動されません。
pinned「wired」と同じです。
anonファイルと関係ないメモリ(ファイルから再読み込みできないメモリ)
exec実行コード。通常、(プログラム)ファイルから実行されます。
file最近アクセスされたファイルのコンテンツのキャッシュ
buffersファイルシステムのメタデータのようなもののキャッシュ
cachedさまざまなもののキャッシュ
shared複数のプロセスによって同時にアクセスできるメモリ
usedactive + wired のメモリ
pused「total」に対するactive + wired のメモリ
availableinactive + cached + free のメモリ
pavailable「total」に対するinactive + cached + free のメモリ

これらを全て監視すれば良いというわけではありません。全てを監視してしまうと、「本当に重要な情報が埋もれてしまう」「監視サーバのリソース枯渇につながる」デメリットが発生してしまいます。私が個人的に必要と感じているのは、すぐに使用なメモリの残容量をパーセンテージで返すpavailableのみと思います。

free, pfreeは、他のプロセスがキャッシュとして使用している領域は含めずに残容量を計算しています。freeを監視してしまうと、プロセスがキャッシュを有効活用している状態であるのにも関わらず、残容量が少ないかのように見えてしまいます。Zabbix 2.2のデフォルト設定のテンプレートはfreeを監視していますが、freeは監視項目として不向きです。監視するならば、実際に使用可能な容量を表すavailable, pavailableにしましょう。

Zabbixのマニュアルにも以下のように記されていますので、Zabbixも私と似たような見解かと思います。

実際の手順としては、アイテム作成の画面でキーに「vm.memory.size[pavailable]」を指定します。

zabbix_monitoring_resource_memory_001

トリガーの設定例は以下の通りです。例えば、関数は「期間Tの値の最大値 > N」、最新の(T)は「3カウント」、Nは「10」と設定する事で、メモリ残容量が3連続で10%を下回った際に、アラートを発報する事ができます。

zabbix_monitoring_resource_memory_002

メモリリソース監視 Windowsの場合

Windowsの監視設定もLinux同様に、pavailableの監視がお勧めです。

しかし、Windows版のzabbix agentはLinuxに比べてサポートされる監視項目が少ないため、zabbix_getコマンドを使用して、どのような監視項目がサポートされるかを調査してから、GUIの設定を行った方が効率的でしょう。

サポートされない監視項目の場合、以下のようにZBX_NOTSUPPORTEDと表示されます。

全体的なCPUリソース監視 Linuxの場合

アイテム「system.cpu.util」を利用する事で、CPUの監視が可能です。system.cpu.utilは、cpu, type, modeの3つの引数を取ります。

それぞれの引数の意味は以下の通りです。

引数設定可能な値説明
cpuall, 0, 1, 2, 3...監視対象となるCPU番号を指定します。省略時は、全CPUの平均を意味するallとなります。
typeidle, nice, user, system, iowait, interrupt, softirq, stealCPUがどんな用途に使用されていたのかを指定します。
modeavg1, avg5, avg151分間、5分間, 15分間の平均値を返します。

最も重要な監視項目はidleです。idleは遊んでいる時間を表し、「100 – idle」をCPU使用率と考えても良いでしょう。idleを監視するには、アイテム作成の画面で、キーに「system.cpu.util[,idle,]」を指定します。

zabbix_monitoring_resource_cpu_001

もしCPU使用率を監視するならば、設定例は以下のようになります。以下はCPU使用率90%以上の状態が3連続で続いた場合にアラートを発報する監視設定です。

zabbix_monitoring_resource_cpu_002

CPU監視はバッチ処理(ジョブ)実行時にアラートが発報されやすい性質がありますので、監視としての実運用を回すのが難しい項目です。監視を行ったとしても、不要なアラートが多く「運用担当者を疲弊させる」「オオカミ少年状態で本当の障害が発生しても無視されてしまう」状態に繋がりうる可能性があります。

サーバの負荷上昇はロードアベレージで検知し、CPUはボトルネックを分析するための「情報」として利用するのも一案です。

全体的なCPUリソース監視 Windowsの場合

WindowsのCPU(タスク管理)には、idle, nice, user, system, iowait, interrupt, softirq, stealという概念が存在しません。Windows版zabbix_agentはsystemを指定する事でCPU使用率を返します。Windows版zabbix_agentにidle, nice, user, iowait, interrupt, softirq, stealをサポートしていません。

WindowsのCPU使用率を監視するには、アイテム作成の画面でキーに「system.cpu.util[,system,]」を指定します。

zabbix_monitoring_resource_cpu_003

個別CPUリソース監視

アプリケーションの作りによっては個々のCPUに処理が偏る事がよくあります。CPU全体の負荷は高くありませんが、1つのCPUの使用率が100%になっているため、処理性能が向上しない事がよくあります。

このようなボトルネックを分析するには、CPUを個別に監視する必要があります。人海戦術をとる事ができる会社ならば、CPUコア数毎にZabbixテンプレートを作成して監視設定を割り当てても良いでしょう。一方、小数精鋭戦略を取る会社ならば、ローレベルディスカバリを利用して自動的に監視設定を行うと良いでしょう。

Zabbix 2.4以上ならばCPUのローレベルディスカバリは標準の機能として盛り込まれています。Zabbix 2.2以下の方は、Baptiste Wichtさんの以下ブログ記事を元にローレベルディスカバリを実装して下さい。

プロセス監視

アイテム「proc.num」を利用する事で、CPUの監視が可能です。proc.numは、name, user, state, cmdlineの4つの引数を取ります。

それぞれの引数の意味は以下の通りです。

引数説明
nameプロセス名を指定します。例えばtd-agentのプロセス名は"ruby"になりますが、このような重複の恐れがあるようなプロセス名は、第四引数のcmdlineを使用した方が無難です。
userプロセスを実行するユーザ名を指定します。
stateall, run, sleep, zombのいずれかを指定します。
cmdlineプロセスを実行する際のコマンドを指定します。正規表現を利用する事も可能です。

実運用として、基本的に第一引数name, 第四引数cmdlineのいずれか両方を使用すると良いでしょう。

第一引数nameを使用する時はプロセス名を指定します。プロセス名は/proc/<プロセスID>/statに格納されています。例えば、td-agentのプロセス名を調べるコマンド例は以下のようになります。

td-agentの監視を行うには、以下のように、proc.numの第一引数<name>にrubyを指定します。

但し、rubyのようなプロセス名は重複の恐れがあります。例えば、rubyで作成したバッチ処理(ジョブ)もproc.num[ruby,,,]でカウントされてしまいます。重複の恐れがある場合は、第四引数cmdlineと併用すると良いでしょう。実行例は以下の通りです。

私個人の意見になりますが、第一引数<name>と第四引数<cmdline>を使い分けを徹底するのは非常に困難だと思いますので、Zabbixの設定ルールとして第一引数<name>を使用禁止にするのが無難かと思います。

サービス監視 (Windows限定)

アイテム「service_state」を利用する事で、Windowsのサービス監視が可能です。service_stateの構文は以下の通りで、引数は<service>のみです。

引数<service>にはサービス名を入力します。サービスはWindowsのサービスコンソールの画面から確認する事ができます。例えば、以下のような画面ならば「Zabbix Agent」がサービス名になります。

zabbix_monitoring_services_001

GUIを使用するのに抵抗がある方は、コマンドプロンプトでscコマンドをご利用ください。実効例は以下の通りです。findstrはLinuxにおけるgrepに相当するコマンドです。

zabbix_monitoring_services_002

ログ監視 (動けば良いレベル)

Zabbixのログ監視の仕組みは非常に難しいです。いきなり、実運用に耐えられる仕組みを設計するのは難しいので、まずは「動けば良いレベル」の設定例を紹介します。

設定を行う前にZabbix Agentの設定を確認します。ログ監視は、Zabbix Agentがログを定期的に監視し、監視結果をZabbix AgentからZabbix ServerへZabbix Trapを用いて送信します。Zabbix Serverは、Zabbix Trap内に含まれたZabbixホスト名を元に、どのサーバから送られたログなのかを判断します。ですので、設定を行う前に以下2点の確認が必要となります。

  • Zabbix Trapの宛先が想定通りである事
  • Zabbixホスト名が想定通りである事
ログ監視 – 事前確認(1) Zabbix Trapの宛先

/etc/zabbix/zabbix_agentd.confのServerActiveはZabbix Trapの宛先を表します。ServerActiveが想定通りの宛先である事を確認します。

ログ監視 – 事前確認(2) Zabbixホスト名

Zabbix AgentはZabbix Trapを送信する際に、Zabbix Trapのメッセージ内にホスト名を格納します。このホスト名は、OSに設定されるホスト名でもなく、名前解決(DNS)で使用されるホスト名でもありません。/etc/zabbix/zabbix_agentd.confに設定されたHostnameです。

このZabbixホスト名が、Zabbix Serverの「ホスト」の名前と一致している事を確認して下さい。

zabbix_monitoring_log_basic_001

「/etc/zabbix/zabbix_agentd.confに設定されたHostname」と、「Zabbix Serverのホストの名前」が一致していない場合は、/var/log/zabbix/zabbix_server.logにcannot send list of active checks toとのログが出力されます。

ログ監視 – アイテム設定 (動けば良いレベル)

ログを監視するアイテムを作成します。タイプは「Zabbixエージェント(アクティブ)」を選び、データ型は「ログ」を選択して下さい。

zabbix_monitoring_log_basic_002

アイテムキー「log 」または「logrt」を利用する事で、ログ監視が可能です。それぞれの引数は以下の通りです。各引数の意味は別の機会に説明します。

zabbix_monitoring_log_basic_003

最新データの画面で対象のログが取得されている事を確認します。以下は、キーとしてlog[/var/log/httpd/error_log,error,,,,]を設定した場合の画面です。この画面で「ヒストリー」を押下すると、第二引数に指定した正規表現「error」に合致したログを参照する事ができます。

zabbix_monitoring_log_basic_004

正規表現「error」に合致したログが確認できます。

zabbix_monitoring_log_basic_005

URL監視

ウェブシナリオの定義

URL監視を行うには「ウェブシナリオ」を定義する必要があります。「ウェブシナリオ」という名前がついていも、できる事はいわゆるURL監視です。seleniumのような一連の画面操作をテストする物ではございません。

テンプレートまたはホストの設定画面で、「ウェブシナリオ」「シナリオの作成」の順に押下します。

zabbix_monitoring_url_001

「名前」「更新間隔」「リトライ回数」を入力します。

zabbix_monitoring_url_002

上記入力が完了しましたら、「ステップ」タブを押下します。「追加」ボタンから監視対象のURLを設定する事ができます。

zabbix_monitoring_url_003

「名前」「URL」「要求ステータスコード」を入力し、「追加」を押下します。

「要求文字列」は監視結果に特定の文字列が含まれるかどうかを確認する処理です。要求文字列(監視文字列)を定義する事によって200番応答でもアプリケーションに異常がある場合を検知する事ができます。

私の経験則ですが、仕様変更の多いアプリの場合、要求文字列の変更によってアラートが発生し睡眠時間を奪われる事が多くなります。運用担当者の負担と相談しつつ、要求文字列を監視すべきかどうか判断するのが良いでしょう。ユーザ企業ならば、google analyticsのトラッキングIDなど仕様変更が発生しづらい文字列を選ぶという考え方もあります。

zabbix_monitoring_url_004

監視対象のURLが1つではない場合は、「追加」ボタンから監視対象のURLを増やす事ができます。

zabbix_monitoring_url_005

監視対象のURL定義が完了しましたら、「保存」を押下します。

zabbix_monitoring_url_006

URL監視のトリガー定義

「ウェブシナリオ」を定義すると、自動的に以下のようなアイテム(監視項目)が作成されます。最低限監視すべきは、URL監視のエラー件数を表す「Failed step of senario」です。余力があれば、応答時間を表す「Response time for step」も監視しましょう。

zabbix_monitoring_url_007

「Failed step of senario」はURL監視のエラー件数を表します。例えば、3つのURLを監視しており、そのうち1つがエラー(タイムアウト、ステータスコード期待値と異なる、要求文字列(監視文字列)未検知)となる場合、「Failed step of senario」は1を返します。

どれか1つでもエラーがある状態が一定期間続いた場合にエラーを返すようにしたいので、関数は「期間Tの値の最小値 NOT N」を選んでおくと良いでしょう。以下スクリーンショットのように設定しておく事で、URL監視のうちどれか1つでもエラーを返す状態が2回連続したら、アラートが発報されます。

zabbix_monitoring_url_008

「Response time for step」は応答時間(レスポンスタイム)を表します。

応答時間(レスポンスタイム)が悪化している状態が一定期間続いた場合にエラーを返すようにしたいので、関数は「期間Tの値の最小値 > N」を選んでおくと良いでしょう。以下スクリーンショットのように設定しておく事で、応答時間(レスポンスタイム)が8秒を超える状態が3回連続したら、アラートが発報されます。

zabbix_monitoring_url_009

Tips

chat 通知 / 電話通知

Zabbixはアクションとして任意のスクリプトを実行する事ができます。chat通知や電話通知のスクリプトを用意すれば、メール以外の伝達方法も可能です。必ずしも即時対応の必要のないものはメールとし、即時対応が必要なものをchat通知や電話通知にしておくと良いでしょう。

設定確認とスクリプトの配置

ZabbixサーバはAlertScriptsPathで定義されたパスに配置されたスクリプトを実行する事ができます。AlertScriptsPathがどのように設定されているかを確認するため、zabbix_server.confをgrepします。

AlertScriptsPath配下に通知を行うスクリプトを配置します。以下はTwilioによる電話通知を行うスクリプト例です。

zabbixユーザで実行が可能になるよう、権限設定も忘れずに行いましょう。

ブラウザ操作

ブラウザによるZabbixの設定は、前述の「メール通知設定手順」と殆ど同じですが、念のためスクリーンショット付きの手順を示します。

「管理」タブの「メディアタイプ」を押下します。その後、画面上部の「メディアタイプの作成」を押下します。

zabbix_telephone_001

「名前」「タイプ」「スクリプト名」を入力します。「タイプ」は「スクリプト」として下さい。「スクリプト名」は、/usr/lib/zabbix/alertscripts/に配置したスクリプトファイル名を指定します。

zabbix_telephone_002

次にメディアタイプとユーザの紐付を行います。「管理」タブの「ユーザ」を押下します。その後、該当のユーザを押下します。

zabbix_telephone_003

「メディア」タブの「追加」を押下します。

zabbix_telephone_004

「タイプ」「送信先」を入力します。送信先は必ずしも必要としないパラメータですが、必須入力項目となっているため、何らかの値を入力して下さい。

「有効な時間帯」「指定した深刻度のときに使用」はデフォルト設定でも差し支えございまえせんが、「有効な時間帯」「指定した深刻度のときに使用」をチューニングする事によってアラートの件数を減らす事ができます。

zabbix_telephone_005

「保存」を押下し設定を保存します。

zabbix_telephone_006

「設定」タブの「アクション」を押下します。アクションを作成するのは非常に手間ですので、デフォルト設定のアクションをコピーして作成します。「Report problems to Zabbix administrator」を押下します。

zabbix_telephone_007

「複製」を押下します。

zabbix_telephone_008

「アクション」に「名前」「デフォルトの件名」「デフォルトのメッセージ」を入力します。

「デフォルトの件名」「デフォルトのメッセージ」は、スクリプトに第2,3引数として渡されます。特に引数を必要としないスクリプトならば、「デフォルトの件名」「デフォルトのメッセージ」は空欄でも良いでしょう。

zabbix_telephone_009

「アクションの実行条件」タブを編集します。デフォルト設定のままでも差し支えございません。

なお、「メディア」設定画面だけでなく、「アクションの実行条件」でもアラートの頻度を調整できます。「アクションの実行条件」の方が、より細かな設定が可能です。

zabbix_telephone_010

「アクションの実行内容」タブの「変更」を押下します。

zabbix_telephone_011

「次のメディアのみを使用」に電話通知のスクリプトの名前を指定します。その後、「変更」を押下します。

zabbix_telephone_012

最後に、「保存」を押下して下さい。

zabbix_telephone_013

シェアする

  • このエントリーをはてなブックマークに追加

フォローする