ログ・パーティション化機能の利用例
要件に応じて、異なる事業部門または実行するサービスごとに異なるログ・セットを使用できます。次に、ログ・パーティション化機能の典型的なユース・ケースを示します。
トピック:
パーティション化ログ・セットを定義する正しい方法は1つではありません。Oracle Supportに連絡して、ユースケースに最適なものを決定できます。
最終使用: 複数の取扱商品
ユースケースには、通常、Log Analyticsユーザーが一度に1つのLOBについてのみログを分析し、場合によっては複数またはすべてのLOBにわたって検索する複数の事業部門(LOB)がある場合があります。
このシナリオでは、各LOBが常に1日当たり6TBのログを下にある場合、事業部門と連携するログ・セット文字列を使用することをお薦めします。たとえば、HR、グローバルIT、財務、出荷、オーダー、セキュリティなどのログ・セットです。
1つのLOBがログ収集の1日当たり6TBを超えるに達できる場合、ログ・セットは、ログの取得元のLOBのファンクションのタイプなど、二次的な側面に基づいて定義できます。たとえば、グローバルIT LOBで、ログ・セットとしてグローバルITを使用するのではなく、1日当たり20TBのログが取り込まれると予想される場合は、GIT-Database、GIT-Mail、GIT-Supportをログ・セット値として使用することをお薦めします。
ログ・セットを選択する鍵は、データの分析方法と一致することです。通常、GIT-Mailログが他のログを混在させずに単独で分析される場合、このログ・セットが適しています。GIT-DatabaseとGIT-Supportを常に同じ検索で組み合せる場合、それらを異なるログ・セットとして使用することは適切ではありません。
エンド・ユース: クライアントに基づくサービスのスケーリング
ユース・ケースでは、クライアント数に基づいてスケーリングする水平方向にスケーラブルなクラウド製品の実行が必要になる場合があります。
たとえば、各クライアントのクラウド・サービスの使用に一連の計算、データベースおよびネットワークが必要な場合、ログ・セットを編成する適切な方法は、クライアント名またはクライアント識別子を使用するこれらのクライアントです。この情報はアクセス可能で、特定のクライアントのログを検索するユーザーが理解できる必要があります。このような場合、クライアントC1、C2、C3がある場合、これらは各クライアントのログに使用するログ・セット文字列になります。
通常、問題をデバッグする場合、運用チームは、サポートの一部として特定のクライアントのログを検索します。ただし、複数のクライアントまたはすべてのクライアントにわたってログを分析する場合もあります。このような場合、ほとんどのログはクライアントによってセグメント化されていますが、すべてのクライアントで共通するログもあります。たとえば、中央請求データベースは一般的です。その後、クライアント名に基づいてログ・セットを混在させ、CentralDBのログ・セットを持つことができます。