データ変換タスクが開始されると、変換結果はルーティングルールに基づいて送信先 Logstore に送信されます。タスクが失敗した場合、たとえば、送信先 Logstore にログが生成されない、または大幅な遅延が発生した場合、本トピックでは、これらの問題のトラブルシューティング方法を説明します。
エラー分析
エラーが発生した場合、どの段階でエラーが発生したかを特定することで、より効率的に問題を突き止めることができます。
「仕組み」にあるように、データ変換タスクは主に 4 つの段階で構成されています。
エラーはこれらのいずれの段階でも発生する可能性があります。原因、影響、およびトラブルシューティング方法は、段階ごとに異なります。
データ変換エンジンの起動
この段階のエラーは、主にデータ変換エンジンが起動時に DSL ルール内の問題を検出し、内部セキュリティチェックに失敗すると発生します。
この段階でエラーが発生すると、データ変換タスクは停止します。DSL ルールを修正し、タスクを再起動する必要があります。再起動が成功すると、タスクはデータ損失やデータの冗長性を発生させることなく、正常な動作を再開します。
この段階でのエラーのトラブルシューティング方法については、「データ変換エンジンの起動エラー」をご参照ください。
ソース Logstore からのデータ読み取り
この段階のエラーは、ソース Logstore へのアクセス問題が原因で発生することがあり、これは設定ミス、ネットワークの問題、または Logstore 設定の変更に起因します。
データ変換タスクは、成功するか手動で停止されるまで、継続的に再試行します。成功すると、タスクはデータ損失なく正常な動作を再開します。
一部のデータがすでに読み取られた後にエラーが発生した場合、サービスはチェックポイントを保存し、再試行を続けます。再試行が成功すると、チェックポイントから読み取りを継続するため、データ損失や重複を防ぐことができます。再試行プロセス中にタスクが停止した場合でも、データは失われたり重複したりすることはありません。
この段階でのエラーのトラブルシューティング方法については、「ソース Logstore の読み取りエラー」をご参照ください。
ログイベントの変換
この段階でのエラーは、主に一部またはすべてのログイベントが変換ルールと互換性がない場合に発生します。
この段階では、変換ルールと互換性のないログイベントによってエラーが引き起こされます。エラーは
WARNINGレベルまたはERRORレベルに分類され、これは処理ログのlogging.levelnameフィールドで示されます。ERRORレベルのエラーの場合、対応するログイベントは破棄され、変換後の出力には含まれません。WARNINGレベルのエラーの場合、たとえばイベントが正規表現ルールに一致しない場合、そのイベントに対して現在の DSL ステップはスキップされ、処理は次のステップに進みます。
この段階でのエラーのトラブルシューティング方法については、「変換ルールエラー」をご参照ください。
送信先 Logstore へのエクスポート
この段階のエラーは、送信先 Logstore へのアクセス問題が原因で発生することがあり、これは設定ミス、ネットワークの問題、または Logstore 設定の変更に起因します。
データ変換タスクは、成功するか手動で停止されるまで、継続的に再試行します。成功すると、タスクはデータ損失なく正常な動作を再開します。
一部のデータがすでにエクスポートされた後にエラーが発生した場合、たとえば 2 つの送信先があり、一方が成功し、もう一方が失敗した場合、タスクはチェックポイントを保存し、再試行を続けます。再試行が成功すると、データは失われたり重複したりすることはありません。ただし、このプロセス中にタスクを停止して再起動すると、最後のチェックポイントから再開されます。この場合、データ損失は発生しませんが、データの冗長性が発生する可能性があります。
この段階でのエラーのトラブルシューティング方法については、「送信先 Logstore の書き込みエラーのトラブルシューティング」をご参照ください。
一般的なトラブルシューティング
データが送信先 Logstore に書き込まれていることを確認します。
データが最近送信先 Logstore に書き込まれたかどうかを確認するには、送信先 Logstore の [消費プレビュー] ページでデータを表示します。
説明Logstore を直接クエリした場合、次の理由で正確でない場合があります：
データ変換は、受信時間に基づいてログを処理します。履歴ログを処理する場合、その書き込み時間がクエリの時間範囲内に収まらない可能性があります。
履歴ログはインデックスが作成された後にのみクエリできますが、これには通常数分かかります。したがって、履歴ログを書き込むタスクからのデータは、すぐにクエリできない場合があります。
データ変換タスクのステータスを確認します。
タスクの進行状況を確認して、開始されているかを確認します。詳細については、「データ変換タスクのステータス表示」をご参照ください。固定の時間範囲を持つタスクは、終了時刻に達すると自動的に停止します。
タスクに関連付けられているコンシューマーグループを確認します。有効であり、ステータスが更新されていることを確認してください。
[コンシューマーグループステータス] ページで、各シャードの [最終データ消費時間] 列を確認し、タイムスタンプが更新されているかを確認します。タイムスタンプが変更されない場合、コンシューマーグループは期待どおりにデータを消費していません。
ソース Logstore がデータを生成しているかを確認します。
データ変換タスクの時間範囲内に、ソース Logstore にログが存在することを確認します。
終了時刻が設定されていない場合は、ソース Logstore で新しいログが生成されているかを確認します。指定された時間範囲に新しいログも履歴ログもない場合、データ変換タスクは続行できません。
履歴時間範囲を選択した場合は、その範囲内にソース Logstore にログが存在することを確認します。
タスクの データ変換タスクの変換ルールを変更 をクリックし、関連する時間範囲を選択して、生ログが存在するかを確認します。
変換ルールに問題がないか確認します。
変換ルールに問題を引き起こす可能性のあるコードがないか確認します。例：
ルールがログ時刻を変更し、ログがクエリの時間範囲外になる。
変換ルールが特定の条件下でログを破棄する。
例えば、次のコードは
nameフィールドが存在しない、または空である場合に、すべてのログを破棄します。このnameフィールドは先行するロジックによって作成されます。このため、先行するロジックに問題がありnameフィールドが正しく作成されないと、ログは生成されません。# .... 先行するロジック。 # .... name フィールドを構築... e_keep(e_search('name: "?"'))ロジックがエンリッチメントのためにサードパーティのソースからデータをプルする場合、サードパーティのデータセットが大きすぎないか確認します。これにより、データ変換タスクがデータを消費し始める前に、長時間初期化状態のままになる可能性があります。例：
e_dict_map(res_rds_mysql(..database="userinfo", table="user"), "username", ["city", "school", "age"])
タスクの データ変換タスクの変換ルールを変更 をクリックし、時間範囲を選択してから、[データプレビュー] をクリックして結果を表示します。
問題を再現できる場合は、特定のステートメントをコメントアウトして結果を再度プレビューすることで、デバッグできます。
シャード数が要件を満たしていることを確認します。
データ変換が遅すぎると感じた場合は、ソース Logstore と送信先 Logstore の設定がパフォーマンス要件を満たしているかをご検討ください。ソース Logstore または送信先 Logstore のシャード数を調整することを推奨します。
エラーログの表示
次の方法でエラーログを表示できます：
Logstore
internal-etl-logでデータを表示できます。データ変換タスクによって生成されたログは、Logstore
internal-etl-logに保存されます。この Logstore は、データ変換タスクが実行された後、システムによって自動的に作成されます。internal-etl-logは、無料の専用 Logstore です。その設定を変更したり、他のデータを書き込んだりすることはできません。internal-etl-logでは、各ログイベントの__topic__フィールドにデータ変換タスクのステータスが表示されます。このフィールドを使用して、対応するデータ変換タスクでエラーが発生したかどうかを判断できます。以下の例に示すように、各ログイベントの
messageフィールドとreasonフィールドで具体的なエラー情報を確認できます。1 07-24 17:16:24 __source__: 172.20.3.39 __tag__:__job_name__: etl-1563959389-739231 __tag__:__schedule_id__: f474510ad3c7e4c233995018c95b32d6 __tag__:__schedule_type__: Resident __topic__: __etl-log-status__ event_id: transorm_data:put_logs:fail logging: {} funcName: "put_logs_auto_div" processName: "MainProcess" thread: "140066601039616" threadName: "ThreadPoolExecutor-0_1" process: "1" levelname: "WARNING" module: "logclient_operator" message: transorm_data: fail to send event to endpoint eu-west-1-intranet.log.aliyuncs.com:80, project ali-licheng-test-uk2, logstore sdasda, detail: {"errorCode": "LogStoreNotExist", "errorMessage": "logstore sdasda does not exist", "requestId": "5D3821E8956DED973F2B500A"} reason: transorm_data: fail to send event to endpoint eu-west-1-intranet.log.aliyuncs.com:80, project ali-licheng-test-uk2, logstore sdasda, detail: {"errorCode": "LogStoreNotExist", "errorMessage": "logstore sdasda does not exist", "requestId": "5D3821E8956DED973F2B500A"}
ダッシュボードでエラーを表示
対象のデータ変換タスクをクリックし、[データ変換概要] ページの [実行ステータス] エリアでダッシュボードを表示します。
詳細なエラーメッセージは、例外の詳細の
reason列にあります。「例外詳細」ページの
reason列には、具体的なエラーメッセージが表示されます。 たとえば、error occur when create consumer group, errorCode: Unauthorized, errorMessage: AccessKeyId not found:は、AccessKeyIdが見つからなかったためにコンシューマーグループの作成中に認証が失敗したことを示しています。コンソールでエラーを表示
Log Service コンソールは、プレビューフェーズのエラーログを直接表示します。プレビューフェーズは、変換ルールの操作をシミュレートし、ソース Logstore や送信先 Logstore に実際の変更を加えることなく、期待される結果を表示します。したがって、プレビューフェーズで発生したエラーは、ソースログイベントに影響を与えません。
プレビューの制限
プレビューフェーズでのデータ変換には、実際のデータ変換タスクと比較していくつかの制限があります。
プレビューフェーズでは、ソース Logstore の認証情報に関する権限の問題を検出できません。
プレビューフェーズでは、データを消費するためのコンシューマーグループを作成しないため、コンシューマーグループの権限はチェックされません。
プレビューフェーズでは、変換ルール内の無効な送信先名を検出できません。
プレビューフェーズでは、送信先への実際の書き込み操作を実行しないため、設定された送信先が存在するかはチェックされません。
プレビューフェーズでは、送信先の設定エラーを検出できません。
これには、送信先のプロジェクト、Logstore、または AccessKey の権限の設定ミスが含まれます。
プレビューフェーズでは、送信先への実際の書き込み操作を実行しないため、送信先の構成が正しいかはチェックされません。
プレビューはすべてのデータをカバーしません。
デフォルトでは、プレビューフェーズは変換のためにソース Logstore から 1,000 件のログイベントのみをプルします。
最初の 1,000 件のログイベントで変換結果が生成されない場合、サービスは結果が生成されるまで最大 5 分間データをプルし続けます。