トップ > New Relic > 【New Relic】 ECSエージェントを使用しないでECS(Fargate)の欲しい情報をNewRelicに送ってみた（後編）

【New Relic】 ECSエージェントを使用しないでECS(Fargate)の欲しい情報をNewRelicに送ってみた（後編）

New Relic Amazon ECS AWS EventBridge
記事タイトルとURLをコピーする

みなさんこんにちは。
マネージドサービス部の福田です。

本記事は以下ブログの後編になります。

blog.serverworks.co.jp

前編のまとめ

NewRelicにてECS(Fargate)の情報を収集する方法として「ECSエージェントをサイドカーコンテナとしてデプロイし、ECS情報を取得する」がありますが
タスク定義を変更することが難しい場合もあるかと思います。
docs.newrelic.com

前編の記事はタスク定義を変更しないで以下の情報をNewRelicへ送ってみようという内容になりました。
本記事では実際の設定方法やNewRelic側で収集した情報をどのように可視化できるかについて記載いたします。

  • AWSインテグレーション（API Polling経由）：ECSのサービス単位の情報
  • AWSインテグレーション（Metric Streams経由）：ECSのタスク/コンテナ単位の情報(Container Insightsによる取得情報)
  • イベント情報（EventBrige経由）：タスクのステータス推移およびWARN、ERRORのイベント情報

上記設定の全体像

AWSインテグレーションについて

設定の説明をする前に前編で記載できていなかったAWSインテグレーションについて記載します。
NewRelicのAWSインテグレーションには二つの種類があります。
それぞれ、API pollingと、Metric streamsです。
それぞれのインテグレーションに関する私の認識は以下になります。
実際のインテグレーションに関する詳細は公式ドキュメントをご覧ください： Amazon CloudWatch Metric Streamsのインテグレーションの概要 | New Relic Documentation

API pollingについて

  • IAMロールを用いてAWSの各APIを呼び出してデータを取得する方法になります。

  • APIポーリング間隔が最短で5分程かかるのでNewRelic上へのデータ反映に遅延が発生します。

  • NewRelicへ送るリソースをタグ単位で指定することが可能です。（データ通信量のコスト削減可能）

Metric streamsについて

  • Amazon CloudWatch Metric Streamsを利用する方法になります

  • CloudWatchメトリクスをKinesis経由でストリーム送信するのでデータ反映のレイテンシーが少ない です。

  • 全てのAWSサービスとカスタム名前空間からのすべてのCloudWatchメトリクスを取得可能です。

  • NewRelicへ送るリソースはメトリクスの名前空間までしか絞れないので不要なリソースのメトリクスを送ってしまいます。（データ通信料のコストは要検討）

AWSインテグレーション（API Polling経由）：
ECSのサービス単位の情報

設定イメージ図

設定内容

  • NewRelic上のInfrastructureメニューより画面に沿ってAPI pollingの設定（IAMロール作成など）を進めます

  • インテグレーション連携したら必要に応じて送りたいリソースに対してリージョンやタグの条件を指定します

AWSインテグレーション（Metric Streams経由）：
ECSのタスク/コンテナ単位の情報(Container Insightsによる取得情報)

設定イメージ図

設定内容（NewRelic側）

  • NewRelic上のInfrastructureメニューより画面に沿ってMetric Streamsの設定（IAMロールの作成やCloudFormationスタック作成）を進めます

設定内容（AWS側）

ECS（Container Insights有効）のロググループ（/aws/ecs/containerinsights/<クラスタ名>/performance）にてタスク/コンテナ単位のカスタムメトリクスを作成

  • ロググループからメトリクスフィルター（カスタムメトリクス）を作成

    • コンテナ単位のCPU使用率の内容例：(CpuUtilized/CpuReserved*100)になるのでCpuUtilizedとCpuReservedのメトリクスを作成が必要
    • カスタムメトリクス作成時に名前空間も任意の値に指定できるのでNewRelicへのデータ通信料の削減のためタスク単位のカスタムメトリクスも作成
      • Container Insights有効にするとタスク定義のメトリクスは存在するが名前空間がECS/ContainerInsightsのため他リソースのデータ通信の発生を防ぐため作成
    • ディメンション値はNewRelic側でNRQLを作成時にリソース識別するために必要

  • コンテナ単位のCpuUtilizedの内容例

  • CloudWatch Metric Streamsで作成した名前空間のメトリクスのみNewRelicへ送るよう指定する（コスト削減のため必要なメトリクスのみ指定）

イベント情報（EventBrige経由）：
タスクのステータス推移およびWARN、ERRORのイベント情報

設定イメージ図

設定内容

  • 以下のブログ記事を参考にEventBridgeとNewRelicを連携させてください。 blog.serverworks.co.jp

  • ルールの内容は以下の画面例を参考にしてください。

    • resourcesの指定はECSクラスターARNになります。

収集された情報をNewRelicにて可視化

上記の設定でECSの情報をNewRelicのデータベース（NRDB)に送ることができるようになりました。
情報を収集した後はどのようにデータを活用していくかという話になります。

NewRelicではNRDBに収集された情報をNew Relicクエリ言語（NRQL）を用いることでダッシュボード作成（可視化、分析）やアラート設定等をすることができます。
では収集された情報をNRQLを使用するとどのように可視化できるかを記載していきたいと思います。

docs.newrelic.com

ダッシュボードについて

先ほどダッシュボードを作成するためにはNRQLを用いる必要があるとお話をしましたが
NewRelicでは基本的なダッシュボードであればテンプレートが多数用意されています。

エージェントによる監視や単純なインテグレーション連携による設定であれば用意されているテンプレートのダッシュボードを 使用するだけでも十分にデータの可視化はできるかと思います。

ECSのテンプレートダッシュボード

ダッシュボード作成

今回表示したいダッシュボードはテンプレートにも含まれない内容がありますので
NRQLを使用して作成をしていきたいと思います。

  • 使用したNRQL例

今回作成したダッシュボード一覧

  • 死活系（サービス、コンテナ起動数、タスクの状態/発生したイベント情報）

  • リソース系（サービス、タスク定義、コンテナ単位のCPU/メモリ使用率）

まとめ

いかがでしたでしょうか。

個人的にECSエージェントを使用しないでも思った以上に自分が欲しい情報をNewRelicへ送ることができたなと感じました。
これを実現できるのはNewRelicのデータ連携方法が充実していることとデータ活用の自由度の高さがあってこそだと思います。

今回はECSについてお話ししましたが他にもコマンド結果を
メトリクス化できるFlexを使用すればメトリクスが存在しないOS内のデータや
アプリケーションのデータをNewRelicに送ることが可能です。
NewRelicにデータを送りさえすればNRQL等を用いればNewRelic側でいい感じに可視化や分析もできます。

こうしたNewRelicの収集したデータの活用に関する自由度の高さは強みの一つかなと感じております。
ただ自由度が高い反面やはり慣れも必要かと思うのでこれからも学んでいきたいと思います。

docs.newrelic.com

福田 圭 (記事一覧)

マネージドサービス部

2023 New Relic Partner Trailblazer