Enterprise

VictoriaMetrics, VictoriaLogs and VictoriaTraces components are provided in two kinds - Community edition and Enterprise edition .

The community components are open source and are free to use:

See VictoriaMetrics source code and VictoriaMetrics license .
See VictoriaLogs source code and VictoriaLogs license .
See VictoriaTraces source code and VictoriaTraces license .

Both open-source and enterprise components are available at the following places:

Binary executables are available at the corresponding releases pages:
Docker images are available at Docker Hub and Quay .

Enterprise executables and Docker images have enterprise suffix in their names and tags.

Valid cases for VictoriaMetrics Enterprise #

The use of Enterprise components is permitted in the following cases:

Evaluation use in non-production setups. Pass the -eula command-line flag Available from v1.156.0 to accept the ESA as described in these docs .
Production use if you have a valid enterprise contract or valid permit from VictoriaMetrics company. Please contact us via this page if you are interested in such a contract.
VictoriaMetrics Cloud is built on top of VictoriaMetrics Enterprise.

See these docs for details on how to run Enterprise components of VictoriaMetrics and VictoriaLogs.

VictoriaMetrics Enterprise features #

VictoriaMetrics Enterprise includes all the features of the community edition , plus the following additional features:

Stable releases with long-term support, which contains important bugfixes and security fixes. See these docs .
First-class consulting and technical support provided by the core VictoriaMetrics dev team.
Monitoring of monitoring - this feature allows forecasting and preventing possible issues in VictoriaMetrics setups.
Enterprise security compliance .
Prioritizing of feature requests from Enterprise customers.

On top of this, Enterprise package of VictoriaMetrics includes the following features:

Downsampling - this feature allows reducing storage costs and increasing performance for queries over historical data.
Multiple retentions - this feature allows reducing storage costs by specifying different retentions for different datasets.
Automatic discovery of vmstorage nodes - this feature allows updating the list of vmstorage nodes at vminsert and vmselect without the need to restart these services.
Anomaly Detection Service - this feature allows automation and simplification of your alerting rules, covering complex anomalies found in metrics data.
Backup automation .
Advanced per-tenant stats .
Query execution stats .
Advanced auth and rate limiter .
Automatic issuing of TLS certificates .
mTLS for all the VictoriaMetrics components .
mTLS for communications between cluster components .
mTLS-based request routing .
Kafka integration .
Google PubSub integration .
Multitenant support in vmalert .
Ability to read alerting and recording rules from Object Storage .
Ability to filter incoming requests by IP at vmauth .
FIPS 140-3 compatible builds .

VictoriaLogs Enterprise features #

VictoriaLogs enterprise includes all the features of the community edition , plus the following additional features:

Stable releases with long-term support, which contains important bugfixes and security fixes. See these docs .
First-class consulting and technical support provided by the core VictoriaMetrics dev team.
Monitoring of monitoring - this feature allows forecasting and preventing possible issues in VictoriaLogs setups.
Enterprise security compliance .
Prioritizing of feature requests from Enterprise customers.

On top of this, Enterprise package of VictoriaLogs includes the following features:

Running VictoriaMetrics Enterprise #

All the Enterprise components require specifying the -eula command-line flag Available from v1.156.0 to accept the ESA .

LTS lines support -eula flag starting from releases v1.136.23 and v1.148.9. If you need another Enterprise version, please contact the Sales team .

Before these releases, Enterprise components required the -license or -licenseFile command-line flag. These flags are now deprecated and are treated as -eula, so existing setups keep working after the upgrade. See how to run releases before v1.156.0 .

Enterprise components are available in the following forms:

Binary releases #

It is allowed to run Enterprise components in cases listed here .

Binary releases of Enterprise components are available at the releases page for VictoriaMetrics , the releases page for VictoriaLogs and the releases page for VictoriaTraces . Enterprise binaries and packages have enterprise suffix in their names. For example, victoria-metrics-linux-amd64-v1.156.0-enterprise.tar.gz.

In order to run binary release of Enterprise component, please download the *-enterprise.tar.gz archive for your OS and architecture from the corresponding releases page and unpack it. Then run the unpacked binary.

For example, the following command runs VictoriaMetrics Enterprise binary:

      wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.156.0/victoria-metrics-linux-amd64-v1.156.0-enterprise.tar.gz
tar -xzf victoria-metrics-linux-amd64-v1.156.0-enterprise.tar.gz
./victoria-metrics-prod -eula
    

Docker images #

It is allowed to run Enterprise components in cases listed here .

Docker images for Enterprise components are available at VictoriaMetrics Docker Hub and VictoriaMetrics Quay . Enterprise docker images have enterprise suffix in their names. For example, victoriametrics/victoria-metrics:v1.156.0-enterprise.

