Ingeniería

Aprendizaje automático para logs de Nginx: Identificar problemas operativos en su sitio web

Obtener información de los archivos de log de nginx puede ser complicado. Este artículo del blog muestra cómo se puede usar el aprendizaje automático para extraer información operativa a partir de grandes volúmenes de datos de log de nginx.

Descripción general

La ciencia de los datos puede ser un proceso complicado y experimental en el que puede ser muy fácil perderse en los datos o en la complejidad de las estadísticas. Por lo tanto, un objetivo clave de diseño para el grupo de aprendizaje automático en Elastic es desarrollar herramientas que permitan a un amplio espectro de usuarios obtener información a partir de los datos de Elasticsearch.

Esto nos llevó a desarrollar funciones como los asistentes de «trabajo de métrica única» y «trabajo de múltiples métricas» en el aprendizaje automático de X-Pack, y estamos planeando simplificar los pasos de análisis y configuración aún más en las próximas versiones.

En paralelo a estos asistentes, también pensamos en desarrollar configuraciones de trabajos predefinidas para fuentes de datos comunes como Beats y Logstash. Por ejemplo, si está reuniendo datos con el módulo NGINX de Filebeat, podemos ofrecer un conjunto de configuraciones y visualizaciones preconstruidas para ayudar a los usuarios a aplicar el aprendizaje automático a sus datos. Estas configuraciones, además, tienen como objetivo mostrar cómo desarrollamos configuraciones de aprendizaje automático internamente considerando nuestra experiencia. Ayúdenos a priorizar el siguiente conjunto de módulos que debería incluir tareas de aprendizaje automático preconfiguradas al completar esta breve encuesta.

Trataremos los detalles de cómo instalar estas configuraciones en un artículo del blog más adelante. El objetivo de este blog es describir los casos de uso y las configuraciones.

Notas sobre casos de uso

Las opciones de configuración para el aprendizaje automático de X-Pack son amplias, y, a menudo, los nuevos usuarios caen en la tentación de comenzar con configuraciones complejas y seleccionar grandes cantidades de atributos y series. Estos tipos de configuraciones pueden ser muy potentes y expresivos, pero es necesario ser cuidadoso, ya que los resultados pueden ser difíciles de interpretar. Por ende, recomendamos a los usuarios que comiencen con casos de uso simples y bien definidos, y que aumenten la complejidad a medida que se van familiarizando con el sistema. (Nota: A menudo, los mejores casos de uso iniciales se originan con la detección automática de anomalías en los gráficos de las visualizaciones centrales de los equipos de Operaciones).

Descripción de los datos de ejemplo

Los datos usados en estos ejemplos provienen de un sistema de producción que consiste en 4 servidores web nginx en balanceo de carga. Analizamos datos de 3 meses (aprox. 29 000 000 eventos, aprox. 1 100 000 de visitantes únicos, aprox. 29 GB de datos). Tenga en cuenta que los datos se anonimizaron.

Formato del registro de nginx:

'"$http_x_forwarded_for" $remote_addr - [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"';

Log de muestra:

"2021:0eb8:86a3:1000:0000:9b3e:0370:7334 10.225.192.17 10.2.2.121" - - [30/Dec/2016:06:47:09 +0000] "GET /test.html HTTP/1.1" 404 8571 "-" "Mozilla/5.0 (compatible; Facebot 1.0; https://developers.facebook.com/docs/sharing/webmasters/crawler)"

Tras el procesamiento por parte de la configuración del módulo NGINX de Filebeat, obtenemos el siguiente documento JSON en Elasticsearch:

