Metodología de dimensionamiento

Principios

• Las fórmulas son visibles. Cada calculadora muestra sus cálculos para los datos de entrada actuales y una descripción estática del modelo.
• Los supuestos son explícitos. Valores predeterminados como las proporciones de 15% / 35% de Splunk o el objetivo de utilización planificada de 85% están nombrados, con su fuente, y son editables.
• Primero la documentación del proveedor. Cuando Splunk o Elastic documentan un comportamiento, el modelo lo sigue y enlaza la página y la versión. Los supuestos propios de ObservKit se identifican como tales, por ejemplo el 10% de caché frozen.
• Una estimación de planificación no es una garantía. Los resultados dimensionan almacenamiento; no reemplazan pruebas de carga, el dimensionamiento del proveedor ni arquitecturas validadas.
• Local primero. Los cálculos se ejecutan en el navegador; los datos de entrada no se envían a ningún servidor.
• Los modelos cambian cuando cambia la evidencia. Las correcciones se registran en el registro de cambios de más abajo, con su impacto.

Modelo común

1. Ingesta
2. Retención
3. Factor en disco
4. Copias / réplicas
5. Crecimiento / margen de capacidad
6. Capacidad aprovisionada

dataset        = ingesta diaria × días de retención
en disco       = dataset × factor en disco             (compresión, estructuras de índice, mappings)
copias         = en disco × copias                      (replicación, search factor, réplicas)
utilizable     = copias × (1 + crecimiento)
aprovisionado  = utilizable ÷ objetivo de utilización   (donde la plataforma necesita disco libre)

El modelo genérico de Log Storage usa un factor en disco de 1,0 y ningún objetivo de utilización. Los modelos de plataforma reemplazan cada factor por el comportamiento documentado de la plataforma. El hub de planificación de capacidad recorre 250 GB/día por los tres modelos, lado a lado.

Modelos específicos por proveedor

Splunk

Rawdata es cerca de 15% del volumen previo a la indexación en cada copia (× RF); los archivos de índice, cerca de 35% solo en las copias con capacidad de búsqueda (× SF). SmartStore reemplaza el disco local dimensionado por la retención por una ventana de caché más hot buckets replicados, y almacena una copia remota de los warm buckets. Detalles: cómo se calcula el dimensionamiento de Splunk, guía de SmartStore.

Elasticsearch

Volumen sin procesar × factor índice/crudo por tier; réplicas solo en índices regulares; los searchable snapshots fully mounted conservan una copia local y frozen conserva una caché, con el dataset en el repositorio de snapshots; disco aprovisionado = utilizable ÷ 85% de utilización planificada (÷ 90% de participación de la caché compartida en frozen). Detalles: cómo se calcula el dimensionamiento de Elastic, guía de tiers de datos.

Grafana Loki

El almacenamiento de objetos contiene una copia de los chunks comprimidos y del índice. Grafana no publica una tasa de compresión, por lo que el factor almacenado ÷ recibido es una suposición de planificación conservadora de ObservKit de 1,0× (editable, no es una recomendación de Grafana); mide loki_ingester_chunk_stored_bytes_total ÷ loki_distributor_bytes_received_total. El WAL de todo el clúster es una estimación de planificación aproximada y de baja confianza, escalada de forma lineal a partir del único punto que publica Grafana (un ingester, cerca de 5 MB/s, cerca de 5.000 series, cerca de 10–15 GB de WAL), con la replicación aplicada a la ingesta; no es un tamaño de disco requerido. El cómputo se muestra como el perfil de referencia de Grafana para el tier de ingesta correspondiente, no calculado para tu carga; las cargas de consulta pueden necesitar mucho más. Confianza: media para el almacenamiento de objetos, baja para la escala del WAL.

OpenSearch

Amazon OpenSearch Service sigue la fórmula de dimensionamiento de almacenamiento de AWS con un factor de índice de 1,1, 5% de espacio reservado de Linux y 20% de overhead de servicio (con un tope de 20 GiB por instancia, así que sin dimensionar nodos el resultado puede sobrestimar). OpenSearch autogestionado es solo hot y usa un objetivo agregado de utilización planificada basado en el low watermark de 85% por defecto. La guía de shards es de 10–50 GB por shard (AWS: 10–30 GiB para búsqueda, 30–50 GiB para análisis de logs). El límite de shards por nodo es de 1.000 por defecto en OpenSearch autogestionado (configurable) y, en Amazon OpenSearch Service, de 1.000 hasta la 2.15 y basado en el heap desde la 2.17 (1.000 por cada 16 GiB de heap, máximo 4.000); sin versión del motor ni heap, no se muestra una estimación de nodos de datos. No se modela: cantidad de nodos a partir de la capacidad, tipos de instancia, IOPS.

Eventos por segundo

EPS × bytes promedio por evento × 86.400 segundos = bytes por día, que se muestran como GB/día decimales (1 GB = 10⁹ bytes). El tamaño promedio del evento debe medirse sobre tus eventos reales.

Verificación

• Documentación. Cada supuesto con fuente enlaza a la página del proveedor y a la versión de la documentación con la que se contrastó. Las páginas muestran el mes de su última revisión; la fecha solo cambia cuando el contenido se vuelve a revisar.
• Fórmulas. Las pruebas automatizadas reproducen ejemplos documentados (los 100 GB de Splunk con RF3/SF2 dan 45 GB de rawdata + 70 GB de archivos de índice = 115 GB) y fijan invariantes como que SF nunca supere a RF, que no haya réplicas en searchable snapshots y que los datos frozen nunca se cuenten como una copia local completa.
• Ejemplos. Cada cifra de los ejemplos resueltos, los escenarios de referencia y las guías la generan los motores de cálculo y la recalculan las pruebas. Si cambia una fórmula, las pruebas fallan hasta que se actualice el contenido publicado.

