Q: How can I submit StatsD data to Circonus?
Circonus offers a StatsD check that allows the collection of StatsD data on Circonus Enterprise brokers.
On the Enterprise broker, incoming StatsD data is identified by the IP of the sending host and the metric name, and then sent to the corresponding check. So, make sure that the target host configured in the check matches the source address of the packets that arrive at the broker.
Q: Why can't I just point the StatsD client at one of the public Circonus brokers?
The reason Circonus does not accept StatsD data on public brokers is that the StatsD protocol does not allow for authentication and security. So there is no reliable way to route the incoming data to the right check. Enterprise brokers should be installed inside a LAN which is protected from illegitimate requests by a firewall.
Q: How can I aggregated StatsD data from several nodes in a single metric?
As mentioned before, StatsD data is routed by the source IP address (and the metric name), so data that arrives from different nodes
will end up in different checks. There are two ways to work around this limitation:
(a) Setup a statsD repeater. StatsD supports repeaters, which forward all incoming metrics to an upstream host. You can setup such a repeater to forward the incoming data to the Circonus broker. In this way, you have a single host IP that we can attribute that data to:
(b) Aggregate data in a separate CAQL check. CAQL checks can be used to aggregate data across different metrics. Since percentiles can't be aggregated (Statistics for Engineers @ ACMQ), it's critical that you store your data as Histogram metrics for this method to work. An example could look as follows:
search:metric:histogram("(metric:GET`/some/endpoint`timing) (tag:db)") | histogram:merge()
This CAQL statement would aggregate all metrics which match the search query: "(metric:GET`/some/endpoint`timing) (tag:db)"
TIP: Use the search function in the Metrics page to check that these are the metrics you are looking for.