特開 2024-15673 監視支援装置、監視支援方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024015673

(43)【公開日】2024-02-06

(54)【発明の名称】監視支援装置、監視支援方法及びプログラム

(51)【国際特許分類】

   G06F 11/32 20060101AFI20240130BHJP

   G06F 11/34 20060101ALI20240130BHJP

   G06F 11/30 20060101ALI20240130BHJP

【ＦＩ】

G06F11/32 130

G06F11/34 176

G06F11/30 140G

【審査請求】未請求

【請求項の数】12

【出願形態】ＯＬ

(21)【出願番号】P 2022117900

(22)【出願日】2022-07-25

(71)【出願人】

【識別番号】000005234

【氏名又は名称】富士電機株式会社

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(72)【発明者】

【氏名】大室 善則

【テーマコード（参考）】

5B042

【Ｆターム（参考）】

5B042JJ20

5B042JJ30

5B042KK13

5B042MA08

5B042MA10

5B042MA11

5B042MA14

5B042MC21

5B042MC31

5B042NN08

(57)【要約】

【課題】複数のアプリケーションの連携により実現されるサービスの監視を支援できる技術を提供すること。
【解決手段】本開示の一態様による監視支援装置は、複数のアプリケーションの連携により実現されるサービスの異常兆候の監視を支援する監視支援装置であって、前記監視の対象となるサービスを表す対象サービスと、前記監視の対象となる期間を表す対象期間とを受け付けるように構成されている受付部と、前記対象サービスを実現する複数のアプリケーションに対して、前記対象期間のログを要求するように構成されている要求部と、前記要求に対する応答として前記複数のアプリケーションから返信されたログを用いて、前記対象期間における前記対象サービスの異常兆候の有無を監視するための情報を可視化するように構成されている可視化部と、を有する。
【選択図】図１０

【特許請求の範囲】

【請求項1】

複数のアプリケーションの連携により実現されるサービスの異常兆候の監視を支援する監視支援装置であって、
前記監視の対象となるサービスを表す対象サービスと、前記監視の対象となる期間を表す対象期間とを受け付けるように構成されている受付部と、
前記対象サービスを実現する複数のアプリケーションに対して、前記対象期間のログを要求するように構成されている要求部と、
前記要求に対する応答として前記複数のアプリケーションから返信されたログを用いて、前記対象期間における前記対象サービスの異常兆候の有無を監視するための情報を可視化するように構成されている可視化部と、
を有する監視支援装置。

【請求項2】

前記要求部は、
サービスと、該サービスを実現するアプリケーションとが対応付けられたテーブルを参照して、前記対象サービスを実現する複数のアプリケーションを特定し、特定した複数のアプリケーションに対して、前記対象期間のログを要求するように構成されている、請求項１に記載の監視支援装置。

【請求項3】

前記テーブルには、前記アプリケーションが前記サービスを識別するサービス種別が更に対応付けられており、
前記要求部は、
前記テーブルを参照して、前記対象サービスを実現する複数のアプリケーションと、前記複数のアプリケーションの各々で前記対象サービスを識別するサービス種別とを特定し、特定した複数のアプリケーションに対して、前記アプリケーションに対応するサービス種別のログであって、かつ、前記対象期間のログを要求するように構成されている、請求項２に記載の監視支援装置。

【請求項4】

前記可視化部は、
前記要求に対する応答として前記複数のアプリケーションから返信されたログから総合ログを作成し、前記対象期間における前記対象サービスの異常兆候の有無を監視するための情報として前記総合ログを可視化するように構成されている、請求項１乃至３の何れか一項に記載の監視支援装置。

【請求項5】

前記可視化部は、
１回の前記対象サービスを実現する処理の前記総合ログ毎に、前記総合ログを時系列順に可視化するように構成されている、請求項４に記載の監視支援装置。

【請求項6】

前記総合ログは、
前記要求に対する応答として前記複数のアプリケーションから返信されたログ、又は、前記ログに対して返信元のアプリケーションに関する情報を付与した情報、のいずれかである、請求項５に記載の監視支援装置。

【請求項7】

前記総合ログから所定の指標値を算出するように構成されている指標値算出部を更に有し、
前記可視化部は、
前記指標値から判定された前記異常兆候の有無を表すラベルを更に可視化するように構成されている、請求項６に記載の監視支援装置。

【請求項8】

前記指標値算出部は、
１回の前記対象サービスを実現する処理において時間的に隣接する総合ログ間の時間幅と、予め設定された前記総合ログ間の標準的な時間幅との差分を前記指標値として算出するように構成されており、
前記可視化部は、
前記差分と、予め設定された許容時間幅との大小関係により前記ラベルの値を判定し、判定した前記値を持つラベルを可視化するように構成されている、請求項７に記載の監視支援装置。

【請求項9】

前記可視化部は、
前記差分と、前記許容時間幅との比を更に可視化するように構成されている、請求項８に記載の監視支援装置。

【請求項10】

前記許容時間幅には、第１の許容時間幅と、該第１の許容時間幅より大きい第２の許容時間とが含まれ、
前記可視化部は、
前記差分が前記第１の許容時間幅未満である場合、前記ラベルの値として前記異常兆候が無いことを表す値を判定し、
前記差分が前記第１の許容時間幅以上かつ前記第２の許容時間幅未満である場合、前記ラベルの値として前記異常兆候が発生する危険性があることを表す値を判定し、
前記差分が前記第２の許容時間幅以上である場合、前記ラベルの値として前記異常兆候があることを表す値を判定する、請求項８に記載の監視支援装置。

【請求項11】

複数のアプリケーションの連携により実現されるサービスの異常兆候の監視を支援する監視支援装置が、
前記監視の対象となるサービスを表す対象サービスと、前記監視の対象となる期間を表す対象期間とを受け付ける受付手順と、
前記対象サービスを実現する複数のアプリケーションに対して、前記対象期間のログを要求する要求手順と、
前記要求に対する応答として前記複数のアプリケーションから返信されたログを用いて、前記対象期間における前記対象サービスの異常兆候の有無を監視するための情報を可視化する可視化手順と、
を実行する監視支援方法。

【請求項12】

