使用Datadog的AutoDiscovery功能，自动监控Kubernetes的Pod
动机 jī)
Prometheus 中有一个功能叫做服务发现，它可以自动检测并添加监视目标节点。
在中文中，只需要一种选择，将以下内容进行释义：(https://prometheus.io/docs/prometheus/latest/configuration/configuration/ 的_sds_config将是这些设置的配置。)
https://prometheus.io/docs/prometheus/latest/configuration/configuration/的_sds_config将是这些设置的配置。
最近，随着 Kubernetes 等 Docker 编排工具的普及，监控对象不断动态变化的环境越来越多。因此，具备自动缩放和自愈功能的监控工具的必要性也越来越高。
因为我个人喜欢Datadog，所以我一直希望它也具备类似的功能。但令我欣喜的是，Datadog也提供了AutoDiscovery功能，通过使用它，可以实现类似的效果。
这里假设在Kubernetes环境中操作，并且将要介绍Docker的自动发现设置方法。
组成 (zǔ
我会简洁地介绍一下Kubernetes，通过使用Kubernetes的DaemonSet功能，您可以在一个主机实例上仅部署一个特定的Docker镜像。
通常，类似于Datadog的管理类Docker镜像，只需要在每个主机实例上运行一个。对于这种情况，常见的做法是将其配置为DaemonSet。（类似地，Fluentd等也经常采用这种配置方式）。
在这个例子中
-
- daemonset: datadog
- deployment: nginx
我们将在Kubernetes上进行配置，并使用Datadog来监控每个Nginx。
设置
命名空间
尽管没有特别必要，但在这里我们将使用sada4j。
apiVersion: v1
kind: Namespace
metadata:
name: sada4j
守护进程集
我将对Datadog进行配置。
因为提前准备好了经过优化的docker-dd-agent镜像，所以可以直接使用该镜像。
在环境变量中加入API密钥和在Kubernetes上运行所需的配置。
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
name: dd-agent
namespace: sada4j
spec:
template:
metadata:
labels:
app: dd-agent
name: dd-agent
spec:
containers:
- image: datadog/docker-dd-agent:latest
imagePullPolicy: Always
name: dd-agent
ports:
- containerPort: 8125
name: dogstatsdport
protocol: UDP
env:
- name: API_KEY
value: "<your api key>"
- name: KUBERNETES
value: "yes"
- name: SD_BACKEND
value: "docker"
- name: KUBERNETES_KUBELET_HOST
valueFrom:
fieldRef:
fieldPath: status.hostIP
- name: SD_CONFIG_BACKEND
value: "etcd"
- name: SD_BACKEND_HOST
value: "127.0.0.1"
- name: SD_BACKEND_PORT
value: "4001"
volumeMounts:
- name: dockersocket
mountPath: /var/run/docker.sock
- name: procdir
mountPath: /host/proc
readOnly: true
- name: cgroups
mountPath: /host/sys/fs/cgroup
readOnly: true
volumes:
- hostPath:
path: /var/run/docker.sock
name: dockersocket
- hostPath:
path: /proc
name: procdir
- hostPath:
path: /sys/fs/cgroup
name: cgroups
部署
这里的目的是启动nginx并启用/nginx_status。
其他各种设置值都是一些草率而不适合服务运营的设置。
apiVersion: v1
kind: ConfigMap
metadata:
name: sada4j-nginx
namespace: sada4j
data:
nginx.conf: |-
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server {
listen 80;
location /nginx_status {
stub_status on;
access_log off;
}
}
}
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: sada4j-nginx
namespace: sada4j
spec:
replicas: 2
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
type: RollingUpdate
template:
metadata:
labels:
cluster_name: dev-sada4j-nginx
env: dev
project: sada4j
tier: app
annotations:
service-discovery.datadoghq.com/frontend.check_names: '["nginx"]'
service-discovery.datadoghq.com/frontend.init_configs: '[{}]'
service-discovery.datadoghq.com/frontend.instances: '[{"nginx_status_url": "http://%%host%%:%%port%%/nginx_status"}]'
spec:
containers:
- name: frontend
image: nginx:alpine
ports:
- containerPort: 80
volumeMounts:
- name: nginx-config
mountPath: /etc/nginx/nginx.conf
subPath: nginx.conf
volumes:
- name: nginx-config
configMap:
name: sada4j-with-nginx
---
apiVersion: v1
kind: Service
metadata:
name: sada4j-nginx
namespace: sada4j
spec:
type: LoadBalancer
ports:
- port: 80
targetPort: 80
selector:
cluster_name: dev-sada4j-nginx
设置文件很长，但以下是重点部分。
annotations:
service-discovery.datadoghq.com/frontend.check_names: '["nginx"]'
service-discovery.datadoghq.com/frontend.init_configs: '[{}]'
service-discovery.datadoghq.com/frontend.instances: '[{"nginx_status_url": "http://%%host%%:%%port%%/nginx_status"}]'
在Kubernetes的annotations中，记录了与该pod的监控设置相关的信息。
通过这样做，Datadog的代理程序可以了解要监视的容器镜像以及要监视的内容。
每个设置值都需要按照以下的设置来进行。
service-discovery.datadoghq.com/.check_names
監視対象のスクリプトの名前です。datadog-dd-agent に同梱されているか、 datadog の docker image 内の /etc/dd-agent/checks.d/ 配下に設置されている checks スクリプトで同名のものがあれば、ここで指定された名前の監視スクリプトを実行します。
service-discovery.datadoghq.com/.init_configs
監視処理を行うスクリプトの init_config に渡すパラメータを設定します。何を渡せるかは監視スクリプトの作り次第になります。
https://docs.datadoghq.com/ja/guides/agent_checks/#init-config
nginx の監視スクリプトには特に init_config に渡せる値はないので空の連想配列を渡しています。
service-discovery.datadoghq.com/.instances
監視処理を行うスクリプトの instances に渡すパラメータを設定します。何を渡せるかは監視スクリプトの作り次第になります。
https://docs.datadoghq.com/ja/guides/agent_checks/#instances
nginx の監視スクリプトでは、監視対象の nginx のURL を指定できる ( nginx_status_url ) ので、上記例ではそちらを設定しています。
在进行设置时，需要注意以下容易出现问题的情况。
container_name の部分は、 containers に記述している name の値と一致している必要があります。
上記例だと frontend
一つの annotation 記述で、複数の監視スクリプトを指定することが出来ます。
ex. service-discovery.datadoghq.com/frontend.check_names: ‘[“nginx”, “jmx”]’
etcd にこちらの情報が書き込まれるのですが、左辺の値が key 文字列として用いられるので、複数の監視スクリプトを設定する場合は上記のようにしないとうまく動きません。
通过进行上述设置，在应用容器镜像时或增加容器镜像数量时，自动添加的容器将成为监视对象。
确认行动
为了确保监控脚本是否正确应用了AutoDiscovery的设置，确认变得相当麻烦。但可以通过以下两个角度进行确认。
确认是否向Datadog发送了值
可以通过使用Metrics Explorer等工具来确认所发送到Datadog的预期值是否正确。
确认 datadog-agent info 命令的结果
当以daemonset形式启动的dd-agent的docker容器中，执行命令datadog-agent info，即可查看dd-agent当前正在收集的指标的列表。
如果在上述设置示例中包含了nginx的脚本，那就没问题。
$ /etc/init.d/datadog-agent info
====================
Collector (v 5.21.1)
====================
(snip.)
Checks
======
nginx (5.21.1)
--------------
- instance #0 [OK]
- Collected 7 metrics, 0 events & 1 service check
network (5.21.1)
----------------
- instance #0 [OK]
- Collected 20 metrics, 0 events & 0 service checks
kubernetes (5.21.1)
-------------------
- instance #0 [OK]
- Collected 108 metrics, 0 events & 3 service checks
(snip.)
您可以通过检查是否包含 Nginx，来判断是否正确地被监视为监控对象。
当遇到错误时，您可以检查/var/log/dd-agent/collector.log等日志文件，可能能够了解到当前的情况。
只需一种选择，用中文进行改写：
总结起来
由于Datadog的自动发现功能周围缺乏详细的文档，理解其工作原理非常困难，因此我个人汇总了一些备忘录。
