[解決済み] SLF4J/Logbackでマーカーを使用するためのベストプラクティス

質問

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

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

私は特に、どこで、なぜ、どのように
[1] マーカーをログに記録することです。たとえば、クラスが複数の関心事を処理する間、ログ ステートメントを区別するためにタスク/関心事特有のマーカーを使用することができます。

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

更新しました。 私が思うに、私が本当に求めているものは、あまり なぜ を使うか、ではなく、むしろ どのように の部分です。マーカーを命名する良い方法はあるのでしょうか (たとえば、スペースを含むプレーンテキストを使用するか、ダッシュ/アンダースコア/句読点で区切られたキーワード形式の名前を使用するか)、標準の名前とビジネス機能に基づいた名前のプールがあるのでしょうか？質問はおそらく自分で解決できますが、これらの機能を体系的に使用し、開発者のチームにそれらを導入したい場合、何らかの正式なガイドラインのセットを持つことは理にかなっています...。

[1] - どのようにすればよいかを問うことで を使う マーカーをどのように使用するかを尋ねているのではなく、マーカーを一貫して使用するためのロギングをどのように設定するかという、より一般的なレベルを尋ねているのです。

どのように解決するのですか?

まず、@darioo さんのおっしゃる通りです。

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

MDC を使いたいということですね。マーカーは、quot;slicing" というよりも、quot;special" イベントを強調する、いわばフィルタリングするためのものです。たとえば、特定のユーザーに基づいてスライスし、予期せぬ例外が発生した場合にフィルタリングすることができます。この場合 ユーザー MDC ディメンジョンと UnexpectedException マーカーを使用しています。

しかし、これはどうやら、あなたが考えていた質問には対応していないようです。あなたはむしろ、一貫してマーカーを使用してどのようにログを設定するかという、より一般的なレベルについて言及しているのです。

MDC は スライスとダイシング であり、マーカは フィルタリング . これらの活動は、テスト中や本番中に行われる . そのため、テストや本番が近づいたときに、ログデータをどの次元でスライスするのが便利か、どのケースに対してフィルタリングするのが便利かを決める必要があります。 各次元には MDC 次元が含まれます。各ケースはマーカーを取得します。 というように単純です。

開発者はここで何も決める必要はないのです。 一人の人間、あるいはチームが決定すべきです。 設計時に どのような種類のスライス、ダイシング、およびフィルタリングがサポートされる必要があるか。これは、どのような種類の分析タスクを実行するよう求められるかを想像することによって知らされるべきです。

この同じ人またはチームが命名規則を決定する必要があります。

それは完全に任意です。 . 美観に優れたものを選びましょう。 自己記述的 (最も重要)で、後から追加したものと衝突しない程度に具体的なものを選んでください。ハイフン vs. アンダースコアは非常に些細なことで、驚くほど重要ではありませんが、ESL従業員がアンダースコアを読むのに混乱が少ないかもしれないことに注意してください (少なくともキャメルケースと比較して)。

方針を決めるということに関しては、これは単に 特定のマーカーまたは MDC ディメンジョンをどのような場合に使用するかを定義することです。 . これは厳重に（一元的に、意図的に）管理しますが、ディメンションとマーカーのセットが目下のタスクに対して不十分であると感じた場合は、開発者からのフィードバックを許可します。必要に応じて、ディメンジョンや属性を修正/追加してください。

理解する この方針は、ほぼ必然的にプロジェクト固有のものになります。 . すべてのプロジェクトに同じ種類のログ解析が必要なわけではありません。いくつかの悪夢のようなシナリオを思い浮かべてください。そして、そのシナリオでログをどのように分析できるようにしたいかを想像してください。おそらく、どのメッセージがどのコンテキストに属しているか、どの状態がどの時間であるかを追跡するために、複雑なスクリプトを書く必要はないでしょう？そのような情報が必要であれば、ディメンションおよびマーカーとしてエンコードし、何か問題が発生したときに手間を省くことができます。