複数のアプリケーションの連携により実現されるサービスの異常兆候の監視を支援する監視支援装置に、
前記監視の対象となるサービスを表す対象サービスと、前記監視の対象となる期間を表す対象期間とを受け付ける受付手順と、
前記対象サービスを実現する複数のアプリケーションに対して、前記対象期間のログを要求する要求手順と、
前記要求に対する応答として前記複数のアプリケーションから返信されたログを用いて、前記対象期間における前記対象サービスの異常兆候の有無を監視するための情報を可視化する可視化手順と、
を実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、監視支援装置、監視支援方法及びプログラムに関する。

【背景技術】

【0002】

一般に、アプリケーションは様々なログを出力している。例えば、アプリケーションに対する操作情報、アプリケーションの動作情報（内部動作、外部動作）、エラーや故障等といった異常事象に関する情報等がログとして出力される。これらのログは、アプリケーションに異常が発生した際の異常要因の特定や影響範囲の解析等といった異常発生後の調査作業等に用いられることが多いが（例えば、特許文献１等を参照）、異常兆候の検出等といった異常発生前の監視作業でも活用することができる。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１９－４６２１５号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

ここで、複数のアプリケーションが連携して或る特定のサービスを提供しているような場合には、異常発生前の監視作業のために、そのサービスを提供している各アプリケーションのログが必要になることがある。しかしながら、例えば、ログの肥大化を防止するためといった理由等により、各アプリケーションは、一部のログ（例えば、異常発生時のログ等）しか外部に出力していない場合がある。この場合、必要なログが入手できず、異常兆候を検出するための監視作業が困難になる。

【0005】

本開示は、上記の点に鑑みてなされたもので、複数のアプリケーションの連携により実現されるサービスの監視を支援できる技術を提供することを目的とする。

【課題を解決するための手段】

【0006】

本開示の一態様による監視支援装置は、複数のアプリケーションの連携により実現されるサービスの異常兆候の監視を支援する監視支援装置であって、前記監視の対象となるサービスを表す対象サービスと、前記監視の対象となる期間を表す対象期間とを受け付けるように構成されている受付部と、前記対象サービスを実現する複数のアプリケーションに対して、前記対象期間のログを要求するように構成されている要求部と、前記要求に対する応答として前記複数のアプリケーションから返信されたログを用いて、前記対象期間における前記対象サービスの異常兆候の有無を監視するための情報を可視化するように構成されている可視化部と、を有する。

【発明の効果】

【0007】

複数のアプリケーションの連携により実現されるサービスの監視を支援できる技術が提供される。

【図面の簡単な説明】

【0008】

【図1】複数のアプリケーションの連携により実現されるサービスの一例を説明するための図である。

【図2】第一の実施形態に係るログ管理システムの全体構成の一例を示す図である。

【図3】第一の実施形態に係るアプリケーション処理装置の機能構成の一例を示す図である。

【図4】第一の実施形態に係る監視支援装置の機能構成の一例を示す図である。

【図5】サービスとアプリケーションとサービス種別の関係の一例を説明するための図である。

【図6】サービス種別テーブルの一例を示す図である。

【図7】第一の実施形態に係る個別ログの作成及び保存処理の一例を説明するための図である。

【図8】個別ログの一例を示す図である。

【図9】第一の実施形態に係るログ可視化処理の一例を説明するための図である。

【図10】ログ可視化の一例を説明するための図（その１）である。

【図11】ログ可視化の一例を説明するための図（その２）である。

【図12】異常兆候の検出方法の一例を説明するための図（その１）である。

【図13】異常兆候の検出方法の一例を説明するための図（その２）である。

【図14】異常兆候の検出方法の一例を説明するための図（その３）である。

【図15】第二の実施形態に係る監視支援装置の機能構成の一例を示す図である。

【図16】標準時間テーブルの一例を示す図である。

【図17】第二の実施形態に係るログ可視化処理の一例を説明するための図である。

【図18】ログ可視化の一例を説明するための図（その３）である。

【図19】コンピュータのハードウェア構成の一例を示す図である。

【発明を実施するための形態】

【0009】

以下、本発明の一実施形態として第一の実施形態と第二の実施形態について説明する。

【0010】

［第一の実施形態］
本実施形態では、複数のアプリケーションの連携により実現されるサービスを対象として、それらのサービスを実現する各アプリケーションのログを取得することで、異常兆候を検出するための監視作業を支援することができるログ管理システム１について説明する。なお、異常兆候とは、未だ異常の発生には至ってないが、将来的に異常が発生する蓋然性が高い事象のことである。以下、アプリケーションを「アプリ」とも呼ぶことにする。

【0011】

＜複数のアプリケーションの連携により実現されるサービス＞
複数のアプリケーションの連携により実現されるサービスの一例を図１に示す。図１では、アプリＡ１とアプリＢとアプリＣの連携により実現されるサービスＸと、アプリＡ２とアプリＢとアプリＣの連携により実現されるサービスＹとを示している。

【0012】

図１に示すように、サービスＸは、アプリＡ１の処理を行った後、その処理結果を用いてアプリＢの処理を行い、更にその処理結果を用いてアプリＣの処理を行うことで実現されるサービスである。同様に、サービスＹは、アプリＡ２の処理を行った後、その処理結果を用いてアプリＢの処理を行い、更にその処理結果を用いてアプリＣの処理を行うことで実現されるサービスである。

【0013】

サービスＸの具体例としては、例えば、デジタル機器の画像をアプリＡ１で撮像し、その画像をアプリＢで画像解析により数値に変換し、その数値データをアプリＣでデータベースに保存する、等といったサービスが挙げられる。同様に、サービスＹの具体例としては、例えば、アナログ機器の画像をアプリＡ２で撮像し、その画像をアプリＢで画像解析により数値に変換し、その数値データをアプリＣでデータベースに保存する、等といったサービスが挙げられる。ただし、これらのサービスの具体例はいずれも一例であって、これに限られるものではない。

【0014】

なお、上記のような複数のアプリケーションの連携によりサービスを実現する手法又はアーキテクチャは「マイクロサービス・アーキテクチャ」とも呼ばれる。一方で、１つのアプリケーションにより１つのサービスを実現する手法又はアーキテクチャは「モノリシック・アーキテクチャ」とも呼ばれる。マイクロサービス・アーキテクチャでは、複数のアプリケーションの各々は小さなサービス（つまり、マイクロサービス）を提供し、これらのマイクロサービスを連携又は組み合わせることで、目的とする様々なサービスが実現される。

【0015】

