JP2015215770A - ログ収集システム - Google Patents

Abstract

【課題】リアルタイム性が要求されるログの収集に遅延が生じないログ収集システムを提供する。【解決手段】ログ収集システムは、クライアント２０からのログをサーバ１０で収集するログ収集システムであって、クライアント２０は、収集タイミングのリアルタイム性の観点から付与された優先度に基づいてサーバ１０に送信するログについてサーバ送信間隔制御を行い、サーバ１０は、サーバリソース状況に応じ、優先度に基づいてクライアント２０から受信するログについて受信抑制制御を行う。【選択図】図２

Description

本発明は、クライアントからのログをサーバで収集するログ収集システムに関する。

近年、ＳＴＢ（Set Top Box）やＨＧＷ（Home Gateway）、タブレットなど、宅内情報端末が多様化している。このように多様化する宅内情報端末の「保守運用の高度化」や「付加価値サービスの提供」を実現するためには、端末情報（以下「ログ」という。）をサーバで収集・管理する必要があり、サーバの負荷制御が必要となる（特許文献１、２参照）。サーバの負荷制御方式としては、以下のサーバ側負荷制御方式とクライアント側負荷制御方式がある。

サーバ側負荷制御方式は、サーバ側で各端末宛に負荷軽減制御を実施する集中制御方式である。各端末は全てのログをイベントドリブンでサーバに送信する。サーバ負荷の閾値超過時には、サーバが各端末に対してサーバの負荷低減制御を実施する。

クライアント側負荷制御方式は、端末側で個別に負荷分散制御を実施する個別制御方式である。各端末は、起動後や情報取得後にランダムな時間を設けてログをサーバに送信することでサーバの負荷分散を行う。

特開２００３−１８６６８５号公報 特開２０１３−３７６５６号公報

しかし、宅内情報端末の将来的な利用拡大を想定すると、ログ収集のための大量通信によるサーバリソースの枯渇が懸念される。その場合、リアルタイム性が要求されるログの収集に遅延が生じる可能性がある。すなわち、サーバ側負荷制御方式によれば、クライアント側でサーバリソース状況に応じたログ送信抑制制御ができない。そのため、サーバ側で抑制される可能性のあるログも含めた全てのログについてサーバ負荷平常時と同じタイミングでログ送信要求をする結果、無駄なサーバトラフィックが発生し、負荷収束も遅れる。一方、クライアント側負荷制御方式によれば、ログ送信間隔を短くするとサーバ負荷が高まり、ログ送信間隔を長くするとリアルタイムなログ収集ができない。

本発明は、上述した従来の技術に鑑み、リアルタイム性が要求されるログの収集に遅延が生じないログ収集システムを提供することを目的とする。

上記目的を達成するため、第１の態様に係る発明は、クライアントからのログをサーバで収集するログ収集システムであって、前記クライアントは、収集タイミングのリアルタイム性の観点から付与された優先度に基づいて前記サーバに送信するログについてサーバ送信間隔制御を行い、前記サーバは、サーバリソース状況に応じ、前記優先度に基づいて前記クライアントから受信するログについて受信抑制制御を行うことを要旨とする。

第２の態様に係る発明は、第１の態様に係る発明において、前記クライアントが、サーバリソース状況に応じ、ログ送信を待機させる待機時間を前記優先度に基づいて動的に変更することを要旨とする。

第３の態様に係る発明は、第２の態様に係る発明において、前記クライアントが、前記サーバで受信抑制されたログの優先度より低い全てのログについてサーバ送信タイミングを遅らせるとともに、前記サーバで受信完了したログの優先度より高い全てのログについてサーバリソース平常時のサーバ送信タイミングに戻すことを要旨とする。

本発明によれば、リアルタイム性が要求されるログの収集に遅延が生じないログ収集システムを提供することが可能である。

