ログ取り扱いの仕組み

[戻る]
VAL 2005/02/22(火) 15:08:58
テキストログを記録し、表示するプログラムを作っています。
ログは1件につき1行あり、改行コードで終わります。
新たなログが発生する度に、テキストログに追記します。

ログの表示形態は以下のパターンを可能とします。
・最新の10件(10行)を新しい順に表示
・同じく古い順に表示
・全てを新しい順に表示
・同じく古い順に表示

ここで質問ですが、上記のようなプログラムの場合、どのような作り方をすれば良いで
しょうか?

とりあえず以下の方法を思い付きました。

・全てメモリに読み出して行インデックスで管理する(どのような表示方法でも柔軟に
扱えるかも?)
 →ログが膨大になってくると処理時間がかかりそうです。

・表示方法に応じてファイルの先頭や終端から改行コードをサーチする
 →スマートではない気がしますし、終端からサーチするのは効率が悪そうです。

・単純なテキスト形式をやめて、固定長レコードでログを記録する
 →ログ内容の仕様次第ですが、ログの長さが制限されてしまうので出来れば避けたい
です。

・ログの追記をやめて、ログ毎にファイルを作る
 →これも、ログが膨大になってくると処理時間がかかりそうです。

どれも一長一短かと思いますが、実際につくって検証した訳ではないのであまり自信は
ありません。

他に良い方法はありますでしょうか?
環境としてはデータベースやクラスライブラリを使用しません。
C/C++でWindowsXPです。
よろしくお願いします。

PATIO 2005/02/22(火) 15:44:24
データベースもクラスライブラリも使わないのであれば、
ログはただのテキストファイルでしょうし、そうなれば処理方法も限られると
思いますが、どうなんでしょう。

一括で読むと言う方法が挙げられていますが、
ログが膨大になった時にメモリに読み込みきれなくなったりしませんか?
ログのサイズに制限があってサイクリックに使用するというのであれば、
全て読み込むと言うのもわかりますが、永遠と追記するのであれば、
その方法では駄目でしょう。

あと、ログを書き出す方にも手を入れられるのであれば、ログを書き出す時に
インデックスも書き出すようにすれば、ファイルを舐めるという事はしないで
済みます。ただし、この場合はインデックスとログファイルの同期が取れていないと
駄目ですから、消す時は両方ともバッサリ消すか、古い順にN件消すと言うような
ツールを用意しないと駄目でしょうね。表示ツールで消すと言う手もあるかな。

細かい話をしだしたらそれこそ星の数ほど方法がありそうな気はしますけれど、
まずはこれはと言う方法でやってみる事からはじめてはどうですか?
開発規模としてはさほどでもないと思いますし、Try And Errorでやってみるのも
良いかと思います。

PATIO 2005/02/22(火) 15:48:16
実際に細かい仕様を詰めるには、提示している条件では足りないと思います。
ログサイズに上限はあるのかとか、
表示プログラムは何処までのサイズまで対応できればいいのかとか。
OSとかファイルシステムの制限以外に制限を設けないと言う話なら
それはそれで考えないといけませんよね。
表示プログラムに求められているスペックをもっと明示的に数値で決めないと
細かい部分を決めようとするたびに疑問点にぶち当たる事になると思いますよ。

PATIO 2005/02/22(火) 15:52:35
なんか追記ばっかりですが、
表示ツールのどの部分の機能を重視したいのかで設計も変わってきます。
表示できるファイルのサイズなのか、指定の位置を表示する時のレスポンスなのか
それとももっと別に重視したい部分があるのか。

状況によってはスマートでない方法を取らねばならない事もあります。
目的がはっきりしなければ、手段を選ぶ決め手にかけると思います。

とおり 2005/02/22(火) 16:48:43
イベントログに書き込みしてしまうのもありかもしれません。
最大ログサイズ指定があるので書きっぱなしで平気ですし、
イベント番号を決めておけば表示するときもそれほど
苦にはならないと思います。

#あ、でも消えたら駄目なのか。
#ログの上限決められるなら調べてみるのもいいかもしれません。

VAL 2005/02/22(火) 16:58:58
[[解決]]
お返事ありがとうございます。

> あと、ログを書き出す方にも手を入れられるのであれば、ログを書き出す時に
> インデックスも書き出すようにすれば、ファイルを舐めるという事はしないで

なるほどです。バグで整合性が取れなくなった時の救済策も考える必要はありますが、
それを差し置いて、これだとかなりスマートですね。

> 実際に細かい仕様を詰めるには、提示している条件では足りないと思います。
> ログサイズに上限はあるのかとか、
> 表示プログラムは何処までのサイズまで対応できればいいのかとか。

プログラムイメージとしては、サーバーで生成されるアクセスログの解析ツールの
ようなものを考えていましたが、これ以上のことはあまり考えていませんでした。

上限というか、一度に表示する件数が多すぎても重たいのは確実でしょうから、
10件毎とか100件毎にページを切り替えるようなことは考えていました。

ログサイズの上限は、生成側で何らかの処理を行う事にします。

> 表示ツールのどの部分の機能を重視したいのかで設計も変わってきます。
> 表示できるファイルのサイズなのか、指定の位置を表示する時のレスポンスなのか
> それとももっと別に重視したい部分があるのか。

まずは最近のログを過去に遡って確認したいということと、それにかかる負荷を
抑えたいということですね。

全てのログを表示する機能は取りあえず置いておきます。
先程書いたように、これだと恐らく使い物にならないでしょうから、n件毎に表示
する方向で行きたいと思います。

ということで、取りあえずインデックスファイルを作る方向で検討してみます。

解決チェックを入れますが、もし他にもありましたら追記お願いします。
ありがとうございました。

VAL 2005/02/22(火) 17:05:52
書いてる間にレスが…ありがとうございます。

> イベントログに書き込みしてしまうのもありかもしれません。

これは面白いですね。
環境を選ぶかも知れませんが(よく分かりませんが)、場合によってはかなり楽そうで
す。
検討材料に加えたいと思います。

ありがとうございました。

Ban 2005/02/22(火) 18:00:43
> 環境を選ぶかも知れませんが(よく分かりませんが)、

Win2000 や XP など、きょうびの NT系Windows なら動作します。

古いスレッドには追加発言できません。