＜ログ管理システム１の全体構成例＞
本実施形態に係るログ管理システム１の全体構成例を図２に示す。図２に示すように、本実施形態に係るログ管理システム１には、１以上のアプリケーション処理装置１０と、ログ格納装置２０と、監視支援装置３０とが含まれる。また、これらの各装置は、例えば、ＬＡＮ（Local Area Network）等の通信ネットワークＮを介して通信可能に接続されている。

【0016】

アプリケーション処理装置１０は、１以上のアプリケーション１００を有し、これらのアプリケーション１００の処理を実行する。１以上のアプリケーション処理装置１０により複数のアプリケーション１００の処理が実行されることで、上記のサービスＸやサービスＹのようなマイクロサービス・アーキテクチャによるサービスが実現される。ここで、各アプリケーション１００は、重要度に応じて段階的にレベル分けされたログ（以下、個別ログという）を出力するものとする。

【0017】

ログ格納装置２０は、アプリケーション１００の個別ログを格納する。ログ格納装置２０は、アプリケーション１００から出力された個別ログの中で或るレベル以上の個別ログ（例えば、異常発生を表す個別ログ）が格納される個別ログ記憶部２１０を有する。

【0018】

監視支援装置３０は、監視支援プログラム３００を有しており、この監視支援プログラム３００により総合ログと呼ぶとログを作成し、それらの総合ログをサービス毎に可視化する。より具体的には、可視化対象となる総合ログの条件（以下、可視化対象条件ともいう。）が与えられたときに、監視支援プログラム３００は、その可視化対象条件を満たす個別ログを取得すると共に総合ログを作成し、それらの総合ログをサービス毎に可視化する。この可視化によって、ユーザ（例えば、各サービスを監視するオペレータ等）は、所望のサービスの総合ログを参照し、そのサービスに異常兆候が存在するか否かを確認することが可能となる。

【0019】

なお、図１に示すログ管理システム１の全体構成は一例であって、これに限られるものではなく、他の構成であってもよい。例えば、ログ格納装置２０と監視支援装置３０とが一体で構成されていてもよい。より具体的には、例えば、監視支援装置３０が個別ログ記憶部２１０を有しており、ログ格納装置２０は無くてもよい。

【0020】

＜アプリケーション処理装置１０及び監視支援装置３０の機能構成例＞
本実施形態に係るアプリケーション処理装置１０と監視支援装置３０の機能構成例について説明する。

【0021】

≪アプリケーション処理装置１０≫
本実施形態に係るアプリケーション処理装置１０の機能構成例を図３に示す。図３に示すように、本実施形態に係るアプリケーション処理装置１０は、アプリケーション処理部１０１と、個別ログ管理部１０２と、内部ログ記憶部１０３とを有する。アプリケーション処理部１０１と個別ログ管理部１０２は、例えば、アプリケーション１００が、ＣＰＵ（Central Processing Unit）等の演算装置に実行させる処理により実現される。また、内部ログ記憶部１０３は、例えば、ＳＳＤ（Solid State Drive）やＨＤＤ（Hard Disk Drive）等の補助記憶装置により実現される。

【0022】

アプリケーション処理部１０１は、アプリケーション１００の固有の処理を実行する。ここで、アプリケーション１００の固有の処理（以下、固有処理ともいう。）とは、そのアプリケーション１００のマイクロサービスを提供するための処理のことを意味するものとする。

【0023】

また、アプリケーション処理部１０１は、個別ログの保存対象となる事象（イベント）が発生した場合にログ保存要求を個別ログ管理部１０２に送信する。

【0024】

個別ログ管理部１０２は、アプリケーション処理部１０１からのログ保存要求に応じて、アプリケーション１００の固有処理で発生した事象の個別ログを作成し、内部ログ記憶部１０３に保存する。ここで、ログ保存要求にはログレベルとサービス種別とメッセージとが少なくとも指定されており、個別ログ管理部１０２は、ログレベルとサービス種別とメッセージに対して現在日時を付与することで個別ログを作成する。

【0025】

ログレベルとは、個別ログが表す事象（イベント）の重要度に応じて予め決められたレベルのことである。以下、一例として、ログレベルには、定常処理中の事象であることを表す「ＩＮＦＯ」、例外処理中の事象であることを表す「ＮＯＴＩＣＥ」、警告すべき事象であることを表す「ＷＡＲＮ」、異常事象であることを表す「ＥＲＲＯＲ」の４つがあるものとする。ただし、これは一例であって、ログレベルは事象の重要度に応じて任意の定義することが可能である。なお、「ＩＮＦＯ」、「ＮＯＴＣＥ」、「ＷＡＲＮ」及び「ＥＲＲＯＲ」は、例えば、それぞれ「０」、「１」、「２」及び「３」と数値で表現されてもよい。

【0026】

定常処理中の事象、例外処理中の事象、警告すべき事象及び異常事象として、それぞれどのような事象が存在するかは、マイクロサービスを提供するアプリケーション１００によって異なり得る。定常処理中の事象の一例としては、例えば、ログイン、ログアウト、画面表示、機器の復旧、アラーム抑制・解除等といった事象が挙げられる。例外処理中の事象の一例としては、例えば、目標値の変更操作やシステム停止操作等といった事象が挙げられる。警告すべき事象の一例としては、例えば、データ欠損、軽度又は中程度のエラー、軽度又は中程度の故障、上限値又は下限値の超過等といった事象が挙げられる。異常事象の一例としては、例えば、システム停止やデータ異常につながる重大なエラー、重大な故障等といった事象が挙げられる。

【0027】

サービス種別とは、アプリケーション１００の固有処理で実現されるサービスを識別するための情報である。これにより、例えば、或るアプリケーション１００の固有処理で複数のサービスが実現される場合であっても、いずれのサービスの個別ログであるかがサービス種別により識別される。例えば、図１に示す例では、アプリＢとアプリＣはその固有処理によりサービスＸとサービスＹの両方を実現することができるため、いずれのサービスの個別ログであるかをサービス種別により識別する。

【0028】

メッセージとは、個別ログが表す事象を端的に表現する文字列（例えば、当該事象の概要を表す文字列等）のことである。

【0029】

また、個別ログ管理部１０２は、或るログレベル（以下、これを「設定ログレベル」ともいう）以上の個別ログを個別ログ記憶部２１０に保存する。ここで、どのログレベルを設定ログレベルとするかは任意に設定することが可能であるが、以下では、一例として、「ＥＲＲＯＲ」を設定ログレベルとする。これにより、「ＥＲＲＯＲ」以上の個別ログが個別ログ記憶部２１０に保存される。

