ロギングアーキテクチャソリューション
コンテキストを簡単に設定することから始めましょう。
私たちの組織（ビッグデータ会社）には、Webサイト、ワーカー（キューやトピックをリッスンするシステム）、スケジュールされたプロセス（トリガーされたプロセス）など、さまざまなシステムがあります。 、Java、Pythonなど。
組織が成長するにつれて、マイクロサービスエコシステムと関連するデータの量も増加します。ほとんどのシステムはローカルファイルにログを書き込みますが、一部のシステムは他のシステムよりもかなり古いため、統一されたアプローチはありません。明確に定義されたログアーキテクチャがなく、ほとんどのシステムがローカルファイルにログを書き込むため、これらのログを利用することは困難になっています。私たちは積極的に対応することができず、ログを読むことは複雑で、しばしば役に立たない。
これらの要件を特定しました。
- 関連するすべてのログをグループ化して追跡する方法が必要です
- ログは読みやすく、クエリしやすいものにする必要があります
- パフォーマンスを低下させてはなりません
- 各ログには次のものが含まれている必要があります：
- タイムスタンプ
- システム
- 環境
- インスタンス
- ActivityId（グループ化因子）
- クラス+メソッド
- 有用な情報
- 例外の場合は、スタック、メッセージ、回線、入力などを呼び出します。
そして、これらの要件に基づいて、次のアーキテクチャを考案しました。
疑似実装は、おおよそ次のようになります。
システムが呼び出しを受信すると、その呼び出しにすでにActivityIdが含まれているかどうかを確認し、含まれていない場合は一意のActivityIdを作成します。各ログにはそのActivityIdが含まれ、その後の他のシステムへのすべての呼び出しにはそのActivityIdが含まれます。
ロギングコンポーネントは、ログを（バッチで、または1つずつ）ストリーミングサービスにスムーズに送信する必要があります。
発生する質問は次のとおりです。
- 私たちは何かが欠けていますか？アーキテクチャは意味がありますか？
- どのような考慮事項を考慮する必要がありますか？
- 存在するはずのコンポーネントと実際には存在しないコンポーネントはありますか？
- 実装の間違いに関係なく、アーキテクチャとしては機能しますか？
ここには他にもいくつか質問がありますが、それらのほとんどはアーキテクチャよりも実装に言及しています。
まだ設計段階にあるため、実装の詳細については詳しく説明していませんが、.Net用のSerilogとDataflow、およびJava用のLog4Jを使用したいくつかの優れたアプローチを見てきました。
任意の推奨事項や提案を歓迎します。
いくつかの考え。
写真は機械の境界を示していません。パフォーマンスが気になる場合は、サービスログをローカルファイルに（おそらく独自の形式で）作成し、他のローカルプログラムに、状況が冷えたときにログエントリを怠惰な方法で中央データベースに転送するようにします。
ロギングに関する私の経験では、大量のテキストが生成され、実際にスタックするまで誰もそれを気にしません。ログを記録すればするほど、そのログファイルをたどるのは魅力的ではなくなります。通常、1つのシナリオを作成し、それを再生して履歴の値を制限します（ジャーナル、証跡、トランザクションログについては説明しません）。ほとんどの場合、帯域幅とストレージスペースの無駄になります。そのため、分析を開始する直前に、起動時（または実行時でも）に設定できる重大度レベル（デバッグ、情報、警告、エラー、致命的）など、本番側でフィルタリングするものが必要です。注意が必要です。
これを機能/便利にするには、既存のすべてのサービスが同じ論理ログポリシーに従う必要があります。これは、既存のすべてのコードを確認してやり直すなど、多くの作業になる可能性があります。これはそれ自体が大きなプロジェクトのように聞こえ、販売するのは難しいように思えます。