Elasticsearch es una plataforma muy versátil que soporta varios casos de uso y brinda gran flexibilidad para la organización de datos y las estrategias de replicación. Sin embargo, en ocasiones esta flexibilidad puede dificultar determinar por anticipado cómo organizar de la mejor manera tus datos en índices y shards, en especial si eres nuevo en el Elastic Stack. Si bien las elecciones subóptimas no necesariamente generarán problemas al inicio, tienen el potencial de causar problemas de rendimiento a medida que aumentan los volúmenes de datos con el tiempo. Mientras más datos contiene el cluster, más difícil resulta corregir el problema. Esto se debe a que, a veces, puede ser necesario reindexar grandes cantidades de datos.Cuando encontramos usuarios que tienen problemas de rendimiento, con frecuencia es posible rastrear su origen hasta inconvenientes en cómo se indexan los datos y en la cantidad de shards en el cluster. Esto suele ser así, en especial, en los casos de uso que involucran multitenancy o el uso de índices basados en el tiempo. Al hablar de este tema con los usuarios, tanto personalmente en eventos o reuniones como a través de nuestro <a href="https://discuss.elastic.co" target="_self">foro</a>, algunas de las preguntas más comunes son: "¿cuántos shards debería tener?" y "¿qué tan grandes deberían ser los shards?".El objetivo de este blog es ayudarte a responder estas preguntas y brindar una orientación práctica para los casos de uso que involucrar el uso de índices basados en el tiempo (por ejemplo, logging o analítica de seguridad) en un solo lugar.<h2 dir="ltr">¿Qué es un shard?</h2>Antes de comenzar, debemos establecer algunas cuestiones y terminología que necesitaremos en secciones posteriores.Los datos en Elasticsearch se organizan en <a href="https://www.elastic.co/guide/en/elasticsearch/guide/2.x/_add_an_index.html" target="_self">índices</a>. Cada índice se compone de uno o más shards. Cada shard es una instancia de un índice de Lucene, en lo que puedes pensar como un motor de búsqueda autocontenido que indexa y se encarga de las búsquedas de un subconjunto de datos en un cluster de Elasticsearch.A medida que los datos se escriben en un shard, se publican periódicamente en nuevos segmentos inmutables de Lucene en disco, y entonces se vuelven disponibles para la búsqueda. A esto se lo denomina "actualización". El funcionamiento se describe en más detalle en <a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/inside-a-shard.html" target="_self">Elasticsearch: the Definitive Guide</a> (Elasticsearch: La guía definitiva).A medida que aumenta la cantidad de segmentos, estos se consolidan periódicamente en segmentos más grandes. A este proceso se lo denomina "<a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.5/index-modules-merge.html" target="_self">fusión</a>". Dado que todos los segmentos son inmutables, esto significa que el espacio en disco usado generalmente fluctuará durante la indexación debido a que deben crearse segmentos nuevos fusionados para poder eliminar aquellos a los que reemplazarán. La fusión puede consumir muchos recursos, en especial con respecto a la E/S del disco.El shard es la unidad en la que Elasticsearch distribuye los datos en el cluster. La velocidad a la que Elasticsearch puede mover los shards al rebalancear los datos (por ejemplo, tras un fallo) dependerá del tamaño y la cantidad de shards, y del rendimiento del disco y la red.<table><tbody><tr><td>SUGERENCIA: Evita tener shards muy grandes, dado que esto puede afectar de forma negativa la capacidad del cluster de recuperarse ante un fallo. No existe un límite fijo de tamaño de los shards, pero un tamaño de shard de 50 GB suele citarse como un límite que funciona en una variedad de casos de uso.</td></tr></tbody></table><h2 dir="ltr">Índice por período de retención</h2>Como los segmentos son inmutables, <a href="https://www.elastic.co/guide/en/elasticsearch/guide/2.x/update-doc.html" target="_self">actualizar un documento</a> requiere que Elasticsearch primero encuentre el documento existente, luego lo marque como eliminado y agregue la versión actualizada. <a href="https://www.elastic.co/guide/en/elasticsearch/guide/2.x/delete-doc.html" target="_self">Eliminar un documento</a> también requiere que el documento se encuentre y se marque como eliminado. Por este motivo, los documentos eliminados <a href="/es/blog/lucenes-handling-of-deleted-documents" target="_self">seguirán usando espacio en disco y algunos recursos del sistema hasta que se fusionen</a>, lo cual puede consumir muchos recursos del sistema.Elasticsearch permite una eliminación muy eficiente de índices completos directamente desde el sistema de archivos, sin tener que eliminar de manera explícita todos los registros individualmente. Es, por mucho, la forma más eficiente de eliminar datos de Elasticsearch.<hr/>SUGERENCIA: Intenta usar <a href="https://www.elastic.co/guide/en/elasticsearch/guide/2.x/time-based.html" target="_self">índices basados en el tiempo</a> para gestionar la retención de datos cuando sea posible. Agrupa los datos en índices según el período de retención. Los índices basados en el tiempo también facilitan variar la cantidad de shards primarios y réplicas en el tiempo, dado que esto puede cambiarse en el próximo índice que se generará. Esto simplifica la adaptación a los requisitos y los volúmenes de datos cambiantes.<hr/><h2 dir="ltr">¿Los índices y shards no son gratis?</h2>De cada índice de Elasticsearch, la información sobre mapeos y estado se almacena en el estado del cluster. Esto se mantiene en memoria para poder acceder con rapidez. Tener una gran cantidad de índices y shards en un cluster, por lo tanto, puede dar como resultado un estado de cluster grande, en especial si los mapeos son grandes. Es posible que actualizar esto sea lento, debido a que todas las actualizaciones deben hacerse a través de un solo thread a fin de garantizar la consistencia antes de que se distribuyan los cambios por todo el cluster.<hr/>SUGERENCIA: A fin de reducir la cantidad de índices y evitar mapeos grandes y crecientes, considera almacenar los datos con estructura similar en el mismo índice, en lugar de separarlos en diferentes índices según el origen de los datos. Es importante encontrar un buen equilibrio entre la cantidad de índices y shards, y el tamaño de mapeo de cada índice individual. Como el <a href="https://www.elastic.co/guide/en/elasticsearch/guide/2.x/finite-scale.html#finite-scale" target="_blank">estado del cluster</a> se carga en la memoria heap de cada nodo (incluidos los maestros) y la cantidad de memoria heap es directamente proporcional a la cantidad de índices, campos por índice y shards, es importante monitorear también el uso de la memoria heap en los nodos maestros y asegurarse de que se dimensionen correctamente.<hr/>Cada shard tiene datos que deben mantenerse en memoria y usan espacio de la memoria heap. Esto incluye estructuras de datos que mantienen información a nivel del shard, pero también a nivel del segmento para definir dónde residen los datos en el disco. El tamaño de estas estructuras de datos no es fijo y variará según el caso de uso.Una característica importante de la sobrecarga relacionada con los segmentos, sin embargo, es que no es estrictamente proporcional al tamaño del segmento. Esto significa que los segmentos más grandes tienen menos sobrecarga por volumen de datos en comparación con segmentos más pequeños. La diferencia puede ser significativa.A fin de poder almacenar la mayor cantidad de datos posibles por nodo, resulta importante gestionar el uso de memoria heap y reducir lo más posible la cantidad de sobrecarga. Mientras más espacio de memoria heap tenga un nodo, más datos y shards podrá controlar.Por lo tanto, los índices y shards no son gratis desde la perspectiva del cluster, dado que hay una cierta sobrecarga de recursos por cada índice y shard.<hr/>SUGERENCIA: Los shards pequeños dan como resultado segmentos pequeños, lo cual aumenta la sobrecarga. Intenta mantener el tamaño promedio de shard entre algunos GB y algunas decenas de GB. En los casos de uso con datos basados en el tiempo, es habitual ver shards de entre 20 GB y 40GB.SUGERENCIA: Como la sobrecarga por shard depende del recuento y el tamaño de los segmentos, forzar la fusión de segmentos más pequeños en otros más grandes con la operación <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.5/indices-forcemerge.html" target="_self">forcemerge</a> puede reducir la sobrecarga y mejorar el rendimiento de la búsqueda. Idealmente, esto debería realizarse una vez que no se escriban más datos en el índice. Ten en cuenta que es una operación costosa y lo ideal sería realizarla en las horas con menor demanda.SUGERENCIA: La cantidad de shards que puedes tener en un nodo será proporcional a la cantidad de memoria heap que tengas disponible, pero no hay un límite fijo impuesto por Elasticsearch. Una buena regla general es asegurarse de mantener menos de 20 shards por nodo por GB de memoria heap configurado. Un nodo con una memoria heap de 30 GB, por lo tanto, debería tener un máximo de 600 shards, pero mientras más alejado puedas mantenerte por debajo de este límite, mejor. En general, esto ayudará a mantener el cluster en buen estado. (Nota del editor: A partir de la versión 8.3, redujimos en gran medida el uso de memoria heap por shard, por lo que actualizamos la regla general en este blog. Ve la SUGERENCIA siguiente para las versiones 8.3 y posteriores de Elasticsearch).NUEVA SUGERENCIA: Permitir 1 kB de memoria heap por campo por índice en los nodos de datos, más las sobrecargas El uso exacto de recursos de cada campo mapeado depende de su tipo, pero una regla general es permitir aproximadamente 1 kB de sobrecarga de memoria heap por campo mapeado por índice mantenido en cada nodo de datos. También debes permitir suficiente memoria heap para el uso básico de Elasticsearch y tu carga de trabajo, como indexación, búsquedas y agregaciones. Una memoria heap adicional de 0.5 GB será suficiente para muchas cargas de trabajo razonables, y es posible que necesites incluso menos si tu carga de trabajo es muy liviana, mientras que una carga más pesada requerirá más.Por ejemplo, si un nodo de datos mantiene shards de 1000 índices, cada uno con 4000 campos mapeados, entonces deberías permitir aproximadamente 1000 × 4000 × 1kB = 4 GB de memoria heap para los campos y otros 0.5 GB para la carga de trabajo y otras sobrecargas; entonces, este nodo necesitará un tamaño de memoria heap de al menos 4.5 GB.<hr/><h2 dir="ltr">¿Cómo afecta el tamaño del shard al rendimiento?</h2>En Elasticsearch, cada búsqueda se ejecuta en un solo thread por shard. Sin embargo, varios shards pueden procesarse en paralelo, al igual que pueden hacerlo varias búsquedas y agregaciones en el mismo shard.Esto significa que la latencia de búsqueda mínima, cuando no se involucra el almacenamiento en caché, dependerá de los datos, del tipo de búsqueda y del tamaño del shard. Buscar en muchos shards pequeños acelerará el procesamiento por shard, pero dado que muchas más tareas se pondrán en cola y procesarán en secuencia, no será necesariamente más rápido que buscar en una menor cantidad de shards más grandes. Tener muchos shards pequeños también puede reducir el rendimiento de la búsqueda si hay varias búsquedas concurrentes.<hr/>SUGERENCIA: La mejor forma de determinar el tamaño máximo de los shards desde una perspectiva de rendimiento de la búsqueda es <a href="/es/elasticon/conf/2016/sf/quantitative-cluster-sizing" target="_self">una evaluación comparativa con búsquedas y datos realistas</a>. Realiza siempre la evaluación comparativa con una búsqueda y carga de indexación representativas de lo que el nodo tendría que manejar en producción, debido a que optimizar para una sola búsqueda puede llevar a resultados engañosos.<hr/><h2 dir="ltr">¿Cómo gestiono el tamaño de los shards?</h2>Al usar índices basados en el tiempo, cada índice se ha asociado tradicionalmente con un período de tiempo fijo. Los índices diarios son muy comunes y suelen usarse para mantener datos con período de retención breve o grandes volúmenes diarios. Permiten que el período de retención se gestione con buena granularidad y facilitan los ajustes para volúmenes cambiantes a diario. Los datos con un período de retención más prolongado, en especial si los volúmenes diarios no garantizan el uso de índices diarios, suelen usar índices semanales o mensuales para mantener elevado el tamaño de los shards. Esto reduce la cantidad de índices y shards que deben almacenarse en el cluster con el tiempo.<hr/>SUGERENCIA: Si usas índices basados en el tiempo que abarcan un período fijo, ajusta el período que cubre cada índice según el período de retención y los volúmenes de datos esperados para alcanzar el tamaño de shard objetivo.<hr/>Los índices basados en el tiempo con un intervalo de tiempo fijo funcionan bien cuando los volúmenes de datos son razonablemente predecibles y cambian lento. Si la tasa de indexación puede variar rápidamente, es muy difícil mantener un tamaño de shard objetivo uniforme.Para poder manejar mejor este tipo de escenarios, se introdujeron las <a href="/es/blog/managing-time-based-indices-efficiently" target="_self">API de rollover y reducción</a>. Agregan mucha flexibilidad a la gestión de índices y shards, en especial a los índices basados en el tiempo.La <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.5/indices-rollover-index.html" target="_self">API de índice de rollover</a> posibilita especificar la cantidad de documentos que debería contener un índice o el período máximo durante el cual deberían escribirse documentos en él. Una vez superado uno de estos criterios, Elasticsearch puede activar la creación de un índice nuevo para la escritura sin tiempo de inactividad. En lugar de que cada índice cubra un período de tiempo específico, ahora es posible cambiar a un índice nuevo al alcanzar un tamaño específico, lo cual facilita tener un tamaño de shards más parejo en todos los índices.En casos en los que puedan actualizarse los datos, ya no hay un enlace distinto entre la marca de tiempo del evento y el índice en el que reside al usar esta API, lo cual puede hacer que las actualizaciones sean significativamente menos eficientes dado que cada actualización puede necesitar estar precedida por una búsqueda.<hr/>SUGERENCIA: Si tienes datos inmutables basados en el tiempo en los que los volúmenes pueden variar significativamente con el tiempo, considera usar la API de índice de rollover para lograr un tamaño de shard objetivo óptimo variando de forma dinámica el período de tiempo que abarca cada índice. Esto brinda gran flexibilidad y puede ayudar a evitar tener shards demasiado grandes o pequeños cuando los volúmenes de datos son impredecibles. <hr/>La <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.5/indices-shrink-index.html" target="_self">API de índice de reducción</a> te permite reducir un índice existente a un índice nuevo con menos shards primarios. Si se desea una distribución pareja de los shards en los nodos durante la indexación, pero esto dará como resultado shards demasiado pequeños, esta API se puede usar para reducir la cantidad de shards primarios una vez que ya no se realicen indexaciones en el índice. El resultado será shards más grandes, más adecuados para el almacenamiento de datos a largo plazo. <hr/>SUGERENCIA: Si necesitas que cada índice cubra un período de tiempo específico, pero deseas poder distribuir la indexación en una gran cantidad de nodos, considera usar la API de reducción para disminuir la cantidad de shards primarios una vez que ya no se realicen indexaciones en el índice. Esta API también se puede usar para disminuir la cantidad de shards en caso de que hayas configurado demasiados shards al inicio. <hr/><h2 dir="ltr">Conclusiones</h2>En este blog se proporcionaron consejos y orientación práctica sobre cómo gestionar los datos en Elasticsearch de la mejor manera. Si te interesa conocer más, "Elasticsearch: the definitive guide" (Elasticsearch: La guía definitiva) contiene una sección sobre <a href="https://www.elastic.co/guide/en/elasticsearch/guide/2.x/scale.html" target="_self">diseñar para escalar</a>, que vale la pena leer a pesar de que es un poco antigua.Muchas decisiones respecto a cómo distribuir mejor tus datos en los índices y shards dependerán de las especificaciones de los casos de uso, y a veces puede ser difícil determinar cómo aplicar mejor el consejo disponible. Para obtener consejos más detallados y personalizados, involúcrate con nosotros <a href="/es/subscriptions" target="_self">comercialmente a través de una suscripción</a> y deja que nuestros equipos de Soporte y Consultoría te ayuden a acelerar tu proyecto. Si deseas debatir sobre tu caso de uso de forma pública, también puedes obtener ayuda de <a href="/es/community" target="_self">nuestra comunidad</a> y a través del <a href="https://discuss.elastic.co" target="_self">foro</a> público. Este blog se publicó originalmente el 18 de septiembre de 2017. Se actualizó el 6 de julio de 2022.

How many shards should I have in my Elasticsearch cluster?

¿Cuántos shards debo tener en mi cluster de Elasticsearch?

¿Necesitas evitar duplicados en el Elastic Stack con impacto mínimo en el rendimiento? Veremos diferentes opciones y ofreceremos algunas pautas prácticas.

<html><head></head><body>El Elastic Stack se usa para muchos casos de uso diferentes. Uno de los m&#xE1;s comunes tiene que ver con el almacenamiento y an&#xE1;lisis de diferentes tipos de datos basados en eventos o series temporales; por ejemplo, los eventos, los logs y las m&#xE9;tricas de seguridad. Estos eventos a menudo consisten en datos vinculados a una marca de tiempo espec&#xED;fica que representa el momento en que el evento tuvo lugar o se recopil&#xF3;, y a menudo no hay una clave natural para identificarlo de manera inequ&#xED;voca.
Para algunos casos de uso, e incluso posiblemente tipos de datos en un caso de uso, es importante que los datos de Elasticsearch no se dupliquen: La duplicaci&#xF3;n de documentos puede derivar en an&#xE1;lisis incorrectos y errores de b&#xFA;squeda. Comenzamos a observar esto el a&#xF1;o pasado en el blog de <a href="/es/blog/logstash-lessons-handling-duplicates">introducci&#xF3;n al manejo de duplicados con Logstash</a>, y en este profundizaremos un poco m&#xE1;s y abordaremos algunas preguntas comunes.
<h2>Indexaci&#xF3;n en Elasticsearch</h2>Al indexar datos en Elasticsearch, debes recibir la respuesta para asegurarte de que la indexaci&#xF3;n sea exitosa. Si un error (por ejemplo, un problema de conexi&#xF3;n o una falla en un nodo) no te permite recibirla, no podr&#xE1;s estar seguro de que los datos se hayan indexado. Cuando los clientes se encuentran en una situaci&#xF3;n como esta, la alternativa est&#xE1;ndar para garantizar la entrega es hacer un nuevo intento. Esto puede hacer que el mismo documento se indexe m&#xE1;s de una vez.
Como se indic&#xF3; en el blog sobre manejo de duplicados, es posible solucionar esto definiendo un ID &#xFA;nico para cada documento en el cliente en lugar de hacer que Elasticsearch asigne uno autom&#xE1;ticamente en el momento de la indexaci&#xF3;n. Cuando un documento duplicado se escribe en el mismo &#xED;ndice, el documento se actualiza en lugar de escribirse por segunda vez. Esto evita duplicados.
<h2>UUID vs. ID de documentos basados en hash</h2>Cuando se trata de determinar el tipo de identificador que se usar&#xE1;, hay dos tipos.
Los <a href="https://en.wikipedia.org/wiki/Universally_unique_identifier">identificadores &#xFA;nicos universales</a> (UUID) son identificadores basados en n&#xFA;meros de 128 bits que pueden generarse en sistemas distribuidos, aunque por motivos pr&#xE1;cticos son &#xFA;nicos. Este tipo de identificador generalmente no depende del contenido del evento con el que se asocia.
Para evitar duplicados mediante UUID, es fundamental que estos &#xFA;ltimos se generen y se asignen al evento antes de que el evento exceda cualquier l&#xED;mite que garantice que se entregue exactamente una vez. En la pr&#xE1;ctica, esto a menudo significa que el UUID debe asignarse en el punto de origen. Si el sistema en el que se origina el evento no puede generar un UUID, posiblemente deba usarse un tipo de identificador diferente.
El otro tipo de identificador principal es aquel en el que se usa una <a href="https://en.wikipedia.org/wiki/Hash_function">funci&#xF3;n de hash</a> para generar un hash num&#xE9;rico seg&#xFA;n el contenido del evento. La funci&#xF3;n de hash siempre generar&#xE1; el mismo valor para un contenido espec&#xED;fico, pero no se garantiza que el valor generado sea &#xFA;nico. La <a href="https://preshing.com/20110504/hash-collision-probabilities/">probabilidad de un conflicto de hashes</a>, situaci&#xF3;n que se produce cuando dos eventos diferentes generan el mismo valor de hash, depende del n&#xFA;mero de eventos del &#xED;ndice, y tambi&#xE9;n del tipo de funci&#xF3;n de hash empleado y de la extensi&#xF3;n del valor que produce. Un hash de al menos 128 bits de extensi&#xF3;n (por ejemplo, MD5 o SHA1) generalmente proporciona un buen equilibrio entre la extensi&#xF3;n y bajas probabilidades de conflicto en much&#xED;simas situaciones. Para garantizar todav&#xED;a m&#xE1;s la exclusividad se puede usar un hash a&#xFA;n m&#xE1;s extenso, como el de cifrado SHA256.
Debido a que los identificadores basados en hash dependen del contenido de los eventos, es posible asignar esto en una etapa posterior del procesamiento porque el mismo valor se calcular&#xE1; donde se genere. Esto permite asignar este tipo de ID en cualquier punto antes de la indexaci&#xF3;n de los datos en Elasticsearch, lo que ofrece flexibilidad al designar un pipeline de ingesti&#xF3;n.
Logstash ofrece compatibilidad con el c&#xE1;lculo de UUID, y con diferentes funciones de hash populares y comunes, a trav&#xE9;s del <a href="/guide/en/logstash/6.4/plugins-filters-fingerprint.html">plugin de filtro de huellas digitales</a>.
<h2>Elegir un ID de documento eficaz</h2>Cuando tiene autorizaci&#xF3;n para asignar el identificador de documentos en el momento de la indexaci&#xF3;n, Elasticsearch puede aplicar optimizaciones porque seg&#xFA;n sus registros el identificador generado no puede existir previamente en el &#xED;ndice. Esto mejora el rendimiento de la indexaci&#xF3;n. En el caso de los identificadores generados de manera externa y transmitidos con los documentos, Elasticsearch debe considerar esto como una posible actualizaci&#xF3;n y verificar si los identificadores ya existen en segmentos de &#xED;ndice, proceso que requiere trabajo adicional y es m&#xE1;s lento.
No todos los identificadores de documentos externos se crean de igual forma. Los identificadores que con el tiempo aumentan seg&#xFA;n el orden de clasificaci&#xF3;n generalmente ofrecen un mejor rendimiento de indexaci&#xF3;n que los identificadores totalmente aleatorios. Esto se debe a que Elasticsearch puede determinar r&#xE1;pidamente si un identificador existe en segmentos de &#xED;ndices m&#xE1;s antiguos bas&#xE1;ndose &#xFA;nicamente en los valores m&#xED;nimo y m&#xE1;ximo de identificador de esos segmentos en lugar de tener que hacer b&#xFA;squedas en ellos. Hay disponible una descripci&#xF3;n en este <a href="http://blog.mikemccandless.com/2014/05/choosing-fast-unique-identifier-uuid.html">blog</a>, que sigue teniendo vigencia a pesar de ser un poco antigua.
Los identificadores basados en hash y muchos tipos de UUID generalmente son de naturaleza aleatoria. Al trabajar con un flujo de eventos en el que cada uno de estos tiene una marca de tiempo definida, se puede usar esta marca de tiempo como prefijo para el identificador para puedan clasificarse y, por lo tanto, aumentar el rendimiento de la indexaci&#xF3;n.
Crear un identificador con prefijo de una marca de tiempo tambi&#xE9;n tiene el beneficio de reducir la probabilidad de conflicto de hash, ya que el valor de hash debe ser &#xFA;nico por cada marca de tiempo. Esto permite usar valores de hash m&#xE1;s cortos aun en situaciones de alto volumen de ingesti&#xF3;n.
Es posible crear estos tipos de identificadores en Logstash usando el plugin de filtro de huellas digitales o generar un UUID o hash y un filtro Ruby para crear una representaci&#xF3;n de texto con codificaci&#xF3;n hexadecimal de la marca de tiempo. Suponiendo que hay un campo <code>message</code> al que podemos aplicar hash y que la marca de tiempo del evento ya se parse&#xF3; en el campo <code>@timestamp</code>, se pueden crear los componentes del identificador y almacenarlo en los metadatos de la siguiente manera:
<pre class="prettyprint">fingerprint {
 source =&gt; &quot;message&quot;
 target =&gt; &quot;[@metadata][fingerprint]&quot;
 method =&gt; &quot;MD5&quot;
 key =&gt; &quot;test&quot;
}
ruby {
 code =&gt; &quot;event.set(&apos;@metadata[tsprefix]&apos;, event.get(&apos;@timestamp&apos;).to_i.to_s(16))&quot;
}
</pre>Estos dos campos luego pueden usarse para generar un ID de documento en el plugin de salida de Elasticsearch:
<pre class="prettyprint">elasticsearch {
 document_id =&gt; &quot;%{[@metadata][tsprefix]}%{[@metadata][fingerprint]}&quot;
}
</pre>Esto dar&#xE1; como resultado un ID de documento con codificaci&#xF3;n hexadecimal y 40 caracteres de extensi&#xF3;n; por ejemplo, <code>4dad050215ca59aa1e3a26a222a9bbcaced23039</code>. Se puede hallar un ejemplo de configuraci&#xF3;n completo en <a href="https://gist.github.com/cdahlqvist/8ff8fb8e56c43414396edf60e7944144">este caso</a>.
<h2>Implicaciones para el rendimiento de la indexaci&#xF3;n</h2>El impacto que tiene usar diferentes clases de identificadores depender&#xE1; much&#xED;simo de tus datos, de tu hardware y del caso de uso. Si bien se pueden ofrecer algunas pautas generales, es importante hacer evaluaciones comparativas para determinar con exactitud el efecto que esto tiene en tu caso de uso.
Para que los resultados de indexaci&#xF3;n sean &#xF3;ptimos, la opci&#xF3;n m&#xE1;s eficaz siempre ser&#xE1; usar identificadores generados autom&#xE1;ticamente por Elasticsearch. Debido a que no se requieren verificaciones de actualizaci&#xF3;n, el rendimiento de la indexaci&#xF3;n no se modifica demasiado a medida que aumenta el tama&#xF1;o de los &#xED;ndices y los shards. Por lo tanto, se recomienda aplicar esto siempre que sea posible.
Para las verificaciones de actualizaci&#xF3;n debidas al uso de un ID externo se requerir&#xE1; acceso adicional al disco. El impacto de esto depende de la eficacia con que el sistema operativo pueda almacenar en cach&#xE9; los datos requeridos, de la velocidad del almacenamiento y del grado de efectividad con que pueda manejar lecturas aleatorias. La velocidad de indexaci&#xF3;n a menudo tambi&#xE9;n disminuye a medida que el tama&#xF1;o de los &#xED;ndices y los shards aumenta y que m&#xE1;s segmentos deben verificarse.
<h2>Uso de la API de rollover</h2>Los &#xED;ndices tradicionales basados en tiempo dependen de que cada &#xED;ndice abarque un per&#xED;odo de tiempo establecido espec&#xED;fico. Esto significa que los tama&#xF1;os de los &#xED;ndices y los shards pueden variar much&#xED;simo si los vol&#xFA;menes de datos fluct&#xFA;an con el tiempo. Los tama&#xF1;os de shards irregulares no se recomiendan y pueden ocasionar problemas de rendimiento.
La <a href="/guide/en/elasticsearch/reference/6.4/indices-rollover-index.html">API de &#xED;ndice de rollover</a> se introdujo para ofrecer una manera flexible de administrar &#xED;ndices basados en tiempo seg&#xFA;n varios criterios, no solo el del tiempo. Permite hacer una implementaci&#xF3;n en un &#xED;ndice nuevo una vez que el existente alcanza un tama&#xF1;o, una antig&#xFC;edad o un n&#xFA;mero de documentos espec&#xED;ficos. Esto hace posibles tama&#xF1;os de shards e &#xED;ndices m&#xE1;s predecibles.
Sin embargo, esto rompe el enlace entre la marca de tiempo de evento y el &#xED;ndice al que pertenece. Cuando los &#xED;ndices se basaban estrictamente en el tiempo, un evento siempre se destinaba al mismo &#xED;ndice, independientemente del momento en que llegaba. Este principio permite evitar duplicados usando identificadores externos. Por lo tanto, cuando se usa la API de rollover, ya no es posible evitar duplicados por completo, aunque la probabilidad se reduce. Es posible que dos eventos duplicados se reciban a ambos lados de una implementaci&#xF3;n y, por lo tanto, queden en diferentes &#xED;ndices aunque tengan la misma marca de tiempo. De esto no surgir&#xE1; una actualizaci&#xF3;n.
Por ello, no se recomienda usar una API de rollover si es un requisito estricto evitar duplicados.
<h2>Adaptaci&#xF3;n a vol&#xFA;menes de tr&#xE1;fico impredecibles</h2>Aun cuando no se pueda usar la API de rollover, hay maneras de adaptar y ajustar el tama&#xF1;o de los shards si los vol&#xFA;menes de tr&#xE1;fico fluct&#xFA;an y generan &#xED;ndices basados en tiempo demasiado peque&#xF1;os o grandes.
Si el tama&#xF1;o final de los shards es demasiado grande debido, por ejemplo, a un aumento s&#xFA;bito del tr&#xE1;fico, es posible usar la <a href="/guide/en/elasticsearch/reference/6.4/indices-split-index.html">API de &#xED;ndice dividido</a> para dividir el &#xED;ndice en un n&#xFA;mero m&#xE1;s grande de shards. Para esta API se debe aplicar un ajuste al crear el &#xED;ndice. Por ello, esto debe agregarse a trav&#xE9;s de una plantilla de &#xED;ndice.
Si los vol&#xFA;menes, por el contrario, son demasiado bajos y el tama&#xF1;o de los shards resultantes es anormalmente peque&#xF1;o, se puede usar la <a href="/guide/en/elasticsearch/reference/6.4/indices-shrink-index.html">API de &#xED;ndice de reducci&#xF3;n</a> para reducir el n&#xFA;mero de shards del &#xED;ndice.
<h2>Conclusiones</h2>Como viste en este blog, es posible evitar duplicados en Elasticsearch especificando un identificador de documento de manera externa antes de indexar datos en Elasticsearch. El tipo de estructura del identificador puede tener un impacto considerable en el rendimiento de la indexaci&#xF3;n. Esto, sin embargo, variar&#xE1; seg&#xFA;n el caso de uso y por ello se recomienda hacer una evaluaci&#xF3;n comparativa para identificar la opci&#xF3;n &#xF3;ptima para ti y tu situaci&#xF3;n espec&#xED;fica.
</body></html>

