ロガーの障害をどのように処理すればよいですか？

当社のアプリケーションのいくつかでは、カスタムロガーを使用しています。かなり堅牢ですが、将来NLogのようなものに置き換える可能性があります。ロガーのタスクの1つは、アプリケーションで発生した例外をログに記録することです。

私が常に抱えていた懸念の1つは、ロガー内の例外処理がサイレント障害を許容することです。つまり、ログが特定の例外（ロガーのエラーのため）に書き込まれていない場合、どのようにログを処理し、（どういうわけか）ロガー自体に例外を記録する必要がありますか？

WriteLog関数が例外をスローするとします。関数を何回か、または例外がスローされなくなるまで呼び出そうとしますか？スローされた例外をロガーで書き込もうとする必要があります（これにより、例外が発生する可能性が高くなります。最初にカスタムロガーを実装していたときを除いて、この状況に出会えないほど幸運でした。一方で、ロガーがアプリケーションの例外（独自の例外のため）のログに失敗したかどうかを現時点で知る方法はありません。

私はオンラインといくつかのSEサイトで検索しようとしましたが、すべての投稿がロガーのエラー（潜在的な例外とそれらのログ方法ではありません）またはロガー外の例外を扱っているため、これまでのところ無駄です。

ロガー内で例外が発生した場合、ロガーを使用して例外をログに記録しないでください。その理由は次のとおりです。

• 無限ループに陥っている可能性があります。ロガー内に、テストされていない（そして例外を生成する）条件分岐があると想像してください。条件が満たされると、それ以降に報告された例外はすべて同じブランチで処理されることを想像してください。これは、ブランチが実行された瞬間から、無限ループに陥ることを意味します。

• 一時的なループに陥り、1秒あたり数千の例外が発生する場合があります。リモートサーバーに例外を報告しているとします。サーバーの問題により別の例外が発生し、接続が復帰するまで別の例外が発生します。

代わりに行うべきことは、例外をログに記録するより安全な方法にフォールバックすることです。たとえば、ロガーがリモートサーバーに例外を送信する場合、syslog代わりにロガー内の例外を送信します。ロガーがWindowsイベントで例外を記録し、このアクションが失敗した場合、単純なテキストファイルに失敗の例外を保存します。

それができたら、次の質問は、それらの例外が発生したことをどのように知るかです：数千のサーバーで数十のアプリケーションを実行している場合、ローカルで何かをログに記録しているかどうかを定期的に確認することはできません。

1つの方法は、それらの「例外ログ」をチェックし、他の例外が保存されている場所にプッシュするcronジョブを持つことです（最終的にロガーを使用しますが、無限ループまたは一時ループに注意してください）。

ロギングがアプリケーションにとって重要な場合、ロギングが失敗したらアプリケーションを停止する必要があります。

クリティカルでない場合は、ある程度防御的であるため、セカンダリソースへのログ/アラートを行うロギングエラーを処理するセカンダリコンポーネントを使用できます。しかし、それでも完全な証拠ではなく、プライマリロガーを監視しているときにセカンダリロガーが失敗した場合に何が起こるかを考慮する必要があります。

優れた戦略は、ローカルファイルにログを記録し、それが失敗した場合、イベントログにそのログを記録し、電子メールアラートを生成し、データベースに保存するなどです。ディスク容量不足またはその他のまれな状態。

理想的には、アプリケーションの複雑さを軽減するため、静かに失敗するほうが良いでしょう。

さらに重要なことは、ロギング障害を処理するには、サードパーティからのログを監視することです。時間が経つにつれて、健全なアプリケーションがログに記録しているイベントの数を識別できるようになります。低レベルのログ記録を開始するか、イベントを記録しない場合、監視を通じて、発生している問題を確認し、サードパーティのメカニズムを介して潜在的にアラートを出すことができます。