JP5050357B2 - ロギング情報管理方法およびロギング情報管理システムおよびロギング情報管理手段 - Google Patents

Description

本発明は、ロギング情報管理方法およびロギング情報管理システムおよびロギング情報管理手段に関し、システムやアプリケーションの運用情報や障害時の障害情報などのロギング情報を管理するロギング情報管理方法およびロギング情報管理システムおよびロギング情報管理手段に関する。

多くのアプリケーションやシステムは、稼働状況の確認や障害発生時の原因の切り分けを行うために、システムやアプリケーションの運用情報や障害時の障害情報などのロギング情報を記録する機能を実装している。

ロギング情報の管理の形式は様々であるが、基本的にはログファイルなどに長期にわたって蓄積を行う。ロギング情報は、基本的にはオフライン的（事後の調査等）に利用されることが多いが、アプリケーションやシステムの開発時においては、逆にリアルタイムで稼動状況を見る必要性が生じる。

多くのアプリケーションやシステムは、各種のアプリケーションがロギング情報を出力し、その情報を参照することで稼働状況のモニタリングを行うものが多く、リアルタイムでのモニタリングを行うものは、別途運用コンソールのようなものを用意し、ロギング情報の管理とは別にそういった機能を実装してきた。

通常のロギング情報は、基本的にはテキストまたはバイナリ形式のファイルとして常時蓄積される。基本的にロギング情報は、タイムスタンプとレベルや種別とログ情報（メッセージやダンプなど）および発信元情報で、ある程度決まった情報である。ロギング情報は、運用状態を履歴として表示したりすること以外は、基本的にはシステムのバックグランドで蓄積されている情報であり、システムのように複数のアプリケーションや装置によって構成される複雑な環境においては、アプリケーション間の処理の関連や動作状況を記録し、管理するためにそれらを統合することが望ましい。

しかし、ロギング情報の管理は、個々のアプリケーションが独自に管理したり、図１に示すように、ミドルウェアなどアプリケーションの基盤部分が提供するロギング機能をアプリケーションが利用する形態がほとんどである。

また、ロギング情報を一元管理する方法としては、図２に示すように、ＵＮＩＸ系ＯＳに標準で実装されているＳｙｓｌｏｇ（以下、「シスログ」という）を利用されている。シスログ自体は既存のＯＳのサービスやアプリケーションなどの互換性を考慮するためにほとんど機能拡張されていない状況である。

従って、自由度の高いロギング情報を効率的に管理するためには、ＯＳ種別の都合やアプリケーション側の実装の都合によりシスログが使用できない場面も多く、その結果、いくつかのシスログの代替となるログ管理ソフトが存在している。

なお、特許文献１には、処理開始通知データおよび処理終了通知データがＴＣＰまたはＵＤＰを適用して伝送されることが記載されている。
特開２００２−５５８８８号公報

以下に、従来のロギング情報管理における問題を説明する。

＜第１の問題、ロギング情報の分散化＞
ミドルウェアが複数存在したり、複数の装置に分散されたりすると、ロギング情報はそれぞれのミドルウェアまたは装置に分かれてしまう。また複数に分かれたロギング情報を集約しようとすると、ファイルの排他や同期等の問題が発生したり、ログ形式（出力フォーマット）がそれぞれのアプリケーションやミドルウェアで異なったりして、管理が困難である。

このような背景があって、現在の多くのアプリケーションやミドルウェアは、個々でロギング情報管理するものがほとんどであり、その結果、システムとしての稼動状況の分析や障害解析時に参照すべきログファイルがシステムのいたるところに散乱してしまう。シスログは、この問題を解決できる１つの手段ではあるが、環境に制限があるのと設定や実装側（アプリケーション側）の敷居が高い。また、ロギング情報のサイズの制限や、ＯＳ種別によりメッセージフォーマットが異なるため、ＯＳ単体やＵＮＩＸ系のＯＳのみで構成されるシステムでは有効であるが、近年のようにＷｉｎｄｏｗｓ(登録商標)やＵＮＩＸ(登録商標)などのＯＳ複合環境においては、ロギング情報の分散化は避けられない問題である。

＜第２の問題、リアルタイム性の欠如＞
ロギング情報は、アプリケーションやシステムの稼働状況を利用者に提供すること以外では、基本的には単に蓄積しておいて、障害等が発生した場合に解析するための情報である。従って、利用者に提供する部分ではリアルタイム性と情報のわかりやすさを重視することが多いが、利用者に提供せず、障害や問題に備えて蓄積しているロギング情報は、基本的には情報量が多く、また保守・メンテナンス部門や開発部門向けの情報（エラーコードやデータのダンプ・スタックトレースなど）であることが一般的である。

そのため、複数のアプリケーションやプロセス内部のスレッド等の業務の各単位でロギング情報の出力（ファイリング）の排他を管理したり、ロギングによる負荷を軽減させるためにロギング情報をいったんバッファにプーリングしたりする。これらの処理は、基本的にはロギング情報を出力して、ファイル等に出力するまでに時間がかかったり、ファイリングによる負荷がかかったり、場合によっては、ロギング情報の出力が、実際に行うべき業務（処理）の遅延につながることもある。

単にファイリングするだけであれば、結果的にファイルに正しいタイムスタンプのロギング情報が記録されていれば良いが、リアルタイムでシステムの稼働状況を監視することはできない。即ち、ファイリング以外にリアルタイムでロギング情報を参照するための何らかの手段が必要となるという問題があった。

＜第３の問題、複数のアプリケーション間での連携の解析が困難＞
複数のアプリケーションや複数の装置が連携して動作している場合、各アプリケーションのシーケンシャルな動作を１つのロギング情報として時系列的に管理できることが望ましい。同一のミドルウェア上で動作する複数のアプリケーションが連携する場合は、ミドルウェアのログ管理機能により上記時系列的管理を実現することはできるが、異なるミドルウェア上で動作する複数のアプリケーションが連携する場合や、異なる装置上の複数のアプリケーションが連携する場合、共有のロギング情報としての管理は難しい。

また、装置が複数に分散化している環境では、個々の装置はある程度時刻は合わせることはできても、微妙な時刻差は必ず生じる。その結果、ロギング情報を解析する場合、連携に関係する各々のロギング情報をつき合わせ、比較するなどの多大な手間がかかる。また、真にシーケンシャルなロギング情報の時系列管理は困難であるという問題があった。

＜第４の問題、障害解析の手間が大きい＞
システムの運用中に稼働状況をファイル等に蓄積する場合は、通常は全てのアプリケーションのロギング情報を同一のレベル（どれだけ詳細かのレベル）で蓄積を行う。この方法はシスログにおいても同様である。しかし、特定アプリケーションに障害が発生した場合に障害解析を行うには、該当するアプリケーションの周辺のみの情報解析を行いたいところであるが、ロギングされたファイルを解析すると、障害とは全く関係のないアプリケーションの情報も含まれているために解析に手間がかかる。

また、同一のレベルでロギングしているため、障害の起こったアプリケーションの周辺に関しては、詳細なレベルのロギング情報が必要であるが、既にロギングされたものに関してはそれ以上に詳細な情報は記録されていない。逆に詳細なレベルで常時ロギング情報を蓄積していると、システムに必要以上の負荷をかけることになるという問題があった。