【0030】

更に、個別ログ管理部１０２は、後述する個別ログ取得要求を監視支援装置３０から受信すると、この個別ログ取得要求で要求された個別ログを内部ログ記憶部１０３から取得し、個別ログ取得要求に対する応答として当該監視支援装置３０に返信する。

【0031】

内部ログ記憶部１０３は、例えば、アプリケーション１００の名称等が付与されたフォルダ等であり、個別ログ管理部１０２により作成された個別ログを記憶する。

【0032】

なお、１つのアプリケーション処理装置１０が複数のアプリケーション１００を有している場合には、当該アプリケーション処理装置１０は、アプリケーション１００毎に、アプリケーション処理部１０１と個別ログ管理部１０２と内部ログ記憶部１０３とを有している。

【0033】

≪監視支援装置３０≫
本実施形態に係る監視支援装置３０の機能構成例を図４に示す。図４に示すように、本実施形態に係る監視支援装置３０は、条件受付部３０１と、個別ログ要求部３０２と、総合ログ管理部３０３と、ログ可視化部３０４と、サービス種別テーブル記憶部３０５と、総合ログ記憶部３０６とを有する。条件受付部３０１と個別ログ要求部３０２と総合ログ管理部３０３とログ可視化部３０４は、例えば、監視支援プログラム３００が、ＣＰＵ等の演算装置に実行させる処理により実現される。また、サービス種別テーブル記憶部３０５と総合ログ記憶部３０６は、例えば、ＳＳＤやＨＤＤ等の補助記憶装置により実現される。

【0034】

条件受付部３０１は、与えられた可視化対象条件を入力として受け付ける。可視化対象条件には、可視化対象となる総合ログの期間を表す対象期間と、可視化対象となる総合ログのサービスを表す対象サービスとが含まれる。なお、可視化対象条件は、例えば、ユーザ等の入力操作によって与えられてもよいし、他のプログラムから与えられてもよいし、監視支援装置３０と通信ネットワークＮを介して接続される他の端末又は機器等から与えられてもよい。

【0035】

個別ログ要求部３０２は、サービス種別テーブル記憶部３０５に記憶されているサービス種別テーブルを参照して、可視化対象条件に含まれる対象サービスを実現する各アプリケーション１００と当該アプリケーション１００で対象サービスを識別するサービス種別とを特定する。そして、個別ログ要求部３０２は、特定したアプリケーション１００に対して個別ログ取得要求を送信する。ここで、個別ログ取得要求には、送信先のアプリケーション１００が対象サービスを識別するサービス種別と、当該可視化対象条件に含まれる対象期間とが指定される。

【0036】

総合ログ管理部３０３は、個別ログ取得要求に対する応答として各アプリケーション１００から返信された個別ログから総合ログを作成した上で、それらの総合ログをサービス毎に日時順に総合ログ記憶部３０６に格納する。総合ログとは、ログ可視化部３０４によって可視化対象となるログのことであり、例えば、個別ログそのものを総合ログとしてもよいし、個別ログに対して何等かの情報（例えば、その個別ログを返信したアプリケーション１００の名称や識別子等）を付与したものであってもよい。

【0037】

ログ可視化部３０４は、総合ログ記憶部３０６に記憶されている総合ログをサービス毎に可視化する。

【0038】

サービス種別テーブル記憶部３０５は、対象サービスからアプリケーション１００及びサービス種別を特定するためのサービス種別テーブルを記憶する。ここで、一例として、図１に示すサービスＸとサービスＹが存在し、図５に示すように、アプリＡ１はサービス種別「ａ１」でサービスＸを識別し、アプリＢはサービス種別「ｂ１」でサービスＸを識別し、アプリＣはサービス種別「ｃ１」でサービスＸを識別しているものとする。同様に、アプリＡ２はサービス種別「ａ２」でサービスＹを識別し、アプリＢはサービス種別「ｂ２」でサービスＹを識別し、アプリＣはサービス種別「ｃ２」でサービスＹを識別しているものとする。このとき、サービス種別テーブルの一例を図６に示す。図６に示すサービス種別テーブルでは、サービスＸに対して、アプリケーションＡ１及びサービス種別ａ１と、アプリケーションＢ及びサービス種別ｂ１と、アプリケーションＣ及びサービス種別ｃ１とが対応付けられている。同様に、サービスＹに対して、アプリケーションＡ２及びサービス種別ａ２と、アプリケーションＢ及びサービス種別ｂ２と、アプリケーションＣ及びサービス種別ｃ２とが対応付けられている。

【0039】

このように、サービス種別テーブルでは、サービス毎に、そのサービスを実現するアプリケーション１００とそのアプリケーション１００で当該サービスを識別するサービス種別とが対応付けられている。これにより、対象サービスを実現するアプリケーション１００とそのアプリケーション１００で対象サービスを識別するサービス種別とを特定することが可能となる。

【0040】

総合ログ記憶部３０６は、総合ログ管理部３０３によって格納された総合ログを記憶する。

【0041】

＜個別ログの作成及び保存処理＞
本実施形態に係る個別ログの作成及び保存処理の一例について、図７を参照しながら説明する。以下のステップＳ１０１～ステップＳ１０５の処理は、各アプリケーション処理装置１０において、アプリケーション処理部１０１からログ保存要求が送信されるたびに繰り返し実行される。

【0042】

アプリケーション処理装置１０の個別ログ管理部１０２は、ログレベルとサービス種別とメッセージとが指定されたログ保存要求を受信する（ステップＳ１０１）。

【0043】

次に、アプリケーション処理装置１０の個別ログ管理部１０２は、上記のステップＳ１０１で受信したログ保存要求に指定されているログレベル、サービス種別及びメッセージに対して現在日時を付与して個別ログを作成する（ステップＳ１０２）。ここで、個別ログの一例を図８に示す。図８に示すように、個別ログには、日時と、ログレベルと、サービス種別と、メッセージとが含まれる。

【0044】

次に、アプリケーション処理装置１０の個別ログ管理部１０２は、上記のステップＳ１０２で作成した個別ログを内部ログ記憶部１０３に保存する（ステップＳ１０３）。

【0045】

