Calculadora de dimensionamiento de Grafana Loki

Almacenamiento de objetos, disco del WAL de los ingesters y una referencia de cómputo publicada para Loki: capacidad de datos y cómputo se muestran por separado, con cada supuesto respaldado por una fuente.

● Calculado localmente en tu navegador

Datos de entrada de capacidad

Ingesta diaria bytes recibidos por día

Retención días

Margen de crecimiento 25%

Capacidad de datos

Almacenamiento de objetos a planificar · chunks + índice, una copia · estimación de planificación

—

Recibido durante la retención —

Almacenado (× factor, antes del crecimiento) —

Margen de crecimiento —

WAL estimado para todo el clúster · estimación de planificación aproximada y de baja confianza—Incluye el factor de replicación (ingesta de los ingesters = ingesta diaria × factor de replicación), repartida entre todos los ingesters. Se deriva del único punto que publica Grafana (un ingester, ~5 MB/s, ~5.000 series, ~10–15 GB de WAL) y se escala de forma lineal: no es un tamaño de disco requerido. Repartido por igual, unos — por ingester mantendrían la estimación alta bajo el umbral de disco lleno de 90%. Disco local, independiente del almacenamiento de objetos.

Ver el cálculo

La replicación no se aplica al almacenamiento de objetos: el distributor escribe cada stream en replication_factor ingesters, pero los chunks idénticos generan el mismo hash y el mismo objeto, por lo que el object store contiene una sola copia. El object store aporta su propia durabilidad.

Perfil de referencia de Grafana No calculado para tu ingesta

—

Requests de CPU, todos los componentes—

Requests de memoria, todos los componentes—

Componentes de este perfil

Perfil de referencia de Grafana (modo microservicios, utilización p90)
Componente	Request de CPU	Request de memoria	Réplicas

Grafana presenta este perfil como una guía aproximada para el tier de ingesta. No se calcula a partir de tu volumen, y las cargas de consulta pueden requerir mucho más: Grafana advierte que las consultas sin optimizar pueden necesitar hasta 10× los recursos sugeridos.

Supuestos y fuentes

Cada supuesto, de dónde sale y cuál es su límite
Supuesto	Fuente	Limitación	Confianza
La ingesta diaria son los bytes sin comprimir que reciben los distributors.	Métricas de observabilidad de Loki (v2.9): `loki_distributor_bytes_received_total`.	Mide durante una semana completa; cuenta por tenant.	Alta
Factor almacenado ÷ recibido: suposición de planificación conservadora de 1,0× (editable); Grafana no recomienda este valor.	Almacenamiento: los chunks se comprimen en el almacenamiento de objetos; no se publica ninguna proporción. Referencia de configuración: `chunk_encoding` es gzip por defecto.	La proporción real depende del contenido de los logs y de la codificación. Mide `loki_ingester_chunk_stored_bytes_total` ÷ bytes recibidos (nombres de métricas de la v2.9).	Baja
El almacenamiento de objetos conserva una copia de cada chunk.	Componentes: los chunks idénticos generan el mismo hash y el mismo objeto, así que las réplicas no escriben duplicados.	El flush desde el WAL tras un reinicio puede reducir la deduplicación (WAL). La redundancia propia del object store es la del proveedor.	Mediano
Factor de replicación 3.	Componentes: generalmente 3; referencia de configuración: 3 por defecto.	Determina la ingesta de los ingesters y el quórum de escritura, no el tamaño almacenado.	Alta
WAL estimado para todo el clúster ≈ 2.000–3.000 segundos de ingesta de los ingesters (ingesta × factor de replicación).	WAL: una prueba, un ingester con 5.000 series que ingiere ~5 MB/s y un checkpoint de 5 minutos, mantuvo ~10–15 GB de disco de WAL.	Un único dato escalado de forma lineal. La cantidad de series, el intervalo de checkpoint y el comportamiento de flush lo modifican. Estimación de planificación aproximada y de baja confianza, no un tamaño de disco requerido.	Baja
Volumen del WAL mantenido por debajo de 90%.	WAL: por defecto, el ingester rechaza escrituras cuando el sistema de archivos que contiene el WAL llega a 90%.	El umbral mide todo el sistema de archivos, así que dale al WAL su propio volumen.	Alta
El cómputo es el perfil de referencia de Grafana para el tier de ingesta (una guía aproximada).	Dimensiona el clúster de Loki: CPU, memoria y réplicas por componente, utilización p90, modo microservicios.	No se escala a tu ingesta; no se cubren otros modos de despliegue; las consultas pueden necesitar hasta 10× los recursos de los queriers.	Mediano
La retención la aplica el compactor y viene desactivada por defecto.	Retención y referencia de configuración: `retention_enabled` en false, `retention_period` en 0s.	Las reglas de ciclo de vida del object store deben ser más largas que el período de retención.	Alta
Margen de crecimiento de 25% sobre el almacenamiento de objetos.	Suposición de planificación de ObservKit.	Ajústalo a tu propia proyección de crecimiento.	n/a

