Servicio Amazon OpenSearch (sucesor de Amazon Elasticsearch Service) admite un motor de detección de anomalías integrado de alto rendimiento que permite la identificación en tiempo real de anomalías en la transmisión de datos. El año pasado lanzamos detección de anomalías de alta cardinalidad (HCAD) para detectar anomalías de entidades individuales. Con la versión 1.1, le permitimos monitorear un millón de entidades con un rendimiento constante y predecible. HCAD es más fácil cuando se describe en contraste con la solución de flujo único que no es HCAD. En un detector de flujo único, detectamos anomalías para una entidad agregada. Por ejemplo, podemos usar un detector de flujo único para filtrar el tráfico agregado en todas las direcciones IP para que los usuarios puedan ser notificados cuando ocurran picos inusuales. Sin embargo, a menudo necesitamos identificar anomalías en entidades, como hosts individuales y direcciones IP. Cada entidad puede trabajar sobre una línea base diferente, lo que significa que la distribución de sus series temporales (medidas en parámetros como magnitud, tendencia y estacionalidad, por mencionar algunos) es diferente. Las diferentes líneas de base hacen que sea impreciso detectar anomalías utilizando un solo modelo monolítico. HCAD se distingue de los detectores de flujo único al personalizar los modelos de detección de anomalías para las entidades.

Ejemplos de casos de uso de HCAD incluyen los siguientes:

• Internet de las cosas – Hacer un seguimiento continuo de la temperatura de los frigoríficos y advertir a los usuarios de las temperaturas en las que la longevidad de los alimentos o medicamentos está en riesgo, para que los usuarios puedan tomar medidas para evitarlas. Cada entidad tiene campos categóricos específicos que la describen, y puede pensar en los campos categóricos como características de esas entidades. El número de serie de un frigorífico es el campo categórico que identifica de forma única los frigoríficos. Usar un solo modelo genera muchas falsas alarmas porque las temperaturas ambientales pueden ser diferentes. Una temperatura de 5 °C es normal durante el invierno en Seattle, EE. UU., pero tal temperatura en un lugar tropical durante el invierno probablemente sea anómala. Además, los usuarios pueden abrir la puerta de un refrigerador varias veces, provocando un aumento en la temperatura. La duración y la frecuencia de los picos pueden variar según el comportamiento del usuario. HCAD puede agrupar datos de temperatura en geografías y usuarios para detectar temperaturas locales variables y el comportamiento del usuario.
• Seguridad – Un sistema de detección de intrusos que identifique un aumento de intentos fallidos de inicio de sesión en los registros de autenticación. El nombre de usuario y la IP del host son los campos categóricos que se utilizan para determinar el usuario que accede desde el host. Los piratas informáticos pueden adivinar las contraseñas de los usuarios por fuerza bruta, y no todos los usuarios en la misma IP de host pueden ser el objetivo. La cantidad de recuentos de inicios de sesión fallidos varía en un host para un usuario en particular en un momento específico del día. HCAD crea una línea de base representativa por usuario en cada host y se adapta a los cambios en la línea de base.
• Operaciones de TI – Supervisión del tráfico de acceso por casco en un servicio distribuido. El ID de fragmento es el campo categórico y la entidad es el fragmento. Un sistema distribuido moderno generalmente consta de fragmentos vinculados entre sí. Cuando un fragmento experimenta una interrupción, el tráfico aumenta significativamente para los fragmentos dependientes debido a reintentar tormentas. Es difícil descubrir el aumento porque solo se ve afectada una cantidad limitada de fragmentos. Por ejemplo, el tráfico en los fragmentos relacionados puede ser hasta 64 veces superior a los niveles normales, mientras que el tráfico promedio en todos los fragmentos puede crecer en un pequeño factor constante (menos de 2).

Hacer que HCAD funcione en tiempo real y al mismo tiempo lograr la integridad y la escalabilidad es un desafío formidable:

• Integridad – Modelar todas o tantas entidades como sea posible.
• Escalabilidad – Escalado horizontal y vertical sin cambiar la fidelidad del modelo. Es decir, al aumentar o reducir la escala de la máquina, un detector de anomalías puede agregar modelos de forma monótona. HCAD usa el mismo modelo y da la misma respuesta para la serie temporal de una entidad que en la detección de flujo único.
• Rendimiento – Bajo impacto en el uso de recursos del sistema y alto rendimiento general.

La primera versión de HCAD en Amazon OpenSearch Service intercambió integridad y escalabilidad por rendimiento: el detector de anomalías limitó la cantidad de entidades a 1,000. Puede cambiar la configuración plugins.anomaly_detection.max_entities_per_query para aumentar el número de entidades monitoreadas por intervalo. Sin embargo, dicho cambio incurre en un costo no despreciable, lo que abre la puerta a la inestabilidad de los clústeres. Cada entidad utiliza memoria para albergar modelos, E/S de disco para leer y escribir puntos de control de modelos y resultados de anomalías, ciclos de CPU para mantenimiento de metadatos y capacitación e inferencia de modelos, y recolección de elementos no utilizados para modelos y metadatos eliminados. Cuantas más entidades, más uso de recursos. Además, HCAD podría sufrir una explosión combinatoria de entidades al admitir múltiples campos categóricos (una función lanzada en Amazon OpenSearch Service 1.1). Imagine un detector con una sola geolocalización de campo categórico. La geolocalización tiene 1,000 valores posibles. Agregar otro producto de campo categórico con 1,000 valores permitidos le da al detector 1 millón de entidades.

Para la próxima versión de HCAD, dedicamos mucho esfuerzo a mejorar la integridad y la escalabilidad. Nuestro enfoque captura el tamaño correcto de un clúster y combina el alojamiento de modelos en memoria y la carga de modelos en disco. Las métricas de rendimiento muestran que HCAD no satura el clúster con un costo sustancial y aún deja mucho espacio para otras tareas. Como resultado, HCAD puede analizar un millón de entidades en 10 minutos y marcar anomalías en diferentes patrones. En esta publicación, exploraremos cómo HCAD puede analizar un millón de entidades y las implementaciones técnicas detrás de las mejoras.

Cómo dimensionar dominios

La administración de modelos es una compensación: las soluciones basadas en disco que recargan, usan, detienen y almacenan modelos en cada intervalo ofrecen ahorros en memoria pero sufren una gran sobrecarga y son difíciles de escalar. Las soluciones basadas en memoria ofrecen una sobrecarga más baja y un mayor rendimiento, pero normalmente aumentan los requisitos de memoria. Aprovechamos la compensación mediante la implementación de un mecanismo adaptativo que aloja modelos en la memoria tanto como está permitido (limitado a través de la configuración del clúster plugins.anomaly_detection.model_max_size_percent), según lo requiera el mejor rendimiento. Cuando los modelos no caben en la memoria, procesamos solicitudes de modelos adicionales cargando modelos desde discos.

El uso de la memoria siempre que sea posible es responsable de la escalabilidad de HCAD. Por lo tanto, es crucial dimensionar correctamente un clúster para ofrecer suficiente memoria para HCAD. Los principales factores a considerar al dimensionar un clúster son:

• Suma del recuento total de entidades de todos los detectores – El recuento total de entidades de un detector es la cardinalidad de los campos categóricos. Si hay varios campos categóricos, el número cuenta todas las combinaciones únicas de valores de estos campos presentes en los datos. Puede decidir la cardinalidad a través de agregación de cardinalidad en el servicio de búsqueda abierta de Amazon. Si el detector es un detector de flujo único, el número de entidades es uno porque no hay un campo categórico definido.
• Tamano de la pila – Amazon OpenSearch Service reserva el 50 % de la RAM para el montón. Para determinar el tamaño de almacenamiento dinámico de un tipo de instancia, consulte Servicio Amazon OpenSearch
  cotización . Por ejemplo, un host r5.2xlarge tiene 64 GB de RAM. Por lo tanto, el tamaño de almacenamiento dinámico del host es de 32 GB.
• Porcentaje máximo de memoria de detección de anomalías (AD) – AD puede usar hasta el 10 % del montón de forma predeterminada. Puede personalizar el porcentaje a través de la configuración del clúster plugins.anomaly_detection.model_max_size_percent. La siguiente actualización permite que AD use la mitad del montón a través de la configuración mencionada anteriormente:

PUT /_cluster/settings
{ "persistent": { "plugins.anomaly_detection.model_max_size_percent": "0.5" }
}

