Docs upgrade for v1.30.0 release of vmanomaly, including:
- UX fixes and refreshed UI screenshots on `/anomaly-detection/` pages;
- revised AI tooling guidance and new cross-references to MCP, skills,
and UI Copilot;
- Temporal Envelope, autotune, reader, settings, and custom-model
documentation aligned with v1.30.0;
- updated self-monitoring metric names, labels, stage semantics,
resource-capacity descriptions, and license health metrics;
- corrections to outdated instructions across the anomaly-detection
documentation.
TODOs:
- [x] update UI screenshots
- [x] add cross-references
- [x] update stale monitoring metrics/logs page
This commit adds `name` label to the `vm_persistentqueue_*` metrics. It provides more context for queues with human read-able format. Because `path` label contains only on-disk path, which is not really useful.
For vmagent case it will contain remote.writeURL position at command-line args.
Fixes https://github.com/VictoriaMetrics/VictoriaMetrics/issues/7944
This PR exposes a new metric `vmalert_rule_group_results_limit` to track the effective results limit applied to a given rule group.
Currently, `vmalert` allows bounding the number of series returned by
evaluating a rule either globally (`-rule.resultsLimit`) or per group
(`groups[].limit`). However, the effective limit applied isn't easily
observable as a metric, which makes it difficult to natively construct
alerts for rules that are dropping output due to exceeding this limit.
By exposing `vmalert_rule_group_results_limit{group="...", file="..."}`,
users can seamlessly compare actual evaluation outputs against the
configured bounds natively using Prometheus/VictoriaMetrics, without
needing out-of-band workarounds.
**Changes:**
- Registers the `vmalert_rule_group_results_limit` gauge during group
initialization.
- Adds tests verifying limits correctly resolve from both global
fallbacks and per-group overrides.
Fixes https://github.com/VictoriaMetrics/VictoriaMetrics/issues/11179
PR https://github.com/VictoriaMetrics/VictoriaMetrics/pull/11182
---------
Signed-off-by: Vinyas Bharadwaj <vinyasbharadwaj101@gmail.com>
Signed-off-by: vinyas-bharadwaj <vinyasbharadwaj101@gmail.com>
Co-authored-by: Max Kotliar <mkotlyar@victoriametrics.com>
The issue could happen subtly and be hard to debug. It might also
generate confusing results. For example, if the system clock for vmalert
is moved 30m backward, vmalert would reset the evaluation timestamps to
30m ago, causing duplicate evaluations for timestamps within that 30m
window. Exposing a new group metric `vmalert_iteration_reset_total` to
help debuging this issue.
fixes:
https://github.com/VictoriaMetrics/VictoriaMetrics/issues/10985https://github.com/VictoriaMetrics/VictoriaMetrics/issues/10423.
`IndexDBRecordsDrop` and `TooManyTSIDMisses` were mistakenly placed to `alerts-health.yml`,
which was supposed to contain rules related to all VM components. But these two rules
are related to storage components only (vmstorage and vmsingle). Moving them to corresponding
files.
Signed-off-by: hagen1778 <roman@victoriametrics.com>
The change should reduce confusion for users where `alerts.yml`
belongs to. Before, developers could mistakenly assume that
`alerts.yml` was related to both single and cluster installations.
In result, rule `MetadataCacheUtilizationIsTooHigh` was added only
to `alerts.yml` and not copied to `alerts-cluster.yml`.
The rename change should bring more context into the file name
and reduce confusion in the future.
Signed-off-by: hagen1778 <roman@victoriametrics.com>
Before, this rule was only a part of single-node rule set.
But it is applicable for both: single and cluster installations.
Adding it to cluster as well.
Signed-off-by: hagen1778 <roman@victoriametrics.com>
The new rule `MetricNameStatsCacheUtilizationIsTooHigh` will signalize
about overutilization of Metric names usage stats tracker. See
https://docs.victoriametrics.com/victoriametrics/#track-ingested-metrics-usage
This rule can fire for deployments with high churn rate of metric names.
In cases like this, it is better to disable metric name tracking
completely, as it brings no use.
It might fire for deployments that were tracking metric names for very
long periods and this alert might be a good sign to reset the cache.
### Describe Your Changes
Please provide a brief description of the changes you made. Be as
specific as possible to help others understand the purpose and impact of
your modifications.
### Checklist
The following checks are **mandatory**:
- [ ] My change adheres to [VictoriaMetrics contributing
guidelines](https://docs.victoriametrics.com/victoriametrics/contributing/#pull-request-checklist).
- [ ] My change adheres to [VictoriaMetrics development
goals](https://docs.victoriametrics.com/victoriametrics/goals/).
---------
Signed-off-by: hagen1778 <roman@victoriametrics.com>
This commit adds new metrics `vmalert_remotewrite_queue_capacity` and `vmalert_remotewrite_queue_size`, which is updated with each push and it's
frequency depends on `-remoteWrite.concurrency`,
`remoteWrite.flushInterval`
It doesn't account for the pending data within each pushers request, it
should provide a general indication of the queue usage.
Related PR https://github.com/VictoriaMetrics/VictoriaMetrics/pull/10765
The new Grafana dashboard uses the following APIs:
- /api/v1/status/tsdb
- /api/v1/status/metric_names_stats
It shows the list of metric names, the request count and the last time
they were "used". Clicking on metric name allows exploring its
cardinality.
Based on https://github.com/VictoriaMetrics/VictoriaMetrics/issues/9832
-----------
The PR contains a few unrelated changes:
* rename of folder for prometheus datasource to remove the duplicated
word
* fix for vmalert's access to the datasource, as before it wasn't able
to write/read properly
-------------
The dashboard screen cast:
https://github.com/user-attachments/assets/01dda5d9-14e5-4f5a-b795-a838abec4f5e
---------
Signed-off-by: hagen1778 <roman@victoriametrics.com>
Co-authored-by: Haley Wang <haley@victoriametrics.com>
Enable BuildKit-native SPDX SBOM and provenance attestations by setting
`--sbom=true --provenance=true` in `docker buildx build` within
`publish-via-docker`.
- Set `--provenance=true --sbom=true` in `publish-via-docker` for both
Alpine and scratch variants
- Add SBOM section to SECURITY.md with inspection and Trivy scan
instructions
- Update Release-Guide.md
- Add changelog entry
Verified end-to-end: pushed test image to GHCR, confirmed SBOM
attestation via `docker buildx imagetools inspect`, and Trivy scan via
`trivy image --sbom-sources oci` succeeded (with 0 vulnerabilities :-)).
Fixes#10473
### Checklist
The following checks are **mandatory**:
- [X] My change adheres to [VictoriaMetrics contributing
guidelines](https://docs.victoriametrics.com/victoriametrics/contributing/#pull-request-checklist).
- [X] My change adheres to [VictoriaMetrics development
goals](https://docs.victoriametrics.com/victoriametrics/goals/).
---------
Signed-off-by: John Allberg <john@ayoy.se>
Signed-off-by: Max Kotliar <mkotlyar@victoriametrics.com>
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Co-authored-by: Max Kotliar <kotlyar.maksim@gmail.com>
Co-authored-by: Max Kotliar <mkotlyar@victoriametrics.com>
