Planificación de retención y almacenamiento de logs

El método

GB diarios  = eventos/s × bytes promedio por evento × 86.400 ÷ 10⁹
dataset      = GB diarios × días de retención
almacenado   = dataset × factor de almacenamiento
copias       = almacenado × replicación
capacidad    = copias × (1 + crecimiento), luego el margen de la plataforma

Ejemplo ilustrativo un equipo envía en promedio 5.000 eventos/s de eventos de 600 bytes, los conserva un año, busca con frecuencia en las últimas dos semanas y rara vez en los datos más antiguos.

1. Volumen diario

5.000 × 600 × 86.400 = 259.200.000.000 bytes = 259,2 GB/día. Usa la tasa promedio sobre días completos y al menos una semana completa. Un pico hipotético de una hora de 12.000 eventos/s extrapolado al día daría 622,1 GB/día: 2,4 veces más almacenamiento del necesario. Los picos dimensionan el throughput de ingesta; los totales diarios dimensionan el almacenamiento.

Si ya tienes una plataforma, su propia contabilidad es mejor que una estimación: el uso diario de licencia en Splunk, o los bytes ingeridos por tus shippers.

2. Retención según el propósito

Un solo número de «retención» suele esconder tres: hasta dónde miran hacia atrás las alertas y los dashboards (días), hasta dónde llegan las investigaciones (de semanas a meses) y lo que exige la política o la regulación (de meses a años). Anótalos por separado; se asignan a tiers en el paso 6. En el ejemplo: 14 días de búsqueda frecuente, 365 días en total.

Cuenta la retención en días. Doce meses de 30 días son 360 días, cinco o seis menos que un año calendario, lo que importa cuando hablamos de cientos de GB por día.

3. Factor de almacenamiento

El tamaño almacenado rara vez coincide con el tamaño sin procesar. Mide bytes almacenados de una copia ÷ bytes crudos ingeridos durante al menos siete días, sobre datos que ya no se están escribiendo. Splunk documenta una referencia de aproximadamente 0,5 (15% de rawdata + 35% de archivos de índice) para syslog; en Elasticsearch varía según mappings, multi-fields, _source, códecs y LogsDB, y puede estar por encima o por debajo de 1,0. Mientras no lo midas, la suposición neutral es 1,0, que es lo que usa la calculadora genérica.

4. Copias

Las copias existen por dos razones distintas: sobrevivir a la pérdida de un nodo (disponibilidad de los datos) y mantener los datos consultables durante esa pérdida (disponibilidad de búsqueda). Las plataformas las separan: Splunk con RF y SF, Elasticsearch con réplicas en tiers regulares y ninguna en searchable snapshots. Una única copia de archivo en almacenamiento de objetos depende de la durabilidad propia de ese almacenamiento.

Con replicación 2 durante todo el año, el ejemplo necesita 236,5 TB incluyendo 25% de crecimiento. Abre este escenario en la calculadora de almacenamiento de logs.

5. Crecimiento y margen de capacidad

Son cosas distintas. El crecimiento es la ingesta del próximo año: servicios, equipos y verbosidad nuevos; ObservKit lo aplica como porcentaje después de las copias. El margen de capacidad (headroom) es el disco libre que la plataforma necesita para seguir funcionando: Elasticsearch, por ejemplo, deja de asignar shards a un nodo que supera su low watermark de 85%, por lo que la calculadora de Elastic divide por un objetivo de utilización planificada. Agregar 15% no es lo mismo que dividir por 0,85: dividir agrega 17,6%.

6. Tiers

Asigna los propósitos de retención al almacenamiento: 14 días de búsqueda frecuente en disco rápido con réplicas, y el resto como una única copia de archivo.

La línea de archivo sigue siendo dato crudo sin comprimir; el almacenamiento de objetos con compresión sería más pequeño, y buscar sobre él es más lento o requiere una restauración.

Modelos por plataforma

Una vez elegida la plataforma, su propio modelo reemplaza a los factores genéricos:

• Splunk SmartStore, los mismos 259,2 GB/día durante 365 días, RF2/SF2, caché de 30 días: 5,02 TB de almacenamiento local en indexers y 59 TB en el almacenamiento de objetos. Abre este escenario en Splunk.
• Elasticsearch, 7 días hot, 7 warm y 351 frozen, una réplica: 23,3 TB de disco de nodos aprovisionado y 113,7 TB en el repositorio de snapshots. Abre este escenario en Elastic.
• Grafana Loki, los mismos 259,2 GB/día durante 365 días con una suposición de planificación conservadora de almacenado ÷ recibido de 1,0×: 118,3 TB de almacenamiento de objetos, una copia. Abre este escenario en Loki.
• OpenSearch en Amazon OpenSearch Service, los 365 días en hot con una réplica: 342,3 TB incluyendo el overhead de AWS. Abre este escenario en OpenSearch.

Para conocer los compromisos detrás de esos layouts, consulta la guía de Loki, la guía de OpenSearch, la guía de SmartStore y la guía de tiers de datos de Elasticsearch.

Errores comunes

1. Extrapolar el pico de eventos al día completo: 622,1 en lugar de 259,2 GB/día en el ejemplo.
2. Dimensionar desde el derecho de licencia en lugar del volumen medido.
3. Asumir una tasa de compresión de otra plataforma o de otra fuente de datos.
4. Replicar el archivo cuando el almacenamiento de objetos ya ofrece durabilidad.
5. Confundir crecimiento con margen de capacidad y no aplicar ninguno.
6. Una sola retención para todo, que deja un año de datos rara vez consultados en el disco más caro.

Qué no cubre este método

• Throughput de ingesta. El almacenamiento sigue los totales diarios; los indexers, los nodos de ingesta y los pipelines deben dimensionarse por separado para los picos de eventos.
• Carga de búsqueda. La concurrencia, los dashboards y las búsquedas programadas determinan CPU y memoria, no el disco.
• Compresión en el tier de archivo y los precios, costos de solicitudes y tiempos de recuperación del almacenamiento de objetos.
• Overhead de la plataforma: sistema operativo, reserva del sistema de archivos, espacio temporal para merges, recuperación y snapshots.
• Datos que no son logs: las métricas y las trazas tienen otros perfiles de tamaño y retención, y normalmente otros motores de almacenamiento.

Cualquiera de estos puntos puede importar más que el almacenamiento en el diseño final; el método entrega el dato de capacidad para ese diseño, no el diseño en sí.

Última revisión: octubre de 2026 · Calculadora de almacenamiento de logs · Planificación de capacidad · Metodología