システムの運用監視とは？業務の進め方やログ・メトリクスの違いも紹介

2022年12月27日

専門性が求められるITの世界においても、システムの運用監視は特に専門性が高い分野といえます。運用監視とはどのような業務なのでしょうか。また、その業務はどのように進めればよいのでしょうか。この記事では、運用監視の概要に加え、ログやメトリクス、トレースなど運用監視において収集対象となる項目の解説や、運用監視の立ち上げフローについて紹介します。

日本を含む2,000社以上での導入実績がある、
IT統合監視サービス「LogicMonitor」とは？

運用監視とは

システムがその価値を生み出すためには、安定的に動作しつつ、異常発生時には早期の対応を行い、安定稼動の継続もしくは速やかな復旧対応作業を行う必要があります。

そのために必要となるのが、システムの運用監視です。システムの稼働状況を監視し、異常が発生していないか、もしくは異常が発生する予兆がないかを確認します。

主な監視対象

システムの運用監視における主な監視対象は以下の通りです。近年では、クラウドサービスの利用やコンテナによる仮想化など、新たな技術の導入も進んでいます。これらを含めて、システムを構成するあらゆる要素を監視対象とする必要があります。

サーバー：システムが稼働するハードウェアとしてのサーバーを監視する。仮想サーバーについても監視対象となる。
コンテナ：DockerやKubernetesなど、コンテナに関するサービス状況を監視する。
OS：稼働状況の死活監視に加え、使用リソース量などを監視する。
ミドルウェア：データベースやWebサーバーなどに対して監視を行う。
アプリケーション：構築したアプリケーションのアクセス数やログイン数、エラーログなどを監視する。
ネットワーク：サーバー間もしくはサーバーとユーザー間を接続するネットワーク回線やネットワーク機器に異常が発生していないかを監視する。
クラウドサービス（IaaS/PaaS/SaaS）：クラウドサービスの利用状況を把握できるようにする。

主な監視項目

主に監視対象とする項目は以下の通りです。各監視対象の特性によって、必要な項目をチェックできるようにします。

死活監視：サーバーやネットワークが稼動しているかを確認する
ハードウェア監視：ハードウェアが物理的に稼動しているか、故障などの異常が発生していないかを確認する。
プロセス監視：プロセスの起動数やサービスの状態を監視する。
ログ監視：出力されたイベントログなどを監視し、異常が発生していないかを確認する。
リソース監視：CPUやメモリ、ディスク容量などの使用量、使用率を監視する。

システム監視のために収集する情報

運用監視においては、システムの状態を様々な情報を基に把握する必要があります。具体的には、「ログ」「メトリクス」「トレース」の3つを把握していくことが基本です。

ログ

OSやアプリケーションなどは、イベント発生状況や動作状況に応じてログを出力します。アプリケーションのバッチ処理が正常に終了した場合や、データベースの更新に失敗した場合など、ログが出力されるタイミングは様々です。

ログは、障害やイレギュラーの発生内容を把握するための情報源となります。障害が発生した際には、ログの内容を確認し、どのような障害が発生したのか調査します。また、ログを追っていくことで、障害発生の根本的な原因追及も可能となります。

ログ管理で気を付けなければならないのが、ログのローテーションです。ログファイルはディスク容量を多く消費します。よって、ディスク容量を確保するために定期的なファイルの切り分けや、別ストレージへの退避、消去などのローテーション処理を行っていく必要があります。

「ログローテーションの処理がうまくいかず、ログが残っていない」という事態は避けなければなりません。ログを用いた監視を行う場合は、システムのログローテーション運用についてもある程度の設計が必要です。

メトリクス

メトリクスとは、システムの内部状態をとらえるために収集される情報のことです。

具体的には、CPUの利用率やディスクの容量などをイメージするとわかりやすいでしょう。システムの監視においては、これらの情報を一定間隔ごとに収集し、異常が発生していないかを確認します。

メトリクスの把握においては「ゲージ」と「カウンタ」という2つの考え方があります。

ゲージは、現時点での状況を数値化するもので、たとえばスピードメーターをイメージするとわかりやすいでしょう。カウンタは、これまでの累積値を出力するものです。カウンタの例としては、自動車の総走行距離をイメージするとわかりやすいかもしれません。

メトリクスは一般的に、時系列データとして収集されることになります。よって、時間の経過に応じて値を折れ線グラフで表示するなど、可視化を行うことで状況を把握しやすくなります。

たとえば、CPUの使用量を時系列の折れ線グラフで表示すれば、いつからどの程度CPUリソースが大量消費されているかを一目で把握できるでしょう。

トレース

