Inferencia ¿El futuro liderado por IA de la observabilidad?

¿Futuro liderado por IA en la observabilidad?

En los últimos nueve meses, los avances rápidos en la IA generativa han tenido un impacto en casi todas las industrias. ¿Cuáles son las implicaciones para cómo hacemos la observabilidad y el monitoreo de nuestros sistemas de producción?

Postulo que la próxima evolución en este espacio será una nueva clase de soluciones que hagan “Inferencia”, es decir, determinen directamente la causa raíz de un error para un desarrollador con una precisión razonable.

En este artículo, examinamos:

  • La inferencia como un siguiente paso natural para la observabilidad.
  • Lecciones aprendidas de AIOps, por qué no despegó y las implicaciones para la inferencia.
  • Algunos principios emergentes para la clase de soluciones de inferencia.

Dónde Estamos

Para entender la próxima generación de observabilidad, comencemos con el objetivo subyacente de todas estas herramientas. Es mantener los sistemas de producción saludables y funcionando como se espera y, si algo sale mal, permitirnos comprender rápidamente por qué y resolver el problema.

Si partimos de ahí, vemos que hay tres niveles distintos en cómo las herramientas pueden ayudarnos:

  • Nivel 1: “Alertarme cuando algo no está bien en mi sistema” – monitoreo.
  • Nivel 2: “Dime por qué algo no está bien (y cómo solucionarlo)” – llamémoslo inferencia.
  • Nivel 3: “Soluciona el problema tú mismo y dime qué hiciste” – auto-remediación.

Las herramientas de monitoreo hacen bien el nivel 1 (detectar problemas). El siguiente paso natural es el nivel 2, donde un sistema nos dice automáticamente por qué algo se está rompiendo. Aún no tenemos soluciones que puedan hacer esto, así que agregamos una categoría de herramientas llamada observabilidad entre el nivel 1 y el nivel 2, cuyo objetivo era “ayudarnos a comprender por qué algo se está rompiendo”. Esto se convirtió básicamente en “cualquier dato que potencialmente pudiera ayudarnos a comprender lo que está sucediendo”.

Observabilidad vs. Inferencia

El Problema con la Observabilidad Hoy en Día

El principal problema con la observabilidad hoy en día es que está definida y ejecutada de manera imprecisa. Esto se debe a que no sabemos qué datos necesitamos de antemano, eso depende del problema. La naturaleza de los errores de producción es que son raros e inesperados; si se pudieran predecir, se habrían resuelto. Por lo tanto, recopilamos una amplia variedad de tipos de datos: métricas, registros, trazas distribuidas, datos de errores de seguimiento de pila, eventos de K8s y perfiles continuos, todo para asegurarnos de tener cierta visibilidad cuando las cosas salen mal.

La mejor manera de entender la observabilidad tal como se implementa en la práctica es: “Todo lo que no son métricas, más métricas”.

Observabilidad en la práctica

Una plataforma de observabilidad también tiene que tomar decisiones sobre cuántos datos capturar y almacenar. Actualmente, esta decisión recae en los clientes y estos tienden a recolectar la mayor cantidad de datos que pueden permitirse. La rápida adopción de la nube y los modelos SaaS han hecho posible recopilar y almacenar grandes cantidades de datos.

El impulso humano subyacente para recolectar más tipos y volúmenes de datos de observabilidad es: “¿Qué pasa si algo se rompe y no tengo suficientes datos para solucionarlo?” Esta es la peor pesadilla de cualquier equipo de ingeniería. Como resultado de esto, hoy en día tenemos una situación en la que:

  • Los tipos de datos de observabilidad están en constante expansión.
  • Los volúmenes de datos de observabilidad están aumentando rápidamente.
  • Aumento de la proliferación de herramientas: en promedio, las empresas utilizan más de 5 herramientas de observabilidad.