• Tamaño del modelo en memoria de la entidad – El tamaño del modelo en memoria de una entidad varía según tamaño de la teja, la cantidad de funciones y la versión de Amazon OpenSearch Service, ya que estamos mejorando constantemente. Todos los modelos de entidad de la misma configuración de detector en la misma versión de software tienen el mismo tamaño. Una forma segura de obtener el tamaño es ejecutar una API de perfil en la misma configuración de detector en un clúster experimental antes de crear un clúster de producción. En el siguiente caso, cada modelo de entidad del detector fkzfBX0BHok1ZbMqLMdu tiene un tamaño de 470,491 XNUMX bytes:

Ingrese la siguiente solicitud de perfil:

GET /_plugins/_anomaly_detection/detectors/fkzfBX0BHok1ZbMqLMdu/_profile/models

Obtenemos la siguiente respuesta:

{ ...{ "model_id": "fkzfBX0BHok1ZbMqLMdu_entity_GOIubzeHCXV-k6y_AA4K3Q", "entity": [{ "name": "host", "value": "host141" }, { "name": "process", "value": "process54" } ], "model_size_in_bytes": 470491, "node_id": "OcxBDJKYRYKwCLDtWUKItQ" } ...
}

• Requisito de almacenamiento para índices de resultados – Los detectores en tiempo real almacenan los resultados de detección tanto como sea posible cuando la presión de indexación no es alta, incluidos los resultados anómalos y no anómalos. Cuando la presión de indexación es alta, guardamos un subconjunto aleatorio y anómalo de resultados no anómalos. OpenSearch Dashboards emplea resultados no anómalos como contexto de resultados anómalos y traza los resultados en función del tiempo. Además, AD almacena el historial de todos los resultados generados durante un número configurable de días después de generar los resultados. Este período de retención de resultados es de 30 días de forma predeterminada y se puede ajustar a través de la configuración del clúster plugins.anomaly_detection.ad_result_history_retention_period. Necesitamos asegurarnos de que haya suficiente espacio en disco disponible para almacenar los resultados multiplicando la cantidad de datos generados por día por el período de retención. Por ejemplo, considere un detector que genera 1 millón de documentos de resultados para un detector de intervalo de 10 minutos con 1 millón de entidades por intervalo. El tamaño de un documento es de aproximadamente 1 KB. Eso es aproximadamente 144 GB por día, 4,320 GB después de un período de retención de 30 días. El requisito total del disco también debe multiplicarse por la cantidad de copias de fragmentos. Actualmente, AD elige un fragmento principal por nodo (hasta 10) y una réplica cuando se llama por primera vez. Debido a que la cantidad de réplicas es 1, cada fragmento tiene dos copias y el requisito de disco total se acerca a los 8,640 GB para el millón de entidades de nuestro ejemplo.
• Sobrecarga de detección de anomalías – AD incurre en sobrecarga de memoria para análisis históricos y operaciones internas. Recomendamos reservar un 20 % más de memoria para la sobrecarga a fin de mantener la ejecución de los modelos sin interrupciones.

Para derivar el número requerido de nodos de datos D, primero debemos derivar una expresión para el número de modelos de entidad N que un nodo puede alojar en la memoria. Definimos S_i ser el tamaño del modelo de entidad del detector i. Si usamos un tipo de instancia con tamaño de montón H donde está el porcentaje máximo de memoria de AD P, N es igual a la asignación de memoria AD dividida por el tamaño máximo del modelo de entidad entre todos los detectores:

Consideramos el número requerido de nodos de datos D como una función de N. Denotemos por C_i los recuentos totales de entidades del detector i. Dado n detectores, se sigue que:

El hecho de que AD necesite un 20 % adicional de sobrecarga de memoria se expresa multiplicando 1.2 en la fórmula. La función ceil representa el entero más pequeño mayor o igual que el argumento.

Por ejemplo, un r5.2xlarge Nube informática elástica de Amazon (Amazon EC2) la instancia tiene 64 GB de RAM, por lo que el tamaño del almacenamiento dinámico es de 32 GB. Configuramos AD para usar como máximo la mitad del tamaño de almacenamiento dinámico permitido. Tenemos dos detectores HCAD, cuyos modelos tienen un tamaño de 471 KB y 403 KB, respectivamente. Para alojar 500,000 36 entidades para cada detector, necesitamos un clúster de XNUMX nodos de datos de acuerdo con el siguiente cálculo:

