スケジュールされたプロセスのロギング

Question

システムを1時間ごとに実行する予定のシステムでプロセスを実装しました。このプロセスは、レガシーシステムからインポートされたレコードの一部を実行し、いくつかの資格変更を行い、レコードステータスと資格情報を更新する必要があります。プロセスは毎日1000のレコード上で実行することができます

1. ：

   次は、このプロセスに関するいくつかの事実です。

2. 単一のレコードを修飾するには、複雑な論理パスが必要です。ある時点で、特定のレコードがどのように適格かどうかをデバッグして知る必要があります。資格を取得するために必要なロジックのパス。

私が知りたいのですが：

1. 任意のデザインパターンやアーキテクチャがスケジュールされたプロセスのこれらの種類のための効率的なロギングを適用するために使用することができますがある場合。
2. このプロセスのログメカニズムを実装する際に、どの情報がログに記録されると考えられますか？
3. どちらの方が良いでしょうか？データベースまたはファイルシステムにログを保存しますか？データベースのロギングが優れている場合は、任意のデザインがありますか？

スケジュールされたプロセスのアクションを記録する際のベストプラクティスに関する詳細を提供できる記事やリファレンスがあれば、私は感謝します。

Answer 1

質問に答えるには、ログの目的が何であるかを知る必要があります。私はいくつかの推測をするつもりですが、あなたの質問を広げることができれば、それは助けになります。

通常、アプリケーションにログを記録する理由は2つあります。これらの無人処理により

アプリケーション監視

は、あなたは彼らがまだ実行されていることを確認する必要があり、そうでない場合に誰かが通知されます。もちろん、これにはキャッチ22があります。アプリケーションが起動しなければ、どのようにログに記録できますか？

ほとんどのIT部門には監視ツールがあり、離れた場所からシステムを監視することができます - マイクロソフトではOperations Managerです。したがって、あなたの "ハートビート"ログは監視ツールでうまくいくはずです。この種類のログ記録に最適な場所は、Windowsイベントログです。イベントログは（データベースのように）死んでしまうことはなく、ファイル共有などの設定をせずに他のマシンから読み取ることができ、あらゆる種類の監視ツールとすぐに統合できます。

ハートビート監視は、次のものがあります

• 仕事を始めました。
• 仕事、資格のないXレコード処理され、Y資格、Zを終え
• 例外やエラー

その後、仕事に目を離さない、と確認することができますあなたの監視ツールその「X、Y及びZ」予想される境界内にある。

イベントログにも例外を記録することができます。つまり、毎日ログファイルを解析せずに何か問題が発生したときに、監視ツールから通知することができます。もちろん

デバッグ

、あなたはまた、物事がうまくいかないときに何が起こるかを調べることができるようになるでしょう。これは通常、イベントログには入りません。デバッグログには機密情報が含まれている可能性があり、オペレーションチームにはほとんど使用されません。

通常、デバッグログは、ローリングアペンダーを使用してディスクに書き込んで、ディスクスペースを大量に消費しないようにします。

通常、これらのファイルには「INFO」レベルでログオンします。オプションを使用すると、設定によってDEBUGに切り替えることができます。

ログは、主にアプリケーション設計によって決まります。あなたは間違いなく "入力"データを記録する必要があるので、開発者はデバッグしようとしている入力を使ってコードを再実行することができます。プロセスが外部データを実行する必要がある場合は、そのデータもログに記録します（たとえば、結果を判断する情報を得るためにWebサービスを使用する場合）。意思決定ツリーのすべてのステップを "INFO"レベルで記録しません。それはあまりにも冗長であり、追跡が難しいです。あなたは監査要件がある場合は

監査

は、イベントログには、適切な場所である - データが不正なスタッフによって操作することができないように、セキュリティを設定することができます。

私はあなたがすでに多くのログフレームワークの1つを使用していると仮定しています - Log4Netは私のお気に入りです。

コメントには、ログ記録要件の主な目的は、プロセスの結果を追跡して説明できることです。私はその "ロギング"を正直なものとは呼んでいません。ビジネスドメインからのファーストクラスの要件のように聞こえるのに対し、ロギングは通常技術的な要件を満たすために行われます。ログファイルは技術者を対象としており、通常、ジョブが実行される（安全な）マシン上にとどまります。お客様の要件は、顧客が直面しているように聞こえます。

私はアプリケーション設計を再訪し、ビジネス要件を満たすための最良の方法が何であるかを見ていきます。役に立つデザインパターンがいくつかあります。"Chain of responsibility"は、この種の決定木をモデル化するためのきれいな方法であり、チェーンのログを含めるように簡単に拡張することができます。

Answer 2

私は次のログを記録するのと同じ状況で：

• スケジュールジョブがスケジュールされたジョブは、各レコード
• 統計の処理に必要な処理
• デバッグ情報を見つかったレコードどのように多くの
• を開始しました処理されたレコード数および処理結果に関する情報

一般に、このタイプのロギングはファイルに行われます。データベースへのロギングに関する問題は、データベースがダウンするとロギングが停止することです。