＜第５の問題、データ長の大きなロギング情報の扱いが困難＞
シスログを利用してロギング情報を一元管理した場合、シスログの仕様により、約１Ｋバイトのデータ長のロギング情報しか管理することができない。これは、シスログがＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）によりロギング情報の送受信を行うために、最大パケットサイズ（ＭＴＵ）による制約を受けるためである。

近年は、インフラ環境が充実してきており、以前に比べて飛躍的に大容量なデータを扱う機会が多くなった。それに伴い、各種のアプリケーションが扱うデータのサイズも必然的に大きくなっているにも拘わらず、シスログではデータ長による制限があるために、比較的大きなデータ長のロギングを扱う場合は、シスログを利用せずに個々のアプリケーションがロギング情報を出力・管理するのが現状である。

また、シスログの代替となるログ管理ソフトにおいては、シスログにおいてはＵＤＰを利用しているところをＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）にすることによりロギング情報の抜けはなくすことができるが、その反面、ロギング情報が比較的大きなデータ長になると、それに比例してアプリケーション側の処理遅延を生じさせる可能性が高くなるという問題があった。

本発明は、上記の点に鑑みなされたものであり、複数のアプリケーションのロギング情報を一元管理することができるロギング情報管理方法およびロギング情報管理システムおよびロギング情報管理手段を提供することを目的とする。

本発明のロギング情報管理システムは、複数のアプリケーションのロギング情報を管理する情報管理システムであって、
前記複数のアプリケーションにそれぞれ設けられ、各アプリケーションの状況に応じたレベル情報を含むロギング情報を送信し、前記ロギング情報が所定のサイズを超えるときは、前記ロギング情報を分割した、それぞれが前記レベル情報を含む、分割ロギング情報を送信する、複数のロギング情報送信手段と、
前記ロギング情報および前記分割ロギング情報を受信しファイリングするロギング情報管理手段と、を備え、
前記ロギング情報管理手段は、
前記ロギング情報および前記分割ロギング情報を受信するロギング情報収集手段と、
前記ロギング情報収集手段で受信した前記ロギング情報および前記分割ロギング情報を、前記レベル情報ごとに記憶する一次メモリ手段と、
前記一次メモリ手段に記憶されている前記分割ロギング情報を結合し、前記ロギング情報とともに前記レベル情報ごとに記憶する整形済みメモリ手段と、
前記整形済みメモリ手段の全情報を退避可能な非常用メモリ手段と、
前記整形済みメモリ手段に記憶されている前記ロギング情報を、ファイリングするファイル管理手段を有し、
前記ロギング情報管理手段は、通常運用モードおよび非常運用モードを有し、
前記ロギング情報収集手段が、前記レベル情報が例外レベルである前記ロギング情報または前記分割ロギング情報を受信したときは、非常運用モードに移行し、所定の時間後に通常運用モードに移行し、
前記ロギング情報管理手段が前記通常運用モードにあるときは、前記ファイル管理手段は、前記整形済みメモリ手段に記憶された前記ロギング情報のうち、所定のレベル以上の前記ロギング情報を前記レベル情報ごとにファイリングし、
前記ロギング情報管理手段が、前記非常運用モードに移行したときに、前記整形済みメモリ手段の情報をすべて前記非常用メモリ手段に退避し、前記非常用メモリ手段より前記レベル情報ごとにファイリングするとともに、その後、前記整形済みメモリ手段に記憶される前記ロギング情報をすべて前記レベル情報ごとにファイリングすることにより、複数のアプリケーションのロギング情報を一元管理することが可能となる。

前記ロギング情報管理システムは、前記ロギング情報管理手段は、受信した前記ロギング情報または前記分割ロギング情報をマルチキャスト配信する配信手段を有する。

前記ロギング情報管理システムは、前記マルチキャスト配信された前記ロギング情報または前記分割ロギング情報を受信する複数の表示手段を有し、
前記複数の表示手段は、所定のレベル以上の前記ロギング情報または前記分割ロギング情報のみを抽出し、前記抽出された前記分割ロギング情報を結合し、時系列に並び替えて表示する。

また、本発明の前記ロギング情報管理手段は、複数のアプリケーションにそれぞれ設けられ、各アプリケーションの状況に応じたレベル情報を含むロギング情報を送信し、前記ロギング情報が所定のサイズを超えるときは、前記ロギング情報を分割した、それぞれが前記レベル情報を含む、分割ロギング情報を送信する、複数のロギング情報送信手段からの前記ロギング情報および前記分割ロギング情報を受信しファイリングするロギング情報管理手段であって、
前記ロギング情報および前記分割ロギング情報を受信するロギング情報収集手段と、
前記ロギング情報収集手段で受信した前記ロギング情報および前記分割ロギング情報を、前記レベル情報ごとに記憶する一次メモリ手段と、
前記一次メモリ手段に記憶されている前記分割ロギング情報を結合し、前記ロギング情報とともに前記レベル情報ごとに記憶する整形済みメモリ手段と、
前記整形済みメモリ手段の全情報を退避可能な非常用メモリ手段と、
前記整形済みメモリ手段に記憶されている前記ロギング情報を、前記レベル情報ごとにファイリングするファイル管理手段を有し、
前記ロギング情報管理手段は、通常運用モードおよび非常運用モードを有し、
前記ロギング情報収集手段が、前記レベル情報が例外レベルである前記ロギング情報または前記分割ロギング情報を受信したときは、前記非常運用モードに移行し、所定の時間後に前記通常運用モードに移行し、
前記ロギング情報管理手段が、前記非常運用モードに移行したときに、前記整形済みメモリ手段の情報をすべて前記非常用メモリ手段に退避し、前記非常用メモリ手段より前記レベル情報ごとにファイリングするとともに、その後、前記整形済みメモリ手段に記憶される前記ロギング情報をすべて前記レベル情報ごとにファイリングする。

また、本発明の前記ロギング情報管理方法は、複数のアプリケーションより送信された、各アプリケーションの状況に応じたレベル情報を含むロギング情報、または、前記ロギング情報が所定のサイズを超えるときは、前記ロギング情報を分割したそれぞれが前記レベル情報を含む分割ロギング情報を、受信しファイリングする、ロギング情報管理方法であって、
前記ロギング情報および前記分割ロギング情報を受信する収集ステップと、
前記受信した前記ロギング情報および前記分割ロギング情報を、前記レベル情報ごとに記憶するステップと、
前記レベル情報ごとに記憶された前記分割ロギング情報を結合し、前記ロギング情報とともに前記レベル情報ごとに整形済みメモリ手段に記憶するステップと、
前記レベル情報ごとに記憶された、前記結合された前記分割ロギング情報および前記ロギング情報を、前記レベル情報ごとにファイリングするステップと、を備え、
前記収集ステップで、前記レベル情報が例外レベルである前記ロギング情報または前記分割ロギング情報を受信したときは、非常運用モードに移行し、所定の時間後に通常運用モードに移行し、
前記非常運用モードに移行したときに、前記整形済みメモリ手段の情報をすべて非常用メモリ手段に退避し、前記非常用メモリ手段より前記レベル情報ごとにファイリングするとともに、その後、前記整形済みメモリ手段に記憶される前記ロギング情報をすべて前記レベル情報ごとにファイリングする。

