Calculadora de almacenamiento de logs

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

Ejemplo ilustrativo Una estimación independiente de la plataforma: 500 GB/día, 90 días, replicación 2, 25% de crecimiento, sin asumir compresión. Abre este escenario.

La fórmula es diario × retención × replicación × (1 + crecimiento). Como no se aplica compresión, es un límite superior para las plataformas que comprimen (la referencia documentada de Splunk conserva cerca de la mitad del volumen sin procesar por copia) y una estimación razonable para los sistemas que almacenan los datos cerca de su tamaño original.

Escenarios de referencia

Escenario de referencia Tres tamaños para comparar, no recomendaciones.

La retención y la replicación se multiplican entre sí: el entorno grande ingesta 100 veces más por día que el pequeño, pero necesita 900 TB y no 750 GB, porque conserva seis veces más tiempo y almacena dos copias.

De eventos por segundo a GB/día

Si solo conoces la tasa de eventos, conviértela a volumen diario con el tamaño promedio del evento sin procesar:

bytes/día = eventos/s × bytes promedio por evento × 86.400
GB/día    = bytes/día ÷ 1.000.000.000

Ejemplo ilustrativo 5.000 eventos/s × 600 bytes × 86.400 s = 259.200.000.000 bytes = 259,2 GB/día. Con 30 días de retención, replicación 2 y 25% de crecimiento, son 19,4 TB. Abre este escenario.

• Usa la tasa promedio de un día completo, no el pico. Ejemplo hipotético Si la misma fuente alcanza picos de 12.000 eventos/s durante una hora, 12.000 × 600 × 86.400 da 622,1 GB/día: 2,4 veces el volumen real. Dimensiona el throughput para los picos; dimensiona el almacenamiento para los totales diarios.
• Mide el tamaño del evento en su formato original, antes del parseo o del enriquecimiento. Un JSON con muchos campos y los stack traces de varias líneas pueden ser varias veces más grandes que una línea de syslog.
• Incluye un ciclo semanal. El volumen de los días laborales y el del fin de semana suelen diferir; mide al menos siete días.

Mide tu factor de almacenamiento real

La calculadora genérica asume que los bytes almacenados son iguales a los bytes sin procesar. El factor real de tu plataforma es:

factor de almacenamiento = bytes almacenados de una copia ÷ bytes sin procesar ingeridos de los mismos datos

1. Elige una ventana de al menos siete días para incluir los patrones semanales.
2. Toma el volumen sin procesar de la contabilidad de ingesta de la propia plataforma o de los contadores de bytes del shipper en esa ventana.
3. Toma el tamaño en disco de una copia de esos mismos datos cuando ya no se estén escribiendo, una vez asentados los merges en segundo plano.
4. Divide y aplica las réplicas por separado.

El factor varía mucho. En Splunk es la proporción de rawdata más archivos de índice, que Splunk documenta como cerca de 0,5 para syslog y que cambia según la fuente (| dbinspect informa los tamaños de los buckets). En Elasticsearch, los mappings, multi-fields, _source, códecs y el modo de índice LogsDB pueden llevarlo muy por debajo o por encima de 1,0 (compara pri.store.size con los bytes sin procesar). El texto muy repetitivo se comprime bien; los campos estructurados de alta cardinalidad se comprimen menos. Usa las calculadoras de cada plataforma, que aceptan un factor medido, cuando ya lo tengas.

Tiers de retención

No todos los datos retenidos necesitan el mismo almacenamiento. Una división habitual:

• Hot / activo: datos recientes sobre los que se busca y se generan alertas; disco rápido y replicado.
• Warm: datos más antiguos con búsquedas ocasionales; disco más económico, a menudo todavía replicado.
• Archivo / almacenamiento de objetos: se conservan por cumplimiento o para investigaciones poco frecuentes; una copia en almacenamiento de objetos, con búsqueda más lenta o que requiere una restauración.

Dimensiona cada tier como su propia ventana de retención. Ejemplo ilustrativo Para 500 GB/día: 7 días hot con replicación 2 necesitan 8,75 TB (abrir), y los 83 días restantes como una única copia de archivo necesitan 51,9 TB (abrir), frente a 112,5 TB cuando los 90 días se replican. La compresión del archivo y los precios del almacenamiento de objetos no se modelan aquí.

Los tiers de cada plataforma cambian aún más el cálculo: Splunk separa rawdata y archivos de índice y ofrece SmartStore; Elasticsearch dimensiona los tiers hot, warm, cold y frozen con searchable snapshots. La guía de planificación de retención y almacenamiento de logs recorre el método completo.