【目次】
・はじめに
・システム監視の考え方
- システム監視とは
- システム監視の検討ポイント
- システム監視のコンポーネント
・監視ポイント
- ビジネス監視
- フロントエンド監視
- アプリケーション監視
- サーバ監視
- ネットワーク監視
- セキュリティ監視
はじめに
システムを安定稼働させるためには「システム監視」が不可欠であり、稼働がストップすると困るようなシステムであれば、何かしら監視を行っていることでしょう。
しかし監視というのも一概ではなく、監視の設計によって良し悪しが出てきます。
保守運用されている人はご存じと思いますが、監視がしっかり設計されているシステムではトラブル発生しても迅速に対応できたり、トラブル予防措置も効率よく行えます。
逆に監視の設計が悪い場合は必要以上にコストや手間がかかってしまい、システム運用の足かせになることもあります。
システム監視の設計は重要なのですが、「いつもやっていることだから」ということで、深く検討せず従来通りの監視ルールを導入していないでしょうか。
または既に稼働しているシステムについても、不自由を感じながら監視方法の見直しを後回しにしてはいないでしょうか。
それらを振り返るためにも、システム監視についての考え方と設計ポイントについて見なおしていきましょう。
システム監視の考え方
システム監視とは
システムという言葉は含意が広いですが、ITシステムとして考えると特定のサービスを提供する仕組みを指すことが多いです。
システムは正常に稼働していることは当然であり、トラブルによりサービス提供できない状態になっては困るため、トラブルが発生したら迅速に復旧対応することが求められます。
そのためにはシステムの稼働状況を正しく把握する必要があり、システム監視の仕組みが必要になってきます。
ここで注意してほしいのですが、必要なのはシステムの安定稼働なので、ハードやアプリケーションを点で監視しても監視漏れが出ることがあります。
システム全体を俯瞰して、点でなく面で監視対象を検討する必要があります。
ただし監視ポイントは多岐にわたるため、それらを全てチェックする仕組みを構築するのは構築や運用のコストが上がるので現実的でありません。
そこで非機能要件においてシステム全体の中からサービス提供への影響が大きい部分にフォーカスして検討することになります。
システム監視の検討ポイント
システムを理解して監視ポイントを洗い出す
システム監視の目的はシステム全体の安定稼働であるため、単純に「サーバの死活監視をすればよい」という話ではありません。
トラブルが発生するとサービス提供に影響が出る箇所はどこなのか、その影響範囲はどこまでなのか監視ポイントを洗い出す必要があります。
監視ポイントの中から、予算や工期の範囲で対応できる対象を絞り込んでいきます。
監視対象の選定はユーザ目線を意識する
エンジニアが監視を設計すると、どうしても機械の正常動作を中心に確認したくなります。
しかし重要なのはサービス提供の安定稼働なので、サービスを利用するユーザ目線で考えることが大切です。
例えば、Webアプリケーションなどでユーザがリクエストをしてから応答までの時間が許容範囲に収まっているなら、CPUやメモリの使用率が高止まりの状況だったとしても問題ありません。（将来のトラブル抑止のためサーバ増強の検討は必要かもしれませんが）
しかしCPUやメモリが高負荷になってしまいリクエストの応答時間が許容範囲を超えてしまう場合は「トラブル」です。
この違いを意識することは大切です。
ツールありきで監視しない
対象システムの検討が進んでいないのに、先に監視方法が決まっていることがあります。
組織の標準ルールであったり、既存製品の監視ツール利用を指定されているなど理由はあると思います。
だからと言って、何も検討せずにツールありきで監視設計をするのはよくありません。
システムは千差万別なので、指定のツールではカバーできない監視項目があるかもしれません。
逆にツールの仕様によって機能が制限されることも考えられます。
既に監視ツールが決まっていたとしてもシステムの検討が進んだら、その監視設計で問題ないのか検討することが大切です。
基本は自作でなく既製の監視ツールを組み合わせる
監視ツールは原則として自前で作成するのではなく既製品のツールを組み合わせて構築します。
自作は既製品ではカバーできない特殊な監視のみとするべきです。
自作で作成する場合、監視ツールの品質を考慮する必要があります。
ツールを開発するにしても設計、製造、テストが必要になるのでコストも発生します。
監視方法の継続的改善
システムの機能改良など、後から監視ルールを変更することを考慮した監視設計にします。
独自の監視ツールを作成したり複雑な監視設定をすると、後から変更するのが困難になります。
また監視設定の内容はドキュメント化して、常に最新化していくことが大切です。
システム監視のコンポーネント
データ収集
システムの稼働状況を把握するための情報を収集します。
一般的にはログ、メトリクス情報を収集してデータとして格納します。
格納先は監視サーバなどに集約することになりますが、格納方法で注意することがあります。
各サーバがログなど出力するとき、出力先をローカルに格納してから転送するのか、直接ネットワーク越しに格納するのか検討が必要です。
リアルタイム監視が求められている場合を除き、原則はローカルにファイルを格納してからファイル転送する方法が良いと考えています。
理由は２つあります。
１つ目は、ネットワーク越しにアクセスするとネットワークのトラフィックが増えてしまい、結果としてシステムの処理遅延につながる可能性があるためです。
２つ目は、収集元と収集先のネットワークがつながらないとき、収集元サーバでログ出力ができずにトラブル発生となる可能性があります。
サーバ間を疎結合にすることは大切です。
可視化
収集データは情報の羅列なので状況がわかるように可視化します。
データを整理して数値化し、棒グラフや折れ線グラフ、ランキングなどで表現するとよいでしょう。
また、しきい値を設定して警告を発生したり分析／レポート機能を設けることも有効です。
ただ保守運用者がトラブルに気づきやすいように警告を出すことはよいですが、だからと言って、あれもこれも警告に出すのは避けるべきです。
警告情報が多すぎると重要度高の警告が埋もれて見落とす可能性があります。
何を警告として出すのか、監視設計で十分に検討する必要があります。
トラブル検知後のアクション
監視機能がトラブルを検知した場合、速やかに対処するための仕組みとしてアラートを利用することがあります。
アラートはトラブル対応を迅速に行うために必要なものですが、この設計が非常に重要です。
必要以上にアラートを発報させると保守運用者の「アラート疲れ」につながります。
まず、アラートには２つの使い方があります。
緊急対応のアラート
何があっても至急対応が必要な状況のときにアラート発報します。
監視者が検知してエンジニアをオンコールしたり、携帯端末でアラート発報することで通知します。
必要があれば夜中であっても対応することが要求されます。
情報提供としてのアラート
直ぐに対応が必要になるものでなく、後から気づけばよい程度の情報を発報します。
上記のうち、緊急対応のアラートがそこまで緊急でないのに発報される状況は良くありません。
アラートは次のことを意識することが大切です。
- アラートの重要度を定期的にメンテナンスする
- システムが自動復旧する仕組みを構築してアラートを減らす
- エンジニアをオンコールしなくても対処できるように手順書を作成する
- アラートが発生したトラブルへの予防策を検討する
監視ポイント
ビジネス監視
システムがビジネスKPIなどの事業達成目標を実現しているか監視します。
例えば新規顧客を獲得することを目標にするシステムについて「月間100人の新規顧客を獲得する」などのKPIがあった場合、その実績を評価することは大切です。
別の例でいうと、工場で各種センサーから収集したデータを5分以内に分析して表示することが求められているシステムであれば、現状どれくらいのレスポンスタイムなのか把握します。
KPIに達していないのであればシステムとして期待されている成果が出ていないことになるので改善が必要になります。
これらの情報を監視してレポートできる仕組みは事業継続の観点から必要です。
フロントエンド監視
フロントエンドとは、Webサービスなど直接ユーザが操作する部分のことです。
Webコンテンツやスマホアプリなどが該当します。
サーバ側で稼働するプログラムやDB操作などはバックエンドと呼びます。
Webコンテンツ
Webコンテンツではページロード時間とJavaScriptで発生する例外処理を監視します。
ユーザが画面操作してリクエストを出してからデータ取得し、HTMLやCSSの表示、JavaScriptなどのスクリプト実行などが完了して画面表示されるまでの時間を確認します。
サーバ処理が完了してリクエストを返すだけでなく、クライアント側の処理時間も考慮します。
またJavaScriptで発生した例外を収集することで品質改善することができます。
あらかじめエラー情報をサーバに渡すコードスニペット（特定の機能を実現した短いコード）を用意し、例外処理の中に記述します。
スマホ／タブレットアプリ
スマホやタブレットにインストールしたアプリでエラーが出たとしても、それをサーバ側でエラー情報を検知することは出来ません。
そのためクラッシュレポートなどの機能を利用してエラー情報のフィードバックを収集してアプリの改善を行います。
しかしエラーは幅広く発生するので全てに対処することは現実的でありません。
週次、月次など定期的にエラー情報を確認し、発生頻度の高いエラーや致命的なエラーなど優先度の高いものを選定して対処します。
アプリケーション監視
サーバで稼働しているアプリケーションを監視します。
Webサービスにおけるバックエンドは、このアプリケーションに含まれます。
ログ情報の監視
アプリケーションが出力したログを監視サーバがチェックします。
例えばログの中から「ERROR」など特定文字列のある行を収集し、アラート発報するなどの仕組みを設けます。
この仕組みを導入する場合、システム全体で統一した監視ルールが必要になります。
アプリケーションの機能ごとに「ERROR」を出すタイミングやルールが異なっていたら正しい監視は行えません。
そのため上流工程で監視ルールを策定し、実装前にはコーディングルールを用意して開発者に展開する必要があります。
パフォーマンス監視
アプリケーションの処理遅延はサービス提供の品質に直結するので、遅延の発生状況を確認できる仕組みを用意することは有効です。
また可能であればプログラムの各所に処理計測する仕組みを用意することで、処理遅延が発生するボトルネックの調査に使用することもできます。
ただし計測ポイントを入れすぎてレスポンス悪化につながらないように注意する必要はあります。
マイクロサービスの監視
マイクロサービスにおける監視は難易度が上がります。
システムで使用する各機能（サービス）を独立して疎結合するような環境の場合、ユーザのリクエストがどのサービスで処理されているのか把握することが困難になります。
その対策として、システムに入ってくるリクエストごとに一意となるIDをタグ付けします。
リクエストの流れをトレースするには、そのIDをキーとして検索すると良いでしょう。
サーバ監視
サーバ監視には多くの監視ポイントがあるので、よく使用される監視項目をピックアップします。
ちなみにサーバ監視ではNTPを導入して時刻同期することは必須です。
OSメトリクス監視
システム監視の対象としてよくあげられるのがOSメトリクス監視です。
CPUなどの使用状況を監視してサーバ負荷状況のチェックをします。
チェック対象としては、以下の項目があげられます。
- CPU
- メモリ
- ディスク
- ロードアベレージ
ただ、これらOSメトリクスにしきい値を設けてアラート発報するのは避けた方が良いでしょう。
必要なのはシステムが想定通りに稼働しており、正常にサービス提供できていることが重要です。
正常稼働しているならCPUが100%になっていても問題はなく、むやみにアラート発報してもアラートが形骸化するだけです。
OSメトリクスの情報を定期的にチェックし、サーバ増強計画やアプリケーション改善するための材料として活用します。
サービス／プロセス監視
サーバで稼働しているサービスやアプリケーションのプロセスが稼働しているのかチェックします。
必要なサービスやプロセスが起動していないということは、システムが正常に稼働していない状況であるため、迅速な対応が必要になります。
サーバ死活監視
システムが稼働しているサーバが稼働しているかチェックします。
当然、対象サーバが稼働していなければ即座に対処する必要があります。
死活監視の方法としてハートビート（定期的にpingなどの応答を確認する方法）があります。
ジョブスケジュール監視
ジョブ実行でエラーが発生したときの挙動を設定し、重要度の高いエラーであればアラート発報するなどの仕組みを入れます。
ジョブスケジューラのミドルウェアを導入していればエラー設定することができますが、タスクスケジューラやcronを使用して自前で作成している場合、監視サーバと連携するなどエラー検知の仕組みを作成する必要があります。
SMTP（メール）
システムでメール送受信を行っている場合、メール発信状況を監視する必要があります。
そこではメール送受信が正しく行われているか確認するだけでなく、メール発信が滞留していないことのチェックも行います。
時間あたりに発信できるメール件数よりも、発信対象のメールが多くなると滞留します。
そうなると発信すべき時間に間に合わないなどのトラブルになることもあります。
MQ（メッセージキュー）
上記のSMTPと同様、システム間で連携する電文のMQが滞留する場合もあります。
SSL証明書
通常、サーバのSSL証明書は保守運用で管理されるものですが、それでも更新漏れにより有効期限切れが発生しないようにSSL証明書の有効期限チェックを行うと安心です。
ドメインレジストラや認定局（CA）は有効期限切れを監視して通知する仕組みを提供している場合があるので活用するとよいでしょう。
もしなければ外部のサイト監視ツールを利用したり、社内用の監視ツールを作成するといった方法もあります。
ネットワーク監視
ネットワーク監視ではSNMPを使用したり、サーバからダミーのリクエストやパケットを投げてサーバ状態を監視します。
監視対象は次のものがあげられます。
- ネットワーク機器の死活監視
- サービス・プロトコル監視
- トラフィック監視
- TRAP監視
- エラーパケット監視
- ネットワークレスポンスタイム監視
- 帯域使用率
セキュリティ監視
セキュリティ監視は様々であり、提供されている監視サービスを活用する方法もあります。
自前で用意するのであれば、IDS（不正侵入検知システム）やIPS（不正侵入防止システム）を導入して不正アクセスを検知します。
WAF（Webアプリケーションファイアウォール）を利用して攻撃を検知することもあります。
またマルウェアなどの脅威がないのか監視して、問題を検知したら即座に対処します。
セキュリティ監視については、別記事「セキュリティ対策」を参照してください。