本発明によれば、複数のアプリケーションのロギング情報を一元管理することが可能となる。

以下、図面に基づいて本発明の実施形態について説明する。

＜運用情報蓄積コンポーネントの構成＞
図３は、本発明の運用情報蓄積コンポーネントの概要イメージ図を示す。同図中、運用情報蓄積コンポーネント１０は、コンポーネント本体１１および各種保守コマンド１２と、アプリケーション側に提供する提供クラス１３およびリアルタイム表示機能１４で構成される。

運用情報蓄積コンポーネント１０の適用範囲に関しては、ＯＳおよびＯＳに依存するミドルウェアは、従来どおりＵＮＩＸ系のＯＳであればシスログを利用し、Ｗｉｎｄｏｗｓ系のＯＳであればイベントログなどが利用されるものとし、その他のアプリケーション側の実装およびそれに伴うシステム的なロギング情報の管理を運用情報蓄積コンポーネントの適用範囲としている。

図４は、運用情報蓄積コンポーネントの内部構成図を示す。同図中、運用情報蓄積コンポーネントは、コンポーネント本体２１（図３の１１に対応）に含まれるロギング情報収集機構２２、ロギング情報管理機構２３、通知機構および保守機能２４（図３の１２に対応）、配信表示機構２５（図３の１４に対応）と、ロギング情報送信機構２６より構成されている。

ロギング情報管理機構２３は、メモリ管理部４１，メモリ４２，非常用メモリ４３，ファイル管理部４４を有し、ファイル管理部４４はログファイルＦＬ１〜ＦＬ５を管理している。通知機構および保守機能２４は、アプリケーション通知部４５，運用制御コマンド４６，モード切り替えコマンド４７を有している。配信表示機構２５は、マルチキャスト配信部４８と表示装置４９を有している。

運用情報蓄積コンポーネントは、ロギング情報送信機構２６（クライアント機能）として一または複数のアプリケーション３０にロギング処理を簡易化するクラス（提供クラス）３１を提供する。このクラス３１は、ホスト名とポート番号を設定ファイル（プロパティファイル）に指定して実装することで、コンポーネント本体２１（サーバ機能）のロギング情報収集機構２２がロギング情報を待ち受けている特定のポートに対してＵＤＰによるロギング情報の送信を行う。

上記ロギング情報送信機構２６から送信されるロギング情報は、コンポーネント本体２１のロギング情報収集機構２２で収集され、ロギング情報管理機構２３はロギング情報をクラス３１の種別により複数のファイルに種別分けしてファイリングする。

ところで、シスログはアプリケーション実装部がロギング情報の出力関数を呼ぶと、ロギング情報はメッセージとして／ｄｅｖ／ｌｏｇ配下に出力される。シスログのデーモンは、このメッセージを受信して、ファイリングすると同時にネットワーク上の他装置に対してロギング情報をＵＤＰ送信する。つまり、シスログ自体はアプリケーション実装部とその装置および一元管理する装置の３箇所に存在する。

これに対して、本発明の運用情報蓄積コンポーネントでは、アプリケーション３０の実装部でロギング情報送信機構２６が全てのロギング情報をＵＤＰで送信を行い、ロギング情報収集機構２２によりネットワーク３３に接続された複数のアプリケーション３０の実装部からのロギング情報を収集する。このため、ロギング情報を管理する機構としては、アプリケーション３０の実装部とコンポーネント本体２１の実装部の２箇所だけで済む。

コンポーネント本体２１では、次の種別単位でログファイルを生成・管理する。

メッセージログは、アプリケーションの稼動状況を人が容易に理解できる文章で記録するロギング情報であり、メッセージログファイルＦＬ１にファイリングする。ロギング情報には指定されたレベルの範疇でアプリケーションが任意にロギング情報を分類することができる。なお、運用情報蓄積コンポーネントで利用できるレベルの種別は、図５に示すように、高いほうから、致命的エラーレベル、エラーレベル、警告レベル、情報レベル、デバッグレベルである。各レベルはさらに細分化することができる。基本的には、シスログで管理しているロギング情報のレベルに準拠する。運用中は、これらのレベルの中で指定されたレベル以上のものをロギングする。

通信ログは、ネットワークを経由したデータの疎通に特化したロギング情報であり、通信ログログファイルＦＬ２にファイリングする。特にレベルという概念はないが、確実にデータをロギングするようにロギング処理の優先度がメッセージログよりも高い。このログには、生のデータ（データフォーマットは問わないが、基本的にはスニファーなどのＬＡＮアナライザー上で見えるようなバイナリ形式）を管理する。

例外ログは、アプリケーションの異常や例外に特化したロギング情報であり、例外ログファイルＦＬ３にファイリングする。自動的なモード切り替えやレベル切り替えなどのきっかけとなるのは、このロギング情報である。なお、ロギング処理のレベルは、例外ログが最も高い。例外にもレベルの指定があり、高いほうから致命的、エラー、警告のレベルを持つ。警告レベルに関しては、通常運用でも起こりうるものと想定される例外である。この例外ログには、例外が発生した際のスタックトレースやメモリダンプなど障害の詳細調査に必要な情報を管理する。

アプリケーションログは、利用するアプリケーションが任意の形式で出力することを許すロギング情報であり、アプリケーションログファイルＦＬ４にファイリングする。レベルは致命的レベル〜情報レベルに加え、デバックレベルの出力を許す。

デバックログは、利用するアプリケーションが任意の形式で出力することを許すロギング情報で最も処理レベルの低いロギング情報であり、デバックログファイルＦＬ５にファイリングする。主に、試験やデバック時に利用することを目的としているため、運用情報蓄積コンポーネントをデバックモードで動作させることにより、デバックレベルのロギング情報もロギングされる。通常運用時では、このログは出力しないように運用するが、例外が発生した場合などに運用情報蓄積コンポーネントが行うモードの切り替えにより、一時的にデバックログを出力する状態になることもある。

＜ロギング情報の受信処理＞
ロギング情報収集機構２２は、ロギング情報をロギング情報送信機構２６から受信してロギング情報管理機構２３に渡し、ロギング情報管理機構２３はメモリ４２にプールすると共に後述するロギング情報の配信を行う。メモリ４２にプールする理由は、データ受信の遅延を起こさないためと、あらゆるレベルのロギング情報を特定の運用レベルにフィルタリングしてファイリングするためである。さらに、クライアントからロギングデータの分割送信が行われた場合、ロギング情報を受信したデータ内のシーケンス番号に従って結合するためにも利用する。

また、特定のアプリケーションが例外を送信した場合、メモリ４２上にプールしている全情報をいったん非常用メモリ４３に退避し、ロギング情報の収集を継続しつつ、受信済みの全情報のファイリングを行うことで、例外発生時に限りデバックレベルのログまでファイルに出力することができる。なお、ロギングされたファイルは、一般的なロギング情報の管理機能と同様に、所定のサイズ・所定の期間で蓄積し、古いものから削除することでログファイルが肥大化することはない。