本発明の実施の形態におけるログ収集システムの構成図である。 本発明の実施の形態におけるログ収集システムの機能ブロック図である。 本発明の実施の形態におけるクライアントログＤＢの構成図である。 本発明の実施の形態における優先度別ログ送信タイミングＤＢの構成図である。 本発明の実施の形態におけるクライアントログ収集ＤＢの構成図である。 本発明の実施の形態における負荷判定部の詳細な説明図であって、（ａ）負荷判定部の処理手順、（ｂ）優先度の一例、（ｃ）優先度別の受信可否判定規準。 本発明の実施の形態における送信タイミング変更部の詳細な説明図である。 本発明の実施の形態における送信タイミング変更部の詳細な説明図である。 本発明の実施の形態におけるログ送信部の詳細な説明図であって、（ａ）「受信可」通知を受信した後の状態、（ｂ）ログを送信した後の状態、（ｃ）ログを削除した後の状態。 本発明の実施の形態におけるログ収集システムのフローチャートである。 従来技術と比較するための図であって、（ａ）サーバ側負荷制御方式、（ｂ）ハイブリッド型負荷制御方式。 従来技術と比較するための図であって、（ａ）クライアント側負荷制御方式、（ｂ）ハイブリッド型負荷制御方式。

以下、本発明の実施の形態について図面を参照して詳細に説明する。なお、以下の実施の形態は、この発明の技術的思想を具体化するためのログ収集システムを例示するものであり、装置の構成やデータベースの構成などは、以下の実施の形態に限定されるものではない。

（システム構成）
図１は、本発明の実施の形態におけるログ収集システムの構成図である。このログ収集システムは、図１に示すように、複数のクライアント２０Ａ，２０Ｂ，…，２０Ｘからのログをサーバ１０側で収集するシステムである。クライアント２０Ａ，２０Ｂ，…，２０Ｘは、例えば、ＳＴＢやＨＧＷ、タブレットなどの宅内情報端末である。以下、複数のクライアント２０Ａ，２０Ｂ，…，２０Ｘを一括して「クライアント２０」又は単に「端末」という。

ログは、クライアント２０の端末情報である。例えば、ＩＤやアドレスなどの端末固有情報、ＣＰＵ状態やメモリ状態などの端末状態情報、アプリ利用履歴やＡＰインストール状況などのサービス利用状況がログに該当する。もちろん、本発明でいうログはこれらに限定されるものではない。クライアント２０からサーバ１０に送信してサーバ１０側で収集することが必要な情報である以上、本発明でいうログに含まれる。

図２は、本発明の実施の形態におけるログ収集システムの機能ブロック図である。このログ収集システムでは、収集タイミングのリアルタイム性の観点から各ログに優先度を付与しておき、サーバ１０側・クライアント２０側の負荷制御を組み合わせ、各々にサーバリソース状況や収集するログの優先度に応じた負荷制御を行う（ハイブリッド型負荷制御）。

すなわち、サーバ１０は、負荷判定部１１と、クライアントログ収集ＤＢ１２と、ログ受信部１３とを備える。負荷判定部１１は、クライアント２０から通知を受け取った優先度についてログの受信可否をサーバ１０の負荷状況を基に判定し、クライアント２０に受信可否結果を通知する。クライアントログ収集ＤＢ１２は、クライアント２０から収集したログを管理するデータベースである。ログ受信部１３は、各クライアント２０からログを受信してクライアントログ収集ＤＢ１２に格納する。

また、クライアント２０は、送信タイミング制御部２１と、送信タイミング変更部２２と、ログ送信部２３と、優先度別ログ送信タイミングＤＢ２４と、クライアントログＤＢ２５と、ログ集約部２６とを備える。送信タイミング制御部２１は、各優先度のログ送信タイミングを判断し、送信タイミングとなった優先度のログが現在サーバ１０側で受信可能か確認を行う。送信タイミング変更部２２は、サーバ１０側からの受信可否結果を基に次回の送信タイミングを変更する。ログ送信部２３は、サーバ１０側から「受信可」通知を受信した優先度のログをサーバ１０に送信し、送信済みのログを削除する。優先度別ログ送信タイミングＤＢ２４は、優先度別にログの送信タイミングを管理するデータベースである。クライアントログＤＢ２５は、クライアント２０で発生するログを管理するデータベースである。ログ集約部２６は、クライアント２０で発生するログを集約してクライアントログＤＢ２５に格納する。

