251–260 of 298 posts
Earlier quoted context omitted.
For long term retention, look at VictoriaMetrics
My vote is for VictoriaMetrics - the best option if you want to keep things simple and get great performance in the same time!
VictoriaMetrics pretty much has everything you'd hope for as a Prometheus long term storage, like direct PromQL support, good performance and ease of installation.
VictoriaMetrics eats other TSDBs for breakfast. PromQL support (with extensions) and clustered / HA mode. Great storage efficiency. Plays well for monitoring multiple k8s clusters, works great with Grafana, pretty easily deployed on k8s. No affiliation, just a happy user.
Maybe they need a PR person.
Earlier quoted context omitted.
Can you refute the claim that TimescaleDB uses such a huge disk space that is 50 times larger than other time series database? I see no reason to use it over VictoriaMetrics. https://medium.com/@valyala/high-cardinality-tsdb-benchmarks...
Yes, I can refute that claim. TimescaleDB now provides built in compression. https://docs.timescale.com/latest/using-timescaledb/compress...
Are you saying the compression shrinks the data down to 2% on average?
If the compression only makes the data 10 times smaller (I think I'm being generous with that ratio), it's still 5 times larger than the others.
Earlier quoted context omitted.
Why performances shouldn't matter in this case? The more instances, the more timeseries and the more datapoints you have, the more you care for speed when you need to query it to visualize for example WoW changes in, say, memory usage.
Consider the case at hand, involving streaming charts and alerts. There will be zero perceptible difference in the streaming charts regardless of what database is used. Alerts won't trigger for whatever millisecond difference there may be, and I don't think that this matters to any developer or manager awaiting the 3am call.
Earlier quoted context omitted.
> true costs to the employer is typically double the perceived salary. This is true, but my comment was an offhanded way to say that my "salary" (as in, the one on my contracts and the one I "see") is less than a month of Datadog for our number of hosts. As for the rest of your comment, I wish it was true. Developer salaries outside of the capitals is quite low in Europe, and even inside the capitals only go to "near…
> For me to justify spending "3-6" peoples worth of money it had better save "3-6" peoples worth of time. Well, it does in my experience, especially if you have to handle 2000+ hosts, that's some serious infra there, need serious tooling. May I ask which country is it?
Some industries need a lot of hardware because they crunch a lot of data but they aren't software companies. Think Computer graphics rendering.
Paying a FTE salary for software is crazy for them. I would love to see a ration of developers/infrastructure per industry/company.
Earlier quoted context omitted.
2,500~ compute instances. Looking at the pricing page the cost $15/instance so $37,500 Middle-of-the-road developer salary is like $35k in most of Europe, outside of the capitals. Although it does say: "Volume discounts available (500+ hosts/mo). Contact us." at the bottom, so I guess 500 is a lot.
2500 instances could be millions per months in AWS costs. The smallest instances with some disks and bandwidth fees can push 100k a month. Spending a fraction of that to monitor that sort of infrastructure is absolutely justified. I can tell you from experience that datadog gives discount even for 100+ hosts, I don't know what they can do for 2500, but if it were me I wouldn't accept anything less than 50% off. Hones…
Earlier quoted context omitted.
Nope, just that Prometheus and Grafana are running together on the same node. My entire infrastructure is multi-node however.
How much data are you sending and ingesting?
Earlier quoted context omitted.
Yes, I can refute that claim. TimescaleDB now provides built in compression. https://docs.timescale.com/latest/using-timescaledb/compress...
You didn't refute it technically. Are you saying the compression shrinks the data down to 2% on average? If the compression only makes the data 10 times smaller (I think I'm being generous with that ratio), it's still 5 times larger than the others.
Prior to the compression feature, I had the same complaint. Timescale strongly advocated for using ZFS disk compression if compression was really required. Requiring ZFS disk compression wasn't feasible for me.
Earlier quoted context omitted.
(TimescaleDB engineer) Really curious about finding out more about your reservations about the updated schema. All criticisms welcome.
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 partia…