このクラス３１およびロギング情報収集機構２２により、アプリケーション３０が容易にロギング情報を出力することを実現するだけでなく、以下の効果を得ることができる。シスログ関数、シスログデーモンと同等にロギング情報を出力する側（アプリケーション側）とファイリングする側（サーバ機能側）が非同期で動作するために、ロギング情報の出力側がファイリングにかかる負荷や待ちあるいは他のアプリケーションの動作による影響が少ない。

また、ＵＤＰによるロギング情報の送受信を行うため、図６に示すように、従来は各ミドルウェア単位やアプリケーション単位で持っていたログファイルが不要になり、複数のミドルウェアや複数の装置からのロギング情報の出力を運用情報蓄積コンポーネントのコンポーネント本体２１で受信して集約することができる。図６では、アプリケーションサーバＢにコンポーネント本体２１が配置され、アプリケーションサーバＡのアプリケーションＡ，ＢおよびアプリケーションサーバＢのアプリケーションＣ，Ｄそれぞれのロギング情報がコンポーネント本体２１で管理される。

この集約により、図７に示すように、複数のアプリケーションや装置間での複雑な連携も一箇所のログファイルで時系列に記録することができる。図７では、アプリケーションサーバＡのアプリケーションＡ１，Ａ２と、アプリケーションサーバＢのアプリケーションＢ１，Ｂ２は連帯して動作しており、ロギングサーバＧにコンポーネント本体２１が配置されており、コンポーネント本体２１では各アプリケーションのロギング情報を時系列に記録している。

また、システム規模が大きく、アプリケーションの数や記録すべきロギング情報が多い場合などは、ロギング情報の管理を専用とする装置を別に用意し、その装置でロギング情報を集約することにより、システム全体のロギング処理をシステムに負荷をかけることなく行うことができ、また、情報をシスログのように中継することなく一箇所に集約することができる。

運用情報蓄積コンポーネントでロギング情報を蓄積するための構成としては、図８（Ａ）に示すスタンドアロンでロギングする方式、図８（Ｂ）に示すシステム（サーバＡ，Ｂ）中で負荷の低いサーバＢでロギングする方式、図８（Ｃ）に示すロギング専用のサーバＤで複数のサーバＡ，Ｂ，Ｃのロギングを行う方式等の構成を実現することができる。いずれもシスログおよびシスログを拡張したログ管理ソフトにはない単純さを持つ。

なお、シスログおよびシスログを拡張したログ管理ソフトは、アプリケーション側の実装部をのぞき、必ず１装置内に１つのログ管理機構を持つが、運用情報蓄積コンポーネントでは、管理機構がシステムにつき１つで済む。

上記のような効果により、従来のロギング情報の分散化、複数のアプリケーション間での連携の解析が困難という問題を解決することができる。また、ＵＤＰを直接利用することにより即時性と低負荷を実現できるため、従来のリアルタイム性の欠如という問題を解決するために必要な環境が整えられる。さらに、サイズの大きいロギング情報も扱えることから、従来のデータ長の大きなロギング情報の扱いが困難という問題を解決することができる。

なお、ＵＤＰを利用することによるリスクとしては、ネットワーク品質の悪いネットワーク上においては、パケット抜けによるロギング情報の損失が挙げられるが、通常の品質のネットワークであれば、アプリケーション側が高負荷でない限りはロギング情報の損失はほとんどない。また、運用情報蓄積コンポーネントが動作している自装置内におけるアプリケーションからのロギング情報についてもほとんど損失はない。ネットワーク品質が確保されていない環境においては、運用情報蓄積コンポーネントは有効ではないが、通常のネットワーク品質であれば、運用情報蓄積コンポーネントは存分に効力を発揮する。

ロギング情報送信機構（クライアント機能）２６は、クライアントとなるアプリケーション３０側でクラス３１を実装することにより、運用情報蓄積コンポーネントのクライアントになることができ、面倒なロギング情報の管理やロギング処置による負荷から解放される。クラス３１では、運用情報蓄積コンポーネントが用意しているロギング種別の選択を行うだけでよい。クラス３１で選択できる送信種別は以下の通りである。

メッセージログ（デバックログ含む）は、通常運用メッセージおよびデバック用のロギングを行う送信種別である。メッセージのロギングにおいては、必ずレベルの指定を行う。アプリケーションログへのロギングの指定は、本クライアント機能の実装時のパラメータに従う。

通信ログは、ネットワークや特定デバイスとのデータ疎通を行う場合の送受信データのロギングを行う送信種別である。データのロギングにおいては、送信／受信のいずれかの方向を指定する。

例外ログは、アプリケーション内で発生した異常な状態や例外情報のロギングを行う送信種別である。

図９にクラス３１の構成を示す。クラス３１にはメッセージログ送信メソッド５１、通信ログ送信メソッド５２、例外ログ送信メソッド５３が設けられており、アプリケーション３０はメッセージログ送信メソッド５１、通信ログ送信メソッド５２、例外ログ送信メソッド５３のいずれかを起動するだけで各ロギング情報の送信が行われる。

情報付加部５４はタイムスタンプ、業務名、発信元情報（クラス名・メソッド名・メッセージＩＤ）、ロギング種別（メッセージ・通信・例外）、レベルをログに付加する。ＵＤＰのデータ送信におけるデータサイズの上限は、基本的にはＭＴＵ（Ｍａｘｉｍｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ：最大パケットサイズ）に従う。アプリケーションが、ロギングしたい情報のサイズを意識しない場合は、ＭＴＵのサイズによる上限が規定される。しかし、比較的大量なデータを扱う場合は分割送信指定をすることにより、送信ロギングデータ長制御部５５は設定されたサイズでロギング情報を分割し、シーケンス番号を振ってデータ送信を行う。

送信ロギングデータ長制御部５５の出力するロギング情報はロギングデータ送信部５６を経てＵＤＰ送信オブジェクト５８に供給され、ＵＤＰ送信オブジェクト５８はＵＤＰにより各ロギングデータを情報蓄積コンポーネントのコンポーネント本体２１に送信する。なお、ＵＤＰ送信オブジェクト５８は送信先情報取得部５７で取得された送信先情報を供給される。

これにより、負荷も遅延もほとんど無く、きわめて実処理時間に近いタイムスタンプでもってロギング情報の出力を行うことができる。

図１０にＵＤＰ転送データフォーマットを示す。ＵＤＰ転送データは、アプリケーション実装部でつけたタイムスタンプであるログ時刻、サーバ機能でつけたタイムスタンプである受信時刻、分割指定がない場合０、ある場合１以上である分割数、分割したときの分割最大サイズである分割サイズ、分割送信した順番であるシーケンス番号、メッセージ・通信・例外のいずれかの識別文字（１文字）であるログ種別、ログレベルの識別文字（１文字）であるログレベル、送信ホスト名（終端にカンマを付加）、アプリケーション名や業務名などの識別（終端にカンマを付加）である送信元情報１、クラス名などモジュールやソースの識別（終端にカンマを付加）である送信元情報２、メソッド・関数など（終端にカンマを付加）である送信元情報３、メッセージＩＤ（終端にカンマを付加）である送信元情報４、メッセージやデータなどのログ情報からなる。