También debemos asegurarnos de que haya suficiente espacio en disco. Al final, usamos un clúster r39xlarge de 5.2 nodos (3 nodos primarios y 36 de datos) con 4 TB Tienda de bloques elásticos de Amazon (EBS) de almacenamiento en cada nodo.

¿Qué sucede si se desconoce el recuento de entidades de un detector?

A veces, es difícil saber el número de entidades de un detector. Podemos comprobar datos históricos y estimar la cardinalidad. Pero es imposible predecir el futuro con precisión. Una pauta general es asignar memoria de búfer durante la planificación. Si se utiliza adecuadamente, la memoria intermedia proporciona espacio para pequeños cambios. Si los cambios son significativos, puede ajustar la cantidad de nodos de datos porque HCAD puede escalar hacia adentro y hacia afuera horizontalmente.

¿Qué pasa si el número de entidades activas está cambiando?

El número total de entidades creadas puede ser superior al número de entidades activas, como se desprende de las dos cifras siguientes. El número total de entidades en el conjunto de datos de registros HTTP es de 2 millones en 2 meses, pero cada entidad solo aparece siete veces en promedio. El número de entidades activas dentro de un intervalo de tiempo es mucho menor que 2 millones. La siguiente figura presenta una serie temporal de ejemplo del tamaño de la red de las direcciones IP del conjunto de datos de registros HTTP.

El Conjunto de datos de KPI también muestra un comportamiento similar, donde las entidades a menudo aparecen en un corto período de tiempo durante las ráfagas de actividades de la entidad.

AD requiere tamaños de muestra grandes para crear una imagen completa de los patrones de datos, lo que lo hace adecuado para series de tiempo densas que se pueden muestrear de manera uniforme. AD todavía puede entrenar modelos y producir predicciones si el comportamiento de ráfagas anterior puede durar un tiempo y proporcionar al menos 400 puntos. Sin embargo, el entrenamiento se vuelve más difícil y la precisión de la predicción es menor a medida que los datos se vuelven más escasos.

Es un desperdicio preasignar memoria de acuerdo con el número total de entidades en este caso. En lugar del número total de entidades, debemos considerar las entidades activas máximas dentro de un intervalo. Puede obtener un número aproximado usando un date_histogram canalización de agregación de cardinalidad y clasificación durante un período representativo. Puede ejecutar la siguiente consulta si está indexando host-cloudwatch y desea conocer la cantidad máxima de hosts activos en un intervalo de 10 minutos durante 10 días:

GET /host-cloudwatch/_search?size=0
{ "query": { "range": { "@timestamp": { "gte": "2021-11-17T22:21:48", "lte": "2021-11-27T22:22:48" } } }, "aggs": { "by_10m": { "date_histogram": { "field": "@timestamp", "fixed_interval": "10m" }, "aggs": { "dimension": { "cardinality": { "field": "host" } }, "multi_buckets_sort": { "bucket_sort": { "sort": [{ "dimension": { "order": "desc" } }], "size": 1 } } } } }
}

El resultado de la consulta muestra que, como máximo, unos 1,000 hosts están activos durante un intervalo de diez minutos:

{ ... "aggregations": { "by_10m": { "buckets": [{ "key_as_string": "2021-11-17T22:30:00.000Z", "key": 1637188200000, "doc_count": 1000000, "dimension": { "value": 1000 } }] } } ...
}

HCAD tiene un caché para almacenar modelos y mantener una marca de tiempo del último acceso para cada modelo. Para cada modelo, un trabajo por hora comprueba el tiempo de inactividad e invalida el modelo si el tiempo de inactividad es superior a 1 hora. Dependiendo del momento de la verificación por hora y la capacidad de la memoria caché, el tiempo transcurrido en la memoria caché de un modelo varía. Si la capacidad de caché no es lo suficientemente grande como para contener todos los modelos que no han caducado, tenemos una política de caché de uso menos frecuente (LFU) adaptada para desalojar modelos (más sobre esto en una sección posterior) y el tiempo de caché de esos modelos invalidados. es menos de 1 hora. Si la última hora de acceso de un modelo se restablece inmediatamente después de la verificación por hora, cuando se realice la siguiente verificación por hora, el modelo no caduca. El modelo puede tardar una hora más en caducar cuando llegue el próximo control por horas. Entonces, el tiempo máximo de caché es de 2 horas.

