Google Cloud Managed Service for Prometheus を使用して指標の取り込みを制御する

※この投稿は米国時間 2024 年 5 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud Monitoring は、デフォルトで、指標の取り込みエンドポイントに送信された正しい形式の指標をすべて受け入れて処理します。ただし、特定の状況下においては指標が大量に生成され、不要な支出が連続して発生する可能性があります。とりわけ、これは特に用途がない詳細な指標に当てはまります。費用を管理するには、プラットフォームのユーザーは、指標が取り込まれる前にフローを管理し、関連性がある有用な指標のみについて処理と請求が行われるようにする必要があります。

Managed Service for Prometheus の内部では Cloud Monitoring が使用されているため、サンプル単位で課金されます。そのため費用を管理するには、取り込まれるサンプル数を制御することが重要です。これを実現する主な方法として、入力のフィルタリングとサンプリング期間の長さ調整の 2 つがあります。

単純な例としては、サンプリング間隔を延長すると、取り込まれるサンプル数を劇的に削減でき、その結果として費用の大幅な削減につながります。

• サンプリング期間を 10 秒から 30 秒に変更すると、情報を大幅に損失することなくサンプル量を 66% 削減できます。

• サンプリング期間を 10 秒から 60 秒に変更すると、サンプル量を 83% 削減できます。

サンプルのカウント方法とサンプリング期間がサンプル数に与える影響の詳細については、取り込まれたサンプル数に基づく料金の例をご覧ください。

以前のブログ投稿では、指標管理、費用のかかる指標を特定する方法、カーディナリティを削減する方法について説明しました。このブログ投稿では、指標の取り込みを管理するための選択肢を確認し、費用の節約に役立つ Prometheus の実用的な例をいくつかご紹介します。

Kubernetes カスタム リソースを使用して取り込みを制御する

Managed Service for Prometheus の取り込みプロセスは、レート削減および時系列フィルタリングと非常に似ています。どちらも PodMonitoring または ClusterPodMonitoring いずれかのカスタム リソースに適用される構成を介して実装されるためです。ClusterPodMonitoring リソースは PodMonitoring リソースと同じインターフェースを提供しますが、検出対象の Pod を特定の Namespace に制限しません。ほとんどの場合、PodMonitoring リソースの使用をおすすめします。通常 ClusterPodMonitoring リソースは、K8s API からのクラスタに関する情報をレポートする、自然に名前空間にスコープが設定されないアイテム（Kube 状態指標など）に使用されるからです。

スクレイピング間隔の期間を延長する

以下の例では、PodMonitoring リソースのスクレイピング間隔を変更して、サンプル収集の頻度を減らしています。これと同様の基本的な手法を使用して、ClusterPodMonitoring リソースと取り込みフィルタを変更することが可能です。取り込みフィルタを変更する例については、この記事の後半で説明します。スクレイピング間隔を長くすることは、指標の収集をスロットリングするための最もシンプルな方法であるため、最初にご紹介します。

以下のマニフェストは、PodMonitoring リソースである prom-example を EXAMPLE Namespace 内で定義しています。このリソースは Kubernetes ラベルセレクタを使用して、Namespace にある、ラベルが app.kubernetes.io/name で値が prom-example のすべての Pod を検索します。一致する Pod が 30 秒ごとに、/metrics HTTP パスの metrics というポートでスクレイピングされます。スクレイピング間隔を 30 秒から 60 秒に延長するには、以下の 30s を 60s に変更するだけです。

kubectl は以下を適用します。

こうした変更を行った後は、ターゲット ステータス機能を有効にして変更のステータスを確認してから、PodMonitoring リソースまたは ClusterPodMonitoring リソース内のスクレイピング ターゲットのステータスを確かめることをおすすめします。これを行うには、OperatorConfig リソース内の features.targetStatus.enabled 値を true に設定します。注: ターゲット ステータスは、使用した後に無効にしてください。ノイズが多いため、継続的に運用すると費用がかさみます。

ターゲット ステータスを有効にするために、kubectl は以下を適用します。

数秒後、すべての有効な PodMonitoring または ClusterPodMonitoring リソースに Status.Endpoint Statuses フィールドが表示されます（構成されている場合）。

prom-example という名前の PodMonitoring リソースが NAMESPACE_NAME Namespace に存在する場合、次のコマンドを実行してステータスを確認できます。

入力のフィルタリング

サンプリング レートを制限するかわりに、取り込まれる前の受信指標をフィルタすることもできます。時系列指標がコレクタによって処理されないようにするための標準メソッドは、Prometheus ラベル変更ルールで許可リストの keep アクションまたは拒否リストの drop アクションを使用することです。このルールは、PodMonitoring または ClusterPodMonitoring リソースの metricRelabeling セクションに入ります。

以下の指標のラベル変更ルールは、foo_bar_、foo_baz_、foo_qux_ で始まる時系列をすべて除外します。

以下の指標のラベル変更ルールは、正規表現を使用して、指標の名前に基づいて保持する指標を指定します。たとえば、名前が kube_daemonset_ で始まる指標は保持されます。

また、ラベル値に基づいて特定の時系列を管理するルールを設定することもできます。たとえば、以下の指標のラベル変更ルールは、正規表現を使用してラベル「direction」の値が「destination」で始まるすべての時系列を除外します。

上記の例が示すように、指標の許可 / 拒否リストを作成することで簡単に取り込み対象を制御できます。

指標の取り込みを削減するのに、コンテンツをフィルタすべきか、またはスクレイピング レートを低減させるべきかを決めるのは、複雑な作業になる場合があります。サンプルレートの低減はかなりの広範にわたり影響がある一方、フィルタリングはより細かく制御できるうえ、より選択的なアプローチを取れます。フィルタリングの場合も、慎重な検討と計画が必要です。目安としては、スクレイピング間隔を 30 秒に設定してからコンテンツのフィルタリングを適用しますが、スクレピング間隔を 60 秒に変更する前に費用やメリットを分析します。30 秒または 60 秒のいずれかのデータ収集に関する明確なユースケースがあれば、意思決定のプロセスで非常に役立つでしょう。

この記事のリンク:

ー Cloud プラットフォームおよびインフラストラクチャ、戦略的クラウド エンジニア Andrew Gold