データ変換のスケジューリングと変換ルールエンジンの仕組み - Simple Log Service

Simple Log Service のデータ変換機能は、使用者グループを使用してログデータを消費します。200 以上のビルトイン関数を使用してデータを変換します。このドキュメントでは、データ変換中のログデータのスケジューリング方法と、変換ルールエンジンの仕組みについて説明します。

スケジューリングの原則

Simple Log Service のデータ変換機能は、使用者グループを使用して、ソース Logstore からのログデータをストリームとして消費します。各ログは変換ルールによって処理され、出力に送信されます。

スケジューリングメカニズム
各変換ルールに対して、データ変換サービスのスケジューラは 1 つ以上のインスタンスを開始します。各インスタンスは、ソース Logstore から 1 つ以上のシャードを消費します。スケジューラは、メモリと CPU の消費量に基づいて並列インスタンスの数を決定します。インスタンスの最大数は、ソース Logstore のシャード数と同じです。
実行中のインスタンス
インスタンスは、構成に基づいて割り当てられたシャードからソースログデータを読み取ります。次に、変換ルールを使用してデータを処理し、宛先の Logstore にデータを送信します。変換ルールは、外部リソースを使用したデータエンリッチメントをサポートします。インスタンスは、使用者グループのメカニズムを使用して、シャードの消費位置を保存します。これにより、予期せぬ停止の後でも、ブレークポイントから消費を再開できます。
タスクの停止
- タスクの終了時刻を構成しない場合、インスタンスはデフォルトで終了せず、変換タスクは停止しません。
- タスクの終了時刻を構成すると、構成された終了時刻までに受信したログの処理が完了した後、インスタンスは自動的に終了します。その後、変換タスクは停止します。
- 何らかの理由でタスクが停止した場合、再起動されると、デフォルトで最後に保存された位置から消費を再開します。

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

SLS 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)

対応するロジックグラフを以下に示します。

基本ロジック
ルール内の各関数は順番に実行されます。各関数はイベントを処理および変更し、処理されたイベントを返します。
たとえば、e_set("log_type", "access_log") は、各イベントに log_type という名前のフィールドを値 access_log で追加します。次の関数は、log_type フィールドが追加された後のイベントを受け取ります。
条件付きロジック
ステップに条件を設定できます。条件を満たさないイベントはこのステップをスキップします。
たとえば、e_if(e_search("ret: pass"), e_set("result", "pass")) は、まず ret フィールドに pass が含まれているかどうかを確認します。条件が満たされない場合、操作は実行されません。条件が満たされると、result フィールドの値が 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: access,alert
content: admin login to database.

対応するロジックグラフを以下に示します。 Rules engine principle logic diagram

イベントの出力
デフォルトの出力操作は、特殊なタイプの処理停止と見なすことができます。たとえば、ステップ 3 では、log_type フィールドの値が alert であるイベントに対して e_output("alert_Logstore") 関数が呼び出されます。この関数は、イベントを指定された宛先に出力してから、イベントを削除します。このイベントに対しては、後続の操作は実行されません。
イベントのコピーと出力
e_coutput 関数は、現在のイベントをコピーし、そのコピーを出力します。元のイベントは、後続のステップで引き続き処理されます。たとえば、ステップ 1 では、受信したすべてのログが archive_Logstore の宛先に出力されます。
分割と並列化
ステップ 2 で、log_type フィールドに access と alert の両方が含まれている場合、e_split("log_type") はイベントを 2 つのイベントに分割します。結果として得られる 2 つのイベントは、log_type フィールドの値がそれぞれ access と alert である点を除いて同一です。
分割された各イベントは、後続のステップで個別に処理され続けます。