El límite superior de entidades activas que detectan i puede observar es:

Esta ecuación tiene los siguientes parámetros:

• A_i es el número máximo de entidades activas por intervalo del detector i. Obtenemos el número de la consulta anterior.
• 120 es el número de minutos en 2 horas. ∆T_i denota el intervalo del detector i en minutos. La función ceil representa el entero más pequeño mayor o igual que el argumento. techo(120÷∆T_i) se refiere al número máximo de intervalos que se almacena en caché un modelo.

En consecuencia, debemos contabilizar B_i en la fórmula de tamaño:

Diagrama de flujo de cálculo de tamaño

Con las definiciones de cálculo de la cantidad de nodos de datos en su lugar, podemos usar el siguiente diagrama de flujo para tomar decisiones en diferentes escenarios.

¿Qué pasa si el clúster está subescalado?

Si el clúster está subescalado, AD prioriza las entidades más frecuentes y recientes. AD hace su mejor esfuerzo para acomodar entidades adicionales al cargar sus modelos a pedido desde el disco sin alojarlos en la memoria caché en memoria. Cargar los modelos bajo demanda significa recargar-usar-detener-almacenar modelos en cada intervalo, cuyos gastos generales son bastante altos. Los gastos generales tienen que ver principalmente con la red o la E/S de disco, más que con el costo de la inferencia del modelo. Por lo tanto, lo hicimos de manera constante y controlada. Si el uso de recursos del sistema no es excesivo y hay tiempo suficiente, HCAD puede terminar de procesar las entidades adicionales. De lo contrario, HCAD no encuentra necesariamente todas las anomalías que podría encontrar.

Ejemplo: Análisis de 1 millón de entidades

En el siguiente ejemplo, aprenderá a configurar un detector para analizar un millón de entidades.

Ingesta de datos

Generamos 10 mil millones de documentos para 1 millón de entidades en nuestra evaluación de escalabilidad y mejora de la integridad. Cada entidad tiene una serie de tiempo de onda coseno con anomalías inyectadas aleatoriamente. Con la ayuda de los consejos de este post, creamos el index host-cloudwatch e ingerimos los documentos en el clúster. host-cloudwatch registra el tiempo transcurrido de recolección de elementos no utilizados (GC) de la CPU y la JVM por parte de un proceso dentro de un host. El mapeo de índices es el siguiente:

{ ... "mappings": { "properties": { "@timestamp": { "type": "date" }, "cpuTime": { "type": "double" }, "jvmGcTime": { "type": "double" }, "host": { "type": "keyword" }, "process": { "type": "keyword" } } } ...
}

Crear un detector

Considere los siguientes factores antes de crear un detector:

• Índices para monitorear – Puede utilizar un grupo de nombres de índice, alias o patrones. Aquí usamos el índice host-cloudwatch creado en el último paso.
• campo de marca de tiempo – Un detector monitorea datos de series de tiempo. Cada documento en el índice provisto debe estar asociado con una marca de tiempo. En nuestro ejemplo, usamos el campo @timetamp.
• Filtrar – Un filtro selecciona los datos que desea analizar en función de alguna condición. Un filtro de ejemplo selecciona las solicitudes con el código de estado 400 después de los registros de solicitudes HTTP. Las clases 4xx y 5xx del código de estado HTTP indican que una solicitud se devuelve con un error. Luego puede crear un detector de anomalías para la cantidad de solicitudes de error. En nuestro ejemplo en ejecución, analizamos todos los datos y, por lo tanto, no se utiliza ningún filtro.
• Campo de categoría – Cada entidad tiene características específicas que la describen. Los campos de categoría proporcionan categorías de esas características. Una entidad puede tener hasta dos campos de categoría a partir de Amazon OpenSearch Service 1.1. Aquí monitoreamos un proceso específico de un host en particular especificando el proceso y el campo host.
• Intervalo del detector – El intervalo del detector suele estar definido por la aplicación. Agregamos datos dentro de un intervalo y ejecutamos modelos sobre los datos agregados. Como se mencionó anteriormente, AD es adecuado para series temporales densas que se pueden muestrear de manera uniforme. Al menos debe asegurarse de que la mayoría de los intervalos tengan datos. Además, los diferentes intervalos del detector requieren diferentes compensaciones entre el retraso y la precisión. Los intervalos largos suavizan las fluctuaciones de la carga de trabajo a corto y largo plazo y, por lo tanto, pueden ser menos propensos al ruido, lo que genera un gran retraso en la detección. Los intervalos cortos conducen a una detección más rápida, pero pueden encontrar fluctuaciones anticipadas de la carga de trabajo en lugar de anomalías. Puede trazar su serie temporal con varios intervalos y observar qué intervalo mantiene anomalías relevantes mientras reduce el ruido. Para este ejemplo, usamos el intervalo predeterminado de 10 minutos.
• Feature – Una característica es un valor agregado extraído de los datos monitoreados. Se envía a modelos para medir los grados de anormalidad. Formar una característica puede ser tan simple como elegir un campo para monitorear y la función de agregación que resume los datos del campo como métricas. Proporcionamos un conjunto de funciones como mínimo y promedio. También puede usar un campo de tiempo de ejecución a través de secuencias de comandos. Estamos interesados ​​en el campo de tiempo de recolección de basura agregado a través de la función promedio en este ejemplo.
• Retardo de ventana – Retardo de ingestión. Si el valor no está configurado correctamente, un detector podría analizar los datos antes de que los datos tardíos lleguen al clúster. Debido a que recopilamos todos los datos por adelantado, el retraso de la ventana es 0 en este caso.

La configuración de nuestro detector agrega el tiempo promedio de procesamiento de recolección de basura cada 10 minutos y analiza el promedio en la granularidad de los procesos en diferentes hosts. La solicitud de API para crear dicho detector es la siguiente. También puede utilizar nuestro simplificado UI para crear e iniciar un detector.

POST _plugins/_anomaly_detection/detectors
{ "name": "detect_gc_time", "description": "detect gc processing time anomaly", "time_field": "@timestamp", "indices": [ "host-cloudwatch" ], "category_field": ["host", "process"], "feature_attributes": [{ "feature_name": "jvmGcTime average", "feature_enabled": true, "importance": 1, "aggregation_query": { "gc_time_average": { "avg": { "field": "jvmGcTime" } } } }], "detection_interval": { "period": { "interval": 10, "unit": "MINUTES" } }, "schema_version": 2
}

Una vez que se completa el entrenamiento inicial, todos los modelos de 1 millón de entidades están en la memoria y se genera 1 millón de resultados cada intervalo de detector después de unas pocas horas. Para verificar la cantidad de modelos activos en el caché, puede ejecutar la API de perfil:

GET /_plugins/_anomaly_detection/detectors/fkzfBX0BHok1ZbMqLMdu/_profile/models

Obtenemos la siguiente respuesta:

{ ... "model_count": 1000000
}

Puede observar cuántos resultados se generan en cada intervalo del detector (en nuestro caso, 10 minutos) invocando la API de búsqueda de resultados:

GET /_plugins/_anomaly_detection/detectors/results/_search
{ "query": { "range": { "execution_start_time": { "gte": 1636501467000, "lte": 1636502067000 } } }, "track_total_hits": true
}

Obtenemos la siguiente respuesta:

{ ... "hits": { "total": { "value": 1000000, "relation": "eq" }, ... } ...
}

Los paneles de OpenSearch ofrecen una exposición de las principales entidades que producen las anomalías más graves o la mayor cantidad de anomalías.

Puede elegir una celda de color para revisar los detalles de las anomalías que ocurren dentro de ese período determinado.

Puede ver el grado de anomalía, la confianza y las características correspondientes en un área sombreada.

crear un monitor

Puedes crear un monitor de alerta para notificarle sobre anomalías en función del detector de anomalías definido, como se muestra en la siguiente captura de pantalla.

Usamos el grado de anomalía y la confianza para definir un disparador. Tanto el grado de anomalía como la confianza son valores entre 0 y 1.

El grado de anomalía representa la gravedad de una anomalía. Cuanto más cerca esté el grado de 1, mayor será la gravedad. 0 grado significa que la predicción correspondiente no es una anomalía.