Con todo esto, empezamos a enfrentar nuevos problemas. Ahora es cada vez más difícil para los desarrolladores navegar manualmente por los numerosos paneles de control intensivos en datos para identificar un error. La observabilidad también se ha vuelto prohibitivamente cara, por lo que las empresas deben comenzar a hacer compensaciones complejas en cuanto a qué datos almacenar, perdiendo a veces visibilidad. Debido a todo esto y al continuo aumento de la complejidad de los sistemas de producción, estamos viendo que el MTTR (tiempo medio para la resolución) de los errores de producción realmente ha aumentado en los últimos años.

Inferencia: Observabilidad más IA

Argumentaría que el siguiente paso después de la observabilidad es la Inferencia, donde una plataforma puede explicar razonablemente por qué ocurrió un error para que podamos solucionarlo. Esto se vuelve posible ahora en 2023 con la rápida evolución de los modelos de IA en los últimos meses.

Imagina una solución que:

  • Muestre automáticamente solo los errores que necesitan atención inmediata del desarrollador.
  • Le diga al desarrollador exactamente qué está causando el problema y dónde está el problema: este pod, este servidor, esta ruta de código, este tipo de solicitud.
  • Guíe al desarrollador sobre cómo solucionarlo.
  • Utilice las acciones reales del desarrollador para mejorar continuamente sus recomendaciones.

Hay alguna actividad temprana en este espacio, pero todavía estamos en una etapa muy temprana, y podemos esperar que varias nuevas empresas surjan aquí en los próximos años.

Sin embargo, cualquier conversación sobre IA + observabilidad sería incompleta sin una discusión sobre AIOps, que fue la misma promesa (utilizar IA para automatizar operaciones de producción) y vio una oleada de inversión entre ’15-20 pero tuvo un éxito limitado y se desvaneció. Para una exploración exhaustiva de por qué AIOps falló, lee esto: AIOps está muerto.

Evitando las Trampas de AIOps

La premisa original de AIOps era que si llevábamos datos de las cinco o seis fuentes de observabilidad diferentes a una plataforma unificadora y luego aplicábamos IA a todos estos datos (métricas, registros, dependencias, trazas, configuraciones, actualizaciones, eventos de K8s), obtendríamos información sobre por qué algo se rompió.

La arquitectura de una plataforma de AIOps.

Aunque atractivo en teoría, este argumento quedó corto en algunos aspectos.

En primer lugar, unir todo era impráctico y un problema mucho más difícil de lo estimado. Las diferentes herramientas de observabilidad recopilaban diferentes datos sobre diferentes sistemas en intervalos de tiempo diferentes, y exponían diferentes subconjuntos de los datos recopilados a una herramienta de terceros. Además, cada cliente individual tenía sus propias prácticas de recopilación de datos. Por ejemplo, las empresas tendrían varias herramientas de observabilidad diferentes con recopilación de datos altamente personalizada y no estándar, y la empresa tendría que proporcionar manualmente contexto sobre ellas a cualquier nueva herramienta de AIOps. Todo esto afectó la calidad de la respuesta/la búsqueda de la causa raíz a la que los modelos de ML podían llegar y el valor que terminaron entregando.

En segundo lugar, el modelo de AIOps era demasiado amplio y no estaba orientado a casos de uso específicos. Por ejemplo, ¿a qué tipos específicos de errores apuntaban los modelos? ¿Errores de infraestructura/errores de código/errores duros/errores suaves? La mayoría de las plataformas de AIOps se volvieron bastante amplias aquí e intentaron digerir ocho tipos diferentes de datos con la esperanza de encontrar patrones y anomalías, y dependían demasiado de cuántos datos y de qué calidad empujara el cliente hacia la plataforma, lo que variaba la calidad de su resultado.

En tercer lugar, el proceso de integración en cada empresa era demasiado complejo. Una empresa grande tiene una huella fragmentada de herramientas de observabilidad, con decenas de herramientas utilizadas por diferentes equipos. Una plataforma de AIOps debía integrarse en todas esas herramientas para poder agregar valor. Incluso en el caso del módulo de AIOps de una plataforma de observabilidad grande como Datadog o DynaTrace, el requisito era que toda la pila de observabilidad se moviera al único proveedor (en métricas de infraestructura y aplicación, registros, trazas distribuidas, monitoreo de errores, y así sucesivamente), para que el módulo de AIOps fuera efectivo.

