特開 2024-170942 ログ正規化システム及びログ正規化方法

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

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

(11)【公開番号】P2024170942

(43)【公開日】2024-12-11

(54)【発明の名称】ログ正規化システム及びログ正規化方法

(51)【国際特許分類】

   G06F 11/34 20060101AFI20241204BHJP

【ＦＩ】

G06F11/34 176

【審査請求】未請求

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2023087720

(22)【出願日】2023-05-29

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＵＮＩＸ

(71)【出願人】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110001689

【氏名又は名称】青稜弁理士法人

(72)【発明者】

【氏名】井出 貴也

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

5B042

【Ｆターム（参考）】

5B042MA08

5B042MA09

5B042MA14

5B042MC40

(57)【要約】

【課題】ログに適合するパターンを探索するときの探索に関する精度と処理速度を向上させる。
【解決手段】情報処理システムから出力されるログを構造化されたログに正規化するログ正規化装置において、情報処理システムから出力されるログを受け取るログ入力部と、複数のログのパターンであるパターン情報と、ログ送信元に対応するパターンマッチの第一の優先度を示す第一の優先度情報を格納する記憶部と、受け取ったログが第一の優先度情報対応するログ送信元のとき、前記ログと前記パターン情報のパターンとのパターンマッチを第一の優先度に対応するパターンを用いて行い、マッチした前記パターンを用いて正規化ログに変換するパターンマッチ部と、パターンマッチ部で変換された正規化ログを出力するログ出力部を備える。
【選択図】図１

【特許請求の範囲】

【請求項1】

情報処理システムから出力されるログを構造化されたログに正規化するログ正規化装置において、
情報処理システムから出力されるログを受け取るログ入力部と、
複数のログのパターンであるパターン情報と、ログ送信元に対応するパターンマッチの第一の優先度を示す第一の優先度情報を格納する記憶部と、
受け取ったログが第一の優先度情報に対応するログ送信元のとき、前記ログと前記パターン情報のパターンとのパターンマッチを第一の優先度に対応するパターンを用いて行い、マッチした前記パターンを用いて正規化ログに変換するパターンマッチ部と、
パターンマッチ部で変換された正規化ログを出力するログ出力部と、
を備えることを特徴とするログ正規化装置。

【請求項2】

前記パターン情報のパターンにパターンマッチの優先度を示す第二の優先度を含み、
前記パターンマッチ部は、第一の優先度に基づいたパターンマッチでマッチしなかったとき、第二の優先度を用いてパターンマッチを行う、
ことを特徴とする請求項１に記載のログ正規化装置。

【請求項3】

前記第一の優先度は、ログ送信元で稼働するソフトウェアに基づいて定められた優先順位である、
ことを特徴とする請求項２に記載のログ正規化装置。

【請求項4】

前記第一の優先度は、前記パターン情報に含まれる前記パターン情報に対応付けられた前記第二の優先度を変更する指示を含む、
ことを特徴とする請求項２に記載のログ正規化装置。

【請求項5】

前記第一の優先度は、ソフトウェア取得元で稼働するソフトウェアの評価に基づいて定められた優先順位である、
ことを特徴とする請求項３に記載のログ正規化装置。

【請求項6】

前記第二の優先度の更新情報を受付け、受け付けた更新情報を用いて前記パターン情報に含まれる前記第二の優先度を変更する入出力部を備える、
ことを特徴とする請求項２に記載のログ正規化装置。

【請求項7】

ログ送信元で稼働するソフトウェアのソースコードを受け付け、ソースコードに含まれるパラメータを基にパターンを作成し、作成したパターンを前記パターン情報へ登録する、
ことを特徴とする請求項２に記載のログ正規化装置。

【請求項8】

前記受付けたソースコードの意味解析を行い、ソースコードに含まれる変数、関数の位置および名前からログメッセージを出力し、出力したログメッセージからパラメータを抽出し、出力したログメッセージと抽出したパラメータとに基づいて、パターン情報のパターンを生成する、
ことを特徴とする請求項７に記載のログ正規化装置。

【請求項9】

情報処理システムから出力されるログを構造化されたログに正規化するログ正規化方法において、
ログ入力部が、情報処理システムから出力されるログを受け取り、
記憶部が、複数のログのパターンであるパターン情報と、ログ送信元に対応するパターンマッチの第一の優先度を示す第一の優先度情報を格納し、
パターンマッチ部が、ログ入力部が受け取ったログが第一の優先度情報に対応するログ送信元のとき、前記ログと前記パターン情報のパターンとのパターンマッチを第一の優先度に対応するパターンを用いて行い、マッチした前記パターンを用いて正規化ログに変換し、
ログ出力部が、パターンマッチ部で変換された正規化ログを出力するログ正規化方法。

【請求項10】

前記パターン情報のパターンにパターンマッチの優先度を示す第二の優先度を含み、前記パターンマッチ部は第一の優先度に基づいたパターンマッチでマッチしなかったとき、第二の優先度を用いてパターンマッチを行う、
ことを特徴とする請求項９に記載のログ正規化方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理システムから出力されるログを加工する技術に関する。

【背景技術】

【0002】

システムの監視やデバッグのために、システムから出力されるログが使われている。例えば、非特許文献１には、入力されたログに対し、適合するテンプレートをＴＦ－ＩＤＦ（Term Frequency - Inverse Document Frequency）を用いて探索し、ログの解析と構造化ログへの変換を行う手法が開示されている。また、特許文献1にはデータ取入およびクエリシステムによって、ネットワークを介して複数のシステムから取得されたログを含むデータを取込み、データ取入およびクエリシステムによって、データを取得する範囲および構造化された言語で表現された基準を示すユーザ入力を受信し、ユーザ入力によって示された範囲に基づいてデータを取得し、データ取入およびクエリシステムによって、ユーザ入力によって示された基準および範囲に基づいて、検索されたデータから、コンピューティングデバイスの測定された特性を示す第一数値を含む第一フィールド値および第一ディメンションを含む第二フィールド値を抽出し、データ取入およびクエリシステムによって、時系列メトリックストアに第一の構造化されたメトリックおよび第一ディメンションを記憶することを含み、第一の構造化されたメトリックは第一数値を含み、第一ディメンションは第一数値に関連付けられる方法が開示されている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】米国特許出願公開第US20190163678A1(Generating structured metrics from log data)

【非特許文献】

【0004】

【非特許文献1】D. Schipper, M. Aniche and A. van Deursen, "Tracing Back Log Data to its Log Statement: From Research to Practice," 2019 IEEE/ACM 16th International Conference on Mining Software Repositories, 2019, pp. 545-549

