# Comparison to Alternatives | Prometheus  URL:: https://prometheus.io/docs/introduction/comparison/ Author:: Prometheus ## Highlights > Prometheus vs. Graphite ([View Highlight](https://read.readwise.io/read/01ff0zaqhfhak88hwgxbe3ksqh)) > Graphite stores numeric samples for named time series, much like Prometheus does. However, Prometheus's metadata model is richer: while Graphite metric names consist of dot-separated components which implicitly encode dimensions, Prometheus encodes dimensions explicitly as key-value pairs, called labels, attached to a metric name. This allows easy filtering, grouping, and matching by these labels via the query language. ([View Highlight](https://read.readwise.io/read/01ff0zb0n693z3vbbhrse0p0dq)) > Graphite stores time series data on local disk in the [Whisper](https://graphite.readthedocs.org/en/latest/whisper.html) format, an RRD-style database that expects samples to arrive at regular intervals. Every time series is stored in a separate file, and new samples overwrite old ones after a certain amount of time. ([View Highlight](https://read.readwise.io/read/01ff0zb71ga3ae6548cmsk3vgg)) > Prometheus also creates one local file per time series, but allows storing samples at arbitrary intervals as scrapes or rule evaluations occur. Since new samples are simply appended, old data may be kept arbitrarily long. Prometheus also works well for many short-lived, frequently changing sets of time series. ([View Highlight](https://read.readwise.io/read/01ff0zb81t83xwh3z4hkbd5hkb)) > Prometheus vs. InfluxDB ([View Highlight](https://read.readwise.io/read/01ff0zbamgej0t1kypjbcs5tf1)) > For a fair comparison, we must also consider [Kapacitor](https://github.com/influxdata/kapacitor) together with InfluxDB, as in combination they address the same problem space as Prometheus and the Alertmanager. ([View Highlight](https://read.readwise.io/read/01ff0zbfedj4gk7ms0wazhvxm4)) > Like Prometheus, the InfluxDB data model has key-value pairs as labels, which are called tags. In addition, InfluxDB has a second level of labels called fields, which are more limited in use. InfluxDB supports timestamps with up to nanosecond resolution, and float64, int64, bool, and string data types. Prometheus, by contrast, supports the float64 data type with limited support for strings, and millisecond resolution timestamps. ([View Highlight](https://read.readwise.io/read/01ff0zbwk922cwc94vt3ymy2tg)) > Prometheus servers run independently of each other and only rely on their local storage for their core functionality: scraping, rule processing, and alerting. The open source version of InfluxDB is similar. ([View Highlight](https://read.readwise.io/read/01ff0zcbw70rx1cx1gyxjjxdm7)) > The commercial InfluxDB offering is, by design, a distributed storage cluster with storage and queries being handled by many nodes at once. ([View Highlight](https://read.readwise.io/read/01ff0zccems82xmb95cvsbydj5)) > This means that the commercial InfluxDB will be easier to scale horizontally, but it also means that you have to manage the complexity of a distributed storage system from the beginning. Prometheus will be simpler to run, but at some point you will need to shard servers explicitly along scalability boundaries like products, services, datacenters, or similar aspects. Independent servers (which can be run redundantly in parallel) may also give you better reliability and failure isolation. ([View Highlight](https://read.readwise.io/read/01ff0zcendbwh3g1wr9qradv8a)) > Where InfluxDB is better: > • If you're doing event logging. > • Commercial option offers clustering for InfluxDB, which is also better for long term data storage. > • Eventually consistent view of data between replicas. > Where Prometheus is better: > • If you're primarily doing metrics. > • More powerful query language, alerting, and notification functionality. > • Higher availability and uptime for graphing and alerting. ([View Highlight](https://read.readwise.io/read/01ff0zcsteak8nh1pexma7e36r)) > Prometheus vs. OpenTSDB ([View Highlight](https://read.readwise.io/read/01ff0zczkvt9j5n69gq3tgr0hq)) > [OpenTSDB](http://opentsdb.net/)'s storage is implemented on top of [Hadoop](https://hadoop.apache.org/) and [HBase](https://hbase.apache.org/). This means that it is easy to scale OpenTSDB horizontally, but you have to accept the overall complexity of running a Hadoop/HBase cluster from the beginning. ([View Highlight](https://read.readwise.io/read/01ff0zdgxxvzsk0365jpwjd7ab)) > Prometheus will be simpler to run initially, but will require explicit sharding once the capacity of a single node is exceeded. ([View Highlight](https://read.readwise.io/read/01ff0zdj1ge9v39s6jbgb3svt4)) > Prometheus offers a much richer query language, can handle higher cardinality metrics, and forms part of a complete monitoring system. If you're already running Hadoop and value long term storage over these benefits, OpenTSDB is a good choice. ([View Highlight](https://read.readwise.io/read/01ff0zdndgmgcjkfcv0p94dkx5)) > Prometheus vs. Nagios ([View Highlight](https://read.readwise.io/read/01ff0zdpp5q9qderb2qnw0s4m8)) > Nagios is primarily about alerting based on the exit codes of scripts. These are called “checks”. There is silencing of individual alerts, however no grouping, routing or deduplication. ([View Highlight](https://read.readwise.io/read/01ff0zdtjrajjga44fz4dj9zn9)) > Data model ([View Highlight](https://read.readwise.io/read/01ff0zdxxnb9kknpavr4d3chgj)) > Nagios is host-based. Each host can have one or more services and each service can perform one check. ([View Highlight](https://read.readwise.io/read/01ff0zdypta55h8rfff3e2zs45)) > There is no notion of labels or a query language. ([View Highlight](https://read.readwise.io/read/01ff0zdzbg8q9yq1q9vx45bw4t)) > Storage ([View Highlight](https://read.readwise.io/read/01ff0ze0bwp12thshetw5kmrhj)) > Nagios has no storage per-se, beyond the current check state. There are plugins which can store data such as [for visualisation](https://docs.pnp4nagios.org/). ([View Highlight](https://read.readwise.io/read/01ff0ze21pcrjm64xhp3pgp6an)) > Architecture ([View Highlight](https://read.readwise.io/read/01ff0ze3mmmetrpheyd9xs1k2z)) > Nagios servers are standalone. All configuration of checks is via file. ([View Highlight](https://read.readwise.io/read/01ff0ze49fg6bkn625z312974y)) > Nagios is suitable for basic monitoring of small and/or static systems where blackbox probing is sufficient. ([View Highlight](https://read.readwise.io/read/01ff0ze5qk8j7x9m8hs7mdka59)) > If you want to do whitebox monitoring, or have a dynamic or cloud based environment, then Prometheus is a good choice. ([View Highlight](https://read.readwise.io/read/01ff0ze6mcdqkw9mhm6g2k9qk5)) > Prometheus vs. Sensu ([View Highlight](https://read.readwise.io/read/01ff0ze89mchxf19dx05kgb9y9)) > Where Sensu is better: > • If you're collecting and processing hybrid observability data (including metrics *and/or* events) > • If you're consolidating multiple monitoring tools and need support for metrics *and* Nagios-style plugins or check scripts > • More powerful event-processing platform > Where Prometheus is better: > • If you're primarily collecting and evaluating metrics > • If you're monitoring homogeneous Kubernetes infrastructure (if 100% of the workloads you're monitoring are in K8s, Prometheus offers better K8s integration) > • More powerful query language, and built-in support for historical data analysis ([View Highlight](https://read.readwise.io/read/01ff0zf1fjz0cw64n14k9pj1vy)) --- Title: Comparison to Alternatives | Prometheus Author: Prometheus Tags: readwise, articles date: 2024-01-30 --- # Comparison to Alternatives | Prometheus  URL:: https://prometheus.io/docs/introduction/comparison/ Author:: Prometheus ## AI-Generated Summary An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach. ## Highlights > Prometheus vs. Graphite ([View Highlight](https://read.readwise.io/read/01ff0zaqhfhak88hwgxbe3ksqh)) > Graphite stores numeric samples for named time series, much like Prometheus does. However, Prometheus's metadata model is richer: while Graphite metric names consist of dot-separated components which implicitly encode dimensions, Prometheus encodes dimensions explicitly as key-value pairs, called labels, attached to a metric name. This allows easy filtering, grouping, and matching by these labels via the query language. ([View Highlight](https://read.readwise.io/read/01ff0zb0n693z3vbbhrse0p0dq)) > Graphite stores time series data on local disk in the [Whisper](https://graphite.readthedocs.org/en/latest/whisper.html) format, an RRD-style database that expects samples to arrive at regular intervals. Every time series is stored in a separate file, and new samples overwrite old ones after a certain amount of time. ([View Highlight](https://read.readwise.io/read/01ff0zb71ga3ae6548cmsk3vgg)) > Prometheus also creates one local file per time series, but allows storing samples at arbitrary intervals as scrapes or rule evaluations occur. Since new samples are simply appended, old data may be kept arbitrarily long. Prometheus also works well for many short-lived, frequently changing sets of time series. ([View Highlight](https://read.readwise.io/read/01ff0zb81t83xwh3z4hkbd5hkb)) > Prometheus vs. InfluxDB ([View Highlight](https://read.readwise.io/read/01ff0zbamgej0t1kypjbcs5tf1)) > For a fair comparison, we must also consider [Kapacitor](https://github.com/influxdata/kapacitor) together with InfluxDB, as in combination they address the same problem space as Prometheus and the Alertmanager. ([View Highlight](https://read.readwise.io/read/01ff0zbfedj4gk7ms0wazhvxm4)) > Like Prometheus, the InfluxDB data model has key-value pairs as labels, which are called tags. In addition, InfluxDB has a second level of labels called fields, which are more limited in use. InfluxDB supports timestamps with up to nanosecond resolution, and float64, int64, bool, and string data types. Prometheus, by contrast, supports the float64 data type with limited support for strings, and millisecond resolution timestamps. ([View Highlight](https://read.readwise.io/read/01ff0zbwk922cwc94vt3ymy2tg)) > Prometheus servers run independently of each other and only rely on their local storage for their core functionality: scraping, rule processing, and alerting. The open source version of InfluxDB is similar. ([View Highlight](https://read.readwise.io/read/01ff0zcbw70rx1cx1gyxjjxdm7)) > The commercial InfluxDB offering is, by design, a distributed storage cluster with storage and queries being handled by many nodes at once. ([View Highlight](https://read.readwise.io/read/01ff0zccems82xmb95cvsbydj5)) > This means that the commercial InfluxDB will be easier to scale horizontally, but it also means that you have to manage the complexity of a distributed storage system from the beginning. Prometheus will be simpler to run, but at some point you will need to shard servers explicitly along scalability boundaries like products, services, datacenters, or similar aspects. Independent servers (which can be run redundantly in parallel) may also give you better reliability and failure isolation. ([View Highlight](https://read.readwise.io/read/01ff0zcendbwh3g1wr9qradv8a)) > Where InfluxDB is better: > • If you're doing event logging. > • Commercial option offers clustering for InfluxDB, which is also better for long term data storage. > • Eventually consistent view of data between replicas. > Where Prometheus is better: > • If you're primarily doing metrics. > • More powerful query language, alerting, and notification functionality. > • Higher availability and uptime for graphing and alerting. ([View Highlight](https://read.readwise.io/read/01ff0zcsteak8nh1pexma7e36r)) > Prometheus vs. OpenTSDB ([View Highlight](https://read.readwise.io/read/01ff0zczkvt9j5n69gq3tgr0hq)) > [OpenTSDB](http://opentsdb.net/)'s storage is implemented on top of [Hadoop](https://hadoop.apache.org/) and [HBase](https://hbase.apache.org/). This means that it is easy to scale OpenTSDB horizontally, but you have to accept the overall complexity of running a Hadoop/HBase cluster from the beginning. ([View Highlight](https://read.readwise.io/read/01ff0zdgxxvzsk0365jpwjd7ab)) > Prometheus will be simpler to run initially, but will require explicit sharding once the capacity of a single node is exceeded. ([View Highlight](https://read.readwise.io/read/01ff0zdj1ge9v39s6jbgb3svt4)) > Prometheus offers a much richer query language, can handle higher cardinality metrics, and forms part of a complete monitoring system. If you're already running Hadoop and value long term storage over these benefits, OpenTSDB is a good choice. ([View Highlight](https://read.readwise.io/read/01ff0zdndgmgcjkfcv0p94dkx5)) > Prometheus vs. Nagios ([View Highlight](https://read.readwise.io/read/01ff0zdpp5q9qderb2qnw0s4m8)) > Nagios is primarily about alerting based on the exit codes of scripts. These are called “checks”. There is silencing of individual alerts, however no grouping, routing or deduplication. ([View Highlight](https://read.readwise.io/read/01ff0zdtjrajjga44fz4dj9zn9)) > Data model ([View Highlight](https://read.readwise.io/read/01ff0zdxxnb9kknpavr4d3chgj)) > Nagios is host-based. Each host can have one or more services and each service can perform one check. ([View Highlight](https://read.readwise.io/read/01ff0zdypta55h8rfff3e2zs45)) > There is no notion of labels or a query language. ([View Highlight](https://read.readwise.io/read/01ff0zdzbg8q9yq1q9vx45bw4t)) > Storage ([View Highlight](https://read.readwise.io/read/01ff0ze0bwp12thshetw5kmrhj)) > Nagios has no storage per-se, beyond the current check state. There are plugins which can store data such as [for visualisation](https://docs.pnp4nagios.org/). ([View Highlight](https://read.readwise.io/read/01ff0ze21pcrjm64xhp3pgp6an)) > Architecture ([View Highlight](https://read.readwise.io/read/01ff0ze3mmmetrpheyd9xs1k2z)) > Nagios servers are standalone. All configuration of checks is via file. ([View Highlight](https://read.readwise.io/read/01ff0ze49fg6bkn625z312974y)) > Nagios is suitable for basic monitoring of small and/or static systems where blackbox probing is sufficient. ([View Highlight](https://read.readwise.io/read/01ff0ze5qk8j7x9m8hs7mdka59)) > If you want to do whitebox monitoring, or have a dynamic or cloud based environment, then Prometheus is a good choice. ([View Highlight](https://read.readwise.io/read/01ff0ze6mcdqkw9mhm6g2k9qk5)) > Prometheus vs. Sensu ([View Highlight](https://read.readwise.io/read/01ff0ze89mchxf19dx05kgb9y9)) > Where Sensu is better: > • If you're collecting and processing hybrid observability data (including metrics *and/or* events) > • If you're consolidating multiple monitoring tools and need support for metrics *and* Nagios-style plugins or check scripts > • More powerful event-processing platform > Where Prometheus is better: > • If you're primarily collecting and evaluating metrics > • If you're monitoring homogeneous Kubernetes infrastructure (if 100% of the workloads you're monitoring are in K8s, Prometheus offers better K8s integration) > • More powerful query language, and built-in support for historical data analysis ([View Highlight](https://read.readwise.io/read/01ff0zf1fjz0cw64n14k9pj1vy))