この記事は「システム監視の基本」全2回シリーズの第2部です。
【第1部】システム監視の基本｜死活監視・エージェント監視・SNMP監視
監視の基本構造、死活監視、エージェント監視、SNMP監視、MIB・OIDなどを解説【第2部】この記事
クラウド監視、既存監視のFit & Gap、運用で使える監視設計を解説
はじめに
前編では、死活監視、エージェント監視、SNMP監視など、システム監視の基本的な仕組みを整理しました。
そこで確認したのは、ping が通ることと、システムが業務として正常に使えることは別だという点です。
サーバへの到達、プロセスの起動、HTTP/HTTPSの応答、業務処理の正常終了では、それぞれ確認しているレベルが異なります。
後編では、この考え方をクラウド環境へ広げます。
AWS CloudWatchやOCI Monitoringを使えば、自前の監視サーバを構築せずに、メトリクス、ログ、アラームを扱える場合があります。
しかし、クラウド監視サービスを使えば、監視設計が不要になるわけではありません。
- 標準メトリクスで足りるのか
- 既存監視をそのまま置き換えられるのか
- どの値を異常とするのか
- 誰に通知するのか
- 通知後に何を確認し、どう対応するのか
こうした点は、クラウドでも設計する必要があります。
特にオンプレミスからクラウドへ移行する場合は、既存監視をそのまま移すのではなく、何を引き継ぎ、何を標準機能で代替し、何を見直すのかというFit & Gapが重要になります。
監視は、アラートを出すための設定ではありません。
障害に気づき、判断し、対応につなげるための設計です。
クラウド監視とは何か
前編で説明した監視構成は、オンプレミスや従来型の監視製品を前提としたものでした。
一方、クラウドでは監視の実現方法が少し変わります。
クラウドでは、クラウドベンダーが用意する監視サービスを使って、仮想サーバ、ストレージ、ロードバランサ、データベース、ネットワーク、サーバレス、コンテナなどのメトリクス、ログ、イベントを収集できます。
そのため、従来のように自前で監視サーバを立てて、すべてのサーバに監視エージェントを導入し、監視製品を運用する、という構成が必ずしも必要ではありません。ただし、ここで誤解してはいけないことがあります。
クラウド監視サービスがあることと、監視設計が不要になることは別です。
クラウド監視サービスは、監視を実現するための部品です。
何を監視するのか。 どの値を異常とするのか。 どの条件で通知するのか。 通知を受けた人が何を確認するのか。 既存システムで行っていた監視を新システムでも継続するのか。
ここは、設計で決める必要があります。
特にオンプレミスからクラウドへ移行する業務システムでは、既存監視の引き継ぎが大きな論点になります。
クラウド監視サービスの代表例
クラウド監視サービスは、クラウドベンダーごとに用意されています。
AWSであれば、CloudWatch。 Azureであれば、Azure Monitor。
Google Cloudであれば、Cloud Monitoring。
OCIであれば、OCI Monitoring。
それぞれ名称や機能の範囲は異なりますが、基本的には、クラウド上のリソースからメトリクス、ログ、イベントを収集し、条件に応じてアラームや通知につなげるためのサービスです。
この記事では、AWSでよく使われるCloudWatchを中心に説明します。
あわせて、Oracle DatabaseやOracle製品を利用している業務システムではOCIが選択肢になることもあるため、OCI Monitoringについても簡単に触れます。
AWS CloudWatchの場合
AWS CloudWatchは、AWS上のリソースを監視するための代表的なサービスです。
EC2、RDS、ELB、EBS、Lambda、ECS、EKSなど、AWS上の多くのサービスはCloudWatchにメトリクスを出力できます。
たとえば、EC2であればCPU使用率、ネットワーク送受信量、ディスクI/Oなどを確認できます。
RDSであれば、CPU使用率、DB接続数、ストレージ容量、読み書きIOPSなどを確認できます。ELBであれば、リクエスト数、ターゲットの正常性、HTTPエラー数、レスポンスタイムなどを確認できます。
CloudWatchでは、こうしたメトリクスに対してアラームを設定できます。
たとえば、CPU使用率が一定時間以上高い状態が続いたら通知する。 RDSの空き容量が少なくなったら通知する。 ELB配下の正常ターゲット数が減ったら通知する。 アプリケーションログに特定のエラーメッセージが出たら通知する。
このように、CloudWatchはAWS上のシステム監視における基本的な部品になります。ただし、CloudWatchを使えばすべてが自動で完璧に監視されるわけではありません。
標準メトリクスで足りるのか。 詳細監視が必要なのか。 CloudWatch Agentを入れてOS内部のメモリやディスク使用率を取得するのか。 アプリケーションログをCloudWatch Logsへ送るのか。 ログのどの文字列を異常として拾うのか。 アラーム閾値をどう設定するのか。 通知先をどうするのか。 通知を受けた人が何を確認するのか。
これらは設計が必要です。
特にオンプレミスからAWSへ移行する場合、既存の監視をCloudWatchだけでそのまま置き換えられるとは限りません。
JP1、Systemwalker、Zabbix、PFM for Oracle、Oracle Enterprise Managerなどで見ていた監視項目が、CloudWatchの標準メトリクスだけで同じ粒度で取得できるとは限らないからです。
そのため、AWSへ移行する場合でも、CloudWatchで何が見えるかだけではなく、既存監視で何を見ていたのか、新システムでも同じ監視が必要なのか、必要ならCloudWatchで代替できるのか、できない場合は何で補うのかを整理する必要があります。
OCI Monitoringの場合
OCIでも、クラウドネイティブな監視サービスがあります。
代表的なのがOCI Monitoringです。
OCI Monitoringを使うと、OCI上のコンピュート、ストレージ、ロードバランサ、データベース、ネットワーク関連リソースなどのメトリクスを収集し、条件に応じてアラームを設定できます。
OCIのComputeインスタンスでは、プラグインを有効化することで、インスタンスの状態やメトリクスを取得できる構成もあります。
ただし、OCI Monitoringを使えば、Oracle Databaseの性能監視や既存の運用監視がすべて自動で置き換わるわけではありません。
Oracle Databaseを利用している業務システムでは、OCI Monitoringで見るもの、Oracle Database側の機能で見るもの、OEMで見るもの、ログ監視で見るもの、運用手順で確認するものを分けて考える必要があります。
特に、既存システムでOracle Database、Oracle Enterprise Manager、AWR、ASH、Performance Hub、PFM for Oracleなどを利用していた場合、クラウド移行後にどの監視を何で代替するのかを整理する必要があります。
Oracle系システムでは、DB性能、待機イベント、SQL、セッション、表領域、アラートログなど、DB内部の監視観点が重要になることがあります。
そのため、OCI Monitoringだけで考えるのではなく、Oracle Databaseの監視機能や既存運用を含めて、全体として監視設計を行う必要があります。
クラウド移行では、既存監視のFit & Gapが必要
クラウド移行といっても、完全な新規開発ばかりではありません。
実務では、既存のオンプレミスシステムをクラウドへ移すリフト＆シフトや、移行後に段階的にクラウドネイティブ化していくケースが多くあります。
その場合、移行前のシステムで行っていた監視を、移行後にどう引き継ぐかが大きな論点になります。
既存環境では、JP1、Systemwalker、Zabbix、PFM for Oracle、Oracle Enterprise Managerなどで、OS、ジョブ、ログ、DB性能、表領域、待機イベント、SQL、アラートログなどを監視していたかもしれません。
では、それをクラウド移行後に同じように見られるのでしょうか。答えは、簡単ではありません。
クラウド移行後の監視Fit & Gapでは、少なくとも次の3つに整理して考える必要があります。
1. 既存監視を標準機能で置き換えられるもの
PFM for Oracleや既存監視製品で見ていた内容を、OEM、AWR、ASH、Performance Hub、CloudWatch、Performance Insights、Database Insightsなどで代替できる場合は、新環境の標準機能に寄せる判断があります。
この場合、既存監視をそのまま機械的に移植するのではなく、新環境で標準的に提供されている監視機能を使い、運用をシンプルにできないかを検討します。
2. 標準機能だけでは置き換えられないもの
一方で、既存監視で見ていた項目が、新環境の標準機能では取得できない、または同じ粒度で監視できない場合もあります。
その場合は、代替方式を検討します。
別のメトリクスで代替できるのか。 ログ監視で拾えるのか。 スクリプトで補完できるのか。 外部監視製品やAPMを使うのか。 そもそも新環境でも本当に必要な監視なのか。
ここを整理せずに進めると、オンプレでは見えていた異常が、クラウド移行後に見えなくなることがあります。
3. 代替するか、捨てるか、運用でカバーするもの
標準機能で置き換えられない監視については、最終的に判断が必要です。
手組みしてでも実装するのか。 別製品を追加して実現するのか。 運用手順でカバーするのか。 監視対象から外すのか。
監視を外す場合は、障害検知が遅れる可能性、一次対応への影響、サービスレベルへの影響を説明し、リスク受容として顧客と合意する必要があります。
ここで重要なのは、プロジェクト側だけで勝手に決めないことです。
既存システムで実装されていた監視には、多くの場合、過去の障害、運用上の要請、監査対応、顧客側の不安、サービスレベル上の理由があります。
そのため、単に「新しい製品ではできないのでやりません」とは言いにくいことがあります。
技術的には実現できない。 実現はできるがコストが高すぎる。 手組みすれば可能だが保守性が悪い。 運用カバーで十分と判断できる。 リスクを受容して監視対象から外す。
こうした判断を、要件、コスト、運用負荷、障害時の影響、顧客の期待値を踏まえて整理します。
クラウド移行時の監視設計で重要なのは、既存監視を機械的に移植することではありません。
業務システムとして必要な異常検知、性能把握、一次対応、エスカレーションが、新システムでも成立するかを確認することです。
そのうえで、できること、できないこと、代替すること、やめることを顧客と合意する。ここまで含めて、新システムの監視設計です。
監視対象・目的で見た監視の種類
ここで重要なポイントは、「監視方式」と「監視対象・監視目的」を混同しないことです。
この中で、若手SEが特に理解しておくべきなのは、死活監視だけでは業務正常性は分からないという点です。
サーバに ping が通っていても、Web画面がエラーになっているかもしれません。 Web画面が開いても、検索処理が失敗するかもしれません。 DBプロセスが起動していても、表領域が枯渇して更新できないかもしれません。 バックアップジョブが正常終了していても、リストアできないかもしれません。
だからこそ、監視設計では「何をもって正常と判断するのか」を決める必要があります。
監視方式は「何を知りたいか」から選ぶ
監視方式を選ぶときに大事なのは、製品や流行から入らないことです。
まず決めるべきなのは、「何を知りたいのか」です。
- サーバが起動しているかを知りたいなら、死活監視です。
- Webサービスが応答しているかを知りたいなら、URL監視です。
- OS内部のCPUやメモリを知りたいなら、リソース監視です。
- DBプロセスが動いているかを知りたいなら、プロセス監視です。
- DBとしてログインできるかを知りたいなら、DB接続監視です。
- ログに異常メッセージが出ていないか知りたいなら、ログ監視です。
- ストレージやネットワーク機器の状態を知りたいなら、SNMP監視や製品API監視です。
- クラウドリソースの状態を知りたいなら、CloudWatchやOCI Monitoringなどのクラウド監視サービスです。
監視方式は、目的によって変わります。
逆に言えば、監視方式だけを決めても意味がありません。
「SNMPで監視します」では不十分です。
- SNMPで何を監視するのか。
- どのOIDを見るのか。
- どのTrapを受けるのか。
- 重大度をどう判定するのか。
- 通知先はどこか。
- 一次対応手順は何か。
ここまで決めて初めて、監視設計になります。
監視設計で決めること
監視設計では、最低限、次のような項目を決めます。
- 監視対象
- 監視項目
- 監視方式
- 監視間隔
- 閾値
- 検知条件
- 除外条件
- 重大度
- 通知先
- 通知方法
- 監視抑止条件
- メンテナンス時の扱い
- 一次対応手順
- エスカレーション先
- 復旧確認方法
- 監視設定の変更手順
- 監視条件の見直しタイミング
たとえば、CPU使用率の監視でも、単に「CPUを監視する」では足りません。
- CPU使用率が何％を超えたら警告なのか。
- 何分継続したら異常なのか。
- 瞬間的なスパイクは除外するのか。
- 夜間バッチ中は閾値を変えるのか。
- 警告と異常で通知先を分けるのか。
- 通知を受けたら、運用者は何を見るのか。
- AP担当、DB担当、基盤担当のどこへ連絡するのか。
ここまで決める必要があります。
監視は、アラートを出すことが目的ではありません。
アラートを受けた人が判断できることが目的です。
監視でよくある誤解
監視でよくある誤解は、次の3つです。
そのため、監視設計は、設計時点で決めて終わりではありません。
システムテスト、運用テスト、本番リハーサル、本番稼働後の初期期間を通じて、見直す前提が必要です。
システム基盤エンジニアが持つべき監視の見方
まず持ってほしいのは、「監視は設定項目ではなく、運用の入口である」という見方です。
監視アラートは、障害対応のスタート地点です。
アラートが出た瞬間に、運用者は判断を求められます。
- これは本当に障害なのか。
- 無視してよい通知なのか。
- すぐにエスカレーションすべきなのか。
- まず手順書に沿って確認すべきなのか。
- 復旧したと言える条件は何か。
この判断ができるように設計するのが、監視設計です。
- 監視サーバがある。
- エージェントが入っている。
- CloudWatchにメトリクスが出ている。
- OCI Monitoringにアラームがある。 MIBを読み込ませた。
それだけでは、監視設計としては不十分です。
重要なのは、検知した後に運用が動けることです。
まとめ｜クラウドでも、監視の本質は変わらない
クラウド監視サービスを使えば、メトリクス、ログ、アラームを扱いやすくなります。
しかし、CloudWatchやOCI Monitoringを使えば、監視設計そのものが不要になるわけではありません。
特にオンプレミスからクラウドへ移行する場合は、既存監視をそのまま移植するのではなく、
- 標準機能で置き換えられるもの
- 標準機能だけでは置き換えられないもの
- 代替するもの、運用でカバーするもの、監視対象から外すもの
に分けて、Fit & Gapを整理する必要があります。そのうえで、
- 何を監視するのか。
- どの条件で異常と判断するのか。
- 誰に通知するのか。
- 通知後に誰が何を確認し、どう対応するのか。
まで設計して初めて、監視は運用で使える仕組みになります。
監視で重要なのは、たくさんのアラートを出すことではありません。
本当に検知すべき異常を、運用で判断・対応できる形で検知することです。
監視は、アラートを出すための設定ではなく、障害に気づき、判断し、対応につなげるための設計です。
前編では、監視する側・監視される側という基本構造から、死活監視、エージェント監視、エージェントレス監視、SNMP監視、MIB・OIDまで、システム監視の基礎を整理しています。
関連記事
監視設計は、単独で完結するものではありません。
非機能要件で求める可用性や運用性を整理し、詳細設計で監視条件へ落とし込み、テスト・運用につなげていく必要性については次の記事で説明しています。
- 【全3回・第3部】監視・ログ・バックアップ・セキュリティの詳細設計｜運用で使える設計にする観点
監視対象、閾値、通知、ログ監視条件、運用スクリプトなど、監視を詳細設計でどう具体化するかを整理しています
- 機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う点
可用性、性能、運用・保守性など、監視設計の前提となる非機能要件を整理しています。
- 要件定義とは何をする工程か｜RFP・見積前提から認識差を潰す実務
監視を含む非機能要件を、設計に入る前の要件定義でどこまで具体化するのかを解説しています。
- システム開発の全体像｜アプリ・基盤・非機能はどうつながるのか
要件定義、設計、構築、テスト、運用まで、監視設計がシステム開発全体のどこに位置するのかを整理しています。
コメント