In order to run Docker image of VictoriaMetrics Enterprise component, pass the -eula command-line flag Available from v1.156.0 to accept the ESA .

For example, the following command runs VictoriaMetrics Enterprise Docker image:

      docker run --name=victoria-metrics victoriametrics/victoria-metrics:v1.156.0-enterprise -eula

Example docker-compose configuration:

      version: "3.5"
services:
  victoriametrics:
    container_name: victoriametrics
    image: victoriametrics/victoria-metrics:v1.156.0-enterprise
    ports:
      - 8428:8428
    volumes:
      - vmdata:/storage
    command:
      - "-storageDataPath=/storage"
      - "-eula"
volumes:
  vmdata: {}
    

Helm charts #

It is allowed to run Enterprise components in cases listed here .

Helm charts for Enterprise components are available in our VictoriaMetrics Helm repository .

In order to run Enterprise helm chart it is required to accept the ESA and adjust the image tag to the Enterprise one as described in the docker-images section.

For example, the following values file for VictoriaMetrics single-node chart is used to pass -eula command-line flag Available from v1.156.0 to accept the ESA :

      server:
  image:
    tag: v1.156.0-enterprise
  extraArgs:
    eula: "true"
    

Kubernetes operator #

It is allowed to run Enterprise components in cases listed here .

Enterprise components can be deployed via VictoriaMetrics operator . In order to use Enterprise components it is required to accept the ESA and adjust the image tag to the enterprise one.

For example, the following custom resource for VictoriaMetrics single-node is used to pass -eula command-line flag Available from v1.156.0 to accept the ESA :

      apiVersion: operator.victoriametrics.com/v1beta1
kind: VMSingle
metadata:
  name: example-vmsingle
spec:
  retentionPeriod: "1"
  image:
    tag: v1.156.0-enterprise
  extraArgs:
    eula: "true"
    

See the full list of the CRD specifications in the Operator API .

FIPS Compatibility #

VictoriaMetrics Enterprise supports FIPS 140-3 compliant mode starting with version Available from v1.118.0 , using the Go FIPS 140-3 Cryptographic Module . This ensures all cryptographic operations use a validated FIPS module.

Builds are available for amd64 and arm64 architectures.

Example archive:

victoria-metrics-linux-amd64-v1.156.0-enterprise.tar.gz

Includes:

victoria-metrics-prod (standard)
victoria-metrics-fips (FIPS-compatible)

Example Docker image:

victoriametrics/victoria-metrics:v1.156.0-enterprise-fips – uses the FIPS-compatible binary and based on scratch image.

Section below contains backward-compatible anchors for links that were moved or renamed.

Running releases before v1.156.0 #

This section applies only to Enterprise releases before v1.156.0, and LTS releases before v1.136.23 and v1.148.9. Consider upgrading to a newer version, which uses the -eula flag instead of the license key.

Releases older than v1.156.0 (or older than v1.136.23 and v1.148.9 for the LTS lines) require one of the following license flags instead of -eula:

-license - this flag accepts VictoriaMetrics Enterprise license key, which can be obtained at this page .
-licenseFile - this flag accepts a path to file with VictoriaMetrics Enterprise license key, which can be obtained at this page . Use either -license or -licenseFile, but not both.
-licenseFile.reloadInterval - specifies the interval for checking the license file for updates. The default value is 1 hour. If the license file is updated, the new license key is read from the file.
-license.forceOffline - enables offline verification of VictoriaMetrics Enterprise license key. Contact us via this page if you need a license key, which can be verified offline without the need to connect to VictoriaMetrics license server.

For example, the following command runs VictoriaMetrics Enterprise binary with the Enterprise license obtained at this page :

      wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.155.0/victoria-metrics-linux-amd64-v1.155.0-enterprise.tar.gz
tar -xzf victoria-metrics-linux-amd64-v1.155.0-enterprise.tar.gz
./victoria-metrics-prod -license=BASE64_ENCODED_LICENSE_KEY
    

Alternatively, VictoriaMetrics Enterprise license can be stored in the file and then referred via -licenseFile command-line flag:

      ./victoria-metrics-prod -licenseFile=/path/to/vm-license

Example docker-compose configuration with the license file:

      version: "3.5"
services:
  victoriametrics:
    container_name: victoriametrics
    image: victoriametrics/victoria-metrics:v1.155.0-enterprise
    ports:
      - 8428:8428
    volumes:
      - vmdata:/storage
      - /vm-license:/vm-license
    command:
      - "-storageDataPath=/storage"
      - "-licenseFile=/vm-license"
