docs: move keyconcepts to separate dir (#6855)
Moving key-concepts-related docs to a separate dir should make it easier to navigate in `docs/` folder and helps to avoid adding prefixes to image assets. ----------- The change shouldn't have any visual changes or changes to the links. Signed-off-by: hagen1778 <roman@victoriametrics.com>
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 24 KiB |
Before Width: | Height: | Size: 6 KiB After Width: | Height: | Size: 6 KiB |
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
Before Width: | Height: | Size: 30 KiB After Width: | Height: | Size: 30 KiB |
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 22 KiB |
|
@ -135,7 +135,7 @@ So, the `counter` metric shows the number of observed events since the service s
|
|||
|
||||
In programming, `counter` is a variable that you **increment** each time something happens.
|
||||
|
||||
![counter](keyConcepts_counter.webp)
|
||||
![counter](counter.webp)
|
||||
|
||||
`vm_http_requests_total` is a typical example of a counter. The interpretation of a graph
|
||||
above is that time series `vm_http_requests_total{instance="localhost:8428", job="victoriametrics", path="api/v1/query_range"}`
|
||||
|
@ -161,7 +161,7 @@ by humans from other metric types.
|
|||
|
||||
Gauge is used for measuring a value that can go up and down:
|
||||
|
||||
![gauge](keyConcepts_gauge.webp)
|
||||
![gauge](gauge.webp)
|
||||
|
||||
The metric `process_resident_memory_anon_bytes` on the graph shows the memory usage of the application at every given time.
|
||||
It is changing frequently, going up and down showing how the process allocates and frees the memory.
|
||||
|
@ -259,7 +259,7 @@ Such a combination of `counter` metrics allows
|
|||
plotting [Heatmaps in Grafana](https://grafana.com/docs/grafana/latest/visualizations/heatmap/)
|
||||
and calculating [quantiles](https://prometheus.io/docs/practices/histograms/#quantiles):
|
||||
|
||||
![histogram](keyConcepts_histogram.webp)
|
||||
![histogram](histogram.webp)
|
||||
|
||||
Grafana doesn't understand buckets with `vmrange` labels, so the [prometheus_buckets](https://docs.victoriametrics.com/metricsql/#prometheus_buckets)
|
||||
function must be used for converting buckets with `vmrange` labels to buckets with `le` labels before building heatmaps in Grafana.
|
||||
|
@ -301,7 +301,7 @@ go_gc_duration_seconds_count 83
|
|||
|
||||
The visualization of summaries is pretty straightforward:
|
||||
|
||||
![summary](keyConcepts_summary.webp)
|
||||
![summary](summary.webp)
|
||||
|
||||
Such an approach makes summaries easier to use but also puts significant limitations compared to [histograms](#histogram):
|
||||
|
||||
|
@ -372,7 +372,7 @@ VictoriaMetrics supports both models used in modern monitoring applications: [pu
|
|||
|
||||
Client regularly sends the collected metrics to the server in the push model:
|
||||
|
||||
![push model](keyConcepts_push_model.webp)
|
||||
![push model](push_model.webp)
|
||||
|
||||
The client (application) decides when and where to send its metrics. VictoriaMetrics supports many protocols
|
||||
for data ingestion (aka `push protocols`) - see [the full list here](https://docs.victoriametrics.com/#how-to-import-time-series-data).
|
||||
|
@ -417,7 +417,7 @@ The cons of push protocol:
|
|||
Pull model is an approach popularized by [Prometheus](https://prometheus.io/), where the monitoring system decides when
|
||||
and where to pull metrics from:
|
||||
|
||||
![pull model](keyConcepts_pull_model.webp)
|
||||
![pull model](pull_model.webp)
|
||||
|
||||
In pull model, the monitoring system needs to be aware of all the applications it needs to monitor. The metrics are
|
||||
scraped (pulled) from the known applications (aka `scrape targets`) via HTTP protocol on a regular basis (aka `scrape_interval`).
|
||||
|
@ -448,7 +448,7 @@ models for data collection. Many installations use exclusively one of these mode
|
|||
|
||||
The most common approach for data collection is using both models:
|
||||
|
||||
![data collection](keyConcepts_data_collection.webp)
|
||||
![data collection](data_collection.webp)
|
||||
|
||||
In this approach the additional component is used - [vmagent](https://docs.victoriametrics.com/vmagent/). Vmagent is
|
||||
a lightweight agent whose main purpose is to collect, filter, relabel and deliver metrics to VictoriaMetrics.
|
||||
|
@ -463,7 +463,7 @@ installation for querying collected data.
|
|||
|
||||
VictoriaMetrics components allow building more advanced topologies. For example, vmagents can push metrics from separate datacenters to the central VictoriaMetrics:
|
||||
|
||||
![two dcs](keyConcepts_two_dcs.webp)
|
||||
![two dcs](two_dcs.webp)
|
||||
|
||||
VictoriaMetrics in this example may be either [single-node VictoriaMetrics](https://docs.victoriametrics.com/single-server-victoriametrics/)
|
||||
or [VictoriaMetrics Cluster](https://docs.victoriametrics.com/cluster-victoriametrics/). Vmagent also allows
|
||||
|
@ -527,7 +527,7 @@ foo_bar 4.00 1652170560000 # 2022-05-10 10:16:00
|
|||
The data above contains a list of samples for the `foo_bar` time series with time intervals between samples
|
||||
ranging from 1m to 3m. If we plot this data sample on the graph, it will have the following form:
|
||||
|
||||
![data samples](keyConcepts_data_samples.webp)
|
||||
![data samples](data_samples.webp)
|
||||
{width="500"}
|
||||
|
||||
To get the value of the `foo_bar` series at some specific moment of time, for example `2022-05-10 10:03:00`, in
|
||||
|
@ -562,7 +562,7 @@ In response, VictoriaMetrics returns a single sample-timestamp pair with a value
|
|||
we'll see that there is no raw sample at `2022-05-10 10:03`. When there is no raw sample at the
|
||||
requested timestamp, VictoriaMetrics will try to locate the closest sample before the requested timestamp:
|
||||
|
||||
![instant query](keyConcepts_instant_query.webp)
|
||||
![instant query](instant_query.webp)
|
||||
{width="500"}
|
||||
|
||||
The time range in which VictoriaMetrics will try to locate a replacement for a missing data sample is equal to `5m`
|
||||
|
@ -703,7 +703,7 @@ see that it contains only 13 raw samples. What happens here is that the range qu
|
|||
an [instant query](#instant-query) executed `1 + (start-end)/step` times on the time range from `start` to `end`. If we plot
|
||||
this request in VictoriaMetrics the graph will be shown as the following:
|
||||
|
||||
![range query](keyConcepts_range_query.webp)
|
||||
![range query](range_query.webp)
|
||||
{width="500"}
|
||||
|
||||
The blue dotted lines in the figure are the moments when the instant query was executed. Since the instant query retains the
|
||||
|
@ -745,13 +745,13 @@ This flag prevents from non-consistent results due to the fact that only part of
|
|||
|
||||
Here is an illustration of a potential problem when `-search.latencyOffset` is set to zero:
|
||||
|
||||
![without latency offset](keyConcepts_without_latencyOffset.webp)
|
||||
![without latency offset](without_latencyOffset.webp)
|
||||
{width="1000"}
|
||||
|
||||
When this flag is set, the VM will return the last metric value collected before the `-search.latencyOffset`
|
||||
duration throughout the `-search.latencyOffset` duration:
|
||||
|
||||
![with latency offset](keyConcepts_with_latencyOffset.webp)
|
||||
![with latency offset](with_latencyOffset.webp)
|
||||
{width="1000"}
|
||||
|
||||
It can be overridden on per-query basis via `latency_offset` query arg.
|
||||
|
@ -950,7 +950,7 @@ VictoriaMetrics has a built-in graphical User Interface for querying and visuali
|
|||
[VMUI](https://docs.victoriametrics.com/single-server-victoriametrics/#vmui).
|
||||
Open `http://victoriametrics:8428/vmui` page, type the query and see the results:
|
||||
|
||||
![vmui](keyConcepts_vmui.webp)
|
||||
![vmui](vmui.webp)
|
||||
|
||||
VictoriaMetrics supports [Prometheus HTTP API](https://docs.victoriametrics.com/single-server-victoriametrics/#prometheus-querying-api-usage)
|
||||
which makes it possible to [query it with Grafana](https://docs.victoriametrics.com/single-server-victoriametrics/#grafana-setup)
|
Before Width: | Height: | Size: 9.2 KiB After Width: | Height: | Size: 9.2 KiB |
Before Width: | Height: | Size: 9.1 KiB After Width: | Height: | Size: 9.1 KiB |
Before Width: | Height: | Size: 41 KiB After Width: | Height: | Size: 41 KiB |
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 22 KiB |
Before Width: | Height: | Size: 360 KiB After Width: | Height: | Size: 360 KiB |
Before Width: | Height: | Size: 334 KiB After Width: | Height: | Size: 334 KiB |