トラブルシューティングリファレンス

このページでは、スケジュールに関する一般的な問題と、そのデバッグ手順を説明します。

スケジュールされたビルドの問題

スケジュールメトリクスページ

スケジュールの問題のトラブルシューティングを始めるには、スケジュールメトリクスページを確認するのが有効な方法の1つです。メトリクスページでは、失敗の原因を確認できます。一般的な失敗には、次のようなものがあります。

• スケジュールされたビルドに失敗している。実行履歴タブに、ビルドに失敗したことが表示されます。これらのビルドを選択すると、Builds アプリケーションのビルドレポートに移動し、完全なログを確認できます。
• スケジュールされたビルドが無視された。トリガーされたもののビルドされなかったビルドについては、実行履歴タブのステータス列に「無視」と表示されます。
• 期待した時刻または頻度でスケジュールがトリガーされなかった。この場合、実行履歴タブには、期待したタイミングでビルドがトリガーされたことが表示されない場合があります。

もう1つの便利なタブは、過去のスケジュールのバージョンと編集内容を表示するバージョンタブです。スケジュールの動作が突然期待と異なるようになった場合は、その動作の変化と同じタイミングでスケジュールのバージョンに変更がなかったかを確認し、以前正常に動作していた状態にスケジュールを戻すことを検討してください。

スケジュールされたビルドに失敗している

スケジュールメトリクスページの実行履歴タブで、スケジュールが期待した時刻にトリガーされたかどうかを確認できます。

スケジュールがトリガーされたものの、その後ビルドに失敗した場合は、ほかのビルドと同様に、Builds アプリケーションでこのビルドをデバッグできます。

適切な権限が設定されていない場合も、スケジュールによるビルドに失敗します。スケジュールの権限は、そのスケジュールのトークンモードによって異なります。プロジェクトスコープのスケジュールについて詳しくはこちら。

スケジュールされたビルドが無視された

スケジュールメトリクスページの実行履歴タブで、スケジュールが期待した時刻にトリガーされたかどうかを確認できます。通常、この情報にはスケジュールが無視された理由が示されます。

すべてのデータセットが最新

対象のデータセットがすべて最新の場合（つまり、そのデータセットの前回のビルド以降、入力が更新されていない場合）、スケジュールの実行は無視されます。この場合、実行履歴タブにその理由が表示されます。スケジュールエディターで、スケジュール一覧に移動します。そこで、Data Lineage グラフを「最新ではない」に基づいて色分けするオプションを選択でき、どの Job Spec が最新ではないとみなされているかを把握できます。

特別な状況では、詳細設定の強制 Build オプションを使用して、この動作をオーバーライドできます。ただし、それ以外の状況では計算リソースを無駄に消費します。対象のデータセットのいずれかが Object Storage v1（Phonograph）の同期、API 呼び出しを伴うトランスフォーム、または Data Connection の同期によってビルドされる場合、それらは最新ではないと表示されないことがあり、スケジュールを実行するには強制 Build オプションを有効にする必要がある場合があります。

スケジュールが一部の Job Spec をビルドする

スケジュールが一部の Job Spec のみをトリガーする場合、スケジュールメトリクスページの実行履歴タブでそのことを確認できます。

この動作の原因の1つは、一部の Job Spec のみが最新ではなかったことです。スケジュールは最新ではない Job Spec のみをビルドし、最新のものはビルド中に無視されます。トラブルシューティングの詳細については、すべてのデータセットが最新を参照してください。これらの Job Spec がすべて最新の場合、ビルドは「無視」になります。

もう1つの原因として、Job Spec がビルドの Job Spec グラフに含まれていなかった可能性があります。スケジュールエディターで特定のスケジュールを選択すると、ビルド対象の Job Spec が Data Lineage グラフで強調表示されます。Job Spec の選択は、ビルドの種類によって異なります。二点間 Build を使用している場合は、複数のブランチで同じデータセットを使用するスケジュールについて、接続する Job Spec が存在するかを必ず確認してください。

