VictoriaLogs, el sistema de gestión de logs desarrollado por VictoriaMetrics, organiza los registros en un diseño columnar optimizado para velocidad de consulta y eficiencia de almacenamiento. Este artículo explica, sin requerir conocimientos de programación, el recorrido completo de una línea de log desde que llega al sistema hasta que se asienta en disco.
Cuando VictoriaLogs recibe registros a través de protocolos como JSON Lines, Elasticsearch bulk, Loki push, OpenTelemetry o syslog, los traduce a un formato interno compuesto por una marca temporal, un conjunto de campos con nombre y una identidad de flujo (stream identity). Los flujos agrupan los registros que comparten ciertos campos de baja cardinalidad, como host, aplicación, pod o contenedor, lo que permite una alta compresión y consultas que solo acceden a los flujos relevantes.
Los registros se acumulan en un búfer en memoria dividido en fragmentos, uno por núcleo de CPU, y aproximadamente una vez por segundo cada fragmento genera una parte (part) en memoria consultable. Cada parte se asigna a una partición que corresponde a un día natural en UTC, lo que facilita las tareas de retención y las consultas por rango temporal. Las partes en memoria se fusionan en partes pequeñas y, eventualmente, en partes grandes en disco.
El artículo detalla las métricas clave como vl_insert_flush_duration_seconds, vl_storage_parts y vl_pending_rows, así como la métrica -inmemoryDataFlushInterval (5 segundos por defecto), que garantiza la persistencia en disco. También explica la diferencia entre partes pequeñas y grandes según la caché de páginas del sistema operativo, y describe la estructura en disco: una carpeta por día con subcarpetas datadb e indexdb, donde cada parte es un directorio inmutable identificado por un código hexadecimal de 16 caracteres.