【発明の概要】

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

【0005】

多くの種類のソフトウェアを使用している情報処理システムや多数の情報処理システムモニタしている場合には多種類のログが出力され、出力されたログを正規化（構造化）するためには多種類のパターン（テンプレート）が必要となる。この点、非特許文献１には、入力されたログに対し、適合するテンプレートをＴＦ－ＩＤＦを用いて探索し、ログの解析と構造化ログへの変換を行う手法が開示されている。同じく、特許文献１には入力されたログに対し、適合するSource Typeを非開示の方法にて探索し、構造化ログ相当のメタデータを生成する手法が開示されている。

【0006】

しかしながら、非特許文献１、特許文献１ともに、パターン（テンプレート、Source Type）の数に比例して入力されたログと適合するパターンの探索時間が増加し、また誤ったパターンを探索する可能性が増加する。このため、例えば、著名なツールやミドルウェア、ライブラリの出力しうるログのパターンを全て備えたような巨大なパターンがプリセットされたデータを用いてログを正規化した場合、探索に関する処理速度や精度が問題になりうる。

【0007】

本発明の課題は、膨大なパターンから入力されたログに適合するパターンを探索するときの探索に関する精度と処理速度の向上である。

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

【0008】

本発明にかかるログ正規化システムは、情報処理システムから出力されるログを構造化されたログに正規化するログ正規化装置において、情報処理システムから出力されるログを受け取るログ入力部と、複数のログのパターンであるパターン情報と、ログ送信元に対応するパターンマッチの第一の優先度を示す第一の優先度情報を格納する記憶部と、受け取ったログが第一の優先度情報に対応するログ送信元のとき、前記ログと前記パターン情報のパターンとのパターンマッチを第一の優先度に対応するパターンを用いて行い、マッチした前記パターンを用いて正規化ログに変換するパターンマッチ部と、パターンマッチ部で変換された正規化ログを出力するログ出力部と、を備えることを特徴とするログ正規化装置として構成される。

【発明の効果】

【0009】

本発明によれば、ログに適合するパターンを探索するときの探索に関する精度と処理速度の向上が可能となる。

【図面の簡単な説明】

【0010】

【図1】本発明の実施例におけるシステム構成の一例を示した図である。

【図2】本発明の実施例におけるハードウェア構成の一例を示した図である。

【図3】本発明の実施例における操作画面の一例を示した図である。

【図4A】本発明の実施例における構成情報の構成の一例を示した図である。

【図4B】本発明の実施例における構成情報の構成の一例を示した図である。

【図5】本発明の実施例におけるパターン情報の一例を示した図である。

【図6】本発明の実施例におけるソフトウェア情報の一例を示した図である。

【図7】本発明の実施例における履歴情報の一例を示した図である。

【図8】本発明の実施例におけるソフトウェア識別部の処理例を示したフローチャートである。

【図9】本発明の実施例におけるパターンマッチ部におけるパターンマッチの処理例を示したフローチャートである。

【図10】本発明の実施例におけるパターンマッチの処理例を示したフローチャートである。

【図11】本発明の実施例におけるパターン生成部の処理例を示したフローチャートである。

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

【0011】

以下図面について、本発明の一実施の形態を詳述する。

【0012】

ただし、本発明は後述する実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例および同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。

【0013】

なお、本実施例では各情報を「テーブル」または「ＪＳＯＮフォーマットのテキストデータ」形式にて説明するが、これら情報は必ずしもテーブルによるデータ構造で表現されていなくても良く、リスト、ＤＢ(DataBase)、キュー等のデータ構造やＹａｍｌ、ＸＭＬ等フォーマットのテキストデータや、またそれ以外で表現されていても良い。そのため、データ構造に依存しないことを示すために「テーブル」、「リスト」、「ＤＢ」、「キュー」等について単に「情報」と呼ぶことがある。また、各情報の内容を説明する際に、「識別情報」、「識別子」、「ＩＤ(IDentification)」という表現を用いることが可能であり、これらについてはお互いに置換が可能である。

【0014】

本実施例において、ＧＵＩ(Graphical User Interface)上のボタンの押下を起点に実行される処理は、対応するＡＰＩ(Application Programming Interface)の呼び出しを起点に実行されても良い。

【0015】

各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ(Solid State Drive)等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納できる。

【0016】

また、前述した各構成、機能、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。

【0017】

また、以後の説明では「〇〇機能」などのプログラムを主語とした説明を行う場合があるが、プログラムはプロセッサ２０１によって実行されることで定められた処理を主記憶デバイス２０４および通信制御デバイス２０２を用いながら行うため、プロセッサ２０１を主語とした説明としてもよい。また、プログラムを主語として開示された処理はプログラミング装置が行う処理としてもよい。

【0018】

また、異なる電子計算機間にてデータを取得したりプログラムの機能を呼び出したりする際は、実際にはＷｅｂ ＡＰＩ等の通信プロトコルを用いたリモートプロシージャコールを行っている場合がある。

【実施例0019】

情報処理システムの監視やデバッグのために、システムから出力されるログ（メッセージ）が使われている。ログの形式には、テキストとして出力される非構造ログと、ＪＳＯＮ（JavaScript（登録商標） Object Notation）などで構造化された構造化ログがある。以下、それぞれ例１、例２として示す。

【0020】

（例１）非構造ログ
[2022-12-01T10:51:17.33] ERROR: table sample does not exist
（例２）構造化ログ
{
"timestamp": 1669891877330,
"log_level": "error",
"table": "sample",
"message": "ERROR: table sample does not exist"
}

【0021】

構造化ログは非構造ログに比べ、集計などの機械処理を用いた監視や分析に適する。このため、分析の前処理などとして非構造ログを構造化ログに変換（正規化）することが行われる。このログの正規化には、例えば、上述した非特許文献１や特許文献２に記載された技術により活用できる。なお、情報処理システムには、このようなログを出力する様々なシステムや装置が含まれる。

【0022】

図１は、実施例１に係るシステム構成の一例である。

【0023】

ログ正規化装置１は、図２に一例として示す計算機のようなハードウェア構成により実現される。ログ正規化装置１は、制御部２、パターンマッチ部３、ソフトウェア識別部４、ＧＵＩ機能を有した入出力部５、パターン生成部６、パターン情報７、ソフトウェア情報８、履歴情報９を備える。また、パターンマッチ部３は、ホスト１０で稼働するＡＰＰシステム１１等の外部から未加工ログ１４を受け付け、正規化された正規化ログ１５を外部のストレージ１２等に出力する。また、ソフトウェア識別部４は、管理者等のユーザが使用する外部のユーザ端末１３から入力された構成情報１６を、入出力部５経由で受け付ける。外部とのデータの交換には、例えば、Ｗｅｂ ＡＰＩを利用してもよいし、磁気ディスク装置などの記録媒体から読み込んでも良いし、少量の構成情報であればユーザ端末の画面入力でもよい。以下では、ログ正規化装置１が、ホスト１０、ストレージ１２、ユーザ端末１３とやり取りする場合を一例として記載するが、これらに限らず、本技術はログが出力される様々な環境下で用いることができる。