スケジュールがトリガーされなかった

スケジュールメトリクスページの実行履歴タブで、スケジュールが期待した時刻にトリガーされたかどうかを確認できます。一般的なデバッグ手順には、次のようなものがあります。

• スケジュールが一時停止されていないことを確認します。一時停止中のスケジュールは、一時停止が解除されるまでトリガーされません。
• スケジュールのトリガー設定を確認します。以前はスケジュールが正常にトリガーされていた場合は、スケジュール履歴を確認して、最近トリガーに変更がなかったかを調べます。
• スケジュールがイベントトリガーを使用している場合は、期待されるイベントが実際に発生したことを確認します。
  • たとえば、入力が更新されたときにビルドがトリガーされるはずの場合は、入力の前回のビルドが正常に実行され、そのビルドのトランザクションが正常にコミットされたことをデータセットプレビューの履歴表示で確認します。
  • 複数の入力が更新された後にビルドがトリガーされるはずの場合は、すべての入力のビルドとタイミングを確認します。たとえば、入力トリガー A1 と A2 があり、「これらすべてのデータセットが更新されるまで待機」がオンになっているスケジュールを考えます。このスケジュールが前回、時刻 T1 に実行されたとします。このスケジュールが時刻 T2 に再び実行されるには、A1 と A2 の両方が (T1, T2) の期間内に更新される必要があります。
    
    
    
    

スケジュールの再試行が設定と異なる

すべての種類の失敗で再試行できるわけではありません。スケジュール実行時の再試行回数は、管理者が設定した最大回数に制限されます。スケジュールの詳細設定について詳しくはこちら。

再試行可能なエラーコードは次のとおりです。

• INTERNAL
• TIMEOUT
• CUSTOM_SERVER
• FAILED_PRECONDITION

JobSpecInputsTrashed または JobSpecOutputsTrashed でスケジュールに失敗する、または Data Lineage が一部のデータセットがゴミ箱にあると警告する

このエラーは、スケジュールにゴミ箱にあるリソースが含まれているか、そのリソースから読み取っていることを意味します。解決するには、次のいずれかを行います。

• 削除されたデータセットをゴミ箱から復元します。
• 削除されたデータセットをスケジュールから除外します。このデータセットが、スケジュール内の別の下流データセットの入力として使用されている場合は、次のいずれかも行う必要があります。
  • ゴミ箱にあるデータセットとともに、下流データセットも除外します。
  • 下流データセットのロジックを変更して、ゴミ箱にあるデータセットを入力として使用しないようにします。

スケジュールエディターの問題

スケジュールの権限

プロジェクトスコープモードでスケジュールを編集するには、対象データセットに対する編集者権限、トリガーデータセットに対する閲覧者権限、およびスケジュールのスコープとなるプロジェクトに対する編集者権限が必要です。データセットの権限を失った場合は、変更を保存する前に、そのデータセットをスケジュールから外してください。

スケジュールを編集、削除、または一時停止するには、対象データセットに対する編集者権限と、スケジュールのスコープとなるプロジェクトに対する編集者権限が必要です。スケジュールを閲覧するには、対象データセットに対する閲覧者権限が必要です。

スケジュールのコンピュート情報は利用できません

スケジュールを閲覧すると、次のいずれかの理由で「一部のコンピュート情報が利用できません。実際のコンピュート使用量は、表示されている使用量よりも多い可能性があります。」というメッセージが表示されることがあります。

• スケジュールされたビルドが1つ以上まだ進行中で、合計コンピュート使用量がまだ確定していません。
• スケジュールされたビルドのうち1つ以上について、使用されたリソースの情報がありません。

このメッセージが表示されても、ユーザーによる操作は必要ありません。このメッセージは、その時点で表示されている合計コンピュート使用量が不正確である可能性を示すためのものです。