前回のお話
Fargate + cloudwatch eventでcronシステム構築 - Sionの技術ブログ
non exit0かどうか
こちらはlambdaで監視してます。
Fargate + cloudwatch eventでcronシステム構築 - Sionの技術ブログ
ロジックとしては、タスク終了時のイベントをトリガーに、exitCodeの値をとって、0じゃない場合slackに通知してます。
タスクが正常に動いてるかどうか
こちらはdatadog logsの量が0以上なのをチェックしてます。
例えば1分間毎のcronの場合、「1分間でログが0以上あるよね」というチェックをしてます。
クラスタのタスク数と、タスクが並列で動いてないかどうか
クラスタのタスク数
1Clusterにおける、Fargateのタスク上限数は50です
Amazon ECS サービス制限 - Amazon Elastic Container Service
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をいつでも立ち上げれるよう、準備するだけでとどめてます。
datadog/agentが立ち上がる前にメインコンテナが起動終了する？
https://hub.docker.com/r/sioncojp/docker-slack
curlでslackにメッセージPOSTするイメージで検証してました。
あまりにも起動、終了が早いため、datadog/agentより先に立ち上がって終了します。
dependsOnでdatadogに向ければ、datadogが立ち上がった後にアプリケーションが起動するので、メトリクスが取れるようになります。
datadog/agentが永遠に立ち上がる？
dependsOnサイドカーのdatadogを向けた場合、永遠に立ち上がってしまいます。
https://github.com/sioncojp/fargate-sidecar-datadog-agent
のようにタスクが全部終了したら、検知してdatadogをshutdownするソリューションを考えましたが、
app = essential: true + dependsOn: datadog/agent datadog/agent = essential: false
の設定を施せばこれは解決しました
タスクが永久にpending？
例えば、
app:latest = essential: true + dependsOn: datadog/agent datadog/agent:hogeeee = essential: false
でdatadogをサイドカーで立ててる場合、datadog/agent:hogeeee のような存在しないイメージを指定すると永久にタスクがpendingになります。
細かい原因はよくわかりませんが、もしこのようなパターンを使う場合は、app側のwrapperでサイドカーの起動を失敗検知する設定が必要です
