Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>A couple of things to check/try:</p> <p><strong>Configure Graphite for Statsd</strong></p> <p>Check to make sure that you've used the <a href="https://github.com/etsy/statsd/blob/master/docs/graphite.md#storage-schemas" rel="noreferrer">retention schema</a> and <a href="https://github.com/etsy/statsd/blob/master/docs/graphite.md#storage-aggregation" rel="noreferrer">aggregation</a> settings in Graphite that match how Statsd will be sending data (i.e. it sends one data point per 10 second flush interval). </p> <p><strong>Run a single Statsd aggregator</strong></p> <p>Be sure you are only running one instance of Statsd as running multiple statsd daemons will cause metrics to be dropped (as Graphite will be configured to only store one data point for it's highest precision of <code>10s:6h</code>)</p> <p><strong>Limit the time range in the UI or URL API to less than 6 hours</strong></p> <p>When displaying graphs with data that crosses over the 6 hour threshold (e.g. from now to 7 hours ago), you will begin seeing 1 minute worth of aggregated count data for the displayed graph (if you've configured Graphite for statsd with <code>retentions = 10s:6h,1min:7d,10min:5y</code>). Rollups will occur based on the oldest data point in the time range (e.g. now till 7+ days = you'll get 10 min rollups).</p> <p><strong>If sending sparse or "bursty" data AND displaying old time range (triggering aggregation)</strong></p> <p>Confirm that your xFilesFactor is low enough that aggregation produces non null values even with a high rate of nulls. For example, 100 requests in the first 10 seconds, and none for the remaining 50 seconds in a minute would cause a storage of <code>100, null, null, null, null, null</code> which would be summed up to null when the data ages if the XFilesFactor is higher than 1/6. Using the statsd recommended graphite configuration handles this, but it is good to know about... as this can give the appearance of lost data.</p> <p><strong>Saving schema or aggregation changes</strong></p> <p>If you changed the graphite schema or aggregation settings after any metrics were stored (in whisper = graphite's storage) you'll need to either delete the .wsp files for the metric (graphite will recreate them) or run <code>whisper-resize.py</code>. </p> <p><strong>Validating settings</strong></p> <p>You can verify the settings against some whisper data by running whisper-info.py on a .wsp file. Find the .wsp file for one of your metrics in /graphite/storage/whisper/ Run: <code>whisper-info.py my_metric_data.wsp</code>. whisper-info.py output should tell you more about how the storage settings are working. </p> <h2>TLDR;</h2> <p>You should ensure that Graphite is set to store one data point per 10 second interval for metrics coming from StatsD. You should make sure that Graphite is summing (not averaging) for count data coming from Statsd. Both of these can be handled by using the recommended <a href="https://github.com/etsy/statsd/blob/master/docs/graphite.md" rel="noreferrer">Statsd configuration settings</a>. Don't run more than one Statsd aggregator. When using the UI, limit the data returned to less than 6 hours OR understand what rollup you are viewing when looking at data that crosses retention thresholds. Lastly, make sure the settings take (if you've already been sending metrics).</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload