Simple Log Service (SLS) トリガーは、新しいログが生成されたときに関数を自動的に呼び出すことで、SLS と Function Compute を統合します。SLS トリガーを使用して、SLS Logstore 内のデータを増分消費し、カスタム処理タスクを実行します。
ユースケース
データクレンジングと処理
SLS を使用して、ログを迅速に収集、処理、クエリ、分析します。
データ転送
ログデータをクラウド上のビッグデータ製品やサードパーティサービスなどの宛先に転送し、それらの間にデータパイプラインを構築します。
仕組み
SLS トリガーは Function Compute の 1 つの SLS ETL ジョブに対応します。SLS ETL ジョブを作成すると、SLS は ETL ジョブ設定に基づいてタイマーを開始します。タイマーは Logstore のシャード情報をポーリングします。新しいデータが書き込まれると、SLS は関数イベントとして <shard_id, begin_cursor, end_cursor> のトリプレットを生成し、関数を呼び出します。
ストレージシステムがアップグレードされると、新しいデータが書き込まれていなくてもカーソルの変更が発生する場合があります。この場合、各シャードはデータなしでさらに 1 回トリガーされます。関数内のカーソルを使用してシャードデータの取得を試みることができます。データが返されない場合、その呼び出しは空のトリガーのため、関数内で無視できます。詳細については、「カスタム関数開発ガイド」をご参照ください。
トリガーメカニズムは時間ベースです。たとえば、ETL ジョブのトリガー間隔を 60 秒に設定し、データが Logstore の Shard0 に継続的に書き込まれる場合、シャードは 60 秒ごとに関数呼び出しをトリガーします。シャードに新しいデータが書き込まれない場合、呼び出しはトリガーされません。各呼び出しの入力は、過去 60 秒間のカーソル範囲です。関数では、カーソルに基づいて Shard0 データを読み取り、さらに処理できます。
トリガーの頻度には、次の特徴があります。
各シャードは個別にトリガーされます。Logstore で確認できる呼び出しの総数は多く見えるかもしれませんが、各シャードの実際のトリガー時間は設定された間隔と一致します。たとえば、Logstore に 10 個のシャードがある場合、トリガーの遅延なしでリアルタイムデータ処理を行うと、60 秒ごとに 10 回の関数呼び出しが発生します。
単一シャードのトリガー間隔は、毎回処理されるデータの時間範囲と同じです。トリガー間隔が 60 秒であると仮定します。関数が実行されると、トリガー間隔は次の 2 つのケースに分類されます。
トリガー遅延なし: 関数はスケジュールどおりに 60 秒ごとにトリガーされ、処理されるデータ範囲は
[now -60s, now)です。トリガーの遅延:SLS シャードの現在の処理位置が、最新の書き込みデータより 10 秒以上遅れている場合に発生します。トリガーは追いつこうとし、2 秒に 1 回起動することがあります。各呼び出しは、引き続き 60 秒のウィンドウを処理します。
データ処理関数
SLS トリガーが呼び出す関数は、次のいずれかのタイプになります。
テンプレート関数
詳細については、「aliyun-log-fc-functions」をご参照ください。
カスタム関数
設定形式は、関数の実装方法によって異なります。詳細については、「ETL 関数開発ガイド」をご参照ください。
前提条件
Function Compute
Simple Log Service (SLS)
1 つのプロジェクトと 2 つの Logstore を作成します。1 つの Logstore は収集されたログを保存します。Function Compute は増分ログをトリガーとして使用するため、ログがこの Logstore に継続的に収集されるようにしてください。もう 1 つの Logstore は、SLS トリガーによって生成されたログを保存します。
ステップ1:SLS トリガーの作成
SLS トリガーを設定して、更新されたデータを定期的に取得し、関数を呼び出して SLS Logstore 内のデータを増分消費できます。関数では、データクレンジングや処理などのカスタム処理タスクを実行し、サードパーティサービスにデータを配信します。この例では、ログデータを取得して出力する方法のみを示します。データ処理に使用される関数は、SLS が提供するテンプレートまたはカスタム関数のいずれかです。次の手順では、カスタム関数を使用します。
Function Compute コンソールにログインします。左側のナビゲーションペインで、[Functions] > [Functions] を選択します。
上部のナビゲーションバーで、リージョンを選択します。[Functions] ページで、対象の関数をクリックします。
[Function Details] ページで、[Triggers] タブをクリックし、[Create Trigger] をクリックします。[Create Trigger] パネルで、[Trigger Type] を [Log Service] に設定し、その他のパラメーターを設定して [OK] をクリックします。
| パラメーター | 説明 | 例 |
| 名前 | トリガーのカスタム名。このパラメーターを空白のままにすると、Function Compute が自動的にトリガー名を生成します。 | log_trigger |
| バージョンまたはエイリアス | デフォルト値:[LATEST]。別のバージョンまたはエイリアスのトリガーを作成するには、まず [Function Details] ページの右上隅でそのバージョンまたはエイリアスに切り替えます。バージョンとエイリアスの概要については、「バージョンの管理」および「エイリアスの管理」をご参照ください。 | LATEST |
| Log Service プロジェクト | 消費する SLS プロジェクト。 | aliyun-fc-cn-hangzhou-2238f0df-a742-524f-9f90-976ba457**** |
| Logstore | 消費する Logstore。トリガーは、この Logstore 内のデータを定期的にサブスクライブし、カスタム処理のために関数にデータを配信します。 | function-log |
| トリガー間隔 | SLS が関数を呼び出す間隔。値の範囲:[3,600]。単位:秒。デフォルト値:60。 | 60 |
| 再試行 | 1 回のトリガーで許可される最大再試行回数。値の範囲:[0,100]。デフォルト値:3。 説明 呼び出しは、 | 3 |
| トリガーログ | 既存の Logstore を選択します。SLS が関数を呼び出すときに生成されるログは、この Logstore に記録されます。 | function-log2 |
| 呼び出しパラメーター | parameterカスタムパラメーターを渡すには、ここで設定します。値は、イベントの フィールドとして関数に渡されます。値は JSON 形式の文字列である必要があります。デフォルト値:なし。 | なし |
| ロール名 | [AliyunLogETLRole] を選択します。 説明 このタイプのトリガーを初めて作成する場合は、[OK] をクリックし、表示されるダイアログボックスで [Authorize Now] を選択します。 | AliyunLogETLRole |
トリガーが作成されると、[Triggers] タブに表示されます。トリガーを変更または削除するには、『Function Compute User Guide』の「Manage Triggers」をご参照ください。
ステップ2:権限の設定
関数ロールは、関数が呼び出されるときに必要な SLS 権限を提供します。
[Function Details] ページで、[Configurations] タブをクリックします。[Advanced Settings] セクションで、[Modify] をクリックします。[Advanced Settings] パネルで、[Function Role] を選択します。
関数がログデータの読み取りのみを行う場合は、デフォルトで SLS の読み取り専用権限を持つデフォルトロール [AliyunFCServerlessDevsRole] を使用できます。
関数が SLS への読み取り専用以上の権限を必要とする場合は、次の 2 つの要件を満たすカスタム RAM ロールを作成します。
a. RAM ロールを作成するときは、[Select Trusted Entity] を [Alibaba Cloud Service] に設定し、[Trusted Service] を [Function Compute] に設定します。詳細については、「信頼できる Alibaba Cloud サービス用の RAM ロールを作成」をご参照ください。
b. RAM ロールに、関数が必要とする SLS 権限を付与します。詳細については、「カスタム RAM ポリシーの例」をご参照ください。
[Deploy] をクリックします。
ステップ3:関数のデプロイとログの表示
[Function Details] ページの [Code] タブで、コードエディターにコードを記述し、[Deploy] をクリックします。
この例では、次の処理を行う Python 関数をデプロイします。
eventから、endpoint、projectName、logstoreName、beginCursorなどの SLS イベント情報を取得します。contextから認証情報accessKeyId、accessKeySecret、およびsecurityTokenを取得します。取得した情報に基づいて SLS クライアントを初期化します。
ソース Logstore から指定されたカーソル位置のログデータを取得します。
次のサンプルコードは、ほとんどのログ処理シナリオの開始テンプレートとして使用できます。
""" このサンプルコードは、主に次の処理を実行します。 * イベントから SLS 処理関連情報を取得 * SLS クライアントを初期化 * ソース Logstore からログをプル """ import logging import json from aliyun.log import LogClient logger = logging.getLogger() def handler(event, context): # アクセスキーは context.credentials から取得できます print("The content in context entity is: ", context) creds = context.credentials access_key_id = creds.access_key_id access_key_secret = creds.access_key_secret security_token = creds.security_token # イベントをオブジェクトにパースします event_obj = json.loads(event.decode()) print("The content in event entity is: ", event_obj) # event.source からログプロジェクト名、Logstore 名、SLS のエンドポイント、開始カーソル、終了カーソル、shardId を取得します source = event_obj['source'] log_project = source['projectName'] log_store = source['logstoreName'] endpoint = source['endpoint'] begin_cursor = source['beginCursor'] end_cursor = source['endCursor'] shard_id = source['shardId'] # SLS のクライアントを初期化します client = LogClient(endpoint=endpoint, accessKeyId=access_key_id, accessKey=access_key_secret, securityToken=security_token) # この例では、カーソル [begin_cursor, end_cursor) 内のソース Logstore からデータを読み取ります。これには、呼び出しをトリガーしたすべてのログが含まれます while True: response = client.pull_logs(project_name=log_project, logstore_name=log_store, shard_id=shard_id, cursor=begin_cursor, count=100, end_cursor=end_cursor, compress=False) log_group_cnt = response.get_loggroup_count() if log_group_cnt == 0: break logger.info("get %d log group from %s" % (log_group_cnt, log_store)) logger.info(response.get_loggroup_list()) begin_cursor = response.get_next_cursor() return 'success'[Function Details] ページで、[Logs] > [Function Logs] を選択して、関数の実行時に取得された最新のデータを表示します。「The logging feature is not enabled for the current function.」と表示された場合は、[Enable] をクリックします。
これで、SLS トリガーの設定は完了です。トリガー間隔が経過し、新しいデータがソース Logstore に書き込まれると、トリガーが関数を呼び出し、関数ログが [Function Logs] ページに表示されます。ステップ1で [トリガーログ] パラメーターに指定した Logstore を確認して、トリガーが起動したかを確認することもできます。コンソールでコードをデバッグするには、次の手順を実行します。
(オプション) ステップ4:シミュレートされたイベントでの関数のテスト
[Function Details] ページの [Code] タブで、[Test Function] の右側にある
アイコンをクリックし、ドロップダウンリストから [Configure Test Parameters] を選択します。[Configure Test Parameters] パネルで、[Create New Test Event] または [Modify Existing Test Event] を選択し、イベント名とイベント内容を入力してから [OK] をクリックします。新しいテストイベントを作成する場合は、[Log Service] イベントテンプレートを選択することを推奨します。テストデータの詳細については、「
eventパラメーター」をご参照ください。シミュレートされたイベントを設定した後、[Test Function] をクリックします。
呼び出しが完了すると、[Code] タブの上に結果が表示されます。
制限事項
単一のプロジェクトに設定できる SLS トリガーの数は、そのプロジェクトに存在する Logstore の数の 5 倍を超えることはできません。
各 Logstore につき、5 つ以下の SLS トリガーを設定してください。そうしないと、Function Compute へのデータ転送の効率に影響を及ぼす可能性があります。
入力パラメーター
context
Function Compute が関数を実行する際に、コンテキストオブジェクトを関数の context 入力パラメーターに渡します。このオブジェクトには、呼び出し、サービス、関数、および実行環境に関する情報が含まれています。
このトピックでは、context.credentials を使用して認証情報を取得します。利用可能なフィールドの詳細については、「コンテキスト」をご参照ください。
event
SLS トリガーが起動すると、イベントデータがランタイムに渡されます。ランタイムは、このデータを JSON オブジェクトに変換して、関数の event 入力パラメーターに渡します。形式は次のとおりです:
{
"parameter": {},
"source": {
"endpoint": "http://cn-hangzhou-intranet.log.aliyuncs.com",
"projectName": "fc-test-project",
"logstoreName": "fc-test-logstore",
"shardId": 0,
"beginCursor": "MTUyOTQ4MDIwOTY1NTk3ODQ2Mw==",
"endCursor": "MTUyOTQ4MDIwOTY1NTk3ODQ2NA=="
},
"jobName": "1f7043ced683de1a4e3d8d70b5a412843d81****",
"taskId": "c2691505-38da-4d1b-998a-f1d4bb8c****",
"cursorTime": 1529486425
}| パラメーター | 説明 |
parameter | トリガー作成時に指定する呼び出しパラメーターの値。 |
source | 関数が読み取るログブロックに関する情報。 説明
|
jobName | SLS ETL ジョブの名前。関数に設定された SLS トリガーは、1 つの SLS ETL ジョブに対応します。このパラメーターは Function Compute によって自動的に生成されるため、設定する必要はありません。 |
taskId | taskIdETL ジョブの場合、 は関数呼び出しを一意に識別するものです。このパラメーターは Function Compute によって自動的に生成されるため、設定する必要はありません。 |
cursorTime | 最後のログが SLS サーバーに到着したときの Unix タイムスタンプ。単位:秒。 |
よくある質問
SLS トリガーが関数を呼び出す頻度が想定より高くなることがあるのはなぜですか?
各シャードは個別にトリガーされるため、Logstore 全体の呼び出し総数は設定された間隔よりも多く見えることがあります。各シャードの実際のトリガー頻度は、依然として間隔と一致します。トリガー頻度の動作の詳細については、「仕組み」をご参照ください。
denied by sts or ram, action: log:GetCursorOrData, resource: ****
このエラーが関数ログに表示される場合、関数に権限が設定されていないか、アクセスポリシーが正しくないことが原因の可能性があります。「ステップ2:権限の設定」をご参照ください。
新しいログが生成されても SLS トリガーが関数を呼び出さない場合の対処方法
次の点を確認してください。
Function Compute トリガータスクに設定された Logstore に増分データ変更が存在するかどうかを確認してください。関数は、シャードデータが変更されたときに呼び出されます。
トリガーログと関数の実行ログに例外がないか確認してください。トリガーログは、ステップ1で [トリガーログ] パラメーターに指定した Logstore に保存されます。