DatadogでECS Fargate TaskのCPU利用率が100%を超えて表示されていたので調べてみた - Classi開発者ブログ
こんにちは。開発本部の遠藤です。 ClassiではAmazon ECSをアプリケーション実行環境として利用しています。 ECSの各種メトリクスをDatadogを使ってモニタリングしながら、日々安定稼働しているかどうかをチェックしています。 そのうちの一つの重要なメトリクスとして、ECSのFargate TaskのCPU利用率が過度に高まっていないか、があるのですが、ある時期、CPU利用率が100%を超えてしまっていて「一体なにが起きてるんだ？？」と疑問を持ちました。 今回はそれについて深堀りしてみたので、ニッチなトピックですが紹介したいと思います。 ECS Fargate TaskのCPU利用率が100%を超えて表示されている こちらが実際にCPU利用率が100%を超えてしまったときのグラフです。 Datadogのメトリクスは ecs.fargate.cpu.percent です。なお、c
Amazon ECSのログストリームを見やすく階層的に整理できるawslogs設定 - Hatena Developer Blog
こんにちは。SREのid:do-su-0805です。普段はid:do_su_0805として生活しています。 この記事では、Amazon ECS（以下、ECS）でコンテナを動かすとき、ログドライバーとしてawslogsを利用してAmazon CloudWatch Logs（以下、CloudWatch Logs）にログを出力する際に、awslogs-stream-prefixというパラメータには何を設定するとよいかについて考察します。 結論から言うと、このパラメータに「コンテナのイメージタグ」を入れるようにしたところ、出力されるログストリームの/区切りの階層が見やすくなり、ログが世代別に扱いやすくなったよ、というお話です。 ECS＋CloudWatch Logs構成時のロググループとログストリームについて どのようなログストリームが構成されがちかを事例から考えてみる awslogs-strea
コンテナ運用におけるログ基盤設計のベストプラクティス - Qiita
課題 数年前と比較すると、GKEやECSを始めとするコンテナ実行環境でのアプリケーション運用を行うサービスはかなり増えてきた印象があります。 コンテナを運用する上では、アプリケーションのイベントを追跡する上でログをどう扱うかが課題になります。今までのように古いログを定期的にローテートして別のストレージに転送するといった手法はクラウドネイティブなアーキテクチャには最適とは言えません。 アプリケーション開発の方法論として、Twelve Factor App ではログをイベントストリームとして扱うためのガイドラインが示されていますが、近年のWebアプリケーションではシステムを疎結合に連携するマイクロサービスという考え方が主流になりつつあります。 アプリケーションログはサービスごとにフォーマットを整形した上で、ログ収集サービスに配送。必要に応じてリアルタイム分析や異常データの通知、そしてデータの可
コンテナログ処理の技術的なベストプラクティス：Dockerのケーススタディ - Qiita
この記事では、Dockerを例に、コンテナログ処理の一般的な方法やベストプラクティスをいくつか紹介しています。 背景 Docker, Inc. 旧社名：dotCloud, Inc）は、2013年にDockerをオープンソースプロジェクトとしてリリースしました。その後、Dockerに代表されるコンテナ製品は、分離性能の良さ、移植性の高さ、リソース消費の少なさ、起動の早さなど複数の特徴から、瞬く間に世界中で人気を博しました。下図は2013年からのDockerとOpenStackの検索傾向を示しています。 コンテナ技術は、アプリケーションの展開や配信など、多くの便利さをもたらします。また、以下のようなログ処理のための多くの課題ももたらします。 1、コンテナの中にログを保存した場合、コンテナが取り外されるとログは消えてしまいます。コンテナは頻繁に作成・削除されるため、コンテナのライフサイクルは仮想
ECSタスクのコンテナ異常終了を検知する3つの方法 | DevelopersIO
以降、それぞれの検知方法を紹介していきます。 検知方法①：サービスのランニングタスク数をメトリクスから検知 一番代表的な方法です。ECSコンテナエージェントは、タスク内のコンテナの状態をモニタリングしています。構成①と②においては、essential=trueのコンテナのみ含まれているので、コンテナの停止は即ECSタスクの停止となります。 あとは、ECSサービスにおけるDesiredTask Count（期待するタスク数）をしきい値としたランニングタスク数のCloudWatchメトリクスを用意しておき、しきい値を下回った時=タスクが異常終了したときにアラームを発火します。 一点、CloudWatch Alarmはある一定期間のメトリクスの状態からアラームを検知するものなので、検知までいくらかのタイムラグが有ることは注意しておきましょう。 基本的にECSのサービス運用においては、そのDesi
ECSのログ管理にFirelensを導入してみた - Gunosy Tech Blog
はじめに こんにちは。SRE部の板谷(@SItaya5)です。 Gunosyでは様々なプロダクトでECS(Amazon Elastic Container Service)を使用してタスクを実行しています。 ECSの起動タイプにはEC2とFargateの2種類がありますが、どちらのタイプも混在しています。 ログの送信先としては、主にPapertrailというサービスを使用しています。 しかし、Fargateで実行しているタスクに関しては、ログの送信先(Log Driver)に選択の余地がなく、Cloudwatch Logs一択でした。 そのため、EC2で実行しているタスクのログはPapertrailに送信されていましたが、一方のFargateで実行しているタスクはCloudwatch Logsに送信せざるを得ませんでした。 このように起動タイプ毎にログの送信先が分かれており、管理が煩雑にな
ECSとGoで構築したシステムにDatadogを導入する | おそらくはそれさえも平凡な日々
追記: GoのアプリケーションをOpenMetricsを使ってObservableにする方法については別エントリを書きました。 → https://songmu.jp/riji/entry/2020-05-18-go-openmetrics.html ECSとGoで運用しているシステムに対するDatadogの日本語知見があまり無さそうだったので書いてみる。ちなみに以下の環境です。 ECS on EC2 (not Fargate) アプリケーションコンテナのネットワークモードはbridgeモード 動的ポートマッピングも利用 背景として3月にNature Remoのインフラアーキテクチャ改善をしていて、その前にもうちょっと監視を整えたほうが良いな、ということでDatadogを導入したのがある。テストがないとリファクタリングできないように、監視がないとアーキテクチャのアップデートもやりづらいとい
Amazon ECSを安定運用するためにやっていること コンテナインスタンス、ログ、モニタリングにおける工夫
2018年11月28日、クックパッド株式会社が主催するイベント「Cookpad Tech Kitchen」が開催されました。第20回となる今回のテーマは「クックパッドのマイクロサービスプラットフォーム現状」。クックパッドが開発を行っているマイクロサービスプラットフォームの今と、その仕組みについて解説します。プレゼンテーション「Amazon ECS の安定運用のために」に登壇したのは、鈴木康平氏。クックパッドにおけるAmazon ECSの運用事例と工夫していることについて解説します。講演資料はこちら Amazon ECSの安定運用 鈴木康平氏：「Amazon ECSの安定運用」というタイトルで発表したいと思います。今回のアウトラインとしては、「ECSをどう使うか」みたいな話ではなくて、そのECSを運用していく上でこんなことやっていますよということを話していければなと思います。 内容としては、
A High Available Docker Container Platform using CoreOS and Consul
BlogA High Available Docker Container Platform using CoreOS and Consul Docker containers are hot, but containers in themselves are not very interesting. It needs an eco-system to make it into 24×7 production deployments. Just handing your container names to operations, does not cut it. In the blog post, we will show you how CoreOS can be used to provide a High Available Docker Container Platform
Datadog で Docker コンテナをモニタリングする - Qiita
概要 Datadog というモニタリングサービスを利用して Docker コンテナの CPU やメモリなどのメトリクス収集・監視とコンテナの死活監視をするという話。 Datadog を使うメリット Docker をどうモニタリングすべきかのモデルとなる Datadog のエージェントは、 Docker が依存する Linux の "namespace" と "cgroup" が提供するメトリクスを 15 秒ごとに収集することでモニタリングを行っている。また Docker コンテナをどうモニタリングするか・どうメトリクスを収集するか・どんなメトリクスがあるかを学ばさせてもらっている。 参考: "How Docker monitoring works" Monitor Docker with Datadog - Datadog Blog コンテナへ自動でタグ付け Datadog は Docke
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Docker監視環境 - Part1: cAdvisor, collectd, Riemann, InfluxDB, Grafana