次に、アプリケーション処理装置１０の個別ログ管理部１０２は、上記のステップＳ１０２で作成した個別ログのログレベルが設定ログレベル以上であるか否かを判定する（ステップＳ１０４）。

【0046】

上記のステップＳ１０４で個別ログのログレベルが設定ログレベル以上であると判定されなかった場合、アプリケーション処理装置１０は、個別ログの作成及び保存処理を終了する。一方で、上記のステップＳ１０４で個別ログのログレベルが設定ログレベル以上であると判定された場合、アプリケーション処理装置１０の個別ログ管理部１０２は、上記のステップＳ１０２で作成した個別ログを個別ログ記憶部２１０に保存する（ステップＳ１０５）。このように、個別ログ記憶部２１０には、設定ログレベル以上のログレベルの個別ログのみが格納される。これにより、「ＥＲＲＯＲ」以上の個別ログのみが個別ログ記憶部２１０に保存され、ログの肥大化が防止される。

【0047】

＜ログ可視化処理＞
本実施形態に係るログ可視化処理の一例について、図９を参照しながら説明する。なお、可視化対象条件が監視支援装置３０に与えられたときに、以下のステップＳ２０１～ステップＳ２０７の処理の実行が開始される。

【0048】

監視支援装置３０の条件受付部３０１は、与えられた可視化対象条件を入力として受け付ける（ステップＳ２０１）。なお、例えば、対象期間と対象サービスのいずれか一方が可視化対象条件に含まれない場合もあり得る。このため、対象期間が可視化対象条件に含まれない場合、条件受付部３０１は、例えば、予め決められた期間（例えば、全期間や現時点から過去所定の期間等）を対象期間として受け付ければよい。同様に、対象サービスが可視化対象条件に含まれない場合、条件受付部３０１は、予め決められたサービス（例えば、全サービスや予め決められた１つ以上の特定のサービス等）を対象サービスとして受け付ければよい。

【0049】

次に、監視支援装置３０の個別ログ要求部３０２は、サービス種別テーブル記憶部３０５に記憶されているサービス種別テーブルを参照して、上記のステップＳ２０１で受け付けた可視化対象条件に含まれる対象サービスを実現するアプリケーション１００とそのアプリケーション１００で対象サービスを識別するサービス種別とを特定する（ステップＳ２０２）。すなわち、個別ログ要求部３０２は、サービス種別テーブルを参照して、対象サービスに対応付けられているアプリケーション１００及びサービス種別を特定する。

【0050】

例えば、上記のステップＳ２０１で受け付けた可視化対象条件に含まれる対象サービスが「サービスＸ」及び「サービスＹ」であり、サービス種別テーブルが図６に示すようなものであるとする。この場合、サービスＸに関しては、アプリ「Ａ１」及びサービス種別「ａ１」と、アプリ「Ｂ」及びサービス種別「ｂ１」と、アプリ「Ｃ」及びサービス種別「ｃ１」とが特定される。同様に、サービスＹに関しては、アプリ「Ａ２」及びサービス種別「ａ２」と、アプリ「Ｂ」及びサービス種別「ｂ２」と、アプリ「Ｃ」及びサービス種別「ｃ２」とが特定される。

【0051】

次に、監視支援装置３０の個別ログ要求部３０２は、上記のステップＳ２０２で特定された各アプリケーション１００（より正確には、そのアプリケーション１００を有するアプリケーション処理装置１０）に対して、それに対応するサービス種別で、上記のステップＳ２０１で受け付けられた可視化対象条件に含まれる対象期間の個別ログ取得要求を送信する（ステップＳ２０３）。

【0052】

すなわち、個別ログ要求部３０２は、まず、各サービス種別と対象期間とを指定した個別ログ取得要求を作成する。例えば、上記のステップＳ２０２で特定されたアプリケーション１００及びサービス種別が、サービスＸに関しては、アプリ「Ａ１」及びサービス種別「ａ１」、アプリ「Ｂ」及びサービス種別「ｂ１」、アプリ「Ｃ」及びサービス種別「ｃ１」であり、サービスＹに関しては、アプリ「Ａ２」及びサービス種別「ａ２」、アプリ「Ｂ」及びサービス種別「ｂ２」、アプリ「Ｃ」及びサービス種別「ｃ２」であったものとする。また、対象期間が［ｔ１，ｔ２］であるものとする。この場合、個別ログ要求部３０２は、（ａ１，ｔ１，ｔ２）、（ｂ１，ｔ１，ｔ２）、（ｃ１，ｔ１，ｔ２）、（ａ２，ｔ１，ｔ２）、（ｂ２，ｔ１，ｔ２）、（ｃ２，ｔ１，ｔ２）といった６つの個別ログ取得要求を作成する。そして、個別ログ要求部３０２は、個別ログ取得要求（ａ１，ｔ１，ｔ２）と（ａ２，ｔ１，ｔ２）をアプリ「Ａ１」、個別ログ取得要求（ｂ１，ｔ１，ｔ２）と（ｂ２，ｔ１，ｔ２）をアプリ「Ｂ」、個別ログ取得要求（ｃ１，ｔ１，ｔ２）と（ｃ２，ｔ１，ｔ２）をアプリ「Ｃ」にそれぞれ送信する。

【0053】

アプリケーション処理装置１０の個別ログ管理部１０２は、個別ログ取得要求を監視支援装置３０から受信すると、当該個別ログ取得要求に指定されているサービス種別の個別ログであって、かつ、当該個別ログ取得要求に指定されている対象期間内の個別ログを内部ログ記憶部１０３から取得する（ステップＳ２０４）。

【0054】

そして、アプリケーション処理装置１０の個別ログ管理部１０２は、上記のステップＳ２０４で取得された個別ログを、個別ログ取得要求に対する応答として監視支援装置３０に返信する（ステップＳ２０５）。

【0055】

監視支援装置３０の総合ログ管理部３０３は、上記のステップＳ２０２で特定されたすべてのアプリケーション１００からの応答が完了した場合、これらの応答として返信された個別ログから総合ログを作成した上で、サービス毎に日時順に総合ログ記憶部３０６に格納する（ステップＳ２０６）。なお、サービスは、個別ログに含まれるサービス種別とサービス種別テーブルから特定される。

【0056】