En cuarto lugar, los volúmenes masivos de datos y la potencia de procesamiento requeridos para procesar los datos también hicieron que estas herramientas fueran muy caras en relación con su valor cuestionable.

Todo esto resultó en un grado de desilusión entre muchos de los primeros adoptantes de herramientas de AIOps, y la mayoría de las empresas volvieron a un mecanismo simple de “recopilar datos y mostrar en paneles de control” para sus necesidades.

Varios aprendizajes de aquí serán aplicables y se pueden aprender y aplicar a medida que intentamos la Inferencia.

Principios de Inferencia

La inferencia tendría que ser diferente de varias maneras para lograr de manera más eficiente el objetivo final.

Arquitectado Desde Cero Con IA en Mente

Una solución de inferencia tendría que ser arquitectada desde cero para el caso de uso de IA, es decir, la recopilación de datos, el procesamiento, la canalización, el almacenamiento y la interfaz de usuario están diseñados desde cero para “identificar las causas raíz utilizando IA”.

Lo que probablemente NO se verá es IA agregada a una solución de observabilidad existente o a datos de observabilidad existentes, simplemente porque eso es lo que intentamos y fallamos con AIOps. Tendrá que ser un sistema de pila completa en el que todo esté diseñado en torno al uso de IA con el objetivo explícito de realizar análisis de causa raíz.

¿Cómo se vería esto en la práctica?

Arquitectura Nativa de IA de Pila Completa con Recopilación de Datos, Procesamiento, Almacenamiento y Visualización

Una solución de inferencia tendría que ser verticalmente integrada, es decir, tendría que recopilar datos de telemetría, procesar los datos, y poseer la canalización de datos y la capa de interacción con los usuarios.

Esto es importante porque permitiría que la solución utilice las interacciones de los usuarios para aprender y actualizar sus mecanismos de procesamiento y recopilación de datos.

También sería crucial que la solución de Inferencia pudiera recolectar los datos que necesita, en el formato que necesita, con el contexto que necesita, de los entornos del cliente, para tener control sobre la efectividad de la causa raíz y la experiencia del usuario.

Recolección de Datos Adaptativa

Una solución de Inferencia tendría que tener inteligencia incorporada en la recolección de datos en sí. Esto significa que el agente debería poder analizar los datos que se transmiten y decidir en ese momento si capturarlos o descartarlos.

Hoy en día, todos los agentes de instrumentación son “tontos”: simplemente toman una instantánea de todos los datos y los envían, y el procesamiento ocurre más tarde. Esto tiene sentido hoy en día porque principalmente utilizamos agentes de código, y queremos que los agentes sean lo más livianos posible y agreguen una sobrecarga mínima.

Sin embargo, con la aparición de tecnologías como eBPF, que nos permiten realizar la recolección de datos fuera de banda desde el kernel con una sobrecarga casi nula, es posible imaginar un agente de instrumentación inteligente que resuelva activamente la calidad de los datos que los modelos de inferencia requerirían.

Procesamiento de Datos Adaptado a Casos de Uso Específicos

En Inferencia, todas las técnicas de procesamiento de datos tendrían que centrarse en casos de uso específicos, por ejemplo, ¿Cómo puedo identificar de manera confiable el error tipo A? ¿Y el error tipo B? Y así sucesivamente.

Todos los modelos de procesamiento de datos seguirían el principio de poder identificar de manera confiable algunas tipos de errores y aumentar gradualmente el tipo de errores que identificarían a medida que los modelos evolucionen. Esto puede llevar a diferentes tipos de datos, tuberías de datos y consultas para cada tipo de error. Es posible que tengamos algunas plataformas de inferencia que sean mejores para identificar errores de infraestructura, otras para problemas de seguridad, otras para errores de código, y así sucesivamente, cada una de ellas recopilando conjuntos de datos ligeramente diferentes con tuberías de datos ligeramente diferentes y un marco de modelo diferente.

