On Sunday, 4 October 2020 11:10:39 UTC+1, sreehari M V wrote: > > In fact I am looking for scalability and a high available monitoring setup > and planning to implement timescale DB for this. Currently there are node, > process and JMX exporters are installed in nodes and expect nodes count to > be increased to 500+. > > And currently prometheus storage re-tension is 30 days. Can you please > suggest a best solution for this. If timescale db is the best solution , > can you please share the implementation ideas ? Below issues are facing > with time scale DB. > > 1. Storage size is huge. > 2. Not able fetch the data from timescale DB through prometheus. > > I think the storage size problem is fundamental to timescale DB; it's a row-based storage engine, and hence will use much more storage than a column-based system, as well as being much slower to query for typical use cases. However, you *should* be able to read and write to it via prometheus: the postgres/timescale adapter supports both remote read and remote write. If you can't, then it's probably just a configuration issue.
If you're looking for a more scalable solution, I'd recommend you look at VictoriaMetrics, because it can start as a simple single-process system, which may be all you need, but you can change to a horizontally-scalable distributed system later if you need. There are some benchmarks here (from author of VictoriaMetrics): https://medium.com/@valyala/measuring-vertical-scalability-for-time-series-databases-in-google-cloud-92550d78d8ae Thanos/Cortex are other well-known big players in this space. -- You received this message because you are subscribed to the Google Groups "Prometheus Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/ce7e0f76-eb31-47c0-aded-a0e7f4a541a4o%40googlegroups.com.
