Zabbixで自作サイトのHTTP監視を試してみた

Linux

〜 Ubuntu上にZabbixサーバーを構築して、障害検知と復旧確認までやってみました 〜

こんにちは。

今回は、Zabbix を使って、HTTP監視を試してみました。

最終的には、

  • Ubuntu上にZabbixサーバーを構築
  • 自分のサイトをHTTP監視として登録
  • 異常時にProblemsへ表示されるトリガーを作成
  • わざと失敗させて検知確認
  • 設定を戻して復旧確認

というところまで進めることができました。

最初は「画面が出ればOKかな」くらいの感覚だったのですが、実際にやってみると、監視は“設定するだけ”ではなく、“異常を拾って復旧まで確認して初めて理解が深まる” んだなと実感しました。


今回やりたかったこと

今回の目的は、Zabbixの基本的な流れを一通り体験することでした。
以前にもZabbixサーバーの構築はしていたのですが、実際のサイトに監視を入れるというところまでできていなかったので、そこまでやってみました。

具体的には次の3つです。

  • Zabbixサーバーを自分で構築する
  • 自分のサイトを監視対象として追加する
  • 障害が起きたときに、Problemsに表示されるところまで確認する

監視対象には、Xserver上で運用している自分のサイトを使いました。

追加したのは以下の2つです。

  • ポートフォリオサイト
  • ブログサイト

共有レンタルサーバーなので、Zabbix Agent を入れて細かく監視するのは難しいですが、HTTP監視のような外形監視なら十分実践できる と分かりました。


構成

今回の構成はこんな感じです。

  • Mac
  • VirtualBox 上の Ubuntu 24.04
  • Ubuntu上に Zabbix Server を構築
  • 監視対象は Xserver 上のサイト

最初は VirtualBox のコピー&ペーストがうまく使えず少し苦戦したのですが、SSH接続できるようにしてからはかなり快適になりました。

Mac 側のターミナルから Ubuntu に接続し、コマンドをコピペしながら作業できるようになったのは大きかったです。


Zabbixサーバーの構築

Zabbixサーバーは Ubuntu 上に構築しました。

使ったのは以下のような構成です。

  • Zabbix Server
  • MySQL
  • Apache
  • Zabbix Frontend
  • Zabbix Agent

途中で Apache が起動せずに少し詰まりましたが、原因はすでに動いていた Nginx とポート80が競合していたこと でした。

今回は Zabbix の Web 画面を表示することが優先だったので、Nginx を止めて Apache を使う形にしました。

このあたりも、実際に触ってみると「サービスが入っているだけではだめで、どのポートを誰が使っているのかも見ないといけない」と学べてよかったです。(Nginxを停止して進めました)


WebシナリオでHTTP監視を追加

Zabbixの画面が表示できるようになったあと、HTTP監視の設定に進みました。

今回は各サイトごとにホストを作成し、その中に Webシナリオ を追加する形で設定しました。

監視対象として追加したのは、

  • ポートフォリオサイト
  • ブログサイト

です。

まずはトップページに対して HTTP監視を設定し、

  • アクセスできるか
  • ステータスコードが正常か
  • 応答に失敗していないか

を確認するようにしました。

「Zabbix = サーバーのCPUやメモリを監視するもの」というイメージが少しあったのですが、今回触ってみて、Webサイトそのものの外形監視にもかなり使いやすい と感じました。


Problems に出すためのトリガー作成

監視項目を追加しただけでは、「見に行けば状態が分かる」だけです。

せっかくなので今回は、障害が起きたときに Problems に表示されるトリガー も作成しました。

使ったのは Webシナリオの failed step です。

考え方はとてもシンプルで、

  • 正常時は 0
  • 異常時は 1 以上

なので、

failed step が 0 以外なら異常

という条件でトリガーを作りました。

このあたりは、実際に式を見ながら設定したことで、Zabbix のトリガーがどういう考え方で動いているのかを少し掴めた気がします。


わざと失敗させて動作確認してみた

今回いちばん勉強になったのはここでした。

設定しただけで終わらせず、本当に Problems に出るかを確認するために、あえて失敗させるテスト をやってみました。

やったことはシンプルで、WebシナリオのURLを一時的に存在しないURLへ変更し、HTTP監視が失敗する状態を作りました。

その結果、ちゃんと Problems に

Web scenario failed

が表示されました。

この瞬間、「おお、本当に検知された」とかなり実感が湧きました。

さらに、そのあと URL を元に戻し、Latest data や Problems の状態も確認しました。

  • Problems から消える
  • Latest data が正常値に戻る

ところまで見られたので、単に“落ちた”だけでなく、復旧も確認できた のがよかったです。


今回やってみて感じたこと

今回やってみて一番感じたのは、監視は「導入しました」で終わりではなく、

  • ちゃんと値が取れているか
  • 異常時にどう見えるか
  • 復旧したらどう戻るか

まで見て初めて理解できる、ということでした。

特に今回は、

  • Zabbixサーバーを構築
  • 監視対象を登録
  • トリガー作成
  • 障害発生
  • Problems 確認
  • 復旧確認

という一連の流れを体験できたので、かなりよい練習になりました。

実務でも、監視は「入っているだけ」より、「異常時にちゃんと気づけること」が大事だと思うので、その入り口としてすごく良い経験になったと思います。


今後やってみたいこと

今回のHTTP監視はかなり基礎的なところなので、次はもう少し発展させてみたいです。

例えば、

  • 応答時間が遅いときのトリガーを作る
  • 複数ページを監視する
  • SSL証明書の期限監視を試す
  • 監視対象をもう少し増やす

あたりは、次のステップとしてちょうど良さそうです。

また、今回は Xserver 上の共有レンタルサーバーを対象にしましたが、今後は root 権限がある環境で Zabbix Agent を使った監視も試してみたいです。


まとめ

今回の学習で、Zabbix を使って以下を体験できました。

  • Ubuntu 上に Zabbix サーバーを構築
  • Xserver上の自分のサイトを HTTP監視として追加
  • Webシナリオの failed step を使ってトリガーを作成
  • 障害時に Problems に表示されることを確認
  • 復旧後に正常状態へ戻ることを確認

実際に触る前は少し難しそうな印象もありましたが、やってみると「監視の基本的な流れ」をかなり具体的に理解できた気がします。

今後もこういう形で、手を動かしながら学んだことを少しずつ積み上げていきたいです。