（データベース構成）
図３は、本発明の実施の形態におけるクライアントログＤＢ２５の構成図である。このクライアントログＤＢ２５は、ログＩＤ、ログ発生時間、ログ種別ＩＤ、優先度、ログ内容、送信ＩＤ、送信時間などのフィールドを備える。ログＩＤは、ログを識別するための情報である。ログ発生時間は、ログが発生した時刻情報である。ログ種別ＩＤは、ログ種別を識別するための情報である。優先度は、収集タイミングのリアルタイム性の観点から付与される。リアルタイム性を求められるログほど優先度が高く、リアルタイム性を求められないログほど優先度が低い。例えば、リアルタイム性を求められるログとは、アプリ利用履歴などのサービス利用状況であり、リアルタイム性を求められないログとは、端末ＩＤやアドレスなどの端末固有情報や、ＣＰＵ状態やメモリ状態などの端末状態情報である。ここでは、優先度のランクとしてＡ，Ｂ，Ｃ，Ｄ，…を例示し、Ａ，Ｂ，Ｃ，Ｄ，…の順に優先度が高いものとする。ログ内容は、アプリ利用履歴や端末ＩＤなどの値である。送信ＩＤとは、サーバ１０にログ送信された順に付与されたＩＤである。送信時間は、サーバ１０にログ送信された時刻情報である。

図４は、本発明の実施の形態における優先度別ログ送信タイミングＤＢ２４の構成図である。この優先度別ログ送信タイミングＤＢ２４は、優先度、平常時送信周期、高負荷時待機時間などのフィールドを備える。平常時送信周期は、サーバ１０の負荷が平常時におけるログ送信の周期（秒）であり、優先度が低いほど長い送信周期が設定される。高負荷時待機時間は、サーバ１０が高負荷状態の場合にログ送信を待機させる時間（秒）であり、優先度が低いほど長い待機時間が設定される。この高負荷時待機時間は、送信タイミング変更部２２により算出され、サーバリソース状況に応じて動的に変更されるようになっている。

図５は、本発明の実施の形態におけるクライアントログ収集ＤＢ１２の構成図である。このクライアントログ収集ＤＢ１２は、クライアントＩＤ、ログＩＤ、ログ発生時間、ログ種別ＩＤ、優先度、ログ内容などのフィールドを備える。クライアントＩＤは、クライアント２０を識別するための情報である。その他のフィールドについては既に説明した通りである。

（送信タイミング制御部２１の詳細）
以下、送信タイミング制御部２１を更に詳しく説明する。なお、以下の説明は、図４に示される情報が優先度別ログ送信タイミングＤＢ２４に格納されている場合を想定している。

まず、送信タイミング制御部２１は、端末起動時より各優先度について送信タイミングの制御を開始する。すなわち、停電からの復旧などで各端末が一度に電源ＯＮになって送信タイミングの基点が重なってしまうことを避けるため、端末毎に算出した乱数などを起動時間に追加した時間を初回の送信基点とする。例えば、クライアント２０Ａの起動時間が「１０：００：００」である場合においてクライアント２０Ａの起動時算出乱数が「５」であるとき、クライアント２０Ａの初回の送信基点は、「１０：００：００」＋「５」で「１０：００：０５」となる。また、クライアント２０Ｂの起動時間が「１０：００：００」である場合においてクライアント２０Ｂの起動時算出乱数が「１０」であるとき、クライアント２０Ｂの初回の送信基点は、「１０：００：００」＋「１０」で「１０：００：１０」となる。

次に、送信タイミング制御部２１は、負荷平常時送信タイミングとなった優先度について、サーバ１０側で抑制制御中である可能性を確認する。負荷平常時送信タイミングは、「送信基点」＋「平常時送信周期」で決まる。例えば、初回の送信基点が「１０：００：０５」である場合、優先度Ａについての負荷平常時送信タイミングは、送信基点＋１秒（平常時送信周期）で「１０：００：０６」となる。また、優先度Ｂについての負荷平常時送信タイミングは、送信基点＋１００秒（平常時送信周期）で「１０：０１：４５」となる。また、優先度Ｃについての負荷平常時送信タイミングは、送信基点＋５００秒（平常時送信周期）で「１０：０８：２５」となる。また、優先度Ｄについての負荷平常時送信タイミングは、送信基点＋１０００秒（平常時送信周期）で「１０：１６：４５」となる。

