ホストからの Prometheus および OpenMetrics メトリクスの収集
Datadog の調査レポート: サーバーレスの状態 レポート: サーバーレスの状態

ホストからの Prometheus および OpenMetrics メトリクスの収集

Datadog Agent と Datadog-OpenMetrics または Datadog-Prometheus インテグレーションを併用して、ホストで実行されているアプリケーションから、公開されている Prometheus および OpenMetrics メトリクスを収集します。

概要

バージョン 6.5.0 より、Agent には OpenMetrics および Prometheus チェックが用意され、Prometheus エンドポイントをスクレイピングできます。Prometheus テキスト形式を効率よくフルにサポートできるため、Datadog では OpenMetrics チェックの 使用をお勧めします。カスタムチェックの記述を含む OpenMetricsCheck インターフェイスの高度な使用方法については、開発ツールのセクションを参照してください。Prometheus チェックは、メトリクスのエンドポイントがテキスト形式をサポートしていない場合にのみ使用してください。

このページでは、これらのチェックの基本的な使用方法について説明します。これにより、Datadog 内のすべての Prometheus 公開メトリクスをインポートできるようになります。

セットアップ

インストール

対応するオペレーティングシステムに Datadog Agent をインストールします。OpenMetrics および Prometheus チェックは Datadog Agent パッケージに含まれています。コンテナまたはホストに追加でインストールする必要はありません。

構成

公開されたメトリクスを収集するには

  1. Agent の構成ディレクトリのルートにある conf.d/ フォルダーの openmetrics.d/conf.yaml ファイルを編集します。使用可能なすべての構成オプションの詳細については、サンプル openmetrics.d/conf.yaml を参照してください。これは、インテグレーションを有効にするために必要な最低限の構成です。

    init_config:
    
    instances:
        - prometheus_url: 'localhost:<PORT>/<ENDPOINT>'
          namespace: '<NAMESPACE>'
          metrics:
              - '<METRIC_TO_FETCH>': '<DATADOG_METRIC_NAME>'

次の構成プレースホルダー値を使用します。

| プレースホルダー             | 説明                                                                                                                                                                                                            |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `<ポート>`                | Prometheus エンドポイントにアクセスするために接続するポート。                                                                                                                                                         |
| `<エンドポイント>`            | コンテナによって提供されるメトリクスの URL(Prometheus 形式)。                                                                                                                                                     |
| `<ネームスペース>`           | Datadog で表示するときに、すべてのメトリクスの前にネームスペースをプレフィックスとして設定します。                                                                                                                                                   |
| `<フェッチするメトリクス>`     | Prometheus エンドポイントからフェッチされる Prometheus メトリクスキー。                                                                                                                                                     |
| `<DATADOG_メトリクス名>` | オプションパラメーター。設定すると、`<フェッチするメトリクス>` メトリクスキーは Datadog の `<DATADOG_メトリクス名>` に変換されます。<br>このオプションを使用しない場合は、`key:value` ペアではなく、文字列のリストを渡します。 |
  1. Agent を再起動すると、メトリクスの収集が開始されます。

利用可能なパラメーター

インスタンスで使用可能なパラメーターを以下にリストします。