近年では、マイクロサービスにより設計されたシステムも増加しており、サーバーやアプリケーションは単一のものでなく、複数のコンポーネントに分かれて動作しています。このような状況においては「エラーが発生した個所」と「原因となっている箇所」が離れていることも多いといえます。

このような現代的なシステムを監視するためには、連続する処理を追いかけて、どのような流れで処理を実施したのかを確認する必要があります。これがトレースです。

たとえば、Webサイト上でユーザーが商品の購入処理を実施したとします。この時、システムの裏側では「決済処理」「在庫データベース更新処理」「会員照合処理」「画面描画処理」などが実行されることになります。システムがマイクロサービスで設計されている場合、これらの処理は様々な場所（コンテナ）にて実施されることになります。

このようなシステムにおいて商品の購入処理が遅延した場合には、どの処理が原因となっているかを調査しなければなりません。

このとき、処理がどのような流れで実施されているかを把握できるトレースが便利です。調査の結果、「データベース更新処理に遅延が生じていた」というように、原因を把握することができます。

運用監視の進め方

それでは、運用監視を実施するためにはどのような作業が必要となるのでしょうか。以下では、監視を始めるまでの流れを紹介します。

監視方針の定義

あらゆる仕事に共通する話ではありますが、監視においても目的や方針を定めることは重要です。

通常、監視はシステムを定期的・継続的に観測し、異常を検知、復旧することを目的に実施します。しかしながら、対象となるシステムの特性により、実際に対応する際の判断基準は異なります。

たとえば、多数のユーザーを抱えるシステムであれば、何より復旧対応が優先されるでしょう。システムの停止中は売り上げが発生しないなど、ビジネスに与える影響は甚大なものとなります。一方で、業務上正確性が何よりも重要であるシステムにおいては、明確な原因が究明されるまでは安易に復旧をさせない方がベターである可能性もあります。

このようにシステムの特性を踏まえて、監視方針を定義します。

また、方針に基づきKPI・SLIを定めることも重要です。一般的には可用性などがKPI・SLIとなります。これらの目標を達成するべく、必要な体制構築や業務設計を行うことになります。

情報収集・システム構成の確認

障害発生時には、ステークホルダーへの速やかな連絡をはじめとしたコミュニケーションが必要となります。よって、監視対象システムのステークホルダーの洗い出しが必要です。

また、障害発生時の情報公開をどのように行うかについても検討します。FAXやメール、自社のコーポレートサイト、広報SNSなど、システム外で情報共有ができる場所を確保しておくべきです。

監視対象となるシステムの構成を把握することも必須です。それぞれのコンポーネントの依存関係やデータフロー、処理フローを把握します。これにより、障害発生時の影響確認や原因究明を素早く行えるようにします。

なお、障害発生時や原因分析時には、（システムを構成するミドルウェアやOSなどを提供する）外部ベンダーのサポート窓口とのやり取りが必要となるケースがあります。有事の際にも迅速に連絡が取れるように、緊急連絡先の一元管理等が非常に大切です。

監視ツールの実装

アプリケーションやサーバーなどの稼働状況を手動で確認するのは非現実的です。監視を行うためには、システムに監視ツールを導入する必要があります。

ツールの選び方はさまざまですが、近年ではクラウド上でシステムを稼働させるケースが一般化しているため、オンプレミス・クラウドの両方に対応しているツールを選ぶべきでしょう。

また、監視業務を行うためには、後述するドキュメンテーションのためのツールや障害発生時のコミュニケーションツール、チケット管理ツールなども併せて必要となります。

ドキュメンテーション

運用監視においてドキュメンテーションは非常に重要です。障害発生時には、短時間での対応が求められるため、必要な情報を整理して記述しておきます。

具体的には、監視対象のシステム概要やステークホルダー、システム構成図といった基本的な内容に加え、監視項目や項目ごとの確認方法、作業実施手順などを整理します。

ドキュメントはシステムとは別の領域に保管しておきます。システム障害によりドキュメントも同時に閲覧できなくなってしまっては、障害復旧もままなりません。

通知・発報のテスト

ツールの導入後は必ずテストを実施します。いざという時に正しく障害を検知できなければ、監視を行う意味がありません。

リリース前のシステムであれば、比較的テストは実施しやすいといえます。一方で、リリース済みのシステムにおいて、通知や発報のテストを実施する際には工夫が必要です。実際にシステムに異常を起こすのではなく、閾値を変更して疑似的に障害を発生させたり、事前にステークホルダーに案内して本当に障害が発生したと勘違いされないようにしたりする必要があります。

なお、近年ではシステムの堅牢さを確かめるために「意図的に」障害を発生させる「カオスエンジニアリング」という手法も実施されるようになりました。もちろん、意図的に障害を発生させて本当にシステムが停止しないように注意する必要はありますが、実施を検討してみても良いでしょう。