自动收集在Kubernetes部署的应用程序的指标数据

2 年 ago
宇, 华
10 minutes
image.png

示意如下 TL;DR；

为了解决每次收集指标、创建图表和警报时都需要等候基础架构工程师的情况。

我会在应用程序中添加Prometheus指标终端，并通过Prometheus或Datadog自动发现和抓取它。

在这篇文章中，我们将使用Datadog。如果你想了解关于使用Datadog对Kubernetes进行监控的一般知识，我推荐@spesnova的”Monitoring Kubernetes with Datadog”这篇文章。

对于急需的用户：应用程序的设定步骤

在这篇文章的中间部分写过了！只需添加Prometheus终端节点并附加Pod注释。

前提1：为什么选择Prometheus和Datadog？

虽然称为Prometheus，但需要将其与用于公开指标的端点（24231/metrics，被Scrape的应用的端点）区分开来进行解释。

Prometheus的端点可轻松建立。

首先，Datadog提供了通过dogstatsd发送statsd度量指标的标准度量收集方式。但是，我们特意提供Prometheus端点的一个原因是为了利用丰富的Prometheus相关库来轻松公开度量指标。

例如，对于采用Golang编写的GRPC服务器，只需集成名为go-grpc-prometheus的中间件，即可自动测量和公开吞吐量等指标。

不会被特定供应商的度量标准发布和收集规范限制住。

另一个原因是这个。

如果选择采用Datadog，那么Datadog的指标收集代理（dogstatsd）的协议dogstatsd是对statsd功能的部分削弱和扩展。因此，如果构建了基于dogstatsd的指标收集基础设施，那么将变得难以迁移到除了Datadog之外的其他选择。如果能够避免厂商锁定并以较少的工作量实现，那就再好不过了。

参考：关于DogStatsd的公式说明

在这方面，后端可以选择Prometheus或任何其他的SaaS，以便能够通过技术或现实可行的手段来抓取Prometheus指标。具体的例子有Prometheus和Datadog。

是否具备自动发现功能

在自动伸缩和微服务架构以及各团队自助服务的环境中，受监控的应用程序经常变化。每次都需要去找基础架构工程师修改监控系统的配置文件等，这很麻烦不是吗？

如果采用了具有自动发现功能的监控系统，它将在应用程序增加或减少时自动添加或删除要收集的指标。更具体地说，假设我们要在Kubernetes上运行一个公开Prometheus指标的应用程序，当Pod增加或减少时，我们希望自动收集该Prometheus指标。

Datadog和Prometheus都具有自动发现功能。

Datadog: https://docs.datadoghq.com/guides/autodiscovery/

Datadog：https://docs.datadoghq.com/guides/autodiscovery/

然而，据2017年12月所知，Prometheus似乎没有自动抓取任意应用程序指标的功能（如果有，请告知，因为我还不敢相信）。

这篇文章刚发布时写道，Prometheus没有自动发现功能，但这是错误的。实际上，有一种方法是启用Service Discovery来对Pod进行发现。 ( 来自 @shmurata 的信息。非常感谢！)

参考：https://qiita.com/mumoshu/items/9fb7988ccbefa88b61cd#comment-99d56d5b415e574a758a

前言2：为什么选择Datadog而不是Prometheus

希望能够通过一个服务来集中管理度量、追踪和日志，以便节省运维成本。

如果选择采用Prometheus，例如

    • 基本的なグラフ作成とメトリクス収集、アラート設定はPrometheus

 

    • 分散ログはEKF(Elasticsearch + Kibana Fluentd)

 

    分散トレースはZipkinやJaeger

我认为这种结构是好的选择，当然从软件许可费用、支持费用以及未来的扩展性等方面来看。

一方面，

    • アラートを受けたときに、その原因調査のために３つもサービスを行ったり来たりするのは面倒

 

    人が少ない場合にセルフホストしてるサービスの運用保守に手間をかけたくない

我认为也有类似的想法。

在这种情况下，有可能会决定采用SaaS。
截至2017年12月，由于Prometheus的托管服务没有标准选择，因此在这种情况下只能选择Datadog。

