El artículo recorre el ciclo vital completo de una métrica de telemetría dentro del ecosistema VictoriaMetrics, siguiendo un único contador —http_requests_total— desde que se incrementa en la memoria del proceso hasta que termina almacenado en disco. La explicación está pensada para lectores sin experiencia en programación y se apoya en la versión 1.147.0 del proyecto, simplificando a propósito los detalles internos.
El recorrido comienza en la aplicación: cuando el código incrementa el contador, no se produce ninguna comunicación con la red ni escritura en disco; la biblioteca de métricas simplemente actualiza una tabla interna que asocia cada combinación de etiquetas con su valor acumulado. Periódicamente —cada 15 a 60 segundos— el proceso expone su página /metrics en formato Prometheus o envía un snapshot a un colector. En ese instante la métrica abandona el proceso, normalmente como texto plano, y viaja hacia el backend, que puede recibirla mediante varios protocolos como Prometheus remote write, OpenTelemetry, InfluxDB o Graphite.
Antes de llegar al almacenamiento, los datos pueden pasar por un intermediario como vmagent, que los guarda en una cola persistente en disco para evitar pérdidas cuando el servidor está caído. Una vez en VictoriaMetrics, la petición se descomprime, se decodifica y se aplana a registros internos con la forma (etiquetas, timestamp, valor), donde el nombre de la métrica pasa a ser una etiqueta más (name). Después, las etiquetas se empaquetan en un blob binario compacto (MetricNameRaw) que sirve como clave de búsqueda, mientras que la identidad real de la serie —las etiquetas ya ordenadas— solo se construye cuando el sistema la necesita. El texto cierra con una invitación a profundizar revisando el código fuente del proyecto.