ここで、送信タイミング制御部２１は、該当優先度についてサーバ１０側で抑制制御中の可能性が低ければ、該当優先度についての受信可否判定をサーバ１０に即座に依頼する。例えば、該当優先度が優先度Ａである場合は「高負荷時待機時間＝０」であるため、サーバ１０側で抑制制御中の可能性が低い。そのため、優先度Ａについての受信可否判定をサーバ１０に即座に依頼し、このようにサーバ１０に受信可否判定を依頼した時刻を次回の送信基点とする。

一方、送信タイミング制御部２１は、該当優先度についてサーバ１０側で抑制制御中の可能性が高ければ、高負荷時待機時間が経過した後、該当優先度についての受信可否判定をサーバ１０に依頼する。例えば、該当優先度が優先度Ｂである場合は「高負荷時待機時間＞０」であるため、サーバ１０側で抑制制御中の可能性が高い。そのため、高負荷時待機時間である２０秒が経過した後、優先度Ｂについての受信可否判定をサーバ１０に依頼し、このようにサーバ１０に受信可否判定を依頼した時刻を次回の送信基点とする。

初回の送信基点が「１０：００：０５」である場合、次回の送信基点の算出方法は次の通りである。すなわち、優先度Ａについての次回の送信基点は、送信基点＋１秒（平常時送信周期）で「１０：００：０６」となる。また、優先度Ｂについての次回の送信基点は、送信基点＋１２０秒（平常時送信周期＋高負荷時待機時間）で「１０：０２：０５」となる。また、優先度Ｃについての次回の送信基点は、送信基点＋８００秒（平常時送信周期＋高負荷時待機時間）で「１０：１３：２５」となる。また、優先度Ｄについての次回の送信基点は、送信基点＋１６００秒（平常時送信周期＋高負荷時待機時間）で「１０：２６：４５」となる。

（負荷判定部１１の詳細）
以下、図６を用いて負荷判定部１１を更に詳しく説明する。

図６（ａ）は、負荷判定部１１の処理手順を示している。まず、負荷判定部１１は、インターネット網や閉域ＩＰ網などのネットワーク３０を介して、送信タイミングとなった優先度をクライアント２０から受け取る（Ｓ１）。次いで、クライアント２０から受け取った優先度の受信可否をサーバ１０の負荷状況を基に判定する（Ｓ２）。最後に、クライアント２０から受け取った優先度の受信可否結果をクライアント２０に通知する（Ｓ３）。

図６（ｂ）は、優先度の一例である。ここでは、アプリ操作情報や異常検知アラームなどのＡＰログは、イベントドリブンな収集が求められる情報であるため、比較的高い優先度Ａ，Ｂとしている。一方、ＦＷバージョンやアプリ起動情報などの端末情報は、一定量を蓄積して定期的に送信すればよい情報であるため、比較的低い優先度Ｃ，Ｄとしている。

図６（ｃ）は、優先度別の受信可否判定規準を示している。この受信可否判定規準は、負荷判定部１１により用いられるものである。ここでは、負荷状況が５０％以下である場合は、全ての優先度Ａ，Ｂ，Ｃ，Ｄについて受信可としている。また、負荷状況が６０％〜５１％である場合は、優先度Ａ，Ｂ，Ｃについては受信可とし、優先度Ｄについては受信不可としている。また、負荷状況が８０％〜６１％である場合は、優先度Ａ，Ｂについては受信可とし、優先度Ｃ，Ｄについては受信不可としている。また、負荷状況が８１％以上である場合は、優先度Ａのみ受信可とし、優先度Ｂ，Ｃ，Ｄについては受信不可としている。

クライアント２０に対する受信不可通知方式としては、効果の違う方式Ａと方式Ｂの２方式を実装する。負荷判定部１１は、状況に応じていずれかの方式を適宜選択することができる。