Lo que probablemente no harán es “detección general de anomalías” y luego retroceder para ver qué pudo haber causado la anomalía. Esto se debe a que los datos necesarios para identificar la causa raíz de un error son muy diferentes de los datos necesarios para “identificar/detectar” un error.

Almacenamiento Diseñado para IA

La visión del almacenamiento en un mundo de Inferencia ya se ve diferente que en un mundo de monitoreo u observabilidad. Ahora tenemos grandes almacenes de datos para todo lo que ocurre, pero en inferencia, lo que necesitamos es solo almacenar los datos más relevantes y recientes que los modelos de IA necesitan para identificar de manera confiable las causas raíz de los errores. Esto podría implicar varias prácticas, como almacenar datos en bases de datos vectoriales para facilitar el agrupamiento y la recuperación, almacenar solo una pequeña parte de los casos de éxito y descartar el resto, eliminar duplicados de errores, y así sucesivamente.

Como resultado, la cantidad de almacenamiento requerida para las soluciones de Inferencia podría ser menor que la que necesitan las soluciones tradicionales de monitoreo y observabilidad.

Interfaz de Usuario Más Sencilla e Interactiva

Una interfaz de Inferencia probablemente se vería menos como un conjunto de paneles con datos y más como una interfaz conversacional++ ajustada para los equipos de desarrollo. Tal vez tenga una tabla simple de errores priorizados que necesitan atención humana: haces clic en cada error y muestra una lista de las causas raíz más probables con una probabilidad de precisión. Luego podría tener RLHF (Aprendizaje por Reforzamiento a partir de la Retroalimentación Humana) para que los usuarios confirmen si se identificó correctamente una causa raíz, de modo que los modelos mejoren su rendimiento con el tiempo. Las posibilidades son amplias aquí.

Resumen

En resumen, es probable que haya cambios drásticos en el espacio de monitoreo y observabilidad con los desarrollos recientes en IA general.

Es probable que la primera ola de soluciones se parezca a las plataformas de IAOPs de antaño, con una delgada capa de IA general alrededor de los datos de observabilidad existentes. Los actores establecidos están mejor posicionados para ganar esta ola. Esto probablemente se asemeje a Github Copilot: obtienes una buena sugerencia aproximadamente el 10% del tiempo. Sin embargo, el verdadero salto adelante probablemente esté a un par de años de distancia, con una nueva clase de soluciones de Inferencia que puedan identificar con precisión las causas raíz de los errores más del 80% del tiempo. Para lograr esto, tendrían que ser de pila completa y tener el control de la recolección de datos, el procesamiento, el almacenamiento, los modelos y las interacciones con el usuario. Exploramos algunas hipótesis iniciales sobre cómo las soluciones de Inferencia difieren de las prácticas existentes en cada parte de la pila.

We will continue to update Zepes; if you have any questions or suggestions, please contact us!

Share:

Was this article helpful?

93 out of 132 found this helpful

Discover more

Inteligencia Artificial

Esta revisión de investigación de IA explora la integración de imágenes satelitales y aprendizaje profundo para medir la pobreza basada en activos.

Investigadores de la Universidad de Lund y la Universidad de Halmstad llevaron a cabo una revisión sobre la inteligen...

Inteligencia Artificial

Investigadores de UC Berkeley y Deepmind proponen SuccessVQA una reformulación de la detección de éxito que es compatible con VLM pre-entrenados como Flamingo.

Para lograr la máxima precisión en el rendimiento, es crucial entender si un agente está en el camino correcto o pref...

Inteligencia Artificial

Conoce GPTCache una biblioteca para desarrollar una caché semántica de consultas LLM.

ChatGPT y los modelos de lenguaje grandes (LLMs) son extremadamente flexibles, lo que permite la creación de numeroso...

Inteligencia Artificial

Los repetidores cuánticos utilizan defectos en el diamante para interconectar sistemas cuánticos

Ahora los científicos están aprovechando los defectos en los diamantes para construir repetidores cuánticos.

Inteligencia Artificial

La cámara detiene los deepfakes al disparar

Las credenciales de contenido integradas verifican la autenticidad de las fotos.