Currently my organisation uses Graphite for metrics monitoring. We have
~1600 instances pushing ~40 metrics to Graphite every minute. This causes a
straight ~600 iops on our SAN, which was deemed too expensive by the
infrastructure managers for what amounts to 3 MB of information.
Synthetic tes
Thanks Paul, I will see if I can fork some libraries to include the Java client
in the future so we can use UDP.
For now we'll continue with Telegraf as proxy, since there are no showstoppers
for production anymore.
--
Remember to include the version number!
---
You received this message beca
When metrics are sent to Telegraf's http-input plugin and from there sent
to InfluxDB, the nanosecond timestamps are truncated by removing the last 9
0's. This means all timestamps in InfluxDB end up in the far past instead
of the correct time.
The same values sent straight to InfluxDB are corr
s = ["http://localhost:8086";]
makes no difference for truncation
On Friday, January 13, 2017 at 5:04:27 PM UTC+1, Ross McDonald wrote:
>
> Could you provide your Telegraf configuration? Also what version of
> Telegraf are you using?
>
> On Fri, Jan 13, 2017 at 9
>
> On Fri, Jan 13, 2017 at 9:20 AM, Niels van Klaveren > wrote:
>
>> When metrics are sent to Telegraf's http-input plugin and from there sent
>> to InfluxDB, the nanosecond timestamps are truncated by removing the last 9
>> 0's. This means all timestam
e",
>
> "bar"
>
> ],
>
> "values": [
>
> [
>
> "1970-01-01T00:24:44.346119541Z",
>
> "NOT using precision=ms"
>
> ],
>
> [
OK, when sending metrics over http in nanoseconds through a Telegraf proxy,
everything works as expected. Use any other time unit and things will end up in
the past.
--
Remember to include the version number!
---
You received this message because you are subscribed to the Google Groups
"Infl
Depends on how you inserted the data. InfluxDB stores everything in nanos since
epoch.
If you sent your data in seconds since epoch, and didn't state precision=s as a
URL parameter, it will store the same number as nanoseconds since epoch, and
you'll find your data in the early 70's instead of
I'm getting Nginx reverse proxy data into Influx through the Telegraf
logparser.
Nginx outputs some fields that measure duration as part of another duration
(i.e. upstream_response_time is part of the total response_time). For
analysis, it would be best to have a separate field that's response_
