オンプレミスKubernetes環境でのDatadogのデータ欠損を解消した話

はじめに

こんにちは。インフラ部のlyluckです。

この記事ではオンプレミスKubernetesクラスター環境のデータがDatadogへ送りきれず欠損した現象と、その解消方法について紹介します。

背景

ピクシブでは2023年からオンプレミスKubernetesクラスターが稼働し始めました。徐々にクラスター上で稼働するサービスが増えつつあります。今では10ノードほどの規模のクラスター上で10程度のサービスが稼働しており、常に300台ほどのPodが起動しています。

クラスターやクラスター上のリソースの監視にはDatadogを利用していましたが、時間帯によっては監視データが欠損することが問題になりました。

リソースの監視に支障をきたしたり、意図しないアラートのトリガーが発生してしまったりしたため、この問題に対応することになりました。

まとめ

クラスターチェックランナーを使ってKubernetes State Coreインテグレーションのチェックをnamespaceごとに分割したジョブで収集するようにしたところ、最終的にデータ欠損を解消できました。

クラスターチェックランナーとは

Kubernetesクラスターを監視するためのDatadogのソフトウェアの一種です。クラスターチェックの実行に特化しています。

クラスターチェックとは、1クラスターに1つのインスタンスのみ実行されるチェック(データ収集)のことです。1つのクラスターチェックがクラスター内のノードで実行されているなら、同時に別のノードでそのチェックが実行されることはありません。

Kubernetes State Coreインテグレーションとは

クラスターチェックの一種です。

このインテグレーションが収集するデータを活用することで、クラスターやクラスター上リソースの状態やパフォーマンスをリアルタイムで監視・視覚化することができます。

今回はこのインテグレーションに含まれるデータが欠損していました。

対策のねらい

Datadog Agentが一度に収集するデータ量を減らすことです。

クラスター上で稼働するサービスが増えたことで、Datadog Agentが収集するデータ量が増えました。それによってDatadog AgentがDatadogに送信するペイロードが大きくなったことがデータ欠損の原因ではないかと推測しました。

対策の詳細

具体的にどんなことをしたのかを説明します。

Datadog AgentはdatadogのHelmチャート3.65.0でデプロイしています。Kubernetesのバージョンは1.28.6です。

クラスターチェックランナーを有効化する

ドキュメントの通りにデプロイすることで有効化しました。

Kubernetes State Core インテグレーションをクラスターチェックランナーで実行する

datadog.kubeStateMetricsCore.useClusterCheckRunnersという設定項目があり、これをtrueにしてデプロイすることで実現しました。

Kubernetes State Core インテグレーションの設定を変更する

このインテグレーションにはこのような設定項目があります。この中のnamespacesという設定を使います。

init_config:
instances:
  - namespaces:
      - namespace1
    skip_leader_election: true
    cluster_check: true
  - namespaces:
      - namespace2
    skip_leader_election: true
    cluster_check: true

このような設定を適用することでチェックを名前空間ごとに分割して実行できます。クラスターチェックランナー内の /etc/datadog/conf.d/kubernetes_state_core.yaml にファイルを設置すれば変更できます。

しかし、Helmチャートから変更を適用することはできなさそうでした。クラスターチェックランナーのPodのcommandは以下です。

bash -c 'rm -rf /etc/datadog-agent/conf.d && touch /etc/datadog-agent/datadog.yaml && exec agent run'

/etc/datadog-agent/conf.d ディレクトリを消去してからDatadog Agentを起動しています。普通のAgentの場合、このディレクトリにDatadog Agentの設定ファイルを配置することでインテグレーションなどの設定を変更することができます。クラスターチェックランナーでは起動の直前に消去されるので、同じ方法では設定を変更できません。

これにはHelmチャートのクラスターチェックランナーのvolumesとenvを使ってagentコマンドをバイパスすることで対応しました。

apiVersion: v1
kind: ConfigMap
metadata:
  name: datadog-agent-clusterchecks-custom-agent
  namespace: datadog
data:
  agent: |
    #!/bin/bash
    if [ ! -e /etc/datadog-agent/conf.d ] ; then
      ln -sf /custom-confd /etc/datadog-agent/conf.d
    fi
    /opt/datadog-agent/bin/agent/agent $@

このようなConfigMapをvolumesでマウントし、本来のagentよりもこのスクリプトが優先されて参照されるようにPATHをenvを使って設定しました。

先述のチェックを名前空間ごとに分割して実行する設定を記述したファイルを/custom-confd/kubernetes_state_core.yamlに配置することで、 agent run 実行時に/custom-confd/kubernetes_state_core.yaml が/etc/datadog-agent/conf.d/kubernetes_state_core.yaml にリンクされます。これで設定を反映できました。

データ欠損の監視

Datadogメトリクス送信失敗の問題はDatadogでは監視できないので、また同様のデータ欠損が発生したら気づけるように監視を作りました。もともと別の用途でGoogle Cloudプロジェクトを使っていたため、Google Cloud Cloud Monitoringのアラートを利用しました。

情報源はagent statusコマンドです。このコマンドはDatadog Agentの状態を出力します。

agent status —json で結果をjsonで取得できます。このような形をしており、

{
  "metadata": { ... },
  "config": { ... },
  "runnerStats": { ... },
  // 略
  "forwarderStats": {
    // 略
    "Transactions": {
      "InputBytesByEndpoint": { ... },
      // 略
      "DroppedByEndpoint": {
        "series_v2": 100
      }
    }
  }
}

この中の forwarderStats.Transactions.DroppedByEndpoint の値はデータ欠損が生じると増加します。

この値をKubernetesのCronJobで定期的に収集し、ユーザー定義指標としてCloud Monitoringに送っています。