方式Ａは、サーバ１０が支配下の全クライアント２０に対して次回の送信タイミングを変更することを一斉に指示する全体一斉周知方式である。閾値超過時、サーバ１０側から各クライアント２０に対してアクセス間隔にランダムな時間を追加するように通知する。この方式Ａのメリットは、負荷集中時において、全クライアント２０について一斉にアクセス間隔を変更するため、負荷収束が早い点である。一方、この方式Ａのデメリットは、サーバ負荷が低減された際も、低減前に全クライアント２０について一斉変更したリトライ時間までクライアント２０からアクセスがないため、ログ収集頻度の回復時間が長い点である。

方式Ｂは、受信可否判定を依頼したクライアント２０に対してのみ次回の送信タイミングを変更することを指示する個別対応方式である。閾値超過時、サーバ１０側にアクセスがあったクライアント２０に対してのみ次回の送信までの間隔にランダムな時間を追加するように通知する。この方式Ｂのメリットは、サーバ負荷が低減された際に、アクセスのあったクライアント２０から受付可能となるため、ログ収集頻度の回復時間が短い点である。一方、この方式Ｂのデメリットは、負荷集中時において、アクセスのあったクライアント２０毎にアクセス間隔を変更するため、負荷収束が遅い点である。

（送信タイミング変更部２２の詳細）
以下、図７及び図８を用いて送信タイミング変更部２２を更に詳しく説明する。

まず、送信タイミング変更部２２は、サーバ１０側から通知された受信可否結果が「受信不可」である場合、「受信不可」通知を受信した優先度以下の高負荷時待機時間として、優先度に応じた任意の範囲で発生させた乱数をセットする。ここでは、優先度Ａに応じた乱数範囲を「１〜９」、優先度Ｂに応じた乱数範囲を「１０〜９９」、優先度Ｃに応じた乱数範囲を「１００〜４９９」、優先度Ｄに応じた乱数範囲を「５００〜９９９」とする。この場合、図７に示すように、優先度Ｂについて「受信不可」通知を受信したときは、優先度Ｂ，Ｃ、Ｄの高負荷時待機時間として「３０」「１５０」「６００」などの乱数をセットすることができる。

また、送信タイミング変更部２２は、サーバ１０側から通知された受信可否結果が「受信可」の場合、「受信可」通知を受信した優先度以上の高負荷時待機時間をクリアする。例えば、図８に示すように、優先度Ｃについて「受信可」通知を受信した場合は、優先度Ａ，Ｂ，Ｃの高負荷時待機時間をクリアして「０」にすることができる。

（ログ送信部２３の詳細）
以下、図９を用いてログ送信部２３を更に詳しく説明する。

まず、ログ送信部２３は、サーバ１０側から「受信可」通知を受信すると、クライアントログＤＢ２５において送信ＩＤが付与されていない該当優先度のログ全てをサーバ１０に送信する。該当優先度のログがない場合は送信しない。例えば、優先度Ｂについて「受信可」通知を受信した場合は、図９（ａ）に示すように、クライアントログＤＢ２５からログＩＤ「３」及び「４」のログを読み出してサーバ１０に送信する。

次いで、ログ送信部２３は、サーバ１０に送信した該当優先度のログについて送信ＩＤと送信時間をセットする。例えば、ログＩＤ「３」及び「４」のログをサーバ１０に送信した場合は、図９（ｂ）に示すように、クライアントログＤＢ２５の該当フィールドに送信ＩＤ「３１」と送信時間「１０：０９：５７」をセットする。

その後、ログ送信部２３は、サーバ１０側から「ログ受信完了」通知を受信すると、クライアントログＤＢ２５から該当送信ＩＤのログを削除する。例えば、送信ＩＤ「３１」について「ログ受信完了」通知を受信した場合は、図９（ｃ）に示すように、クライアントログＤＢ２５から送信ＩＤ「３１」のログを削除する。

