マイクロサービスのロギングアーキテクチャ
ダースのマイクロサービスによって実行されるエンタープライズレベルのアプリケーションを開発します。すべてのマイクロサービスはdocker内にあり、これはすべて Kubernetes によってオーケストレーションされます。明らかに、私たちはいくつかのロギングソリューションを必要としています、そしてここにキャッチがあります。アプリケーションには2種類のログがあります。1つ目はアプリケーションエラーをデバッグする通常のログで、エラーがスローされた場合や何か問題が発生した場合に何が起こったかを確認します。たとえばテクニカルレベルのログ 。 2つ目はユーザーアクションログです。これは、ユーザーが行ったアクションを理解するためのもので、このログはIT担当者ではなくユーザーマネージャーによって使用されることになっています。たとえば、ビジネスレベルのログとしましょう。
私はすべてのログを管理し、たとえばログの重大度によるElastic searchフィルターを使用して技術者/ビジネスログを分離するための ELK Stack ソリューションを調査しています。重大度がINFOのすべてのログがビジネスログと見なされ、INFOが技術ログと見なされないとします。ログメッセージの内部形式を実装する可能性があります。これは、technical/businessログに格納する必要があるデータに依存します、この形式には、ビジネスログか技術ログかを示すフィールドが含まれます。
私の解決策についていくつかの批評を求めています。データ量に関してはログに保存される予定です。これは、インストールごとのユーザー数が100人未満のエンタープライズアプリケーションであるため、上限は1年で数ギガバイトになると思います。
私の経験に基づくいくつかの推奨事項があります。
- ユーザーアクションログユーザー監査ログを呼び出して、アプリケーションログと区別します。
- ELKは、両方の種類のログを保存するのに最適な場所です。
- アプリケーションログとユーザー監査ログに個別のインデックスを使用するので、それぞれにすべてのログレベルを使用できます。
INFOログはアプリケーションログに非常に役立ち、適切なログレベルを使用する能力を妨げないようにします。 - ログに相関識別子を含めて、問題のトラブルシューティングでユーザーログとアプリケーションログを照合できるようにします。