SPL を使用したコンテンツに基づく Logstore 間ログルーティング - SLS

データ配信では、データ変換タスクを使用して、事前に設定された構造化プロセス言語 (SPL) ルールに基づいてソースログを処理し、処理後のデータを 1 つ以上の宛先 Logstore に書き込みます。このプロセスは、異なるアカウントやリージョンをまたいだデータ書き込みをサポートします。Simple Log Service は、2 つの配信モードを提供します。

静的配信：宛先のプロジェクトと Logstore はタスク構成時に固定されます。このモードは最大 20 の出力先をサポートし、宛先 Logstore が不変であるシナリオに適しています。
動的配信：宛先アドレスは、ログ内の tenant_id、service、level などのビジネスフィールドに基づいて動的に生成されます。この生成されたアドレスは、静的に構成されたプロジェクトと Logstore を置き換えます。このモードは、宛先のプロジェクトと Logstore がビジネスログのコンテンツに基づいて命名されるシナリオに適しています。

コアメカニズム

動的配信は静的配信をバイパスするのではなく、フィールド値の置き換えによって静的配信の上に構築されます。

__tag__:__sls_etl_output_project__：静的に構成された宛先プロジェクトを置き換えます。
__tag__:__sls_etl_output_logstore__：静的に構成された宛先 Logstore を置き換えます。

したがって、動的配信における静的構成の役割は、最終的な書き込みパスではなく、実行コンテキスト (アカウント + リージョン + 権限) を提供することです。

説明

動的配信では、宛先リージョンやアカウント間の権限の境界を変更することはできません。これらの設定は、静的な宛先プロジェクトと Logstore に対して正しく構成する必要があります。

一般的なシナリオは次のとおりです。

マルチテナントのデータ隔離：Software as a Service (SaaS) プラットフォームが、テナント ID (tenant_id) に基づいて異なるテナントのログを個別に保存します。この分離により、その後のアクセス制御、課金、データ分析が簡素化されます。
環境ごとのログ配信：ログは、環境識別子 (prod、staging、dev) に基づいて、対応する環境の Logstore に自動的に配信されます。これにより、デバッグとモニタリングのワークフローが簡素化されます。
ビジネスモジュールごとの分類：注文、支払い、ユーザーなど、複雑なアプリケーション内の異なるビジネスモジュールからのログを、専用のストレージと分析のために別々の Logstore に配信します。

ソース Logstore データの準備

ソース Logstore に生ログが取り込まれており、ログにルーティングに必要なキーフィールドが含まれていることを確認します。

{
  "timestamp": "2025-04-05T10:00:00Z",
  "method": "POST",
  "uri": "/api/v1/orders",
  "status": 200,
  "tenant_id": "t-7a8b9c",
  "service": "order-service",
  "log_type": "access",
  "user_id": "u-12345"
}

主要なルーティングフィールド：

tenant_id：テナントの一意の識別子。この ID は、テナントレベルの隔離を実現するために宛先プロジェクトを決定します。
service：マイクロサービス名。この名前は、宛先 Logstore 名を構築するために使用されます。たとえば、システムに次のサービスが含まれているとします。
- user-service
- order-service
- payment-service
- auth-service

動的ルーティングのための SPL ルールの作成

Simple Log Service コンソールにログインします。
ソースプロジェクトの名前をクリックします。
左のナビゲーションウィンドウで、 [タスク管理] をクリックします。
[データ変換] タブで、[データ変換タスクの作成] をクリックし、ソース Logstore を選択して、[確認] をクリックします。
データの時間範囲を選択し、SPL ルールを入力します。

プロジェクトのみを動的に指定 (Logstore は固定)

このアプローチは、各テナントが同じ構造の Logstore を持つマルチテナンシープラットフォームに適しています。SPL ルールは次のとおりです。

* 
| extend "__tag__:__sls_etl_output_project__" = concat('saas-tenant-', tenant_id)
// 宛先 Logstore は静的構成の値 (例: 'access-log') を使用

SPL ルールをデバッグし、デフォルトの保存先を構成します。

[生ログ] で、ログデータを選択し、[テストデータに追加] をクリックします。
[テストデータ] タブで、[SPL のデバッグ] をクリックして [処理結果] を表示します。
変換結果が期待どおりの場合は、[データ変換を保存 (新規バージョン)] をクリックします。
[データ変換ジョブの作成 (新バージョン)] パネルで、ストレージ先を次のように設定します。
- [ターゲットリージョン] には、動的プロジェクトのリージョンを選択します。
- [ターゲットプロジェクト] には、リージョン内の既存のプロジェクトを選択できます。選択したプロジェクトは上書きされます。
- 指定された[宛先データベース]は上書きされません。
- 動的プロジェクトが存在し、それにアクセスする権限があることを確認してください。