La confianza mide si el modelo de una entidad ha observado suficientes datos como para que el modelo contenga suficientes puntos de datos únicos del mundo real. Si un valor de confianza de un modelo es mayor que la confianza de un modelo diferente, entonces la anomalía del primer modelo ha observado más datos.

Como queremos recibir alertas de alta fidelidad, configuramos el umbral de calificación en 0 y el umbral de confianza en 0.99.

El último paso para crear un monitor es agregar una acción sobre qué incluir en la notificación. Nuestro detector de ejemplo encuentra anomalías en un proceso particular en un host. El mensaje de notificación debe contener la identidad de la entidad. En este ejemplo, usamos ctx.results.0.hits.hits.0._source.entity para obtener la identidad de la entidad.

Un monitor basado en un detector extrae la anomalía de ley máxima y activa una alerta basada en la ley configurada y el umbral de confianza. El siguiente es un ejemplo de mensaje de alerta:

Attention Monitor detect_cpu_gc_time2-Monitor just entered alert status. Please investigate the issue.
- Trigger: detect_cpu_gc_time2-trigger
- Severity: 1
- Period start: 2021-12-08T01:01:15.919Z
- Period end: 2021-12-08T01:21:15.919Z
- Entity: {0={name=host, value=host107}, 1={name=process, value=process622}}

Puede personalizar la consulta de extracción y la condición de activación cambiando el método de definición del monitor a Monitor de consulta de extracción y modificando la consulta y condición correspondiente. Aquí es la explicación de todos los campos de índice de resultados de anomalías que puede consultar.

Evaluación

En esta sección, evaluamos la precisión, la recuperación y el rendimiento general de HCAD.

Precisión y recuerdo

Evaluamos precisión y recuerdo sobre los datos de onda coseno, como se mencionó anteriormente. Estas evaluaciones no son fáciles en el contexto del procesamiento en tiempo real porque solo hay un punto disponible por entidad durante cada intervalo del detector (10 minutos en el ejemplo). Procesar todos los puntos lleva mucho tiempo. En su lugar, simulamos el procesamiento en tiempo real acelerando el procesamiento en un script. Los resultados son un promedio de 100 ejecuciones. La desviación estándar es de alrededor de 0.12.

La precisión promedio general, incluidos los efectos del arranque en frío mediante interpolación lineal, para los datos sintéticos es 0.57. El recuerdo es 0.61. Observamos que no se aplicaron transformaciones; es posible y probable que las transformaciones mejoren estos números. La precisión es 0.09 y la recuperación es 0.34 para los primeros 300 puntos debido a los datos de arranque en frío interpolados para el entrenamiento. Los números aumentan a medida que el modelo observa más datos reales. Después de otros 5,000 puntos de datos reales, la precisión y la recuperación mejoran a 0.57 y 0.63, respectivamente. Reiteramos que los números exactos varían según las características de los datos: una configuración de detección o un punto de referencia diferente tendrían otros números. Además, si no faltan datos, la fidelidad del modelo HCAD sería la misma que la de un detector de flujo único.

Rendimiento

Ejecutamos HCAD en un clúster inactivo sin consumo ni tráfico de búsqueda. Métricas como Presión de memoria JVM y la CPU de cada nodo se encuentran dentro de la zona segura, como se muestra en la siguiente captura de pantalla. La presión de la memoria JVM varía entre el 23 y el 39 %. La CPU es principalmente alrededor del 1%, con picos por hora de hasta el 65%. Un trabajo de mantenimiento interno por hora puede explicar el aumento debido a que se salvan cientos de miles de puntos de control del modelo, se limpian los modelos no utilizados y se realiza la contabilidad de los estados internos. Sin embargo, esto puede ser una mejora futura.

Implementación

A continuación, analizamos los detalles del trabajo técnico relacionado con la integridad y la escalabilidad de HCAD.

FCR 2.0

