VictoriaMetrics/docs/operator/resources

This documentation section describes the design and interaction between the custom resource definitions (CRD) that the Victoria Metrics Operator introduces. Operator introduces the following custom resources:

• VMAgent
• VMAlert
• VMAlertManager
• VMAlertManagerConfig
• VMAuth
• VMCluster
• VMNodeScrape
• VMPodScrape
• VMProbe
• VMRule
• VMServiceScrape
• VMStaticScrape
• VMSingle
• VMUser
• VMScrapeConfig

Here is the scheme of relations between the custom resources:

Specification

You can find the specification for the custom resources on API Docs.

Extra arguments

If you can't find necessary field in the specification of custom resource, you can use extraArgs field for passing additional arguments to the application.

Field extraArgs is supported for the following custom resources:

• VMAgent spec
• VMAlert spec
• VMAlertManager spec
• VMAuth spec
• VMCluster/vmselect spec
• VMCluster/vminsert spec
• VMCluster/vmstorage spec
• VMSingle spec

Supported flags for each application can be found the in the corresponding documentation:

• VMAgent
• VMAlert
• VMAuth
• VMCluster
• VMSingle

Usage example:

apiVersion: operator.victoriametrics.com/v1beta1
kind: VMSingle
metadata:
  name: vmsingle-example-extraargs
spec:
  retentionPeriod: "1"
  extraArgs:
    dedup.minScrapeInterval: 60s
  # ...

Extra environment variables

Flag can be replaced with environment variable, it's useful for retrieving value from secret. You can use extraEnvs field for passing additional arguments to the application.

Usage example:

kind: VMSingle
metadata:
  name: vmsingle-example-extraenvs
spec:
  retentionPeriod: "1"
  extraEnvs:
    - name: DEDUP_MINSCRAPEINTERVAL
      valueFrom:
        secretKeyRef:
          name: vm-secret
          key: dedup

This feature really useful for using with -envflag.enable command-line argument.

Examples

Page for every custom resource contains examples section:

• VMAgent examples
• VMAlert examples
• VMAlertmanager examples
• VMAlertmanagerConfig examples
• VMAuth examples
• VMCluster examples
• VMNodeScrape examples
• VMPodScrape examples
• VMProbe examples
• VMRule examples
• VMServiceScrape examples
• VMStaticScrape examples
• VMSingle examples
• VMUser examples
• VMScrapeConfig examples

In addition, you can find examples of the custom resources for VictoriaMetrics operator in the examples directory of operator repository.

Managing versions of VM

Every custom resource with deployable application has a fields for specifying version (docker image) of component:

• Managing versions for VMAgent
• Managing versions for VMAlert
• Managing versions for VMAlertmanager
• Managing versions for VMAuth
• Managing versions for VMCluster
• Managing versions for VMSingle

Managing resources

Every custom resource with deployable application has a fields and operator parameters for specifying resources for the component:

• Managing resources for VMAgent
• Managing resources for VMAlert
• Managing resources for VMAlertmanager
• Managing resources for VMAuth
• Managing resources for VMCluster
• Managing resources for VMSingle

High availability

VictoriaMetrics operator support high availability for each component of the monitoring stack:

• VMAgent
• VMAlert
• VMAlertmanager
• VMAuth
• VMCluster

In addition, these CRD support common features, that can be used to increase high availability - resources above have the following fields:

• affinity - to schedule pods on different nodes (affinity and anti-affinity in kubernetes docs),
• tolerations - to schedule pods on nodes with taints (taints and tolerations in kubernetes docs),
• nodeSelector - to schedule pods on nodes with specific labels (node selector in kubernetes docs),
• topologySpreadConstraints - to schedule pods on different nodes in the same topology (topology spread constraints in kubernetes docs).

See details about these fields in the Specification.

Enterprise features

Operator supports following Enterprise features for VictoriaMetrics components:

• VMAgent Enterprise features:
  • Reading metrics from kafka
  • Writing metrics to kafka
• VMAlert Enterprise features:
  • Reading rules from object storage
  • Multitenancy
• VMAuth Enterprise features
  • IP Filters
• VMCluster Enterprise features
  • Downsampling
  • Multiple retentions / Retention filters
  • Advanced per-tenant statistic
  • mTLS protection
  • Backup automation
• VMRule Enterprise features
  • Multitenancy
• VMSingle Enterprise features
  • Downsampling
  • Retention filters
  • Backup automation
• VMUser Enterprise features
  • IP Filters

More information about enterprise features you can read on VictoriaMetrics Enterprise page.

Configuration synchronization

Basic concepts

VictoriaMetrics applications, like many other applications with configuration file deployed at Kubernetes, uses ConfigMaps and Secrets for configuration files. Usually, it's out of application scope to watch for configuration on-disk changes. Applications reload their configuration by a signal from a user or some other tool, that knows how to watch for updates. At Kubernetes, the most popular design for this case is a sidecar container, that watches for configuration file changes and sends an HTTP request to the application.

Configmap or Secret that mounted at Pod holds a copy of its content. Kubernetes component kubelet is responsible for content synchronization between an object at Kubernetes API and a file served on disk. It's not efficient to sync its content immediately, and kubelet eventually synchronizes it. There is a configuration option, that controls this period.

That's why, applications managed by operator don't receive changes immediately. It usually takes 1-2 min, before content will be updated.

It may trigger errors when an application was deleted, but VMAgent still tries to scrape it.

Possible mitigations

The naive solution for this case decrease the synchronization period. But it configures globally and may be hard for operator users.

That's why operator uses a few hacks.

For ConfigMap updates, operator changes annotation with a time of Configmap content update. It triggers ConfigMap's content synchronization by kubelet immediately. It's the case for VMAlert, it uses ConfigMap as a configuration source.

For Secret it doesn't work. And operator offers its implementation for side-car container. It can be configured with env variable for operator:

- name: VM_USECUSTOMCONFIGRELOADER
  value: "true"

If it's defined, operator uses own config-reloader instead of prometheus-config-reload.

It watches corresponding Secret for changes with Kubernetes API watch call and writes content into emptyDir. This emptyDir shared with the application. In case of content changes, config-reloader sends HTTP requests to the application. It greatly reduces the time for configuration synchronization.