Fix doc menu order, fix spelling of time series.

content/docs/concepts/automatic.md

@@ -8,7 +8,7 @@ sort_rank: 3
 ## Automatically attached labels
 
 When Prometheus scrapes a target, it attaches some labels automatically to the
-scraped metrics timeseries which serve to identify the scraped target:
+scraped metrics time series which serve to identify the scraped target:
 
 * `job`: The configured Prometheus job name for which the target was scraped.
 * `instance`: The specific URL of the instance's endpoint that was scraped.
@@ -18,9 +18,9 @@ replaced. Instead, Prometheus adds its own labels with `exporter_` prepended to
 the label name: `exporter_job` and `exporter_instance`. The same pattern holds
 true for any manually supplied base labels supplied for a target group.
 
-## Synthetic timeseries
-Prometheus also generates some timeseries internally which are not directly
+## Synthetic time series
+Prometheus also generates some time series internally which are not directly
 taken from the scraped data:
 
 * `up`: for each endpoint scrape, a sample of the form `up{job="...", instance="..."}` is stored, with a value of `1.0` indicating that the target was successfully scraped (it is up) and `0.0` indicating that the endpoint is down.
-* `ALERTS`: for pending and firing alerts, a timeseries of the form `ALERTS{alertname="...", alertstate="pending|firing",...alertlabels...}` is written out. The sample value is 1.0 as long as the alert is in the indicated active (pending/firing) state, but a single 0.0 value gets written out when an alert transitions from active to inactive state.
+* `ALERTS`: for pending and firing alerts, a time series of the form `ALERTS{alertname="...", alertstate="pending|firing",...alertlabels...}` is written out. The sample value is 1.0 as long as the alert is in the indicated active (pending/firing) state, but a single 0.0 value gets written out when an alert transitions from active to inactive state.

content/docs/concepts/metric_types.md

@@ -17,7 +17,7 @@ right one for the right job.
 Metric types are currently only differentiated in the client libraries (to
 enable APIs tailored to the usage of the specific types) and in the wire
 protocol. The Prometheus server does not yet make use of the type information
-after ingesting samples as timeseries. This may change in the future.
+after ingesting samples as time series. This may change in the future.
 
 ## Counter
 

content/docs/concepts/timeseries.md → content/docs/concepts/time_series.md

 ---
-title: Timeseries
+title: Time series
 sort_rank: 1
 ---
 
-# Timeseries
+# Time series
 
