Mejor rendimiento y seguridad al monitorear registros, métricas y más

En el artículo anterior de esta serie, The Everything Guide to Data Collection in DevSecOps , discutimos la importancia de la recopilación de datos. En este artículo, exploraremos el papel del monitoreo en la observabilidad, especialmente en lo que se refiere a la seguridad, el rendimiento y la confiabilidad.

El monitoreo es esencial para detectar problemas y valores atípicos a medida que ocurren en la producción y permite que los equipos de DevSecOps identifiquen y aborden los problemas antes de que causen daños graves. Supervisar las degradaciones del rendimiento o la actividad sospechosa puede generar alertas y respuestas automáticas para aislar posibles problemas o ataques.

En este artículo, veremos el monitoreo en detalle, brindaremos varios casos de uso y mejores prácticas, y discutiremos cómo el monitoreo puede mejorar específicamente la seguridad, el rendimiento y la confiabilidad a través de la observación.

¿Cuál es el papel del monitoreo en la observabilidad?

En un sistema observable, recopilamos datos de registros, métricas y seguimientos distribuidos. Y mientras que para sistemas muy pequeños puede navegar y buscar manualmente los registros, visualizar las métricas como gráficos y rastrear a través de diagramas que muestran cómo fluye el tráfico a través del sistema para identificar problemas, a escala, esto no es suficiente. Necesita monitoreo, un proceso automatizado que vigile estos datos y le avise apropiadamente. (Para un tratamiento más detallado sobre la diferencia entre monitoreo y observabilidad, puede consultar ).

En una empresa, necesita formas automatizadas de filtrar, agregar, enriquecer y analizar todos estos datos. Las empresas también necesitan formas automatizadas de actuar cuando se detecta algo inusual. La respuesta automática puede notificar al equipo responsable o incluso tomar medidas correctivas directamente. En otros campos como la medicina, la monitorización de las constantes vitales de los pacientes es una actividad clave, que salva vidas. El monitoreo de los sistemas de software es muy similar, e incluso usamos la misma metodología cuando realizamos controles de salud y discutimos la salud de diferentes componentes. Suficiente teoría, veamos algunos ejemplos concretos de monitoreo.

Casos de uso de monitoreo para la observabilidad

Estos son algunos casos de uso típicos que aprovechan el monitoreo:

• Las aplicaciones web son una parte importante de muchos sistemas distribuidos a gran escala y son clave para el éxito de los primeros negocios digitales. Supervisar las aplicaciones en contenedores de Kubernetes o simplemente los registros del servidor web en busca de una aparición excesiva de códigos de error (como 4xx o 5xx ) puede ayudar a un equipo a abordar los problemas de rendimiento y confiabilidad antes de que se conviertan en problemas importantes.
• A nivel de infraestructura, es importante monitorear la CPU, la memoria y el almacenamiento de sus servidores. Como la mayoría de las empresas, es probable que utilice el ajuste de escala automático para que su sistema pueda asignar más capacidad. Los registros de la plataforma capturan cuando hay cambios en los recursos, como cuando se aprovisionan, desaprovisionan o reconfiguran. Sin embargo, monitorear estas métricas y registros de recursos puede ayudarlo a asegurarse de que está trabajando dentro de las cuotas y los límites, y puede ayudar a su organización en lo que respecta a la planificación y el presupuesto de recursos.
• Los almacenes de datos están en el corazón de la mayoría de los sistemas a gran escala. Si sus datos se pierden, se corrompen o no están disponibles, entonces tiene una situación grave en sus manos. Para realizar un seguimiento de sus datos, debe monitorear las conexiones de la base de datos, las métricas de duración de las consultas, el espacio en disco, las copias de seguridad y las tasas de error. También debe comprender sus almacenes de datos y establecer alertas cuando observe valores que están fuera del rango esperado, como consultas lentas, alta tasa de errores o poco espacio en disco. También puede configurar el registro de sus bases de datos para capturar conexiones, consultas y cambios en campos o tablas. Supervisar los registros de su base de datos puede ayudarlo a detectar no solo dónde puede mejorar su rendimiento y confiabilidad, sino también la seguridad si se están realizando operaciones maliciosas (o no intencionales).

