概要

任意の OpenMetrics または Prometheus エンドポイントからカスタムメトリクスを抽出します。

このインテグレーションは、Prometheus エクスポジション形式と OpenMetrics 仕様標準の両方に対応しています。

セットアップ

ホストで実行されている Agent 用にこのチェックをインストールおよび構成する場合は、以下の手順に従ってください。コンテナ環境の場合は、オートディスカバリーのインテグレーションテンプレートのガイドを参照してこの手順を行ってください。

このインテグレーションには、最新モード (ターゲットエンドポイントを指すように openmetrics_endpoint を設定することで有効) とレガシーモード (代わりに prometheus_url を設定することで有効) があります。すべての最新機能を利用するために、Datadog は最新モードを有効にすることを推奨します。詳しくは、OpenMetrics ベースのインテグレーションにおける最新バージョニングとレガシーバージョニングを参照してください。

インストール

OpenMetrics チェックは、Datadog Agent v6.6.0 以降にパッケージ化されています。

構成

Agent の構成ディレクトリの root にある conf.d/openmetrics.d/conf.yaml ファイルを編集します。利用可能なすべての構成オプションについては、サンプル openmetrics.d/conf.yaml を参照してください。これは、Datadog Agent バージョン 7.32.0 の時点での最新の OpenMetrics チェックの例です。以前にこのインテグレーションを実装していた場合は、レガシー例を参照してください。

それぞれのインスタンスには、以下のパラメーターが必要です。

Datadog Agent v7.32.0 以降では、OpenMetrics 仕様標準に従って、_total で終わるカウンター名からは _total サフィックスを省略して指定する必要があります。例えば、promhttp_metric_handler_requests_total を収集するには、メトリクス名 promhttp_metric_handler_requests を指定します。これにより、メトリクス名に .count を付加した promhttp_metric_handler_requests.count が Datadog に送信されます。

このチェックは、1 インスタンスあたり 2000 メトリクスの制限があります。返されたメトリクスの数は、Datadog Agent の status コマンドを実行した際に表示されます。構成を編集することで、関心のあるメトリクスを指定することができます。収集するメトリクスのカスタマイズ方法については、Prometheus および OpenMetrics メトリクスの収集をご覧ください。

制限以上のメトリクスを監視する必要がある場合は、Datadog のサポートチームまでお問い合わせください。

検証

Agent の status サブコマンドを実行し、Checks セクションで openmetrics を探します。

収集データ

メトリクス

OpenMetrics チェックによって収集されたメトリクスはすべて、カスタムメトリクスとして Datadog に転送されます。

イベント

OpenMetrics チェックには、イベントは含まれません。

サービスチェック

OpenMetrics チェックには、サービスのチェック機能は含まれません。

トラブルシューティング

高いカスタムメトリクスの課金

OpenMetrics の構成において、metrics オプションに一般的なワイルドカード値を使用すると、カスタムメトリクスの課金に大きな影響を及ぼします。

Datadog では、より正確な収集のために、特定のメトリクス名またはメトリクス名の部分一致を使用することを推奨しています。

型のないメトリクスの欠落

デフォルトでは、インテグレーションは、Prometheus エクスポジション上で型のないメトリクスをスキップします。型のないメトリクスを収集したい場合は、例えば metrics マッピングで明示的に型を指定する必要があります。例:

  metrics:
    - "<NAME_OF_METRIC_WITHOUT_TYPE>":
        "type": "gauge"

メトリクス名は正規表現として指定できるため、すべてのメトリクスを個別に列挙することなく、一連のメトリクスのタイプを指定することができます。

Agent 7.46 での OpenMetrics ペイロードのパースエラー

Agent のバージョン 7.46 で出荷されたこのインテグレーションのバージョンでは、メトリクスエンドポイントからメトリクスをリクエストする際、デフォルトで OpenMetrics 形式が優先されます。これは、Accept ヘッダを application/openmetrics-text;version=1.0.0,application/openmetrics-text;version=0.0.1;q=0.75,text/plain;version=0.0.4;q=0.5,*/*;q=0.1 に設定することで行います。これは、サーバーから受け取った Content-Type に基づいて、どのスクレーパーを使用するかを動的に決定することと組み合わせて、手動で設定する必要性を減らすために行われました。

以前のバージョンのデフォルトは text/plain で、通常、サーバーは Prometheus エクスポジション形式でメトリクスを返します。つまり、このバージョンのインテグレーションに更新すると、Prometheus 形式から OpenMetrics 形式に切り替わる可能性があります。

ほとんどの場合動作に変わりはありませんが、一部のアプリケーションでは Content-Type を設定して OpenMetrics 標準形式を使用することを示しているにも関わらず、完全には OpenMetrics に準拠していない形式のメトリクスを返すことがあります。このため、メトリクスのペイロードをパースする際に、インテグレーションがエラーを報告することがあります。

この新しいバージョンで OpenMetrics エンドポイントをスクレイピングしたときにパースエラーが表示される場合は、コンフィギュレーションファイルの headers オプションを使用して、インテグレーションが送信する Accept ヘッダーを手動で text/plain に設定することで、より厳密でない Prometheus 形式を強制的に使用することができます。例:

## ここで定義されたすべてのオプションは、すべてのインスタンスで利用可能です。
#
init_config:
  ...
instances:
  - openmetrics_endpoint: <OPENMETRICS_ENDPOINT>
    ...
    headers:
      Accept: text/plain

ご不明な点は、Datadog のサポートチームまでお問合せください。

その他の参考資料

• OpenMetrics チェックの構成
• カスタム OpenMetrics チェックの書き方