Monitoring your own infrastructure using Grafana, InfluxDB, and CollectD

Re:Monitoring your own infrastructure using Grafana, InfluxD... by themgt on Tuesday July 21, 2020 @02:23PM (#23909387)

I was testing out both TimescaleDB/InfluxDB recently, including maybe using with Prometheus/Grafana. I was leaning towards Timescale, but InfluxDB was indeed a lot easier to quickly boot a "batteries included" setup and start working with live data.

I eventually spent a while reading about Timescale 1 vs 2, and testing the pg_prometheus[1] adapter and started thinking through integrating its schema to our other needs then realizing it's "sunsetted" and then reading about the new timescale-prometheus[2] adapter and reading through its ongoing design doc[3] with updated schema that I'm less a fan of.

I finally wound up mostly-settling on Timescale although I've put the Prometheus extension question on hold, just pulling in metrics data and outputting with ChartJS and some basic queries got me a lot closer to done for now. Our use case may be a little odd regardless, but I think a timescale-prometheus extension with a some ability to customize how the data is persisted would be quite useful.

[1] https://github.com/timescale/pg_prometheus

[2] https://github.com/timescale/timescale-prometheus

[3] https://docs.google.com/document/d/1e3mAN3eHUpQ2JHDvnmkmn_9r...

[ Parent | on HN ]

Re:Monitoring your own infrastructure using Grafana, InfluxD... by cevian on Tuesday July 21, 2020 @03:50PM (#23910249)

(TimescaleDB engineer) Really curious about finding out more about your reservations about the updated schema. All criticisms welcome.

[ Parent | on HN ]

Re:Monitoring your own infrastructure using Grafana, InfluxD... by themgt on Tuesday July 21, 2020 @06:34PM (#23911702)

Thanks, as I say our use case may be too odd to be worth supporting, but effectively we're trying to add a basic metrics (prom/ad-hoc) feature to an existing product (using Postgres) with an existing sort of opinionated "ORM"/toolkit for inserting/querying data.

Because of that and the small scale required, the choice of table-per-metric would be a tough fit and I think a single table with JSONB and maybe some partial indexes is going to work a lot better for us. It would just be nice if we could somehow code in our schema mapping and use the supported extension, but I get it may be too baked-into the implementation.

Anyway, overall we're quite happy with TimescaleDB!

[ Parent | on HN ]

Re:Monitoring your own infrastructure using Grafana, InfluxD... by cevian on Tuesday July 21, 2020 @09:42PM (#23913098)

I see, that makes a whole lot of sense. This is an interesting use-case. It actually may be possible to use some of the aggregates provided by the extension even with a different schema. If you are interested in exploring further, my username on slack is `mat` and my email is the same @timescale.com

[ Parent | on HN ]