… { "nginx" : { "access" : { "referrer" : "-", "response_code" : "404", "remote_ip" : "2021:0eb8:86a3:1000:0000:9b3e:0370:7334", "geoip" : { "continent_name" : "Europe", "country_iso_code" : "PT", "location" : { "lon" : -10.23057, "lat" : 34.7245 } }, "method" : "GET", "user_name" : "-", "http_version" : "1.1", "body_sent" : { "bytes" : "8571" }, "remote_ip_list" : [ "2021:0eb8:86a3:1000:0000:9b3e:0370:7334", "10.225.192.17", "10.2.2.121" ], "url" : "/test.html", "user_agent" : { "major" : "1", "minor" : "0", "os" : "Other", "name" : "Facebot", "os_name" : "Other", "device" : "Spider" } } } }...

Caso de uso 1: Cambios en el número de visitantes del sitio web

Desde el punto de vista operativo, los problemas de sistema a menudo se reflejan en cambios en la tasa de visitantes. Por ejemplo, si la tasa de visitantes decrece significativamente en un período breve, es posible que haya un problema de sistema en el sitio. Una forma sencilla de comprender los cambios en la tasa de visitantes es analizar la tasa de logs generales o la tasa de diferentes visitantes.

Tarea 1.1: Número bajo de visitantes del sitio web

Esta tarea puede configurarse de manera simple con el asistente de «tarea de métrica única»: Número bajo de visitantes del sitio web

Resumen de configuración de la tarea:

Configuración de número bajo de visitantes del sitio web

Este análisis indica una anomalía significativa el 27 de febrero; la tasa total del evento cae de forma abrupta:

Anomalías de número bajo de visitantes del sitio web

(Nota: Este análisis de los 29 000 000 eventos tomó un total de 16 s en una instancia m4.large de AWS).

Tarea 1.2: Número bajo de visitantes únicos del sitio web

Los conteos de eventos pueden verse influenciados por bots o ataques, por lo que es necesario contar con una función más coherente para analizar la cantidad de visitantes únicos del sitio web. Nuevamente, esto puede configurarse de manera simple con el asistente de «tarea de métrica única»:

Número bajo de visitantes únicos del sitio web

Una vez más, hay una anomalía significativa el 27 de febrero: la cantidad de visitantes únicos por 15 m cae de la cifra típica de 1487 a 86:

!Anomalías de número bajo de visitantes únicos del sitio web

Combinación de las tareas 1.1 y 1.2

Con el explorador de anomalías Anomaly Explorer, los resultados de ambas tareas se pueden correlacionar temporalmente para lograr una vista general de la anomalía de acuerdo con estas funciones:

Anomaly Explorer

e aprecia claramente en una vista única que hubo una anomalía significativa el 27 de febrero entre las 10:00 y las 12:00, cuando la tasa total de eventos cayó, al igual que la cantidad de visitantes únicos.

El equipo de Operaciones confirmó que el sitio presentó problemas graves durante este período, debido a un cambio en la configuración anterior de la red de distribución de contenidos (CDN). Desafortunadamente, no detectaron el impacto sobre los usuarios hasta las 11:30 (debido a que varios usuarios internos de Slack presentaron sus quejas), mientras que, con ML, hubieran recibido una alerta a las 10:00, cuando ocurrió el problema.

Este análisis puede combinarse con alertas para ofrecer a los equipos operativos información de cambios en el comportamiento del sistema a tiempo.

Caso de uso 2: Cambios en el comportamiento del sitio web

Una vez que se analizan los comportamientos simples, a menudo los siguientes pasos implican analizar funciones más complejas. Por ejemplo, los cambios en las tasas de eventos de los diferentes códigos de estado HTTP que arroja el servidor web con frecuencia pueden indicar cambios en el comportamiento del sistema o clientes inusuales:

Códigos de estado HTTP con el tiempo

Este caso de uso es más complejo, ya que implica analizar múltiples series en simultáneo, pero puede configurarse de manera simple con el asistente de «tarea de múltiples métricas»:

Análisis de códigos de estado HTTP

Los resultados muestran algunos cambios significativos en los diferentes códigos de respuesta:

Anomalías en los códigos de estado HTTP

