あなたがこの記事を読んでいるなら、あなたはおそらく簡単なワンストップショップの方法を探しています ログを理解する.
申し訳ありませんが、ログは簡単に処理できるほど単純ではありません。 実際、実用的なレベルでこのトピックに取り組み始めると、それが本当にどれほど複雑で煩わしいのかがすぐにわかります。
この投稿では、ログを10年間使用してきた経験を共有し、環境内を流れるログの完全な制御を維持するログインフラストラクチャを確立するために必要なコンポーネントを理解できるようにします。
ログインフラストラクチャのセットアップ
ログインフラストラクチャとはどういう意味ですか？
ここでは、検討する必要のある各レイヤーについてXNUMXつずつ説明します。さまざまなレイヤーに使用する必要のあるツールは非常に依存しているため、特定のツールに飛び込むことなく実行します。 特定の環境と 特定のニーズ。 代わりに、ログインフラストラクチャを設計するときに最良の条件を念頭に置くために、各レイヤーについて考慮する必要があることについて少し説明します。 それが小さなインフラストラクチャであるか大きなインフラストラクチャであるかは関係ありません。 最終的には設計する必要があり、最初から設計するのに役立ちます。
ログインフラストラクチャは、コンポーネントタイプのいくつかのレイヤーの合計であり、XNUMXつの環境ですべての目標を達成し、すべてのコンプライアンス要件を満たすのに役立ちます。 組織によっては、これはさまざまなコンポーネントの大きな山を意味し、他の組織にとっては、それらの小さな山を意味するか、場合によってはXNUMXつの巨大なツールでさえあります。 最終目標として通常念頭に置いているレイヤーが最後のレイヤーになります。
これらのレイヤーの一部にはそれぞれ複数のコンポーネントが含まれている可能性があることを知っておくことが重要です。さらに混乱させるために、一部のコンポーネントは複数のレイヤーもカバーしています。 それはすべて、環境のニーズ、ポリシーに設定されている潜在的な要件、および環境に含めることを選択したコンポーネントによって異なります。
ログインフラストラクチャのさまざまなレイヤー
コレクション
ほとんどのITコンポーネントはログを生成します。 それらのいくつかは、それらをネイティブに送信するための優れた方法を持っています。 ログの送信方法が制限されているものもあれば、ログをどこにも送信できないものもあります。代わりに、ローカルで収集して次のレイヤーに送信する必要があります。 ログをローカルに収集することは、多くの場合、ログを読み取るためにデバイスにエージェントをローカルにインストールする簡単なプロセスです。 ログを転送するためにわずかに再構成する必要のあるエージェントがすでに存在する場合もあれば、エージェントを使用して、ログを転送するネイティブメソッドがないソースからログをフェッチして、ログを処理、保存、および実行できるようにすることもできます。とにかく分析しました。
摂取
ログはどこかに送信する必要があります。 この「どこか」は、通常、ログの直接の受信者である取り込みレイヤーと呼ばれるものです。 このレイヤーは、送信されたログを取得して、XNUMXつの場所のいずれかに転送する役割を果たします。 一部のログインフラストラクチャは、 バッファリング データがストリーミングされるレイヤー。 ただし、ほとんどの場合、単純な ルーティング 層。 取り込みレイヤーは、イベントからデータを抽出したり、該当する場合はメタデータでイベントを強化したりする役割も果たします。 つまり、このレイヤーで発生する可能性があり、頻繁に発生するカスタム解析が多数あるということです。 他のレイヤーで実行することも可能ですが、ここまたはコレクションレイヤーで実行することをお勧めします。
バッファリング
バッファリングレイヤー（ストリーミングレイヤーと呼ばれることもあります）は、常に存在するとは限らない、もう少し高度なレイヤーです。 ただし、これは非常に便利なものになる可能性があります。 バッファリングレイヤーは通常、実装されると、取り込みとルーティングの両方が相互作用するレイヤーです。 キューイングのためにログインフラストラクチャでログを転送するための取り込みレイヤーとルーティングレイヤーは、ログを取得して転送するためにそれに接続します。
ルーティング
ルーティングレイヤーは、受信したログを取得し（または、バッファーレイヤーが関係している場合はフェッチし）、ルールの仕様に従って、ログを目的の宛先に転送します。 このレイヤーはかなり単純ですが、通常、ログインフラストラクチャ全体の複雑さに応じて、作成するのがより複雑なレイヤーのXNUMXつです。 私にとって、個人的には、これは適切なログインフラストラクチャの最も重要なレイヤーです。 これの単純な理由は、さまざまなタスク用に設計されたさまざまな分析コンポーネントにさまざまなログを転送できることです。 セキュリティログをセキュリティログ分析コンポーネントに送信します。 運用ログは運用ログコンポーネントに、アプリケーションログはアプリケーション監視コンポーネントに。 適切な場所への適切なログ。
Storage
ストレージレイヤーは、そこにルーティングされたログを受信し、保存する必要がある期間、ログを保存します。 これは通常、コンプライアンス要件または組織が採用することを決定したポリシーのいずれかに関連しています。
分析
分析レイヤーは、ログで多くのクールな魔法が発生するレイヤーです。 上記のレイヤーのほとんどは、この目的を達成するための手段にすぎません。 コンプライアンス以外の価値を提供するには、ログを分析する必要があります。 多くの組織は、ログデータをほとんど分析していません。 ほとんどの場合、ログデータをすぐに利用することすらできません。 分析層はそれを改善するためにあります。 一部の組織は、単純な検索レイヤーを採用し、エンドユーザーが特定のパラメーターに一致する履歴ログをログストレージに照会する方法を提供しています。 これは、多くのシナリオでの調査に役立ちます。 一部の組織は、ライブ分析システムを介してログを送信します。これにより、特定のイベントタイプに関するアラート、時間の経過に伴うメトリックの追跡、または履歴検索とは対照的なライブデータのセキュリティ監査を実行できます。
レイヤーをまとめる
これらのレイヤーをカバーすることは、ログデータを操作するための最良の状況が得られることを意味します。 たとえば、ルーティングレイヤーを忘れた場合、環境に新しい分析レイヤーコンポーネントを実装しようとすると問題が発生します。 取り込みシステムの書き換えの側面を見逃していると、ログメトリック追跡コンポーネントを使用しようとすると問題が発生します。
始めたら ログの操作、常に完全なパイプラインについて考えるようにしてください。 次に実装しようとしている特定のコンポーネントについて考えるだけではいけません。 代わりに、将来それらをさらに実装する必要がある、または実装したいという観点と、それに対処するために環境を最初からどのように設計できるかという観点から、事前に計画を立ててください。 ある時点で、新しいソリューションを実装する必要があるからです。 それはITの自然法則であり、私たちは決して終わっていません。
