スケジュールのトラブルシューティング

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

スケジュール問題のトラブルシューティングを開始する最良の方法の一つは、スケジューラメトリクスページを見ることです。メトリクスページではユーザーの失敗の源を特定でき、以下のような一般的な失敗モードを含みます：

• スケジュールされたビルドが失敗しています。 Run History タブに失敗したビルドの証拠が表示され、これらのビルドをクリックすると、完全なログのためのビルドアプリケーションのBuild Reportに移動します。
• スケジュールされたビルドが無視されました。Run Historyタブは、トリガーされたがビルドされなかったすべてのビルドについて、ステータス列にIgnoredを表示します。
• スケジュールがトリガーされませんでした、予想される時間や頻度で。この場合、Run Historyタブは、ユーザーが予想したときにビルドがトリガーされたことを示さない場合があります。

Versions タブは、過去のスケジュールバージョンと編集を表示し、スケジュールが突然予想外の動作を始めた場合に役立つ可能性があります。この変更と一致するスケジュールバージョンの変更を確認し、スケジュールを以前に動作していた状態に戻すことを検討してください。

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

スケジューラメトリクスページのRun Historyタブを確認することで、スケジュールが予想される時間にトリガーされたかどうかを確認できます。

スケジュールがトリガーされたが、その後のビルドが失敗した場合、デバッグガイダンスに従ってこのビルドをデバッグできます。

適切な権限が設定されていないと、スケジュールのビルドも失敗します。スケジュールの権限は、スケジュールがどのトークンモードにあるかによります。詳細は Project Scoped Schedules を参照してください。

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

スケジューラメトリクスページのRun Historyタブを確認することで、スケジュールが予想される時間にトリガーされたかどうかを確認できます。これは通常、スケジュールが無視された理由を提供します。

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

目標とするすべてのデータセットが最新である、つまり、その入力が最後のビルド以降に更新されていない場合、スケジュールの実行は無視されます。この場合、Run Historyタブでこの理由が表示されます。schedule editorに移動してスケジュールリストに移動します。次に、Out-of-dateでData Lineageグラフをカラーリングするオプションが表示され、どのジョブスペックが古いと見なされているかの概要が得られます。

この動作は、特別な状況でForce Buildオプションを使用することで上書きできますが、これらの状況以外では計算上無駄です。目標とするデータセットが、フォノグラフによる同期、API呼び出しによるトランスフォーム、またはデータ接続による同期によってビルドされるデータセットのいずれかである場合、それらは古いと表示されず、スケジュールが実行されるためにはForce Buildオプションを有効にする必要があるかもしれません。

スケジュールはデータセットの一部をビルドします

スケジュールがデータセットの一部だけをトリガーする場合、これの証拠がスケジューラメトリクスページのRun Historyタブに表示されます。

これの一因は、データセットの一部だけが古い可能性があります。スケジューラは古いデータセットだけをビルドし、最新のものはビルド中に無視されます。詳しくはall datasets are up-to-dateを参照してください。ビルドがIgnoredになるのは、これらのデータセットすべてが最新の場合です。

別の原因は、データセットがビルドのデータセットグラフに含まれていなかった可能性があります。schedule editorで、特定のスケジュールが選択されているとき、ビルドされるデータセットはData Lineageグラフで強調表示されます。データセットの選択はbuild typeに依存します。Connecting buildを使用している場合、同じデータセットを使用して複数のブランチでスケジュールを使用する場合は、接続データセットが存在するかどうかを特に確認する必要があります。

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

スケジューラメトリクスページのRun Historyタブを確認することで、スケジュールが予想される時間にトリガーされたかどうかを確認できます。ここでの一般的なデバッグステップは次のとおりです：

• スケジュールが一時停止していないことを確認します。一時停止したスケジュールは、再開されるまでトリガーされません。
• スケジュールトリガー設定を確認します。これが以前成功していた場合、最近トリガーに変更があったかどうかを確認するためにスケジュール履歴を確認します。
• スケジュールがイベントトリガーを使用している場合、予想されるイベントが実際に発生したことを確認します。例えば、入力の更新時にビルドがトリガーされるべきである場合、入力の最後のビルドが成功して、このビルド上のトランザクションがDataset Preview History viewで正常にコミットされたことを確認します。

スケジュールのリトライが設定と異なる

すべての種類の失敗がリトライ可能であるわけではないことに注意してください。スケジュールの実行時のリトライ回数は、ユーザーの管理者が設定した最大値に制限されます。詳細は Advanced settings を参照してください。

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

これは、スケジュールがゴミ箱に入っているリソースを含んでいるか、またはそのリソースから読み取っていることを意味します。以下のいずれかを行うことで解決できます：

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

スケジューラの権限

スケジュールを編集できない問題に遭遇した場合、プロジェクトスコープの権限が根本的な原因である可能性があります。

project scoped modeでスケジュールを編集するには、ユーザーは目標データセットにEdit権限、トリガーデータセットにView権限、そしてスケジュールがスコープされているプロジェクトにEdit権限を持つ必要があります。権限を失ったデータセットが1つでもある場合、変更を保存する前にこのデータセットをスケジュールから削除します。

スケジュールを編集、削除、または一時停止するには、ユーザーは目標データセットにEdit権限と、スケジュールがスコープされているプロジェクトにEdit権限を持つ必要があります。スケジュールを表示するには、ユーザーは目標データセットにView権限を持つ必要があります。