dd-agent的安装步骤

dd-agent 的安装

由于dd-agent的Helm图表功能丰富且出色，我们将使用它。

参考：在 Kubernetes 上安装 Datadog Agent 的最佳实践 – Qiita

普罗米修斯检查的安装

因为Prometheus检查工具未包含在dd-agent中，所以需要以某种形式将其安装到dd-agent中。幸运的是，可以从ConfigMap中加载任何需要的检查工具，而无需重新创建dd-agent，因此将使用这种方法。

$ curl -o prometheus.py https://raw.githubusercontent.com/latency-at/datadog-agent-prometheus/master/check.d/prometheus.py

$ k get configmap datadog-datadog-checksd -o yaml> datadog-datadog-checksd.configmap.yaml

$ k create configmap datadog-datadog-checksd --dry-run -o yaml --from-file prometheus.py | k apply -f -
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
configmap "datadog-datadog-checksd" configured

为了加载自定义检查到dd-agent中，需要重新启动dd-agent。

$ kubectl delete pod $(k get po | grep datadog-datadog | cut -d ' ' -f 1)

看一下需要抓取的指标。

只需要一个选项：Prometheus Endpoint通过HTTP协议公开指标，通常在/metrics路径上公开。因此，我们可以使用curl试探性地检查哪些指标已经公开，并确保它们确实已经公开了。

首先，启动适当的Pod并安装curl。

root@xenial-1512636123:/# apt-get update -y && apt-get install curl

确认目标Pod的IP地址。

$ k get po -o wide | grep fluentd
fluentd-cloud-logging-7630p                                             1/1       Running            0          2m        10.2.37.28    ip-10-0-0-221.ap-northeast-1.compute.internal
fluentd-cloud-logging-9mwxs                                             1/1       Running            0          4m        10.2.91.80    ip-10-0-0-26.ap-northeast-1.compute.internal
fluentd-cloud-logging-fgs52                                             1/1       Running            0          4m        10.2.23.121   ip-10-0-0-82.ap-northeast-1.compute.internal
fluentd-cloud-logging-hr309                                             1/1       Running            0          2m        10.2.63.82    ip-10-0-0-140.ap-northeast-1.compute.internal
fluentd-cloud-logging-llhm6                                             1/1       Running            0          4m        10.2.6.24     ip-10-0-0-47.ap-northeast-1.compute.internal

我将向/metrics目标PodIP发送HTTP GET请求。

