※この記事は「システム監視の基本」前編・後編シリーズの後編です。
前編はこちら
監視には、監視する側である監視サーバーや監視マネージャーがあり、監視される側である
Webサーバ、APサーバ、DBサーバ、ストレージ、ネットワーク機器があります。
また、死活監視、エージェント監視、エージェントレス監視、SNMP監視といった方式があり、監視したい内容に応じて使い分ける必要があります。
前編で特に強調したのは、ping が通ることと、システムが業務として正常に使えることは別だという点です。
サーバに到達できること。
プロセスが起動していること。
ポートが待ち受けていること。
HTTP/HTTPSで応答が返ること。
業務シナリオが正常に完了すること。
これらは、それぞれ確認しているレベルが違います。
また、SNMP監視では、MIBやOIDを理解することも重要です。
ただし、MIBを登録しただけでは監視設計は終わりません。
どのOIDを監視するのか。
どの値を警告・異常とするのか。
どのTrapを通知対象にするのか。
どのアラートを除外するのか。
テスト工程で発報内容をどう精査するのか。
ここまで考えて初めて、監視は運用で使える仕組みになります。
後編では、クラウド監視に話を進めます。
AWS CloudWatchやOCI Monitoringのようなクラウドネイティブな監視では、自前の監視サーバーを構築しなくても、メトリクス、ログ、アラームを扱える場合があります。
しかし、クラウド監視サービスを使えば、監視設計が不要になるわけではありません。
標準メトリクスで足りるのか。 エージェントやプラグインが必要なのか。 どの条件でアラームを出すのか。 誰に通知するのか。 通知を受けた人が何を確認するのか。
クラウドでも、オンプレミスでも、監視の本質は同じです。
監視は、アラートを出すための設定ではありません。障害に気づき、判断し、対応につなげるための設計です。
クラウド監視とは何か
ここまで説明してきた監視構成は、どちらかというとオンプレミスや従来型の監視製品を前提にしています。
一方、クラウドでは考え方が少し変わります。
クラウドでは、クラウドベンダーが用意する監視サービスを使って、仮想サーバ、ストレージ、ロードバランサ、データベース、ネットワーク、サーバレス、コンテナなどのメトリクス、ログ、イベントを収集できます。
そのため、従来のように自前で監視サーバーを立てて、すべてのサーバに監視エージェントを導入し、監視製品を運用する、という構成が必ずしも必要ではありません。ただし、ここで誤解してはいけないことがあります。
クラウド監視サービスがあることと、監視設計が不要になることは別です。
クラウド監視サービスは、監視を実現するための部品です。
何を監視するのか。 どの値を異常とするのか。 どの条件で通知するのか。 通知を受けた人が何を確認するのか。 既存システムで行っていた監視を新システムでも継続するのか。
ここは、設計で決める必要があります。
特にオンプレミスからクラウドへ移行する業務システムでは、既存監視の引き継ぎが大きな論点になります。
クラウド監視サービスの代表例
クラウド監視サービスは、クラウドベンダーごとに用意されています。
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つです。
そのため、監視設計は、設計時点で決めて終わりではありません。
システムテスト、運用テスト、本番リハーサル、本番稼働後の初期期間を通じて、見直す前提が必要です。
若手SEに持ってほしい監視の見方
若手SEにまず持ってほしいのは、「監視は設定項目ではなく、運用の入口である」という見方です。
監視アラートは、障害対応のスタート地点です。
アラートが出た瞬間に、運用者は判断を求められます。
これは本当に障害なのか。
無視してよい通知なのか。
すぐにエスカレーションすべきなのか。
まず手順書に沿って確認すべきなのか。
復旧したと言える条件は何か。
この判断ができるように設計するのが、監視設計です。
監視サーバーがある。
エージェントが入っている。
CloudWatchにメトリクスが出ている。
OCI Monitoringにアラームがある。 MIBを読み込ませた。
それだけでは、監視設計としては不十分です。
重要なのは、検知した後に運用が動けることです。
まとめ
クラウド監視サービスを使えば、メトリクス、ログ、アラームを扱いやすくなります。しかし、監視設計が不要になるわけではありません。
特にオンプレミスからクラウドへ移行する業務システムでは、既存監視をどう扱うかが重要です。
既存監視を標準機能で置き換えられるもの。
標準機能だけでは置き換えられないもの。
代替するか、捨てるか、運用でカバーするもの。
この3つに分けて、Fit & Gapを整理する必要があります。
監視で大事なのは、たくさん検知することではありません。
本当に検知すべき異常を、運用で対応できる形で検知することです。
監視は、アラートを出すための設定ではありません。
障害に気づき、判断し、対応につなげるための設計です。
詳細設計の中で監視をどう設計するか、ログ監視条件をシステムテスト以降にどう見直すか、監視と運用手順をどうつなげるかについては、以下の記事でも詳しく整理しています。
前編では、監視サーバーの構成、死活監視、エージェント監視、エージェントレス監視、SNMP監視の基本を整理しています。
あわせて読みたい
詳細設計で決めること 後編②｜監視・ログ・バックアップ・セキュリティ・運用スクリプト
機能要件と非機能要件の違い
システム開発の流れを現場目線で理解する｜前編
要件定義の正体
コメント