duplication_banner.jpg

duplication_thumb.jpg

Efficient Duplicate Prevention for Event-Based Data in Elasticsearch

Prevención eficaz de duplicados para datos basados en eventos en Elasticsearch

Sizing Hot-Warm Architectures for Logging and Metrics in the Elasticsearch Service on Elastic Cloud

Dimensionamiento de arquitecturas calientes-tibias para logging y métricas en Elasticsearch Service en Elastic Cloud

Introducción a Logstash que muestra cómo trabajar con este motor al desarrollar una configuración para el análisis y la ingesta de logs.

A Practical Introduction to Logstash

Introducción práctica a Logstash

¿Tiene dudas sobre cuándo usar Logstash y cuándo Ingest Node de Elasticsearch? Este blog guiará por la lista de cosas que debe tener en cuenta para su decisión.

<html><head></head><body>Logstash fue uno de los componentes originales de Elastic Stack y ha sido, durante mucho tiempo, la herramienta para analizar, enriquecer o procesar datos. Con los a&#xF1;os, se fueron agregando muchos complementos de entrada, salida y filtro, lo que la convirti&#xF3; en una herramienta bastante flexible y potente, apta para una variedad de arquitecturas diferentes.
Los nodos de ingesti&#xF3;n se presentaron con Elasticsearch 5.0 como una forma de procesar documentos en Elasticsearch antes de la indexaci&#xF3;n. Estos nodos permiten arquitecturas m&#xE1;s sencillas con una cantidad m&#xED;nima de componentes, en las que las aplicaciones env&#xED;an datos directamente a Elasticsearch para procesar e indexar. A menudo, esto simplifica el inicio con Elastic Stack, pero tambi&#xE9;n escala horizontalmente cuando los vol&#xFA;menes de datos aumentan.
Sin embargo, el nodo de ingesti&#xF3;n duplica algunas de las funcionalidades de Logstash, por lo que muchos usuarios preguntan con frecuencia cu&#xE1;l deben usar. En esta art&#xED;culo del blog, analizaremos los aspectos arquitect&#xF3;nicos que debes tener en cuenta a la hora de elegir entre los dos con el objetivo de ayudarte a tomar una decisi&#xF3;n mejor informada.
Esta es la tercera entrega de nuestra serie sobre preguntas frecuentes que tienen los usuarios. Las anteriores fueron:
<ul>
	<li><a href="/es/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster">&#xBF;Cu&#xE1;ntas particiones debo tener en mi cl&#xFA;ster de Elasticsearch?</a></li>
	<li><a href="/es/blog/why-am-i-seeing-bulk-rejections-in-my-elasticsearch-cluster">&#xBF;Por qu&#xE9; veo rechazos masivos en mi cl&#xFA;ster de Elasticsearch?</a></li>