root@xenial-1512636123:/# curl 10.2.37.28:24231/metrics
# TYPE fluentd_status_buffer_queue_length gauge
# HELP fluentd_status_buffer_queue_length Current buffer queue length.
fluentd_status_buffer_queue_length{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b8d3494",plugin_category="output",type="datadog_log"} 0.0
fluentd_status_buffer_queue_length{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b9396f4",plugin_category="output",type="datadog_log"} 0.0
# TYPE fluentd_status_buffer_total_bytes gauge
# HELP fluentd_status_buffer_total_bytes Current total size of queued buffers.
fluentd_status_buffer_total_bytes{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b8d3494",plugin_category="output",type="datadog_log"} 7235.0
fluentd_status_buffer_total_bytes{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b9396f4",plugin_category="output",type="datadog_log"} 0.0
# TYPE fluentd_status_retry_count gauge
# HELP fluentd_status_retry_count Current retry counts.
fluentd_status_retry_count{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04fd9fa3c",plugin_category="output",type="null"} 0.0
fluentd_status_retry_count{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b8d3494",plugin_category="output",type="datadog_log"} 0.0
fluentd_status_retry_count{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b9396f4",plugin_category="output",type="datadog_log"} 0.0
# TYPE fluentd_output_status_buffer_queue_length gauge
# HELP fluentd_output_status_buffer_queue_length Current buffer queue length.
fluentd_output_status_buffer_queue_length{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b8d3494",type="datadog_log"} 0.0
fluentd_output_status_buffer_queue_length{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b9396f4",type="datadog_log"} 0.0
# TYPE fluentd_output_status_buffer_total_bytes gauge
# HELP fluentd_output_status_buffer_total_bytes Current total size of queued buffers.
fluentd_output_status_buffer_total_bytes{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b8d3494",type="datadog_log"} 7235.0
fluentd_output_status_buffer_total_bytes{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b9396f4",type="datadog_log"} 0.0
# TYPE fluentd_output_status_retry_count gauge
# HELP fluentd_output_status_retry_count Current retry counts.
fluentd_output_status_retry_count{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04fd9fa3c",type="null"} 0.0
fluentd_output_status_retry_count{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b8d3494",type="datadog_log"} 0.0
fluentd_output_status_retry_count{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b9396f4",type="datadog_log"} 0.0
# TYPE fluentd_output_status_num_errors gauge
# HELP fluentd_output_status_num_errors Current number of errors.
fluentd_output_status_num_errors{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04fd9fa3c",type="null"} 0.0
fluentd_output_status_num_errors{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b8d3494",type="datadog_log"} 0.0
fluentd_output_status_num_errors{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b9396f4",type="datadog_log"} 0.0
# TYPE fluentd_output_status_emit_count gauge
# HELP fluentd_output_status_emit_count Current emit counts.
fluentd_output_status_emit_count{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04fd9fa3c",type="null"} 18.0
fluentd_output_status_emit_count{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b8d3494",type="datadog_log"} 92.0
fluentd_output_status_emit_count{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b9396f4",type="datadog_log"} 0.0
# TYPE fluentd_output_status_emit_records gauge
# HELP fluentd_output_status_emit_records Current emit records.
fluentd_output_status_emit_records{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04fd9fa3c",type="null"} 18.0
fluentd_output_status_emit_records{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b8d3494",type="datadog_log"} 548.0
fluentd_output_status_emit_records{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b9396f4",type="datadog_log"} 0.0
# TYPE fluentd_output_status_write_count gauge
# HELP fluentd_output_status_write_count Current write counts.
fluentd_output_status_write_count{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04fd9fa3c",type="null"} 0.0
fluentd_output_status_write_count{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b8d3494",type="datadog_log"} 30.0
fluentd_output_status_write_count{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b9396f4",type="datadog_log"} 0.0
# TYPE fluentd_output_status_rollback_count gauge
# HELP fluentd_output_status_rollback_count Current rollback counts.
fluentd_output_status_rollback_count{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04fd9fa3c",type="null"} 0.0
fluentd_output_status_rollback_count{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b8d3494",type="datadog_log"} 0.0
fluentd_output_status_rollback_count{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b9396f4",type="datadog_log"} 0.0
# TYPE fluentd_output_status_retry_wait gauge
# HELP fluentd_output_status_retry_wait Current retry wait
fluentd_output_status_retry_wait{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04fd9fa3c",type="null"} 0.0
fluentd_output_status_retry_wait{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b8d3494",type="datadog_log"} 0.0
fluentd_output_status_retry_wait{host="fluentd-cloud-logging-7630p",plugin_id="object:3fb04b9396f4",type="datadog_log"} 0.0

给Pod添加指定的注释

由于本次使用Prometheus检查，因此需要对其进行自动设置的注释。

Datadog的AutoDiscovery一般的注释写法在官方文件中有提供。

使用Prometheus检查 今次利用Prometheus检查的话，会是以下这样的注释。基本上，不论应用程序如何，直接将这内容写下来应该都没有问题。

piVersion: extensions/v1beta1
kind: ...
metadata:
  # ...
spec:
  template:
    metadata:
      # ...
      annotations:
        service-discovery.datadoghq.com/fluentd-cloud-logging.check_names: '["prometheus"]'
        service-discovery.datadoghq.com/fluentd-cloud-logging.init_configs: '[{}]'
        service-discovery.datadoghq.com/fluentd-cloud-logging.instances: '[{"target":"http://%%host%%:24231/metrics"}]'

在添加注释时容易遇到的问题

作为一个注意点，Datadog的代理即dd-agent在以下时机执行自动发现。

    1. 当Pod被创建时

 

    当dd-agent启动或重新启动时

当进行反转操作时，在以下时机下将不会执行自动发现。

    すでにあるPodをkubectl edit/applyなどで変更したとき

因此，在创建Pod时应添加注释。如果在创建Pod之后添加注释，可以通过删除并重新创建Pod来触发自动发现。

我来检查一下dd-agent的Prometheus检查是否已经启用。

如果自动发现功能正常运行，应该会自动启用Prometheus检查，所以请验证一下这一点。

在容器上执行datadog-agent info命令可以了解dd-agent正在运行的检查。

通常情况下，dd-agent应该以DaemonSet的形式在每个主机上调度1个Pod。因此，我们可以对所有dd-agent执行以下命令进行确认。

$ for pod in $(k get po | grep datadog | cut -d ' ' -f 1); do echo pod: $pod; k exec -it $pod -- sh -c 'service datadog-agent info | grep prometheus -C 3'; done
pod: datadog-datadog-4vplw
Defaulting container name to datadog.
Use 'kubectl describe pod/datadog-datadog-4vplw' to see all of the containers in this pod.
2017-12-07 13:49:39,786 | WARNING | dd.collector | utils.service_discovery.config(config.py:31) | No configuration backend provided for service discovery. Only auto config templates will be used.
  Checks
  ======

    prometheus (custom)
    -------------------
      - instance #0 [OK]
      - Collected 32 metrics, 0 events & 0 service checks
2017-12-07 13:49:40,449 | WARNING | dd.dogstatsd | utils.service_discovery.config(config.py:31) | No configuration backend provided for service discovery. Only auto config templates will be used.
pod: datadog-datadog-8nwzv
Defaulting container name to datadog.
Use 'kubectl describe pod/datadog-datadog-8nwzv' to see all of the containers in this pod.
  Checks
  ======

    prometheus (custom)
    -------------------
      - instance #0 [OK]
      - Collected 32 metrics, 0 events & 0 service checks

*snip*

因为prometheus（自定义）本次使用的是Prometheus check，所以它显示在Checks下面，并且实例＃0为[OK]，如果收集的指标数量为非零，则表示“已收集xx个指标”为OK。

如果在Auto Discovery过程中出现任何错误（在此情况下，错误应在collector.log中显示。有关详细信息，请参考本文底部的“故障排除”部分），那么如果有Prometheus（自定义）存在，它不应该显示在这里。

此外，需要instance #0变为[OK]的原因是，由于本次注解仅指示了一次检查，因此该唯一检查的索引为0。

而且，如果”Collected xx metrics”的值不为零的原因是，检查已执行并成功访问了Prometheus终端，并且如果Prometheus终端至少公开了一个或多个指标，那么该值应该会增加。如果没有增加，那么可能发生了错误，或者终端存在但没有公开任何指标，只能考虑这样的情况。

确认Datadog已经收到了指标信号。

我們將在Datadog的Metrics Explorer中使用部分匹配的方式嘗試搜索要抓取的指標名稱。

image.png

只要能够出现指标名称的自动补全候选项，就可以确定该名称的指标已经被发送到Datadog，因此是成功的。

将Datadog收到的指标转化为图表。

在Metrics Explorer的Graph栏中，选择所有我们这次发送的指标，并将其绘制成图表。

image.png

如果绘制出了预定的图表，那么可以说我们能够自动发现和抓取应用程序的指标到dd-agent，以符合意图。

充分利用Datadog独特的功能

Datadog的一个特点是指标标签的灵活性。

在Prometheus中有一个名为relabellin的功能，可以在抓取指标时重新设置标签（相当于Datadog的tag）。它可以在kubenetes_sd_config中使用，但根据我所查到的设置方法，似乎没有一种通用的方法来设置任意标签(?)。

比如说，某个datadog-agent可以给其收集的指标统一添加标签，例如env:test和kube_cluster:mycluster。分别表示“只想筛选出测试环境的指标”和“只想筛选出部署在名为mycluster的Kubernetes集群中的应用程序的指标”。这样可以实现这些使用场景，并且非常方便。

如果要使用Pod Annotation

在实施 Prometheus Check 的 prometheus.py 中应用此 PR 的变更后，可以通过以下的实现来实现。

# ...
spec:
  # ...
  template:
    metadata:
      annotations:
        service-discovery.datadoghq.com/fluentd-cloud-logging.check_names: '["prometheus"]'
        service-discovery.datadoghq.com/fluentd-cloud-logging.init_configs: '[{}]'
        service-discovery.datadoghq.com/fluentd-cloud-logging.instances: '[{"target":"http://%%host%%:24231/metrics",
          "tags":["env:test","kube_cluster:mycluster"]}]'

如果在dd-agent级别上进行设置

如果在dd-agent容器的TAGS环境变量中设置类似于key1:val1，key2:val2的字符串，可以实现此功能。

参考：Datadog Helm Chart相关代码

总结

我已经解释了如何使用Datadog自动抓取应用程序的度量指标的方法。

应用程序只需在Kubernetes Pod上添加指定的注释，并在Prometheus端点上创建，不再需要每次都召集基础架构工程师，大大简化了收集指标的过程，变得更加轻松！

由于Datadog具有友好的用户界面，任何人都可以轻松创建图表和警报。这样一来，在创建图表和警报时就不再需要基础设施工程师的介入，变得更加轻松！

如果您希望使服务和应用程序的监控自助化的话，请务必尝试一下。

附录：故障排除

Prometheus指标无法导入到Datadog中。

请检查dd-agent的collector.log文件，看看是否有任何错误信息，因为Prometheus检查是由dd-agent的collector组件执行的。

$ for pod in $(k get po | grep datadog | cut -d ' ' -f 1); do echo pod: $pod; k exec -it $pod -- sh -c 'cat /var/log/datadog/collector.log | tail -n 30'; done

收集器日志中的“Could not decode the JSON configuration template for the entity“无法解码实体的JSON配置模板。

如果在期望有特定annotation的地方，却出现了无法解析为JSON的内容，就会出现错误。

2017-12-07 12:54:31 UTC | WARNING | dd.collector | utils.service_discovery.config(config.py:31) | No configuration backend provided for service discovery. Only auto config templates will be used.
2017-12-07 12:54:31 UTC | WARNING | dd.collector | utils.service_discovery.config(config.py:31) | No configuration backend provided for service discovery. Only auto config templates will be used.
2017-12-07 12:54:31 UTC | WARNING | dd.collector | collector(kubeutil.py:277) | Couldn't find the agent pod and namespace, using the default.
2017-12-07 12:54:31 UTC | ERROR | dd.collector | utils.service_discovery.abstract_config_store(abstract_config_store.py:238) | Could not decode the JSON configuration template for the entity mumoshu/kube-fluentd:1.0.0-0.9.10-rc.17...
Traceback (most recent call last):
  File "/opt/datadog-agent/agent/utils/service_discovery/abstract_config_store.py", line 230, in _extract_template
    check_names = json.loads(source_dict[key_prefix + CHECK_NAMES])
  File "/opt/datadog-agent/embedded/lib/python2.7/site-packages/simplejson/__init__.py", line 505, in loads
    return _default_decoder.decode(s)
  File "/opt/datadog-agent/embedded/lib/python2.7/site-packages/simplejson/decoder.py", line 370, in decode
    obj, end = self.raw_decode(s)
  File "/opt/datadog-agent/embedded/lib/python2.7/site-packages/simplejson/decoder.py", line 400, in raw_decode
    return self.scan_once(s, idx=_w(s, idx).end())
JSONDecodeError: Expecting ',' delimiter or ']': line 1 column 14 (char 13)
2017-12-07 12:54:36 UTC | WARNING | dd.collector | checks.docker_daemon(docker_daemon.py:641) | Unable to report cgroup metrics: Cannot report on bogus pid(0)

让我们检查三个注解值是否存在JSON错误。

连接错误：HTTPConnectionPool（主机= ‘10.2.63.85’，端口= 24321）：超过最大重试次数，URL为/ metrics。

如果在instances annotation中提供的爬取目标端口号不同，则会出现错误（在此例中，应该是24231，而不是24321）。

Traceback (most recent call last):
  File "/opt/datadog-agent/agent/checks/__init__.py", line 795, in run
    self.check(copy.deepcopy(instance))
  File "/etc/dd-agent/checks.d/prometheus.py", line 68, in check
    instance=instance)
  File "/etc/dd-agent/checks.d/prometheus.py", line 48, in process
    content_type, data = self.poll(endpoint, headers=headers)
  File "/opt/datadog-agent/agent/checks/prometheus_check.py", line 301, in poll
    req = requests.get(endpoint, headers=headers)
  File "/opt/datadog-agent/embedded/lib/python2.7/site-packages/requests/api.py", line 70, in get
    return request('get', url, params=params, **kwargs)
  File "/opt/datadog-agent/embedded/lib/python2.7/site-packages/requests/api.py", line 56, in request
    return session.request(method=method, url=url, **kwargs)
  File "/opt/datadog-agent/embedded/lib/python2.7/site-packages/requests/sessions.py", line 475, in request
    resp = self.send(prep, **send_kwargs)
  File "/opt/datadog-agent/embedded/lib/python2.7/site-packages/requests/sessions.py", line 596, in send
    r = adapter.send(request, **kwargs)
  File "/opt/datadog-agent/embedded/lib/python2.7/site-packages/requests/adapters.py", line 487, in send
    raise ConnectionError(e, request=request)
ConnectionError: HTTPConnectionPool(host='10.2.63.85', port=24321): Max retries exceeded with url: /metrics (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7fa268bb7f90>: Failed to establish a new connection: [Errno 111] Connection refused',))

能否補足一下：Prometheus 無法做嗎？

有点难以置信，但至少不能像Datadog那样轻松吧？

虽然有一些功能和问题，可以自动发现Node和常用Kubernetes组件，但没有找到可以自动发现用户部署的任意应用的指标的工具。

我相信我总有一天会能够做到，但现在来说，Datadog是唯一的选择。

在此文章发布时，曾经提到Prometheus没有自动发现功能，但是我错了。实际上，似乎有一种方法是通过对Pod启用服务发现来实现。 (根据@shmurata提供的信息。非常感谢您！)

请参阅此链接：https://qiita.com/mumoshu/items/9fb7988ccbefa88b61cd#comment-99d56d5b415e574a758a

我已经贴出了下面的调查结果，请有经验的人补充一下，谢谢。

KubernetesのPrometheus DiscoveryというIssue

https://github.com/kubernetes/kubernetes/issues/11858

PrometheusにKubernetes Discoveryという機能が以前追加された

これはnodeやpodのメトリクスを自動的に発見、スクレープできるという話
podで動くアプリケーションプロセスのメトリクスを自動的に発見する仕組みはない
Prometheusのkubernetes_sd_configの説明にはpodやnode以外のSD(Service Discovery)の設定が含まれるが、アプリのメトリクスに関しては言及なし

SOでPrometheusのpushgatewayをアプリケーションのsidecarにして、そこから送れば、という提案があるが、Prometheus開発者は推奨していない

あと、自動発見とはいえない

補充：未來的挑戰

根据我的理解，这段话的含义是：我们使用的Prometheus check似乎不支持自定义标签，所以无法使用Kubernetes特有的元数据（例如Pod名称或Deployment名称）来搜索、过滤和汇总指标。 Datadog之所以好的原因在于它可以灵活地支持自定义标签，但这种情况下就显得不够完整了….

Chinese paraphrase: 由于我们所使用的Prometheus check似乎不支持自定义标签，因此无法利用Kubernetes独特的元数据（如Pod名称或Deployment名称）来进行指标搜索、筛选和汇总。Datadog的优点在于其可以灵活地支持自定义标签，这种情况下就有些欠缺了…。

由于存在问题，如果您在意的话，请点赞+1。

bannerAds