これにより、サービス毎に、総合ログが日時順に総合ログ記憶部３０６に格納される。なお、総合ログは、各アプリケーション１００から応答として返信された個別ログそのものであってもよいし、個別ログに対して何等かの情報（例えば、その個別ログを返信したアプリケーション１００の名称や識別子等）を付与したものであってもよい。

【0057】

そして、監視支援装置３０のログ可視化部３０４は、総合ログ記憶部３０６に記憶されている総合ログをサービス毎に可視化する（ステップＳ２０７）。なお、ログ可視化部３０４は、例えば、監視支援装置３０が備えるディスプレイ上に総合ログを可視化してもよいし、監視支援装置３０と通信ネットワークを介して接続される端末や機器が備えるディスプレイ上に総合ログを可視化してもよい。

【0058】

＜ログ可視化例＞
以下、図９のステップＳ２０７における総合ログの可視化例について説明する。以下では、一例として、サービスＸを実現する際にアプリＡ１は「ログＡ１－１」と「ログＡ１－２」を個別ログとして出力し、アプリＢは「ログＢ－１」と「ログＢ－２」と「ログＢ－３」を個別ログとして出力し、アプリＣは「ログＣ－１」と「ログＣ－２」を個別ログとして出力するものとする。同様に、サービスＹを実現する際にアプリＡ２は「ログＡ２－１」と「ログＡ２－２」を個別ログとして出力し、アプリＢは「ログＢ－１」と「ログＢ－２」と「ログＢ－３」を個別ログとして出力し、アプリＣは「ログＣ－１」と「ログＣ－２」を個別ログとして出力するものとする。また、簡単のため、総合ログは個別ログそのものであるとする。

【0059】

また、図１０の上図に示す個別ログが総合ログとして総合ログ記憶部３０６に格納されているものとする。なお、図１０の上図では、縦軸が個別ログの名称、横軸が日時ｔを表している。

【0060】

このとき、図９のステップＳ２０７における総合ログの可視化例を図１０の下図に示す。図１０の下図に示すように、サービス毎に総合ログが区分けされて可視化されている。しかも、サービスＸでは、ログＡ１－１とログＡ１－２、ログＡ１－２とログＢ－１、ログＢ－１とログＢ－２、ログＢ－２とログＢ－３、ログＢ－３とログＣ－１、ログＣ－１とログＣ－２がそれぞれ線分で接続されている。同様に、サービスＹでは、ログＡ２－１とログＡ２－２、ログＡ２－２とログＢ－１、ログＢ－１とログＢ－２、ログＢ－２とログＢ－３、ログＢ－３とログＣ－１、ログＣ－１とログＣ－２がそれぞれ線分で接続されている。すなわち、各サービスにおいて、そのサービスを実現する処理の開始から終了までの間で日時ｔが隣接する総合ログ同士がそれぞれ線分で接続されている。以下、このように線分で接続された総合ログを「ロググラフ」と呼ぶことにする。なお、ロググラフは、サービス１回あたりの処理で出力された総合ログの集合を表している。

【0061】

図１０の下図では、サービスＸのロググラフとサービスＹのロググラフとが区別可能に同一の領域内に可視化されているが、サービスＸのロググラフとサービスＹのロググラフとが異なる領域内に可視化されていてもよい。例えば、図１１に示す例では、サービスＸのロググラフ１００１～１００３と、サービスＹのロググラフ２００１～２００３とが異なる領域内に可視化されている。

【0062】

＜異常兆候の検出例＞
図１０の下図や図１１に示すように総合ログを可視化することで、ユーザはこれらの総合ログを参照し、対象サービスに異常兆候が存在するか否かを確認することができる。

【0063】

例えば、サービス１回あたりの処理で出力される各総合ログの時間間隔は、同一サービスであり、かつ、サービスに何等の異常兆候も存在しなければ、通常、大きく異ならないと考えられる。このため、例えば、サービスＹに何等の異常兆候も存在しなければ、図１２に示すように、ロググラフ２００１～ロググラフ２００３は互い類似する形状となる。

【0064】

また、同様に、ロググラフ内の或る特定のアプリの総合ログのみを取り出しても、その取り出した部分は互いに類似する形状となる。例えば、サービスＹに何等の異常兆候も存在しなければ、図１３に示すように、ロググラフ２００１～ロググラフ２００３のアプリＢの総合ログを取り出した部分は互いに類似する形状となる。

【0065】

したがって、ユーザは、ロググラフ全体又はその一部の形状が非類似となった場合に、そのロググラフによって表されるサービスの異常兆候を検出することができる。例えば、図１４に示すように、サービスＹのロググラフ２１０１～ロググラフ２１０３が可視化されているものとする。図１４に示す例では、ログＢ－１とログＢ－２の間の時間（つまり、この間の処理時間）が徐々に長くなっており、ロググラフ２１０１と比べて、ロググラフ２１０２～ロググラフ２１０２全体及びその一部の形状が徐々に非類似になっている。言い換えれば、図１４に示す例では、ロググラフ２１０２～ロググラフ２１０２の形状が時間経過に伴って変化していると言える。これにより、ユーザは、これらのロググラフ２１０１～ロググラフ２１０３によって表されるサービスＹの異常兆候を検出することができる。

【0066】

このように、ユーザは、対象サービスの総合ログによって表現されるロググラフ（又は、当該ロググラフ内の或る特定のアプリの総合ログが表す部分）の形状に着目し、それらの形状が時間経過に伴って変化する場合、当該対象サービスに異常兆候が存在すると検出する。これにより、ユーザは、実際に異常が発生する前に、その異常の兆候を知ることが可能となり、例えば、異常の発生を防止する様々な対策（例えば、機器や部品の交換等）を行うことが可能となる。

【0067】

［第二の実施形態］
次に、第二の実施形態について説明する。第一の実施形態ではロググラフの形状の時間経過に伴う変化からユーザが異常兆候を検出する場合について説明したが、本実施形態では、ロググラフの形状から異常兆候か存在し得るかを表す情報（後述するラベル）を更に可視化する場合について説明する。これにより、ユーザは、対象サービスに異常兆候が存在するか否かをより容易に判断することが可能となる。

【0068】

なお、本実施形態では、主に、第一の実施形態との相違点について説明し、第一の実施形態と同様の構成要素については同一の符号を付与し、その説明を省略するものとする。

【0069】

