Datadog の Kubernetes エクスプローラーでは、Pod やデプロイメントなどの Kubernetes リソースの状態を監視できます。デプロイメント内の失敗した Pod のリソース仕様を表示する、ノードのアクティビティを関連ログに関連付ける、リソース使用率を追跡する、ワークロードを自動的にスケーリングする、エラーを修正することもできます。

構成

Kubernetes エクスプローラーを有効にする

ほとんどの Datadog Agent インストールでは、Kubernetes エクスプローラーはデフォルトで有効になっています。

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    clusterName: <CLUSTER_NAME>
    credentials:
      apiKey: <DATADOG_API_KEY>
      appKey: <DATADOG_APP_KEY>
  features:
    orchestratorExplorer:
      enabled: true

datadog:
  clusterName: <CLUSTER_NAME>
  # (...)
  processAgent:
    enabled: true
  orchestratorExplorer:
    enabled: true

export DD_API_KEY="<YOUR_DATADOG_API_KEY>"
export DD_SITE="<span class="js-region-param region-param" data-region-param="dd_site"></span>"

kubectl create secret generic datadog-secret \
  --namespace default \
  --from-literal="api-key=$DD_API_KEY" \
  --from-literal="dd-site=$DD_SITE"

mode: deployment
replicaCount: 1

image:
  repository: otel/opentelemetry-collector-contrib
  tag: 0.159.0
  pullPolicy: IfNotPresent

extraEnvs:
  - name: DD_API_KEY
    valueFrom:
      secretKeyRef:
        name: datadog-secret
        key: api-key
  - name: DD_SITE
    valueFrom:
      secretKeyRef:
        name: datadog-secret
        key: dd-site
  - name: K8S_NODE_NAME
    valueFrom:
      fieldRef:
        fieldPath: spec.nodeName

presets:
  kubernetesObjects:
    enabled: true
    watch: true

config:
  receivers:
    k8sobjects:
      interval: 3m

  processors:
    resource_detection:
      detectors: [k8s_api]
      override: false
    resource/add-cluster-name:
      attributes:
        - key: k8s.cluster.name
          value: "<YOUR_CLUSTER_NAME>"
          action: upsert

  exporters:
    otlp_http:
      endpoint: https://otlp.${env:DD_SITE}
      logs_endpoint: https://otlp.${env:DD_SITE}/v1/logs
      headers:
        dd-api-key: ${env:DD_API_KEY}
      compression: zstd
      compression_params:
        level: 3
      sending_queue:
        batch:
          sizer: bytes
          min_size: 2097152
          max_size: 4194304

  service:
    pipelines:
      logs:
        receivers: [k8sobjects]
        processors: [resource_detection, resource/add-cluster-name]
        exporters: [otlp_http]

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update

helm install deployment-collector open-telemetry/opentelemetry-collector \
  --namespace default \
  --values ./deployment-collector.yaml

processors:
  k8sattributes:
    auth_type: "serviceAccount"
    extract:
      metadata:
        - k8s.pod.name
        - k8s.pod.uid
        - k8s.deployment.name
        - k8s.namespace.name
        - k8s.node.name
        - k8s.replicaset.name
        - k8s.statefulset.name
        - k8s.daemonset.name
        - k8s.cronjob.name
        - k8s.job.name
        - k8s.container.name
    pod_association:
      - sources:
          - from: resource_attribute
            name: k8s.pod.uid
      - sources:
          - from: resource_attribute
            name: k8s.pod.ip
      - sources:
          - from: resource_attribute
            name: k8s.pod.name
          - from: resource_attribute
            name: k8s.namespace.name
      - sources:
          - from: connection

service:
  pipelines:
    logs:
      processors: [k8sattributes, resourcedetection, ...]
    metrics:
      processors: [k8sattributes, resourcedetection, ...]
    traces:
      processors: [k8sattributes, resourcedetection, ...]

./install

helm repo add jetstack https://charts.jetstack.io
helm repo update

helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager --create-namespace \
  --set crds.enabled=true

export DD_API_KEY="<YOUR_DATADOG_API_KEY>"
export DD_SITE="datadoghq.com"  # for example us3.datadoghq.com, datadoghq.eu

kubectl create namespace opentelemetry-operator-system \
  --dry-run=client -o yaml | kubectl apply -f -

