実稼働環境のバグを調査するためにデバッグレベルのログに代わるより良い代替手段はありますか？
一部のお客様からは、ソフトウェアの1つの機能で予期しない動作が報告されることがあり、バグがあると思われます。
機能自体とバグの種類は、このディスカッションの目的にとって興味深いものではありませんが、壊れた部分がコマンドスケジューラであるという考えを修正するだけです。時々、スケジュールされたコマンドは失われ、それらはその日のスケジュールされた時間に実行されません。現在、この問題を管理された方法で再現することはできません。
壊れた機能の実装を担当するサービスを調査したところ、現在の実装ではログの数が不十分であり、ランタイムの動作を理解するのが非常に困難であることがわかりました。そのため、お客様のインストールでのランタイム動作についてより深い洞察を得るために、ロギングを改善することを決定しました。
この問題について推論しながら、基本的な質問を自問しました。ソフトウェア製品で何が行われているのかを完全に理解するために、デバッグレベルのログに応じてこれを選択するのは良い選択ですか？このような状況に対処するより良い方法はありますか？
重要なのは、なしは、デバッグレベルのログを有効にすることで、ソフトウェアを本番環境で実行することです（少なくとも標準的なシナリオでは）。デバッグレベルのログを有効にすると、大量のログが書き込まれ、ストレージの消費とパフォーマンスの点でログストアに悪影響を与える可能性があります。
したがって、最初の問題はデバッグレベルのログはデフォルトで本番環境で有効になっていません。これは、初めて問題が発生したときに、何が起こったのかを完全に理解するのに役立つ貴重なログがないことを意味します。予期しない動作を観察するだけですが、根本的な原因を明確に理解していません。
この点は、多くの場合予期しない動作を再現するパターンが不明であるか、あまり明確でないであるため、非常に有害な場合があります。つまり、調査を続行するためにデバッグレベルのログを有効にすると、以前に観察された問題を再現できなくなり、根本的な原因を理解できずにスタックする可能性があります。
これらのシナリオを処理するには、低レベルのログよりも優れた代替手段がありますか？
実稼働環境の外で壊れたコマンドスケジューラのようなバグを再現できず、テスト環境で実稼働環境を「十分に類似した」方法でミラーリングできない場合、質問に記載されている欠点にもかかわらず、ロギングは依然としてIMHOが最善ですあなたが持っているツール。
したがって、「デバッグレベルのログ」が必要だが、現在のロギングメカニズムが本番環境で役立つように多くのストレージまたはパフォーマンスを消費する場合は、ロギングを最適化するをお勧めします。例えば、
ロギングを「水平」（「最小」、「標準」、「デバッグ」レベルなど）だけでなく、垂直に（「モジュール」ごとに）構成できることを確認してください。これは、コマンドスケジューラのログレベルを「デバッグ」に設定するために使用できますが、システムの残りの部分では「最小」に保ちます。
スペースを最適化するには、デバッグログが必要以上に長く保持されていないことを確認してください。たとえば、バグが発生してから1時間以内に発生したことを検出できた場合、たとえば2時間より古い「デバッグ」ログエントリを自動的に削除できるようにします。
並列化を利用して速度を最適化します-おそらくログエントリの管理とディスクへの書き込みは、非同期ログサービスで実行できますか？もちろん、それは余分なエラーの原因になる可能性がありますが、ロギングシステムがまだそのように実装されていない場合は、試してみる価値があるかもしれません。
最適化は非常にケースに依存しているので、これに対する万能のソリューションはありませんが、一般的な考えを理解していると思います。
ロギング（または少なくとも「広範囲なロギング」）の代わりに、特定のバグがいつ自動的に発生したかを検出するメカニズムを実装してから事後ダンプを作成すると役立つ場合があります。 =ディスクへ。これは、クラッシュしたプロセスの永続的なメモリイメージという狭義の意味ではありませんが、システムの現在の状態に関するすべての情報を含む、自分で実装したカスタムダンプの種類として、問題の根本的な原因。
これがどのように見えるか、そしてこれがあなたのケースにとって意味があるかどうかは、システムの詳細に大きく依存しますが、これが過去にうまく機能していたシステムは確かにたくさんあります。
「ベスト」についてはわかりませんが、次のことが頭に浮かびます。
まず、あなたの直感は正しいです、
はい、操作ログは最初の発生をうまくカバーできないことがあります。
しかし、それはcatchしないことが目標ですdebugそれ。
.NETの IntelliTrace 複数のログを保持するためのアイデアを提供します。
- WarnLevel-永久に保持されます
- デバッグ-＃日後にプルーニング
パフォーマンスには役立ちませんが、ログストアをクリーンアップします
（ほとんどのロガーは設定によってそれを簡単に行うことができます）
もう1つのアイデアは、「動的」ログレベルを作成することです。
ログレベルは、発生したエラーの数の関数として増加します。
（注：このソリューションは複雑すぎるため、努力する価値はないと思います）
問題は：
- 問題がある場合は、すべてをログに記録します。
- 問題がなければ何もログに記録したくない。
- 問題が発生するかどうかはわかりません。
コードが問題の発生後にそれを認識できる場合は、かなりの労力でこれを解決できます。
すべてのログコードがあります。ただし、ログコードは、最小限のコストでログステートメントをバッファに格納するだけです。複雑な操作の開始時と終了時、およびエラーが検出されたときにロガーに通知します。操作が完了し、途中でエラーが検出された場合にのみ、すべてのロギングステートメントを永続ストアに保存します。それ以外の場合は、プロダクションロギングステートメントのみを保存します。
そのシステムは、全部である必要も、何もない必要もありません。ロガーに操作の開始を伝えなかった場合、現在のように、デバッグログは無視され、本番ログのみが書き込まれます。