Kiu/VictoriaMetrics
Kiu/VictoriaMetrics
1
0
Fork 0
mirror of https://github.com/VictoriaMetrics/VictoriaMetrics.git synced 2024-12-12 12:46:23 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

docs: remove img width

Browse Source 
Signed-off-by: Artem Navoiev <tenmozes@gmail.com>
This commit is contained in:
Artem Navoiev 2024-07-24 20:09:03 +02:00 committed by Aliaksandr Valialkin
parent 85d624d6c2
commit 61f9e3112d
No known key found for this signature in database
GPG Key ID: 52C003EE2BCDB9EB
4 changed files with 17 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
docs/anomaly-detection/Presets.md
View File

@ -39,7 +39,7 @@ Run a service using config file with one of the [available options](./QuickStart
After you run `vmanomaly` with `preset` arg specified, available assets can be viewed, copied and downloaded at `http://localhost:8490/presets/` endpoint.
![preset-localhost](presets-localhost.webp)
{width="800px"}
## Node-Exporter
@ -210,25 +210,25 @@ Here's how attached [Grafana dashboard](https://github.com/VictoriaMetrics/Victo
On the (global) graph **'Percentage of Anomalies'**, you can see a spike 8.75% of anomalies at the timestamp '2024-06-03 10:35:00'. The (global) graph **'Anomalies per Indicator'** shows the indicators that were anomalous at the corresponding time.
![global](presets_global_percentage.webp)
{width="800px"}
At this timestamp on the **'Number of Anomalous Indicators by Node'** graph we can identify the node that had the most anomalies: `10.142.0.27`
![by_node](presets_anomalies_by_node.webp)
{width="800px"}
Now you can select anomalous node to drill down further (local):
![anomalous_node_selection](presets_anomalous_node_selection.webp)
{width="800px"}
For this node from the timestamp `2024-06-03 10:35:00` CPU time spent handling software interrupts started to grow.
(`cpu_seconds_total{mode="softirq"}`)
![irq](presets_cpu_seconds_softirq.webp)
{width="800px"}
At the same time `cpu_seconds_total` for `steal` mode started to grow as well.
![steal](presets_cpu_seconds_steal.webp)
{width="800px"}

2
docs/anomaly-detection/components/README.md
View File

@ -16,7 +16,7 @@ Below, you will find an example illustrating how the components of `vmanomaly` i
> **Note**: [Reader](./reader.md#vm-reader) and [Writer](./writer.md#vm-writer) also support [multitenancy](../../Cluster-VictoriaMetrics.md#multitenancy), so you can read/write from/to different locations - see `tenant_id` param description.
![vmanomaly-components](vmanomaly-components.webp){width="800px"}
![vmanomaly-components](vmanomaly-components.webp)
Here's a minimalistic full config example, demonstrating many-to-many configuration (actual for [latest version](../CHANGELOG.md)):

18
docs/anomaly-detection/components/models.md
View File

@ -133,21 +133,21 @@ Introduced in [1.13.0](../CHANGELOG.md#1130), `detection_direction` arg can help
Here's how default (backward-compatible) behavior looks like - anomalies will be tracked in `both` directions (`y > yhat` or `y < yhat`). This is useful when there is no domain expertise to filter the required direction.
![schema_detection_direction=both](schema_detection_direction=both.webp)
{width="800px"}
When set to `above_expected`, anomalies are tracked only when `y > yhat`.
*Example metrics*: Error rate, response time, page load time, number of failed transactions - metrics where *lower values are better*, so **higher** values are typically tracked.
![schema_detection_direction=above_expected](schema_detection_direction=above_expected.webp)
{width="800px"}
When set to `below_expected`, anomalies are tracked only when `y < yhat`.
*Example metrics*: Service Level Agreement (SLA) compliance, conversion rate, Customer Satisfaction Score (CSAT) - metrics where *higher values are better*, so **lower** values are typically tracked.
![schema_detection_direction=below_expected](schema_detection_direction=below_expected.webp)
{width="800px"}
Config with a split example:
@ -194,10 +194,10 @@ Introduced in [v1.13.0](../CHANGELOG.md#1130), the `min_dev_from_expected` argum
Visualizations below demonstrate this concept; the green zone defined as the `[yhat - min_dev_from_expected, yhat + min_dev_from_expected]` range excludes actual data points (`y`) from generating anomaly scores if they fall within that range.
![min_dev_from_expected-default](schema_min_dev_from_expected=0.webp)
{width="800px"}
![min_dev_from_expected-small](schema_min_dev_from_expected=1.0.webp)
{width="800px"}
![min_dev_from_expected-big](schema_min_dev_from_expected=5.0.webp)
{width="800px}
@ -251,7 +251,7 @@ If during an inference, you got a series having **new labelset** (not present in
<p></p>
![vmanomaly-model-type-univariate](model-lifecycle-univariate.webp)
{width="800px"}
### Multivariate Models
@ -267,7 +267,7 @@ If during an inference, you got a **different amount of series** or some series
<p></p>
![vmanomaly-model-type-multivariate](model-lifecycle-multivariate.webp)
{width="800px"}
### Rolling Models
@ -285,7 +285,7 @@ Such models put **more pressure** on your reader's source, i.e. if your model sh
<p></p>
![vmanomaly-model-type-rolling](model-type-rolling.webp)
{width="800px"}
### Non-Rolling Models
@ -343,7 +343,7 @@ Tuning hyperparameters of a model can be tricky and often requires in-depth know
- `timeout` (float) - How many seconds in total can be spent on each model to tune hyperparameters. The higher, the longer it takes, allowing to test more trials out of defined `n_trials`, but the better the results can be.
![vmanomaly-autotune-schema](autotune.webp)
{width="800px"}
```yaml
# ...

2
docs/vmalert.md
View File

@ -585,7 +585,7 @@ Alertmanagers.
```
![vmalert ha](vmalert_ha.webp)
{width="800px"}
To avoid recording rules results and alerts state duplication in VictoriaMetrics server
don't forget to configure [deduplication](./Single-Server-VictoriaMetrics.md#deduplication).