kubectl create secret generic datadog-secret \
  --namespace opentelemetry-operator-system \
  --from-literal="api-key=$DD_API_KEY" \
  --from-literal="dd-site=$DD_SITE" \
  --dry-run=client -o yaml | kubectl apply -f -

mkdir -p deployment

# EKS, GKE, or AKS (resource detector auto-populates k8s.cluster.name):
cp examples/eks-deployment/values.yaml deployment/values.yaml
cp examples/gcp-deployment/values.yaml deployment/values.yaml
cp examples/aks-deployment/values.yaml deployment/values.yaml

# Other platforms (set the cluster name manually):
cp examples/manually-set-k8s-cluster-name/values.yaml deployment/values.yaml

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update

helm upgrade --install opentelemetry-kube-stack \
  open-telemetry/opentelemetry-kube-stack \
  --namespace opentelemetry-operator-system \
  --values ./values.yaml \
  --values ./deployment/values.yaml

リソースにカスタムタグを追加する

フィルタリングを容易にするために、DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS 環境変数を使用して Kubernetes リソースにカスタムタグを追加できます。これらのタグは Kubernetes エクスプローラーにのみ表示されます。

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    credentials:
      apiKey: <DATADOG_API_KEY>
      appKey: <DATADOG_APP_KEY>
  features:
    liveContainerCollection:
      enabled: true
    orchestratorExplorer:
      enabled: true
  override:
    agents:
      containers:
        processAgent:
          env:
            - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
              value: "tag1:value1 tag2:value2"
    clusterAgent:
      env:
        - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
          value: "tag1:value1 tag2:value2"

kubectl apply -n $DD_NAMESPACE -f datadog-agent.yaml

agents:
  containers:
    processAgent:
      env:
        - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
          value: "tag1:value1 tag2:value2"
clusterAgent:
  env:
    - name: "DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS"
      value: "tag1:value1 tag2:value2"

- name: DD_ORCHESTRATOR_EXPLORER_EXTRA_TAGS
  value: "tag1:value1 tag2:value2"

使用方法

ビュー

ページの左上隅にある [Select Resources] (リソースの選択) ドロップダウンメニューで、[Pods]、[Clusters] (クラスター)、[Namespaces] (ネームスペース)、およびその他の Kubernetes リソースを切り替えます。

それぞれのビューには、ステータス、名前、Kubernetes ラベルなどのフィールドごとにデータをよりよく整理するために役立つデータテーブルと、ポッドと Kubernetes クラスターの全体像を把握するための詳細なクラスターマップが含まれています。

これらのビューのフィルタリング方法の詳細については、「クエリフィルターの詳細」を参照してください。

機能およびファセットごとにグループ化する

Pod をタグ、Kubernetes ラベル、または Kubernetes アノテーションでグループ化してビューを集約することで、情報をより迅速に見つけられるようになります。グループ化を行うには、ページ右上の [Group by] (グループ化) バーを使用するか、特定のタグやラベルをクリックして、以下に示すようなコンテキストメニューのグループ化機能を使用します。

また、ページの左側にあるファセットを利用することで、リソースをグループ化したり、ポッドステータスが CrashLoopBackOff のポッドなど、最も気になるリソースをフィルタリングすることができます。

クラスターマップ

クラスターマップでは、Pod と Kubernetes クラスターの全体像を把握できます。カスタマイズされたグループやフィルターを使って、すべてのリソースを 1 つの画面にまとめて表示し、ノードの色に対応するメトリクスを選択することができます。

サークルまたはグループをクリックして詳細パネルを表示し、クラスターマップからリソースを調べます。

情報パネル

表内の任意の行、またはクラスターマップの任意のオブジェクトをクリックすると、特定のリソースに関する情報がサイドパネルに表示されます。

サイドパネルの [YAML] タブには、リソースの完全な定義が示されます。Agent バージョン 7.44.0 以降では、7 日間の定義履歴も含まれます。時間の経過による変化や異なるバージョン間での変更を比較できます。表示されている時刻は、リソースに変更が適用されたおおよその時間です。

関連性のない変更が多数表示されることを防ぐために、以下のフィールドのみに影響する更新は無視されます。

• metadata.resourceVersion
• metadata.managedFields
• metadata.generation
• metadata.annotations[“kubernetes.io/config.seen”]
• status

