みなさんこんにちは。
マネージドサービス部の福田です。
NewRelicでECSの監視する方法として公式ドキュメントで示されている
「ECSエージェントをサイドカーコンテナとしてデプロイし、ECS情報を取得する」方法があります。
しかし、タスク定義を変更することが難しい場合もあるかと思います。
docs.newrelic.com
本記事では、タスク定義を変更せずに、ECSの監視をどこまで行えるかを検証しました。
後編では具体的な設定方法について記載予定です。
なお、ECSエージェントをサイドカーコンテナとして導入できる環境であれば
ECSエージェントを入れた方が楽に監視を実現できます。
以下の画像は、ECSエージェントを導入した場合にNew Relicで収集できるコンテナレベルの情報になります。
ECSの概念
クラスター、サービス、タスクの概念は以下資料をご確認ください。
ざっくりとそれぞれの説明を記載すると以下になります。
クラスターとは
タスクまたはサービスの論理グループになります。
サービスとは
クラスター内のタスクを管理し、スケーリングや負荷分散を行います。
タスクとは
タスク定義を元に作られる、アプリケーションの実行単位になります。
タスク定義は、コンテナで使用するDockerイメージやコンテナに割り当てるCPU、メモリなどを定義します。
監視内容
CloudWatchメトリクス
ECSの標準的な主なメトリクスはクラスター、サービス単位の以下内容になります
CPU使用率
- サービス内のタスクで使用されているCPUユニット数をタスクで予約しているCPUユニット数で割った値
メモリ使用率
- サービス内のタスクで使用されているメモリ数をタスクで予約しているCメモリ数で割った値
サービスのタスクの挙動
- サービス内でのタスクのステータス(RUNNING、PENDING)状態や起動タスク数の値
Container Insights
Container Insightsとは
コンテナワークロードに特化したモニタリング機能になります。
Container Insightsを有効にすると以下内容が実現できます。
- サービス単位だけでなくタスク定義単位でのCPU、メモリ、ディスク、ネットワークなどのメトリクスが取得可能になります。
- CloudWatchのメニューから「Container Insights」を選択し、最新のパフォーマンス情報を確認できます。
- 画面内では、コンテナ単位のCPU使用率などの情報も確認できます。
- パフォーマンス情報はContainer Insightsを有効にすることで自動的に作成されるロググループ内のログに記録されます。
- 作成されるロググループ名:/aws/ecs/containerinsights/<クラスタ名>/performance
費用
Container Insightsを有効化にすると以下の料金が発生します。
メトリクス
- クラスタ、サービス、タスクごとのカスタムメトリクスが自動的に生成されます。
- 1メトリクスにつき月額0.30 USDとし、カスタムメトリクスの数で料金が決まります。
ログ
- 1メトリクスあたり、1時間で13KBのログが取り込まれます。
- 取り込んだログの容量1GBにつき0.50 USDとし、料金が決まります
例:クラスター、サービス、タスクがそれぞれ1つのECSの場合:7.5USD+0.11USD=7.61USD
- メトリクスの月額費用:メトリクス数(25)0.30USD=7.5USD
- メトリクス数:8*クラスター数+6タスク数+11*サービス数=25 - ログの月額費用: 0.5USD*取り込むLosのデータ量=0.11USD
- 取り込むログ量:(13 KB/1024/1024) GB * メトリクス数 * 730 時間=0.22GB
- メトリクスの月額費用:メトリクス数(25)0.30USD=7.5USD
コンテナ単位のメトリクスは取れないのか
結論から言うと、コンテナ単位のメトリクスは取得可能です。
Container Insightsを有効にすると自動的に作成されるロググループにコンテナ単位のパフォーマンス情報も記録されます。
ロググループ名:/aws/ecs/containerinsights/<クラスタ名>/performance
※クラスタ/サービス/タスク定義単位も記録されるのでContainer Insightsのメトリクスは
このパフォーマンス情報を元にした情報ではないかと想像しています
以下がコンテナ単位のパフォーマンスログ内容になります。
{ "Version": "0", "Type": "Container", "ContainerName": "★コンテナ名★", "TaskId": "★タスクID★", "TaskDefinitionFamily": "★タスク定義名★", "TaskDefinitionRevision": "1", "ServiceName": "★サービス名★", "ClusterName": "★クラスター名★", "Image": "★コンテナのイメージ名★", "ContainerKnownStatus": "RUNNING", "Timestamp": 1699592880000, "CpuUtilized": 2.2165252939860025, "CpuReserved": 10, "MemoryUtilized": 2, "MemoryReserved": 10, "StorageReadBytes": 52666368, "StorageWriteBytes": 2152448, "NetworkRxBytes": 19, "NetworkRxDropped": 0, "NetworkRxErrors": 0, "NetworkRxPackets": 123131, "NetworkTxBytes": 68, "NetworkTxDropped": 0, "NetworkTxErrors": 0, "NetworkTxPackets": 2821 }
上記ログ情報から、メトリクスフィルターを使用してカスタムメトリクスを作成できます。
例:コンテナ単位のCPU使用率をカスタムメトリクス化したい場合はCpuUtilized の値を CpuReservedで割ったもの*100をする
※カスタムメトリクスをNewRelicに送るにはMetric Streamsを使用する必要があります(API polling では不可)
イベント
ECSではイベント情報を取得することができEventBrigeと連携することができるので
以下のようにEventBrige経由でNewRelicにデータを送信します
今回は以下のイベントをNewRelicに送ろうと思っております。
タスク状態変更イベント
- タスクの起動/停止などステータス状態に関する情報を取得できます。
サービスアクション
- イベントタイプが、INFO、WARN、ERROR分かれている
- CloudWatchでは拾えなかったタスク置換エラーやサービスディスカバリーのスロットル情報なども存在する
まとめ
ECS(Fargate)の監視方法として公式ドキュメントにある通りサイドカーコンテナ方式は便利ですが、場合によってはタスク定義の変更が難しい状況も考えられます。
本記事はサイドカーコンテナ方式にしない場合もContainer Insightsやイベント情報を活用すれば様々な情報をNewRelicに送ることができるという内容になりました。
後編では実際に以下情報をNewRelicへ送るための設定方法やNewRelic側でどのように情報が可視化されるのかについて記載していこうと思います。
- AWSインテグレーション(API Polling経由):ECSのサービス単位の情報
- AWSインテグレーション(Metric Streams経由):ECSのタスク/コンテナ単位の情報(Container Insightsによる取得情報)
- イベント情報(EventBrige経由):タスクのステータス推移およびWARN、ERRORのイベント情報