BSA
Log Format and Management †
- ログデータは様々な方法によって構成することができる。
- フラットなテキストファイル、データベース、システムからのフォーマルなモニタリングシステムへの直接の入力を含む。
- 例えばHP Open ViewやWindowsのevent logのようなもの
Log Format †
下記はログのフォーマットに対する一般的な傾向だ。
国際化
- ユーザの言語でのログデータの作成はユーザビリティの継続的な改善となる。
- それはシステムすべての操作を自分の言語で行いたいユーザにとっては良いポイントとなる。
タイムスタンプで始まること
- ログファイルの最初の記述はタイムスタンプで始まるべき。
常にユニークなID、実際のソースコードのロケーションが追えること
- ログデータはユーザが知りたい時にソースコード上で何が起こっているか説明できるともっとも使いやすい。
トランザクションIDの提供
- 多くのログエントリーは様々なトランザクションに関連付いている。
- 一旦IDがトランザクションに割り当てられたら、それをログに記載すること。
- これは一つのトランザクションのログデータを紐付ける良い方法だ。
Flat files
- フラットフォーマットはログファイルでもっとも一般的な形式だろう。
- それはデータベースよりも素早く適用性が高く、移植が簡単だ。
- 下記は良いフラットファイルのデザインの考え方だ。
簡単に解析できること
- フラットファイルの内容は簡単に解析できないといけない。
- 少し思うこととしては、これは後で多くの作業を抑えることができる。
- 経験則的には、リレーショナルデータベースやMS Excelのような解析ツールに容易にインポートできるようにすべきだ。
簡単に読めること
- ログファイルは通常簡単に解析できるものだが、
- しかし、読むのが簡単でない時もある。
- もう一度、少し計画的にコンピュータと人間の両方にとって解読しやすいものを作成するようにして見ることを考えてみよう。
よく考えられた場所に置くこと
- ログファイルをユーザが想像もつかない場所に置いてはいけない。
- 例えばルートディレクトリのような場所には。
- ログファイルはよく考えられた場所に置くべきだ、アプリケーションに関連付けられたものかユーザもしくは管理者が設定できるものであることが好ましい。
よく考えられたログの名前
- 筆者はログファイルの名前が簡単に理解されやすいものを好む。
- しかしたまにはそれは不可能な時もある。
- 例えば、アプリケーションのそれぞれの実行時に分離されたログファイルを生成される場合など。
- これらのケースでは、開発者はランダムな名前をファイルに対してつけたいと思うかもしれないが、ログファイルはよく考えられた場所に置くべきで、ログファイルの名前の一部はログファイルが生成された日時とすべきだ。
- YYYY-MM-DD-HH-MM-<log file name>のフォーマットは日付によってソートする時に役立ったりする。
ゴミや特殊文字を含まない
- ログファイル中に普通でない文字を記載することは避けるべき。
- もし複数の言語のことを心配するなら、Unicode文字を使おう。
ドキュメント
- 設定ファイルのようにログファイルも適切に使用することを確かにしてくれる厳密なドキュメントが必要だ。ログがどう作成され、いつどのように作成されたかを説明する必要がある。また違う設定によって起こったものか、そうでないかを示す必要がある。
調和または監査ID
- 開発者が異なるログファイルを使用するなら、それらのエントリー間の関連性を紐付けることができるIDを作成しよう。
それがすべてにおいて可能なら、サードパーティアプリケーションのIDを使用しよう。
Log Management †
- このセクションではログがエラに状態についてどういつ作成・更新または削除されるかを述べる。
- 下記を考えてみよう。
Dynamic Logging
- 複合システムはオペレーションの間にログレベル詳細やどの種類のオペレーションをログにするかといったロギングパラメータを設定できる機能があるとメリットがある。
- これは顧客に対し、顧客自身がキーとなる問題をリアルタイムで解決することのサポートをすることができる。
- もっと洗練された手法ではロギングの設定をログデータが必要な場合か判断することができるようシステムが構築されている。
- 障害検知機能がなにかの故障を知らせている場合は、しばらくの間詳細なログを出力するといったものだ。
Per-Thread Logging
- 複数のアーキテクチャレイヤーを通るオペレーションをする複数のサーバではリクエストは通常分離されたスレッドにて実行される。
- この結果として、ログのエントリーはいくつかの異なるコンポーネントから生成され、実行する複数のスレッドごとに有用な出力をするために関連付けされている必要があるかもしれません。
- もしマルチスレッドを使用するなら、スレッド毎のロギングをサポートしているか確認したほうがいい。
Logging Levels
- ロギングの開始・終了に加えて、詳細なレベルの設定を実装することを考えてみよう。
- これは通常ロギングレベルと表現される。それはロギングすべき情報の種類の量を示す数字を設定する。
- 例えば、開発者用のロギングに高い数字を設定し、デフォルトのロギングになにかを設定したとする。
- これはログが特殊または特別な環境でのみ必要とされるデータでいっぱいになることを防ぐ助けとなるだろう。
- ロギングレベルの完璧なアプローチは様々なロギングデータをラベル化することだろう。
- これらのラベルはロギングレベルを使うことでとてもフレキシブルなシステムを作り上げることができる。
- 下記はラベルのいくつかの例だ。
- Debug: 通常はデータを拡張するために使用される。エラー診断が必要な場合に有効にする。
- Info: 通知するに値する情報を提供する。
- Warning: 潜在的なエラー状態が検知された場合にログを生成される。これはシステムがクリティカルなリソース量より少ないと検知した場合に生成される。
- Error: エラーが起こった時にログが生成される。
- ロギングレベルとラベルについては早期に定義されたカテゴリとともに動作するべきだ。
- なので、Warningエントリーについては期待されたプロセスのイベントよりシステムが長い時間を取る場合にパフォーマンス目的で生成されるべき。
- Warningエントリーはメモリやディスクの不足から生成されるオペレーション状態に基づく。
- warningかerrorを振る舞いのトラッキングや使用状況に使うのは悪い例だ。
APIs
- ロギングレベルとラベルのふるまいをコントロールするために適合的にデザインされたAPIを通して設定されるべきだ。
Configureable Syntax
- プロセスを簡単に異なるフォーマットとしたいときがある。
- たとえばWebサーバの機能として、Apacheがあるが、文法と内容を完全に設定することができる。
Log Exceptions
- 例外とロギングは密接に関連している。ログはいつも例外でもある。
Removable
- 多くのログは使用可能なように長く保存され、不必要な混乱したマシンやログを見る人に混乱を与える。ログの生成日時をファイルネームの一部とすることで、不必要なログを容易に削除することができる。
Security
- ログデータはセンシティブで、エンコードまたは特定の場所に保存すべきだ。
- ログデータの中身によっては、顧客は開発者と共有したくない場合もあるかもしれない。
Aumatic Forwarding
- テクニカルサポートと顧客の会話ではうまくいかないときは緊張が走るだろう。
- 顧客に対してログファイルを集めて送ることを求めた場合はもっとフラストレーションがたまるかもしれない。
- 技術的でない顧客はログがどこにあるか知らないかもしれないし、どう送ったらいいかわからないかもしれない。
- 顧客にとって簡単にするためには自動的に取得し、ログを送る機能を提供することを考えてみよう。
- 開発者にとって良い結果を得るだけでなく、顧客もハッピーになる。
Logging Standards and Libraries
- ログの標準は独立したプラットフォームかプラットフォーム依存だろう。
- ログファイルを標準化することで、顧客は解析ツールにて広い範囲で使用可能だろう。
- 他のロギングライブラリとして、log4jがjava向けにある。
担当者のつぶやき †
みんなの突っ込み †
