ユース・ケースには複数のライン・オブ・ビジネス(LOB)があり、ログ・アナリティクス・ユーザーは通常、一度に1つのLOBのログのみを分析し、場合によっては複数のLOBまたはすべてのLOBで検索します。

このシナリオでは、各LOBに1日当たり常に6TBのログが下にある場合、業種に合せたログ・セット文字列を使用するのに適しています。たとえば、HR、グローバルIT、財務、出荷、オーダー、セキュリティなどのログ・セットです。

単一のLOBがログ収集の1日当たり6TB以上到達できる場合、ログ・セットは、ログの取得元のLOBのファンクションのタイプなど、2次的な側面に基づいて定義できます。たとえば、グローバルIT LOBでは、ログ・セットとしてグローバルITを使用するのではなく、1日当たり20TBのログを取り込むことが想定される場合、GIT-Database、GIT-Mail、GIT-Supportをログ・セット値として使用することをお薦めします。

ログ・セットの選択の鍵は、データの通常分析方法に合せることです。通常、GIT-Mailログが他のログを混在させずに単独で分析される場合、このログ・セットが適しています。GIT-DatabaseとGIT-Supportを常に同じ検索に組み合せる場合、それらを異なるログ・セットとして持つことは適切ではありません。

ユースケースには、クライアントの数に基づいてスケーリングする水平方向にスケーラブルなクラウド製品の実行が含まれる場合があります。

たとえば、各クライアントのクラウド・サービスの使用に一連の計算、データベースおよびネットワークが必要な場合、ログ・セットを編成する適切な方法は、クライアント名またはクライアント識別子を使用してこれらのクライアントを使用することです。この情報はアクセス可能で、特定のクライアントのログを検索するユーザーが理解できる必要があります。このような場合、クライアントC1、C2、C3がある場合、これらは各クライアントからのログに使用するログ・セット文字列になります。

通常、問題をデバッグする場合、運用チームはサポートの一部として特定のクライアントのログを検索します。ただし、複数のクライアントまたはすべてのクライアントでログを分析する場合もあります。このような場合、ほとんどのログがクライアントによってセグメント化されていても、すべてのクライアントで共通するいくつかのログが存在する可能性があります。たとえば、中央請求データベースが一般的です。その後、クライアント名に基づいてログ・セットを混在させ、CentralDBのログ・セットを設定できます。