運用情報蓄積コンポーネントのロギング情報管理機構２３は、データ内のシーケンス番号および分割サイズに従って受信したロギング情報を結合することで比較的大量データであっても扱うことができる。ただし、基本的には通信ログ以外は分割指定を行わないものとし、分割指定なしで運用することにより、たとえアプリケーションが予想しないデータサイズのロギング情報を送信したとしても、上限で頭打ちして運用情報蓄積コンポーネントに送信するものとする。

ロギング情報送信機構２６は、運用情報蓄積コンポーネントのコンポーネント本体２１とはネットワーク的な関係であるため、コンポーネント本体２１とは異なるＯＳやプログラム言語であっても、その環境毎にロギング情報送信機構２６を用意することで様々な環境に適用することが容易である。

ロギング情報送信機構２６による効果としては以下があげられる。アプリケーション３０で実装している部分は、単にＵＤＰのデータ送信を行っているだけなので、処理が軽い。なお、ロギングのタイムスタンプは、このクラスにより行うが、ＵＤＰのデータ送信はほとんど負荷がないため、アプリケーションの実動作時刻にきわめて近いタイムスタンプを生成できる。

また、クライアント機能であるロギング情報送信機構２６とサーバ機能であるコンポーネント本体２１がネットワーク上でクライアント／サーバの関係であり、クライアント側の実装はサーバから独立していることから実装のバリエーション（対応できるＯＳや開発言語など）が豊富になりうる。

上記により、ロギング情報送信機構２６は、利用するアプリケーションに負荷をかけることなくロギング情報をコンポーネント本体２１に送信するため、リアルタイム性の欠如の問題を解決するために必要な環境が整えられる。

＜ロギング情報管理機構＞
ロギング情報管理機構２３は、サーバ機能の一部で、処理遅延なく受信したロギング情報を格納することと、運用の制御コマンドによるモード切り替え、および例外ログの受信によりモード切り替えを行うものである。基本的にロギング情報管理機構２３はメモリの管理を行うもので、収集したロギング情報をメモリプールに格納する機構と、モードの切り替えを行う機構に分かれる。

＜メモリ管理機能＞
図１１にロギング情報管理機構２３におけるロギング情報および制御の流れを示す。同図中、破線の矢印は通常時のロギング情報（制御）の流れを示し、実線の矢印は非常時のロギング情報（制御）の流れを示す。メモリ管理部４１内の種別振り分け部４１ａは、ロギング情報収集機構２２で受信したロギング情報をいったん複数の一次格納メモリプール４２ａ，４２ｂ，４２ｃに種別毎に振り分けて格納する。ロギング情報をメモリ４２上にプールするのは、以下の理由による。

受信したロギング情報を遅延なく処理するために、全ロギング情報をほとんど無処理で一次格納メモリプール４２ａ，４２ｂ，４２ｃに格納し、その後にメモリ管理部４１内の非同期制御部４１ｂは種別振り分け部４１ａと非同期（例えば１秒周期）でプーリングされたロギング情報の編集を行う。編集とは分割されたロギング情報の結合やＵＤＰによる取りこぼしが発生したと思われる箇所の特定などである。

また、ファイリング時に指定されたレベル以上のロギング情報を抽出するためのテーブルとして使用するためである。さらに、例外ログを検出した際のモード切り替え時に例外発生直前の全レベルのロギング情報をファイリングできるように保持しておくためである。

また、ロギング情報が一定量（設定により指定可能なメモリサイズ：レコードサイズとレコード長を指定する）に達した場合、メモリ内容をログファイルとして出力（フラッシュ）する。

メモリプールは３層に分けておりそれぞれ次のような役割を持つ。一次格納メモリプール４２ａ，４２ｂ，４２ｃは、受信したロギング情報の一次格納を行う。整形済みメモリプール４２ｄ，４２ｅ，４２ｆは、一次格納されたロギング情報に対して分割されたものは結合して整形を行う。非常用メモリプール４３ａ，４３ｂ，４３ｃは、例外発生時に整形された全情報を即時にファイリングするためにいったん別領域に退避を行う。なお、メモリプール４２ａ〜４２ｆはメモリ４２内に設定され、非常用メモリプール４３ａ〜４３ｃは非常用メモリ４３内に設定される。

運用情報蓄積コンポーネントは、複数の装置・複数のアプリケーションからのロギング情報を一箇所で受信するために、各種のロギング情報の編集や制御を、メモリ４２，非常用メモリ４３を介して行うことで受信時の負荷を抑え、ＵＤＰによる取りこぼしを軽減させる。

受信時に行うことは、ロギング情報の種別振り分け（メッセージログ・通信ログ・例外ログの判定）だけである。ロギング情報管理機構２３は、この受信処理とは非同期に例えば１秒周期で上記一次格納、整形、退避の編集処理を行う。通常時は一次格納と整形までであるが、ロギング情報の中の例外ログを検出し、後述するモード切り替えの判定がされると、退避を行う。この編集処理により、各種のロギング情報は、ロギング情報のサイズや受信頻度に関係なく整形されて、最終的には種別毎のログファイルに出力される。

上記の編集処理における分割されたロギング情報の結合の様子を図１２に示す。同図中、一次格納メモリプール４２ａ，４２ｂ，４２ｃに格納されている１番目のロギング情報（図中、最上段）は発信元１で分割なしであり、２，３，５番目のロギング情報は発信元２で分割ありであり、４番目のロギング情報は発信元３で分割なしであり、６番目のロギング情報は発信元２で分割なしであり、７番目のロギング情報は発信元１で分割なしである。

この場合、整形済みメモリプール４２ｄ，４２ｅ，４２ｆには１番目のロギング情報、結合された２，３，５番目のロギング情報、４番目のロギング情報、６番目のロギング情報の順に時系列に並び替えて格納される。

図１３にメモリプール４２ａ〜４２ｆ，非常用メモリプール４３ａ〜４３ｃにおけるロギング情報のフォーマットを示す。同図中、ロギング情報は、レコード管理の番号であるレコード番号、分割完了を０、未完了を０以外（残り分割数）で表わす分割完了フラグ、アプリケーション実装部でつけたタイムスタンプであるログ時刻、サーバ機能でつけたタイムスタンプであある受信時刻、分割指定がない場合０、ある場合１以上である分割数、分割したときの分割最大サイズである分割サイズ、分割送信した順番であるシーケンス番号、メッセージ・通信・例外のいずれかの識別文字（１文字）であるログ種別、ログレベルの識別文字（１文字）であるログレベル、送信ホスト名（終端にカンマを付加）、アプリケーション名や業務名などの識別（終端にカンマを付加）である送信元情報１、クラス名などモジュールやソースの識別（終端にカンマを付加）である送信元情報２、メソッド・関数など（終端にカンマを付加）である送信元情報３、メッセージＩＤ（終端にカンマを付加）である送信元情報４、メッセージやデータなどのログ情報からなる。

＜レベル・モード管理機能＞
運用情報蓄積コンポーネントは、通常運用モードとデバックモードとエマージェンシーモード（非常運用モード）の３つのモードがあり、これらのモードは、運用中に切り替えることができる。また、ロギング情報のレベルおよびロギング情報の種別（メッセージログや通信ログなど）により蓄積有無等のフィルタリング条件を変更制御することもできる。

