9
Help us understand the problem. What are the problem?

More than 5 years have passed since last update.

digdagのsla/fail/error/waitについてのメモ

digdag(正確にはTreasureData Workflow)の sla パラメータで若干ハマったのでメモ。

slaとは

ドキュメント の通りですが、一定の時間を過ぎた場合、あるいは指定の時間を超えた場合にアラートを飛ばすことができます。

こちらもドキュメントに記載してありますが、 fail: オプションでworkflowを失敗にすることができます。

* sla: parameter supports duration: HH:MM:SS syntax in addition to time: HH:MM:SS syntax.
* sla: parameter supports fail: BOOLEAN and alert: BOOLEAN options. Setting fail: true makes the workflow failed. Setting alert: true sends an notification using above notification mechanism.

実際にやってみる

僕がハマりポイントがわかりやすいように実際に動かしてみます

以下のようなワークフローを定義します。
内容としては td_wait_table> でテーブルを待つだけです。
SLAは10秒に設定していて、fail: false としています。
手動でワークフローを実行後、10秒経過してから対象のテーブルを作成しました。

sample.dig
sla:
  duration: 00:00:10
  fail: false
  alert: false
  +notice:
    echo>: sla alert!!

+wait:
  td_wait_table>: tdwf_wait

_error:
  echo>: error!!

実行結果

wf1.png

10秒以上経過したため、 +notice で定義した内容が実行されてます。
SLAは超過していますが、テーブルが作成されたので正常に終了しています。


次に、fail: trueにして同じように実行してみます。

実行結果

wf2.png

同じく、10秒以上経過したため、 +notice で定義した内容が実行されています。
SLAは超過していますが、その後もタスクは実行され続け、テーブルを作成した時点でtd_wait_tableが正常終了で終わりますが、このタスク自体のステータスは失敗となります。
そのため、 _errorで定義した内容も実行されているのがわかります。

個人的に勘違いしていた点として、 fail: true にするとSLAを超えた時点で終了すると思っていましたが、そうではありません。


次にテーブルを作成せずに、途中でキャンセル(kill)してみます。
キャンセルはtd_wait_tableやs3_waitで24時間以上待っても存在しない場合に発生してしまいます

実行結果

wf3.png

タスクのステータス自体はキャンセルしているので、失敗となります。
ここで注目してほしいのでは _errorで定義した内容が実行されない ということです。

指定したSLAを超えた場合は+noticeで定義した内容を実行できますが、waitのタスクで24時間を超えても対象が存在しない場合は要注意です。

まとめ

  • fail: trueとしてもタスクが中断されるわけではない
  • waitのタスクで24時間超えた場合はキャンセルとなり、error処理が実行できない

fail: trueのユースケースってあるんだろうか。。

備考

  • TD workflow 0.9.13で実行

Register as a new user and use Qiita more conveniently

  1. You can follow users and tags
  2. you can stock useful information
  3. You can make editorial suggestions for articles
What you can do with signing up
9
Help us understand the problem. What are the problem?