なお、送信時間からある一定時間経過してもクライアントログＤＢ２５に残っているログの送信ＩＤ及び送信時間はクリアするのが望ましい。例えば、図９（ｃ）に示すように、ログＩＤ「１」のログは、送信時間からある一定時間（例えば１０分）経過してもクライアントログＤＢ２５に残っている。このような場合は、ログ送信失敗と判断して送信ＩＤ「３０」と送信時間「１０：００：００」をクリアし、次回タイミングで送信する。これにより、サーバ１０側で受信できていないログを確実に再送することができる。

（動作）
図１０は、本発明の実施の形態におけるログ収集システムの動作を示すフローチャートである。以下、図１０を用いて本ログ収集システムの構成をその動作とともに説明する。

まず、クライアント２０は、初回のログについて送信基点をセットし（Ｓ１１）、ログの送信タイミング（送信基点＋平常時送信周期）になると、該当優先度についてサーバ１０側で抑制制御中である可能性を確認する（Ｓ１２→Ｓ１３）。ここで、サーバ１０側で抑制制御中である可能性が低い場合（高負荷時待機時間＝０）は、該当優先度についての受信可否判定をサーバ１０に即座に依頼するとともに、次回のログについて送信基点をセットする（Ｓ１３→Ｓ１４）。一方、サーバ１０側で抑制制御中である可能性が高い場合（高負荷時待機時間＞０）は、高負荷時待機時間が経過するまで待つ（Ｓ１３→Ｓ１５）。そして、（送信基点＋平常時送信周期＋高負荷時待機時間）となった時、該当優先度についての受信可否判定をサーバ１０に依頼するとともに、次回のログについて送信基点をセットする（Ｓ１５→Ｓ１４）。

次いで、サーバ１０は、クライアント２０から送信タイミングとなった優先度を受け取ると、その優先度についてログの受信可否をサーバ１０の負荷状況を基に判定する（Ｓ２１）。ここで、当該優先度についてログ受信不可と判定した場合は、「受信不可」通知をクライアント２０に送信する（Ｓ２１→Ｓ２２）。一方、当該優先度についてログ受信可と判定した場合は、「受信可」通知をクライアント２０に送信する（Ｓ２１→Ｓ２３）。

次いで、クライアント２０は、サーバ１０から「受信不可」通知を受信すると、優先度別ログ送信タイミングＤＢ２４において該当優先度以下の高負荷時待機時間をセットする（Ｓ１６）。一方、サーバ１０から「受信可」通知を受信すると、優先度別ログ送信タイミングＤＢ２４において当該優先度以上の高負荷時待機時間をクリアするとともに、当該優先度のログをクライアントログＤＢ２５から読み出してサーバ１０に送信する（Ｓ１７，Ｓ１８）。

これにより、サーバ１０は、クライアント２０からログを受信すると、そのログをクライアントログ収集ＤＢ１２に格納するとともに、ログ受信完了通知をクライアント２０に送信する（Ｓ２４→Ｓ２５）。クライアント２０は、サーバ１０からログ受信完了通知を受信すると、その送信済みのログをクライアントログＤＢ２５から削除する（Ｓ１９）。

（従来技術との比較）
図１１は、従来技術と比較するための図であって、（ａ）は従来のサーバ側負荷制御方式、（ｂ）は本発明の実施の形態におけるハイブリッド型負荷制御方式を示している。

まず、従来のサーバ側負荷制御方式によれば、図１１（ａ）に示すように、ログ発生の都度、ログ送信要求をするため、サーバ１０が高負荷状態になりやすく、負荷収束も遅れる。その結果、サーバ１０が高負荷状態である場合は、リアルタイムに収集したいログ３の収集に遅延が生じる。

一方、本発明の実施の形態におけるハイブリッド型負荷制御方式によれば、図１１（ｂ）に示すように、優先度（リアルタイム性）が高いログ１，３をリアルタイムに収集可能である。また、優先度が低いログ２，４，５については、サーバ１０側で受信不可となる可能性があるため、待機時間が経過するのを待ってからサーバ１０に送信することができる。

図１２は、従来技術と比較するための図であって、（ａ）は従来のクライアント側負荷制御方式、（ｂ）は本発明の実施の形態におけるハイブリッド型負荷制御方式を示している。