【0024】

パターンマッチ部３は、未加工ログ１４が入力されるとパターン情報７を用いてログを解析・変換し、正規化ログ１５を外部記憶装置やクラウド等のストレージ１２に出力する(図９にて詳述)。

【0025】

ソフトウェア識別部４は、履歴情報９や構成情報１６を用いてホスト１０等のログの生成元で用いられるソフトウェアを識別し、識別結果をソフトウェア情報８に登録する(図８にて詳述)。

【0026】

入出力部５は、例えば、ＧＵＩ機能により、ユーザ端末１３等からのユーザ操作を元に、パターン情報７、ソフトウェア情報８、履歴情報９のデータの確認、追加、削除、更新を受け付ける(図３にて詳述)。

【0027】

パターン情報７は、未加工ログを解析するための雛形(パターン、テンプレート)を保持するテーブルである(図５にて詳述)。

【0028】

ソフトウェア情報８は、処理対象となるホスト上で稼働していると推測されるソフトウェアの候補を保持するテーブルである(図６にて詳述)。ソフトウェア情報８は、パターンマッチ部３においてマッチングの探索範囲を削減するために使用される。

【0029】

履歴情報９は、パターンマッチ部３にて受け付けた未加工ログ１４および正規化にあたり適用されたパターンのデータを保持するテーブルである(図７にて詳述)。履歴情報９は、ソフトウェア識別部４におけるソフトウェアの識別に利用される。

【0030】

未加工ログ１４は、非構造ログの文字列、およびホスト情報を含むデータである。ホスト情報とは、ログの送信元を特定するための情報で、例えば、送信元ＩＰアドレスや、ホスト名、コンテナ名、Kubernetes（登録商標）のＰｏｄ名、またはそれらの組み合わせであり、例えば、ＪＳＯＮなどのデータ形式で表現される。

【0031】

正規化ログ１５は、未加工ログ１４をログ正規化装置１で構造化ログに正規化したデータで、構造化ログの文字列を含む。また、正規化ログ１５は、メタデータとして、ログの生成元となるソフトウェアの情報(ソフトウェア名、バージョン、ソースコードのＵＲＬ、行番号など)を含んでも良い。メタデータは、例えば、デバッグの参考情報として利用できる。

【0032】

構成情報１６は、ソフトウェア識別部４におけるソフトウェアの識別に利用するためのデータで、例えば、ログを生成するソフトウェアの依存関係管理ファイルや構成ファイルを含む(図４Ａ、４Ｂにて詳述)。

【0033】

未加工ログ１４、正規化ログ１５、構成情報１６のデータは、文字列やファイル、エンコードされたバイナリデータ、データストリームの形式を含む。

【0034】

ここで、パターン探索を効率化するため、パターン情報７は、テーブル以外にインデックスのデータを有しても良い。当該インデックスを本実施の形態では全体インデックスと呼称する。インデックスの構成は、パターンの探索方式により異なり、例えば、パターンごとのＴＦ－ＩＤＦ値を加えたテーブルや、パターンの構造に基づく順序木や、単純にパターン情報７の優先度６５の昇順でパターンを並べたテーブルの形態を取って良い。パターンの構造に基づく順序木とは、より包含的なパターンが親となるよう調整した木構造で、例えば、パターンA「.*%{WORD:user}.*」、B「.*%{WORD:user} log in.*」、C「.*%{WORD:user} log out.*」D「.*admin %{WORD:user} log in.*」があったとき、Aが親、B・CがAの子、DがBの子とするような構造を取る。また、兄弟ノードの並びとしては、図５で示される優先度６５が小さい（優先度が高い）パターンほど先に探索されるよう配置する。

【0035】

図２は、ログ正規化装置１のハードウェア構成の一例を示すブロック図である。このハードウェア構成は、物理的な計算機であっても良いし、仮想サーバと呼ばれる物理的な計算機を論理的に分割された計算機の単位で動作していてもよい。もしくは１台の計算機または複数の計算機クラスタ上で実行されるタスク(プロセスやコンテナとも呼ばれる)であってもよい。

【0036】

電子計算機２０は、ＣＰＵ（Central Processing Uint）等のプロセッサ２１、通信制御装置２２、通信インターフェース２３、主記憶装置２４および補助記憶装置２５を備える。プロセッサ２１、通信制御装置２２、通信インターフェース２３、主記憶装置２４および補助記憶装置２５は、内部バス２６により相互に接続されている。

【0037】

プロセッサ２１は、動作制御を司るハードウェアである。主記憶装置２４は、各種プログラムやデータを保持する記憶装置であり、例えば、半導体メモリが用いられる。

【0038】

補助記憶装置２５は、大容量の記憶容量を有する記憶装置であり、例えば、ハードディスク装置やＳＳＤ（Solid State Drive）である。補助記憶装置２０５は、各種プログラムの実行ファイルを保持する。補助記憶装置２５は、プロセッサ２０１からアクセス可能である。

【0039】

通信制御装置２２は、通信を制御する機能を有するハードウェアであり、図１において外部とログ正規化装置１とのデータの交換に使用される。通信制御装置２２は、通信インターフェース２３を介してネットワーク２７に接続される。

【0040】

図３は、ログ正規化装置１の入出力部５が有するＧＵＩ機能が提供するＧＵＩ画面である入力画面３０の一例である。当該画面を用いることで、ユーザは、パターン情報７、ソフトウェア情報８、履歴情報９のデータを確認、追加、削除、更新できる。

【0041】

入力画面３０には、パターン情報７、ソフトウェア情報８、履歴情報９、および不図示のその他の各種情報を格納したテーブルに新規データを追加するための追加ボタン(３７、３９)、既存データを削除するための削除ボタン(３８、４０、４１)が含まれる。

【0042】

入出力部５は、パターン情報入力部３１に、パターン情報７のデータを表示する。入出力部５は、操作者から、マウスやキーボード等の入力装置を用いた操作を受け付けて、パターン情報入力部３１のうちの任意のセル３５または行３４を選択３６可能とする。入出力部５は、選択されたセル３５の値を、キーボード等による文字や数字の入力を受け付けて更新できる。