Lo que ObservKit no afirma

ObservKit es un proyecto independiente. No está afiliado, respaldado ni certificado por Splunk LLC, Elasticsearch B.V., la Cloud Native Computing Foundation ni ningún otro proveedor, y sus resultados no son un dimensionamiento oficial de ningún proveedor. Los conteos de infraestructura, como la estimación de indexers de Splunk, son heurísticas de planificación. La concurrencia de búsquedas, el dimensionamiento de nodos, los perfiles de hardware y las apps premium quedan fuera de los modelos.

Registro de cambios

1. octubre de 2026 — Comparación de plataformas y conversión de EPS

   Nueva comparación de plataformas: una ingesta diaria, retención y crecimiento a través de los modelos de Splunk, Elasticsearch, Grafana Loki y OpenSearch, cada uno con exactamente los valores predeterminados que su propia calculadora aplica a un escenario importado, de modo que al abrir una tarjeta se ve la misma cifra. Un costo mensual opcional multiplica cada cantidad principal por un precio por GB-mes que ingresas tú; ObservKit no incluye precios. Las cuatro calculadoras de plataforma ahora convierten eventos por segundo a GB/día en el mismo lugar, con la misma fórmula que Log Storage. No cambió ninguna fórmula de dimensionamiento.

2. octubre de 2026 — Modelos de Grafana Loki y OpenSearch, entrada por EPS

   Se agregaron dos calculadoras. Grafana Loki: almacenamiento de objetos = ingesta diaria × almacenado ÷ recibido × retención, una copia, más crecimiento; el factor de replicación afecta solo a los ingesters y al WAL; el WAL se escala de forma lineal a partir de una prueba documentada de Grafana; el cómputo es el perfil de referencia publicado por Grafana para cada tier de ingesta y nunca se suma al almacenamiento. OpenSearch: Amazon OpenSearch Service usa fuente × (1 + réplicas) × factor de índice ÷ 0,95 ÷ 0,80, con UltraWarm y almacenamiento cold como datos solo primarios en S3; OpenSearch autogestionado divide el tamaño almacenado por un objetivo de utilización de disco de planificación (85% por defecto). Log Storage incorporó una entrada de eventos por segundo (EPS × bytes promedio por evento × 86.400 = bytes/día) y puede continuar hacia cuatro plataformas, transfiriendo solo la ingesta diaria, la retención y el crecimiento. Elasticsearch y OpenSearch incorporaron un planificador de shards compartido (regla práctica de 10–50 GB; 1.000 shards por nodo de datos por defecto en Elasticsearch). Los modelos existentes no cambian.

3. octubre de 2026 — Contenido de referencia y guías

   Las páginas de Splunk, Elasticsearch y Log Storage incorporaron ejemplos resueltos, escenarios de referencia, decisiones de dimensionamiento, errores comunes y fuentes visibles. Se agregaron tres guías y esta página de metodología. Cada cifra de estas páginas la generan los motores de cálculo y la verifican las pruebas.

4. octubre de 2026 — Hub de planificación de capacidad y traspaso desde Log Storage

   Log Storage puede continuar hacia Splunk o Elasticsearch, transfiriendo solo la ingesta diaria, la retención y el crecimiento. La replicación no se transfiere porque Splunk usa RF/SF y Elasticsearch usa réplicas por tier. La retención importada a Elasticsearch parte como 7 días hot, 23 warm y el resto cold, como punto de partida que debes revisar.

5. octubre de 2026 — Modelo de almacenamiento de Splunk corregido

   Antes: indexado = volumen previo a la indexación × 0,5 y luego × RF para cada copia. Después: rawdata = P × 0,15 × RF más archivos de índice = P × 0,35 × SF, según la documentación de clústeres de indexers de Splunk: las copias sin capacidad de búsqueda solo contienen rawdata. Impacto con RF3/SF2: 1,15× en lugar de 1,50× el volumen previo a la indexación. El resultado corregido es 23,3% menor que el anterior; dicho al revés, el modelo previo era 30,4% mayor que el corregido. Con RF = SF ambos modelos dan el mismo resultado. El modo SmartStore se agregó al mismo tiempo (caché local + hot buckets replicados; una copia remota de los warm buckets).

6. octubre de 2026 — Modelo de tiers de Elasticsearch corregido

   Antes: cada tier, incluido frozen, almacenaba el dataset completo × (1 + réplicas), sin margen de disco. Después: las réplicas se aplican solo a índices regulares; el cold fully mounted conserva una copia local; frozen conserva una caché local y el dataset completo en el repositorio de snapshots; se agregó una entrada de factor índice/crudo; el disco aprovisionado divide los datos utilizables por un objetivo de utilización planificada.

7. octubre de 2026 — Redacción de la utilización planificada

   La entrada que antes se llamaba watermark de disco pasó a llamarse «Objetivo de utilización de disco planificada» (85%), porque es un supuesto agregado de planificación y no el asignador por watermark de cada nodo, que además aplica un tope de max-headroom de 200 GB.

8. septiembre de 2026 — Publicación de las calculadoras de Splunk y Elasticsearch

   Primeras versiones de la calculadora de dimensionamiento y almacenamiento de Splunk y de la calculadora de dimensionamiento de Elasticsearch.

Última revisión: octubre de 2026