その他のタブには、選択したリソースのトラブルシューティングに関する詳細情報が示されます。

• [Logs] (ログ): コンテナまたはリソースのログを表示します。ログをクリックすると、ログエクスプローラーで関連するログが表示されます。
• [APM]: コンテナまたはリソースのトレース (日付、サービス、期間、メソッド、トレースのステータスコードを含む) が表示されます。
• [Metrics] (メトリクス): コンテナまたはリソースのライブメトリクスが表示されます。このタブでは、グラフを全画面表示したり、グラフのスナップショットを共有したり、グラフをエクスポートしたりすることができます。
• [Processes] (プロセス): このリソースのコンテナで実行されているすべてのプロセスが表示されます
• [Network] (ネットワーク): コンテナまたはリソースのネットワークパフォーマンスを表示します ([source] (送信元)、[destination] (送信先)、[sent and received volume] (送受信ボリューム)、[throughput] (スループット) の各フィールドを含む)。[Destination] フィールドを使用して DNS や ip_type などのタグで検索するか、このビューの [Group by] フィルターを使用して、pod_name や service などのタグでネットワークデータをグループ化します。
• [Events] (イベント): リソースのすべての Kubernetes イベントを表示します。
• [Monitors] (モニター): このリソースのタグ付けされた、スコープが設定された、またはグループ化されたモニターが表示されます。

このリソースの詳細なダッシュボードについては、このパネルの右上隅にある View Dashboard をクリックしてください。

リソース使用率

[Resource Utilization] (リソース使用率) ページについては、「リソース使用率」を参照してください。

[Kubernetes Explorer] (Kubernetes エクスプローラー) タブでは、リソース使用率メトリクスの選択を確認することができます。

これらの列はすべてソートをサポートしており、リソース使用率に基づいて個々のワークロードを特定するのに役立ちます。

クエリフィルターの詳細

ページの左上にある [Filter by] (フィルター) 検索バーにクエリを入力することで、表示されるリソースを絞り込むことができます。

構文

クエリフィルターは条件と演算子で構成されます。例:

条件

複数の種類の条件を使用できます。

注: 同じキーと値のペアがタグとラベル (またはアノテーション) の両方として見つかる場合があります。これはクラスターの構成方法によって異なります。

以下のリソース属性は、任意の文字列一致でサポートされています。

• metadata.name
• metadata.uid
• 以下で検出された IP アドレス:
  • Pod
  • ノード (内部および外部)
  • サービス (クラスター、外部、およびロードバランサー IP)

リソースを名前または IP で検索する場合、キーを指定する必要はありません。文字列検索に特定の特殊文字が含まれていない限り、引用符は不要です。

比較演算子

すべての条件で : 等価演算子がサポートされます。メトリクス値条件では、数値比較もサポートされています。