【0043】

また、入出力部５は、行３４を選択した状態で削除ボタン３８の押下を受け付けることにより、選択された行３４を削除できる。入出力部５は、操作者から追加ボタン３７の押下を受け付けると、パターン情報入力部３１に新規の行を作成する。入出力部５は、操作者から新規に追加された行に対するデータの入力を受け付けることにより、パターン情報７に新規のレコードを追加できる。ただし、追加された行のＩＤは一意の値でない場合、入出力部５は、エラーを表示し、登録処理をスキップする。パターン情報入力部３１にて追加、削除、更新されたデータは、パターン情報１１３に反映される。

【0044】

入出力部５は、ソフトウェア情報入力部３２に、ソフトウェア情報８のデータを表示する。パターン情報入力部３１と同じように、入出力部５は、ソフトウェア情報入力部３２に対して、追加ボタン３９や削除ボタン４０、またセルの編集などの操作を受け付けることにより、ソフトウェア情報８のデータを追加、削除、更新できる。入出力部５は、同様に履歴情報入力部３３に、履歴情報９のデータを表示し、削除ボタン４１やセルの編集などの操作を受け付けることにより、履歴情報９のデータを削除または更新できる。

【0045】

図４Ａ、４Ｂは、構成情報１６の一例である。図４Ａ、４Ｂを用いて、構成情報１６の形式およびソフトウェア識別部４における構成情報１６を用いたソフトウェア情報８の生成方法を示す。

【0046】

構成情報１６は、ソフトウェア識別部４におけるソフトウェアの識別に利用するためのデータであり、例えば、ログを生成するソフトウェアの依存関係管理ファイルや構成ファイルを含む。図４Ａでは、構成ファイルの例として、(a)コンテナオーケストレータのKubernetes(登録商標)にて使用されるマニフェストの一例を示している。また、依存管理ファイルの例として、図４Ｂのように、(b)Node.jsで使用されるpackage.jsonの一例を示している。構成情報１６は、マニフェストやpackage.json以外に、例えば、docker-compose.ymlやDockerfile、go.mod、pom.xml、requirement.txt、build.gradleなども含む。

【0047】

構成情報１６は、ホスト情報５０およびソフトウェア情報５１を含む。ホスト情報５０には、ログの生成元となる計算機やプロセスを特定するための情報(ＩＰアドレス、ホスト名、コンテナ名、Ｐｏｄ名など)が含まれる。ソフトウェア情報５１には、ホスト情報５０にて示された対象が使用しているソフトウェアやライブラリの情報が含まれる。

【0048】

図４Ａの(a)Kubernetesマニフェストにおいて、ホスト情報５０としてはmetadata.name、ソフトウェア情報５１としてはspec.containers[*].imageが利用できる。図４Ｂの(b)package.jsonにおいて、ソフトウェア情報５１には、nameやdependenciesが利用できる。しかし、package.jsonにはホスト情報５０が含まれないため、構成情報１６としてpackage.jsonを用いる際は、別途追加情報としてＪＳＯＮ等の形式でホスト情報５０を付与する。

【0049】

ソフトウェア識別部４は、構成情報１６を入出力部５経由で受け付け、構成情報１６が入力されると、ファイル名やデータの構成から構成情報１６の形式を示すファイルタイプを特定し、その後、ファイルタイプごとに予め定められた処理でホスト情報５０およびソフトウェア情報５１を抽出・加工し、ソフトウェア情報８に登録する。加工とは、例えば、Kubernetesマニフェストの場合、ホスト情報４０１Ａのキー名をmetadata.nameからpodに変更して、ホスト情報４０１Ａと未加工ログ１２０のホスト情報とデータ形式を揃える処理が含まれる。また、spec.container[*].image(registry.access.redhat.com/rhscl/postgresql-10-rhel7:1)からコンテナイメージ名(postgresql-10-rhel7)を抽出し、ソフトウェア識別部４が予め備える辞書を用いてソフトウェア名とバージョン情報を正規化({"name":"postgres","version":10})する処理が含まれる。

【0050】

なお、ソフトウェア情報８に初期登録する際、図６にて後述するソフトウェア内優先度７２の値は空とする。その理由は、ソフトウェア内優先度７２の値は、入力画面３０における操作者の操作により追加される値のためである。

【0051】

図５は、パターン情報７のデータ構造の一例である。パターン情報１１３は未加工ログ１４を解析するための雛形(パターン)を保持しており、パターンマッチ部３で使用される。

【0052】

パターン情報７は、ＩＤ６０、パターン６１、ソフトウェア６２、バージョン６３、ソースコード提供元６４、及び優先度６５の各値を含む。

【0053】

ＩＤ６０は、各レコードの識別子であり、ログ正規化装置１内で一意の値を持つ。

【0054】

パターン６１は、ログを解析するための雛形となる文字列で、非構造ログからパラメータを抽出するために使用される。パターン６１は、例えば、正規表現やGrok(登録商標)パターンを用いて良い。

【0055】

ソフトウェア６２は、当該パターン６１のログを生成するソフトウェアの名前を表し、バージョン６３は、当該パターン６１のログを生成するソフトウェアのバージョンを表す。バージョン６３は、複数の値の列挙(例:1.0.0, 1.0.2)や範囲指定(例:1.0.0-2.3.5)をしても良い。

【0056】

ソースコード提供元６４は、当該ソフトウェア６２における当該ログの出力処理が実装されているソースコードの情報である。ソースコード提供元６４は、ファイル名や、インターネット上のリポジトリにてソースコードが公開されている場合はＵＲＬで示され、行番号の情報を含んでも良い。

【0057】

優先度６５は、当該パターン６１が他のパターンより優先される度合いを表す。優先度６５は、小さい値ほど優先されることを表し、例えば、ＧｉｔＨｕｂ（登録商標）における当該ソフトウェアのリポジトリが獲得したスター数の逆数などが利用できる。優先度は、パターンマッチング部３における探索順序に影響する。

【0058】

一つのソフトウェアに対して複数のログパターンがある場合は、各々のログパターンに優先度を設定できる。この例では、ソフトウェアpostgresにID1とID4のパターンがあり、その優先度は同じであることが指定されている。

【0059】

図６は、ソフトウェア情報８のデータ構造の一例である。ソフトウェア情報８は、各ホストで稼働しているソフトウェアの候補を保持しており、パターンマッチ部３におけるパターンの探索範囲の削減に利用される。

【0060】

