Fargate + cloudwatch eventでcronシステムモニタリング編

前回のお話

こちらはlambdaで監視してます。

ロジックとしては、タスク終了時のイベントをトリガーに、exitCodeの値をとって、0じゃない場合slackに通知してます。

こちらはdatadog logsの量が0以上なのをチェックしてます。

例えば1分間毎のcronの場合、「1分間でログが0以上あるよね」というチェックをしてます。

1Clusterにおける、Fargateのタスク上限数は50です

datadogで監視出来るのはFargateのserviceのみ。今回はcloudwatch eventsを通してタスクを動かしてるので取得できませんでした。

これが監視できないと、上限値に達した場合タスクが起動できなくなってしまいます。

その前に検知して上限緩和をしたいですね。

最初は「datadog logsで決めた量の２倍以上になったら2つ動いてる」というロジックで監視してましたが、

2倍以上にならない場合もあるので、悩みました。

双方の監視はGoで実装し、Fargate service上で動かして監視してます。

上記でやってることは

- stg, prodのcronクラスター内のタスクの数を監視し、slackに通知。 
- タスクがn個以上実行されてるかを監視します。15分ごとにまとめをslackに通知。（nは設定できます）

となってます。

datadogではfargate service + clusterの場合メトリクスが取れます。

が、今回はfargate + cloudwatch eventなのでクラスタからメトリクスが取れません。

なのでもし中々taskが終わらない...などの調査用に取りたい場合は、サイドカーでdatadog/agentをいつでも立ち上げれるよう、準備するだけでとどめてます。

curlでslackにメッセージPOSTするイメージで検証してました。

あまりにも起動、終了が早いため、datadog/agentより先に立ち上がって終了します。

dependsOnでdatadogに向ければ、datadogが立ち上がった後にアプリケーションが起動するので、メトリクスが取れるようになります。

dependsOnサイドカーのdatadogを向けた場合、永遠に立ち上がってしまいます。

のようにタスクが全部終了したら、検知してdatadogをshutdownするソリューションを考えましたが、

app = essential: true + dependsOn: datadog/agent
datadog/agent = essential: false

の設定を施せばこれは解決しました

例えば、

app:latest = essential: true + dependsOn: datadog/agent
datadog/agent:hogeeee = essential: false

でdatadogをサイドカーで立ててる場合、datadog/agent:hogeeee のような存在しないイメージを指定すると永久にタスクがpendingになります。

細かい原因はよくわかりませんが、もしこのようなパターンを使う場合は、app側のwrapperでサイドカーの起動を失敗検知する設定が必要です