アマゾンウェブサービスは、アジャイルインフラストラクチャを迅速に実現するのに最適ですが、これはコスト管理や予測可能性の問題につながる可能性があります。 残念ながら、AWSリソースのモニタリングは、AWSデータをクエリするという行為自体がモニタリングサービスのコストよりも高くつく可能性があるため、予測できないコストのこの問題を悪化させる可能性があります。
任意 AWSモニタリング その塩に値するツールは、 CloudWatch API、特定のリソースについては、それが利用可能な唯一のデータであるためです。 ただし、AWSはこのAPIへのリクエストに対して課金します。つまり、AWSモニタリングには関連するCloudWatchコストが伴います。また、モニタリングの実行方法に注意を払わないと、APIコストだけでも高額になる可能性があります。
CloudWatchのコストだけで予算を浪費することを避けるために、モニタリングツールがCloudWatchデータを可能な限り効率的にリクエストするようにすることが重要です。 同様に、モニタリングツールがCloudWatchデータのリクエスト方法を柔軟に調整できることを確認して、環境に合わせてデータを最適化できるようにする必要があります。 LogicMonitorを使用して、コレクターベースの監視と 柔軟なポーリング間隔 監視対象データの価値を最大化しながら、CloudWatchのコストを簡単に最小化できます。
CloudWatch APIへのAWSリクエストは、メトリックスごとにXNUMXつのリクエストに制限されています。 これは、最終的に、モニタリングのためのCloudWatchのコストが 監視されるメトリックの数に正比例します。 各AWSサービスはCloudWatchAPIを介して異なる数のメトリクスを公開するため、コストはこれらのサービス間で異なります。 例えば、 Elasticsearch デフォルトで12個のメトリクスをCloudWatchに発行しますが、 ラムダ 公開するのは4つだけです。同じリクエスト頻度を想定すると、可能なすべてのメトリックを監視する場合、Elasticsearchの監視コストはLambdaの3倍になります。
CloudWatchのコストも リクエストの頻度に正比例。 より少ない頻度でより多くのデータを要求することは可能ですが、リアルタイムのアラート評価を妨げ、監視されるデータの価値を低下させる可能性があります。 その目的に基づいて、特定のサービスではELBなどのより頻繁なデータ収集が保証されますが、S3などの他のサービスではより長い収集間隔が許容されます。 LogicMonitorの AWSデータソース これを念頭に置いて、デフォルトの収集間隔を設定してください。
CloudWatchAPIリクエストを考えると 01リクエストあたり$ .1000の費用、デフォルトのLogicMonitor AWSデータソースのデータポイントと収集間隔に基づいて、さまざまなサービスの価格を実際に計算できます。 この点を説明するために、監視する必要のある最も高価なサービスと最も安価なXNUMXつのサービスをそれぞれ示します。
トップXNUMX：
ElastiCache： Memcachedクラスターあたり$ 10.35 / 30日、Redisクラスターあたり$ 9.50 / 30日
RDS： RDSインスタンスあたり$ 6.90 / 30日
自動スケーリング （集計およびグループメトリック）：AutoScalingグループあたり$ 6.50 / 30日
ボトムXNUMX：
ラムダ： ラムダ関数あたり$ .35 / 30日
SNS： SNSトピックあたり$ .34 / 30日
S3： S02バケットあたり$ .3 / 30日
上記の情報を踏まえて、LogicMonitorがどのようにあなたの支出に見合うだけの価値を得るのを助けることができるかを以下に示します。
- CloudWatchを介して公開されたEC2メトリックを使用する代わりに、LogicMonitorコレクターを使用してEC2インスタンスをモニターします。 LogicMonitorのサーバーデータソースは、CloudWatchがEC2インスタンスに対して提供するよりも詳細な情報を提供します。 これは、Collector（右）を介して監視されたEC2インスタンスとCloudWatch（左）を介して監視されたECXNUMXインスタンスを並べて比較したものです。
2分ごとに1回メトリックを収集するデフォルトのAWS_EC30データソースは、EC2インスタンスごとに約$ 2/4.75日しかかかりません。 詳細なメトリクスを有効にしている場合は、AWS_EC30 CloudWatchデータソースを調整して、2分に2回の頻度で収集することができます。これには、ECXNUMXインスタンスごとに約$ XNUMX / XNUMX日かかります。 数百または数千のインスタンスがある場合、これは合計される可能性があります。 AWS環境にコレクターがすでにインストールされている場合は、AWS_ECXNUMXデータソースを無効にすることをお勧めします。これにより、監視対象のメトリクスを犠牲にすることなくコストを節約できます。 カスタムCloudWatchメトリクスがある場合は、 別のCloudWatchデータソースを作成する それらをキャプチャします。 - LogicMonitor Collectorを使用して、CloudWatchを介して公開されたRDSメトリックを優先してRDSインスタンスをモニターします。 これは推奨事項に似ています。 Aurora RDSインスタンスを除いて、LogicMonitor Collectorメトリックスは、RDSのCloudWatchレポートよりも包括的なデータベースパフォーマンスとヘルスメトリックスを提供します。 RDSインスタンスは最終的にAWSによって管理されているサーバーで実行されるため、CloudWatchはRDSのメモリとストレージの指標も報告します。 サーバーに直接アクセスできないため、これらのメモリとストレージのメトリクスはCloudWatch経由でのみ取得できます。 ただし、データベースのパフォーマンスと正常性のメトリックは、LogicMonitorコレクターデータソースを介して監視できます。 デフォルトのAWS_RDSDataSourceは毎分メトリックを収集し、約16のデータポイントを使用すると、RDSインスタンスあたり月額約7ドルの費用がかかります。 AWS環境にLogicMonitorコレクターがある場合は、メモリやストレージなどの基盤となるサーバーメトリックについてはAWS_RDSデータソースのみに依存し、データベースのパフォーマンスとヘルスメトリックについてはMySQL、Microsoft SQL Server、PostgreSQLデータソースを使用することをお勧めします。
- 可能な場合は、ポーリング間隔を増やしてください。 XNUMX分の粒度を必要としないリソースがいくつかある場合があります。 たとえば、DevおよびQA環境では、本番リソースほど細かくする必要はありません。 データソース定義でグローバルレベルでポーリング間隔を設定できますが、 カスタムプロパティを使用して、特定のグループやデバイス用にカスタマイズします。 たとえば、この特定のグループには、すべてのAWS_ELBメトリックに対して5分のポーリング間隔があります。これは、AWS_ELBデータソース定義で設定されたポーリング間隔をオーバーライドします。
- 可能な場合はデータポイントをトリミングします。 LogicMonitorのComplexデータポイントを利用して、CloudWatchデータに基づいてレートやその他の計算を取得できます。 複雑なデータポイントはCloudWatchへのリクエストを伴わないため、料金を支払う必要はありません。 つまり、CloudWatchから直接プルするのではなく、すべてのレートと計算を複雑なデータポイントとして確立する必要があります。 可能な場合はデフォルトのAWSデータソースを使用してこれを行いますが、カスタムメトリックを考慮することは特に重要です。 CloudWatchによってレポートされた特定のデータポイントが一部のリソースにとって価値がない場合もあります。 たとえば、開発/ QAリソースのレイテンシを知る必要がない場合があります。 その場合、データソースのクローンを作成して、次のように、元のデータポイントのサブセットのみを持つDev / QAバージョンを作成できます。
AWSモニタリングを最適化して請求額を最小限に抑えることに加えて、モニタリングすることをお勧めします AWSの請求 LogicMonitorのデータ自体。 LogicMonitorでリージョン、サービス、タグデータソースごとにAWSの請求を使用し、請求メトリックのしきい値を設定して、過剰な請求値や異常な請求値のアラートを受信するようにする必要があります。 毎日または毎週確認できるダッシュボードまたはレポートを設定することを検討してください。 これにより、CloudWatchの費用に対応し、より適切に管理できるようになるため、AWS環境で監視されているパフォーマンスデータの価値を維持しながら、費用を最小限に抑えることができます。
アラートや長期的なトレンドのためにCloudWatchからデータを取得するのは素晴らしいことですが、モニタリングツールが不要なAPI呼び出しでクラウドバジェット全体を消費しないようにしてください。