ソフトウェア情報８は、ログ送信元７０、ソフトウェア候補７１、ソフトウェア内優先度７２の各値を含む。ログ送信元７０は、ログの送信元となる計算機やプロセスを表す情報であり、例えば、送信元ＩＰアドレスやホスト名、コンテナ名、KubernetesのＰｏｄ名、またはそれらの組み合わせで構成される。ログ送信元７０のデータ形式は、例えば、ＪＳＯＮ形式で表される。

【0061】

ソフトウェア候補７１は、当該ログ送信元７０にて稼働するソフトウェアやライブラリの情報を表し、当該ソフトウェアの名前のリストの情報を含む。また、ソフトウェアごとに名前とともに該当するバージョンの情報を含んでも良い。

【0062】

ソフトウェア内優先度７２は、当該ログ送信元７０ごとに、個別にパターン情報７の優先度６５をカスタマイズするための値であり、０個以上のＩＤと優先度の組で構成される。ＩＤは、パターン情報７のＩＤ６０を表し、優先度は、当該ＩＤに新規に設定する優先度を表す。ソフトウェア内優先度７２は、入力画面３０にて、入出力部５が、操作者からソフトウェア情報入力部３０における編集を受け付けることで設定できる。その他、入力画面３０にて、入出力部５が、操作者から履歴情報入力部３３における操作を受け付けて、履歴情報９の誤りを訂正した際に、変更前に登録されていたパターンの優先度６５より小さい値の優先度が変更後のパターンに設定されても良い。これにより、パターン探索の誤りの再現を防ぐことができる。

【0063】

この例では、ソフトウェア内優先度で[{id:1, priority:-1}]と指定されることにより、パターン情報のＩＤ１に登録されているパターンの優先順位を「－１」することが定められている。このため、ソフトウェアpostgresのパターンは、ＩＤ１よりＩＤ４が優先されることになる。

【0064】

図７は、履歴情報９のデータ構造の一例である。履歴情報９は、ログ正規化装置１にて正規化したログの情報を保持し、入力画面３０での内容確認の他、ソフトウェア識別部４におけるソフトウェア識別で用いられる。

【0065】

履歴情報９は、タイムスタンプ８０、ホスト８１、ログ８２、適用されたパターン８３の各値を含む。タイムスタンプ８０は、ログ正規化装置１が対象のログを正規化した時刻の情報であり、例えば、ISO8601形式の文字列やUnix Epochの数値で表現される。

【0066】

ホスト８１は、ソフトウェア情報８のログ送信元７０と同じ仕様で表現されたログの送信元となる計算機やプロセスを表す情報である。ログ８２は、ログ正規化装置１に入力された未加工ログ１４の文字列である。適用されたパターン８３は、当該ログ８２を正規化するために用いられたパターン情報７のＩＤ６０である。

【0067】

履歴情報９を用いて、ソフトウェア識別部４が識別処理を行うプロセスを、次の図８を用いて詳述する。

【0068】

図８は、ソフトウェア識別部４における履歴情報９を用いたソフトウェアの識別処理の一例である。本処理は、ログの解析で適用されたパターンの傾向から対象のホストで稼働しているソフトウェアを識別し、ソフトウェア情報８を更新するものである。なお、図８に図示された処理の１つ以上のプロセスは削除されてもよく、またはプロセスの順序が変更されてもよい。これは、以降の図９、図１０、図１１の処理プロセスでも同様である。

【0069】

ソフトウェア識別部４は、予め定められた一定のタイミングごとに各ホストについてＳ９１～Ｓ９４の処理を行う。このため、Ｓ９１からＳ９４は、特定のホスト１つに対する処理を指すが、他のホストについても同様である。

【0070】

ソフトウェアの識別処理を行うタイミングは、入出力部５がユーザ端末１３から受付けた値に基づくタイミングで、制御部２が識別処理結果をいつマッチング処理に反映するか制御することによりホストやアプリケーションシステムの追加に柔軟な対応が可能となる。もちろん、制御部２に替えて、他の各部が同様の制御を行ってもよい。

【0071】

まず、ソフトウェア識別部４は、履歴情報９から特定のホスト８１を持つレコードを取得する(Ｓ９１)。取得するレコードは、制限を設けても良い。制限には、例えば、個数(例えば、最新のレコード１０００個)や時間(例えば、過去１２時間)、またはその組み合わせが利用できる。これにより古いレコードがソフトウェアの識別精度を下げることを抑止できる。

【0072】

次に、ソフトウェア識別部４は、取得したレコードを、ソフトウェアおよびバージョンの組ごとに集計し、ソフトウェアおよびバージョンの組ごとのレコードの数をカウントする(Ｓ９２)。具体的には、ソフトウェア識別部４は、上記取得したレコードの適用されたパターン８３と同じ値のＩＤ６０に対応するパターン６１を持つレコードを、パターン情報７から取得する。ソフトウェア識別部４は、上記取得したレコードの集計において、取得したパターン情報７に含まれるパターン６１に対応するソフトウェアおよびバージョンの値について、ソフトウェアが同一、かつバージョンが内包関係にあるレコード群がある場合は、それらのレコード群を集約する。例えば、ソフトウェアがpostgresでバージョンが17.0.0のレコード群は、ソフトウェアがpostgresでバージョンが1.3.8-18.0.0の範囲であるレコード群に加えて良い。この処理により、ホスト８１ごとに、適用されたパターン８３に対応するソフトウェアおよびバージョンの組の数を集計できる。

【0073】

次に、ソフトウェア識別部４は、集計結果から当該ホストのソフトウェア候補を算出する(Ｓ９３)。ソフトウェア識別部４は、ソフトウェア候補として、例えば、Ｓ９２の集計結果にて一定の個数以上(例えば３０個以上)のレコードを持っていたり、レコードの集計数を降順で並べたときに一定以上の順序(例えば３位以上)となるソフトウェアおよびバージョンの組を選定する。ソフトウェア候補は複数存在しても良い。ソフトウェア識別部４は、該当がない場合、ソフトウェア候補はなしとする。この処理により、それぞれのホストについて、未加工ログを正規化する際に適用されたパターンに対応するソフトウェア候補を、過去の実績に基づいて得ることができる。

【0074】

最後に、ソフトウェア識別部４は、算出したソフトウェア候補をソフトウェア情報８に登録する（Ｓ９４）。具体的に、ソフトウェア識別部４は、ソフトウェア情報８に当該ホストとログ送信元７０が同値のレコードがある場合、当該レコードのソフトウェア候補７１に、算出したソフトウェア候補を更新(追加または上書き)する。一方、ソフトウェア識別部４は、該当するレコードがない場合、新規のレコードとして、ホストとソフトウェア候補を登録する。ソフトウェア識別部４は、このとき、ソフトウェア候補を、例えば、ＪＳＯＮ形式などのデータ形式で表現する。

