データ変換機能は、コンシューマグループを使用してログデータを消費し、変換ルールを使用してログデータを変換します。 200を超える組み込み関数を使用して、変換ルールを調整できます。 このトピックでは、データ変換中にログデータの消費がどのようにスケジュールされるか、およびデータ変換のルールエンジンがどのように機能するかについて説明します。

スケジューリングの基本

Log Serviceのデータ変換機能は、コンシューマーグループを使用してソースLogstoreのログデータをストリーミングモードで消費し、指定された変換ルールに基づいて各ログエントリを変換し、変換されたログデータを1つ以上の宛先Logstoreに書き込みます。

  • スケジューリングメカニズム

    各変換ルールについて、データ変換スケジューラは、1つ以上の実行中のインスタンスを開始する。 実行中の各インスタンスは、ソースLogstoreの1つ以上のシャードからデータを消費するコンシューマーとして動作します。 スケジューラは、実行中のインスタンスによって使用されるメモリおよびCPUリソースに基づいて、同時実行中のインスタンスの数を決定します。 スケジューラーが開始できるインスタンスの最大数は、ソース Logstore 内のシャードの数と同じです。

  • 実行中のインスタンス

    実行中のインスタンスは、設定に基づいて割り当てられたシャードからソースログデータを読み取ります。 データは変換ルールに基づいて変換され、1つ以上の宛先ログストアに書き込まれます。 変換ルールを設定して、外部リソースを使用してログデータを強化できます。 コンシューマーグループメカニズムに基づいて、実行中のインスタンスはデータ消費チェックポイントをシャードに記録します。 チェックポイントは、消費が予期せず中断された場合に役立ちます。 中断が終了した後、実行中のインスタンスは最後のチェックポイントからデータを消費し続けることができます。

  • タスクの終了
    • デフォルトでは、変換タスクの終了時刻を設定しない場合、実行中のインスタンスは終了せず、タスクは停止しません。
    • 変換タスクの終了時間を設定すると、実行中のインスタンスは終了時間までログデータを消費します。 タスクが終了時間に達すると、インスタンスは終了し、タスクは停止します。
    • デフォルトでは、タスクを停止してから再起動すると、実行中のインスタンスは最後に記録されたチェックポイントのデータを消費し続けます。

ルールエンジンの基本: 基本操作

Log Serviceのドメイン固有言語 (DSL) で記述された組み込み関数を使用して、変換ルールを調整できます。 各関数は変換ステップである。 ルールエンジンは、変換ルールの関数を順番に呼び出します。 例えば、以下の変換規則は、4つの関数を使用することによって編成される。 関数は、データを変換するために使用される4つのステップです。 
e_set("log_type", "access_log")
e_drop_fields("__action")
e_if(e_search("ret: pass") 、e_set("result" 、"pass"))
e_if(e_search("ret: unknown") 、DROP)
次の図は、変換ロジックを示しています。
  • 基本ロジック

    Theルールエンジン通話各機能はで定義されたルールで。 各関数は、各ログエントリを処理および変更し、変換されたログエントリを返します。

    たとえば、e_set("log_type", "access_log") 関数は、log_typeフィールドを各ログエントリに追加します。 フィールドの値はaccess_logです。 Then、次機能受信各変換ログエントリ含まログ_タイプフィールド。

  • 条件式

    条件を段階的に設定できます。 ログエントリがステップ内の条件を満たさない場合、そのログエントリについてこのステップはスキップされる。

    たとえば、e_if(e_search("ret: pass"), e_set("result", "pass")) 関数は、まずログエントリのretフィールドの値にpassが含まれているかどうかをチェックします。 いいえの場合、ログエントリのこのステップはスキップされます。 はいの場合、関数はログエントリの結果フィールドの値をpassに設定します。

  • 変換終了

    関数が変換されたログエントリを返さない場合、ログエントリは破棄されます。

    たとえば、e_if(e_search("ret: unknown"), DROP) 関数は、retフィールドの値がunknownであるログエントリを破棄します。 ログエントリが破棄された後、ルールエンジンは、このログエントリを変換するための後続の関数をもはや呼び出さず、次のログエントリの変換を開始する。

ルールエンジンの基本: データ出力、複製、分割

ルールエンジンは、ログ出力、複製、および分割もサポートします。 例えば、以下の変換規則は、4つの関数を使用することによって編成される。 関数は、データを変換するために使用される4つのステップです。 
e_coutput("archive_Logstore")
e_split("log_type")
e_if(e_search("log_type: alert") 、e_output("alert_Logstore") )
e_set("result", "pass")
次の例は、変換されるサンプルログエントリです。 
log_type: アクセス、アラート
content: データベースへの管理者ログイン。
次の図は、変換ロジックを示しています。ルールエンジンの基本図
  • ログ出力

    ログ出力は、ログエントリの変換を停止する特別な方法と見なすことができます。 前の図に示すように、ログエントリのlog_typeフィールドの値がalertの場合、手順3のe_output("alert_Logstore") 関数が呼び出され、ログエントリが指定された宛先Logstoreに書き込まれます。 その後、ログエントリは破棄され、後続の関数は呼び出されません。

  • ログの複製と出力

    e_coutput関数は、ログエントリを複製し、複製されたログエントリを1つ以上の宛先ログストアに書き込みます。 次に、ルールエンジンは、ログエントリを変換するために後続の関数を呼び出し続ける。 前の図に示すように、手順1で複製されたログエントリは、archive_Logstoreという名前の宛先Logstoreに書き込まれます。

  • ログの分割

    ログエントリのlog_typeフィールドの値がaccessおよびalertの場合、手順2のe_split("log_type") 関数が呼び出され、ログエントリが2つのログエントリに分割されます。 2つのログエントリは、log_typeフィールドの値を除いて同じです。 フィールドの値は、ログエントリではaccessであり、他のエントリではalertです。

    分割後に生成されるログエントリは、後続の関数によって変換されます。