-Prometheus fundamentally stores all data as [timeseries](http://en.wikipedia.org/wiki/Time_series).
+Prometheus fundamentally stores all data as
+[time series](http://en.wikipedia.org/wiki/Time_series): series of
+timestamp values.
 
 ## Identification
-Timeseries are uniquely identified by a _metric name_ and a set of _key-value
+Time series are uniquely identified by a _metric name_ and a set of _key-value
 pairs_, also known as labels. Changing any label value, including adding or
-removing a label, will result in a new timeseries.
+removing a label, will result in a new time series.
 
 Metric names must match the regular expression `[a-zA-Z_:][a-zA-Z0-9_:]`.
 
 ## Samples
-Samples form the actual data that timeseries consist of. A sample consists of:
+Samples form the actual data that time series consist of. A sample consists of:
 
    * a value with float64-precision
    * a timestamp with millisecond-precision
 
 ## Notation
-Given a metric name and a set of labels, we frequently identify timeseries using this notation:
+Given a metric name and a set of labels, we frequently identify time series using this notation:
 
     <metric name>{<label name>=<label value>, ...}
 
-For example, a timeseries with the metric name `api_http_requests_total` and
+For example, a time series with the metric name `api_http_requests_total` and
 the labels `method="POST"` and `handler="/messages"` could be written like
 this:
 

content/docs/instrumenting/index.md

 ---
 title: Instrumenting
-sort_rank: 4
+sort_rank: 5
 nav_icon: code
 ---
-

content/docs/introduction/codelab.md

@@ -9,7 +9,7 @@ This guide is a "Hello World"-style codelab which shows how to install,
 configure, and use Prometheus in a simple example setup. You'll build and run
 Prometheus locally, configure it to scrape itself and an example application,
 and then work with queries, rules, and graphs to make use of the collected
-timeseries data.
+time series data.
 
 ## Getting Prometheus
 
@@ -45,7 +45,7 @@ global: {
   scrape_interval: "15s"     # By default, scrape targets every 15 seconds.
   evaluation_interval: "15s" # By default, evaluate rules every 15 seconds.
 
-  # Attach these extra labels to all timeseries collected by this Prometheus instance.
+  # Attach these extra labels to all time series collected by this Prometheus instance.
   labels: {
     label: {
       name: "monitor"
@@ -56,7 +56,7 @@ global: {
 
 # A job definition containing exactly one endpoint to scrape: Prometheus itself.
 job: {
-  # The job name is added as a label `job={job-name}` to any timeseries scraped from this job.
+  # The job name is added as a label `job={job-name}` to any time series scraped from this job.
   name: "prometheus"
   # Override the global default and scrape targets from this job every 5 seconds.
   scrape_interval: "5s"
@@ -108,12 +108,12 @@ expression console:
 prometheus_target_operation_latency_milliseconds
 ```
 
-This should return a lot of different timeseries (along with the latest value
+This should return a lot of different time series (along with the latest value
 recorded for each), all with the metric name
 `prometheus_target_operation_latency_milliseconds`, but with different labels. These
 labels designate different latency percentiles and operation outcomes.
 
-To count the number of returned timeseries, you could write:
+To count the number of returned time series, you could write:
 
 ```
 count(prometheus_target_operation_latency_milliseconds)
@@ -149,7 +149,7 @@ Let's make this more interesting and start some example targets for Prometheus
 to scrape.
 
 Download the Go client library for Prometheus, and run some random examples
-from it that export timeseries with random data:
+from it that export time series with random data:
 
 ```bash
 # Fetch the client library code:
@@ -212,14 +212,14 @@ job: {
 ```
 
 Go to the expression browser and verify that Prometheus now has information
-about timeseries that these example endpoints expose, e.g. the
+about time series that these example endpoints expose, e.g. the
 `rpc_calls_total` metric.
 
-## Configure rules for aggregating scraped data into new timeseries
+## Configure rules for aggregating scraped data into new time series
 
-Queries that aggregate over thousands of timeseries can get slow when computed
+Queries that aggregate over thousands of time series can get slow when computed
 ad-hoc. To make this more efficient, Prometheus allows you to prerecord
-expressions into completely new persisted timeseries via configured recording
+expressions into completely new persisted time series via configured recording
 rules. Let's say we're interested in recording the per-second rate of
 `rpc_calls_total` averaged over all instances as measured over the last 5
 minutes. We could write this as:
@@ -228,7 +228,7 @@ minutes. We could write this as:
 avg(rate(rpc_calls_total[5m]))
 ```
 
-To record this expression as a new timeseries called `rpc_calls_rate`, create a
+To record this expression as a new time series called `rpc_calls_rate`, create a
 file with the following recording rule and save it as `prometheus.rules`:
 
 ```
@@ -245,7 +245,7 @@ global: {
   scrape_interval: "15s"     # By default, scrape targets every 15 seconds.
   evaluation_interval: "15s" # By default, evaluate rules every 15 seconds.
 
-  # Attach these extra labels to all timeseries collected by this Prometheus instance.
+  # Attach these extra labels to all time series collected by this Prometheus instance.
   labels: {
     label: {
       name: "monitor"
@@ -257,6 +257,6 @@ global: {
 }
 ```
 
-Restart Prometheus with the new configuration and verify that a new timeseries
+Restart Prometheus with the new configuration and verify that a new time series
 with the metric name `rpc_calls_rate_mean` is now available by querying it
 through the expression browser or graphing it.

content/docs/introduction/overview.md

@@ -13,12 +13,12 @@ Since its inception in 2012, it has become the standard for instrumenting new
 services at SoundCloud and has seen growing external usage and contributions.
 Prometheus's main distinguishing features are:
 
-- a **multi-dimensional** data model (timeseries identified by metric name and key/value pairs)
+- a **multi-dimensional** data model (time series identified by metric name and key/value pairs)
 - a [**flexible query language**](/docs/using/querying/basics/)
   to leverage this dimensionality
 - no reliance on distributed storage; **single server nodes are autonomous**
-- timeseries collection happens via a **pull model** over HTTP
-- **pushing timeseries** is supported via an intermediary gateway
+- time series collection happens via a **pull model** over HTTP
+- **pushing time series** is supported via an intermediary gateway
 - targets are discovered via **service discovery** or **static configuration**
 - multiple modes of **graphing and dashboarding support**
 - **federation support** coming soon
@@ -26,7 +26,7 @@ Prometheus's main distinguishing features are:
 The Prometheus ecosystem consists of multiple components, many of which are
 optional:
 
-- the main [Prometheus server](https://github.com/prometheus/prometheus) which scrapes and stores timeseries data
+- the main [Prometheus server](https://github.com/prometheus/prometheus) which scrapes and stores time series data
 - client libraries for instrumenting application code
 - a [push gateway](https://github.com/prometheus/pushgateway) for supporting short-lived jobs
 - a [GUI-based dashboard builder](PromDash) based on Rails/SQL

content/docs/operating/rules.md

@@ -32,7 +32,7 @@ If there are any syntax errors, it prints an error message and exits with a
 
 ## Recording rules
 Recording rules allow you to precompute frequently needed or computationally
-expensive expressions and save their result as a new set of timeseries.
+expensive expressions and save their result as a new set of time series.
 Querying the precomputed result will then often be much faster than executing
 the original expression every time it is needed. This is especially useful for
 dashboards, which need to query the same expression repeatedly every time they
@@ -41,21 +41,21 @@ refresh.
 To add a new recording rule, add a line of the following syntax to your rule
 file:
 
-    <new timeseries name>[{<label overrides>}] = <expression to record>
+    <new time series name>[{<label overrides>}] = <expression to record>
 
 Some examples:
 
-    // Saving the per-job HTTP request count as a new set of timeseries:
+    // Saving the per-job HTTP request count as a new set of time series:
     job:api_http_requests_total:sum = sum(api_http_requests_total) by (job)
 
-    // Drop or rewrite labels in the result timeseries:
-    new_timeseries{label_to_change="new_value",label_to_drop=""} = old_timeseries
+    // Drop or rewrite labels in the result time series:
+    new_time series{label_to_change="new_value",label_to_drop=""} = old_time series
 
 Recording rules are evaluated at the interval specified by the
 `evaluation_interval` field in the Prometheus configuration. During each
 evaluation cycle, the right-hand-side expression of the rule statement is
 evaluated at the current instant in time and the resulting sample vector is
-stored as a new set of timeseries with the current timestamp and a new metric
+stored as a new set of time series with the current timestamp and a new metric
 name (and perhaps an overridden set of labels).
 
 ## Alerting rules

content/docs/practices/index.md

 ---
 title: Best practices
-sort_rank: 6
+sort_rank: 7
 nav_icon: thumbs-o-up
 ---

content/docs/practices/pushing.md

@@ -9,7 +9,7 @@ Occasionally you will need to monitor components which cannot be scraped: They
 might be behind a firewall, or they might be too short-lived to expose data
 reliably via the pull model. The
 [push gateway](https://github.com/prometheus/pushgateway) allows you to push
-timeseries from these components to an intermediary job which Prometheus can
+time series from these components to an intermediary job which Prometheus can
 scrape.
 
 For more information on installing and using the push gateway, see the

content/docs/querying/basics.md

@@ -8,7 +8,7 @@ sort_rank: 1
 ## Overview
 
 Prometheus provides a functional expression language that lets the user select
-and aggregate timeseries data in real-time. The result of an expression can
+and aggregate time series data in real-time. The result of an expression can
 either be shown as a graph, viewed as data in the expression browser, or
 consumed and further processed by external systems via the HTTP API.
 
@@ -19,25 +19,25 @@ start with a couple of [examples](/docs/using/querying/examples).
 
 ## Basic Concepts
 
-### Timeseries
+### Time series
 
-Data in Prometheus is stored as timeseries, which are uniquely identified by a
-metric name and a set of arbitrary label/value pairs. Each timeseries can have
+Data in Prometheus is stored as time series, which are uniquely identified by a
+metric name and a set of arbitrary label/value pairs. Each time series can have
 one or more data points attached to it. Data points are timestamp/value pairs.
 
 #### Metric name
-The metric name of a timeseries (e.g. `http_requests_total`) specifies the
+The metric name of a time series (e.g. `http_requests_total`) specifies the
 general feature of a system that is measured. It may contain alpha-numeric
 characters, plus underscores and colons.
 
 #### Labels
-The label/value pairs which identify a timeseries allow later filtering and
+The label/value pairs which identify a time series allow later filtering and
 aggregation by these dimensions (e.g. `endpoint`, `response_code`, `instance`). Label keys
 are identifiers (alpha-numeric characters plus underscores, but no colons),
 while their values may be arbitrary strings.
 
 #### Data points
-Each timeseries can have one or more data points attached to it, which are
+Each time series can have one or more data points attached to it, which are
 timestamp/value pairs. Values are always encoded as floating-point numbers
 (currently 64-bit precision).
 
@@ -48,8 +48,8 @@ evaluate to one of four types:
 
 * **string**
 * **scalar** - simple numeric floating point value
-* **instant vector** - vector of multiple timeseries, containing a single sample for each timeseries, with all samples sharing the same (instant) timestamp
-* **range vector** - vector of multiple timeseries, containing a range of data points over time for each timeseries
+* **instant vector** - vector of multiple time series, containing a single sample for each time series, with all samples sharing the same (instant) timestamp
+* **range vector** - vector of multiple time series, containing a range of data points over time for each time series
 
 Depending on the use-case (e.g. when graphing vs. displaying the output of an
 expression), only some of these types are legal as the result from a
@@ -73,24 +73,24 @@ Scalar float values can be literally written as numbers of the form
 
     -2.43
 
-## Timeseries Selectors
+## Time series Selectors
 
 ### Instant Vector Selectors
 
-Instant vector selectors allow the selection of a set of timeseries and a
+Instant vector selectors allow the selection of a set of time series and a
 single sample value for each at a given timestamp (instant): in the simplest
 form, only a metric name is specified. This results in an instant vector
-containing elements for all timeseries that have this metric name.
+containing elements for all time series that have this metric name.
 
-This example selects all timeseries that have the `http_requests_total` metric
+This example selects all time series that have the `http_requests_total` metric
 name:
 
     http_requests_total
 
-It is possible to filter these timeseries further by appending a set of labels
+It is possible to filter these time series further by appending a set of labels
 to match in curly braces (`{}`).
 
-This example selects only those timeseries with the `http_requests_total`
+This example selects only those time series with the `http_requests_total`
 metric name that also have the `job` label set to `prometheus` and their
 `group` label set to `canary`:
 
@@ -104,7 +104,7 @@ again regular expressions. The following label matching operators exist:
 * `=~`: Select labels that regex-match the provided string (or substring).
 * `!~`: Select labels that do not regex-match the provided string (or substring).
 
-For example, this selects all `http_requests_total` timeseries for `staging`,
+For example, this selects all `http_requests_total` time series for `staging`,
 `testing`, and `development` environments and HTTP methods other than `GET`.
 
     http_requests_total{environment=~"staging|testing|development",method!="GET"}
@@ -128,7 +128,7 @@ following units:
 * `y` - years
 
 In this example, we select all the values we have recorded within the last 5
-minutes for all timeseries that have the metric name `http_requests_total` and
+minutes for all time series that have the metric name `http_requests_total` and
 a `job` label set to `prometheus`:
 
     http_requests_total{job="prometheus"}[5m]

content/docs/querying/examples.md

@@ -7,12 +7,12 @@ sort_rank: 4
 
 ## Simple literals
 
-Return (as a sample vector) all timeseries with the metric
+Return (as a sample vector) all time series with the metric
 `http_requests_total`:
 
     http_requests_total
 
-Return (as a sample vector) all timeseries with the metric
+Return (as a sample vector) all time series with the metric
 `http_requests_total` and the given `job` and `group` labels:
 
     http_requests_total{job="prometheus", group="canary"}
@@ -24,13 +24,13 @@ making it a range vector:
 
 ## Using Functions, Operators, etc.
 
-Return (as a sample vector) the per-second rate for all timeseries with the
+Return (as a sample vector) the per-second rate for all time series with the
 `http_requests_total` metric name, as measured over the last 5 minutes:
 
     rate(http_requests_total[5m])
 
-Let's say that the `http_request_totals` timeseries all have the labels `job`
+Let's say that the `http_request_totals` time series all have the labels `job`
 (fanout by job name) and `instance` (fanout by instance of the job). We might
-want to sum over the rate of all instances, so we get fewer output timeseries:
+want to sum over the rate of all instances, so we get fewer output time series:
 
     sum(rate(http_requests_total[5m]))

content/docs/querying/functions.md

@@ -12,7 +12,7 @@ their absolute value.
 
 ## count_scalar()
 
-`count_scalar(v instant-vector)` returns the number of elements in a timeseries
+`count_scalar(v instant-vector)` returns the number of elements in a time series
 vector as a scalar. This is in contrast to the `count()` aggregation operator,
 which always returns a vector (an empty one if the input vector is empty) and
 allows grouping by labels via a `by` clause.
@@ -20,15 +20,15 @@ allows grouping by labels via a `by` clause.
 ## delta()
 
 `delta(v range-vector, counter bool)` calculates the difference between the
-first and last value of each timeseries element in a range vector `v`,
+first and last value of each time series element in a range vector `v`,
 returning an instant vector with the given deltas and equivalent labels. If
-`counter` is set to `1` (`true`), the timeseries in the range vector are
+`counter` is set to `1` (`true`), the time series in the range vector are
 treated as monotonically increasing counters. Breaks in monotonicity (such as
 counter resets due to target restarts) are automatically adjusted for. Setting
 `counter` to `0` (`false`) turns this behavior off.
 
 Example which returns the total number of HTTP requests counted within the last
-5 minutes, per timeseries in the range vector:
+5 minutes, per time series in the range vector:
 
 ```
 delta(http_requests{job="api-server"}[5m], 1)
@@ -53,7 +53,7 @@ and value across all series in the input vector.
 * the `counter` argument is implicitly set to `1` (`true`)
 
 Example call which returns the per-second rate of HTTP requests as measured
-over the last 5 minutes, per timeseries in the range vector:
+over the last 5 minutes, per time series in the range vector:
 
 ```
 rate(http_requests{job="api-server"}[5m])

content/docs/querying/index.md

 ---
 title: Query language
-sort_rank: 2
+sort_rank: 3
 nav_icon: search
 ---

content/docs/querying/operators.md

@@ -21,7 +21,7 @@ and vector/vector value pairs.
 scalar that is the result of the operator applied to both scalar operands.
 
 **Between an instant vector and a scalar**, the operator is applied to the
-value of every data sample in the vector. E.g. if a timeseries instant vector
+value of every data sample in the vector. E.g. if a time series instant vector
 is multiplied by 2, the result is another vector in which every sample value of
 the original vector is multiplied by 2.
 
@@ -99,7 +99,7 @@ clause).
 
 Example:
 
-If the metric `http_requests_total` had timeseries that fan out by
+If the metric `http_requests_total` had time series that fan out by
 `application`, `instance`, and `group` labels, we could calculate the total
 number of seen HTTP requests per application and group over all instances via:
 

content/docs/visualization/index.md

 ---
 title: Visualization
-sort_rank: 3
+sort_rank: 4
 nav_icon: search
 ---
-

content/index.html

@@ -5,12 +5,12 @@ title: Home
   <div class="row">
     <div class="col-md-4">
       <h2><i class="fa fa-flask"></i> Data Model</h2>
-      <p class="desc">Prometheus implements a highly dimensional data model. Timeseries are identified by a metric name and a set of key-value pairs.</p>
+      <p class="desc">Prometheus implements a highly dimensional data model. Time series are identified by a metric name and a set of key-value pairs.</p>
       <p><a class="btn btn-default" href="#" role="button">View details &raquo;</a></p>
     </div>
     <div class="col-md-4">
       <h2><i class="fa fa-search"></i> Query Language</h2>
-      <p class="desc">A flexible query languge allows slicing and dicing of collected timeseries data in order to generate ad-hoc graphs, tables, and alerts.</p>
+      <p class="desc">A flexible query languge allows slicing and dicing of collected time series data in order to generate ad-hoc graphs, tables, and alerts.</p>
       <p><a class="btn btn-default" href="#" role="button">View details &raquo;</a></p>
     </div>
     <div class="col-md-4">
@@ -22,12 +22,12 @@ title: Home
   <div class="row">
     <div class="col-md-4">
       <h2><i class="fa fa-cloud-download"></i> Pull Model</h2>
-      <p class="desc">Prometheus collects timeseries data by scraping instrumented services. This allows Prometheus to detect when targets are down.</p>
+      <p class="desc">Prometheus collects time series data by scraping instrumented services. This allows Prometheus to detect when targets are down.</p>
       <p><a class="btn btn-default" href="#" role="button">View details &raquo;</a></p>
     </div>
     <div class="col-md-4">
       <h2><i class="fa fa-database"></i> Storage</h2>
-      <p class="desc">Prometheus stores timeseries in memory and on local disk in an efficient custom format. Scaling is achieved by functional sharding and federation.</p>
+      <p class="desc">Prometheus stores time series in memory and on local disk in an efficient custom format. Scaling is achieved by functional sharding and federation.</p>
       <p><a class="btn btn-default" href="#" role="button">View details &raquo;</a></p>
     </div>
     <div class="col-md-4">

layouts/jumbotron.html

@@ -3,7 +3,7 @@
 <div class="jumbotron">
   <div class="container">
     <h1>Prometheus</h1>
-    <p class="subtitle">An open-source service monitoring system and timeseries database.</p>
+    <p class="subtitle">An open-source service monitoring system and time series database.</p>
     <p><a class="btn btn-default btn-lg" href="/docs/introduction/overview" role="button">Get Started</a></p>
   </div>
 </div>