3 ms·

It's certainly gotten better but I would not call it a great experience. Right this minute for example, my metrics machine's disk is filling up at higher than u

It's certainly gotten better but I would not call it a great experience. Right this minute for example, my metrics machine's disk is filling up at higher than usual rate and I have no knowledge of what is causing this to happen, no tools to figure it out. A week ago, I tried to set up a "successful writes per second" metric. I have a "time since start", and "successful writes since start", but no way to operate one with the other. The HTTP input API is dog-slow with HTTPS, and the UDP input API requires a separate socket for every database. It's lots of things like these...

linsomniac 9y ago
"successful writes since start" has a time value associated with it, right? I think what you want is not to correlate "time since start" and "successful writes since start", but to just do a derivative of the "successful writes since start" metric. This is just like the networking stats on Linux hosts. I have something like: FROM default net WHERE host =~ /$Host$/ SELECT field(bytes_recv) mean() derivative(1s) alias(In) GROUP BY time($interval) tag(host) tag(interface) fill(null) FORMAT AS Time series ALIAS BY [[col]] [[tag_host]]/[[tag_interface]] That's in my Grafana query. Aside: I sent the TimeseriesDB reference to a friend that just a couple days ago asked about options for storing metrics on storage servers. I had told him about my experiences with Influx, had mentioned Prometheus and also Sentry has some sort of internal TSDB they do on Postgres. In reply to the TimeseriesDB reference, he replied that he was all about InfluxDB now.