3 ms·

Prometheus only handle aggregated data, though. While with influx you can store the events themselves with labels etc. While Prometheus is often good enough for

Prometheus only handle aggregated data, though. While with influx you can store the events themselves with labels etc. While Prometheus is often good enough for standard metrics, it is just things it can't handle.

ilyt 3y ago
AFAIK only difference is that in Influx a given row can have more than one value so say "interface traffic" would be interface_if_octets host=router,instance=eth0,rx=123584,tx=213956 while in prometheus it would be interface_if_octets host=router,instance=eth0,type=rx 123584 interface_if_octets host=router,instance=eth0,type=tx 213956 which in theory yes it is more compact but it gave me more annoyances than advantages during querying >While Prometheus is often good enough for standard metrics, it is just things it can't handle. My experience is that just anything made to ingest and analyze logs ends up mediocre for metrics and vice versa. I don't think I've seen single product that did both well or efficiently. So I'd rather have good metrics and just use ELK/Graylog/whatever else for logs.
- matsemann 3y ago
  Not really the biggest difference, I feel. In Prometheus, you only have the data you scrape. So lets say you scrape every minute. Then all you have is a counter per pod increasing from some value to something else. With influx you can save every event. So you know exactly when it happened, the unique labels for that event etc. It's a completely different paradigm. So in Prometheus you have myCounter,pod=1,time=20:23,value=1000 myCounter,pod=2,time=20:23,value=500 myCounter,pod=1,time=20:24,value=1100 myCounter,pod=2,time=20:24,value=700 so all you know is that some event happened 100 times on pod1 and 200 times on pod2 the last minute. But with influx you could have a row for every single event. Of course that explodes the query time in comparison, but allows you to do much more with the data if needed.
hagen1778 3y ago
> Prometheus only handle aggregated data, though. That's not true. You're referring to pull-based approach for metrics collection. It has its tradeoffs (like fixed interval scraping), but has a lot of benefits too (like higher reliability). Check the following link [0] from VictoriaMetrics docs, which supports both push and pull approaches. Prometheus also gained push support this year, though. However, the main difference between Prometheus-like systems (Thanos, Mimir, VictoriaMetrics) and more traditional DBs for time series like InfluxDB or TimescaleDB is that first are designed to reflect system's state, and last are designed to reflect system's events. That's the main difference in paradigm, data model, and query languages. There is a reason why PromQL is so easy in 99% of cases, and so complex and annoying when users want to express what they get used to in traditional databases. I'm saying this because I went through creating a Grafana datasource for ClickHouse [1] and I felt how complicated it is to express a most straightforward PromQL query in SQL, and vice versa. If you'd like to learn more about differences between common queries for plotting time series in PromQL and SQL see my talk here [2]. [0] https://docs.victoriametrics.com/keyConcepts.html#write-data https://docs.victoriametrics.com/keyConcepts.html#write-data [1] https://grafana.com/grafana/plugins/vertamedia-clickhouse-datasource/ https://grafana.com/grafana/plugins/vertamedia-clickhouse-da... [2] https://youtu.be/_zORxrgLtec?t=835 https://youtu.be/_zORxrgLtec?t=835

ilyt 3y ago

AFAIK only difference is that in Influx a given row can have more than one value so say "interface traffic" would be interface_if_octets host=router,instance=eth0,rx=123584,tx=213956 while in prometheus it would be interface_if_octets host=router,instance=eth0,type=rx 123584 interface_if_octets host=router,instance=eth0,type=tx 213956 which in theory yes it is more compact but it gave me more annoyances than advantages during querying >While Prometheus is often good enough for standard metrics, it is just things it can't handle. My experience is that just anything made to ingest and analyze logs ends up mediocre for metrics and vice versa. I don't think I've seen single product that did both well or efficiently. So I'd rather have good metrics and just use ELK/Graylog/whatever else for logs.

matsemann 3y ago
Not really the biggest difference, I feel. In Prometheus, you only have the data you scrape. So lets say you scrape every minute. Then all you have is a counter per pod increasing from some value to something else. With influx you can save every event. So you know exactly when it happened, the unique labels for that event etc. It's a completely different paradigm. So in Prometheus you have myCounter,pod=1,time=20:23,value=1000 myCounter,pod=2,time=20:23,value=500 myCounter,pod=1,time=20:24,value=1100 myCounter,pod=2,time=20:24,value=700 so all you know is that some event happened 100 times on pod1 and 200 times on pod2 the last minute. But with influx you could have a row for every single event. Of course that explodes the query time in comparison, but allows you to do much more with the data if needed.

hagen1778 3y ago

> Prometheus only handle aggregated data, though. That's not true. You're referring to pull-based approach for metrics collection. It has its tradeoffs (like fixed interval scraping), but has a lot of benefits too (like higher reliability). Check the following link [0] from VictoriaMetrics docs, which supports both push and pull approaches. Prometheus also gained push support this year, though. However, the main difference between Prometheus-like systems (Thanos, Mimir, VictoriaMetrics) and more traditional DBs for time series like InfluxDB or TimescaleDB is that first are designed to reflect system's state, and last are designed to reflect system's events. That's the main difference in paradigm, data model, and query languages. There is a reason why PromQL is so easy in 99% of cases, and so complex and annoying when users want to express what they get used to in traditional databases. I'm saying this because I went through creating a Grafana datasource for ClickHouse [1] and I felt how complicated it is to express a most straightforward PromQL query in SQL, and vice versa. If you'd like to learn more about differences between common queries for plotting time series in PromQL and SQL see my talk here [2]. [0] https://docs.victoriametrics.com/keyConcepts.html#write-data https://docs.victoriametrics.com/keyConcepts.html#write-data [1] https://grafana.com/grafana/plugins/vertamedia-clickhouse-datasource/ https://grafana.com/grafana/plugins/vertamedia-clickhouse-da... [2] https://youtu.be/_zORxrgLtec?t=835 https://youtu.be/_zORxrgLtec?t=835