JP2004078401A - ログ出力管理統合システム - Google Patents

Abstract

【課題】多様な手段での出力方式を有する複数のアプリケーションのログ出力設定およびログ統合管理を実現するシステムの提供
【解決手段】多様な手段での出力方式を有する複数のアプリケーションＡＰ１〜ＡＰ４から第１インタフェース６を介して受信したログ情報のキューイング処理を行うログ出力クライアント４と、前記ログ出力クライアント４から第２インタフェース７を介して受信したログ情報の管理並びに出力を行うログ出力管理サーバ５と、から成り、前記ログ出力サーバ５にて、多様な手段での出力方式を有する複数のアプリケーションＡＰ１〜ＡＰ４のログ出力設定処理およびログの統合管理を一元的に行うことを可能とする。
【選択図】　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、複数のアプリケーションのログ情報を一元的に出力管理，統合管理可能なログ出力管理統合システムに関するものである。
【０００２】
【従来の技術】
従来、各種アプリケーションは、当該アプリケーションにおける処理状況やエラー発生状況をログとして、トレースファイル，イベントログ，ｓｙｓｌｏｇ，メール，ＳＮＭＰトラップ，データベース（以下、ＤＢという）等といった多様な手段で出力している。
【０００３】
【発明が解決しようとする課題】
しかしながら、上記のような出力処理はアプリケーション毎に独自に実装されることが多く、他アプリケーションでの使用を考慮されることが少ないため、ログ出力設定方法が各アプリケーション独自のものとなり、その結果、ログ出力設定の統合的な管理ができないといった不都合が生じていた。また、これによりログ管理ドメインの制御も難しくなるといった不都合が生じていた。
【０００４】
また、以上のような不都合により、上述した従来技術では、アプリケーションの開発工数が余計にかかってしまうといった不都合や、各アプリケーションが独自にログ出力を行うため、各アプリケーションによるログの出力先やフィルタリング設定などの管理、ならびにログの一元管理が困難であるといった不都合が生じてしまう。
【０００５】
そこで本発明の目的は、各種アプリケーションに対してログ出力のための統一されたインタフェースを提供してアプリケーション開発効率を上げ、トレースファイル，イベントログ，ｓｙｓｌｏｇ，メール，ＳＮＭＰトラップ，ＤＢ等の多様な手段での出力方式および出力手段拡張機能を有し、複数のアプリケーションのログ出力設定およびログの統合管理を一元的に行うことを可能とするログ出力管理統合システムを提供することにある。
【０００６】
【課題を解決するための手段】
上記目的を達成するため、本発明のログ出力管理統合システムは、多様な手段での出力方式を有する複数のアプリケーションから成るクライアントアプリケーション群と、各アプリケーションが共有可能な共有ライブラリと、前記複数のアプリケーションから第１インタフェースを介して受信したログ情報のキューイング処理を行うログ出力クライアントと、前記ログ出力クライアントから第２インタフェースを介して受信したログ情報の管理並びに出力を行うログ出力管理サーバと、から成り、前記ログ出力サーバは、前記ログ出力クライアントから受信したログ情報の出力条件が格納されるログ出力管理設定データベースと、前記ログ出力管理設定データベース内の出力条件に基づいてログ情報の管理処理および出力処理を行うログ出力管理部と、ログ情報を出力する複数のログ出力モジュールと、これら複数のログ出力モジュールの内から各メッセージの最適な出力先となるログ出力モジュールを選択してログ出力管理部と最適ログ出力モジュールとを接続するログ出力モジュール選択接続部と、を具備し、前記ログ出力サーバにて、多様な手段での出力方式を有する複数のアプリケーションのログ出力設定処理およびログの統合管理を行うことを可能とする構成となっている。
【０００７】
また本発明のログ出力管理統合システムにおいて、前記ログ出力クライアントは、クライアントアプリケーション群から受信した各メッセージのキューイング処理並びに送信処理を管理，実行するメッセージキュー管理部と、緊急を要さないメッセージをキューイングする通常メッセージキューと、緊急を要するメッセージをキューイングする緊急メッセージキューと、前記メッセージキュー管理部が各メッセージキューからメッセージを順次取り出す際の優先順位に関する条件が定義されている設定ファイルと、を具備して成る。
【０００８】
さらに本発明のログ出力管理統合システムにおいて、複数のログ出力管理サーバを接続してログ出力管理サーバを階層化し、且つ接続されたログ出力管理サーバの内の下位のサーバにおける前記複数のログ出力モジュールの内に、ログ情報を他のログ出力管理サーバへ転送する機能を備えたフォワーダを備えた構成としても、上記目的を達成することができる。
【０００９】
【発明の実施の形態】
以下、本発明の一実施形態に係るアプリケーションログ出力管理統合システムについて、図面を用いて詳細に説明する。
【００１０】
＜本実施形態に係るシステムの構成＞
まず、本実施形態に係るアプリケーションログ出力管理統合システムの構成について、図１を参照して説明する。図１は、本発明の一実施形態に係るアプリケーションログ出力管理統合システムの構成を示す図である。
【００１１】
本実施形態によるアプリケーションログ出力管理統合システム１は、クライアントマシン内において使用される複数のアプリケーションから成るクライアントアプリケーション群２（以下、クライアントＡＰ群という）と、各アプリケーションが共有可能に関数やデータを提供する共有ライブラリ３と、前記クライアントＡＰ群２の各クライアントアプリケーションＡＰ１〜ＡＰ４（以下、単にアプリケーションという）から受信したログ情報（以下、メッセージともいう）のキューイング処理並びに後述のログ出力管理サーバ５への送信処理を行うログ出力クライアント４と、前記ログ出力クライアント４から受信したログ情報の管理並びに出力を行うログ出力管理サーバ５と、前記クライアントＡＰ群２と前記ログ出力クライアント４とを接続するクライアントインタフェース６と、前記ログ出力クライアント４と前記ログ出力管理サーバ５とを接続するサーバインタフェース７と、から構成されている。尚、本実施形態におけるクライアントＡＰ群は４種類のアプリケーションＡＰ１〜ＡＰ４から成るが、クライアントＡＰ群を構成するアプリケーションの数はこれに限定されるものではない。
【００１２】
前記ログ出力クライアント４は、クライアントＡＰ群２から受信した各メッセージのキューイング処理並びに送信処理を管理，実行するメッセージキュー管理部４ａと、例えばシステムの稼動状況に関するメッセージのように緊急を要さないメッセージをキューイングする通常メッセージキュー４ｂと、例えば異常終了や致命的なエラーに関するメッセージのように緊急を要するメッセージをキューイングする緊急メッセージキュー４ｃと、前記メッセージキュー管理部４ａが各メッセージキュー４ｂ，４ｃからメッセージを順次取り出す際の優先順位に関する条件が定義されている設定ファイル４ｄと、を具備している。尚、このログ出力クライアント４は、前記クライアントＡＰ群２と同一ホストコンピュータ上に存在しており、この同一ホスト上で処理されるものである。
【００１３】
ここで、前記設定ファイル４ｄにて定義されている条件としては、具体的には、通常メッセージキュー４ｂのメッセージよりも先に緊急メッセージキュー４ｃのメッセージを取り出すというようなメッセージタイプによる優先順位付けの条件、あるいは例えばアプリケーションＡＰ１を最優先に取り出すというようなアプリケーション名による優先順位付けの条件などがある。また、優先順位付け条件は任意に定義付け可能である。
【００１４】
前記ログ出力サーバ５は、前記ログ出力クライアント４から送信されたログ情報の出力条件が格納されるログ出力管理設定データベース５ａ（以下、ログ出力管理設定ＤＢという）と、前記ログ出力管理設定ＤＢ５ａ内の出力条件に基づいてログ情報の管理処理および出力処理を行うログ出力管理部５ｂと、ログ情報を出力する複数のログ出力モジュールＭ１〜Ｍ３と、これら複数のログ出力モジュールＭ１〜Ｍ３の内から各メッセージの最適な出力先となるログ出力モジュールを選択してログ出力管理部５ｂと最適ログ出力モジュールとを接続するログ出力モジュール選択接続部５ｃと、を具備している。
【００１５】
尚、図１では３種類のログ出力モジュールＭ１〜Ｍ３が設けられているが、ログ出力モジュールの台数はこれに限定されるものではなく、本実施形態に係るシステムにおける前記ログ出力モジュールには、図２に示すように、メール，ｓｙｓｌｏｇ，トレースファイル，ＳＮＭＰトラップ，イベントログ，ＤＢおよびフォワーダの各出力方式を設定している。また、設定するログ出力モジュールの出力方式についても、図２に示す７種類の上記出力方式に限定されるものではない。また、本実施形態におけるフォワーダは、後述のようにログ情報を他のログ出力管理サーバへ転送する機能を備えたものである。
【００１６】
また、前記ログ出力管理設定ＤＢ５ａは、例えば図３のような構成となっている。このログ出力管理設定ＤＢ５ａには、図３に示すように、各メッセージの出力対象を示す「出力対象」項目と、該当するメッセージを出力するか削除するかを決定する「出力・削除」項目と、各メッセージにおけるアプリケーションの出力方式を示す「出力手段」項目と、各メッセージにおける出力方式に基づいて選択されたログ出力モジュールからのメッセージ出力先を示す「メッセージ出力先」項目と、から構成されている。
【００１７】
具体的に説明すると、「出力対象」項目には、例えば「アプリケーションＡＰ１の緊急メッセージ」，「アプリケーションＡＰ１の通常メッセージ」等のように設定され、「出力・削除」項目には、各出力条件キーごとに「出力」，「削除」の何れかが設定されている。尚、緊急メッセージについては全て「出力」と設定されている。また「出力手段」項目には、「トレースファイル」，「イベントログ」，「ｓｙｓｌｏｇ」，「ＳＮＭＰトラップ」等といった各アプリケーションの出力方式が設定されている。さらに「メッセージ出力先」項目には、各メッセージにおける出力方式に対応して、例えばトレースファイルの場合はそのパス名，イベントログの場合はホスト名とデータソース名，ｓｙｓｌｏｇの場合はｓｙｓｌｏｇサーバＩＰアドレス，ポート番号，プライオリティ及びログ名，メールの場合はメールアドレスとＳＭＴＰサーバ名，ＳＮＭＰトラップの場合は出力先ＩＰアドレスと使用するＯＩＤ（Ｏｂｊｅｃｔ　ＩＤｅｎｔｉｆｉｅｒ），ＤＢの場合はＤＢサーバ名，ＤＢ名およびテーブル名，フォワーダの場合はログ出力管理サーバＩＰアドレスとポート番号，がメッセージ出力先の情報としてそれぞれ設定されている。尚、このログ出力管理設定ＤＢに格納される出力条件は任意に設定可能である。
【００１８】
＜本実施形態に係るシステムによる処理動作＞
次に、本実施形態に係るログ出力管理統合システム１によるログ出力管理統合処理について、図４から図８を参照して以下説明する。
【００１９】
まず、クライアントＡＰ群２における各アプリケーションからログ出力クライアント４へのログ情報の送信処理について説明する。ログ出力を行う際のクライアントＡＰ群２における各アプリケーションは、共有ライブラリ３にて提供される１個の関数を用い、クライアントインタフェース６を介してログ情報をログ出力クライアント４に送信する。尚、この関数は任意に設定可能である。また、各メッセージは通常メッセージであるか緊急メッセージであるかのフラグ（以下、メッセージタイプともいう）を持っている。また、各アプリケーションからログ出力クライアント４へ送信される送信情報は、例えば図４のような構成となっている。
【００２０】
＜ログ出力クライアントにおける処理手順＞
次に、ログ出力クライアント４における処理手順について、図５を参照して説明する。まず、各アプリケーションからメッセージを受信すると（ステップＳＴ１）、ログ出力クライアント４のメッセージキュー管理部４ａは、受信メッセージをアプリケーション名ごとに１メッセージ１ファイルとして一旦キューイングする。また、キューイングの際に、メッセージキュー管理部４ａは、各メッセージの持つフラグに基づいて、各メッセージを通常メッセージキュー４ｂ又は緊急メッセージキュー４ｃにキューイングする（ステップＳＴ２）。
【００２１】
続いて、メッセージキュー管理部４ａは、別スレッドにて各キュー４ｂ，４ｃからメッセージを取得し（ステップＳＴ３）、ログ出力管理サーバ５へサーバインタフェース７（ＴＣＰソケット通信）を介して送信する（ステップＳＴ４）。ここで、メッセージキュー管理部４ａは、設定ファイル４ｄに定義された条件に基づいて、アプリケーション名およびメッセージタイプにより優先順位付けを行いながらメッセージを各キュー４ｂ，４ｃから順次取得する。尚、このメッセージキュー管理部４ａによりログ出力管理サーバ５へ送信される送信情報は、例えば図６のような構成となっている。
【００２２】
＜ログ出力管理サーバにおける処理手順＞
以上のようにしてメッセージをログ出力クライアント４から受信したログ出力管理サーバ５における処理手順について、図７を参照して説明する。上述のようにログ出力管理サーバ５がログ出力クライアント４からメッセージを受信すると（ステップＳＴ１１）、ログ出力管理部５ｂは、各メッセージに対し、当該受信メッセージを出力するか削除するか、をログ出力管理設定ＤＢ５ａの「出力対象」項目および「出力・削除」項目に基づいて判定する（ステップＳＴ１２）。ここで、削除するメッセージについては削除処理を行い（ステップＳＴ１３）、次の受信メッセージについてステップＳＴ１２の判定処理を改めて行う。
【００２３】
一方、ステップＳＴ１２においてメッセージを出力すると判定した場合には、ログ出力モジュール選択接続部５ｃが当該メッセージについて、ログ出力管理設定ＤＢ５ａの「出力手段」項目から当該メッセージにおけるアプリケーションの出力方式を参照し、そのメッセージの最適なログ出力モジュールを選択し（ステップＳＴ１４）、選択された最適ログ出力モジュールとログ出力管理部５ｂとを接続する（ステップＳＴ１５）。
【００２４】
ステップＳＴ１５の後、ログ出力管理部５ｂは、選択された最適ログ出力モジュールから出力されるログ情報のメッセージ出力先を、ログ出力管理設定ＤＢ５ａの「メッセージ出力先」項目から取得して出力するメッセージと共に最適ログ出力モジュールに送信し且つ当該最適ログ出力モジュールをダイナミックロードし（ステップＳＴ１６）、しかる後にこの最適ログ出力モジュールが、メッセージ出力先データに基づいて当該受信メッセージをメッセージ出力先に送信する（ステップＳＴ１７）。
【００２５】
尚、メッセージ出力先のデータとしては、具体的には上述の如く、トレースファイルの場合はそのパス名，イベントログの場合はホスト名とデータソース名，ｓｙｓｌｏｇの場合はｓｙｓｌｏｇサーバＩＰアドレス、ポート番号、プライオリティおよびログ名，メールの場合はメールアドレスとＳＭＴＰサーバ名，ＳＮＭＰトラップの場合は送信先ＩＰアドレスと使用するＯＩＤ，ＤＢの場合はＤＢサーバ名、ＤＢ名およびテーブル名，フォワーダの場合はログ出力管理サーバＩＰアドレスとポート番号などである。また、最適ログ出力モジュールのダイナミックロードの際にログ出力管理部から最適ログ出力モジュールへ送信される送信情報は、例えば図８のような構成となっている。
【００２６】
以上のステップＳＴ１１〜ＳＴ１７の処理を、受信した各メッセージについて行い、全ての受信メッセージについて上記処理を行った場合に、ログ出力管理サーバ５の全処理工程が終了となる（ステップＳＴ１８）。
【００２７】
このように、上記構成を有する本実施形態のログ出力管理統合システム１によれば、多様な手段（トレースファイル，イベントログ，ｓｙｓｌｏｇ，メール，ＳＮＭＰトラップ，データベース等）でログ出力を行いたい場合でも、アプリケーション毎に、あるいは出力手段毎に出力処理の再実装を行わなくてもよいため、アプリケーションの開発工数が余計にかかってしまうといった不都合は解消される。
【００２８】
また、本実施形態のログ出力管理統合システム１によれば、各アプリケーション，各カテゴリ，各出力手段においてログを出力するかどうかをログ出力管理設定ＤＢ５ａにより任意に設定できるため、各アプリケーションが出力するログの出力先やフィルタリングの設定をログ出力管理設定ＤＢ５ａにて一元管理できる。さらに、出力手段としてＤＢやトレースファイル等を利用することにより、各アプリケーションが出力するログを一元管理できる。
【００２９】
さらにまた、ログ出力モジュールの追加拡張が可能なので、システムの構築後に出力手段を追加したい場合にも、アプリケーション本体を変更せず、設定変更もしくはログ出力モジュールの追加を行えば良いといった利点がある。また、ログ出力モジュールをダイナミックローディングさせることにより、ログ出力管理サーバの再コンパイルの必要がなく、また停止する必要もない。
【００３０】
＜第二実施形態＞
ここで、上記第一実施形態において、複数のログ出力モジュールの内の一つに、メッセージを他のログ出力管理サーバへ転送するフォワーダを備えた場合、図９（ａ）のようにログ出力管理サーバの階層化を実現することができる。例えば、図９（ａ）のような３台のログ出力管理サーバＳＶ１〜ＳＶ３の階層化を行った際に、図９（ｂ）のようなフォワーダの設定を行い、この設定条件を各ログ出力管理サーバＳＶ１〜ＳＶ３のログ出力管理設定ＤＢに格納したとする。この場合、ログ出力管理サーバＳＶ１は管理ドメインＤ１内のログ情報、即ち、ホストＨ１のアプリケーションＡＰ１およびアプリケーションＡＰ３のログ情報を管理することとなる。
【００３１】
またログ出力管理サーバＳＶ２は、ホストＨ２のアプリケーションＡＰ１およびアプリケーションＡＰ２のログ情報と、ホストＨ３のアプリケーションＡＰ１およびアプリケーションＡＰ４のログ情報とを取得するが、ログ出力管理サーバＳＶ２のフォワーダが図９（ｂ）のフォワーダの設定により、アプリケーションＡＰ４のログ情報をログ出力管理サーバＳＶ３に転送することとなるため、ログ出力管理サーバＳＶ２は管理ドメインＤ２内のログ情報、即ち、ホストＨ２のアプリケーションＡＰ１およびアプリケーションＡＰ２のログ情報と、ホストＨ３のアプリケーションＡＰ１のログ情報とを管理することとなる。
【００３２】
またログ出力管理サーバＳＶ３は、ホストＨ４のアプリケーションＡＰ４およびアプリケーションＡＰ５のログ情報を取得するが、ログ出力管理サーバＳＶ２のフォワーダが、図９（ｂ）のフォワーダの設定により、アプリケーションＡＰ４のログ情報をログ出力管理サーバＳＶ３に転送することとなるため、ログ出力管理サーバＳＶ３は管理ドメインＤ３内のログ情報、即ち、ホストＨ３のアプリケーションＡＰ４のログ情報と、ホストＨ４のアプリケーションＡＰ４およびアプリケーションＡＰ５のログ情報とを管理することとなる。
【００３３】
以上のように、フォワーダによってメッセージを他のログ出力管理サーバへ転送することにより複数のログ出力管理サーバを階層化することによって、アプリケーション名，メッセージカテゴリ名単位でログ情報の管理ドメインを制御することができるため、システム自身のスケーラビリティの確保が可能となり、且つネットワークへの負荷の低減ならびに管理の分担を容易に行うことが可能となる。また、ログの転送によるネットワークのトラフィックを抑制することもできる。さらには、下位のログ出力管理サーバのログ情報を上位サーバへ転送することにより、下位のログ出力管理サーバの状態も上位サーバで把握することができるため、管理者の作業効率の向上にもつながることとなる。
【００３４】
＜ログ出力管理設定ＤＢの構成の他の具体例＞
尚、上記第一実施形態および第二実施形態におけるログ出力管理設定ＤＢの構成は、上述の構成の他に、例えば図１０のような構成としてもよい。この図１０の構成によれば、ログ出力管理設定情報として最も大きい単位はログ出力管理サーバのリストであり、図１０ではログ出力管理サーバＳＶ１について登録されている。またログ出力管理サーバＳＶ１は、ログ出力モジュールリスト，ＡＰ共通設定リスト，ＡＰ個別設定リストを有する構成となっている。
【００３５】
ログ出力モジュールリストには、複数のログ出力モジュールを登録可能であり、このログ出力モジュールリストは、図１０のように各出力手段用のログ出力モジュール名（図中、Ｔｒａｃｅ，ＳｎｍｐＴｒａｐに相当），モジュール名（図中、ＭｏｄｕｌｅＮａｍｅ＝ｔｒａｃｅ．ｄｌｌ，ＭｏｄｕｌｅＮａｍｅ＝ｓｎｍｐｔｒａｐ．ｄｌｌに相当），関数名（図中、ＦｕｎｃＮａｍｅ＝ｔｒａｃｅｏｕｔ，ＦｕｎｃＮａｍｅ＝ｓｅｎｄｔｒａｐ．ｄｌｌに相当）を１単位とするリストである。
【００３６】
またＡＰ共通設定リストは、上記と同様のログ出力モジュール名と、共通設定情報とを１単位とするリストであり、共通設定情報には図１０のように、Ｔｒａｃｅ出力用モジュールでは、出力するかしないかのデフォルト値と、出力先フォルダのデフォルト値と、サイズ制限のデフォルト値と、ファイル個数のデフォルト値と、トレースファイル全体のサイズ制限のデフォルト値と、が登録されている。またＳｎｍｐＴｒａｐ出力用モジュールでは、出力するかしないかのデフォルト値と、出力先ＩＰアドレスのデフォルト値と、使用するＯＩＤのデフォルト値と、一般番号のデフォルト値と、ＳｎｍｐＴｒａｐの最大データ長と、が登録されている。
【００３７】
またＡＰ個別設定リストは、アプリケーション名リスト（図では、アプリケーションＡＰ１，ＡＰ２）を有し、各アプリケーション名はメッセージカテゴリ名リストを有しており、各メッセージカテゴリ名はログ出力モジュール名と個別設定情報とを有する構成となっている。
【００３８】
具体的には、例えばアプリケーションＡＰ１において、ＴｒａｃｅのＥｒｒｏｒＭｅｓｓａｇｅについては、Ｔｒａｃｅ出力用モジュールにＥｒｒｏｒＭｅｓｓａｇｅを出力するよう設定されており（Ｅｎａｂｌｅｄ＝Ｔｒｕｅ）、この出力の際には、ＥｒｒｏｒＭｅｓｓａｇｅをＣ：￥Ｔｒａｃｅ￥ＡＰ１フォルダ内のトレースファイルに出力するように登録されている。また、１トレースファイルのサイズ制限（Ｓｉｚｅ＝１００）とトレースファイルの個数制限（Ｇｅｎｅｒａｔｉｏｎ＝５）とが登録されている。また、アプリケーションＡＰ１におけるＳｎｍｐＴｒａｐのＥｒｒｏｒＭｅｓｓａｇｅについては、ＳｎｍｐＴｒａｐ出力用モジュールにＥｒｒｏｒＭｅｓｓａｇｅを出力するよう設定されており、この出力の際には、ＥｒｒｏｒＭｅｓｓａｇｅをＩＰアドレス１０．１．１．１に向けて発行するように登録されている。またこの他に、ＳｎｍｐＴｒａｐを発行するときのＯＩＤ（ＥｎｔｅｒｐｒｉｓｅＩＤ＝１．３．６．１．４．１．６０４９．１０１），ＳｎｍｐＴｒａｐを発行するときの一般番号（ＧｅｎｅｒｉｃＩＤ＝６），ＳｎｍｐＴｒａｐを発行するときの固有番号（ＳｐｅｃｉｆｉｃＩＤ＝１）とが登録されている。
【００３９】
以上のようなデータは、図１０においてＤｅｂｕｇＭｅｓｓａｇｅについても上記と同様に登録されているが、ＳｎｍｐＴｒａｐのＤｅｂｕｇＭｅｓｓａｇｅは出力しないように登録されている（Ｅｎａｂｌｅｄ＝Ｆａｌｓｅ）。さらに、アプリケーションＡＰ２以降、各アプリケーションについても同様のデータが登録されている。
【００４０】
以上のようなログ出力管理設定ＤＢ内の構成によっても、ログ出力管理サーバＳＶ１では、このログ出力管理設定ＤＢ内の各データ（各メッセージを出力するか削除するかというデータ，各メッセージにおけるアプリケーションの出力方式に関するデータ，各メッセージにおける出力方式に基づいて選択されたログ出力モジュールからのメッセージ出力先を示すデータ）に基づき、図７と同様の工程の処理が行われることによって、アプリケーション名とメッセージカテゴリ名ごとの出力管理が可能となる。また、図１０ではログ出力管理サーバＳＶ１に関するデータ構成のみを示しているが、例えば図９のようなログ出力管理サーバの階層化を行うにあたっては、階層化の対象となる各ログ出力管理サーバＳＶ２，ＳＶ３に関するデータについても、ログ出力管理サーバＳＶ１に関するデータと同様のデータ構成でログ出力管理設定ＤＢ内に登録することで、各ログ出力管理サーバＳＶ１〜ＳＶ３において、各ログ出力管理サーバＳＶ１〜ＳＶ３のログ出力管理設定ＤＢ内のデータに基づいて図７に示す工程の処理がそれぞれ行われ、アプリケーション名ごと，メッセージカテゴリ名ごとの出力管理が可能となる。
【００４１】
【発明の効果】
以上述べたように、本発明のログ出力管理統合システムによれば、次に示すような効果を得ることができる。まず、トレースファイル，イベントログ，ｓｙｓｌｏｇ，メール，ＳＮＭＰトラップ等といった多様な手段でログ出力を行いたい場合、アプリケーションごと，あるいは手段ごとに出力処理の再実装を行う必要がない。また、各アプリケーション，各メッセージカテゴリ，各出力手段においてログを出力するか否かをログ出力管理設定ＤＢにおいて設定できるため、各アプリケーションが出力するログの出力先やフィルタリングの設定をログ出力管理ＤＢにて一元管理できる。
【００４２】
さらに、出力手段としてデータベースやトレースファイル等を利用することにより、各アプリケーションが出力するログを一元管理できる。さらにまた、ログ出力モジュールの追加拡張が可能なので、システム構築後に改めて出力手段を追加したい場合には、アプリケーション本体を変更せずとも、システムの設定変更もしくはログ出力モジュールの追加を行えば良く、容易に追加処理を行うことができる。また、ログ出力モジュールをダイナミックローディングさせることによりログ出力管理サーバの再コンパイルの必要はなく、停止する必要もない。
【００４３】
さらに、ログ出力モジュールにフォワーダを設けることで、ログ出力管理サーバを階層構造にすることができ、その結果、ログの管理ドメインを制御できることとなるため、本システムのスケーラビリティが確保でき、またログの転送によるネットワークのトラフィックを抑制することが可能となる。さらにまた、このようにログ出力管理サーバを階層構造にした場合、下位ログ出力管理サーバのログも上位サーバへ転送することによって、下位ログ出力管理サーバの状態も上位サーバで把握可能となるため、管理者の作業効率の向上にもつながる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るログ出力管理統合システムの構成を示す図である。
【図２】本実施形態に係るログ出力管理統合システムのログ出力管理サーバに設けられるログ出力モジュールの一例を示す図である。
【図３】本実施形態に係るログ出力管理統合システムのログ出力管理サーバに設けられるログ出力管理設定ＤＢの構成の一例を示す図である。
【図４】各アプリケーションからログ出力クライアント４へ送信される送信情報の構成の一例を示す図である。
【図５】本実施形態に係るログ出力管理統合システムにおいて、ログ出力クライアントにおける処理手順を示すフローチャートである。
【図６】メッセージキュー管理部によりログ出力管理サーバへ送信される送信情報の構成の一例を示す図である。
【図７】本実施形態に係るログ出力管理統合システムにおいて、ログ出力管理サーバにおける処理手順を示すフローチャートである。
【図８】ログ出力管理部から最適ログ出力モジュールへ送信される送信情報の構成の一例を示す図である。
【図９】ログ出力管理サーバの階層化を行った場合のログ出力管理統合システムを説明するための図であり、図９（ａ）は３台のログ出力管理サーバの階層化を行った場合の構成の一例を示し、図９（ｂ）は図９（ａ）の階層化を行った場合のフォワーダの設定条件の一例を示す図である。
【図１０】ログ出力管理設定ＤＢの構成の他の例を示す図である。
【符号の説明】
１…ログ出力管理統合システム、２…クライアントＡＰ群、３…共有ライブラリ、４…ログ出力クライアント、４ａ…メッセージキュー管理部、４ｂ…通常メッセージキュー、４ｃ…緊急メッセージキュー、４ｄ…設定ファイル、５…ログ出力管理サーバ、５ａ…ログ出力管理設定ＤＢ、５ｂ…ログ出力管理部、５ｃ…ログ出力モジュール選択接続部、６…クライアントインタフェース、７…サーバインタフェース、ＡＰ１〜ＡＰ４…クライアントアプリケーション（アプリケーション）、Ｍ１〜Ｍ３…ログ出力モジュール。

