mirror of
https://github.com/VictoriaMetrics/VictoriaMetrics.git
synced 2024-11-21 14:44:00 +00:00
docs: remove img width
Signed-off-by: Artem Navoiev <tenmozes@gmail.com>
This commit is contained in:
parent
ef0e6af6a8
commit
4735d8803e
4 changed files with 17 additions and 17 deletions
|
@ -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"}
|
||||
|
||||
|
|
|
@ -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)):
|
||||
|
||||
|
|
|
@ -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
|
||||
# ...
|
||||
|
|
|
@ -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).
|
||||
|
|
Loading…
Reference in a new issue