• :> より大きい (例: metric#cpu_usage_avg15:>0.9)
• :>= 以上
• :< より小さい
• :<= 以下

演算子

複合クエリで複数の条件を組み合わせるには、以下の大文字と小文字を区別するブール演算子を使用します。

OR 値の省略形

同じキーを共有する複数の条件は、それらがすべて OR 演算子を使用している場合、単一の条件にまとめることができます。たとえば、次のクエリの場合は:

app_name:web-server OR app_name:database OR app_name:event-consumer

次のように短縮できます。

app_name:(web-server OR database OR event-consumer)

ワイルドカード

* ワイルドカードを条件の一部として使用し、値とキーの両方で部分一致によるフィルタリングを行うことができます。以下はその例です。

• kube_job:stats-*: stats- で始まる kube_deployment タグ値を持つすべてのリソースを検索します。
• pod_name:*canary: canary で終わる pod_name 値を持つすべてのリソースを検索します。
• label#release:*: 値に関係なく、release ラベルを持つすべてのリソースを検索します。
• -label#*.datadoghq.com/*: Datadog スコープのラベルを持たないリソースを検索します。
• kube_*:*stats*canary: 値の途中に stats が含まれ、かつ canary で終わる、関連リソースタグ (kube_*) を持つリソースを検索します。

抽出されたタグ

Datadog Agent 内でユーザーが構成したタグに加え、リソース属性に基づいて生成されたタグが Datadog によって挿入されます。これは、検索やグループ化のニーズに役立ちます。これらのタグは、関連性がある場合に条件付きでリソースに追加されます。

すべてのリソース

すべてのリソースには kube_cluster_name タグが追加され、すべてのネームスペースリソースには kube_namespace タグが追加されます。

さらに、リソースには kube_<api_kind>:<metadata.name> タグが含まれています。たとえば、web-server-2 という名前のデプロイメントには、kube_deployment:web-server-2 タグが自動的に追加されます。

注: このパターンにはいくつかの例外があります。

• Pod は代わりに pod_name を使用します。
• VPA: verticalpodautoscaler。
• HPA: horizontalpodautoscaler。
• 永続ボリュームクレーム: persistentvolumeclaim。

リソースに付与されたラベルに基づいて、以下のタグも抽出されます。

Relationships (関係)

関連リソースは、相互にタグ付けされます。以下はその例です。

• 「XYZ」デプロイメントの一部である Pod には、kube_deployment:xyz タグが付けられます。
• サービス「A」を指す Ingress には、kube_service:a タグが付けられます。

「親」リソースから生成されたリソース (Pod やジョブなど) には、kube_ownerref_kind タグと kube_ownerref_name タグが付けられます。

ヒント: フィルタークエリのオートコンプリート機能を利用して、利用可能な関連リソースタグを見つけられます。kube_ と入力して、どのような結果が提示されるか確認してください。

Pod

Pod には以下のタグが付けられます。

• pod_name
• pod_phase (マニフェストから抽出)
• pod_status (kubectl と同様に計算)

ワークロード

ワークロードリソース (Pod、デプロイメント、ステートフルセットなど) には、[Resources Utilization] ページ内でサポートされていることを示す以下のタグが付与されます。

• resource_utilization (supported または unsupported)
• missing_cpu_requests
• missing_cpu_limits
• missing_memory_requests
• missing_memory_limits

条件

一部のリソースについては、特定の条件がタグとして抽出されます。たとえば、デプロイメントでは kube_condition_available タグが検出されます。タグの形式は常に kube_condition_<name> で、true または false の値をとります。

ヒント: オートコンプリート機能を使用して、kube_condition と入力し、結果を確認することで、特定のリソースタイプで利用可能な条件を確認することができます。

リソース固有のタグ

一部のリソースには、クラスターの環境に基づいて抽出される特定のタグがあります。上記の共有タグに加えて、以下のタグが利用可能です。

リソース使用率フィルター

以下のワークロードリソースは、リソース使用率メトリクスによって拡充されます。

• クラスター
• ノード
• Pod

これらのメトリクスは、過去 15 分間の平均値に基づいて、収集時に計算されます。metric#<metric_name><comparator><numeric_value> のように指定して、メトリクス値でフィルタリグできます。

• metric_nameは利用可能なメトリクスです (下記を参照)。
• comparator はサポートされている比較演算子です。
• numeric_value は浮動小数点値です。

Pod の場合は、以下のメトリクス名が利用可能です。

また、クラスターおよびノードでは、以下のメトリクスが利用可能です。

• cpu_usage_pct_alloc_avg15
• cpu_requests_pct_alloc_avg15
• mem_usage_pct_alloc_avg15
• mem_requests_pct_alloc_avg15

メトリクス単位

CPU メトリクスは、コア数として保存されます。

メモリメトリクスは、バイト数として保存されます。

パーセント (*_pct_*) は浮動小数点数として保存され、0.0 は 0%、1.0 は 100% です。値は、示されている 2 つのメトリクスの比率です。たとえば、cpu_usage_pct_limits_avg15 は usage / limits の値です。メトリクス値は、リクエストの CPU 使用率のパーセンテージのように、100% を超える場合があります。

注意事項と既知の問題

• データは一定の間隔で自動的に更新されます。
• 1000 個以上のデプロイメントまたは ReplicaSets があるクラスターでは、Cluster Agent による CPU 使用率の上昇が見られる場合があります。Helm チャートには、コンテナのスクラビングを無効にするオプションがあります。詳細については、Helm チャートリポジトリを参照してください。

参考資料

役立つドキュメント、リンク、記事:

Kubernetes オペレーターを監視して、アプリケーションがスムーズに動作するようにします。ブログ Kubernetes Observability の開始ラーニングセンター