SLF4J / Logbackでマーカーを使用するためのベストプラクティス

プロジェクトでSLF4JとLogbackの組み合わせをしばらく使用しており、非常に満足していますが、ロギング戦略は非常に単純で、単純なクラスベースのロガーを使用し、MDCやマーカーなどの派手なものは使用していません。

私が知りたいのは、コミュニティの誰かが実際にこれらの機能を使用しているかどうか、およびロギング/フィルタリングを改善するためにどのように使用されているかです。

私は特に、ロギングに^[1]マーカーをどこで、なぜ、どのように使用するかについて興味があります。それらはロギングにセマンティックコンテキストを追加するためのかなりきちんとした機能として私を襲います-たとえば、クラスが複数の懸念を処理している間、タスク/懸念固有のマーカーを使用してログステートメントを区別することができます。

ロギングでマーカーを作成して使用するためのベストプラクティス、規則、または戦略は何でしょうか。

更新：私が思っているのは、マーカーを使用する理由ではなく、どのように部分を使用するかです。マーカーに名前を付ける上でいくつかの良い習慣があります（たとえば、スペースを含むプレーンテキストまたはダッシュ/アンダースコア/句読点で区切られたキーワードスタイル名を使用する） ）、「標準名」のプールのようなものがあれば、ビジネス機能に基づいて名前を付けます。おそらく私自身で理解できる質問ですが、これらの機能を体系的に使用して開発者のチームに紹介したい場合は、正式なガイドラインのセットを用意することは理にかなっています...

^[1] -する方法を尋ねることによって使用マーカーを、私は本当に（それはかなりまっすぐ進む本当にある）APIを使用する方法を求めていないのです-私はむしろ1が一貫マーカーを使用して周りのロギングを設定する方法を、より一般的なレベルに言及しています

まず、@ dariooが言ったように：

• MDCは、複数のイベントをいくつかの「エンティティ」に関連付けるために使用されます
• [マーカー]は、通常のイベントからフィルタリングしたい「特別な」イベントに使用されます

つまり、このためにMDCを使用したいというあなたの主張。マーカーは、「スライス」ではなく、「特別な」イベントを強調表示するためのものです。たとえば、特定のユーザーに基づいてスライスし、予期しない例外に基づいてフィルタリングすることができます。この場合、ユーザー MDCディメンションとUnexpectedExceptionマーカーを作成します。

しかし、これは明らかにあなたが考えていた質問には対応していません。「むしろ、一貫してマーカーを使用してログを設定する方法のより一般的なレベルを参照しています。」それでそれを取り上げましょう：

MDCはスライスとダイシング用で、マーカーはフィルタリング用です。これらのアクティビティは、テスト中および本番環境で実行されます。そのため、テスト/本番環境に移行するときに、ログデータをスライスするのに役立つ可能性があるディメンションと、フィルタリングするのに役立つ可能性があるディメンションを決定する必要があります。各ディメンションはMDCディメンションを取得します。各ケースはマーカーを取得します。それはそれと同じくらい簡単です。

開発者はここで決定を行う必要はありません。1人の人またはチームが、設計時に、サポートする必要があるスライス、ダイシング、およびフィルタリングの種類を決定する必要があります。これは、実行を要求される可能性のある分析タスクの種類を想像することによって通知されます。

この同じ人またはチームが命名規則を決定する必要があります。それは完全に任意です。審美的に心地がよく、自己記述的（最も重要）で、後の追加と競合する可能性がないほど十分に具体的なものを選択します。ハイフンとアンダースコアの違いは非常に細かく、驚くほど重要ではありませんが、ESLの従業員がアンダースコアを読むことは、少なくともCamelCaseと比べて混乱が少ないことに注意してください。同時に、必要なキーに到達するのが面倒なので、これは一部の開発者を困らせていると報告されています。

ポリシーの決定に関する限り、これは、特定のマーカーまたはMDCディメンションを使用する必要があるケースを定義することを意味します。これは厳しく（集中化、慎重に）維持しますが、開発者が寸法とマーカーのセットが現在のタスクには不十分であると感じた場合は、開発者からのフィードバックを許可します。必要に応じて、寸法や属性を修正/追加します。

このポリシーはほとんどの場合プロジェクト固有のものであることを理解してください。すべてのプロジェクトで同じ種類のロギング分析が必要なわけではありません。いくつかの悪夢のシナリオを想像してください。次に、そのシナリオでログを分析する方法を想像してください。どのメッセージがどのコンテキストに属し、どの状態がどの時点であるかを追跡するために、複雑なスクリプトを記述する必要はないでしょう。必要な情報を寸法とマーカーとしてエンコードし、問題が発生した場合の手間を省きます。

まず、MDC。

MDCは、いくつかの動作に関連付けられた「エンティティ」が1つある環境で本当に役立ちます。典型的な例：Webアプリケーションと対話するユーザー。したがって、多くのユーザーがWebアプリをいじり回しているとしましょう。MDCを使用すると、手間をかけずに簡単に追跡できます。簡略化した例：

...[Sandy][abcd] clicked on "change profile"
...[Joe][1234] clicked on "weather reports"
...[Joe][1234] clicked on "Europe"
...[Sandy][abcd] clicked on "logout"
...[Joe][1234] clicked on "logout"
...[Sandy][efgh] logged in

ここでは、ユーザー名とセッションIDの2つの場所でMDCを使用しています。このようにして、1人のユーザーのセッションを簡単にgrepして、ユーザーがこれまで行ってきたすべてのことを確認できます。

第二に、マーカー。

マーカーは通常、重大なエラーが発生した場合に管理者にメールを送信するなど、「特別な」状況で使用されます。すべてのエラーが常に同じカテゴリに分類されるわけではありません。一部は適切な方法で対処する必要があります。

または、ユーザーがサービスを終了すると、通常はINFOログに移動しますが、このようなイベントを別のログファイルに移動して監視したい場合は、そのようなインスタンスにマーカーを使用することもできます終了したユーザーの統計収集をより簡単に。

経験則：

• MDCは、複数のイベントをいくつかの「エンティティ」に関連付けるために使用されます
• マーカーは、通常のイベントからフィルタリングしたい「特別な」イベントに使用されます

マーカーを使用して、1つのログステートメントに色を付けたり、マークを付けたりできます。これらの色、つまりマーカーで何をするかは完全にあなた次第です。ただし、マーカーの使用には2つのパターンが共通しているようです（最初のパターンは2番目のパターンよりも一般的です）。

1. トリガー：一部のアペンダーは、特定のマーカーの存在下でアクションを実行するように指示される可能性があります。たとえば、ログレベルに関係なくSMTPAppender、ロギングイベントがNOTIFY_ADMINマーカーでマークされるたびに電子メールを送信するように設定できます。ログバックのドキュメントのマーカーベースのトリガーをご覧ください。ログレベルとマーカーを組み合わせてトリガーすることもできます。

2. フィルタリング：たとえば、（さまざまな複数のクラスファイル内の）永続性関連のすべてのログに「DB」という色を付けたり、色を付けたりできます。次に、「DB」をフィルタリングできます。DBでマークされたログステートメントを除き、ロギングを無効にします。詳細については、Logbackドキュメントのフィルターに関する章を参照してください（MarkerFilterを検索）。

補足として、logstashを使用していてjsonロギングを有効にしている場合、マーカーを使用して、特定のログメッセージに関連付ける変数をロギングすることができます。これは、メッセージ本文に含めるよりも一貫性があり、解析が簡単です。それがあなたのユースケースに合っている場合、非常に便利です。

詳細はこちら：

https://github.com/logstash/logstash-logback-encoder#loggingevent_custom_event