En Amazon OpenSearch Service 1.1, nos integramos con Biblioteca Random Cut Forest (RCF) 2.0. RCF se basa en la partición de datos en diferentes cuadros delimitadores. La versión anterior de RCF mantiene cuadros delimitadores en la memoria. Sin embargo, un detector en tiempo real solo usa los cuadros delimitadores cuando procesa un nuevo punto de datos y los deja inactivos la mayor parte del tiempo. RCF 2.0 permite recrear esos cuadros delimitadores cuando sea necesario para que los cuadros delimitadores estén presentes en la memoria al procesar la entrada correspondiente. La recreación a pedido ha llevado a una reducción de la sobrecarga de memoria nueve veces mayor y, por lo tanto, puede admitir el alojamiento de nueve veces más modelos en un nodo. Además, RCF 2.0 renueva el módulo de serialización. El nuevo módulo serializa y deserializa un modelo 26 veces más rápido utilizando un espacio en disco 20 veces menor.

Paginación

Con respecto a la agregación de funciones, cambiamos de obtener los mejores resultados mediante la agregación de términos a la paginación a través de la agregación compuesta. Evaluamos múltiples implementaciones de paginación utilizando un conjunto de datos generado con 1 millón de entidades. Cada entidad tiene dos documentos. Las configuraciones del experimento pueden variar según la cantidad de nodos de datos, fragmentos primarios y campos categóricos. Creemos que las consultas compuestas son la elección correcta porque, aunque no sean las más rápidas en todos los casos, son las más estables en promedio (40 segundos).

Amortizar operaciones costosas

HCAD puede enfrentar un tráfico de manada estruendoso, en el que muchas entidades realizan solicitudes como leer puntos de control de discos aproximadamente al mismo tiempo. Por lo tanto, creamos varias colas para almacenar en búfer las solicitudes reprimidas. Estas colas amortizan costos costosos al realizar una cantidad de trabajo pequeña y limitada de manera constante. Por lo tanto, HCAD puede ofrecer un rendimiento y disponibilidad predecibles a escala.

Caché en memoria

HCAD recurre al almacenamiento en caché para procesar entidades cuyo requisito de memoria es mayor que el tamaño de memoria configurado. Al principio, probamos un caché usado menos recientemente, pero experimentamos una paliza al ejecutar el Carga de trabajo de registros HTTP: con 100 detectores de intervalos de 1 minuto y millones de entidades para cada detector, vimos pocas coincidencias de caché (muchos cientos) en 7 horas. Estábamos desperdiciando ciclos de CPU intercambiando modelos dentro y fuera de la memoria todo el tiempo. Como regla general, no vale la pena considerar el almacenamiento en caché para accesos rápidos al modelo con una proporción de aciertos y errores inferior a 3:1.

En su lugar, recurrimos a un almacenamiento en caché de LFU modificado, aumentado para incluir la aproximación de los bateadores pesados. A conteo decaído se mantiene para cada modelo en el caché. El recuento deteriorado de un modelo en la memoria caché se incrementa cuando se accede al modelo. El modelo con el recuento de descomposición más pequeño es el modelo que se usa con menos frecuencia. Cuando la memoria caché alcanza su capacidad, invalida y elimina el modelo que se usa con menos frecuencia si la frecuencia de la nueva entidad no es menor que la entidad que se usa con menos frecuencia. Esta conexión entre la aproximación de bateador pesado y LFU tradicional nos permite hacer que los modelos más frecuentes y recientes se mantengan fijos en la memoria y eliminar gradualmente los modelos con menores probabilidades de éxito de caché.

Tolerancia a fallos

El estado de la memoria irrecuperable es limitado y se almacena suficiente información de los modelos en el disco para resistir los bloqueos. Los modelos se recuperan en un host diferente después de que se detecta un bloqueo.

Alto rendimiento

HCAD se basa en E/S asíncrona: todas las solicitudes de E/S, como las llamadas a la red o los accesos al disco, son sin bloqueo. Además, la distribución del modelo se equilibra en todo el clúster mediante un anillo hash coherente.

Resumen

Mejoramos HCAD para mejorar su escalabilidad e integridad sin alterar la fidelidad del cálculo. Como resultado de estas mejoras, le mostré cómo dimensionar un dominio de OpenSearch y usar HCAD para monitorear 1 millón de entidades en 10 minutos. Para obtener más información sobre HCAD, consulte documentación de detección de anomalías.

Si tiene comentarios sobre esta publicación, envíe comentarios en el sección de comentarios a continuación. Si tiene preguntas sobre esta publicación, inicie un nuevo hilo en el Foro de aprendizaje automático.