</ul><h2>&#xBF;C&#xF3;mo entran y salen los datos?</h2>Una de las diferencias principales entre Logstash y el nodo de ingesti&#xF3;n es la forma en que los datos entran y salen.
A medida que el nodo de ingesti&#xF3;n se ejecuta dentro del flujo de indexaci&#xF3;n de Elasticsearch, los datos deben insertarse mediante solicitudes masivas o de indexaci&#xF3;n. Por lo tanto, debe haber un proceso que escriba datos activamente en Elasticsearch. Un nodo de ingesti&#xF3;n no puede extraer datos de una fuente externa, como una cola de mensajes o una base de datos.
Hay una restricci&#xF3;n similar despu&#xE9;s de que los datos se procesan: la &#xFA;nica opci&#xF3;n es indexar los datos localmente en Elasticsearch.
Por otro lado, Logstash cuenta con una amplia variedad de complementos de entrada y salida, y puede usarse para admitir diversas arquitecturas. Puede actuar como servidor y aceptar datos insertados por los clientes por TCP, UDP y HTTP, adem&#xE1;s de extraer datos activamente desde, por ejemplo, bases de datos y colas de mensajes. En lo que respecta a la salida de datos, hay una gran variedad de opciones disponibles, por ejemplo, colas de mensajes como Kafka y RabbitMQ o el archivo de datos a largo plazo en S3 o HDFS.
<h2>&#xBF;Qu&#xE9; hay de las colas y la contrapresi&#xF3;n?</h2>Al enviar datos a Elasticsearch, ya sea directamente o mediante una canalizaci&#xF3;n de ingesti&#xF3;n, los clientes necesitan poder resolver el caso cuando Elasticsearch no pueda aceptar m&#xE1;s datos. Esto es lo que denominamos aplicar contrapresi&#xF3;n. Si los nodos de datos no pueden aceptar datos, el nodo de ingesti&#xF3;n dejar&#xE1; de aceptar datos tambi&#xE9;n.
Las arquitecturas en las que no hay un mecanismo de cola incorporado a la canalizaci&#xF3;n de procesamiento, ya sea en la fuente o a lo largo del proceso, tienen el potencial de perder datos si no se puede acceder a Elasticsearch o este no puede aceptar datos durante un per&#xED;odo prolongado. Esto incluye Beats, que no puede almacenar ni leer datos desde el archivo, as&#xED; como otros procesos que pueden escribir datos directamente en Elasticsearch, como syslog-ng.
Logstash puede poner datos en cola en un disco mediante la funci&#xF3;n de <a href="https://www.elastic.co/guide/en/logstash/current/persistent-queues.html">colas persistentes</a>, lo que permite que Logstash ofrezca garant&#xED;as de entrega al menos una vez y almacene datos en b&#xFA;fer a nivel local durante los picos de ingesti&#xF3;n. Logstash tambi&#xE9;n admite la integraci&#xF3;n con diversos tipos de colas de mensajes, lo que permite contar con varios patrones de implementaci&#xF3;n compatibles.
<h2>&#xBF;C&#xF3;mo enriquezco y proceso mis datos?</h2>El nodo de ingesti&#xF3;n incluye m&#xE1;s de 20 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/master/ingest-processors.html">procesadores</a> diferentes que abarcan la funcionalidad de los complementos m&#xE1;s usados de Logstash. Sin embargo, una de las limitaciones es que la canalizaci&#xF3;n del nodo de ingesti&#xF3;n solo funciona en el contexto de un &#xFA;nico evento. Adem&#xE1;s, los procesadores en general no pueden comunicarse con otros sistemas ni leer datos del disco, lo que limita los tipos de enriquecimiento que pueden llevar a cabo.
Logstash cuenta con una selecci&#xF3;n significativamente m&#xE1;s grande de complementos para elegir. Esto incluye complementos para agregar o transformar contenido basado en b&#xFA;squedas en archivos de configuraci&#xF3;n, Elasticsearch o bases de datos relacionales.
Beats y Logstash tambi&#xE9;n permiten filtrar y anular eventos en funci&#xF3;n de criterios configurables, algo que no es posible actualmente en el nodo de ingesti&#xF3;n.
<h2>&#xBF;Cu&#xE1;l es m&#xE1;s f&#xE1;cil de configurar?</h2>Este es un tema muy subjetivo, y depende de tu experiencia y de lo que sueles hacer. Cada canalizaci&#xF3;n de nodo de ingesti&#xF3;n se define en un documento JSON que se almacena en Elasticsearch. Se puede definir una gran cantidad de canalizaciones diferentes, pero los documentos solo se pueden procesar por una sola cuando atraviesan el nodo de ingesti&#xF3;n. Este formato puede ser un poco m&#xE1;s f&#xE1;cil de usar que el formato de archivo de configuraci&#xF3;n de Logstash, al menos para canalizaciones bien definidas y razonablemente simples. Para canalizaciones m&#xE1;s complejas con m&#xFA;ltiples formatos de datos, el hecho de que Logstash admita el uso de condicionales para controlar el flujo suele facilitar su uso. Asimismo, Logstash admite la definici&#xF3;n de m&#xFA;ltiples <a href="https://www.elastic.co/guide/en/logstash/6.1/multiple-pipelines.html">canalizaciones separadas l&#xF3;gicamente</a>, que pueden administrarse <a href="https://www.elastic.co/guide/en/logstash/6.1/logstash-centralized-pipeline-management.html">a trav&#xE9;s de una interfaz de usuario basada en Kibana</a>.
Tambi&#xE9;n vale la pena mencionar que la medici&#xF3;n y la optimizaci&#xF3;n de la canalizaci&#xF3;n es generalmente m&#xE1;s f&#xE1;cil en Logstash, ya que este admite el monitoreo y ofrece una excelente <a href="https://www.elastic.co/guide/en/logstash/current/logstash-pipeline-viewer.html">interfaz de usuario (UI) de visualizaci&#xF3;n de la canalizaci&#xF3;n</a> que puede usarse para detectar atascos y problemas potenciales r&#xE1;pidamente.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltef55f367a4ce1443/5c307eefb2b2be79676e851a/pipeline_viewer.gif" data-sys-asset-uid="bltef55f367a4ce1443" alt="pipeline_viewer.gif">
<h2>&#xBF;C&#xF3;mo se ve afectado el consumo de recursos de hardware?</h2>Una de las mayores ventajas de los nodos de ingesti&#xF3;n es que admiten arquitecturas muy simples, en las que Beats puede escribir directamente en una canalizaci&#xF3;n de nodo de ingesti&#xF3;n. Cada nodo en un cl&#xFA;ster de Elasticsearch puede actuar como nodo de ingesti&#xF3;n, lo que permite acotar el consumo de recursos de hardware y simplificar la complejidad de la arquitectura, al menos para los casos de uso m&#xE1;s peque&#xF1;os.
Cuando los vol&#xFA;menes de datos aumentan o el procesamiento se vuelve m&#xE1;s complejo y se genera mayor carga de la CPU en el cl&#xFA;ster, generalmente se recomienda cambiar a nodos de ingesti&#xF3;n dedicados. En este punto, se necesita hardware adicional para alojar los nodos de ingesti&#xF3;n dedicados o Logstash, y cualquier diferencia en el consumo de recursos depender&#xE1;, en gran medida, del caso de uso.
<h2>&#xBF;Los nodos de ingesti&#xF3;n pueden hacer algo que Logstash no pueda?</h2>Hasta ahora, parece que los nodos de ingesti&#xF3;n solo ofrecen un subconjunto de la funcionalidad que admite Logstash, pero esto no es totalmente cierto.
Los nodos de ingesti&#xF3;n admiten el <a href="https://www.elastic.co/guide/en/elasticsearch/plugins/current/ingest-attachment.html">complemento de procesador de datos adjuntos de ingesti&#xF3;n</a>, que puede usarse para procesar e indexar datos adjuntos en formatos comunes, como PPT, XLS y PDF. Actualmente, no hay complementos equivalentes disponibles para Logstash, por lo que, si planeas indexar varios tipos de datos adjuntos, es posible que necesites un nodo de ingesti&#xF3;n.
Dado que la canalizaci&#xF3;n de ingesti&#xF3;n se ejecuta justo antes de la indexaci&#xF3;n de datos, es tambi&#xE9;n el m&#xE9;todo m&#xE1;s confiable para agregar una marca de tiempo que indique cu&#xE1;ndo se index&#xF3; el evento, por ejemplo, para medir y analizar las demoras de ingesti&#xF3;n de forma precisa. Configurar esto antes de que los datos lleguen correctamente a Elasticsearch puede resultar enga&#xF1;oso, ya que puede haber demoras entre la fijaci&#xF3;n de la marca de tiempo y la indexaci&#xF3;n de datos en Elasticsearch, por ejemplo, si se aplica contrapresi&#xF3;n o si el cliente se ve forzado a reintentar la indexaci&#xF3;n de los datos varias veces. Este tipo de marcas de tiempo puede usarse para medir la <a href="https://gist.github.com/cdahlqvist/e713b39f0c17d85e613f56408a7facd5">demora de ingesti&#xF3;n por documento</a>.
<h2>&#xBF;Puedo usar Logstash y el nodo de ingesti&#xF3;n en conjunto?</h2>Aunque la mayor&#xED;a de las veces se prefiere usar uno de ellos, naturalmente es posible usar ambos en conjunto, ya que <a href="https://www.elastic.co/guide/en/logstash/current/plugins-outputs-elasticsearch.html#plugins-outputs-elasticsearch-pipeline">Logstash admite el env&#xED;o de datos a una canalizaci&#xF3;n de ingesti&#xF3;n</a>. Para arquitecturas m&#xE1;s complejas puede haber m&#xFA;ltiples flujos l&#xF3;gicos con requisitos muy diferentes. Algunos pueden pasar por Logstash, mientras que otros se env&#xED;an directamente a los nodos de ingesti&#xF3;n de Elasticsearch. Usar el que tenga m&#xE1;s sentido para cada flujo de datos facilitar&#xE1; el mantenimiento de la arquitectura.
<h2>Conclusiones</h2>Hay cierta superposici&#xF3;n de funcionalidades entre Logstash y el nodo de ingesti&#xF3;n de Elasticsearch. Esto quiere decir que algunas arquitecturas pueden implementarse con cualquiera de estas tecnolog&#xED;as. Ambas opciones tienen sus ventajas y sus desventajas, por lo que es importante analizar los requisitos y la arquitectura de tu canalizaci&#xF3;n de procesamiento entera, y seleccionar la m&#xE1;s adecuada en funci&#xF3;n de los criterios expuestos en esta art&#xED;culo del blog. La elecci&#xF3;n no es siempre preferir una, ya que pueden usarse en conjunto o en paralelo para diferentes partes de la canalizaci&#xF3;n de procesamiento.
</body></html>