No se modela: el tamaño del índice por separado de los chunks, la memoria de caché (memcached), el directorio de trabajo del compactor, la carga de consultas, los límites por tenant ni otros modos de despliegue.

Solo estimaciones de planificación. La capacidad real de Loki depende del contenido de los logs, la cardinalidad de labels, la carga de consultas, la configuración de caché y el modo de despliegue.

Ejemplo resuelto: 250 GB/día durante 90 días

Escenario de referencia los valores predeterminados de la calculadora: 250 GB/día recibidos, 90 días de retención, almacenado ÷ recibido 1,0, factor de replicación de los ingesters 3, 6 ingesters y 25% de crecimiento. Abre este escenario.

De la ingesta diaria al almacenamiento de objetos, el WAL y la referencia de cómputo
Paso	Fórmula	Resultado
Recibido durante la retención	`250 GB/day × 90 days`	22,5 TB
Almacenado (chunks + índice)	`× stored ÷ received 1.0`	22,5 TB
Margen de crecimiento	`× 25%`	5,63 TB
Almacenamiento de objetos a planificar	`almacenado + crecimiento`, una copia	28,1 TB
Tasa de ingesta	`250 GB/day ÷ 86,400 s`	2,9 MB/s
Ingesta de los ingesters	`rate × replication factor 3`	8,7 MB/s
WAL, todos los ingesters	`ingesta × 2.000–3.000 s` (escalado a partir de la prueba de Grafana)	17,4 GB–26 GB
Volumen de WAL por ingester	`high WAL ÷ 6 ingesters ÷ 0.9`	4,82 GB
Tier de referencia de cómputo	Perfil de Grafana para el tier de esta ingesta	Menos de 100 TB/mes (3 TB/día): 38 CPU en requests, 59 Gi de memoria en requests

La capacidad de datos y el cómputo son cantidades distintas y nunca se suman: terabytes de almacenamiento de objetos, gigabytes de disco de WAL, y requests de CPU y memoria de un perfil publicado.

Escenarios de referencia

Escenario de referencia puntos de comparación, no tamaños recomendados. Almacenado ÷ recibido 1,0, factor de replicación 3, 6 ingesters, 25% de crecimiento.

Capacidad de Loki según el volumen
Escenario	Datos de entrada	Almacenamiento de objetos	WAL, todos los ingesters	Tier de referencia de cómputo	Enlace
Pequeño	50 GB/día · 30 días	1,88 TB	3,47 GB–5,21 GB	Menos de 100 TB/mes (3 TB/día)	Abrir este escenario
Mediano	250 GB/día · 90 días	28,1 TB	17,4 GB–26 GB	Menos de 100 TB/mes (3 TB/día)	Abrir este escenario
Grande	3 TB/día · 90 días	337,5 TB	208,3 GB–312,5 GB	De 100 TB a 1 PB/mes (3–30 TB/día)	Abrir este escenario

El almacenamiento de objetos crece de forma lineal con el volumen y la retención; el WAL solo sigue la tasa de ingesta. Con 3 TB/día la referencia de cómputo pasa al perfil de 3–30 TB/día de Grafana (431 CPU en requests, 857 Gi de memoria en requests), que es un tier publicado, no una cifra escalada.

Errores comunes