En particular, nuevamente el 27 de febrero, hay un cambio significativo en el comportamiento de los códigos de respuesta 404, 301, 306 y 200. Si observamos más de cerca los códigos 404, podemos ver algunas anomalías significativas:

Anomalías en los códigos de estado HTTP

La primera anomalía destacada se atribuye a una dirección IP específica, ya que nginx.access.remote_ip se define como «influenciador» (más sobre esto en otro artículo del blog). La segunda anomalía destacada representa un cambio general significativo en el comportamiento de 404.

El aumento de 404 el 27 de febrero fue un nuevo dato para el equipo de Operaciones, y representó una gran cantidad de enlaces rotos que se habían introducido por el cambio en la configuración.

Caso de uso 3: Clientes inusuales

Generalmente, el tráfico del sitio web consiste en una combinación de uso normal, escaneo de bots e intentos de actividad maliciosa. Si suponemos que la mayoría de los clientes son normales, podemos usar el análisis de población para detectar ataques o actividad de bots significativos.

La cantidad de páginas que un usuario normal solicita en un período de 5 minutos puede verse limitada por la velocidad en que puede hacer clic manualmente en una página del sitio web. Los procesos automatizados pueden escanear miles de páginas por minuto, y los atacantes pueden, simplemente, inundar un sitio con solicitudes.

Existe una cantidad de funciones que podemos usar para diferenciar los tipos de tráfico, pero, en primera instancia, la tasa de eventos y la cantidad de URL distintas por cliente pueden ser indicios de actividad de clientes inusuales.

En este caso, la configuración avanzada de tareas se usa para ajustar tareas de 2 poblaciones:

Configuración del análisis de población

Tarea 3.1: Detectar IP remotos inusuales, alta tasa de solicitudes

Al observar una tasa inusualmente alta de eventos de un cliente (nginx_access_remote_ip_high_count), notamos lo siguiente:

Detectar IP remotos inusuales, alta tasa de solicitudes

Esto muestra un número de clientes anómalos. Por ejemplo, 185.78.31.85 parece ser anómalo después de un período extenso:

Detectar IP remotos inusuales, alta tasa de solicitudes

Analizar una visualización que resume esta interacción:

Detectar IP remotos inusuales, alta tasa de solicitudes

Esto muestra que esta dirección IP ha seleccionado una gran cantidad de veces la URL raíz (/) en un período breve, y que este comportamiento se repitió durante varios días.

Tarea 3.2: Detectar IP remotos inusuales, alta tasa de solicitudes

Al observar una tasa inusualmente alta de eventos de un cliente (nginx_access_remote_ip_high_dc_url), notamos lo siguiente:

!Detectar IP remotos inusuales, alta tasa de solicitudes

Nuevamente, esto indica un número de clientes inusuales. Si observamos 72.57.0.53, muestra que un cliente accedió a >12 000 URL diferentes en un período breve.

Detectar IP remotos inusuales, alta tasa de solicitudes

Analizar una visualización que resume esta interacción:

Esto indica que este cliente está intentando acceder a una inusual cantidad de URL, lo que coincide con tipos de ataque de directorio transversal.

Detectar IP remotos inusuales, alta tasa de solicitudes

Estas tareas ofrecen visibilidad en tiempo real respecto de clientes inusuales que acceden al sitio web. El tráfico web a menudo es manipulado por bots y atacantes, y diferenciar a estos clientes puede ayudar a los administradores a comprender comportamientos como los siguientes:

  • A qué tipos de ataques está sujeto el sitio
  • Si los bots pueden acceder al sitio completo
  • Qué es el uso «normal»

Resumen

Este artículo del blog intenta mostrar cómo X-Pack ML puede ofrecer información con respecto al comportamiento del sitio web. En las siguientes versiones de Elastic Stack, estos tipos de configuraciones y visualizaciones estarán disponibles para usuarios finales como paquetes de fácil instalación. Esto permitirá que los usuarios cuenten con configuraciones comprobadas y, además, les mostrará los tipos de configuraciones recomendados para copiar y extender.