This check monitors the availability and uptime of non-Datadog StatsD servers. It also tracks the number of metrics, by metric type, received by StatsD.
This check does NOT forward application metrics from StatsD servers to Datadog. It collects metrics about StatsD itself.
The StatsD check is included in the Datadog Agent package, so you don’t need to install anything else on any servers that run StatsD.
Follow the instructions below to configure this check for an Agent running on a host. For containerized environments, see the Containerized section.
init_config: instances: - host: localhost port: 8126 # or wherever your statsd listens
host(Optional) - Host to be checked. This will be included as a tag:
host:<host>. Defaults to
port(Optional) - Port to be checked. This will be included as a tag:
port:<port>. Defaults to
timeout(Optional) - Timeout for the check. Defaults to 10 seconds.
tags(Optional) - Tags to be assigned to the metric.
Restart the Agent to start sending StatsD metrics and service checks to Datadog.
For containerized environments, see the Autodiscovery Integration Templates for guidance on applying the parameters below.
|blank or |
Run the Agent’s
status subcommand and look for
statsd under the Checks section.
|The number of counter metrics currently seen by StatsD|
|The number of gauge metrics currently seen by StatsD|
|The number of timer metrics currently seen by StatsD|
The StatsD check does not include any events.
Returns CRITICAL if the StatsD server does not respond to the Agent’s health status request, otherwise OK.
Returns CRITICAL if the Agent cannot collect metrics about StatsD, otherwise OK.
Need help? Contact Datadog support.
If you don’t know what StatsD is and how does it work, check out our blog post about it
To get a better idea of how (or why) to visualize StatsD metrics with Counts Graphing with Datadog, check out our series of blog posts about it.
Mistake in the docs? Feel free to contribute!