Should I use Logstash or Elasticsearch ingest nodes?

¿Debo usar Logstash o los nodos de ingestión de Elasticsearch?

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

headshot-christian-dahlquist-300x300.jpg

Solutions Architect

Christian Dahlqvist

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

The content on this page is not available in the selected language.

El contenido de esta página no está disponible en el idioma seleccionado. Elastic está trabajando para garantizar que el contenido esté disponible en varios idiomas. Gracias por tu paciencia mientras trabajamos.

By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_self">Terms of Service</a>, and you agree to receive the <a href="/legal/privacy-statement#how-we-use-the-information" target="_self">selected communications</a> at the contact details you provided above. See <a href="/legal/privacy-statement/" target="_self">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Communication Preferences - ONLY for /communication-preferences

Al enviar, confirma que ha leído y acepta nuestras <a href="/es/legal/elastic-cloud-account-terms" target="_self">Condiciones de servicio</a>, y que acepta recibir las <a href="/es/legal/privacy-statement#how-we-use-the-information" target="_self">comunicaciones seleccionadas</a> en los detalles de contacto que proporcionó anteriormente. Consulte la <a href="/es/legal/privacy-statement/" target="_self">Declaración de privacidad de Elastic</a> para obtener más información o para cancelar su suscripción en cualquier momento.

