Este análisis profundo ahonda en los detalles de la migración a Elastic Common Schema (ECS) en un entorno de Beats e incluye un ejemplo de migración.

migrating-ecs-fullbleed.jpg

migrating-ecs-thumbnail.jpg

Migrating to Elastic Common Schema in Beats environments

Migración a Elastic Common Schema (ECS) en ambientes de Beats

<p>Presentamos el Elastic Common Schema (ECS), una nueva especificación que proporciona una manera coherente y personalizable de estructurar tus datos en Elasticsearch y facilitar el análisis de datos de diferentes fuentes. Con ECS, el contenido de analíticas, como los dashboards y los trabajos de Machine Learning, pueden aplicarse de manera más amplia, las búsquedas pueden diseñarse de manera más limitada y los nombres de campo son más fáciles de recordar.
</p>
<h2>¿Por qué un esquema común (Common Schema)?</h2>
<p>Ya sea que estés haciendo un análisis interactivo (por ejemplo, búsqueda, exploración profunda con dinamización, visualización) o un análisis automatizado (por ejemplo: alertas, detección de anomalías basada en Machine Learning), debes poder examinar tus datos de manera uniforme. Sin embargo, a menos que tus datos se originen en una sola fuente, te enfrentarás a incoherencias de formato, que son el resultado de lo siguiente:
</p>
<ul>
	<li>Tipos de datos dispares (por ejemplo: logs, métricas, APM, flujos, datos contextuales)</li>
	<li>Entornos heterogéneos con diversos estándares de proveedores</li>
	<li>Fuentes de datos similares, pero diferentes (por ejemplo: fuentes múltiples de datos del punto de conexión, como <a href="/es/beats/auditbeat">Auditbeat</a>, Cylance y Tanium)</li>
</ul>
<p>Imagina que buscas un usuario específico entre los datos que se originan de fuentes múltiples. Solo para buscar este campo, es probable que debas tener en cuenta varios nombres de campo, como el <code>usuario</code>, el <code>nombre de usuario</code>, <code>nginx.access.user_name</code> y el <code>inicio de sesión</code>. Hacer una búsqueda profunda y optimizar esos datos presentaría un desafío aún mayor. Ahora, imagina el desarrollo de contenido de analíticas, como una visualización, una alerta o un trabajo de Machine Learning: cada nueva fuente de datos agregaría complejidad o duplicación.
</p>
<h3>¿Qué es el Elastic Common Schema?</h3>
<p>ECS es una especificación de open source que define un conjunto común de campos de documentos para los datos ingestados en Elasticsearch. ECS está diseñado para admitir modelos de datos uniformes, lo que le permite analizar de forma centralizada datos de diversas fuentes con técnicas interactivas y automatizadas.
</p>
<p>ECS ofrece tanto la previsibilidad de una taxonomía especialmente diseñada como la versatilidad de una especificación inclusiva que se adapta a casos de uso personalizados. La taxonomía de ECS distribuye elementos de datos en campos que están organizados en estos tres niveles:
</p>
<table>
<tbody>
<tr>
	<td style="background-color: rgb(223, 223, 223);"><strong>Nivel</strong>
	</td>
	<td style="background-color: rgb(223, 223, 223);"><strong>Descripción</strong>
	</td>
	<td style="background-color: rgb(223, 223, 223);"><strong>Recomendación</strong>
	</td>
</tr>
<tr>
	<td><strong>Campos centrales de ECS</strong>
	</td>
	<td>Conjunto de nombres de campo totalmente definido que existe bajo un conjunto definido de objetos de nivel superior de ECS
	</td>
	<td>Estos campos son comunes a la mayoría de los casos de uso, por lo que el trabajo debe comenzar aquí
	</td>
</tr>
<tr>
	<td><strong>Campos extendidos de ECS</strong>
	</td>
	<td>Conjunto de nombres de campo parcialmente definido que existe bajo el mismo conjunto de objetos de nivel superior de ECS
	</td>
	<td>Los campos extendidos pueden aplicarse a casos de uso más limitados o estar más abiertos a la interpretación según el caso de uso
	</td>
</tr>
<tr>
	<td><strong>Campos personalizados</strong>
	</td>
	<td>Conjunto de campos sin definir y sin nombrar que existe bajo un conjunto de objetos de nivel superior proporcionado por el usuario, que no son de ECS ni deben entrar en conflicto con los campos u objetos de ECS
	</td>
	<td>Aquí es donde puedes agregar campos para los que ECS no tenga un campo correspondiente; aquí también puedes guardar una copia de los campos de eventos originales, como cuando haces la transición de tus datos a ECS
	</td>
