Datadogでコンテナのダウンタイム設定ならラベルを使うべき

2021年08月20日2021年08月29日

Datadogでアラートなど設定して監視をするときは、モニタリングを使うことになります。
Kubernetesのコンテナ運用の場合、コンテナやPOD単位でCPUのしきい値などを指定することになると思いますが、
「このコンテナだけ夜間にバッチ処理走るから、アラートがなってしまう」ことがありました。

Datadogでは監視を設定しているモニタリングに対して、その時間だけアラートを止めることができるダウンタイムを設定することができます。
今回は特定のコンテナに対してアラートがならないよう、ダウンタイムを設定してみたいと思います。

ベストプラクティスはラベルでダウンタイムを指定すること

どんなPODにもラベルが付与してあるかと思います。

# manifest.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80


DatadogのAgentにはlabels:のappをkube_appとして取り込む設定があるので、その設定をhelmに追加しました。

# helm

# datadog.podLabelsAsTags -- Provide a mapping of Kubernetes Labels to Datadog Tags
podLabelsAsTags: #{}
  app: kube_app
#   release: helm_release
#   <KUBERNETES_LABEL>: <DATADOG_TAG_KEY>


app以外にもオリジナルのラベルを登録できるみたいです。
monitoring: falseとかもいいかと思いました。

監視しているモニタリング設定にkube_appを追加することでダウンタイムで指定することができます。

# Define the metric

( avg:kubernetes.cpu.usage.total{!kube_namespace:kube-system} by {container_name, kube_app}


ダウンタイム設定でscopeを指定するにはモニタリングでgroup_byされた値しか指定することができないので追加が必要でした。
ダウンタイムスコープ

コンテナ名で指定するのはヤバい

最初はコンテナ名でダウンタイムを設定していたのですが、コンテナ名ってユニークなサフィックスがつくんですよね。
コンテナって再起動するたびにそのサフィックスが変更されるので、その度にダウンタイム設定するのは現実的ではなかったです。

POD名で指定するのはヤバい

次に考えついたのがPOD名での指定。
でもPODもサフィックスついてるし、レプリカ数が増えればその都度追加していかなければ行けなかったです。

しかも設定できるscopeはいろいろと条件がありました。

  • 検索みたいに使えない pod_name: nginx-deployment-
  • 正規表現が使えない pod_name: nginx-deployment-\d
  • 複数指定するとAND条件になる podname: nginx-deployment-0, podname: nginx-deployment-1


たとえば、host:Xのダウンタイムをスケジュールし、host:Xとhost:Yの両方でホストトリガーによってグループ化されたマルチアラートモニターをスケジュールすると、Datadogはhost:Yの通知をトリガーしますが、host:Xの通知はトリガーしません。


コンテナはラベル管理が必須

コンテナは増えたり減ったり名前が変わったり、かなり柔軟に扱われます。
その都度、設定をイジイジするのは現実的じゃないですよね。
ラベルという概念を取り込むことで、楽に簡単に管理することができました。

Datadog以外でもラベルを使うことが多々あるため、ラベルの重要性を改めて実感しました。
適切なラベルの運用管理って何だろう。