Multiplicar el almacenamiento de objetos por el factor de replicación. Un factor de replicación de 3 escribe cada stream en tres ingesters, pero los chunks se almacenan una sola vez. Aplicarlo al escenario de 250 GB/día da 84,4 TB en lugar de 28,1 TB.
Asumir una tasa de compresión que no has medido. El factor predeterminado de 1,0× es una suposición de planificación conservadora, no una medición. Ejemplo hipotético si una semana de mediciones diera un almacenado ÷ recibido de 0,25, el escenario de 250 GB/día necesitaría 7,03 TB. Abre este escenario.
Dimensionar el WAL a partir de la retención. El WAL contiene datos recientes y aún no volcados, no datos retenidos: cerca de 26 GB como máximo para el escenario de 250 GB/día, no una fracción de 28,1 TB. Siete días de retención cambian el almacenamiento de objetos a 2,19 TB y dejan el WAL en 26 GB.
Aprovisionar el volumen del WAL con su tamaño esperado. El ingester rechaza escrituras cuando el sistema de archivos llega a 90%. Dividir por 0,9 lleva el volumen por ingester de 4,34 GB a 4,82 GB, y el volumen debe contener solo el WAL porque el umbral cuenta todo el sistema de archivos.
Escalar la referencia de cómputo con tu ingesta. El perfil de Grafana se publica por tier de ingesta. Por debajo de 3 TB/día el perfil de arriba no es proporcional: 38 CPU en requests es el perfil del tier, no una función de 50 GB/día. Úsalo como techo de comparación y luego mide.
Asumir que la retención ocurre sola. La retención se ejecuta en el compactor y viene desactivada por defecto (retention_enabled en false, retention_period en 0s), así que los logs viven para siempre hasta que la habilitas. El almacenamiento de objetos crece entonces sin un límite que esta calculadora no puede mostrar.
Menos ingesters que el factor de replicación. Cada stream se escribe en esa cantidad de ingesters, así que 3 ingesters con factor de replicación 3 es el mínimo que acepta la calculadora: 9,65 GB de volumen de WAL por ingester en lugar de 4,82 GB con seis.

Cómo se calcula el dimensionamiento de Loki

recibido        = ingesta diaria × días de retención
almacenamiento de objetos = ingesta diaria × almacenado÷recibido × retención × (1 + crecimiento)     una copia
tasa de ingesta = ingesta diaria ÷ 86.400 s
WAL (total)     = tasa de ingesta × factor de replicación × 2.000–3.000 s
volumen de WAL  = WAL (alto) ÷ ingesters ÷ 0,9
cómputo         = perfil de referencia de Grafana para el tier de ingesta (no se calcula)

Todos los volúmenes usan unidades decimales (1.000 GB = 1 TB).
Las constantes de 2.000–3.000 s son 10–15 GB ÷ 5 MB/s del único dato de WAL de Grafana.
Tiers de cómputo: menos de 3 TB/día, 3–30 TB/día y 30 TB/día o más (cerca de 1 PB/mes). Los límites son la interpretación de ObservKit de los tiers publicados.
No se modela: el tamaño del índice aparte de los chunks, el dimensionamiento de memcached, el directorio de trabajo del compactor, la carga de consultas ni otros modos de despliegue.

El modelo de capacidad común detrás de cada calculadora está en la metodología.

Fuentes

Dimensiona el clúster de Loki — documentación de Grafana Loki (latest). CPU, memoria y réplicas de referencia por componente y por tier de ingesta.
Componentes de Loki — documentación de Grafana Loki (latest). WAL del ingester, replicación y quórum del distributor, chunks e índice en el almacenamiento de objetos, compactor.
Almacenamiento — documentación de Grafana Loki (latest). Chunks e índice TSDB en object stores, retención a través del compactor.
Write ahead log — documentación de Grafana Loki (latest). La prueba de ~5 MB/s, el umbral de disco lleno de 90% y el comportamiento de replay.
Referencia de configuración — documentación de Grafana Loki (latest). Valores por defecto de replication_factor, chunk_encoding, retention_enabled y retention_period.
Retención de logs — documentación de Grafana Loki (latest). Retención del compactor y advertencia sobre las reglas de ciclo de vida.
Métricas de observabilidad — documentación de Grafana Loki, v2.9. Nombres de métricas para medir el factor almacenado ÷ recibido.

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