本記事では、ITインフラを運用する上で必須の知識となる監視について解説したいと思います。
本記事をよむことで、ざっくりと「監視とはなにか」が理解できると思いますので、初心者、もしくは監視業務をこれから仕事でやっていく方の一助になれば幸いです。
運用における監視とは
昨今のITサービスは、24時間365日稼働することが普通になってきました。そこで重要になるのが、いかなる時においてもサービスを停止させず、顧客に価値を提供し続けていくということです。
これを実現するために、システムの監視というのがITの世界で行われています。具体的には以下のような事例があります。
- ECサイトでいつでも商品が購入できるよう、サーバのCPU、メモリ、ディスク使用率を常時監視し、負荷が高くなりそうな場合は原因を突き止め対処する。
- 緊急時を含め、いつでも電話がかけられるようにするために、使用している通信機器の状態（正常に稼働しているか、内部温度が高くなっていないか等）を常時監視する。
このようなこと（監視対象のサーバに入りCPU使用率、メモリ使用率、ディスク使用率を確認するというのを24時間繰り返す）を人間が手動でやるのは難しいです。監視対象が1台だけならまだしも、現代においては1つのサービスを稼働させるのに、数十台、数百台のマシンを稼働させ続けるというのは普通にありえるので、こうなってくると不可能です。
ただ、サービスは稼働させ続けなければ、ビジネス機会を逃してしまいます。そこで登場するのが、監視ツールです。具体的なツールの紹介は後に行いますが、以下のようなことが可能になります。
- 監視サーバから監視対象に対して、1分に1回ping疎通確認を行う。
- 5分に1回、監視対象側でCPU使用率、メモリ使用率、ディスク使用率を取得し、その情報を監視サーバに送る。
- 監視サーバから特定のURLにcurlコマンドを実行し、HTTP応答コードが200番台であることを確認する。
監視の種類
ここでは、主に使われる監視の種類をまとめてみます。
Pull型
監視ツールをインストールしたサーバから、各監視対象に情報を取りに行き監視をする方式になります。この方式の監視としては以下があります。
- 死活監視
- 対象のサーバ・ネットワーク機器が「生きている」ことを確認します。具体的には、監視サーバからのICMP通信(pingコマンド実行)が通るかどうかで確認します。
- ポート監視
- 対象のサーバの特定のポートへの通信が通るかを確認します。この監視が障害の場合、そのポートを使用しているミドルウェアが起動していないことがあります。
- サービス監視
- 提供しているサービスが正常に稼働していることを確認します。例えば、監視サーバから監視したいURLへcurlコマンドを実行し、そのHTTPステータスコードが200番台かどうかを確認します。
Push型
監視をしたい機器にエージェントアプリケーションをインストールし、定期的に監視サーバに情報を提供する方式です。この方式の監視としては以下があります。
- リソース監視
- 監視対象のCPU、メモリ、ディスクなどのリソースに関する状態が正常かを確認します。これを検知すると、提供しているサービスのパフォーマンスが低下しているおそれがあります。
- プロセス監視
- サーバ内で動いている各種プロセスが正常に稼働しているかを確認します。事前に定義したプロセス数ではない場合、正常にサービスを提供できていいない可能性があります。
- ログ監視
- 指定したログファイルに得手の文字列（Errorやfailed）などが記録されていないかを確認します。主にアプリケーションでエラーが発生していないかどうかを確認するのに用います。
Push型は対象機器にエージェントをインストールし、そのエージェントが情報を送ってくれているため、もしエージェントが止まると対象機器の情報を正しく取得できなくなります。また、途中経路のルータが止まった場合、対象機器上でエージェントは動いているけど監視サーバに情報が飛んでこないといったことも起こり得ます。
そのため、Push型の監視において情報の取得ができなくなった場合、いろいろな可能性を考えて調査を行う必要があります。
主要な監視ツール
監視を実現するツールにはいろいろありますが、以下がよく使われているツールになります。
- Zabbix
- Pandora FMS
- Prometheus
- Nagios
Zabbix
- サーバ、ネットワーク機器、アプリケーションの監視まで幅広く可能
- 企業が監視運用に使われている事が多く、日本国内でも設定方法などのドキュメントが揃ってる。
- Pull型、Push型両方の監視が使える。
Zabbixについては、以下の記事で自動監視登録についても紹介しているので、是非御覧ください。
Pandora FMS
- Zabbixと同じく、幅広い機器での監視が可能。
- 監視データを元にしたレポート作成機能がある。
- Pull型、Push型両方の監視が使える。特に、Push型の監視の設定変更を(有償版であれば)監視サーバ側で変更が可能。
Prometheus
- 自動で監視対象を追加・削除する機能がある。そのため、スケーラブルなシステムの監視を得意としており、Kubernetesを用いたシステムとの親和性が高い。
- エージェントレス型の監視であるため、基本的にはPull型の監視がメイン。ただし、Exporterとよばれるものを対象の機器にインストールすることで、リソース監視なども可能。
- 数値情報を用いた監視を行うため、ログ監視は難しい。
Nagios
- 死活監視を行うのが得意で、導入するのも大変じゃない。
- 小規模なシステム向きであり、大規模システムの監視には向かない。
監視の先にある障害対応
上記のようなツールを導入して、各機器の監視をするだけではサービスの継続的な提供は実現しません。監視と一緒に障害対応についても考える必要があります。
障害対応については考えるべきことが色々あります。例えば
- 実際に障害が発生したときの対応手順書の整備
- 24時間365日すぐに対応できる体制
- 障害時に主系のシステムから従系のシステムに切り替える場合は、滞りなくできるようにするための訓練
特に大変なのが、手順書の整備です。少数しか対応しないのであれば、その人達が理解できる手順書であればいいですが、入れ替わりだったりで新しく来た人も対応できるようにするには、誰が実行しても同じ結果になるような手順書を書かなければいけません。
ただ、人によって能力の差があるため、いくら手順を整備しても手動で行う上ではどうしても障害対応のクオリティに差が生じます。
そこで、障害対応自体も自動化してしまうと、人が対応しなくて良くなり、かつ障害対応のクオリティも維持できます。自動化周りについてはいろいろやりようがありますが、最近では以下のようなツールが登場してきています。
- Red Hat Ansible Automation Platform
- AWX
- StackStorm
これらのツールを使うことで、障害対応の自動化が可能になり、運用の負担を下げることができます。ここでは詳しく解説しませんが、今度それぞれのツールの使い方についてまとめたいと思います。
まとめ
今回は監視の必要性と、代表的な監視ツールについてまとめました。
- 24時間365日サービスを安定的に稼働させていくために必要。
- 以下のようなツールを用いて監視を実現する。
- Zabbix
- Pandora FMS
- Prometheus
- Nagios
- 監視だけではなく、障害対応についても重要。
それではここまで読んでいただき、ありがとうございました！