これらのモードの切り替え制御は、通知機構および保守機能２４のモード切り替えコマンド４７によって行う。ただし、エマージェンシーモードに関しては、運用設定において、このモードの適用可否を設定することで、例外発生時の動作を指定することができる。以下に各モードを説明する。

通常運用モードは、通常運用時のモードであり、通知機構および保守機能２４の設定ファイルで指定されたレベル以上のロギング情報を蓄積・配信するモードである。

デバックモードは、アプリケーションの開発時や試験時に利用するモードで、全レベルの情報を蓄積・配信するモードである。

エマージェンシーモード（非常運用モード）は、例外ログのエラーレベル以上のロギング情報をコンポーネント本体２１が受信した場合に遷移するモードである。

エマージェンシーモードに移行すると、ロギング情報管理機構２３のメモリ管理部４１は、出力可能な全レベルの情報でメモリ４２上にプールされているロギング情報の全てをいったんログファイルＦＬ１〜ＦＬ５に書き落とすと共に、全情報の配信を行う。その後は、運用情報蓄積コンポーネントで指定されたシナリオに従って、一定時間このモードを継続させて運用モードに戻ったり、設定されたコマンドを起動してシステムを再起動させたりする。

エマージェンシーモードでは、次のような動作を通知機構および保守機能２４の情報蓄積コンポーネントの設定ファイルにシナリオ設定することで実行することができる。
（１）モード切り替え制御
エマージェンシーモードの継続時間と次に遷移するモードを指定することでモード切り替えを行う。
（２）コマンド実行
任意のコマンドを実行する。本機能では、単にコマンドを実行するだけなので、複数の処理を連続で行う場合は、シェルやバッチにその処理を記述する。
（３）アプリケーション通知
ＪＭＳ（Ｊａｖａ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）（Ｊａｖａは登録商標）によるアプリケーション通知を行う。通知する内容は、設定ファイルに記述した固定情報および受信した情報である。

これにより、通常運用時と障害発生時の自動的なロギング情報の出力切り替えにより、通常運用時は必要最低限のロギングしか行わず、障害発生時には全情報を採取し、またシステムのリカバリ等の処理が可能となることである。よってこの機能により、障害解析の手間を省くことができる。

＜リアルタイムなロギング情報の配信表示機構＞
コンポーネント本体２１は、ロギング情報送信機構２６から送信されたロギング情報を受信すると、配信表示機構２５のマルチキャスト配信部４８が、そのロギング情報をそのまま指定されたマルチキャストアドレスに対して配信し、配信されたロギング情報を受信して表示する表示装置４９を持つ。

図１４に表示装置４９の構成を示す。この表示装置４９は、絞り込み判定部６１にフィルタリング条件を指定することにより、リアルタイムで配信されているロギング情報から、必要なロギング情報のみを絞り込んで抽出し、受信バッファ６２に格納する。抽出された特定業務のロギング情報は編集処理６３によって分割配信されたロギング情報は結合され、時系列に並び替えられ、表示・出力部６４により表示される。

図１５に編集処理６３による表示の更新例を示す。同図中、受信バッファ６２に１番目のロギング情報（図中、最上段）が格納された時点で表示領域６５ａに示すように１番目のロギング情報が表示される。次に、受信バッファ６２に３番目のロギング情報が格納された時点で表示領域６５ｂに示すように２，３番目のロギング情報が結合され、１番目のロギング情報と共に表示される。

次に、受信バッファ６２に４番目のロギング情報が格納された時点で表示領域６５ｃに示すように１〜４番目のロギング情報が表示される。次に、受信バッファ６２に５番目のロギング情報が格納されると、この５番目のロギング情報は２，３番目のロギング情報と同一のロギング情報が分割されたものであるため、２，３番目のロギング情報と結合され、表示領域６５ｄに示すように表示される。さらに、受信バッファ６２に６番目のロギング情報が格納された時点で表示領域６５ｅに示すように１〜６番目のロギング情報が表示される。

ロギング情報の配信はマルチキャスト配信部４８でマルチキャスト送信することにより、複数の表示装置４９で同時にロギング情報を表示することができるだけでなく、同一のネットワーク上であれば、どの装置からでもロギング情報のリアルタイム表示を行うことができる。これにより、運用状態の監視や開発時のデバック、試験などあらゆる場面でロギング情報を有効に活用することができる。

このようにして、各種のログファイルを逐一見る必要が無くなり、必要な情報のみを表示することで、障害の解析やデバック・試験が効率的行える環境を提供できることができ、リアルタイム性の欠如という問題を解決することができる。

＜通知機構および保守機能＞
コンポーネント本体２１の通知機構および保守機能２４は、受信したロギング情報の中で指定されたレベルの情報をＪＭＳによりアプリケーションに通知することができる。ＪＭＳはＰｕｂｌｉｓｈｅｒ／Ｓｕｂｓｃｒｉｂｅｒ方式（１対多配信）によりアプリケーションに通知を行う。この通知の際には、発信元情報（クラス名・メソッド名など）をＴｏｐｉｃとし、タイムスタンプ・種別・レベル・メッセージＩＤおよびメッセージをメッセージ通知する。

受信するアプリケーションは、メッセージセレクタにより、任意のＴｏｐｉｃを指定して購読することにより、特定の運用情報を取得することができる。主な使い道としては、アプリケーションが出力する業務の開始や完了等をデータベースに登録することで、アプリケーションやシステムの利用者に対して運用情報の履歴を提供することなど、ロギング情報をシステムやアプリケーションが出力するイベントして扱うことができ、それによりメッセージを受信するアプリケーション側で様々な利用を行うことが可能となる。

また、通知機構および保守機能２４の運用制御コマンドには、以下の保守コマンドがあり、それぞれ次のような制御を行う。
（１）運用制御コマンド
このコマンドは、ファイリングする種別の選択とレベルの切り替えを行う。ファイリング種別の選択は、各種別（メッセージ、通信、例外、デバック、アプリケーション）のロギング情報のファイリングする／しないを切り替える。レベル切り替えは、ファイリングする種別のログに対してファイリングを行う最低レベルに指定を行う。
（２）モード切替コマンド
このコマンドは、前述の３つのモードの切り替えを行う。

これらのコマンドは、運用情報蓄積コンポーネントが動作中に各種の切り替えを行うことができる。

＜制御ロジック＞
図１６は、コンポーネント本体の制御ロジックのフローチャートを示す。同図中、ロギング情報収集機構２２はステップＳ１でデータ受信待ちを行い、ステップＳ２でデータを受信すると、受信データをロギング情報管理機構２３に渡す。

ロギング情報管理機構２３内のメモリ管理部４１の種別振り分け部４１ａは、ステップＳ３で受信データの振り分けを行い、これにより、例外ログはステップＳ４で一次格納メモリプール４２ｃに格納され、メッセージログはステップＳ５で一次格納メモリプール４２ａに格納され、通信ログはステップＳ６で一次格納メモリプール４２ｂに格納される。