By submitting you acknowledge that you've read and agree to our <a href="/legal/serverless-preview-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Serverless GDPR Text

Al enviar, confirma que ha leído y acepta nuestras <a href="/es/legal/serverless-preview-terms" target="_self">Condiciones de servicio</a>, y que Elastic puede <a href="/es/legal/privacy-statement#how-we-use-the-information" target="_self">ponerse en contacto con usted</a> acerca de nuestros productos y servicios relacionados. Consulte la <a href="/es/legal/privacy-statement/" target="_self">Declaración de privacidad de Elastic</a> para obtener más información o para cancelar su suscripción en cualquier momento.

By submitting you agree to <a href="/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud Terms of Service</a>. Your personal data will be processed in accordance with <a href="/legal/privacy-statement">Elastic's Privacy Statement</a>.

Cloud Trial GDPR Text

Al enviar esta información, aceptas los <a href="/es/agreements/global/cloud-services-monthly" rel="nofollow">Términos de servicio de Elastic</a>. Los datos personales se procesarán de conformidad con la <a href="/es/legal/privacy-statement">declaración de privacidad de Elastic</a>.

By submitting you acknowledge that you've read and agree to our <a href="/legal/terms-of-use" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.

Newsletter GDPR Text

Al enviar, confirma que ha leído y acepta nuestras <a href="/es/legal/terms-of-use" target="_self">Condiciones de servicio</a>, y que Elastic puede <a href="/es/legal/privacy-statement#how-we-use-the-information" target="_self">ponerse en contacto con usted</a> acerca de nuestros productos y servicios relacionados. Consulte la <a href="/es/legal/privacy-statement/" target="_self">Declaración de privacidad de Elastic</a> para obtener más información o para cancelar su suscripción en cualquier momento.

