ECSタスクのコンテナ異常終了を検知する3つの方法 | DevelopersIO
以降、それぞれの検知方法を紹介していきます。 検知方法①：サービスのランニングタスク数をメトリクスから検知 一番代表的な方法です。ECSコンテナエージェントは、タスク内のコンテナの状態をモニタリングしています。構成①と②においては、essential=trueのコンテナのみ含まれているので、コンテナの停止は即ECSタスクの停止となります。 あとは、ECSサービスにおけるDesiredTask Count（期待するタスク数）をしきい値としたランニングタスク数のCloudWatchメトリクスを用意しておき、しきい値を下回った時=タスクが異常終了したときにアラームを発火します。 一点、CloudWatch Alarmはある一定期間のメトリクスの状態からアラームを検知するものなので、検知までいくらかのタイムラグが有ることは注意しておきましょう。 基本的にECSのサービス運用においては、そのDesi
パブリックサブネットで起動したECS(EC2 + awsvpc)でコンテナがインターネット接続出来ない点について | DevelopersIO
ECSクラスターへデータプレーンが参加している データプレーンをECSクラスターへ追加する時は「インターネット経由でECSと疎通が取れる」か「VPCエンドポイントを設定」する必要があります。 VPCエンドポイントは使用しておらず、インターネット経由でアクセスをしていることを想定しましたのでインターネット接続は問題ないものと考えておりました コンテナをチェック mackerel-container-agent自体の起動は問題なかったので、EC2へSSH接続 → docker execにてbashを起動し、ping、netcat、digコマンドが入っていないことを認識していたのでapt-getを実施したところタイムアウトしました。 この時点でNW部分が怪しい気持ちが増しました。 調査②：ネットワークモードを変更 ネットワークモードを変更(awsvpc → bridge) 確認観点としてネットワ
Elastic Load Balancingトラブルシューティング：HTTPエラーコード | DevelopersIO
ELBが報告するHTTPエラーコード ELBでは様々なエラーコードが発生します。それらはCloudWatchで発生回数を確認することができるのですが、同じようなエラーコードがあり少し紛らわしです。 どのHTTPエラーコードをロードバランサーは返すのか？ ロードバランサーは400、405、408、502、503のエラーレスポンスと、登録されているインスタンスが返すあらゆるエラーレスポンスを返します。 CloudWatchで確認可能なHTTPエラーコード ロードバランサーはクライアントに送信されるHTTPレスポンスコードをAmazon CloudWatchにメトリクスとして保存しています。これを用いると、エラーのソースがロードバランサーなのか、バックエンドのインスタンスなのかを確認することができます。CloudWathcの利用に関する情報と利用可能なメトリクスの定義に関しては、Monitor
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