Tenga en cuenta que el monitoreo es mucho más complicado que establecer una condición simple (como "más de cinco consultas INSERT en la base de datos de orders en dos minutos") y disparar una alerta cuando se cumple esa condición. La estacionalidad puede estar en juego, con patrones de uso que provocan picos en ciertos momentos del día, la semana o el año. El monitoreo efectivo que detecta comportamientos inesperados tiene en cuenta el contexto y puede reconocer tendencias basadas en datos anteriores.

Este tipo de monitoreo, especialmente cuando se implementa con una herramienta que combina observabilidad, monitoreo y seguridad a escala, puede ser inmensamente efectivo, como en de Sumo Logic e Infor, donde Infor pudo ahorrar 5000 horas de tiempo dedicado a incidentes

¿Cómo contribuye específicamente el monitoreo a mejorar el rendimiento y la confiabilidad?

El monitoreo mejora el rendimiento y la confiabilidad de un sistema mediante la detección temprana de problemas para evitar la degradación. Los problemas de rendimiento a menudo se convierten en problemas de disponibilidad y confiabilidad. Esto es especialmente cierto en presencia de tiempos de espera. Por ejemplo, suponga que una aplicación expira después de 60 segundos. Debido a un problema de rendimiento reciente, muchas solicitudes de repente tardan más de 60 segundos en procesarse. Todas estas solicitudes ahora fallarán y la aplicación ahora no es confiable.

Una mejor práctica común para abordar esto es monitorear las cuatro señales doradas de cualquier componente en la ruta crítica de los servicios y aplicaciones de alta prioridad: latencia, tráfico, errores y saturación.

Latencia

¿Cuánto tiempo se tarda en procesar una solicitud? Tenga en cuenta que la latencia de las solicitudes exitosas puede ser diferente a la de las solicitudes fallidas. Cualquier aumento significativo en la latencia puede indicar una degradación del rendimiento del sistema. Por otro lado, cualquier disminución significativa podría ser una señal de que se salta algún procesamiento. De cualquier manera, el monitoreo llamará la atención sobre el posible problema.

Tráfico

Supervisar el tráfico le permite comprender la carga general de cada componente. El tráfico se puede medir de diferentes maneras para diferentes componentes. Por ejemplo:

• API REST: el número de solicitudes
• Un servicio backend: la profundidad de una cola
• Un componente de procesamiento de datos: el total de bytes de datos procesados.

Un aumento en el tráfico puede deberse al crecimiento orgánico del negocio, lo cual es bueno. Sin embargo, también puede indicar un problema en un sistema ascendente que genera un tráfico inusualmente mayor que antes.

errores

Un aumento en las tasas de error de cualquier componente impacta directamente en la confiabilidad y utilidad del sistema. Además, si las opciones fallidas se retiran automáticamente, esto puede generar un aumento en el tráfico y, posteriormente, puede generar problemas de rendimiento.

Saturación

De los recursos disponibles, ¿cuántos utiliza el servicio o la aplicación? Esto es lo que le dice el monitoreo de saturación. Por ejemplo, si un disco está lleno, un servicio que escribe registros en ese disco fallará en cada solicitud posterior. En un nivel superior, si un clúster de Kubernetes no tiene espacio disponible en sus nodos, los nuevos pods estarán pendientes y no programados, lo que puede generar problemas de latencia.

Como notará, las cuatro señales doradas están relacionadas entre sí. Los problemas a menudo se manifiestan a través de múltiples señales.

¿Cómo contribuye específicamente el monitoreo a mejorar la seguridad?

Si bien cualquier problema de salud del sistema puede afectar directa o indirectamente la seguridad, existen algunas amenazas directas que el monitoreo puede ayudar a detectar y mitigar.

• Cualquier anomalía, como un uso excesivo de la CPU o un alto volumen de solicitudes, tal vez un atacante que intente causar fallas de segmentación, realizar criptominería ilegal o lanzar un ataque DDoS en el sistema.
• Un número inusual de paquetes que llegan a puertos inusuales podría ser un de golpe de puerto.
• Una gran cantidad de errores 401 (errores de autenticación) con nombres de usuario válidos y contraseñas no válidas podría ser un ataque de diccionario.
• Una gran cantidad de errores 403 (acceso prohibido) puede ser una escalada de privilegios por parte de un atacante que usa una cuenta comprometida.
• Las cargas útiles no válidas para las API públicas que dan como resultado un aumento de 400 errores pueden ser un atacante que intenta bloquear malintencionadamente sus aplicaciones web públicas.
• Una descarga de grandes cantidades de datos o cualquier dato confidencial fuera del horario comercial puede ser un ataque de exfiltración por parte de un empleado comprometido o un infiltrado deshonesto.

Mejores prácticas de monitoreo para mejorar el rendimiento y la seguridad

Un sistema está hecho de múltiples componentes, pero es más que la suma de sus partes. En un nivel básico, debe monitorear cada componente de su sistema (al menos en las rutas críticas) en busca de las cuatro señales doradas . ¿Qué significa esto en la práctica?

• Observando las métricas clave
• Establecimiento de los rangos métricos para el funcionamiento normal
• Configuración de alertas cuando los componentes se desvían del rango aceptable

También debe prestar mucha atención a las dependencias externas . Por ejemplo, si se ejecuta en la nube o se integra con un proveedor de servicios externo, debe monitorear los puntos finales públicos de los que depende y establecer alertas para detectar problemas. Si un tercero está inactivo o su rendimiento se degrada, esto puede causar una falla en cascada en su sistema.

No es posible tener componentes 100% confiables. Sin embargo, el monitoreo puede ayudarlo a crear un sistema confiable a partir de componentes no confiables al detectar problemas con los componentes, tanto internos como externos, y reemplazarlos o degradar correctamente el servicio . Por ejemplo, si está ejecutando su sistema en una configuración multizona y hay un problema en una zona, entonces el monitoreo puede detectarlo y desencadenar el redireccionamiento (manual o automático) de todo el tráfico a otras zonas.

Por seguridad, las cuatro señales también pueden ser indicadores auxiliares de un compromiso . Este es especialmente el caso, por ejemplo, si ve un aumento en su dispositivo de punto final o CPU de carga de trabajo en la nube, o un aumento en la cantidad de intentos fallidos de inicio de sesión. Sin embargo, la supervisión de la seguridad debe ser muy deliberada, ya que se trata de adversarios malintencionados. Debe definir el servicio de ataque de cada componente y de todo el sistema y asegurarse de que la información que recopila sea suficiente para detectar problemas . Por ejemplo, para detectar la exfiltración de datos, puede monitorear las direcciones IP y la cantidad de datos enviados fuera de su red interna por diferentes aplicaciones y servicios. Si no tiene esos datos, estará ciego a esa metodología de ataque.

Implementación de una estrategia de monitoreo

Una vez que configure su recopilación de datos, puede seguir los pasos a continuación para implementar una estrategia de monitoreo sólida y efectiva.

1. Identificar los activos críticos.

Ya ha realizado un inventario completo de todos sus activos como parte de la recopilación de datos. Ahora, su tarea es identificar los activos críticos que deben monitorearse de cerca para prevenir y mitigar los desastres. Es fácil decir, "simplemente monitoree todo", pero hay costos a considerar con el monitoreo. Supervisar y generar alertas para sus entornos de preparación y desarrollo o servicios experimentales puede generar una gran cantidad de estrés innecesario para sus ingenieros. Las alertas frecuentes a las 3 AM para problemas insignificantes causarán fatiga de alertas, lo que paralizará el impulso de su equipo para abordar un problema cuando realmente importa.

2. Asigne un propietario para cada activo crítico.

Una vez que identifica los activos críticos, necesita un propietario claro para cada uno. El propietario puede ser una persona o un equipo. En el caso de una persona, asegúrese de identificar también una alternativa. También es importante mantener la propiedad de los activos a medida que las personas se unen y abandonan la organización o se trasladan a otros roles y equipos.

3. Definir alertas para activos críticos.

En última instancia, su estrategia de monitoreo vivirá o morirá en función de cómo defina las alertas para los activos que están en mal estado o potencialmente comprometidos. Debe comprender qué es lo normal para cada activo.

Si está monitoreando métricas, definir "normal" significa asociar un atributo (como la utilización de la CPU) con un rango de valores (como "50%-80%"). La banda normal puede cambiar dinámicamente con el negocio y puede variar en diferentes momentos y ubicaciones. En algunos casos, es posible que solo tenga techos o pisos. Al definir rangos normales, crea alertas para notificar al propietario de un activo cuando su activo está funcionando fuera del rango normal.

Si está monitoreando registros, las alertas generalmente se definen en función del resultado de ciertas consultas de registro (como "número de errores 404 registrados en todos los servicios API en los últimos cinco minutos") que cumplen o no cumplen una condición (como "es menos de 10”). pueden ayudar.

4. Defina runbooks para cada alerta.

Cuando se dispara una alerta crítica, ¿qué hace? Lo que no quiere hacer es tratar de descubrir su estrategia en el acto, mientras los clientes tuitean sobre los productos poco confiables de su empresa y la gerencia entra en pánico.

Un runbook es una receta de pasos fáciles de seguir que prepara y prueba con anticipación para ayudarlo a recopilar información adicional (por ejemplo, qué paneles mirar y qué scripts de línea de comandos ejecutar para diagnosticar la causa raíz) y mitigar acciones (por ejemplo, implementar la versión anterior de la aplicación). Su runbook debería ayudarlo a identificar rápidamente el problema en un problema específico e identificar a la mejor persona para manejarlo.

5. Configure un proceso de guardia.

Tiene propietarios, alertas y runbooks. A menudo, las alertas no son lo suficientemente específicas como para asignarlas directamente a los propietarios. La mejor práctica es asignar ingenieros de guardia a diferentes áreas del negocio. Este ingeniero de guardia recibirá la alerta, seguirá el runbook, mirará el panel e intentará comprender la causa raíz. Si no pueden entender o solucionar el problema, lo derivarán al propietario. Tenga en cuenta que este proceso puede ser complicado; a menudo, un problema ocurre debido a una cadena de fallas que requieren que múltiples partes interesadas colaboren para resolver el problema.

6. Avanza hacia la autocuración.

Los runbooks son geniales, pero mantener runbooks complejos y capacitar a los ingenieros de turno para que los sigan requiere mucho esfuerzo. Y al final, su proceso de remediación aún depende de un ser humano lento y propenso a errores. Si su runbook no está actualizado, seguirlo puede empeorar la crisis.

En teoría, un runbook se puede ejecutar mediante programación. Si el runbook dice, "cuando se activa la alerta X, el proceso Y debe reiniciarse", entonces un script o programa puede recibir una notificación de la alerta X y reiniciar el proceso Y. El mismo programa puede monitorear el proceso Y después del reinicio, asegurarse de que todo esté bien. y eventualmente generar un informe del incidente, todo sin despertar al ingeniero de guardia. Si la acción de autorreparación falla, se puede contactar al ingeniero de guardia.

7. Establecer un proceso post-mortem.

La autocuración es increíble, sin embargo, una onza de prevención vale más que una libra de cura, por lo que es mejor prevenir los problemas en primer lugar. Cada incidente es una oportunidad para aprender y posiblemente prevenir toda una clase de problemas. Por ejemplo, si ocurren múltiples incidentes porque el código con errores llega a producción, entonces una lección de las autopsias de incidentes podría ser mejorar las pruebas en la etapa de preparación. Si la respuesta del ingeniero de guardia a una alerta fue demasiado lenta o el runbook no estaba actualizado, esto puede sugerir que el equipo debería invertir en algunas prácticas de recuperación automática.

Conclusión

El monitoreo es una parte crucial de la observabilidad en general y de la observabilidad para la seguridad en particular. No es práctico a gran escala que los humanos "simplemente miren de vez en cuando" varios paneles y gráficos para detectar problemas. Necesita un conjunto completo de prácticas de respuesta a incidentes que incluyan la identificación de propietarios, la configuración de alertas, la escritura de runbooks, la automatización de runbooks y la configuración de procesos de guardia y procesos post-mortem.

¡Que tengas un gran día!