【0075】

以上の処理により、ソフトウェア識別部４は、履歴情報９に基づき、ホストのソフトウェア候補を算出し、ソフトウェア情報８を更新する。

【0076】

図９は、パターンマッチ部３におけるパターンマッチ処理の一例である。本処理は、パターンマッチングを用いて、入力された未加工ログ１４を正規化ログ１５に変換するものである。

【0077】

パターンマッチ部３は、外部から未加工ログ１４を受け付け、一連の処理を開始する(Ｓ１０１)。パターンマッチ部３は、未加工ログ１４を、例えば、Ｗｅｂ ＡＰＩやファイルを通して受け付ける。ファイルやデータストリームなどとして未加工ログ１４が複数連続して入力された場合、パターンマッチ部３は、文字数や特定のセパレータ（例えば、改行記号）をもとに、未加工ログ１４を個々の単位に分解し、個々の未加工ログ１４について以降の処理を実施する。

【0078】

次に、パターンマッチ部３は、受け付けた未加工ログ１４からホスト情報を抽出する(Ｓ１０２)。

【0079】

次に、パターンマッチ部３は、未加工ログ１４の生成元ホストにて稼働しているソフトウェアの情報を基に、探索対象となるパターンを抽出する(Ｓ１０３)。但し、本処理(Ｓ１０３)および後続のインデックス作成(Ｓ１０４)は、パターンマッチ時以外に、ソフトウェア識別部４にてＳ９４でソフトウェア情報８を登録した際(例えばＳ９４の後)に実施しても良い。これら処理は、ソフトウェア識別部３にて実施した方が効率的であるが、発明の特徴をわかりやすく示すため、実施例１ではパターンマッチ部３が行う処理として記載している。

【0080】

具体的に、パターンマッチ部３は、Ｓ１０２で抽出したホスト情報とログ送信元７０が一致するレコードを、ソフトウェア情報８から取得し、そのソフトウェア候補７１を得る。その後、パターンマッチ部３は、パターン情報７から当該ソフトウェア候補７１の値とソフトウェア６２およびバージョン６３が一致するレコードを抽出する。図８において説明したように、ソフトウェア情報８は、履歴情報９に基づいて更新される。したがって、本処理を行うことで、過去の実績に基づく最新のソフトウェア情報８から得られたソフトウェア候補７１に対応するソフトウェア６２およびバージョン６３を得ることができる。Ｓ１０３では、ソフトウェア６２およびバージョン６３が一致する１または複数のパターン６１が抽出され、後述するＳ１０５の処理で、その中から当該未入力ログ１４に該当するパターンが探索される。

【0081】

但し、バージョン６３の一致とは、当該ソフトウェア候補７１のバージョンの値がバージョン６３内の範囲や列挙の中に含まれた場合も含む。また、パターンマッチ部３は、完全に一致するソフトウェア６２がない場合、例えば、ソフトウェア候補中のソフトウェア名とソフトウェア６２の文字列の類似度を、レーベンシュタイン距離などで判定し、距離が一定以下のソフトウェア６２を一致したソフトウェアとして判定しても良い。

【0082】

次に、パターンマッチ部３は、抽出したパターンを効率的に探索するためのインデックスを作成する(Ｓ１０４)。本処理で作成したインデックスを個別インデックスと呼称する。個別インデックスの構造および作成方法は、図１で示した全体インデックスと同一である。

【0083】

次に、パターンマッチ部３は、インデックスを用いて当該未入力ログ１４に該当するパターンを探索する（Ｓ１０５）。パターンの探索では、パターンマッチ部３は、最初に個別インデックスを探索し、該当するパターンがない場合は全体インデックスを探索する。探索方法は、インデックスの形式に基づく。インデックスがＴＦ－ＩＤＦで構成されている場合、パターンマッチ部３は、当該未入力ログ１４のＴＦ－ＩＤＦ値と差分が一定以下のパターンを抽出し、当該未入力ログ１４を表現できるパターンを優先度６５の昇順で評価する。インデックスが順序木の場合、パターンマッチ部３は、パターンが当該未入力ログ１４を表現できるか否かについて、根からの深さを優先した探索で評価していき、子や兄弟ノードが存在しない、もしくは当該未入力ログ１４を表現できないノードを探索する。優先度の昇順にソートされたテーブルの場合、パターンマッチ部３は、上から当該未入力ログ１４を表現できるか評価していく。該当するパターンが発見できない場合、パターンマッチ部３はエラーを返し、後続の処理はスキップされる。

【0084】

次に、パターンマッチ部３は、Ｓ１０５にて発見したパターンの正規表現やGrokパターンをもとに当該未加工ログ１４からパラメータを抽出し、ＪＳＯＮなどのデータ構造に変換する(Ｓ１０６)。このとき、パターンマッチ部３は、メタデータを追加パラメータとしてＪＳＯＮに追加しても良い。メタデータには、例えば、当該未加工ログ１４の原文、ホスト情報、処理時刻、ログ生成元と判定したソフトウェアの名前、当該ソフトウェアのバージョン、ログ生成元のソースコード等が含まれる。

【0085】

次に、パターンマッチ部３は、Ｓ１０６で変換したログを正規化ログ１５として出力すると共に履歴情報９に結果を登録する。パターンマッチ部３は、履歴情報９に、処理時刻をタイムスタンプ８０、当該未送信ログ１４に含まれるホスト情報をホスト８１、同ログの原文をログ８２、ログを加工したパターンのＩＤを適用パターン８３として登録する（Ｓ１０７）。

【0086】

以上の処理により、パターンマッチ部３は、未加工ログ１４を正規化ログ１５に変換できる。

【0087】

次に、図１０を用いて、Ｓ１０５のパターンマッチ処理を説明する。図１０は、本実施例におけるパターンマッチ処理を説明するフローチャートの例である。

【0088】

以下では、パターンマッチ部３が、パターンマッチを行う未加工ログを、ログ送信元で稼働しているプログラムの情報であるソフトウェア情報を用いてマッチングを行う。ソフトウェア情報８にはソフトウェア内優先度７２が格納されており、パターン情報７に格納されているどのパターンがログ送信元で稼働しているプログラムに関連したパターンであるかが、パターン情報７のＩＤ６０にリンクが張られて指定されている。また、リンクが張られたパターンの中における優先順位が、ソフトウェア内優先度７２として指定されている。

【0089】

