翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
以下のよくある質問とその回答は、Amazon Managed Service for Prometheus に関連するコストを理解して最適化するために役立つ可能性があります。
コストに影響する要因は何ですか?
ほとんどのお客様にとって、コストの大部分はメトリクスの取り込みに由来します。クエリの使用量が多いお客様の場合、処理されたクエリサンプル数に基づくコストも発生しますが、メトリクスのストレージがコスト全体に及ぼす影響は小規模です。これらのそれぞれにかかる料金の詳細については、Amazon Managed Service for Prometheus の製品ページの「料金
コストを削減する最善の方法は何ですか? どうすれば取り込みコストを下げることができますか?
ほとんどのお客様にとって、コストの大部分は取り込みレートです (メトリクスのストレージではありません)。取り込みレートを下げるには、収集頻度を低くする (収集間隔を大きくする) か、取り込むアクティブなシリーズの数を少なくします。
収集 (スクレイピング) 間隔は、収集エージェントから大きくすることができます。Prometheus サーバー (エージェントモードで実行) と AWS
Distro for OpenTelemetry (ADOT) コレクターの両方で scrape_interval 設定がサポートされています。例えば、収集間隔を 30 秒から 60 秒に増やすと、取り込みの使用量が半減します。
<relabel_config> を使用して、Amazon Managed Service for Prometheus に送信されるメトリクスをフィルタリングすることもできます。Prometheus エージェントの設定における再ラベル付けの詳細については、Prometheus ドキュメントの https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config
クエリコストを削減する最善の方法は何ですか?
クエリコストは、処理されたサンプルの数に基づきます。クエリの頻度を低くすると、クエリコストを削減できます。
クエリコストに最も大きく影響しているクエリをより明確に把握するには、サポート担当者に連絡してチケットを提出してください。Amazon Managed Service for Prometheus チームが、コストに最も大きく影響しているクエリを特定できるように支援します。
メトリクスの保持期間を短くした場合、合計請求額の削減につながりますか?
保持期間を短縮することはできますが、それによってコストが大幅に削減される可能性はほとんどありません。
保持期間を短縮 (または延長) する必要がある場合は、Retention time for ingested
data クォータを変更するサービス制限リクエスト
アラートクエリのコストを低く抑えるにはどうすればよいですか?
アラートにより、データに対するクエリが作成されるため、クエリのコストが増大します。アラートのクエリを最適化し、コストを削減するために使用できる戦略をいくつか紹介します。
-
Amazon Managed Service for Prometheus アラートの使用 - Amazon Managed Service for Prometheus 外のアラートシステムの場合、外部サービスは複数のアベイラビリティーゾーンやリージョンのメトリクスをクエリするため、耐障害性または高可用性を追加するために追加のクエリが必要になる場合があります。これには、高可用性のための Grafana でのアラートが含まれます。これにより、コストが 3 倍以上に増える場合があります。Amazon Managed Service for Prometheus のアラートは最適化されており、最小限のクエリ数で高可用性と耐障害性を実現します。
外部アラートシステムではなく、Amazon Managed Service for Prometheus のネイティブアラートを使用することをお勧めします。
-
アラート間隔の最適化 - アラートのクエリを最適化する 1 つの簡単な方法は、自動更新間隔を長くすることです。1 分ごとにクエリを実行するアラートがあっても、アラートが 5 分ごとにのみ必要である場合、自動更新間隔を長くすると、アラートのクエリコストを 5 分の 1 に縮小できます。
-
最適なルックバックの使用 - クエリのルックバックウィンドウが大きいほど、より多くのデータが取得されるため、クエリのコストが増えます。PromQL クエリのルックバックウィンドウが、アラートを必要とするデータに適切なサイズであることを確認します。例えば、次のルールでは、式に 10 分のルックバックウィンドウが含まれています。
- alert: metric:alerting_rule expr: avg(rate(container_cpu_usage_seconds_total[10m])) > 0 for: 2mexprをavg(rate(container_cpu_usage_seconds_total[に変更すると、クエリのコストを削減できます。5m])) > 0
一般的に、アラートルールを確認し、サービスに最適なメトリクスでアラートが発生していることを確認します。特に時間の経過とともにアラートを追加する場合、同じメトリクスまたは同じ情報を提供する同じメトリクスや複数のアラートに重複するアラートを作成してしまうことがよくあります。アラートのグループが同時に発生することが多い場合は、アラートを最適化し、すべてのアラートは含めないようにすることができます。
以上の推奨事項は、コストを削減するのに役立ちます。最終的には、システムの状態を理解するための適切なアラートセットを作成することおよびコストとのバランスを取る必要があります。
Amazon Managed Service for Prometheus でのアラートの詳細については、「アラートマネージャーを使用して Amazon Managed Service for Prometheus でアラートを管理および転送する」を参照してください。
コストのモニタリングにはどのようなメトリクスを使用できますか?
Amazon CloudWatch で IngestionRate をモニタリングすることで、取り込みコストを追跡できます。CloudWatch における Amazon Managed Service for Prometheus メトリクスのモニタリングの詳細については、「CloudWatch メトリクスを使用して Amazon Managed Service for Prometheus のリソースモニタリングする」を参照してください。
請求書はいつでも確認できますか?
は AWS 、使用量 AWS Cost and Usage Report を追跡し、請求期間内にアカウントに関連する推定請求額を提供します。詳細については、「 AWS コストと使用状況レポートユーザーガイド」の「 コストと使用状況レポートとは」を参照してください。 AWS
月初めの請求額が月末よりも高いのはなぜですか?
Amazon Managed Service for Prometheus では、取り込み量に応じた階層型の価格モデルが採用されているため、初期の使用量のコストの方が高い結果となります。使用量が上位の取り込み階層に達するにつれて、コストが下がります。取り込み階層を含む料金の詳細については、Amazon Managed Service for Prometheus の製品ページの「料金
注記
-
階層は、リージョン内での使用を対象としており、リージョン間での使用は対象外です。より低いレートを使用するには、リージョン内の使用量が次の階層に達する必要があります。
-
の組織では AWS Organizations、階層の使用状況は、アカウントごとではなく、支払者アカウントごとに集計されます (支払者アカウントは常に組織管理アカウントです）。組織内のすべてのアカウントで取り込まれたメトリクスの合計 (リージョン内) が次の階層に達すると、すべてのアカウントの課金レートが低くなります。
Amazon Managed Service for Prometheus のすべてのワークスペースを削除しましたが、まだ料金が請求されているようです。どうなっているのでしょうか?
この場合の 1 つの可能性は、削除したワークスペースにメトリクスを送信するように設定された AWS マネージドスクレイパーがまだあることです。「スクレイパーの検出と削除」の手順に従ってください。
