Dimensionamiento de Grafana Loki

En resumen

• Almacenamiento de objetos ≈ ingesta diaria × almacenado ÷ recibido × días de retención, una copia, y luego el crecimiento. Grafana no publica una tasa de compresión, así que ObservKit usa una suposición de planificación conservadora de 1,0× (editable). Grafana no recomienda ese valor: mide tu propia relación para dimensionar en producción.
• El factor de replicación (3 por defecto) multiplica lo que reciben los ingesters, no lo que llega al bucket.
• El WAL es disco local en los ingesters. Escala con la tasa de ingesta, no con la retención.
• El cómputo proviene de los perfiles de referencia publicados por Grafana para cada tier de ingesta. No se deriva de tu volumen de datos.
• Escenario de referencia 250 GB/día durante 90 días con 25% de margen de crecimiento son 28,1 TB de almacenamiento de objetos con la suposición de planificación conservadora de 1,0×.

Dónde viven los datos

Los distributors reciben los logs y escriben cada stream en factor de replicación ingesters. Los ingesters guardan los datos recientes en memoria, los registran en un write-ahead log en disco local y vuelcan los chunks y el índice al almacenamiento de objetos. Los queriers leen los datos recientes desde los ingesters y todo lo demás desde el bucket, a través de cachés y del index gateway. Eso da tres tipos de capacidad que nunca deben sumarse: almacenamiento de objetos (TB), discos de los ingesters (GB) y cómputo (CPU y memoria).

Almacenamiento de objetos

Los chunks están comprimidos, pero la documentación de Loki no da una tasa, porque depende de cuán repetitivas sean tus líneas y de la cardinalidad de las labels. Mídela: divide loki_ingester_chunk_stored_bytes_total entre loki_distributor_bytes_received_total durante un período representativo y reemplaza el factor predeterminado por el resultado. El almacenamiento de objetos escala de forma lineal con el factor, de modo que cualquier relación medida reemplaza directamente la suposición de 1,0×.

Escenario de referencia Los mismos 250 GB/día durante 90 días con un factor hipotético de almacenado ÷ recibido de 0,25 dan 7,03 TB, frente a 28,1 TB con 1,0. Abre este escenario

WAL del ingester

Grafana publica un único dato sobre el WAL: un ingester con unas 5.000 series que recibe cerca de 5 MB/s, con el uso de disco solo del WAL estabilizándose alrededor de 10–15 GB. ObservKit escala ese único punto de forma lineal con la ingesta total de los ingesters (ingesta diaria × factor de replicación) y muestra el resultado como un WAL estimado para todo el clúster. Es una estimación de planificación aproximada y de baja confianza, no un tamaño de disco requerido: la cantidad de series, el intervalo de checkpoint y el comportamiento de flush lo modifican. Los ingesters dejan de aceptar escrituras cuando el sistema de archivos del WAL supera 90% de uso (el umbral de disco lleno por defecto), por lo que la calculadora también muestra qué necesitaría un reparto uniforme por ingester para mantener la estimación alta bajo ese umbral.

Escenario de referencia Con 250 GB/día, RF 3 y 6 ingesters, el WAL suma 17,4–26 GB en total, unos 4,82 GB de volumen por ingester. Con 3 ingesters, el volumen por ingester sube a 9,65 GB. Abre este escenario

Factor de replicación

Con el factor predeterminado de 3, el distributor escribe cada stream en tres ingesters, y una escritura se confirma cuando un quórum la reconoce. Al volcar un chunk se calcula un hash a partir del tenant, las labels y el contenido, por lo que las réplicas idénticas no generan objetos duplicados. Por lo tanto, el almacenamiento no se triplica. Lo que se triplica es la ingesta de los ingesters, la memoria y el tráfico del WAL. Ingresar RF × almacenamiento de objetos es el error de dimensionamiento más común.

Escenario de referencia Con RF 1 el almacenamiento de objetos se mantiene en 28,1 TB; solo cambia el WAL (8,68 GB en la estimación alta frente a 26 GB con RF 3). Abre este escenario

Retención

La retención viene desactivada por defecto: los logs se conservan de forma indefinida hasta que habilitas la retención del compactor (compactor.retention_enabled) y defines limits_config.retention_period o reglas por stream. Los cambios no son retroactivos. El borrado se retrasa (retention_delete_delay, 2 horas por defecto) y la retención mínima por stream es de 24 horas. Las reglas de ciclo de vida del object store son solo una red de seguridad: Grafana aconseja que su expiración sea mayor que la retención de Loki más el retraso de borrado, y que nunca expiren el índice ni el estado del compactor.

Escenario de referencia Con 7 días en lugar de 90, la misma ingesta necesita 2,19 TB de almacenamiento de objetos. Abre este escenario

Dimensionamiento del despliegue

Grafana publica requests de CPU y memoria de referencia por componente para tres tiers de ingesta (menos de 3 TB/día, 3–30 TB/día y cerca de 30 TB/día) y los presenta como una guía aproximada. ObservKit muestra el perfil del tier que corresponde a tu ingesta diaria, rotulado como perfil de referencia de Grafana; no lo escala ni lo calcula, porque los perfiles publicados no son una fórmula. Las cargas de consulta pueden requerir mucho más (Grafana advierte que las consultas sin optimizar pueden necesitar hasta 10× los recursos sugeridos), y el dimensionamiento de la caché, la cardinalidad de las labels y el comportamiento de la retención también mueven los requisitos reales. Usa el perfil para iniciar una prueba de carga, no para hacer un pedido.

Escenario de referencia Con 250 GB/día, el perfil de referencia de Grafana correspondiente para Loki distribuido <3 TB/día indica 38 CPU y 59 Gi de requests de memoria en total.

Ejemplo resuelto

Escenario de referencia De EPS a Loki: 8.000 eventos/s con unos 700 bytes son 483,84 GB/día (8.000 × 700 × 86.400). Con 30 días de retención y 25% de crecimiento con el factor conservador de 1,0×, Loki necesita 18,1 TB de almacenamiento de objetos. Abre este escenario

Errores comunes

• Multiplicar el almacenamiento de objetos por el factor de replicación.
• Usar el factor predeterminado de almacenado ÷ recibido de 1,0 como si fuera una medición.
• Sumar volúmenes de WAL, almacenamiento de objetos y cómputo en un único total.
• Tratar el perfil de referencia de Grafana como una fórmula de dimensionamiento para tu carga.
• Depender de las reglas de ciclo de vida del object store en lugar de la retención de Loki, o al revés.

Limitaciones

La calculadora no modela los costos de solicitudes al object store, la carga de consultas, el dimensionamiento de la caché, la cardinalidad de labels, los límites por tenant, los límites del ruler o de ingesta, ni los valores por defecto del operator de Loki. La estimación del WAL se escala a partir de una única prueba documentada. La retención se muestra en días; no se simula el momento real de borrado del compactor.

Fuentes

• Dimensiona el clúster de Loki — documentación de Grafana Loki: requests de CPU y memoria de referencia por tier de ingesta.
• Write Ahead Log — documentación de Grafana Loki: comportamiento del WAL y el dato documentado de 10–15 GB.
• Componentes de Loki — documentación de Grafana Loki: replicación en el distributor, ingester, quórum y flush de chunks.
• Retención de logs — documentación de Grafana Loki: retención del compactor y recomendaciones sobre políticas de ciclo de vida.
• Observabilidad (v2.9.x) — documentación de Grafana Loki: nombres de métricas para medir la relación almacenado ÷ recibido.

Última revisión: octubre de 2026 · Calculadora de dimensionamiento de Grafana Loki · Planificación de capacidad · Metodología