はじめに
プロトソリューション仙台本社にてインフラ、AWSの運用を行っている市川と申します。
この記事では24時間365日常時稼働し続けるITシステムの運用に欠かせない、ITシステム監視について書かせていただきます。
ITシステムにおける監視とは
リモートワーク、オンラインショッピング、オンラインバンキング、行政サービスなど、現代社会においてITシステムは無くてはならないものとして急速に発展してきました。
ITシステムの利点の1つとして、人が居なくても24時間365日働いてくれるということが上げられると思いますが、それが当たり前となっている昨今では、たとえわずかな時間でも停止しようものなら、人々の生活に大きな影響を及ぼしてしまいます。
そんなITシステムの安定稼働を影で支えてくれているのが監視システムです。

例えば、会社員の方であれば年に1回は健康診断の場で身長や体重や血圧などを測って自分の健康状態を把握できるかと思いますが、ITシステムにおいては監視システムがITサービスを支えるサーバーやネットワーク機器等からデータを秒単位・分単位で収集し、常時監視の目を光らせています。
監視システムの用途
そんな監視システムの用途としてまず上げられるのが、障害発生の検知です。
前述の通り、監視システムは監視対象となる機器(ノード)から秒単位、分単位でデータを収集しており、事前に設定した閾値と呼ばれる数値を超えた(時には下回ったり)した場合にメールなどで管理者に知らせしてくれます。メールを受け取った管理者はその内容に応じて原因を特定し、復旧対応を行います。
また、監視システムはそういった障害発生の検知という”リアクティブな対応”のトリガーとしての役割の他にも、収集しているデータから、
・ メモリ使用量が増加傾向にある ⇒ サーバーのスペックをアップしよう!
・ハードディスクの使用量が増加傾向にある ⇒ どこかに過去のデータを退避しよう!
・ハードディスクの書き込みエラーが増えている ⇒ ハードディスクを交換しよう!
など、障害を未然に防ぐ、いわゆる”プロアクティブな対応”を行うためのトリガーとしての役割も担っています。
監視の種類について
人間の健康診断の場合でも体重や身長から血圧や血糖値、ガンマGTPや視力など様々な数値を計測しますが、コンピューターもCPUやメモリ、HDD、ネットワークカードなど様々なコンポーネントで構成されており、収集するデータも多岐にわたります。ITシステム監視は一般的には以下のような監視の種類があり、それぞれ監視対象となるITシステムの用途や仕様によって使い分けられています。
監視区分 | 主な監視対象 | 内容 |
---|---|---|
外形監視 | URL | 設定したURLにアクセスし、意図する応答コードが帰ってくるか、応答が遅くないか、特定文字列がコンテンツに含まれているか等を監視する。 |
死活監視 | サーバ(NIC)等に設定されたIPアドレス | 設定したIPアドレスに対して応答があるか。応答が遅くないか監視する。死活監視・遅延監視などに分けられる。 |
リソース 監視 | CPU、メモリ、HDD | 各リソースが枯渇していないか。使用率や空き容量を監視する。 |
SNMP 監視 | CPU、メモリ、電源、ファン、インターフェース、etc… | 装置の状態を監視する。こちらでリソース監視もできますが、ネットワーク監視向き。 |
サービス 監視 | ポートhttpd、chronyなどの各サービス | サービスが起動しているか(ポートが開いているか)、起動しているプロセス数が上限に達していないかなど監視する。 |
ログ監視 | システムログセキュリティログアプリケーションログ | 重要度(severity)”高”レベルのログが出力されていないか、ErrorやFailなどログに出力されていないか監視する。 |
その他 | SSL証明書 | SSL証明書の有効期限が切れていないか監視する。 |
AWS環境でのインスタンス(サーバー)監視について
AWSではCloudWatch、CloudWatchLogs、CloudWatch Synthetics等のサービスを使用して、各ノードからデータを収集することができ、それらの監視項目(メトリクス)に対してアラームを設定し、メールやチャットで通知することができます。
AWSではAutoScalingという、システムの負荷に応じて自動でインスタンス(サーバー)を増やしたり減らしたりしてサービスを継続させるという非常に有用な機能があるものの、監視アラームの設定面では不都合な部分がありました。
それは、動的に新規生成されたインスタンスには監視アラーム設定を引き継ぐ事が出来ず、手動で設定する必要があるということでした。(逆にインスタンスが消去された場合にはアラーム設定は残ったままとなります)
監視アラームは1台のインスタンスに対し十数個設定する必要があり、それが数台となると非常に面倒ですし、手動設定の場合に閾値設定など誤ってしまう可能性があります。
このため、私が管理するAWS環境では図のような仕組みを構築し、自動的に監視アラームを作成・削除できるように運用しています。

CloudWatchアラーム自動作成/削除の設定例
※ 実環境ではアラームが既に作成されていた場合のスキップ処理や、もっと多くのアラームの作成や削除処理を行っています。
■ EventBridgeのルール設定内容
AutoScalingのサンプルパターンを元にイベントパターンを設定します。
・ AutoScaling、EC2 Instance Launch Successfulのサンプルパターン

・ 上記サンプルパターンを元にした実際のイベントルール設定内容

■ Lambda関数の内容(ランタイムにRuby 2.7を使用)
・アラームの追加/削除の判別処理

・「EC2 Instance Launch Successful」の場合のCluoudWatchアラーム作成(標準メトリクス)

・ 「EC2 Instance Launch Successful」の場合のCluoudWatchアラーム作成(カスタムメトリクス)

・ 「 EC2 Instance Terminate Successful」の場合のCloudWatchアラーム削除

これで、AutoScalingによりインスタンスがLaunch(生成)かTeminate(終了)した場合にEventBridgeのトリガーが自動で発動し、LambdaによりCloudWatchアラームが作成/削除されるようになります。
最後に
20年近く前の話になりますが、私が初めてサーバーエンジニアとして従事させていただいた職場では、毎朝出社時に自分が担当する20台程度のサーバーに1台ずつSSHでログインし、エラーや見慣れない内容のログが出力されていないか、いつも以上に負荷が大きく(小さく)なっていないか、必要なプロセス起動されているか、ディスク容量に顕著な増減が見られないか、時刻がずれていないかなどを1つ1つコマンドを打って目視で確認していました。
それも昔の話で今ではZabbixやNagios、Cactiなど様々な監視プロダクトがあり、機能も日進月歩で向上しているため、適切な監視データの取得と監視アラームの設定がキチンとされていれば、システム断や大きな障害になる前に対処することも可能となります。
そんな監視システムも安定稼働を続けているITシステムにとっては、やっていることのほとんどが無駄となります。しかし、万が一の障害に備えて地道に稼働・監視し続ける監視システムはまさにITシステムの安定稼働を支える、影の立役者と言っても良いのではないでしょうか。