Monitoreo: Parte 5 — VictoriaMetrics

VictoriaMetrics — una base de datos de series temporales compatible con Prometheus. Se utiliza como almacenamiento a largo plazo para las métricas de Prometheus o completamente en su lugar — junto con el colector vmagent y el módulo de alertas vmalert. La edición principal se distribuye bajo la licencia Apache 2.0; algunas funcionalidades (por ejemplo, reducción de la resolución de datos antiguos y distintos períodos de retención para diferentes conjuntos de datos) están disponibles solo en la edición comercial Enterprise.

Para qué sirve

Prometheus almacena los datos en el disco local de un solo servidor, por defecto 15 días. Cuando hace falta conservar métricas durante años, reunir datos de varios Prometheus en un único sitio o ahorrar disco, aparece un almacenamiento separado. VictoriaMetrics acepta datos por el protocolo remote write, responde a las consultas mediante la misma API HTTP que Prometheus, por lo que Grafana la conecta como una fuente tipo Prometheus sin rehacer los paneles.

Ediciones y modos de funcionamiento

• Single-node — un único ejecutable que acepta, almacena y sirve datos. Adecuado para la mayoría de instalaciones pequeñas y medianas y el más sencillo de operar.
• Clúster — componentes separados vminsert (ingesta), vmstorage (almacenamiento) y vmselect (consultas). Escala horizontalmente y soporta múltiples inquilinos en una sola instalación.

MetricsQL

El lenguaje de consultas de VictoriaMetrics se llama MetricsQL. Es compatible hacia atrás con PromQL: los paneles de Grafana creados para Prometheus funcionan sin cambios. Además, MetricsQL permite:

• no especificar la ventana entre corchetes — rate(node_network_receive_bytes_total) la elegirá automáticamente según el paso de la consulta y el intervalo de sondeo;
• extraer partes repetidas de la consulta en plantillas WITH (...);
• usar funciones adicionales: range_median, range_linear_regression, range_trim_outliers y otras.

Stack sin Prometheus: vmagent, VictoriaMetrics y vmalert

Esquema en el que todos los componentes son parte de VictoriaMetrics:

1. vmagent en el servidor de recolección lee el habitual prometheus.yml (secciones global y scrape_configs), consulta los targets y envía los datos al almacenamiento. Si el almacenamiento no está disponible, guarda los datos en un búfer en disco y los reenvía cuando se restablece la conexión.
2. VictoriaMetrics single-node almacena los datos y responde a las consultas en el puerto 8428.
3. vmalert ejecuta las reglas de alertas y las reglas de grabación en formato Prometheus y envía las alertas disparadas a Alertmanager.
4. Grafana se conecta a VictoriaMetrics como fuente Prometheus.

Ejemplo de ejecución de los componentes en un mismo servidor:

# almacenamiento: datos en /var/lib/victoria-metrics, retener 12 meses
victoria-metrics -storageDataPath=/var/lib/victoria-metrics -retentionPeriod=12

# colector: objetivos desde prometheus.yml, envío al almacenamiento
vmagent -promscrape.config=/etc/vmagent/prometheus.yml \
  -remoteWrite.url=http://localhost:8428/api/v1/write

# alertas: reglas en formato Prometheus, notificaciones vía Alertmanager
vmalert -rule='/etc/vmalert/rules/*.yml' \
  -datasource.url=http://localhost:8428 \
  -notifier.url=http://localhost:9093 \
  -remoteWrite.url=http://localhost:8428 \
  -remoteRead.url=http://localhost:8428

El parámetro -retentionPeriod establece el período de retención; un número sin sufijo significa meses, por defecto se conserva un mes. También se pueden indicar otras unidades, por ejemplo -retentionPeriod=90d. Las banderas -remoteWrite.url y -remoteRead.url en vmalert son necesarias para guardar el estado de las alertas y los resultados de las reglas de grabación; para solo alertas bastan -datasource.url y -notifier.url.

El patrón de ruta en -rule debe ir entre comillas, de lo contrario la shell lo expandirá a una lista de archivos. Las reglas de alertas de Prometheus se trasladan sin cambios: vmalert entiende el mismo formato de archivos.

Si Prometheus ya está funcionando

No es imprescindible migrar todo. En prometheus.yml se añade el envío de una copia de los datos:

remote_write:
  - url: http://192.0.2.30:8428/api/v1/write

Prometheus sigue funcionando como antes, y en VictoriaMetrics se acumula el historial a largo plazo. El período de retención local en Prometheus se puede reducir tras esto.

Ventajas

• Ahorro de disco y memoria. Los desarrolladores y muchos usuarios remarcan que el mismo volumen de métricas ocupa notablemente menos espacio que en Prometheus; la ganancia exacta depende de los datos, conviene comprobarla con tus propias métricas.
• Sencillez de single-node. Un proceso, un directorio de datos, copia de seguridad mediante snapshots (/snapshot/create) y la utilidad vmbackup.
• Compatibilidad. Exportadores, paneles de Grafana y reglas de Prometheus funcionan sin cambios.
• Recepción de datos en varios formatos: remote write de Prometheus, InfluxDB line protocol, Graphite, OpenTSDB.

Desventajas

• Componentes separados. VictoriaMetrics es el almacenamiento; la recolección, las alertas y la visualización son vmagent, vmalert, Alertmanager y Grafana, cada uno con su propia configuración.
• Algunas funciones solo en Enterprise. Antes de diseñar la arquitectura, conviene contrastar las funcionalidades necesarias con la lista de funciones Enterprise en la documentación.
• Pequeñas diferencias con PromQL. La compatibilidad es hacia atrás, pero ciertas funciones se comportan de forma distinta; conviene verificar consultas complejas al migrarlas.

Errores típicos

• No se especifica el período de retención. Por defecto los datos se retienen un mes, y al migrar a un “almacenamiento para historial largo” esto puede ser una desagradable sorpresa.
• Puerto 8428 abierto al exterior. La API del almacenamiento permite leer, escribir y eliminar datos. Se limita el acceso mediante red o proxy inverso con autenticación.
• Búfer de vmagent en un disco pequeño. Si el almacenamiento está inaccesible por mucho tiempo, el búfer ocupa el disco del servidor de recolección; su tamaño se limita con el parámetro -remoteWrite.maxDiskUsagePerURL.
• Alta cardinalidad. Como en Prometheus, los valores únicos en etiquetas aumentan rápidamente el número de series y el consumo de recursos.