配信結果を検証します。タスクが開始された後、各宛先 Logstore のデータをクエリして、ルーティングが期待どおりに機能していることを確認します。例：

入力ログの特性	実際の書き込み先
`tenant_id=t-7a8b9c`	プロジェクト： `saas-tenant-t-7a8b9c`、Logstore：指定された宛先 Logstore
`tenant_id=t-xyz123`	プロジェクト： `saas-tenant-t-xyz123`、Logstore：指定された宛先 Logstore

Logstore のみを動的に指定 (プロジェクトは固定)

このアプローチは、同じプロジェクト内でサービスやレベルごとにログを分類するのに適しています。SPL ルールは次のとおりです。

* 
| extend "__tag__:__sls_etl_output_logstore__" = concat(service,'-logs')
// 宛先プロジェクトは静的構成の値 (例: 'central-project') を使用

SPL ルールをデバッグし、デフォルトの保存先を構成します。

[Raw ログ] で、追加するログを選択し、[テストデータに追加] をクリックします。
[テストデータ] タブで、[SPL のデバッグ] をクリックして [変換結果] を表示します。
変換結果が期待どおりの場合は、[データ変換の保存 (新規)] をクリックします。
[データ変換タスクの作成 (新規)] パネルで、次のようにストレージ先を設定できます。
- ターゲットリージョン: 指定されたプロジェクトが配置されているリージョンです。
- 宛先プロジェクト: 指定された動的 Logstore を含むプロジェクトです。
- [宛先データベース] は、ターゲットプロジェクト内の既存の Logstore に設定できます。指定された Logstore 内のデータは上書きされます。

入力ログの特性	実際の書き込み先
`service=user-service`	プロジェクト： `Target Project` Logstore: `user-service-logs`
service=order-service	プロジェクト： `Target Project` Logstore: `order-service-logs`
`service=payment-service`	プロジェクト： `Target Project` Logstore: `payment-service-logs`
`service=auth-service`	プロジェクト： `Target Project` Logstore: `auth-service-logs`

プロジェクトと Logstore の両方を動的に指定

このアプローチは、ログのコンテンツによって完全に駆動される、完全に自動化されたルーティングシナリオに適しています。SPL ルールは次のとおりです。

*
-- 出力先のプロジェクトを動的に指定 (テナントごとに隔離) 
| extend "__tag__:__sls_etl_output_project__" = concat('saas-tenant-', tenant_id) 
-- 出力先の Logstore を動的に指定 (フォーマット: service-name-logs)
| extend "__tag__:__sls_etl_output_logstore__" = concat(service, '-logs')

SPL ルールをデバッグし、デフォルトの保存先を構成します。

[生ログ] で、ログを選択し、[テストデータに追加] をクリックします。
[テストデータ]タブで、[SPL のデバッグ]をクリックすると、[変換結果]が表示されます。
変換結果が正しい場合は、[データ変換を保存 (新規)] をクリックします。
[データ変換タスクの作成 (新規)] パネルで、ストレージ先を次のように設定します:
説明
すべてのフィールドが動的に上書きされる場合でも、デフォルトの保存先を構成する必要があります。この構成の目的は、フォールトトレランスのためではなく、以下を提供するためです。
- 宛先リージョン
- 実行ロール
- 対象リージョン：動的プロジェクトが存在するリージョンを選択します。
- [宛先プロジェクト] と [宛先 Logstore] は、指定されたリージョン内の既存のプロジェクトと Logstore のいずれかに設定できます。この操作により、選択した宛先のすべてのデータが上書きされます。
- 動的なプロジェクトと Logstore が存在し、それらにアクセスする権限があることを確認してください。

配信結果を検証します。タスクが開始された後、各宛先 Logstore のデータをクエリして、ルーティングが期待どおりに機能していることを確認します。

この方法では、tenant_id と service フィールドに基づいて、自動的なマルチテナントのログ隔離が実現されます。同じテナントからのログは同じプロジェクトに保存され、その後 service フィールドに基づいて異なる Logstore にルーティングされます。例：

入力ログの特性

実際の書き込み先

tenant_id=t-1001、service=user-service

プロジェクト： saas-tenant-t-1001

Logstore: user-service-logs

tenant_id=t-1002、service=payment-service

プロジェクト： saas-tenant-t-1002

Logstore: payment-service-logs