3 ms·
This may be a question as much to other prometheus users as you, sorry. :) I'm using Prometheus to record both "metric" data (temperature of CPUs, etc.) as wel
by dgacmu 10y ago
This may be a question as much to other prometheus users as you, sorry. :) I'm using Prometheus to record both "metric" data (temperature of CPUs, etc.) as well as "event" data (program produced result x). It's seemed awesome for metrics and poor for events.
(a) Is there a way to coerce Prometheus into doing what I want?
(b) Is this something fundamentally easier or harder in TimescaleDB, and why? aka - should I consider switching even though you're beta-ish, and is it a compelling reason, or just something I'm doing wrong?
(Yeah, I know, I'm asking the Internet to do my job for me... thank you, Internet!)
- RobAtticus 10y agoI personally haven't used Prometheus much, so I'm not sure I can effectively answer (a). I don't see why this would be difficult in TimescaleDB though. If it's timestamped, it should work nicely with our hypertable abstraction and is as easy as a SQL INSERT. Maybe others can chime in on the first part of your question though.
- dgacmu 10y agoSo, if I have an event like "program observed a car at 2017-04-20 15:15:15.9939311", and I want to calculate summary statistics over time for that -- select count(*) where car_time % 86400 == foo". That's the one kind of query I've been finding problematic in Prometheus. (Edited to add: This was answered by another reply -- Prometheus has to do a full table scan for things like this.)
- cevian 10y agoHey, Not sure if this is part of the question but if you are querying the event data by something other than time (like a property of the event itself -- maybe the program return code in your example) than prometheus requires a full table scan since it does not have secondary indexes. With TimescaleDB you could add indexes on properties of the event data itself.
- dgacmu 10y agoAhh, I think this answers my question. Painful - thank you!