Claims (3)

1. 多様な手段での出力方式を有する複数のアプリケーションから成るクライアントアプリケーション群と、各アプリケーションが共有可能な共有ライブラリと、前記複数のアプリケーションから第１インタフェースを介して受信したログ情報のキューイング処理を行うログ出力クライアントと、前記ログ出力クライアントから第２インタフェースを介して受信したログ情報の管理並びに出力を行うログ出力管理サーバと、から成り、
   前記ログ出力サーバは、前記ログ出力クライアントから受信したログ情報の出力条件が格納されるログ出力管理設定データベースと、前記ログ出力管理設定データベース内の出力条件に基づいてログ情報の管理処理および出力処理を行うログ出力管理部と、ログ情報を出力する複数のログ出力モジュールと、これら複数のログ出力モジュールの内から各メッセージの最適な出力先となるログ出力モジュールを選択してログ出力管理部と最適ログ出力モジュールとを接続するログ出力モジュール選択接続部と、を具備し、
   前記ログ出力サーバにて、多様な手段での出力方式を有する複数のアプリケーションのログ出力設定処理およびログの統合管理を行うことを可能とすることを特徴とするログ出力管理統合システム。
2. 前記ログ出力クライアントは、クライアントアプリケーション群から受信した各メッセージのキューイング処理並びに送信処理を管理，実行するメッセージキュー管理部と、緊急を要さないメッセージをキューイングする通常メッセージキューと、緊急を要するメッセージをキューイングする緊急メッセージキューと、前記メッセージキュー管理部が各メッセージキューからメッセージを順次取り出す際の優先順位に関する条件が定義されている設定ファイルと、を具備していることを特徴とする請求項１に記載のログ出力管理統合システム。
3. 複数のログ出力管理サーバを接続してログ出力管理サーバを階層化し、且つ接続されたログ出力管理サーバの内の下位のサーバにおける前記複数のログ出力モジュールの内に、ログ情報を他のログ出力管理サーバへ転送する機能を備えたフォワーダを備えて成ることを特徴とする請求項１又は２に記載のログ出力管理統合システム。

Images