まず、従来のクライアント側負荷制御方式によれば、図１２（ａ）に示すように、全てのログを一定間隔蓄積してログ送信する。その結果、サーバ１０の負荷状態に関わらず、リアルタイムに収集したいログ１，３の収集に遅延が生じる。

一方、本発明の実施の形態におけるハイブリッド型負荷制御方式によれば、図１２（ｂ）に示すように、優先度（リアルタイム性）が高いログ１，３をリアルタイムに収集可能である。また、優先度が低いログ２，４，５については、サーバ１０側で受信不可となる可能性が低くなったタイミングでサーバ１０に送信することができる。

以上説明したように、本発明の実施の形態におけるログ収集システムは、クライアント２０からのログをサーバ１０で収集するログ収集システムであって、クライアント２０は、収集タイミングのリアルタイム性の観点から付与された優先度に基づいてサーバ１０に送信するログについてサーバ送信間隔制御を行い、サーバ１０は、サーバリソース状況に応じ、優先度に基づいてクライアント２０から受信するログについて受信抑制制御を行う。これにより、サーバ１０が高負荷状態の場合でも、リアルタイム性が要求されるログの収集に遅延が生じない。すなわち、サーバ１０は、サーバリソース状況や収集するログの優先度に基づいた受信抑制制御を行うことができるため、想定上限を超えた負荷を抑制することが可能である。また、クライアント２０は、全てのログをイベントドリブンで送信するのではなく、収集タイミングのリアルタイム性を考慮し、リアルタイム性が低いものは長い間隔で蓄積してサーバ１０に送信するため、サーバ１０への送信要求を最小限に抑えることが可能である。

また、クライアント２０は、サーバリソース状況に応じ、ログ送信を待機させる待機時間を優先度に基づいて動的に変更してもよい。これにより、クライアント２０は、サーバリソース状況に応じた効率的な送信要求を行うことが可能である。

また、クライアント２０は、サーバ１０で受信抑制されたログの優先度より低い全てのログについてサーバ送信タイミングを遅らせるとともに、サーバ１０で受信完了したログの優先度より高い全てのログについてサーバリソース平常時のサーバ送信タイミングに戻してもよい。これにより、サーバ１０が高負荷状態の場合は、優先度の低いログの送信要求を抑制することが可能であるとともに、サーバ１０が低負荷状態に回復した場合は、該当優先度より高い優先度のログの送信要求を促進することが可能である。

なお、本発明は、ログ収集システムとして実現することができるだけでなく、このログ収集システムに用いられるサーバ１０又はクライアント２０として実現することもできる。もちろん、サーバ１０又はクライアント２０が備える特徴的な処理部をステップとするログ収集方法として実現したり、それらのステップをコンピュータに実行させるログ収集プログラムとして実現したりすることも可能である。このようなプログラムは、ＣＤ−ＲＯＭなどの記録媒体やインターネットなどの伝送媒体を介して配信することができるのはいうまでもない。

１０…サーバ
１１…負荷判定部
１２…クライアントログ収集ＤＢ
１３…ログ受信部
２０…クライアント
２１…送信タイミング制御部
２２…送信タイミング変更部
２３…ログ送信部
２４…優先度別ログ送信タイミングＤＢ
２５…クライアントログＤＢ
２６…ログ集約部

Claims (3)

1. クライアントからのログをサーバで収集するログ収集システムであって、
   前記クライアントは、収集タイミングのリアルタイム性の観点から付与された優先度に基づいて前記サーバに送信するログについてサーバ送信間隔制御を行い、
   前記サーバは、サーバリソース状況に応じ、前記優先度に基づいて前記クライアントから受信するログについて受信抑制制御を行う
   ことを特徴とするログ収集システム。
2. 前記クライアントは、サーバリソース状況に応じ、ログ送信を待機させる待機時間を前記優先度に基づいて動的に変更することを特徴とする請求項１に記載のログ収集システム。
3. 前記クライアントは、前記サーバで受信抑制されたログの優先度より低い全てのログについてサーバ送信タイミングを遅らせるとともに、前記サーバで受信完了したログの優先度より高い全てのログについてサーバリソース平常時のサーバ送信タイミングに戻すことを特徴とする請求項２に記載のログ収集システム。

Images