メモリ管理部４１の非同期制御部４１ｂは、ステップＳ１０で１秒周期のタイマを生成し 、ステップＳ１１でモード判定処理を開始する。非同期制御部４１ｂはステップＳ１２で一次格納メモリプール４２ａ〜４２ｃの未処理データを取得し、分割データの場合はステップＳ１３で結合して整形を行う。また、整形済みメモリプール４２ｄ，４２ｅ，４２ｆのロギング情報が一定量を超え、ロギング情報のレベルが指定されたレベル以上のである場合には、ステップＳ１４でロギング情報をファイルＦＬ１〜ＦＬ５にファイリングし、ステップＳ１５で整形済みメモリプール４２ｄ，４２ｅ，４２ｆをクリアする。

さらに、一次格納メモリプール４２ａ，４２ｂ，４２ｃのロギング情報が一定量を超えると、ステップＳ１６で一次格納メモリプール４２ａ，４２ｂ，４２ｃの処理済みデータをクリアする。

一方、ロギング情報が例外ログの場合、ステップＳ２０で全レベルのロギング情報のファイリングを有効とするエマージェンシーモードにモード遷移し、ステップＳ２１でエマージェンシーモードから元のモードに戻すタイマを生成する。次に、ステップＳ２２で整形済みメモリプール４２ｄ，４２ｅ，４２ｆのロギング情報を非常用メモリプール４３ａ，４３ｂ，４３ｃに一時退避し、ステップＳ２３で非常用メモリプール４３ａ，４３ｂ，４３ｃのロギング情報をファイルＦＬ１〜ＦＬ５にファイリングする。この後、ステップＳ２４で非常用メモリプール４３ａ，４３ｂ，４３ｃをクリアする。

なお、ステップＳ２１で生成されたモード戻しタイマはステップＳ３０で計時を行い、タイムオーバーによりステップＳ３１でエマージェンシーモードから元のモードに戻す。

上記の運用情報蓄積コンポーネントにより、次のような効果が得られる。

第１に、ＵＤＰによるロギング情報の送受信により、アプリケーション側に負荷をかけることなくロギング情報の送信ができる。

第２に、ロギング情報の送信側と受信側がネットワーク的な関係でしかないので、送信側（アプリケーション側）の実装（ＯＳや開発言語など）のバリエーションを豊富にすることができる。

第３に、ロギング情報の管理をクライアントとサーバに分けることにより、実際のロギング情報のファイリングにかかる負荷を分離することで、本来重視すべきシステムやアプリケーションに負荷をかけないことができる。

第４に、サーバ機能により複数のミドルウェア上で動作するアプリケーションや複数装置上のアプリケーションのロギング情報を一元管理することができる。

第５に、例外ログの受信時にロギングモードを動的に変化させられることから、障害発生時に普段はファイリングしていないデバックレベルのログまでが、障害発生前後に限り自動で採取することができる。また、本機能により、自動的にアプリケーションやシステムのリカバリを行うことができる。

第６に、サーバ機能が受信したロギング情報をマルチキャストで配信することにより、複数の装置やターミナルにより同時にリアルタイムでロギング情報の表示を行うことができ、これにより、障害解析やデバック・試験などが効率的に実施できる。

第７に、リアルタイムなロギング情報を表示する機能が実装するフィルタリング機能により、表示すべきロギング情報を必要なレベルや表示条件によって絞り込むことで、障害解析やデバック・試験などが効率的に実施できる。

第８に、収集したロギング情報をアプリケーションに通知することにより、アプリケーション側で他のアプリケーションが出力した情報をイベントとして受信することができる。

なお、ロギング情報送信機構２６が請求項記載のロギング情報送信手段に相当し、コンポーネント本体２１がロギング情報管理手段に相当し、一次格納メモリプール４２ａ，４２ｂ，４２ｃが一次メモリ手段に相当し、整形済みメモリプール４２ｄ，４２ｅ，４２ｆが整形済みメモリ手段に相当し、非常用メモリプール４３ａ，４３ｂ，４３ｃが非常用メモリ手段に相当し、配信表示機構２５が配信表示手段に相当し、通知機構および保守機能２４が通知手段に相当する。
（付記１）
複数のアプリケーションそれぞれに設けられたロギング情報送信機構から各アプリケーションのロギング情報を送信し、
コンポーネント本体で前記各アプリケーションのロギング情報を受信し、ロギング情報の種別毎にファイリングすることを特徴とするロギング情報管理方法。
（付記２）
複数のアプリケーションそれぞれに設けられ各アプリケーションのロギング情報を送信するロギング情報送信手段と、
前記各アプリケーションのロギング情報を受信し、ロギング情報の種別毎にファイリングするロギング情報管理手段を
有することを特徴とするロギング情報管理システム。
（付記３）
付記２記載のロギング情報管理システムにおいて、
前記ロギング情報送信手段は、ユーザ・データグラム・プロトコルによりレベルを指定した複数種別のロギング情報を送信し、前記ロギング情報のパケットサイズ長が最大パケットサイズを超えたとき前記ロギング情報を分割して送信することを特徴とするロギング情報管理システム。
（付記４）
付記３記載のロギング情報管理システムにおいて、
前記ロギング情報管理手段は、受信したロギング情報の種別毎に記憶する一次メモリ手段と、
前記一次メモリ手段に記憶されている分割されたロギング情報を結合して前記種別毎に記憶する整形済みメモリ手段と、
前記整形済みメモリ手段の情報を前記種別毎に退避する非常用メモリ手段を有し、
前記整形済みメモリ手段または前記非常用メモリ手段に記憶されたロギング情報を前記種別毎にファイリングすることを特徴とするロギング情報管理システム。
（付記５）
付記４記載のロギング情報管理システムにおいて、
前記ロギング情報管理手段は、特定のロギング情報を受信したとき非常運用モードに切り替えて、前記整形済みメモリ手段の情報を前記種別毎に退避することを特徴とするロギング情報管理システム。
（付記６）
付記５記載のロギング情報管理システムにおいて、
前記ロギング情報管理手段は、受信したロギング情報をマルチキャスト配信して複数の表示装置に表示する配信表示手段を
有することを特徴とするロギング情報管理システム。
（付記７）
付記６記載のロギング情報管理システムにおいて、
前記配信表示手段は、分割されたロギング情報を結合し、時系列に並び替えて表示することを特徴とするロギング情報管理システム。
（付記８）
付記６記載のロギング情報管理システムにおいて、
前記ロギング情報管理手段は、受信したロギング情報を前記複数のアプリケーションに通知する通知手段を
有することを特徴とするロギング情報管理システム。

従来のロギング情報の管理方法を説明するための図である。 従来のロギング情報の一元管理方法を説明するための図である。 本発明の運用情報蓄積コンポーネントの概要イメージ図である。 運用情報蓄積コンポーネントの内部構成図である。 ロギング情報のレベルを示す図である。 本発明のロギング情報の一元管理方法を説明するための図である。 複数装置のロギング情報の一元管理を説明するための図である。 本発明のロギング情報の管理構成例を示す図である。 クラスの構成を示す図である。 ＵＤＰ転送データのフォーマットを示す図である。 ロギング情報管理機構におけるロギング情報および制御の流れを示す図である。 編集処理における分割されたロギング情報の結合の様子を示す図である。 メモリプールにおけるロギング情報のフォーマットを示す図である。 表示装置の構成を示す図である。 表示の更新例を示す図である。 コンポーネント本体の制御ロジックのフローチャートである。