パターンマッチ部３は、Ｓ１０３で抽出されたパターン情報７のパターン６１のうち、リンクを張られているパターンを、ソフトウェア情報８のソフトウェア内優先度７２で指定された順番でパターンマッチする（Ｓ１１１）。これにより、未加工ログに適用すべきパターンを短時間で適切に見つけることができる。

【0090】

パターンマッチ部３は、ソフトウェア情報８とパターン情報７を用いたマッチングでパターンがみつかったか否かを判定し（Ｓ１１２）、パターンが見つかったと判定した場合は（Ｓ１１２；Ｙｅｓ）、処理を終了させる。一方、パターンマッチ部３は、パターンが見つからなかったと判定した場合は（Ｓ１１２；Ｎｏ）、パターン情報７の優先度６５の優先順位でパターンマッチを行う（Ｓ１１３）。続いて、パターンマッチ部３は、パターン情報７を用いたパターンマッチでパターンが見つかったか否かを判定し（Ｓ１１５）、パターンが見つかったと判定した場合は（Ｓ１１５；Ｙｅｓ）、処理を終了させる。一方、パターンマッチ部３は、パターンが見つからなかったと判定した場合は（Ｓ１１５；Ｎｏ）、エラーを出力する（Ｓ１１６）。

【0091】

本実施例では、インデックス作成時においてパターンマッチングを行う順序を制御する例を説明しているが、制御部２がパターンマッチングに用いる優先順位が格納されたファイルの使用順序を変更するようにしても良い。

【実施例0092】

実施例２では、ソースコード情報１７からパターン情報７を生成する。これにより、利用者は、ログごとにパターン情報７を作成せずとも、ソフトウェアのソースコードからログのパターンを生成できるようになる。図１のシステム構成図を用いて実施例２を説明する。実施例１に加えてパターン生成部６、およびソースコード情報１７が必要となるが、これら以外のコンポーネントは図１と同様のため説明を省略する。

【0093】

パターン生成部６は、ソースコード情報１７を基にパターン情報７を生成する処理を行う。

【0094】

ソースコード情報１７は、ソフトウェアやライブラリのソースコードおよびメタデータを組み合わせたデータである。ソースコードは、ソフトウェアのプログラムを表す文字列であり、ソフトウェアのGit(登録商標)のリポジトリ等に含まれるファイル全ての情報、もしくはその一部などの場合がある。メタデータは、ソフトウェアの名称や優先度を示す情報であり、例えば、ソフトウェア名、バージョン、ソースコード取得元、優先度などの情報が含まれる。メタデータは、パターン生成部６にてソースコードから生成される場合もある。

【0095】

ソースコード情報のデータは、文字列やファイル、エンコードされたバイナリデータ、データストリームの形式を含み、例えば、Ｗｅｂ ＡＰＩやファイルとして外部から入力される。

【0096】

図１１は、パターン生成部６におけるパターン生成処理の一例である。パターン生成部６は、ソースコード情報１７からパターン情報７を生成する。

【0097】

パターン生成部６は、外部から入出力部５経由でソースコード情報１７を受け付け、一連の処理を開始する(Ｓ１２１)。

【0098】

パターン生成部６は、ソースコード情報１７を受け付けると、当該ソースコード情報１７のメタデータに、ソフトウェア名、バージョン、ソースコード取得元、優先度が含まれるか確認する。これらの情報が含まれていないデータがある場合、パターン生成部６は、ソースコードからのメタデータ生成を試みる。

【0099】

パターン生成部６は、ソフトウェア名として、ソースコードのリポジトリ名やソースコード内の構成ファイル(package.json、go.mod、setup.py等)、READMEファイル内のタイトル（例えばHTMLのH1タグ）から取得する。パターン生成部６は、ソフトウェア名を構成ファイルから取得する場合、構成ファイルごとに予め定められた処理でソフトウェア名を特定する。例えば、構成ファイルがpackage.jsonの場合、パターン生成部６は、nameパラメータをソフトウェア名とする。このとき、パターン生成部６は、ソフトウェア名に対して、英語の小文字化やスペースをアンダースコアに置き換えるなどの前処理をしても良い。

【0100】

パターン生成部６は、バージョンおよびソースコード取得元も、ソフトウェア名と同じくソースコード内の構成ファイルから、構成ファイルごとに予め定められた処理で取得する。例えば、構成ファイルがpackage.jsonの場合、パターン生成部６は、versionパラメータをバージョンとし、homepageパラメータをソフトウェア取得元とする。

【0101】

また、ソフトウェア取得元が、ＧｉｔＨｕｂやＧｉｔＬａｂ(登録商標)、ＮＰＭ(登録商標)などの評価機能(スター数、Weekly Downloadsなど)を持つリポジトリの場合、パターン生成部６は、ソフトウェア取得元のＵＲＬにアクセスし、ソフトウェア取得元ごとに定められた方法で当該ソースコードの評価値を取得し、優先度にできる。例えば、ソフトウェア取得元がＧｉｔＨｕｂの場合、パターン生成部６は、スター数の逆数を優先度として良い。優先度の値は、リポジトリの種別ごとに範囲を正規化しても良い。

【0102】

ソフトウェア名がメタデータに含まれず、また、ソフトウェアからも生成できない場合、パターン生成部６は、エラーを返し、以降の処理をスキップする。バージョン６３およびソースコード取得元６４が取得できない場合、パターン生成部６は、これらを空欄とする。パターン生成部６は、優先度６５が取得できない場合は、デフォルト値として１を設定する。

【0103】

次に、パターン生成部６は、ソースコードからログメッセージを抽出する(Ｓ１２３)。ログメッセージは、ログとして出力される文書を表すデータで、文字列、変数、関数、クラス、アトリビュート、またはそれらの組み合わせで構成される。パターン生成部６は、プログラミング言語ごとに予め定められた構文解析、意味解析等の処理でログメッセージを特定し、そのデータおよび行番号を取得する。例えば、JavaScriptの場合、パターン生成部６は、console.log関数やLog4jsなどのロギングライブラリの関数(debug関数など)の引数をログメッセージとして取得できる。

【0104】

また、ログメッセージが変数や関数、クラス、アトリビュートなどで実装されている場合、パターン生成部６は、例えば、ソースコードの抽象構文木を用いてログを出力する関数に紐づいている変数や関数、クラス、アトリビュートを特定して、その値や引数をログメッセージとして取得しても良い。更に、一度に出力させるログメッセージの定形文字列が複数に分割されている場合、パターン生成部６は、それらを一つに合成した上でログメッセージとして取得しても良い。上記定型文字列は、例えば、ソースコードのみから静的に確定できる文字列であり、変数など動的に決定するデータは含まない文字列である。ソースコードからログメッセージが複数取得された場合、パターン生成部６は、以降の処理をログメッセージごとに行う。