volumes:
  vmdata: {}
    

When using VictoriaMetrics operator , the license key can be provided via spec.license. For example, the following custom resource for VictoriaMetrics single-node provides the license key in plain-text:

      apiVersion: operator.victoriametrics.com/v1beta1
kind: VMSingle
metadata:
  name: example-vmsingle
spec:
  retentionPeriod: "1"
  license:
    key: {BASE64_ENCODED_LICENSE_KEY}
  image:
    tag: v1.155.0-enterprise
    

In order to provide the license key via an existing secret, the following custom resource is used:

      apiVersion: operator.victoriametrics.com/v1beta1
kind: VMSingle
metadata:
  name: example-vmsingle
spec:
  retentionPeriod: "1"
  license:
    keyRef:
      name: vm-license
      key: license
  image:
    tag: v1.155.0-enterprise
    

Example secret with license key:

      apiVersion: v1
kind: Secret
metadata:
  name: vm-license
type: Opaque
data:
  license: {BASE64_ENCODED_LICENSE_KEY}
    

Or create secret via kubectl:

      kubectl create secret generic vm-license --from-literal=license={BASE64_ENCODED_LICENSE_KEY}
    

Note that the license key provided by using a secret is mounted as a file. This allows updates to the license without the need to restart the pod.

Updating the license key #

License key is only required to run VictoriaMetrics Enterprise releases before v1.156.0, v1.136.23 and v1.148.9. Please see how to run VictoriaMetrics Enterprise . Consider upgrading to a newer version, which doesn’t check license expiration.

Updating the license key for Enterprise components depends on the way the license key is provided to the component:

If the license key is provided via -license command-line flag, then the component should be restarted with the new license key.
If the license key is provided via -licenseFile command-line flag, then the license file should be updated with the new license key. The component will automatically reload the license file at the interval specified via -licenseFile.reloadInterval command-line flag (1 hour by default) and apply the new license key without the need to restart the component.
If the license key is provided via Kubernetes secret, then the secret should be updated with the new license key. The component will automatically reload the license file at the interval specified via -licenseFile.reloadInterval command-line flag (1 hour by default) and apply the new license key without the need to restart the component.
If the license key is provided via Helm chart value, then the corresponding values.yaml file should be updated with the new license key and then the Helm chart should be upgraded via helm upgrade command. This will restart the component with the new license key.
If the license key is provided via Kubernetes operator custom resource, then the corresponding custom resource should be updated with the new license key. This will restart the component with the new license key.

What Happens to Licensed Components When a License Expires #

When a license expires, all licensed components continue to function normally until a restart occurs.

License expiration is checked only at startup. If a license expires while the component is running, nothing changes; the component continues to run until the next restart.

This means you don’t need to restart components to install a new license, as long as the new license is installed before the next restart. A license provided via -licenseFile or a Kubernetes secret is reloaded automatically. The exception is when the -license flag is used, because the license is supplied at startup and changing it requires restarting VictoriaMetrics with the updated flag value.

If your license has expired and you decide to not renew it, you can switch to the VictoriaMetrics Open Source version without data loss, as both versions share the same data model. In doing so, however, you will lose access to the VictoriaMetrics Enterprise features .

See updating the license key for more details.

Monitoring license expiration #

License metrics are exposed only by VictoriaMetrics Enterprise releases before v1.156.0, v1.136.23 and v1.148.9. Please see how to run VictoriaMetrics Enterprise . Consider upgrading to a newer version, which doesn’t check license expiration.

All the Enterprise components expose the following metrics at the /metrics page:

vm_license_expires_at - license expiration date in unix timestamp format
vm_license_expires_in_seconds - the number of seconds left until the license expires

Example alerts for vmalert based on these metrics:

      groups:
  - name: vm-license
    # note the `job` label and update accordingly to your setup
    rules:
      - alert: LicenseExpiresInLessThan30Days
        expr: vm_license_expires_in_seconds < 30 * 24 * 3600
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.job }} instance {{ $labels.instance }} license expires in less than 30 days"
          description: "{{ $labels.instance }} of job {{ $labels.job }} license expires in {{ $value | humanizeDuration }}.
            Please make sure to update the license before it expires."

      - alert: LicenseExpiresInLessThan7Days
        expr: vm_license_expires_in_seconds < 7 * 24 * 3600
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.job }} instance {{ $labels.instance }} license expires in less than 7 days"
          description: "{{ $labels.instance }} of job {{ $labels.job }} license expires in {{ $value | humanizeDuration }}.
            Please make sure to update the license before it expires."
    

Previous Streaming aggregation Next Cluster Per Tenant Statistic