</tr>
</tbody>
</table>
<h2>Elastic Common Schema en acción</h2>
<h3>Ejemplo 1: Análisis</h3>
<p>Pongamos a ECS a trabajar en el siguiente log de Apache:
</p>
<pre class="prettyprint">10.42.42.42 - - [07/Dec/2018:11:05:07 +0100] "GET /blog HTTP/1.1" 200 2571 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36"
</pre>
<p>El mapeo de este mensaje a ECS organiza los campos del log de la siguiente manera:
</p>
<table>
<tbody>
<tr>
	<td style="background-color: rgb(223, 223, 223);" width="25%"><strong>Nombre del campo</strong>
	</td>
	<td style="background-color: rgb(223, 223, 223);" width="38%"><strong>Valor</strong>
	</td>
	<td style="background-color: rgb(223, 223, 223);" width="37%"><strong>Notas</strong>
	</td>
</tr>
<tr>
	<td>@timestamp
	</td>
	<td><code>2018-12-07T11:05:07.000Z</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>ecs.version
	</td>
	<td><code>1.0.0</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>event.dataset
	</td>
	<td><code>apache.access</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>event.original
	</td>
	<td><code>10.42.42.42 - - [07/Dec ...</code>
	</td>
	<td>Log completo y sin modificaciones para auditorías&nbsp;
	</td>
</tr>
<tr>
	<td>http.request.method
	</td>
	<td><code>get</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>http.response.body.bytes
	</td>
	<td><code>2571</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>http.response.status_code
	</td>
	<td><code>200</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>http.version
	</td>
	<td><code>1.1</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>host.hostname
	</td>
	<td><code>webserver-blog-prod</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>message
	</td>
	<td><code>"GET /blog HTTP/1.1" 200 2571</code>
	</td>
	<td>Representación de texto de la información significativa del evento para una visualización precisa en un visualizador de logs
	</td>
</tr>
<tr>
	<td>service.name
	</td>
	<td><code>Company blog</code>
	</td>
	<td>Tu nombre personalizado para este servicio
	</td>
</tr>
<tr>
	<td>service.type
	</td>
	<td><code>apache</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>source.geo.*
	</td>
	<td>
	</td>
	<td>Fields for geolocation
	</td>
</tr>
<tr>
	<td>source.ip
	</td>
	<td><code>10.42.42.42</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>url.original
	</td>
	<td><code>/blog</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>user.name
	</td>
	<td><code>-</code>
	</td>
	<td>
	</td>
</tr>
<tr>
	<td>user_agent.*
	</td>
	<td>
	</td>
	<td>Campos que describen al agente usuario
	</td>
</tr>
</tbody>
</table>
<p>Como se muestra arriba, el log sin procesar se preserva en el campo <code>event.original</code> de ECS para admitir casos de uso de auditorías. Además, ten en cuenta que por una cuestión de simplicidad, en este ejemplo se omiten algunos detalles sobre el agente de monitoreo (en el campo <code>agent.*</code>), algunos detalles sobre el host (en el campo <code>host.*</code>) y algunos campos más. Para obtener una representación más completa, revisa este <a href="https://gist.github.com/webmat/fc4902a61abf1cacbd5b717f1a3a6935">evento de ejemplo en JSON</a>.
</p>
<h3>Ejemplo 2: Búsqueda</h3>
<p>Piensa en una investigación sobre la actividad de una IP específica a través de una pila web completa: Un firewall de Palo Alto Networks, HAProxy (como lo procesa Logstash), Apache (mediante el módulo Beats), Elastic APM y además, Suricata IDS (personalizado, con su formato EVE JSON).
</p>
<p>Antes de ECS, tu búsqueda para esta IP podría haberse visto así:
</p>
<pre class="prettyprint">src:10.42.42.42 OR client_ip:10.42.42.42 OR apache2.access.remote_ip:10.42.42.42 OR context.user.ip:10.42.42.42 OR src_ip:10.42.42.42
</pre>
<p>Pero si has mapeado todas tus fuentes a ECS, tu búsqueda es mucho más simple:
</p>
<pre class="prettyprint">source.ip:10.42.42.42
</pre>
<h3>Ejemplo 3: Visualización</h3>
<p>El poder de ECS se revela de forma más fácil al ver cómo se puede aplicar a datos uniformemente normalizados de diversas fuentes de datos. Quizás estás monitoreando tu pila web en busca de amenazas con varias fuentes de datos de red: un firewall de Palo Alto de la nueva generación en el perímetro y los eventos y alertas de generación de Suricata IDS. ¿Cómo extraes los campos <code>source.ip</code> y <code>network.direction</code> de cada mensaje de manera tal que permita la visualización centralizada en Kibana y una exploración profunda con dinamización independiente? Con ECS, por supuesto, que te permite hacer un monitoreo centralizado con más facilidad que nunca.
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt71256f06dc672546/5c98d595975fd58f4d12646d/ecs-intro-dashboard-1360.jpg" data-sys-asset-uid="blt71256f06dc672546" alt="Búsqueda de direcciones IP en Kibana mediante Elastic Common Schema" "="">
</p><figcaption>Búsqueda de IP 10.42.42.42</figcaption>
<h2>Beneficios del Elastic Common Schema</h2>
<p>La implementación de ECS unifica todos los modos de análisis disponibles en el Elastic Stack, incluida la búsqueda, la exploración profunda con dinamización, la visualización de datos, la detección de anomalías basada en Machine Learning y las alertas. Una vez que se adopta completamente, los usuarios pueden hacer búsquedas con el poder de los parámetros de búsqueda estructurados y no estructurados. Además, ECS optimiza tu capacidad de correlacionar automáticamente los datos de diferentes fuentes, ya sea de dispositivos diferentes de un solo proveedor o de tipos de fuentes de datos completamente diferentes.
</p>
<p>ECS también reduce la cantidad de tiempo que tu equipo dedica al desarrollo de contenido de analíticas. En lugar de crear nuevas búsquedas y dashboards cada vez que tu organización agregue una nueva fuente de datos, podrán continuar aprovechando sus búsquedas y dashboards existentes. ECS también le facilitará enormemente a tu entorno la adopción de contenido de analíticas directamente de otras partes que usan ECS, ya sea Elastic, un socio o un proyecto de open source.
</p>
<p>Al hacer un análisis interactivo, ECS hace que sea más fácil recordar nombres de campo usados comúnmente, ya que hay un solo conjunto, en lugar de un conjunto diferente para cada fuente de datos. Con ECS, también es más fácil deducir nombres de campo olvidados, porque (salvo pocas excepciones) la especificación sigue una convención de nomenclatura simple y estándar.
</p>
<p>¿No quieres comenzar a adoptar ECS? No hay problema: estará aquí cuando lo necesites, pero no será un requisito si no lo necesitas.
</p>
<h2>Primeros pasos con el Elastic Common Schema</h2>
<p>ECS está disponible para revisión a través de un <a href="https://github.com/elastic/ecs">repositorio público de GitHub</a>. Actualmente, la especificación está en versión Beta2 y pronto estará disponible para el público en general. Está publicado bajo la licencia de open source de Apache 2.0, lo que permite la adopción universal por parte de la comunidad de Elastic en general.
</p>
<p><strong></strong>
</p>
<p>Suena automágico, ¿verdad? Bien, como con cualquier esquema, la implementación de ECS no es una tarea trivial. Pero si ya has configurado una plantilla de índice de Elasticsearch y has escrito algunas funciones de transformación con el nodo de ingesta de Logstash o Elasticsearch, tendrás cierta noción de lo que esto implica. Las versiones futuras de los módulos Elastic Beats producirán eventos con el formato de ECS de manera predeterminada y optimizarán esta parte de la transición. El nuevo <a href="/es/blog/introducing-auditbeat-system-module">módulo de sistemas para Auditbeat</a> es el primero de muchos.
</p>
<p>Para obtener más información sobre ECS, puedes ver nuestro seminario web <a href="/es/webinars/introducing-the-elastic-common-schema">Elastic Common Schema (ECS)</a>. En próximos artículos del blog, veremos cómo mapear tus datos a ECS (incluidos los campos que no están definidos en el esquema) y las estrategias para migrar a ECS.
</p>
<h2>Obtén más información</h2>
<ul>
	<li><a href="/es/blog/migrating-to-elastic-common-schema-in-beats-environments">Migración a Elastic Common Schema (ECS) en ambientes de Beats</a></li>
</ul>

AUTHOR

Articles by Mathieu Martin

Migración a Elastic Common Schema (ECS) en ambientes de Beats

Presentamos el Elastic Common Schema

Productos

Compañía

Recursos

Soluciones

Elastic (ELK) Stack

NUEVO

AUTHOR

Articles by Mathieu Martin

Migración a Elastic Common Schema (ECS) en ambientes de Beats

Presentamos el Elastic Common Schema