符号の説明

２１ コンポーネント本体
２２ ロギング情報収集機構
２３ ロギング情報管理機構
２４ 通知機構および保守機能
２５ 配信表示機構
２６ ロギング情報送信機構
４１ メモリ管理部
４２ メモリ
４３ 非常用メモリ
４４ ファイル管理部
４５ アプリケーション通知部
４６ 運用制御コマンド
４７ モード切り替えコマンド
４８ マルチキャスト配信部
４９ 表示装置
ＦＬ１〜ＦＬ５ ログファイル
４２ａ，４２ｂ，４２ｃ 一次格納メモリプール
４２ｄ，４２ｅ，４２ｆ 整形済みメモリプール
４３ａ，４３ｂ，４３ｃ 非常用メモリプール

Claims (5)

1. 複数のアプリケーションのロギング情報を管理する情報管理システムであって、
   前記複数のアプリケーションにそれぞれ設けられ、各アプリケーションの状況に応じたレベル情報を含むロギング情報を送信し、前記ロギング情報が所定のサイズを超えるときは、前記ロギング情報を分割した、それぞれが前記レベル情報を含む、分割ロギング情報を送信する、複数のロギング情報送信手段と、
   前記ロギング情報および前記分割ロギング情報を受信しファイリングするロギング情報管理手段と、を備え、
   前記ロギング情報管理手段は、
   前記ロギング情報および前記分割ロギング情報を受信するロギング情報収集手段と、
   前記ロギング情報収集手段で受信した前記ロギング情報および前記分割ロギング情報を、前記レベル情報ごとに記憶する一次メモリ手段と、
   前記一次メモリ手段に記憶されている前記分割ロギング情報を結合し、前記ロギング情報とともに前記レベル情報ごとに記憶する整形済みメモリ手段と、
   前記整形済みメモリ手段の全情報を退避可能な非常用メモリ手段と、
   前記整形済みメモリ手段に記憶されている前記ロギング情報を、ファイリングするファイル管理手段を有し、
   前記ロギング情報管理手段は、通常運用モードおよび非常運用モードを有し、
   前記ロギング情報収集手段が、前記レベル情報が例外レベルである前記ロギング情報または前記分割ロギング情報を受信したときは、非常運用モードに移行し、所定の時間後に通常運用モードに移行し、
   前記ロギング情報管理手段が前記通常運用モードにあるときは、前記ファイル管理手段は、前記整形済みメモリ手段に記憶された前記ロギング情報のうち、所定のレベル以上の前記ロギング情報を前記レベル情報ごとにファイリングし、
   前記ロギング情報管理手段が、前記非常運用モードに移行したときに、前記整形済みメモリ手段の情報をすべて前記非常用メモリ手段に退避し、前記非常用メモリ手段より前記レベル情報ごとにファイリングするとともに、その後、前記整形済みメモリ手段に記憶される前記ロギング情報をすべて前記レベル情報ごとにファイリングする、ことを特徴とするロギング情報管理システム。
2. 請求項１記載のロギング情報管理システムであって、
   前記ロギング情報管理手段は、受信した前記ロギング情報または前記分割ロギング情報をマルチキャスト配信する配信手段を有することを特徴とするロギング情報管理システム。
3. 請求項１記載のロギング情報管理システムであって、
   前記マルチキャスト配信された前記ロギング情報または前記分割ロギング情報を受信する複数の表示手段を有し、
   前記複数の表示手段は、所定のレベル以上の前記ロギング情報または前記分割ロギング情報のみを抽出し、前記抽出された前記分割ロギング情報を結合し、時系列に並び替えて表示することを特徴とするロギング情報管理システム。
4. 複数のアプリケーションにそれぞれ設けられ、各アプリケーションの状況に応じたレベル情報を含むロギング情報を送信し、前記ロギング情報が所定のサイズを超えるときは、前記ロギング情報を分割した、それぞれが前記レベル情報を含む、分割ロギング情報を送信する、複数のロギング情報送信手段からの前記ロギング情報および前記分割ロギング情報を受信しファイリングするロギング情報管理手段であって、
   前記ロギング情報および前記分割ロギング情報を受信するロギング情報収集手段と、
   前記ロギング情報収集手段で受信した前記ロギング情報および前記分割ロギング情報を、前記レベル情報ごとに記憶する一次メモリ手段と、
   前記一次メモリ手段に記憶されている前記分割ロギング情報を結合し、前記ロギング情報とともに前記レベル情報ごとに記憶する整形済みメモリ手段と、
   前記整形済みメモリ手段の全情報を退避可能な非常用メモリ手段と、
   前記整形済みメモリ手段に記憶されている前記ロギング情報を、前記レベル情報ごとにファイリングするファイル管理手段を有し、
   前記ロギング情報管理手段は、通常運用モードおよび非常運用モードを有し、
   前記ロギング情報収集手段が、前記レベル情報が例外レベルである前記ロギング情報または前記分割ロギング情報を受信したときは、前記非常運用モードに移行し、所定の時間後に前記通常運用モードに移行し、
   前記ロギング情報管理手段が、前記非常運用モードに移行したときに、前記整形済みメモリ手段の情報をすべて前記非常用メモリ手段に退避し、前記非常用メモリ手段より前記レベル情報ごとにファイリングするとともに、その後、前記整形済みメモリ手段に記憶される前記ロギング情報をすべて前記レベル情報ごとにファイリングする、ことを特徴とするロギング情報管理手段。
5. 複数のアプリケーションより送信された、各アプリケーションの状況に応じたレベル情報を含むロギング情報、または、前記ロギング情報が所定のサイズを超えるときは、前記ロギング情報を分割したそれぞれが前記レベル情報を含む分割ロギング情報を、受信しファイリングする、ロギング情報管理方法であって、
   前記ロギング情報および前記分割ロギング情報を受信する収集ステップと、
   前記受信した前記ロギング情報および前記分割ロギング情報を、前記レベル情報ごとに記憶するステップと、
   前記レベル情報ごとに記憶された前記分割ロギング情報を結合し、前記ロギング情報とともに前記レベル情報ごとに整形済みメモリ手段に記憶するステップと、
   前記レベル情報ごとに記憶された、前記結合された前記分割ロギング情報および前記ロギング情報を、前記レベル情報ごとにファイリングするステップと、を備え、
   前記収集ステップで、前記レベル情報が例外レベルである前記ロギング情報または前記分割ロギング情報を受信したときは、非常運用モードに移行し、所定の時間後に通常運用モードに移行し、
   前記非常運用モードに移行したときに、前記整形済みメモリ手段の情報をすべて非常用メモリ手段に退避し、前記非常用メモリ手段より前記レベル情報ごとにファイリングするとともに、その後、前記整形済みメモリ手段に記憶される前記ロギング情報をすべて前記レベル情報ごとにファイリングする、ことを特徴とするロギング情報管理方法。

Images