search

etsy / statsd-jvm-profiler

Simple JVM Profiler Using StatsD and Other Metrics Backends
MIT License
330 stars 93 forks source link

graphite time ranges seem broken #46

Closed Ikariusrb closed 8 years ago

Ikariusrb commented 8 years ago

So after solving the bounds-finding issue and sorting out a few issues where empty results weren't properly handled, I went and tested gathering profiling on a specific map/reduce run. I generated carbonite-formatted timestamps for beginning and ending of the run, and enabled the profiling.

Afterwards, I found that running graphite_dump.py generated no results when using the start and stop timestamps generated before and after the map/reduce job. I verified that all computers had synced time and same timezone. The stat prefixes used for this run were brand new, so no stats had been under these trees in graphite prior to this run.

I was able to extract stats by expanding the time range; using a multi-day time range w/ start time of 01:00 - 23:00 got me stats, but I'm not sure how to find what exact time range these stats are tied to.

ajsquared commented 8 years ago

That's unexpected. I'm wondering if this is related to the retention/aggregation configuration for the storage schema the stats end up in.

You could also try capturing some packets going to your StatsD/Graphite instance and see what the timestamps look like there.

ajsquared commented 8 years ago

I wanted to follow up about this - were you able to make any progress or are you still having issues?

ajsquared commented 8 years ago

If you continue to have trouble let us know. For now I'm going to close this though.