＜監視支援装置３０の機能構成例＞
本実施形態に係る監視支援装置３０の機能構成例を図１５に示す。図１５に示すように、本実施形態に係る監視支援装置３０は、指標値算出部３０７と、標準時間テーブル記憶部３０８とを更に有する。指標値算出部３０７は、例えば、監視支援プログラム３００が、ＣＰＵ等の演算装置に実行させる処理により実現される。また、標準時間テーブル記憶部３０８は、例えば、ＳＳＤやＨＤＤ等の補助記憶装置により実現される。

【0070】

指標値算出部３０７は、標準時間テーブル記憶部３０８に記憶されている標準時間テーブルを参照して、各ロググラフを構成する隣接ログ毎に、対象サービスに異常兆候が存在し得るか否かを判定するための指標値として、その隣接ログ間の処理時間と後述する標準処理時間との差分を算出する。なお、隣接ログとは、対象サービスを実現する処理の開始から終了までの間で日時ｔが隣接する総合ログのことである。

【0071】

標準時間テーブル記憶部３０８は、対象サービスに異常兆候が存在し得るか否かを判定するための指標値の算出とその判定とに用いられる標準時間テーブルを記憶する。ここで、標準時間テーブルの一例を図１６に示す。図１６に示すように、標準時間テーブルでは、各隣接ログ間に対して、標準的な処理時間を表す標準処理時間と、標準処理時間との差分に関して「正常」であるか否かを判定するための閾値を表す第１の許容時間と、当該差分に関して「警告」又は「異常兆候あり」のいずれであるかを判定するための閾値を表す第２の許容時間とが対応付けられている。ここで、「警告」とは、異常兆候は存在しないが、異常兆候が発生する危険性があることを意味している。なお、第１の許容時間＜第２の許容時間である。

【0072】

例えば、図１６に示す例では、隣接ログ間「ログＢ－１からログＢ－２」に対して、標準処理時間Ｓ_ｍ、第１の許容時間α_ｍ、第２の許容時間β_ｍが対応付けられている。これは、ログＢ－１からログＢ－２の間の処理時間と標準処理時間Ｓ_ｍとの差分が第１の許容時間α_ｍ未満であれば「正常」、当該差分が第１の許容時間α_ｍ以上かつ第２の許容時間β_ｍ未満であれば「警告」、当該差分が第２の許容時間β_ｍ以上であれば「異常兆候あり」と判定されることを意味している。

【0073】

同様に、例えば、図１６に示す例では、隣接ログ間「ログＢ－２からログＢ－３」に対して、標準処理時間Ｓ_ｍ＋１、第１の許容時間α_ｍ＋１、第２の許容時間β_ｍ＋１が対応付けられている。これは、ログＢ－２からログＢ－３の間の処理時間と標準処理時間Ｓ_ｍ＋１との差分が第１の許容時間α_ｍ＋１未満であれば「正常」、当該差分が第１の許容時間α_ｍ＋１以上かつ第２の許容時間β_ｍ＋１未満であれば「警告」、当該差分が第２の許容時間β_ｍ＋１以上であれば「異常兆候あり」と判定されることを意味している。

【0074】

なお、図１６に示す例では、隣接ログ間として「ログＢ－１からログＢ－２」と「ログＢ－２からログＢ－３」とが図示されているが、これは一例であって、標準時間テーブルには、各隣接ログ間に対して標準処理時間と第１の許容時間と第２の許容時間とが対応付けられている。

【0075】

ログ可視化部３０４は、第一の実施形態と同様にサービス毎に総合ログを可視化することに加えて、指標値算出部３０７によって算出された指標値から「正常」、「警告」又は「異常兆候あり」を判定し、その判定結果を表すラベルを更に可視化する。

【0076】

＜ログ可視化処理＞
本実施形態に係るログ可視化処理の一例について、図１７を参照しながら説明する。なお、可視化対象条件が監視支援装置３０に与えられたときに、以下のステップＳ２０１～ステップＳ２０７及びステップＳ３０１～ステップＳ３０２の処理の実行が開始される。ステップＳ２０１～ステップＳ２０７の処理は第一の実施形態と同様であるため、以下では、ステップＳ３０１～ステップＳ３０２の処理について説明する。

【0077】

監視支援装置３０の指標値算出部３０７は、標準時間テーブル記憶部３０８に記憶されている標準時間テーブルを参照して、各ロググラフを構成する隣接ログ毎に、隣接ログ間の処理時間と標準処理時間との差分を指標値として算出する（ステップＳ３０１）。

【0078】

例えば、対象サービスのｋ番目のロググラフを構成するｎ番目の総合ログの日時をｔ_ｎ ^（ｋ）とした場合、指標値算出部３０７は、｜（ｔ_ｎ＋１ ^（ｋ）－ｔ_ｎ ^（ｋ））－Ｓ（ｋ，ｎ）｜を指標値として算出する。ただし、Ｓ（ｋ，ｎ）はｋ番目のロググラフを構成するｎ番目の総合ログからｎ＋１番目の総合ログの間の標準処理時間である。なお、ｋ及びｎは１以上の整数である。

【0079】

そして、監視支援装置３０のログ可視化部３０４は、上記のステップＳ３０１で算出された指標値を用いて、その指標値に対応する隣接ログ間が「正常」、「警告」又は「異常兆候あり」のいずれであるかを判定し、その判定結果を表すラベルを更に可視化する（ステップＳ３０２）。

【0080】

例えば、ログ可視化部３０４は、｜（ｔ_ｎ＋１ ^（ｋ）－ｔ_ｎ ^（ｋ））－Ｓ（ｋ，ｎ）｜＜α（ｋ，ｎ）である場合は「正常」、α（ｋ，ｎ）≦｜（ｔ_ｎ＋１ ^（ｋ）－ｔ_ｎ ^（ｋ））－Ｓ（ｋ，ｎ）｜＜β（ｋ，ｎ）である場合は「警告」、｜（ｔ_ｎ＋１ ^（ｋ）－ｔ_ｎ ^（ｋ））－Ｓ（ｋ，ｎ）｜≧β（ｋ，ｎ）である場合は「異常兆候あり」と判定し、その判定結果を表すラベルを更に可視化する。ここで、α（ｋ，ｎ）はｋ番目のロググラフを構成するｎ番目の総合ログからｎ＋１番目の総合ログの間の第１の許容時間、β（ｋ，ｎ）はｋ番目のロググラフを構成するｎ番目の総合ログからｎ＋１番目の総合ログの間の第２の許容時間である。

