- 重要な情報
- はじめに
- 用語集
- ガイド
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- Service Management
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
Datadog Agent と Datadog-OpenMetrics または Datadog-Prometheus インテグレーションを併用して、Kubernetes 内で実行されているアプリケーションから、公開されている Prometheus および OpenMetrics メトリクスを収集します。
注: デフォルトでは、Prometheus の汎用チェックで取得されたすべてのメトリクスは、カスタムメトリクスとみなされます。
バージョン 6.5.0 より、Agent には OpenMetrics および Prometheus チェックが用意され、Prometheus エンドポイントをスクレイピングできます。Prometheus テキスト形式を効率よくフルにサポートできるため、Datadog では OpenMetrics チェックの 使用をお勧めします。カスタムチェックの記述を含む OpenMetricsCheck
インターフェイスの高度な使用方法については、開発ツールのセクションを参照してください。Prometheus チェックは、メトリクスのエンドポイントがテキスト形式をサポートしていない場合にのみ使用してください。
このページでは、このチェックの基本的な使用方法について説明します。これにより、カスタムメトリクスを Prometheus エンドポイントからスクレイピングできるようになります。
Datadog メトリクスにおける Prometheus および OpenMetrics メトリクスのマッピング方法に関する詳細は、Datadog メトリクスにおける Prometheus メトリクスのマッピングガイドを参照してください。
Kubernetes クラスターに Datadog Agent をデプロイします。OpenMetrics および Prometheus チェックは Datadog Agent パッケージに含まれています。コンテナまたはホストに追加でインストールする必要はありません。
OpenMetrics/Prometheus のメトリクスを公開する pod に以下の annotations
を適用し、オートディスカバリーを使用して OpenMetrics または Prometheus のチェックを構成します。
注: AD Annotations v2 は、インテグレーション構成を簡素化するために、Datadog Agent 7.36 で導入されました。Datadog Agent の以前のバージョンでは、AD Annotations v1 を使用してください。
# (...)
metadata:
#(...)
annotations:
ad.datadoghq.com/<CONTAINER_IDENTIFIER>.checks: |
{
"openmetrics": {
"init_config": {},
"instances": [
{
"openmetrics_endpoint": "http://%%host%%:%%port%%/<PROMETHEUS_ENDPOINT> ",
"namespace": "<METRICS_NAMESPACE_PREFIX_FOR_DATADOG>",
"metrics": [{"<METRIC_TO_FETCH>":"<NEW_METRIC_NAME>"}]
}
]
}
}
spec:
containers:
- name: '<CONTAINER_IDENTIFIER>'
# (...)
metadata:
#(...)
annotations:
ad.datadoghq.com/<CONTAINER_IDENTIFIER>.check_names: |
["openmetrics"]
ad.datadoghq.com/<CONTAINER_IDENTIFIER>.init_configs: |
[{}]
ad.datadoghq.com/<CONTAINER_IDENTIFIER>.instances: |
[
{
"openmetrics_endpoint": "http://%%host%%:%%port%%/<PROMETHEUS_ENDPOINT> ",
"namespace": "<METRICS_NAMESPACE_PREFIX_FOR_DATADOG>",
"metrics": [{"<METRIC_TO_FETCH>":"<NEW_METRIC_NAME>"}]
}
]
spec:
containers:
- name: '<CONTAINER_IDENTIFIER>'
コンフィギュレーションには次のプレースホルダー値を使用します。
プレースホルダー | 説明 |
---|---|
<CONTAINER_IDENTIFIER> | annotations で使用される識別子は、メトリクスを公開しているコンテナ name と一致しなければならない。 |
<PROMETHEUS_ENDPOINT> | コンテナによって処理されたメトリクスの URL パス (Prometheus 形式)。 |
<METRICS_NAMESPACE_PREFIX_FOR_DATADOG> | Datadog で表示するときに、すべてのメトリクスの前にネームスペースを付加します。 |
<METRIC_TO_FETCH> | Prometheus エンドポイントから取得される Prometheus メトリクスキー。 |
<NEW_METRIC_NAME> | Datadog の <METRIC_TO_FETCH> メトリクスキーを <NEW_METRIC_NAME> に変換します。 |
metrics
の構成は、カスタムメトリクスとして取得するメトリクスのリストです。取得する各メトリクスと Datadog で希望するメトリクス名をキー値のペアで、例えば {"<METRIC_TO_FETCH>":"<NEW_METRIC_NAME>"}
のように記載します。代わりに、正規表現として解釈されるメトリクス名の文字列のリストを提供し、現在の名前で必要なメトリクスをもたらすことができます。すべてのメトリクスが必要な場合は、"*"
ではなく、".*"
を使用します。
注: 正規表現では、多くのカスタムメトリクスを送信できる可能性があります。
namespace
や metrics
など、インスタンスで利用可能なパラメーターの一覧は、構成例 openmetrics.d/conf.yaml を参照してください。
Prometheus prometheus.yaml
を使用して、ポッドにオートディスカバリーの構成をした Prometheus Deployment の例を起動します。
注: AD Annotations v2 は、インテグレーション構成を簡素化するために、Datadog Agent 7.36 で導入されました。Datadog Agent の以前のバージョンでは、AD Annotations v1 を使用してください。
# (...)
spec:
template:
metadata:
annotations:
ad.datadoghq.com/prometheus-example.checks: |
{
"openmetrics": {
"instances": [
{
"openmetrics_endpoint": "http://%%host%%:%%port%%/metrics",
"namespace": "documentation_example_kubernetes",
"metrics": [
{"promhttp_metric_handler_requests": "handler.requests"},
{"promhttp_metric_handler_requests_in_flight": "handler.requests.in_flight"},
"go_memory.*"
]
}
]
}
}
spec:
containers:
- name: prometheus-example
# (...)
# (...)
spec:
template:
metadata:
annotations:
ad.datadoghq.com/prometheus-example.check_names: |
["openmetrics"]
ad.datadoghq.com/prometheus-example.init_configs: |
[{}]
ad.datadoghq.com/prometheus-example.instances: |
[
{
"openmetrics_endpoint": "http://%%host%%:%%port%%/metrics",
"namespace": "documentation_example_kubernetes",
"metrics": [
{"promhttp_metric_handler_requests": "handler.requests"},
{"promhttp_metric_handler_requests_in_flight": "handler.requests.in_flight"},
"go_memory.*"
]
}
]
spec:
containers:
- name: prometheus-example
# (...)
Prometheus Deployment を作成するコマンド:
kubectl create -f prometheus.yaml
Metric summary ページにアクセスし、このサンプルポッドから収集されたメトリクスを確認します。この構成では、promhttp_metric_handler_requests
、promhttp_metric_handler_requests_in_flight
、および go_memory
で始まるすべての公開メトリクスを収集することになります。
Prometheus Autodiscovery を使用して、Datadog Agent でネイティブ Prometheus アノテーション(prometheus.io/scrape
、prometheus.io/path
、prometheus.io/port
など)を検出し、Kubernetes で自動的に Prometheus メトリクスを収集するよう OpenMetrics チェックをスケジュールできます。
この機能を有効にする前に、まずどのポッドやサービスが prometheus.io/scrape=true
アノテーションを持っているかをチェックすることをお勧めします。これは以下のコマンドで行うことができます。
kubectl get pods -o=jsonpath='{.items[?(@.metadata.annotations.prometheus\.io/scrape=="true")].metadata.name}' --all-namespaces
kubectl get services -o=jsonpath='{.items[?(@.metadata.annotations.prometheus\.io/scrape=="true")].metadata.name}' --all-namespaces
Prometheus Scrape 機能が有効になると、Datadog Agent はこれらのリソースからカスタムメトリクスを収集します。これらのリソースからカスタムメトリクスを収集したくない場合は、このアノテーションを削除するか、高度な構成セクションで説明されているようにオートディスカバリールールを更新することができます。
Helm values.yaml
で、以下を追加します。
datadog:
# (...)
prometheusScrape:
enabled: true
serviceEndpoints: true
# (...)
Agent 用の DaemonSet マニフェスト daemonset.yaml
に、Agent コンテナ用の以下の環境変数を追加します。
- name: DD_PROMETHEUS_SCRAPE_ENABLED
value: "true"
- name: DD_PROMETHEUS_SCRAPE_VERSION
value: "2"
Cluster Agent が有効な場合、そのマニフェスト cluster-agent-deployment.yaml
内に、Cluster Agent コンテナ用の以下の環境変数を追加します。
- name: DD_PROMETHEUS_SCRAPE_ENABLED
value: "true"
- name: DD_PROMETHEUS_SCRAPE_SERVICE_ENDPOINTS
value: "true"
これにより、Datadog Agent がネイティブ Prometheus アノテーションのあるポッドを検出し、対応する OpenMetrics チェックを生成するよう指示します。
また、Datadog Cluster Agent(有効な場合)にネイティブ Prometheus アノテーションのあるサービスを検出し、対応する OpenMetrics チェックを生成するよう指示します。
prometheus.io/scrape=true
: 必須。prometheus.io/path
: 任意。デフォルトは /metrics
。prometheus.io/port
: 任意。デフォルトは %%port%%
で、container/service により置換されるテンプレート変数。このコンフィギュレーションでは、OpenMetrics インテグレーションのデフォルトコンフィギュレーションを使用して、公開されたすべてのメトリクスを収集するチェックを生成します。
values.yaml
の additionalConfigs
コンフィギュレーションフィールドで、ネイティブの Prometheus アノテーション以外にも高度な OpenMetrics チェックコンフィギュレーションまたはオートディスカバリーのカスタムルールを定義することができます。
additionalConfigs
は OpenMetrics チェックコンフィギュレーションとオートディスカバリーのルールを含む構造のリストです。
このページのパラメーターだけが、OpenMetrics v2 with Autodiscovery でサポートされており、構成リストで渡すことができます。
オートディスカバリーのコンフィギュレーションはコンテナ名、Kubernetes アノテーション、またはその両方に基づきます。kubernetes_container_names
および kubernetes_annotations
の両方が定義されている場合、AND のロジックが使用されます (両方のルールに一致する必要があります)。
kubernetes_container_names
は対象とするコンテナ名のリストで、正規表現形式です。kubernetes_annotations
には、ディスカバリーのルールを定義する include
と exclude
の 2 つのアノテーションマップが含まれます。注: Datadog Agent コンフィギュレーションでの kubernetes_annotations
のデフォルト値は次の通りです:
kubernetes_annotations:
include:
prometheus.io/scrape: "true"
exclude:
prometheus.io/scrape: "false"
例:
この例では、アノテーション app=my-app
が付いたポッドで実行される my-app
という名前のコンテナを対象とする高度なコンフィギュレーションを定義しています。send_distribution_buckets
オプションを有効化し、5 秒のカスタムタイムアウトを定義することで、OpenMetrics チェックのコンフィギュレーションも同様にカスタマイズすることができます。
datadog:
# (...)
prometheusScrape:
enabled: true
serviceEndpoints: true
additionalConfigs:
-
configurations:
- timeout: 5
send_distribution_buckets: true
autodiscovery:
kubernetes_container_names:
- my-app
kubernetes_annotations:
include:
app: my-app
Agent と Cluster Agent のマニフェストの DD_PROMETHEUS_SCRAPE_CHECKS
環境変数で、ネイティブの Prometheus アノテーション以外にも高度な OpenMetrics チェックコンフィギュレーションまたはオートディスカバリーのカスタムルールを定義することができます。
DD_PROMETHEUS_SCRAPE_CHECKS
は OpenMetrics チェックコンフィギュレーションとオートディスカバリーのルールを含む構造のリストです。
このページのパラメーターだけが、OpenMetrics v2 with Autodiscovery でサポートされており、構成リストで渡すことができます。
オートディスカバリーのコンフィギュレーションはコンテナ名、Kubernetes アノテーション、またはその両方に基づきます。kubernetes_container_names
および kubernetes_annotations
の両方が定義されている場合、AND のロジックが使用されます (両方のルールに一致する必要があります)。
kubernetes_container_names
は対象とするコンテナ名のリストで、正規表現形式です。kubernetes_annotations
には、ディスカバリーのルールを定義する include
と exclude
の 2 つのアノテーションマップが含まれます。注: Datadog Agent コンフィギュレーションでの kubernetes_annotations
のデフォルト値は次の通りです:
- name: DD_PROMETHEUS_SCRAPE_CHECKS
value: "[{\"autodiscovery\":{\"kubernetes_annotations\":{\"exclude\":{\"prometheus.io/scrape\":\"false\"},\"include\":{\"prometheus.io/scrape\":\"true\"}}}}]"
例:
この例では、アノテーション app=my-app
が付いたポッドで実行される my-app
という名前のコンテナを対象とする高度なコンフィギュレーションを定義しています。send_distribution_buckets
オプションを有効化し、5 秒のカスタムタイムアウトを定義することで、OpenMetrics チェックのコンフィギュレーションも同様にカスタマイズすることができます。
- name: DD_PROMETHEUS_SCRAPE_ENABLED
value: "true"
- name: DD_PROMETHEUS_SCRAPE_CHECKS
value: "[{\"autodiscovery\":{\"kubernetes_annotations\":{\"include\":{\"app\":\"my-app\"}},\"kubernetes_container_names\":[\"my-app\"]},\"configurations\":[{\"send_distribution_buckets\":true,\"timeout\":5}]}]"
- name: DD_PROMETHEUS_SCRAPE_VERSION
value: "2"
デフォルトでは、汎用の Prometheus チェックによって取得されるすべてのメトリクスが、カスタムメトリクスだと見なされます。既製ソフトウェアを監視されて、公式のインテグレーションにするべきだと思われた場合は、ぜひご提供をお願いします。
公式インテグレーションは、それぞれ専用のディレクトリを持ちます。汎用のチェックには、デフォルトの構成とメトリクスメタデータをハードコードするためのデフォルトのインスタンスメカニズムがあります。たとえば、kube-proxy インテグレーションを参照します。