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

このページでは、共通のスケジューリング問題とデバッグ手順を説明します。

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

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

スケジュール問題のトラブルシューティングを始める最良の方法の一つは、スケジュールメトリクスページを見ることです。メトリクスページはユーザーの失敗の原因を教えてくれます。よくある失敗には以下のようなものがあります：

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

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

スケジュールされたビルドが失敗する

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

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

適切な権限が設定されていないと、スケジュールはビルドに失敗します。スケジュールの権限は、スケジュールがどのトークンモードにあるかに依存します。プロジェクトスコープのスケジュールについて詳しく学びましょう。

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

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

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

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

この動作は、特殊な状況で 高度な設定 の Force Build オプションを使用してオーバーライドできますが、これらの状況以外では計算的に無駄です。ターゲットデータセットが Phonograph の同期、API コールを使った変換、または Data Connection の同期によってビルドされる場合、それらは古いと表示されず、スケジュールが実行されるためには Force Build オプションを有効にする必要があるかもしれません。

スケジュールがジョブスペックの一部をビルドする

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

この動作の一因として、ジョブスペックの一部だけが古い可能性があります。スケジュールは古いジョブスペックのみをビルドし、最新のものはビルド中に無視されます。詳細なトラブルシューティング情報については、すべてのデータセットが最新の状態を参照してください。ビルドが Ignored になるケースは、これらのジョブスペックがすべて最新の状態にある場合です。

別の原因として、ジョブスペックがビルドのジョブスペックグラフに含まれていない可能性があります。スケジュールエディタで特定のスケジュールが選択されているとき、ビルドされるジョブスペックはデータフローグラフで強調表示されます。ジョブスペックの選択は ビルドタイプに依存します。Connecting build を使用している場合は、同じデータセットを使用しているスケジュールに対して接続ジョブスペックが存在するかどうかを確認してください。

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

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

• スケジュールが一時停止していないことを確認します。一時停止したスケジュールは、再開されるまでトリガーされません。
• スケジュールトリガーの設定を確認します。スケジュールが以前に成功してトリガーされていた場合は、トリガーに最近変更があったかどうかを確認するためにスケジュール履歴を確認します。
• スケジュールが Event トリガーを使用している場合は、予想されるイベントが実際に起こったことを確認します。

  • 例えば、入力が更新されたときにビルドがトリガーされるべき場合、入力の最後のビルドが正常に実行され、このビルドのトランザクションが Dataset Preview 履歴ビュー で正常にコミットされたかどうかを確認します。

  • 複数の入力が更新された後にビルドがトリガーされるべき場合、すべての入力についてビルドとタイミングを確認します。例えば、入力トリガーA1とA2を持つスケジュールを考えてみてください。そして "Wait until all these datasets update" がオンになっています。このスケジュールは以前に時間T1で実行されました。このスケジュールが再度時間T2で実行されるためには、A1とA2の両方が時間期間 (T1, T2) の間に更新される必要があります。

    

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

すべての種類の失敗がリトライ可能なわけではありません。スケジュールが実行されるときのリトライの回数は、ユーザーの管理者が設定した最大値に制限されます。高度なスケジュール設定について詳しく学びましょう。

リトライ可能なエラーコードは以下の通りです：

• INTERNAL
• TIMEOUT
• CUSTOM_SERVER
• FAILED_PRECONDITION

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

このエラーは、スケジュールがトラッシュ状態のリソースを含んでいるか、またはそれから読み取っていることを意味します。以下のいずれかを行うことで解決できます：

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

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

スケジュールの権限

プロジェクトスコープモードのスケジュールを編集するには、ターゲットデータセットに対する Editor 権限、トリガーデータセットに対する Viewer 権限、スケジュールがスコープされているプロジェクトに対する Editor 権限が必要です。一つのデータセットに対する権限を失った場合、変更を保存する前にこのデータセットをスケジュールから削除します。

スケジュールを編集、削除、一時停止するには、ターゲットデータセットとスケジュールがスコープされているプロジェクトに対して Editor 権限が必要です。スケジュールを表示するには、ターゲットデータセットに対して Viewer 権限が必要です。

スケジュールの計算情報が利用できない

"すべての計算情報が利用できません。実際の計算使用量は表示されているものよりも高くなる可能性があります。"というメッセージが、以下の理由のいずれかでスケジュールを表示するときに表示されることがあります：

• 1つ以上のスケジュールされたビルドがまだ進行中で、合計計算使用量がまだ確定していない。
• 少なくとも1つのスケジュールされたビルドで使用したリソースについての情報が欠落している。

このメッセージが表示されたとき、ユーザーアクションは必要ありません。このメッセージの目的は、表示されている合計計算使用量が特定の時間に不正確である可能性があることを示すことです。