【0105】

次に、パターン生成部６は、ログメッセージからパラメータを抽出し、そのパラメータ名とデータ型を割り当てる(Ｓ１２４)。パラメータは、userやsource_ipなど、構造化ログにおいてログメッセージから抽出される値である。パターン生成部６は、ソースコード情報１７を、ログメッセージ内に埋め込まれている動的に決定される変数または関数をパラメータとして抽出する。このとき、パターン生成部６は、構文抽出木を用いて、抽出した各パラメータのデータを識別し、当該パラメータが複数のデータ(例えば、送信元ＩＰアドレスと送信元ポート番号)を持つ場合、構文抽出木を辿って当該パラメータをデータごとに複数のパラメータへと分割して良い。

【0106】

パターン生成部６は、パラメータ名を、変数や関数の名前から取得する。このとき、パターン生成部６は、パラメータ名を正規化するため、予め定められたパラメータ名の候補の中から、変数や関数の名前またはログメッセージの文意に応じて適したパラメータ名を選定しても良い。パターン生成部６は、例えば、Word2Vec、BERTなどを用いて文字ベクトルや概念辞書における距離を用いて、各パラメータ候補と、変数や関数、またはログメッセージの文意を比較し、パラメータ候補のうち最も意味が近いパラメータを選定するなどの処理を用いることができる。

【0107】

パターン生成部６は、パラメータのデータ型を、変数の変数型や関数の返り値のデータ型から判断する。データ型には、例えば、文字、数値、真偽値、バイナリ、などのプリミティブな値のほか、例えば、Grokパターンとして定義されたデータ型を利用できる。変数型を持たないプログラミング言語の場合や、変数が独自に定義されたデータ型である場合は、パターン生成部６は、構文抽出木を用いて紐づいているデータ型を特定し、パラメータのデータ型として識別して良い。

【0108】

最後に、パターン生成部６は、抽出した当該ログメッセージおよび当該パラメータからパターンを生成し、当該メタデータと共にパターン情報７に登録する（Ｓ１２５）。パターン生成部６は、上記パターンを、ログメッセージ内のパラメータを正規表現やGrokパターン等に置き換えることで生成できる。このとき、パターン生成部６は、生成した当該パターンに、マッチング精度を向上させるための後処理を加えても良い。後処理では、例えば、パターンの先頭に正規表現の「.*」を加えることにより、ソフトウェアの外部でログメッセージにプレフィックスが追加された場合であっても、マッチング可能として取り扱うことができる。

【0109】

パターン情報７への登録は、パターン生成部６が、当該パターンをパターン６１に、メタデータのソフトウェア名、バージョン、ソースコード、優先度を，それぞれソフトウェア５０２、バージョン５０３、ソースコード５０４、優先度５０５とする。そのうえで、し、ログ正規化装置１にて一意のＩＤ６０を付与してパターン情報７のレコードを生成する。

【0110】

以上の処理および情報を用いて、ログ正規化装置１は、ソースコード情報１７からパターン情報７を生成できる。これにより、利用者は、ログごとにパターン情報７を作成せずとも良いという効果を得られる。

【0111】

このように、本実施の形態によれば、情報処理システムから出力されるログを構造化されたログに正規化するログ正規化装置１において、情報処理システムから出力されるログを受け取るログ入力部（パターンマッチ部３）、複数のログのパターンであるパターン情報７と、ログ送信元に対応するパターンマッチの第一の優先度を示す第一の優先度情報（ソフトウェア情報８のソフトウェア内優先度７２）を格納する記憶部（補助記憶装置２５）と、受け取ったログが第一の優先度情報に対応するログ送信元のとき、ログとパターン情報７のパターンとのパターンマッチを第一の優先度に対応するパターンを用いて行い、マッチしたパターンを用いて正規化ログに変換する上記パターンマッチ部３と、当該パターンマッチ部３で変換された正規化ログを出力するログ出力部（パターンマッチ部３）と、を備える。これにより、ログに適合するパターンを探索するときの探索に関する精度と処理速度が向上できる。

【0112】

また、上記パターン情報のパターンにパターンマッチの優先度を示す第二の優先度（パターン情報７の優先度６５）を含み、上記パターンマッチ部は、第一の優先度に基づいたパターンマッチでマッチしなかったとき、第二の優先度を用いてパターンマッチを行う。これにより、第一の優先度に基づいたパターンマッチでマッチしなかった場合でも、第二の優先度を用いてパターンマッチすることができる。

【0113】

また、上記第一の優先度は、ログ送信元で稼働するソフトウェアに基づいて定められた優先順位であってよい。このように規定することで、ログを出力するソフトウェアの種類に応じて、あるいは同じソフトウェアであってもバージョンの種類に応じて、適用すべきパターンの優先順位を定めることができる。

【0114】

また、上記第一の優先度は、上記パターン情報に含まれる上記パターン情報に対応付けられた上記第二の優先度を変更する指示を含んでよい。このように規定することで、パターン情報７の優先度６５を個別にカスタマイズすることができる。

【0115】

また、上記第一の優先度は、ソフトウェア取得元で稼働するソフトウェアの評価に基づいて定められた優先順位であってよい。このように規定することで、ソフトウェア取得元ごとに定められた方法で当該ソースコードの評価を反映した優先度を定めることができる。

【0116】

また、上記第二の優先度の更新情報を受付け、受け付けた更新情報を用いて上記パターン情報に含まれる上記第二の優先度を変更する入出力部５を備える。これにより、優先度をユーザが意図した値に変更することができる。

【0117】

また、ログ送信元で稼働するソフトウェアのソースコードを受け付け、ソースコードに含まれるパラメータを基にパターンを作成し、作成したパターンを上記パターン情報へ登録する。これにより、ユーザは、ログごとにパターン情報７を作成する必要をなくすことができる。

【0118】

また、上記受付けたソースコードの意味解析を行い、ソースコードに含まれる変数、関数の位置および名前からログメッセージを出力し、出力したログメッセージからパラメータを抽出し、出力したログメッセージと抽出したパラメータとに基づいて、パターン情報７のパターンを生成する。これにより、意味解析して得られた情報を用いて、出力されるログメッセージに含まれるパラメータの位置と役割を推定し、パターンを作成したり、当該パターンに含まれるパラメータを求めることができる。

【0119】

以上、図面を用いて詳細に説明したが、本発明は上述の種々の例に限定されるものではなく、その趣旨を逸脱しない範囲で、種々の変更が可能である。