Add Graphite/OpenTSDB comparison info.

content/docs/introduction/comparison.md

@@ -5,27 +5,34 @@ sort_rank: 4
 
 # Comparison to alternatives
 
-## Graphite
+## Prometheus vs. Graphite
 
-**Scope**
+### Scope
 
-[Graphite](http://graphite.readthedocs.org/en/latest/)
+[Graphite](http://graphite.readthedocs.org/en/latest/) focusses on being a
+passive time series database with a query language and graphing features. Any
+other concerns are addressed by external components.
 
-TODO: TODO: explain scope of Graphite.
+Prometheus is a full monitoring and trending system that includes built-in and
+active scraping, storing, querying, graphing, and alerting based on time series
+data. It has knowledge about what the world should look like (which endpoints
+should exist, what time series patterns mean trouble, etc.), and actively tries
+to find faults.
 
-**Data model**
+### Data model
 
 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 (labels) attached
-to a metric name. This allows easy filtering and grouping by these labels via
-its query language.
+to a metric name. This allows easy filtering, grouping, and matching by these
+labels via in the query language.
 
-Further, especially when Graphite is used in combination with StatsD, it is
-common to store only aggregated data over all monitored instances, rather than
-preserving the instance as a dimension and being able to drill down into
-individual problematic ones.
+Further, especially when Graphite is used in combination with
+[StatsD](https://github.com/etsy/statsd/), it is common to store only
+aggregated data over all monitored instances, rather than preserving the
+instance as a dimension and being able to drill down into individual
+problematic ones.
 
 As an example, storing the number of HTTP requests to API servers with the
 response code `500` and the method `POST` to the `/tracks` controller would
@@ -43,19 +50,20 @@ api_server_http_requests_total{method="POST","handler="/tracks",status="500",ins
 api_server_http_requests_total{method="POST","handler="/tracks",status="500",instance="<sample3>"} -> 31
 ```
 
-**Storage**
-
-Graphite's storage format expects samples to arrive at regular intervals, while
-Prometheus stores data at arbitrary intervals, as the data gets stored.
-
-TODO: TODO: Explain more about how timeseries data is stored in Prometheus vs.
-Graphite's Whisper.
+### Storage
 
-**Sample ingestion**
+Graphite stores time series data on local disk in the
+[Whisper](http://graphite.readthedocs.org/en/latest/whisper.html) format, an
+RRD-style database that expects samples to arrive at regular intervals. Every
+timeseries is stored in a separate file, and new samples overwrite old ones
+after a certain amount of time.
 
-TODO: TODO: Explain StatsD vs. Prometheus data ingestion.
+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 timeseries.
 
-## InfluxDB
+## Prometheus vs. InfluxDB
 
 [InfluxDB](http://influxdb.com/) is a very promising new open-source time
 series database. It didn't exist when Prometheus development began, so we were
@@ -66,18 +74,12 @@ geared towards slightly different use cases.
 The comparisons below attempt to help you choose the right system for your use
 case and taste:
 
-**Scope**
+### Scope
 
-InfluxDB focusses on being a passive time series database with a query
-language. Any other concerns are addressed by external components.
+The same scope differences as in the case of
+[Graphite](/docs/introduction/comparison/#prometheus-vs.-graphite) apply here.
 
-Prometheus is a full monitoring and trending system that includes built-in and
-active scraping, storing, querying, and alerting based on time series data. It
-has knowledge about what the world should look like (which endpoints should
-exist, what time series patterns mean trouble, etc.), and actively tries to find
-faults.
-
-**Data model / storage**
+### Data model / storage
 
 *Summary:* InfluxDB stores rows of events with full metadata for each event;
 Prometheus only stores numeric samples for existing time series. Both are good
@@ -116,7 +118,7 @@ Still, InfluxDB is better geared towards the following use cases:
 There are other storage features, such as downsampling, which InfluxDB supports
 and Prometheus doesn't yet.
 
-**Architecture**
+### Architecture
 
 Prometheus servers run independently of each other and only rely on their local
 storage for their core functionality: scraping, rule processing, and alerting.
@@ -135,4 +137,30 @@ node outages due to data replication.
 
 ## OpenTSDB
 
-TODO: TODO: compare Prometheus to OpenTSDB.
+[OpenTSDB](http://opentsdb.net/) is a distributed time series database based on
+[Hadoop](http://hadoop.apache.org/) and [HBase](http://hbase.apache.org/).
+
+### Scope
+
+The same scope differences as in the case of
+[Graphite](/docs/introduction/comparison/#prometheus-vs.-graphite) apply here.
+
+### Data model
+
+OpenTSDB's data model is almost identical to Prometheus's: time series are
+identified by a set of arbitrary key-value pairs (OpenTSDB "tags" are
+Prometheus "labels"). There are minor differences though, such as that
+Prometheus allows arbitrary characters in label values, while OpenTSDB is more
+restrictive. OpenTSDB is also lacking a full query language, only allowing
+simple aggregations via its API.
+
+### Storage
+
+[OpenTSDB](http://opentsdb.net/)'s storage is implemented on top of
+[Hadoop](http://hadoop.apache.org/) and [HBase](http://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.
+
+Again, as in the case of InfluxDB, Prometheus will be simpler to run initially,
+but will require explicit sharding once the capacity of a single node is
+exceeded.

static/docs.css

@@ -120,11 +120,12 @@ footer p {
 }
 
 .doc-content > h3 {
-  font-size: 25px;
+  font-size: 22px;
 }
 
 .doc-content > h4 {
-  font-size: 21px;
+  font-weight: bold;
+  font-size: 18px;
 }
 
 .doc-content a.header-anchor {