Planificación de capacidad para datos de observabilidad
Ve de lo que sabes a un plan de almacenamiento en cinco pasos. Puedes omitir cualquiera: cada herramienta parte de valores predeterminados razonables y muestra sus cálculos.
Flujo de trabajo de planificación de capacidad
Medir
¿Conoces tus eventos por segundo y el tamaño promedio del evento, o tus GB diarios? Conviértelos en una ingesta diaria. EPS × bytes promedio por evento × 86.400 da los GB/día.
Retener
Decide cuántos días deben permanecer disponibles para búsqueda, cuántos pueden estar en almacenamiento más económico y cuántos solo requieren archivo. Log Storage aplica una única ventana de retención; las herramientas de cada plataforma la dividen en tiers.
Elegir una plataforma
Cada herramienta parte de la ingesta diaria y la retención que ya tienes, y usa sus propios valores predeterminados documentados para todo lo demás.
Refinar
Replicación, tiering, shards, almacenamiento de objetos, caché, crecimiento y margen de capacidad (headroom). El modo Experto de cada herramienta muestra los ratios; la planificación de shards está en Elasticsearch y OpenSearch.
Compararopcional
Compara dos escenarios, guárdalos en tu navegador, abre un informe imprimible o comparte un enlace. Nada de esto es obligatorio para obtener un resultado.
Cómo se relacionan los datos de entrada
Todos los modelos parten de la misma base: ingesta diaria × días de retención es el volumen que debes conservar. Luego tres factores lo modifican:
- Factor en disco: los datos rara vez ocupan en disco su tamaño original. La compresión lo reduce; las estructuras de indexación y los mappings pueden aumentarlo.
- Copias: los factores de replicación, los factores de búsqueda y las réplicas multiplican una parte o la totalidad de ese volumen para dar resiliencia y disponibilidad de búsqueda.
- Margen de capacidad (headroom): un margen de crecimiento para la ingesta del próximo año, más el disco libre que la plataforma necesita para seguir operando.
Los shards son una cantidad, no un tamaño: dividen los mismos datos en unidades que el clúster puede ubicar y recuperar, por lo que influyen más en el diseño de nodos que en el disco total.
Por qué cada plataforma necesita su propio modelo
Almacenamiento genérico de logs
Úsala para una estimación independiente de la plataforma cuando solo conoces los GB/día: volumen sin procesar × replicación × crecimiento, sin asumir compresión.
Splunk
Úsala para clústeres de indexers de Splunk Enterprise: rawdata se conserva en cada copia (× RF), pero los archivos de índice solo en las copias con capacidad de búsqueda (× SF), y SmartStore mueve los datos warm a almacenamiento de objetos.
Elasticsearch
Úsala cuando los datos pasan por los tiers hot, warm, cold y frozen: las réplicas se aplican por tier, los searchable snapshots cambian lo que permanece en disco local y el disco se aprovisiona con un objetivo de utilización.
Grafana Loki
Úsala cuando los logs viven como chunks en almacenamiento de objetos: una sola copia almacenada, un factor de replicación que afecta a los ingesters y a su WAL, y una referencia de cómputo publicada en lugar de un número de nodos calculado.
OpenSearch
Úsala para Amazon OpenSearch Service (overhead de la guía de dimensionamiento de AWS, UltraWarm y cold en S3) o para OpenSearch autogestionado. No es el modelo de Elasticsearch con otro nombre.
Las cinco son estimaciones de planificación calculadas en tu navegador. Cada herramienta muestra sus fórmulas, supuestos y fuentes para que puedas contrastar el resultado con tus propios datos.
El pipeline de capacidad, con números
Todos los modelos recorren los mismos seis pasos. Lo que cambia es el factor que cada plataforma aplica en cada paso. Aquí están para 250 GB/día conservados 90 días, con los valores predeterminados de cada calculadora.
Escenario de referencia entradas elegidas para comparar, no un tamaño recomendado.
- Ingesta
- Retención
- Factor en disco
- Copias / réplicas
- Crecimiento / margen de capacidad
- Capacidad aprovisionada
| Paso | Genérico | Splunk RF2/SF2 | Elasticsearch, 1 réplica |
|---|---|---|---|
| Ingesta × retención | 22,5 TB | 22,5 TB | 22,5 TB |
| Factor en disco (una copia) | × 1.0 → 22,5 TB | × 0.5 (0.15 + 0.35) → 11,3 TB | × 1.0 → 22,5 TB |
| Copias | × 2 → 45 TB | rawdata × RF2 + índice × SF2 → 22,5 TB | primario + 1 réplica → 45 TB |
| Crecimiento 25% | 56,3 TB | 28,1 TB | 56,3 TB |
| Margen de disco | no se modela | no se modela | ÷ 85% → 66,2 TB |
| Capacidad aprovisionada | 56,3 TB | 28,1 TB | 66,2 TB |
Ingesta es el volumen diario que debes conservar, medido sobre tráfico real. Retención lo multiplica hasta formar el dataset. El factor en disco convierte bytes crudos en bytes almacenados. Las copias aportan resiliencia y capacidad de búsqueda. El crecimiento reserva espacio para la ingesta del próximo año y el margen de capacidad (headroom) mantiene los discos por debajo del nivel en que la plataforma deja de funcionar bien.
Mismo dato de entrada, arquitecturas distintas
Escenario de referencia 250 GB/día durante 90 días con dos copias y un margen de crecimiento de 25% dan respuestas distintas, y ninguna está equivocada. Son respuestas a modelos de almacenamiento distintos, y no todos los números miden lo mismo.
Volumen sin procesar × 2 copias × 25% de crecimiento. Sin asumir compresión.
Aproximadamente 15% de rawdata × RF más 35% de archivos de índice × SF: la mitad del tamaño sin procesar por copia completa.
Factor 1,0 × 2 copias × 25% de crecimiento, y luego ÷ 85% de utilización de disco planificada.
Dataset en almacenamiento de objetos, una copia, 25% de crecimiento, con una suposición de planificación conservadora de almacenado ÷ recibido de 1,0× (mide la tuya). El factor de replicación cambia el WAL de los ingesters, no esta cifra.
Almacenamiento hot con una réplica, factor de índice 1,1, 25% de crecimiento y luego el overhead de AWS de 5% + 20% (aproximadamente ×1,45 sobre la fuente).
La cifra de Loki es almacenamiento de objetos y las demás son disco local, así que no debe leerse como «más barato». OpenSearch incluye un overhead de servicio que el modelo genérico no tiene.
- Splunk es el más pequeño porque su referencia documentada almacena cerca de la mitad del tamaño sin procesar por copia, y los archivos de índice solo se conservan en las copias con capacidad de búsqueda.
- Elasticsearch es el más grande porque el factor predeterminado asume que no hay compresión y el resultado es disco aprovisionado: 56,3 TB de datos ÷ 0,85 = 66,2 TB. Con todos los tiers regulares, factor 1,0 y una réplica, es el resultado genérico dividido por 0,85: 18% más.
- El modelo genérico es la línea base neutral: sin compresión, con todas las copias completas y sin margen de disco. Úsalo cuando aún no conoces la plataforma.
Compara los modelos
| Modelo | Multiplicador principal | Modelo de replicación | Margen de capacidad | Ubicación del almacenamiento |
|---|---|---|---|---|
| Genérico | GB/día sin procesar × días (factor 1,0) | Todo el dataset × replicación (1–3) | % de crecimiento después de la replicación | Un único pool local |
| Splunk | Rawdata 0,15 y archivos de índice 0,35 del volumen previo a la indexación | Rawdata × RF, archivos de índice × SF | % de crecimiento después de las copias | Disco de los indexers; con SmartStore, caché + hot en local y una copia remota de los warm buckets |
| Elasticsearch | GB/día sin procesar × factor índice/crudo (predeterminado 1,0) | Primarios + réplicas en tiers regulares; ninguna en searchable snapshots | % de crecimiento y luego ÷ utilización planificada (85%) | Disco de nodos hot/warm/cold; caché frozen en local; repositorio de snapshots para searchable snapshots |
| Grafana Loki | GB/día sin procesar × almacenado ÷ recibido (suposición de planificación conservadora de 1,0×, editable) | Una copia en el almacenamiento de objetos; el factor de replicación se aplica a los ingesters y al WAL | % de crecimiento sobre el almacenamiento de objetos; el volumen del WAL se mantiene bajo el umbral de disco lleno de 90% | Almacenamiento de objetos para chunks e índice; disco local para el WAL; cómputo como perfil de referencia publicado |
| OpenSearch | GB/día de la fuente × factor de índice (predeterminado 1,1) | Primarios + réplicas en hot; UltraWarm y cold solo con primarios (Amazon OpenSearch Service) | AWS: ÷ 0,95 ÷ 0,80; autogestionado: ÷ objetivo de utilización planificada | Almacenamiento de nodos hot; UltraWarm y cold en S3 (solo Amazon OpenSearch Service) |
Antes de dimensionar
La mayoría de los errores de dimensionamiento vienen de los datos de entrada, no de las fórmulas. Revisa primero esto:
- Ingesta real. El volumen diario medido, no el derecho de licencia ni una cotización de un proveedor. En una licencia hipotética de 500 GB/día con 320 GB/día de tráfico real, dimensionar desde la licencia sobredimensiona el almacenamiento de Splunk en 56%.
- Pico frente a promedio. Dimensiona el almacenamiento con los totales diarios de una semana completa; dimensiona el throughput de indexación con los picos.
- Retención según el propósito. Las ventanas de búsqueda y alertas, las de investigación y la retención por cumplimiento suelen ser distintas; cada una puede ser un tier diferente.
- Expansión o compresión en disco. Un factor en disco medido supera a cualquier valor predeterminado. Un factor hipotético de 1,3 en lugar de 1,0 cambia el escenario de referencia de 66,2 TB a 86 TB.
- Réplicas y copias. Qué copias contienen los datos completos y cuáles no (SF de Splunk, searchable snapshots).
- Objetivos de recuperación. Cuántas fallas de nodo debes soportar sin perder datos ni capacidad de búsqueda, y cuánto puede tardar la recuperación.
- Tiering. Qué días necesitan disco local rápido y cuáles pueden pasar a nodos más económicos o a almacenamiento de objetos.
- Almacenamiento de objetos. SmartStore y los searchable snapshots mueven la mayor parte de los datos retenidos al almacenamiento de objetos, que necesita su propio presupuesto de capacidad.
- Crecimiento esperado. Las fuentes y los equipos nuevos suelen sumar más volumen que el crecimiento orgánico; acuerda un margen por año.
Profundiza
Planificación de retención y almacenamiento de logs
Método independiente del proveedor: volumen diario a partir de la tasa de eventos, factor de almacenamiento medido y tiers de retención.
Dimensionamiento de Splunk SmartStore
Caché frente a retención, réplicas de hot buckets, dimensionamiento del almacenamiento de objetos y cuándo conviene SmartStore.
Dimensionamiento de tiers de datos de Elasticsearch
Hot, warm, cold y frozen: disco local frente a repositorio, réplicas y el objetivo de utilización.
Dimensionamiento de Grafana Loki
Almacenamiento de objetos, WAL, replicación, retención y caché; qué cubren y qué no cubren los perfiles de dimensionamiento publicados.
Dimensionamiento de OpenSearch
Ingesta, shards, réplicas, tiers de almacenamiento y planificación de disco, y Amazon OpenSearch Service frente a autogestionado.
Cómo ObservKit construye y verifica estos modelos: metodología y registro de cambios.
Última revisión: