Una de las tendencias clave en la infraestructura de software en 2019 es la
Observabilidad .
Ha ganado mucha atención recientemente.
¿Qué es la observabilidad?
Hay muchas discusiones y bromas sobre este término. Por ejemplo:
- ¿Por qué llamarlo monitoreo? Eso ya no es lo suficientemente sexy.
- Observabilidad, porque cambiar el nombre de Ops como DevOps no era lo suficientemente malo, ahora también están desarrollando la monitorización.
- El nuevo Chuck Norris de DevOps.
- Soy un ingeniero que puede ayudar a proporcionar monitoreo a los otros ingenieros de la organización.
- > Genial, aquí hay $ 80k.
- Soy un arquitecto que puede ayudar a proporcionar observabilidad para aplicaciones nativas de la nube basadas en contenedores.
- > ¡Impresionante! ¡Aquí hay $ 300k!
Cindy sridharan¿Cuál es la diferencia entre monitoreo y Observabilidad si hay una?
Mirando hacia atrás ...
Hace años, ejecutamos principalmente nuestro software en servidores físicos. Nuestras aplicaciones fueron monolitos construidos sobre LAMP u otras pilas. Verificar el tiempo de actividad fue tan simple como enviar pings regulares y verificar el uso de CPU / disco para su aplicación.
Cambio de paradigma
El cambio de paradigma principal provino de los campos de infraestructura y arquitectura. Las arquitecturas en la nube, los microservicios, Kubernetes y la infraestructura inmutable cambiaron la forma en que las empresas construyen y operan sistemas.
Como resultado de la adopción de estas nuevas ideas, los sistemas que hemos construido se han vuelto cada vez más distribuidos y efímeros.
Los marcos de virtualización, contenedorización y orquestación son responsables de proporcionar recursos computacionales y el manejo de fallas crea una capa de abstracción para hardware y redes.
Avanzar hacia la abstracción del hardware y las redes subyacentes significa que debemos centrarnos en garantizar que nuestras aplicaciones funcionen según lo previsto en el contexto de nuestros procesos comerciales.
¿Qué es el monitoreo?
El monitoreo es para las operaciones esencialmente lo que las pruebas son para el desarrollo de software. De hecho, las pruebas verifican el comportamiento de los componentes del sistema contra un conjunto de entradas en un entorno de espacio aislado, generalmente con una gran cantidad de componentes simulados.
El problema principal es que la cantidad de posibles problemas en la producción no se puede cubrir con pruebas de ninguna manera. La mayoría de los problemas en un sistema maduro y estable son incógnitas desconocidas que están relacionadas no solo con el desarrollo de software en sí, sino también con el mundo real.
Black Box vs. Monitoreo de caja blanca
Hay dos enfoques para el monitoreo.
En el caso del monitoreo de caja negra, tratamos el sistema o partes del mismo como una caja negra y los probamos en el exterior. Esto podría significar verificar las llamadas a la API, el tiempo de carga o la disponibilidad de diferentes partes del sistema. En este caso, la cantidad de información y control sobre el sistema es limitada.
El monitoreo de recuadro blanco se refiere a la situación, en la que derivamos información de los componentes internos del sistema. Esta no es una idea revolucionaria, pero recientemente ha llamado mucho la atención.
Entonces, ¿la Observabilidad es solo otro nombre para el monitoreo de caja blanca? No del todo.
Por qué necesitamos un nuevo tipo de monitoreo
A menudo, se hace una distinción entre el monitoreo y el concepto de Observabilidad, y este último se define como algo que recopila datos sobre el estado de la infraestructura / aplicaciones y los rastros de rendimiento de una forma u otra (https://thenewstack.io/monitoring-and -observabilidad-cuál es la diferencia y por qué importa /).
O, según
honeycomb.io :
- "Está comprobando el estado y el comportamiento de sus sistemas con respecto a una línea base conocida, para determinar si algo no se está comportando como se esperaba".
- "Puede escribir cheques Nagios para verificar que un montón de cosas están dentro de los umbrales buenos conocidos".
- "Puede crear paneles con Graphite o Ganglia para agrupar conjuntos de gráficos útiles".
- "Todas estas son excelentes herramientas para comprender las incógnitas conocidas sobre su sistema".
Ha evolucionado un gran ecosistema de productos como New Relic, HP y AppDynamics. Todas estas herramientas son perfectas para el monitoreo de bajo y medio nivel o para desenredar problemas de rendimiento.
Sin embargo, no pueden manejar consultas sobre datos con una alta cardinalidad y funcionan mal en el caso de problemas relacionados con problemas de integración de terceros o el comportamiento de grandes sistemas complejos con enjambres de servicios que trabajan en entornos virtuales modernos.
Por qué los paneles de control son inútiles
En realidad no lo son. Pero solo si sabes cuándo y dónde mirar. De lo contrario, es mejor mirar YouTube.
Los paneles no se escalan.
Imagine una situación en la que tiene un montón de métricas relacionadas con su infraestructura (por ejemplo, cpu_usage / disk quotas) y aplicaciones (por ejemplo, JVM allo_speed / GC Runs), etc. El número total de esas métricas puede crecer fácilmente a miles o decenas de miles. Todos sus paneles son verdes, pero luego se produce un problema en un servicio de integración de terceros. Sus paneles de control siguen siendo verdes, pero los usuarios finales ya están afectados.
Decide agregar verificaciones de servicios de integración de terceros a su monitoreo y obtener un conjunto adicional de métricas y paneles en su televisor. Hasta que surja el próximo caso.
Cuando se le pregunta por qué los clientes no pueden abrir un sitio, la respuesta a menudo se ve así:
La spaghettificación de tableros
Si bien la adopción de telemetría de diferentes partes del sistema es una práctica común, generalmente termina con un montón de espagueti dibujado en un tablero.
Estas son las métricas operativas de GitLab que están abiertas al público.Y esto es solo una pequeña parte de todo un ejército de tableros
Parece un tapiz donde es fácil perder el hilo.
Agregación de registros
Las herramientas de agregación de registros como ELK Stack o Splunk son utilizadas por la gran mayoría de las empresas de TI modernas. Estos instrumentos son increíblemente útiles para el análisis de la causa raíz o las autopsias. También se pueden usar para monitorear algunas condiciones que se pueden derivar de su flujo de registros.
Sin embargo, tiene un costo. Los sistemas modernos generan enormes cantidades de registros y un aumento en su tráfico puede agotar sus recursos ELK o elevar la tasa de facturación de Splunk a la luna.
Existen algunas técnicas de muestreo que pueden reducir la cantidad de los llamados registros aburridos en varios órdenes de magnitud y salvar todos los anormales. Puede proporcionar una visión general de alto nivel sobre el comportamiento normal del sistema y una vista detallada de cualquier evento problemático.
De registros a un modelo de eventos
Por lo general, las líneas de registro reflejan eventos que ocurren en el sistema. Por ejemplo, hacer una conexión, autenticar, consultar la base de datos, etc. La ejecución de todas las fases significa que se ha completado un trabajo. El evento de definición como un trabajo lógico puede verse como parte de los objetivos de nivel de servicio relacionados con un servicio en particular. Por "servicio" me refiero no solo a los servicios de software, sino también a ciertos dispositivos físicos, como sensores u otra maquinaria del mundo de IoT.
También es muy complementario a los principios de diseño basados en dominios. El aislamiento y el intercambio de responsabilidades entre servicios o dominios hacen que los eventos sean específicos para cada trabajo en cada parte del sistema.
Por ejemplo, los eventos del servicio de inicio de sesión se pueden separar por exitosos_logs, fallidos_logins con contexto dinámico propio.
Las métricas y los eventos deben construir una historia en torno a los procesos en el sistema.
Los eventos se pueden muestrear de tal manera que en el caso del comportamiento normal del sistema solo se almacena una fracción de ellos y todos los eventos problemáticos se almacenan tal cual. Los eventos se agregan y almacenan como indicadores clave de rendimiento en función de los objetivos de servicios particulares.
Puede reunir métricas de objetivos de servicio y sus metadatos relacionados que aprovechan las conexiones entre los problemas en cada momento.
Escrito con alta cardinalidad en mente, estos datos revelan las incógnitas desconocidas en el sistema.
¿Es esta una forma de instrumentación de software? Si Sin embargo, cuando compara las cantidades de datos que provienen del registro a nivel de depuración y la instrumentación completa, dividir los registros en eventos hace posible beber de una manguera contra incendios en el entorno de producción sin ahogarse en datos y costos.
"Definir un evento como un trabajo podría verse como relacionado con los objetivos de un servicio en particular".
Por qué no estamos preparados para soluciones completas de IA
AI es una buena palabra de moda para atraer inversiones de inicio. Sin embargo, el diablo siempre está en los detalles.
1. Reproducibilidad
El problema de un sistema totalmente basado en el aprendizaje automático (el llamado enfoque de IA completa) es que debido a que constantemente está aprendiendo nuevos comportamientos, no hay reproducibilidad. Si desea comprender por qué, por ejemplo, una condición dio como resultado una alerta, no puede investigarla porque los modelos ya han cambiado. Cualquier solución que se base en el aprendizaje constante del comportamiento enfrenta este problema.
Es esencial optimizar el sistema en sí mismo cuando opera con datos o métricas altamente granulares, pero es muy difícil hacerlo sin reproducibilidad.
2. Consumo de recursos
Para cualquier tipo de aprendizaje automático constante, necesita una cantidad significativa de recursos computacionales. Por lo general, esto toma la forma de conjuntos de datos de procesamiento por lotes. En el caso de algunos productos, los requisitos mínimos para procesar 200,000 métricas son v32CPU y 64 Gb RAM. Si desea duplicar la cantidad de métricas, necesita otra máquina que cumpla con los mismos requisitos.
3. Todavía no puede escalar la automatización completa del aprendizaje profundo
De acuerdo con una tesis de maestría escrita por Samreen Hassan Massak (aún no se ha completado por completo), el proceso de capacitación para miles de métricas requiere días de tiempo de CPU o horas de GPU. No puedes escalarlo sin gastar tu presupuesto.
4. velocidad
Las soluciones como Amazon Forecast que funcionan como servicios de procesamiento por lotes que ingieren datos y esperan a que finalice el cálculo no son adecuadas para eso.
5. Claridad
Según la experiencia de Google:
"Las reglas que capturan incidentes reales con mayor frecuencia deberían ser lo más simples, predecibles y confiables posible".
landing.google.com/sre/sre-book/chapters/monitoring-distributed-systemsCuando los modelos o las reglas cambian constantemente, pierde la comprensión del sistema y funciona como una caja negra.
Anomalías = Alertas?
Digamos que tiene miles de métricas y si desea tener buena Observabilidad, necesita recopilar datos cardinales altos. Cada latido del sistema generará fluctuaciones estadísticas en su enjambre de métricas.
https://berlinbuzzwords.de/15/session/signatures-patterns-and-trends-timeseries-data-mining-etsyLas principales lecciones que se pueden extraer del proyecto Kale de Etsy:
Alertar sobre anomalías de métricas eventualmente conducirá a grandes cantidades de alertas y trabajo manual jugando con umbrales y filtros de elaboración manual.
¿Por qué necesitamos un enfoque de transmisión?
Ganar Observabilidad y poner en evidencia las incógnitas desconocidas requiere datos altamente granulares que pueden clasificarse por centros de datos, versiones de compilación, servicios, plataformas y tipos de sensores. Agregarlos en cualquier combinación es combinatoria por su naturaleza.
Incluso si diseña cuidadosamente sus métricas y eventos, eventualmente terminará con una gran cantidad de ellos. Cuando se opera en esta escala en tiempo real, las consultas regulares o los trabajos por lotes tendrán una latencia y una sobrecarga significativas.
Cosas a considerar
Cualquier operación realizada en un flujo infinito de datos es todo un esfuerzo de ingeniería. Necesita lidiar con las implicaciones relacionadas con los sistemas distribuidos.
Al monitorear eventos, objetivos de nivel de servicio o KPI en un nivel alto, debe ser reactivo y no consultar constantemente sus datos, sino operar en una secuencia que pueda escalar horizontalmente y lograr un gran rendimiento y velocidad sin consumir una cantidad abrumadora de recursos
Algunos marcos de transmisión, como Apache Storm, Apache Flink y Apache Spark, están orientados hacia el procesamiento de tuplas y no hacia el procesamiento de series de tiempo fuera de la caja.
También hay problemas con la semántica de los sistemas distribuidos.
Supongamos que tiene muchas implementaciones en diferentes centros de datos. Puede tener un problema de red y el agente que almacena sus métricas de KPI no puede reenviarlas. Después de un tiempo, digamos 3 minutos, el agente envía estos datos al sistema. Y esta nueva información debería desencadenar una acción basada en esta condición. ¿Deberíamos almacenar esta ventana de datos en la memoria y verificar las condiciones no solo hacia atrás sino también hacia adelante a tiempo? ¿Qué tan grande debe ser esta ventana de desincronización? Operar en miles de métricas en tiempo real hace que estas preguntas sean muy importantes. No puede almacenar todo en la base de datos en el caso de los sistemas de procesamiento de flujo sin perder velocidad.
El análisis de flujo en tiempo real de datos de series temporales en sistemas distribuidos es complicado, porque los eventos relacionados con el comportamiento del sistema pueden estar fuera de orden y las condiciones que podrían surgir en función de estos datos dependen del orden de los eventos. Esto significa que se puede lograr fácilmente una semántica de al menos una vez, pero cuando solo una vez puede ser mucho más difícil.
Características deseables de una estrategia de monitoreo según el libro de trabajo de Google SRE
- "El diseño moderno generalmente implica separar la recopilación y la evaluación de reglas (con una solución como el servidor Prometheus), el almacenamiento de series temporales a largo plazo (InfluxDB), la agregación de alertas (Alertmanager) y el tablero (Grafana)".
- “Los sistemas basados en registros de Google procesan grandes volúmenes de datos altamente granulares. Hay un retraso inherente entre cuando ocurre un evento y cuando es visible en los registros. Para un análisis que no es urgente, estos registros pueden procesarse con un sistema por lotes, interrogarse con consultas ad hoc y visualizarse con paneles. Un ejemplo de este flujo de trabajo sería usar Cloud Dataflow para procesar registros, BigQuery para consultas ad hoc y Data Studio para los paneles ".
- “Por el contrario, nuestro sistema de monitoreo basado en métricas, que recopila una gran cantidad de métricas de cada servicio en Google, proporciona información mucho menos granular, pero casi en tiempo real. Estas características son bastante típicas de otros sistemas de monitoreo basados en registros y métricas, aunque hay excepciones, como los sistemas de registros en tiempo real o las métricas de alta cardinalidad ”.
- “En un mundo ideal, el código de monitoreo y alerta debe estar sujeto a los mismos estándares de prueba que el desarrollo del código. Si bien los desarrolladores de Prometheus están discutiendo el desarrollo de pruebas unitarias para el monitoreo, actualmente no existe un sistema ampliamente adoptado que le permita hacer esto ”.
- “En Google, probamos nuestro monitoreo y alertas utilizando un lenguaje específico de dominio que nos permite crear series temporales sintéticas. Luego escribimos aserciones basadas en los valores en una serie temporal derivada, o el estado de disparo y la presencia de etiquetas de alertas específicas ".
Muchas gracias a Charity Majors y Cindy Sridharan
Gracias a Sigrid Maasen por su ayuda