【0081】

＜ログ可視化例＞
以下、図１７のステップＳ３０２におけるラベルの可視化例について説明する。図１４に示す例と同様の状況を想定し、ラベルも可視化した場合を図１８に示す。図１８に示すように、「正常」を表すラベル２２０１、「注意」を表すラベル２２０２、及び「異常兆候あり」を表すラベル２２０３も可視化されている。これにより、ユーザは、対象サービスに異常兆候が存在するか否かをより容易に判断することが可能となる。

【0082】

なお、上記のラベルに加えて（又は、ラベルに代えて）、指標値と第１の許容時間又は第２の許容時間との比が更に可視化されてもよい。例えば、「正常」を表すラベルに加えて（又は、「正常」を表すラベルに代えて）、｜（ｔ_ｎ＋１ ^（ｋ）－ｔ_ｎ ^（ｋ））－Ｓ（ｋ，ｎ）｜／α（ｋ，ｎ）が可視化されてもよい。同様に、「警告」を表すラベルに加えて（又は、「警告」を表すラベルに代えて）、｜（ｔ_ｎ＋１ ^（ｋ）－ｔ_ｎ ^（ｋ））－Ｓ（ｋ，ｎ）｜／α（ｋ，ｎ）若しくは｜（ｔ_ｎ＋１ ^（ｋ）－ｔ_ｎ ^（ｋ））－Ｓ（ｋ，ｎ）｜／β（ｋ，ｎ）又はその両方が可視化されてもよい。同様に、「異常兆候あり」を表すラベルに加えて（又は、「異常兆候あり」を表すラベルに代えて）、｜（ｔ_ｎ＋１ ^（ｋ）－ｔ_ｎ ^（ｋ））－Ｓ（ｋ，ｎ）｜／β（ｋ，ｎ）が可視化されてもよい。これにより、ユーザは、離散的な意味を持つラベルに加えて（又は、離散的な意味を持つラベルに代えて）、異常兆候が存在するか否かを連続的な数値として把握することが可能となる。

【0083】

［ハードウェア構成例］
第一及び第二の実施形態に係るアプリケーション処理装置１０、ログ格納装置２０、及び監視支援装置３０は、例えば、図１９に示すコンピュータ５００のハードウェア構成により実現される。図１９に示すコンピュータ５００は、入力装置５０１と、表示装置５０２と、外部Ｉ／Ｆ５０３と、通信Ｉ／Ｆ５０４と、ＲＡＭ（Random Access Memory）５０５と、ＲＯＭ（Read Only Memory）５０６と、補助記憶装置５０７と、プロセッサ５０８とを有する。これらの各ハードウェアは、それぞれがバス５０９を介して通信可能に接続されている。

【0084】

入力装置５０１は、例えば、キーボード、マウス、タッチパネル、物理ボタン等である。表示装置５０２は、例えば、ディスプレイ、表示パネル等である。なお、コンピュータ５００は、例えば、入力装置５０１及び表示装置５０２のうちの少なくとも一方を有していなくてもよい。

【0085】

外部Ｉ／Ｆ５０３は、記録媒体５０３ａ等の外部装置とのインタフェースである。コンピュータ５００は、外部Ｉ／Ｆ５０３を介して、記録媒体５０３ａの読み取りや書き込み等を行うことができる。なお、記録媒体５０３ａとしては、例えば、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk）、ＳＤメモリカード（Secure Digital memory card）、ＵＳＢ（Universal Serial Bus）メモリカード等が挙げられる。

【0086】

通信Ｉ／Ｆ５０４は、コンピュータ５００を通信ネットワークに接続するためのインタフェースである。ＲＡＭ５０５は、プログラムやデータを一時保持する揮発性の半導体メモリ（記憶装置）である。ＲＯＭ５０６は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリ（記憶装置）である。補助記憶装置５０７は、ＨＤＤ、ＳＳＤ、フラッシュメモリ等のストレージ装置（記憶装置）である。プロセッサ５０８は、例えば、ＣＰＵ等の演算装置である。

【0087】

第一及び第二の実施形態に係るアプリケーション処理装置１０、ログ格納装置２０、及び監視支援装置３０は、例えば、図１９に示すコンピュータ５００のハードウェア構成を有することにより、上述した各種処理を実現することができる。なお、図１９に示すコンピュータ５００のハードウェア構成は一例であって、アプリケーション処理装置１０、ログ格納装置２０、及び監視支援装置３０は、その他の様々なハードウェア構成により実現されていてもよい。

【0088】

［まとめ］
以上のように、本実施形態に係る監視支援装置１０は、複数のアプリケーションの連携により実現されるサービスを対象として、そのサービスのログを収集及び可視化することで、そのサービスの異常兆候の監視を支援することができる。このため、ユーザは、実際に異常が発生する前に、その異常の兆候を知ることが可能となり、例えば、異常の発生を防止する様々な対策（例えば、機器や部品の交換等）を行うことが可能となる。

【0089】

なお、上記の第一及び第二の実施形態では、実際に運用中のサービスの異常兆候をユーザが監視する場合を想定しているが、これらの実施形態は運用監視以外にも、例えば、或るサービスを実現する複数のアプリケーションのデバッグ等といった場面にも適用することが可能である。

【0090】

本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲の記載から逸脱することなく、種々の変形や変更、既知の技術との組み合わせ等が可能である。

【符号の説明】

【0091】

１ ログ管理システム
１０ アプリケーション処理装置
２０ ログ格納装置
３０ 監視支援装置
１００ アプリケーション
１０１ アプリケーション処理部
１０２ 個別ログ管理部
１０３ 内部ログ記憶部
２１０ 個別ログ記憶部
３００ 監視支援プログラム
３０１ 条件受付部
３０２ 個別ログ要求部
３０３ 総合ログ管理部
３０４ ログ可視化部
３０５ サービス種別テーブル記憶部
３０６ 総合ログ記憶部
３０７ 指標値算出部
３０８ 標準時間テーブル記憶部
５００ コンピュータ
５０１ 入力装置
５０２ 表示装置
５０３ 外部Ｉ／Ｆ
５０３ａ 記録媒体
５０４ 通信Ｉ／Ｆ
５０５ ＲＡＭ
５０６ ＲＯＭ
５０７ 補助記憶装置
５０８ プロセッサ
５０９ バス
Ｎ 通信ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】