3 ms·

Doesn’t it also have cardinality issues?

• RhodesianHunter 6y ago
  There's no real way to develop a metrics system without cardinality issues. Where you draw the line depends on the backing database but they're all fairly constrained.
  • ashtonkem 6y ago
    Honestly, it’s incredibly impressive how far you can push them as is. We send a lot of data into these systems.
• halfmatthalfcat 6y ago
  You get high enough (hitting a metric with >100k unique labels), queries become unmanageable and incredibly slow when backed by the stock datastore (tsdb). However there are backing datastores (TimescaleDB, InfluxDB, VictoriaMetrics, etc) that ingest Prometheus metrics and enable higher cardinality.
  • roskilli 6y ago
    And M3DB too if you want to cluster and scale out, vs cloud store
  • unixhero 6y ago
    This is where I fall off. Is Prometheus a DB that (can) forward data to another DB?
    • halfmatthalfcat 6y ago
      Prometheus is a data format but it's also a "suite" of tools on top of that data format. Usually what happens is your app, db, whatever will expose metrics (http request status, average response time, etc) in the Prometheus format which is then scraped by the Prometheus ingestor. The ingestor stores those metrics in a (short-term) datastore called TSDB. Prometheus also ships with a little web UI as well that can query those metrics in TSDB. However Prometheus allows scraping from the ingestor (usually federation) or pushing into an external datastore that is usually more performant than TSDB. So when people say "Prometheus", they usually are talking about the suite of tools however practically it's really just the format of the metrics data.
      • unixhero 6y ago
        Thanks for the explanation
    • ecnahc515 6y ago
      Sort of. https://prometheus.io/docs/prometheus/latest/storage/#remote-storage-integrations https://prometheus.io/docs/prometheus/latest/storage/#remote...