名前タイプ要否デフォルト値説明
prometheus_url文字列必須なしPrometheus/OpenMetrics がアプリケーションメトリクスを公開する URL。
namespace文字列必須なしすべてのメトリクスネームスペースの前に付加されるネームスペース。メトリクスは、namespace.metric_name の形式で収集されます。
metrics文字列リストまたは key:value 要素必須なしPrometheus エンドポイントから取得されるメトリクスの <フェッチするメトリクス>: <新しいメトリクス名> ペアのリスト。
<新しいメトリクス名> はオプションです。設定すると、Datadog での名前が変換されます。このリストには少なくとも 1 つのメトリクスを指定する必要があります。
prometheus_metrics_prefix文字列オプションなし公開された Prometheus/OpenMetrics メトリクスのプレフィックス。
health_service_checkbooleanオプションtruePrometheus エンドポイントの健全性について報告するサービスチェックを送信します。チェックの名前は <ネームスペース>.prometheus.health です。
label_to_hostname文字列オプションなしホスト名を 1 つのラベルの値で上書きします。
label_joinsオブジェクトオプションなしlabel_joins を使用すると、メトリクスを対象として指定して、そのラベルを 1:1 マッピングを介して取得できます。
labels_mapperkey:value 要素のリストオプションなしlabels_mapper を使用すると、一部のラベルの名前を変更できます。形式: <名前を変更するラベル>: <新しいラベル名>
type_overrideskey:value 要素のリストオプションなしtype_overrides を使用すると、Prometheus ペイロードのタイプを上書きするか、またはタイプが指定されていないメトリクスにタイプを適用できます (デフォルトでは無視されます)。
サポートされている <メトリクスタイプ> は、gaugemonotonic_counthistogram、および summary です。
tagskey:value 要素のリストオプションなしこのインテグレーションによって送信されるすべてのメトリクス、イベント、およびサービスチェックにアタッチされるタグのリスト。
タグ付けについての詳細
send_distribution_bucketsbooleanオプションfalsesend_distribution_bucketstrue に設定すると、OpenMetrics ヒストグラムを送信してディストリビューションメトリクスに変換できます。
send_histograms_bucketstrue に設定する必要があります (デフォルト値)。
send_distribution_counts_as_monotonicbooleanオプションfalsesend_distribution_counts_as_monotonictrue に設定し、OpenMetrics のヒストグラム/サマリーカウントを単調カウントとして送信します。
send_histograms_bucketsbooleanオプションtruesend_histograms_bucketstrue に設定すると、ヒストグラムバケットを送信できます。
send_monotonic_counterbooleanオプションtrueカウントを単調カウントとして送信する方法については、GitHub の関連事項を参照してください。
exclude_labels文字列のリストオプションなし除外されるラベルのリスト。
ssl_cert文字列オプションなしPrometheus エンドポイントがセキュリティ保護されている場合、構成するための設定は以下のとおりです。
設定は、証明書へのパス (秘密キーを指定する必要あり)、または証明書と秘密キーの両方を含むファイルへのパスのいずれかです。
ssl_private_key文字列オプションなし証明書が秘密キーを含んでいない場合に必要です。
警告: ローカル証明書への秘密キーは暗号化されていないことが必要です。
ssl_ca_cert文字列オプションなしカスタム証明書を生成するために使用する、信頼されている CA へのパス。
prometheus_timeout整数オプション10Prometheus/OpenMetrics クエリのタイムアウトを秒単位で設定します。
max_returned_metrics整数オプション2000デフォルトで、メトリクスのチェックは 2000 個に制限されます。必要な場合は、この制限を引き上げてください。
bearer_token_authbooleanオプションfalsebearer_token_authtrue に設定して、ベアラートークン認証のヘッダーに追加します。: bearer_token_path が設定されていない場合は、/var/run/secrets/kubernetes.io/serviceaccount/token がデフォルトのパスとして使われます。
bearer_token_path文字列オプションなしKubernetes サービスアカウントのベアラートークンファイルへのパス(ファイルが存在し正しくマウントされていることを確認してください)。: bearer_token_authtrue に設定し、認証のために HTTP ヘッダにトークンを追加できるようにします。

: send_distribution_buckets および send_distribution_counts_as_monotonic 以外のすべてのパラメーターは、OpenMetrics チェックと Prometheus チェックの両方でサポートされています。

はじめに

シンプルなメトリクスの収集

Prometheus によって公開されたメトリクスの収集を開始するには、次の手順に従います。

  1. Prometheus Getting Started のドキュメントに従って、自分自身を監視する Prometheus のローカルバージョンを起動します。

  2. プラットフォームに Datadog Agent をインストールします

  3. Agent の構成ディレクトリのルートにある conf.d/ フォルダーの openmetrics.d/conf.yaml ファイルを次の内容で編集します。

    init_config:
    
    instances:
        - prometheus_url: http://localhost:9090/metrics
          namespace: 'documentation_example'
          metrics:
              - promhttp_metric_handler_requests_total: prometheus.handler.requests.total
  4. Agent を再起動します

  5. メトリクスサマリーページに移動して、収集されたメトリクスを確認します: prometheus_target_interval_length_seconds*

カスタムインテグレーションを公式インテグレーションに

デフォルトでは、汎用の Prometheus チェックによって取得されるすべてのメトリクスが、カスタムメトリクスだと見なされます。既製ソフトウェアを監視されて、公式のインテグレーションにするべきだと思われた場合は、ぜひご提供をお願いします

公式インテグレーションは、それぞれ専用のディレクトリを持ちます。汎用のチェックには、デフォルトの構成とメトリクスメタデータをハードコードするためのデフォルトのインスタンスメカニズムがあります。たとえば、kube-proxy インテグレーションを参照します。

その他の参考資料