深夜の定期バッチの監視

Webサービスのオフピーク時に重たい処理を実行させるというのは一般的なプラクティスといえます。

特に深夜〜早朝は多くのサービスでバッチ処理を実行させているのではないでしょうか。

Webサービスだけではなく、当然バッチ処理も監視して失敗したらそれを発見し対処したいです。

しかし、失敗を発見しても即座にユーザ影響がないので対応は後でも良いという場合、素朴に監視ルールを作るとバッチが失敗した深夜・早朝にアラートが発報されることになります。

発報されたアラートを見て「これは今すぐに対応してなくても良いな」と判断するのであれば、それは狼少年アラートといえるのではないでしょうか。

悪貨が良貨を駆逐すると言われるように、狼少年アラートがはびこれば良貨のアラートもいずれ無視されるようになってしまうことは容易に想像できます。

Datadogの `timeshift` 関数でアラートの発報タイミングを変える

この狼少年アラート問題を解決するためには 事象が起きたタイミングとアラート発報のタイミングを変える ことができたらよさそうです。

まず最初の案として、当社は監視サービスとしてDatadogを利用しているので、定期的にCustom Checkを投稿・実行することを考えました。

しかし対象のバッチ処理はAWS Step FunctionsとAWS Lambdaを組み合わせたシステムで、DatadogのAWS連携でStep Functionsの失敗数は既にメトリクスとしてDatadogに収集されており、これと重複する処理を作るのはナンセンスです。

通常のメトリクス監視で通知だけずらせたらシンプルで合目的なのですが、そういった解決策はないでしょうか?

ところでモニターの設定画面をあれこれ見ていると hour_before() というある時点より1時間前の値をその時点のメトリクス値とする関数が存在することを知りました。

これを使えば、過去のメトリクス値をもとにアラートを発報することもできるはずです。しかし、1時間前あるいは1日前では間隔が短すぎ・長すぎます。任意の時間だけずらす関数はないのでしょうか?

実はtimeshiftというまさしくそのものの関数があります。というか hour_before() などの XXX_before() 関数はすべて timeshift() 関数へのエイリアスになっています。

我々のバッチシステムは毎朝4時に実行されるので、コアタイムに近い午前10時に通知できれば良いと考え、6時間シフトさせた値を監視することにしました。

実際のクエリは以下のようになります:

timeshift(sum:aws.states.executions_failed{/* snip */} by {stage}.as_count(), -21600)
# 60 * 60 * 6 = 21,600

Datadogの timeshift() 関数を使い、深夜早朝に実行されるバッチのアラートを実際に対処すべき時間に通知する方法について紹介しました。

今回紹介した方法は「次の営業時間内に対応すればよい」という温度感のアラートを運用の実際に近付けるためのものであって、当然ながら濫用して即時対応すべきアラートを遅延させることを推奨するものではありません。

重要なことは 本当に対応すべきタイミングに必要なアラートを受け取る 仕組み作りであることは疑いようがありません。

当社ではWebサービスの監視について継続的に改善を進めており、過去にはこのブログでも紹介しました。

今後もアラートルールを見直しシステムの監視を洗練させ続けたいと思います。