AWS CloudWatch Metric Streams統合は、カスタムネームスペースを含むすべてのAWSサービスからのすべてのCloudWatchメトリクスを監視するための推奨ソリューションです。
New Relic で Metric Stream を設定する方法について説明します 。
なぜそれが重要なのか？
CloudWatchメトリクスストリームの前は、AWSモニタリングパートナーの唯一のソリューションは、ポーリングフリートをデプロイし、定期的に複数のAWS APIを呼び出して、メトリクスとメタデータを取得することでした。次の表は、両方のソリューションの違いを示しています。
APIモード | ストリームモード |
|---|---|
メトリクスを収集するためには、各AWSサービスとの連携が必要となります。 | すべてのAWSサービスとカスタム名前空間からのすべてのCloudWatchメトリクスは、特定の統合の構築や更新を必要とせずに、New Relicで一度に 。 例外が 1 つあります。メトリクスが AWS CloudWatch で利用可能になり、2 時間以上の遅延がある場合、これらのメトリクスはストリームに含まれません。 |
これにより、New Relic でアラートとダッシュボードに使用できるメトリクスに遅延が追加されます。最速のポーリング間隔は 5 分です。 | メトリクスは AWS CloudWatch で利用できるため、2 分未満でストリーミングされるため、レイテンシーが大幅に改善されます。 |
大規模なAWS環境では、AWS APIのスロットリングが発生する可能性があります。 | AWSのAPIスロットルが廃止されました。 |
Amazon CloudWatch Metric Streamsの統合を試してみたいですか？ New Relic にサインアップすれば、永久に無料です。
コスト面での配慮
AWS CloudWatch メトリックストリームと New Relic の統合のコストを評価する際には、以下の点を考慮してください。
- AWS CloudWatchのメトリックの更新。
- AWS Kinesis Firehose ingest.
- AWS Kinesis Firehoseのデータ転送.
- オプション：選択したAWS名前空間のリソースメタデータでメトリクスを強化するために使用されるAWSConfigサービス。
ヒント
New Relic は、AWS のサービスを検出、識別、および監視するために、AWS Config Service にアクセスする必要があります。このアクセス権がないと、New Relic はシステムを監視して表すことができません。
AWSやNewRelic側のフィルターなど、 データ管理に利用できるメカニズムについて学びます。該当する場合は、本番環境前の環境で初期統合を完了して、限られた数のAWSリソースとサービスに基づいてソリューションの総コストを評価してください。
AWS APIポーリング統合からの移行
New Relic がメトリクス ストリームを介してメトリクスを受信し、現在のポーリング ベースの統合を使用して同じメトリクスを取得すると、メトリクスが重複する可能性があります。
たとえば、アラートと sum または count を使用するものは、実際の数の 2 倍を返します。これには、 .Sum サフィックスを持つメトリックを使用するアラートとダッシュボードが含まれます。
テストを安全に行うことができる本番ではないNew Relicアカウントにデータを送ることをお勧めします。それができない場合は、AWS CloudWatch Metric Streamのフィルターを利用して、トラブルの原因となる特定の名前空間を含めたり除外したりすることができます。
または、クエリのフィルタリングを使用して、メトリックストリームからのメトリックとポーリングからのメトリックを区別することもできます。メトリックストリームからのすべてのメトリックは、 collector.name='cloudwatch-metric-streams'でタグ付けされています。
移行の手順
一般的なデプロイメントでは、APIポーリングからメトリックストリームへの移行は以下の手順で行われます（最初にdev/staging環境で試すことをお勧めします）。
- one.newrelic.com > Infrastructure > AWSに移動し、 Add an AWS accountをクリックして、AWS アカウントを New Relic にリンクします。AWS アカウントがすでにポーリング統合にリンクされている場合でも、これを行う必要があります。
- オンボーディングの最後のステップである、AWS CloudWatchのメトリクスストリームとAWS Kinesis Data Firehoseを有効にして、メトリクスをNew Relicにプッシュすることを完了させてください。
- AWS CloudWatchは1つのリージョンに1つのストリームを必要とするので、監視したいAWSリージョンを追加する場合は手順2を繰り返す。
- 接続されているすべてのリージョンとネームスペースからメトリクスが受信されていることを確認します。これには数分かかる場合があります。
- 以前のAWSプロバイダーアカウントで、不要なポーリング統合をすべて無効にする。 いくつかの統合は、メトリックストリームに完全に置き換えられていないため、まだ有効化する必要があることを忘れないでください 。
クエリ、ダッシュボード、アラートに関する考察
AWS Metric Streamsの統合では、Metric APIを使用して次元メトリック形式のメトリックをプッシュします。
ポーリングベースの統合は、イベント（たとえば、 ComputeSampleイベント）に基づいてメトリクスをプッシュし、将来的にディメンションメトリクスに移行されます。
この移行を支援するために、私たちは、透過的に任意のフォーマットでクエリーを書くことができるメカニズム（シミングと呼ばれる）を提供しています。そして、これらのクエリは、利用可能なソース（メトリクスまたはイベント）に基づいて期待通りに処理される。このメカニズムは、イベントからメトリクスへ、あるいはその逆と、両方向に機能する。
ヒント
お客様が AWS CloudWatch メトリクス ストリーム統合 (ディメンション メトリクス形式) でイベントベースのクエリ (* サンプル) を使用できるようにするクエリ メカニズムの制限の詳細をご覧ください。
ポールベースの統合機能から移行する場合は、以下の点を考慮してください。
ダッシュボード: カスタム
ポーリングベースの AWS 統合イベントを使用するものは、引き続き期待どおりに機能します。
アラート: ポーリングベースのAWSイベントを使用したアラート条件は引き続き機能します。これらをディメンション・メトリック形式（NRQLをソースとして使用）に適応させることをお勧めします。
Entities: New Relic Explorerでは、最大で24時間、重複したエンティティが表示されることがあります。
属性: ポーリングベースの AWS 統合では、収集されたリソース タグのプレフィックスとして
label.が付けられますが、AWS CloudWatch Metric Streams 統合では、収集されたリソース タグのプレフィックスとしてtags.が付けられます。同じ AWS アカウントに対して両方の統合が有効になっている場合、イベント形式を使用すると、リソース タグが両方のプレフィックスの下に表示されます。
メトリクスストリームに置き換わらない統合機能
AWS CloudWatch Metric Streamsの統合は、CloudWatchメトリクスに重点を置いています。その結果、AWSサービスから完全な可視性を得るには、以下の統合を構成して有効にする必要があります。
サービスAPIに基づくポーリング統合：
- AWS Billing
- AWS CloudTrail
- AWS Health
- AWS Trusted Advisor
- AWS X-Ray
CloudWatch Logsに基づく統合、 Lambda経由でNew Relicに転送：
- AWSRDS拡張
- AWS VPC フローログ
CloudWatchメトリクスストリームでは利用できないメトリクス
メトリクスが 2 時間以上の遅延で AWS CloudWatch メトリクス ストリームに利用できる場合、これらのメトリクスはストリームに含まれません。
2 時間後に集計および公開されるメトリクスを含む可能性がある AWS 名前空間の例には、AWS DMS、AWS RDS、AWS DocDB、AWS S3、および AWS DAX が含まれます。詳細については、 AWS のドキュメントを参照してください。