Our StatsD integration lets you easily get StatsD-format data into New Relic. You can also add any arbitrary tags (key-value pairs) to your data. Once your metrics are in New Relic, you can query your data and create custom charts and dashboards.
The integration is available as a linux container image in DockerHub for amd64 and arm64 architectures.
Install
This section will explain how to do a standard install. If you want to run StatsD in Kubernetes, see Kubernetes install.
To install the StatsD integration, run the following command and include your New Relic account ID and . This generates a TOML configuration file used by gostatsd.
Here are examples of Kubernetes manifests for deployment and service objects:
Below are examples of Kubernetes manifests to deploy StatsD in a Kubernetes environment and create a StatsD service named newrelic-statsd. You need to insert your account ID and your .
In the install procedure, you run nri-statsd with environment variables, and this generates a TOML configuration file. Additionally, you can set these configuration options:
Configuration options
Description
expiry-interval
string
If a metric is not updated for this amount of time, we stop reporting that metric. Default is 5m.
If you want to send the metrics only if the value was updated between the flush intervals, configure this to 1ms. To never expire metrics, set it to 0.
percent-threshold
list of integers
Specifies the percentiles used for metrics aggregation. Default: 90.
metrics-addr
string
Indicates address on which to listen for metrics. Default: :8125.
From nri-statsd v2.3.0 (goStatsD v34.2.1), connection via Unix Domain Socket (UDS) is supported. Use "metrics-addr=/some/path/newrelic-statsd.socket" instead of "[host]:port" in the configuration.
Tip
To ensure FedRAMP compliance when using the StatsD integration you must define the following endpoints in the custom configuration:
By default, nri_statsd calculates the following for timer metrics: standard deviation, mean, median, sum, lower, and upper bounds for the flush interval. If you want to disable those metrics you can do it by adding a disabled-sub-metrics configuration section and set true for the ones you want disabled. Here's an example:
The best approach to configure nri-statsd running in Kubernetes is to use a configMap and mount the configMap into the container. (This is a similar process to mounting the configuration file in Docker.)
Optional for simple counters or timer counters. When many metrics must be sent, you can use sampling to reduce network traffic. The downside is a reduction in the resolution of the data.
An example of how this would work for sample rates below 1: If you set this to 0.1, the counter would send a measurement one out of every 10 times.
#<tags> string
Optional. Tags attached to your metrics are converted into attributes (key-value pairs). For more on tagging options, see Tags.
Metric types
Here are the types of metrics and how to format them:
A counter measures the number of occurrences of an event. Examples include cache hits per reporting interval and the number of threads created per reporting interval.
A counter can be incremented or decremented during the same flush interval by adding a sign to the value. In the following example, the counter value will be 2:
counter:4|c
counter:-2|c
At each flush, the current count is sent and reset to 0. If the count is not updated, at the next flush it will send the value 0. You can opt to disable this behavior by setting expiry-interval to 1ms.
Here’s an example of a counter that is being sampled 1 out of 10 times:
counter:4|c@0.1
A gauge represents a value that can increase or decrease with time. Examples of gauges include temperature, CPU usage, and memory. Here's an example:
temperature:40|g
If the gauge is not updated, at the next flush it will send the previous value. You can opt to disable this behavior by setting expiry-interval to 1ms.
The timer metric type measures timing data.
By default, nri_statsd calculates the following for timer metrics: standard deviation, mean, median, sum, lower, and upper bounds for the flush interval. These are sent as sub-metrics in the following format:
<metric_base_name>.std_dev
<metric_base_name>.median
<metric_base_name>.summary
<metric_base_name>.sum_squares
<metric_base_name>.mean
<metric_base_name>.per_second
The configured percentiles will generate the following metrics. The percentile threshold value will be attached as a tag.
SELECT latest(prod.test.num) FROM Metric WHERE metricName = 'prod.test.num'
Here's an image showing creating this NRQL alert condition. Notice that the sample data sent in is represented by the blue dot on the upper right of the chart.
Now we can create the alert condition with these settings:
When you create the NRQL alert condition, be sure to set the Condition name.
If a metric with a value above 50 is sent, then an incident is created and notified. The incident is closed automatically after 24 hours. To test that the alert is working, run this command: