datadog
datadog
插件通过 UDP 协议将其自定义指标推送给 DogStatsD 服务器,该服务器通过 UDP 连接与 Datadog Agent 捆绑在一起(关于如何安装 Datadog Agent,请参考 )。DogStatsD 基本上是 StatsD 协议的实现,它为 Apache APISIX Agent 收集自定义指标,并将其聚合成单个数据点,发送到配置的 Datadog 服务器。更多关于 DogStatsD 的信息,请参考 DogStatsD 。
datadog
插件具有将多个指标参数组成一个批处理统一推送给外部 Datadog Agent 的能力,并且可以重复使用同一个数据包套接字。
此功能可以有效解决日志数据发送不及时的问题。在创建批处理器之后,如果对 inactive_timeout
参数进行配置,那么批处理器会在配置好的时间内自动发送日志数据。如果不进行配置,时间默认为 5s。
关于 Apache APISIX 的批处理程序的更多信息,请参考
APISIX-Datadog 插件将其自定义指标推送到 DogStatsD server。而 DogStatsD server 通过 UDP 连接与 Datadog agent 捆绑在一起。DogStatsD 是 StatsD 协议的一个实现。它为 Apache APISIX agent 收集自定义指标,将其聚合成一个数据点,并将其发送到配置的 Datadog server。要了解更多关于 DogStatsD 的信息,请访问 DogStatsD 文档。
当你启用 APISIX-Datadog 插件时,Apache APISIX agent 会在每个请求响应周期向 DogStatsD server 输出以下指标:
这些指标将被发送到 DogStatsD agent,并带有以下标签。如果任何特定的标签没有合适的值,该标签将被直接省略。
- 首先你必须在系统中安装一个 Datadog agent。它可以是一个 docker 容器,一个 pod 或是一个二进制的包管理器。你只需要确保 Apache APISIX agent 可以到达 Datadog agent 的 8125 端口。
如果你从没使用过 Datadog
然后按照下图标注的步骤生成 API 密钥。
APISIX-Datadog 插件只需要依赖
datadog/agent
的 dogstatsd 组件即可实现,因为该插件按照 statsd 协议通过标准的 UDP 套接字向 DogStatsD server 异步发送参数。我们推荐使用独立的datadog/dogstatsd
镜像,而不是使用完整的datadog/agent
,因为datadog/dogstatsd
的组件大小只有大约 11 MB,更加轻量化。而完整的 镜像的大小为 2.8 GB。
运行以下命令,将它作为一个容器来运行:
如果你在生产环境中使用 Kubernetes,你可以将 dogstatsd
作为一个 Daemonset
或 Multi-Container Pod
与 Apache APISIX agent 一起部署。
启用插件
本小节介绍了如何在指定路由上启用 datadog
插件。进行以下操作之前请确认您的 Datadog Agent 已经启动并正常运行。
现在,任何对 uri /hello
的请求都会生成上述指标,并推送到 Datadog Agent 的 DogStatsD 服务器。
补充:自定义配置
在默认配置中,datadog
插件希望 Dogstatsd 服务在 127.0.0.1:8125
可用。如果你想更新配置,请更新插件的元数据。如果想要了解更多关于 插件元数据的字段,请参阅元数据。
向 /apisix/admin/plugin_metadata/datadog
发起请求,更改其元数据。操作示例如下:
上述命令将会更新元数据,后续各指标将通过 UDP StatsD 推送到 172.168.45.29:8126
上对应的服务,并且配置将被热加载,不需要重新启动 APISIX 实例,就可以使配置生效。
如果你想把 datadog
插件的元数据 schema 恢复到默认值,只需向同一个服务地址再发出一个 Body 为空的 PUT 请求。示例如下:
该插件支持使用批处理程序来聚集和处理条目(日志/数据)的批次。这就避免了插件频繁地提交数据,默认情况下,批处理程序每 5
秒或当队列中的数据达到 1000
时提交数据。有关信息或自定义批处理程序的参数设置,请参阅 配置部分。
元数据
要了解更多关于如何有效地编写标签,请访问
启用 datadog 插件之后,APISIX 就会按照下面的指标格式,将数据整理成数据包最终发送到 DogStatsD server。
这些指标会带有以下标签,并首先被发送到本地 DogStatsD Agent。
- route_name:在路由模式定义中指定的名称,如果不存在或插件属性
prefer_name
被设置为 ,它将默认使用路由/服务的 id 值。 - service_name:如果一个路由是用服务的抽象概念创建的,特定的服务 name/id(基于插件的
prefer_name
属性)将被使用。 - consumer:如果路由有一个正在链接中的消费者,那么消费者的用户名将被添加为一个标签。
- balancer_ip:处理当前请求的上游负载均衡器的 IP。
- scheme:已用于提出请求的协议,如 HTTP、gRPC、gRPCs 等。