Hosted by

All Solutions

Follow us on Youtube

Watch now (no PT)

Articles by

Share by Email

Filters

All (no PT translation)

Contact information

See when this webinar starts in my time zone

Ver cuándo comienza este webinar en mi zona horaria

Thank you for your interest!

Register to Attend

Small image for

Register to Watch

Continue reading

Featured webinar

What to explore next...

Reset all

Load more press releases

Sign In to Attend

Share

Upcoming webinar

Learn more

Search Integrations

Share on Reddit

Share on Twitter

Share on Facebook

Load more news

View more posts

On-demand webinar

Follow us on Facebook

Author

Press Release

You'll also receive an email with related content.

You'll also receive an email with related content

Además, te enviaremos contenidos relevantes

Print

Contact Info

Overview

Video for

Read less

Register now

Share this story

See All Posts

See all top stories

View next

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

¿No puedes asistir? Regístrate y te enviaremos la grabación. También recibirás un correo electrónico con contenido relacionado.

Follow us on LinkedIn

Highlights

Explore similar demos

Follow us on Twitter

Share on LinkedIn

Load More

See more insights

Speakers

Close

Thank you for registering. We will send you a confirmation email soon.

Gracias por registrarte. Te enviaremos un correo electrónico de confirmación pronto.

Author

Articles by Christian Dahlqvist

Solutions Architect, Elastic

¿Cuántos shards debo tener en mi cluster de Elasticsearch?

Prevención eficaz de duplicados para datos basados en eventos en Elasticsearch

Dimensionamiento de arquitecturas calientes-tibias para logging y métricas en Elasticsearch Service en Elastic Cloud

Introducción práctica a Logstash

¿Debo usar Logstash o los nodos de ingestión de Elasticsearch?