Monitorización Multifacética de Angie, un Fork del Servidor Web nginx#
Una descripción detallada de las capacidades de monitorización de Angie: API integrada para estadísticas, Console Light para visualización en tiempo real e integración con Prometheus sin módulos de terceros.
Una hermosa demostración en vivo es mejor que cualquier imagen: https://console.angie.software/#
Hola, querido lector. Mi nombre es Dmitry. Soy ingeniero de sistemas en la empresa Web Server. A lo largo de mi experiencia proporcionando servicios de soporte técnico, primero en la empresa Nginx, y ahora en la empresa que desarrolla el servidor web ruso Angie, respondemos a una pregunta muy popular: "¿Cómo organizo la monitorización del estado del servidor web?" Así es como.
Monitorización. "¿Para qué molestarse? ¡Todo está bien en los logs!"
Servidor Web Angie. "¿Por qué? Cuando existe *." Cómo instalar. "¿Hay una compilación para **?"
API. "¡Te digo que hay logs! Espera, déjame habilitarlos en producción." Qué proporciona. "¿Cuál es la diferencia con los logs?" Cómo configurar. "¿No funciona automáticamente?" Obtener la configuración del servidor web. "Pero existe angie -T."
Console Light – interfaz web. "¿¡Otro sistema de monitorización más?!1?1!!!" Qué muestra. "¿Qué quieres decir con tiempo real?" Cómo instalar. "¿De verdad solo un par de líneas de configuración?"
API para Prometheus. "¡Pero ya lo estoy usando! Bueno, sí, analizamos logs..." Cómo configurar Angie para la integración. "¿Cómo es esto sin njs?" Comparación con Console Light. "¿Los valores realmente coinciden?"
Conclusión. "¡Así que eso es lo que significa multifacético!"
1. Monitorización. "¿Para qué molestarse? ¡Todo está bien en los logs!"#
Entonces, hemos superado la situación en la que reaccionamos a incidentes en el funcionamiento del sistema de información basándonos en una llamada de un usuario. Ahora tenemos sistemas de monitorización completos en nuestra infraestructura, con recopilación de datos, un sistema de alertas y un botón de "arreglar todo".
Cuando respondemos preguntas de gerentes, arquitectos o especialistas en seguridad de la información sobre cómo garantizamos la observabilidad de uno de los componentes clave en el proceso de manejo de solicitudes de red a la infraestructura, con mayor frecuencia enumeramos lo siguiente. Tenemos métricas del sistema para el proceso del servidor web (cuánta CPU o RAM consume, cuánto tiempo lleva ejecutándose), tenemos datos de los logs y, con menos frecuencia, tenemos la capacidad de exportar métricas del servidor web utilizando extensiones de terceros.
Obtener métricas del sistema para un proceso es una práctica común, el mínimo indispensable para cualquier infraestructura. Pero a veces esto es extremadamente insuficiente. Vemos un consumo mínimo de CPU, pero el sitio muestra un error 502 Bad Gateway, y todo es terrible.
Obtener datos de los logs es simple. Pero los arquitectos señalan que esencialmente, estamos siguiendo retrospectivamente solicitudes que ya han sido procesadas por el servidor web en ese momento. En el caso de un ataque DoS, solo veremos en los logs cuando algunas solicitudes ya hayan sido procesadas como "fallidas al manejar". Pero necesitamos ver en la monitorización del servidor web las solicitudes que ya han llegado pero que aún no han sido procesadas por el servidor upstream. La monitorización debería, entre otras cosas, mostrar la preparación para un golpe, no mostrar el moretón en la cara.
Configurar la exportación de métricas desde tu servidor web utilizando soluciones de terceros es una opción bastante viable. La única pregunta es tu tiempo para entender la configuración, compilarla para tu sistema operativo y aceptar el riesgo de que mañana tu versión del servidor web pueda ser incompatible con un módulo que aún no se ha actualizado. Y recuerda, los especialistas en seguridad de la información nunca duermen.
Las características integradas de nuestro producto, que discutiremos más adelante, permiten una monitorización completa de la carga del servidor Web/Proxy en tiempo real, y también tienen una serie de capacidades avanzadas de integración con el sistema de monitorización en la infraestructura del cliente.
2. Servidor Web Angie. "¿Por qué? Cuando existe *"#
Para aquellos que no lo sepan, lo diré, y para otros les recordaré, que existe un producto llamado Angie, creado como un fork de nginx, desarrollado por la empresa Web Server. La empresa reúne a antiguos ingenieros principales de la empresa NGINX. Se distribuye bajo la licencia BSD, es legal, eso es lo que nos dijeron.
La base de código del servidor web Angie se bifurcó de Nginx 1.23.1. Desde entonces, hemos estado agregando nueva funcionalidad que no existe en la versión de código abierto de nginx. Al mismo tiempo, intentamos portar las actualizaciones de nginx a nuestro servidor web, asegurando la posibilidad de migración sin problemas para los usuarios de nginx a Angie.
Desde el primer lanzamiento, que fue en octubre de 2022, Angie incluye un módulo API que implementa una interfaz HTTP RESTful para obtener información básica sobre el servidor web en formato JSON, así como estadísticas sobre:
conexiones de clientes
zonas de memoria compartida
consultas DNS
solicitudes HTTP
caché de respuestas HTTP
sesiones del módulo stream
zonas de los módulos limit_conn http, limit_conn stream y limit_req
La lista completa de métricas se puede encontrar en la documentación.
Recientemente, se lanzó una nueva versión Angie 1.3.0, que implementa soporte para la salida de métricas en formato Prometheus. Hemos preparado una interfaz web para ver métricas en tiempo real desde una instancia seleccionada. Y es hora de hacer una pequeña prueba comparativa de las capacidades de monitorización del servidor web.
Entre la funcionalidad distintiva de Angie están:
Soporte de API para recopilar estadísticas, configuración y mucho más.
DNS dinámico con soporte para transformación de registros DNS SRV.
Vinculación de sesión de cliente usando el método sticky session o route.
2.1. Cómo instalar. "¿Hay una compilación para **?"#
Las instrucciones detalladas sobre cómo instalar Angie se presentan en el sitio web oficial en ruso e inglés.
Aunque soportamos 11 distribuciones de varias versiones en arquitecturas x86-64 y arm64, en este artículo solo proporcionaré los pasos necesarios para ilustrar las capacidades de monitorización del servidor web. Realizaré todas las instalaciones en el sistema operativo Debian.
Instalar Angie no es diferente de instalar cualquier otro paquete desde un repositorio. Primero, agrega la clave y el repositorio:
sudo apt-get update && \
sudo apt-get install --no-install-recommends --no-install-suggests --yes \
ca-certificates curl lsb-release && \
sudo curl -o /etc/apt/trusted.gpg.d/angie-signing.gpg \
https://angie.software/keys/angie-signing.gpg && \
echo "deb https://download.angie.software/angie/debian/ `lsb_release -cs` main" \
| sudo tee /etc/apt/sources.list.d/angie.list >/dev/null
E instala Angie:
sudo apt-get update && \
sudo apt-get install --no-install-recommends --no-install-suggests --yes \
angie
Listo. El servidor web está ejecutándose y la página de bienvenida está disponible en el puerto 80.
curl -I localhost HTTP/1.1 200 OK Server: Angie/1.3.0 ....
3. API. "¡Te digo que hay logs! Espera, déjame habilitarlos en producción"#
Cuando un cliente contacta con el soporte técnico, a menudo se le pide que proporcione logs para el diagnóstico. Una de las situaciones que se encuentran con frecuencia es que los logs del servidor web en producción están deshabilitados. Simplemente para ahorrar recursos. La cuestión de analizar logs y enviarlos al sistema de monitorización simplemente no surge. Sin logs, sin problemas. Pero, ¿qué pasa si aún así hacemos análisis de logs y construimos un sistema de monitorización basado en estos datos? ¿Cuál es la diferencia con respecto al uso de métricas a través de la API? Hay varios matices. Primero, los logs se escriben después de que la solicitud ha sido procesada. En otras palabras, cuando el último byte ha sido enviado al cliente. ¿Qué debemos hacer en este caso con conexiones de larga duración o clientes lentos? La API viene al rescate aquí. La métrica "processing" en "requests" dentro de "server_zones" te ayuda a averiguar cuántas solicitudes está procesando actualmente el servidor. Segundo, los logs no pueden decirte nada sobre las zonas de memoria compartida o las zonas de caché utilizadas por tu servidor. Sin embargo, su desbordamiento debido a un tráfico enorme o en varios casos de ataques al servidor puede llevar a resultados desastrosos, segfaults y, en consecuencia, caídas de conexión e incluso indisponibilidad del servicio. Aquí la API viene de nuevo a nuestro rescate. Puedes ver y calcular la ocupación de las zonas y responder a situaciones imprevistas a tiempo. Tercero, al obtener métricas del tiempo de ejecución a través de la API, simplemente obtienes valores más precisos en el momento. Y simplemente hay más de ellos de los que puedes extraer de los logs. Puedes ver el árbol completo de métricas en el sitio web oficial. Volviendo a la cuestión de las soluciones de terceros, el lector puede preguntar: "¿Por qué debería cambiar algo? He estado usando una solución integral basada en el módulo vts durante mucho tiempo". Aquí vale la pena señalar que soluciones como el módulo vts en realidad no proporcionan estadísticas en tiempo real, ya que trabajan en la fase de log y los contadores se calculan solo después de que se completa el procesamiento de la solicitud. En otras palabras, este tipo de solución tiene las mismas desventajas que la monitorización basada en logs. Para habilitar la API, es suficiente añadir la directiva "api" a la configuración. Comentemos las directivas "allow" y "deny" en "location /status/" en el archivo de configuración "/etc/angie/http.d/default.conf" para que podamos ver inmediatamente la página de la API en el navegador. (En producción, deberías configurar adecuadamente estas directivas por motivos de seguridad. Esto también se aplica a las siguientes partes de este artículo): Añadamos un par de zonas y upstream a la configuración para mayor claridad: Reinicia Angie para aplicar la configuración: y en la página /status/ de tu servidor ya verás JSON con las métricas de la API. Hablando de trabajar con la configuración del servidor web. Como bonificación adicional, la API ahora tiene la capacidad de mostrar la configuración de tu servidor. Específicamente la que Angie está ejecutando actualmente. Esto puede ser útil en varios casos, por ejemplo, si por alguna razón increíble eliminaste todas las configuraciones del servidor y quieres restaurarlas. Aquí la salida del comando "angie -T" no te ayudará, ya que el comando "angie -T" realiza una comprobación de sintaxis y muestra la configuración desde el disco. El archivo binario "angie" intentará analizar el archivo de configuración especificado por defecto al iniciar. Ahora, para entender si la configuración actualizada se ha aplicado, puedes comparar las salidas de la API y "sudo angie -T". O puedes hacerlo aún más simple y rastrear la generación de configuración. Angie rastrea la generación de configuración de cada uno de sus procesos; la numeración comienza desde uno cuando el servidor se inicia, y los números crecen con cada recarga de configuración y se indican en los nombres de los procesos. Después de una recarga de configuración exitosa (independientemente de si hay cambios), los números de generación para los procesos que recibieron la nueva configuración aumentarán, y si algunos procesos worker de generaciones anteriores continúan trabajando, esto será inmediatamente notable desde la salida del comando "ps aux | grep angie". La salida de la API en la sección /status/angie/ también mostrará la generación de configuración. Pero a diferencia de la salida de ps, la salida de la API solo mostrará la nueva generación de configuración.3.1. Qué proporciona. "¿Cuál es la diferencia con los logs?"#
3.2. Cómo configurar. "¿No funciona automáticamente?"#
location /status/ {
api /status/;
# allow 127.0.0.1;
# deny all;
}
upstream foo {
zone http-upstream-foo 256k;
server 127.0.0.2 max_conns=10 max_fails=10;
server 127.0.0.3 max_conns=10 max_fails=10;
server 127.0.0.4 max_conns=10 max_fails=10;
}
server {
#...
status_zone example;
#...
location / {
#...
status_zone location_zone;
}
#...
}
sudo angie -t && sudo service angie reload
3.3. Obtención de la configuración del servidor web. "Pero existe angie -T"#
4. Console Light – interfaz web. "¿¡Otro sistema de monitorización más?!1?1!!!"#
A partir de la versión 1.3.0 de Angie, se añadió la funcionalidad Console Light—una consola visual ligera para la monitorización de actividad en tiempo real que muestra indicadores clave de carga y rendimiento del servidor. Y en general, facilita al administrador el seguimiento de la viabilidad y el estado del servidor. La característica de esta simple página web es la visualización de métricas en tiempo real para una instancia específica del servidor web. La página se actualiza con cierta periodicidad (esto se puede configurar). Ten en cuenta que si tienes un clúster de varios servidores web, entonces cada instancia en el clúster tiene su propia consola visual separada configurada. En realidad, todas las métricas mencionadas anteriormente están agrupadas aquí en pestañas recomendadas para el seguimiento. Por ejemplo, puedes encontrar la métrica "processing" en "requests" en la pestaña HTTP Zones. Aquí se llamará Current. Y puedes ver la ocupación de las zonas en las pestañas Shared Zones y Caches. Puedes ver nuestra versión demo de Console Light en https://console.angie.software/, y una descripción detallada de las pestañas y métricas recopiladas allí se puede encontrar en la sección de documentación. Esta funcionalidad se suministra como un paquete separado; no dejes que este hecho te confunda, mi lector. Console Light está completamente integrado con Angie y la API. Instalemos el paquete Console Light para ver las estadísticas actuales del servidor. Para hacer esto, simplemente ejecuta: Luego conecta Console Light colocando "location /console" en el contexto "server" del archivo de configuración de Angie ("/etc/angie/http.d/default.conf"). Así: Puedes encontrar información más detallada en el sitio web oficial. Reiniciemos Angie: Y, yendo a /console, veremos una página con métricas. Aquí verás inmediatamente cómo se rellenan las métricas Requests y Responses. Dado que estamos configurando nuestra consola en el mismo "server" donde se encuentra la "status_zone", vemos cómo la propia consola, al acceder a la API, genera estadísticas para nosotros. Señalaré de nuevo que en producción no deberías hacer tal configuración. Es mejor usar un bloque "server" separado utilizado solo para monitorización.
4.1. Qué permite ver. "¿Qué significa en tiempo real?"#
4.2. Cómo instalar. "¿Realmente solo un par de líneas de configuración?"#
sudo apt-get install angie-console-light
location /console {
alias /usr/share/angie-console-light/html;
index index.html;
location /console/api/ {
api /status/;
}
}
sudo angie -t && sudo service angie reload
5. API para Prometheus. "¡Pero ya lo estoy usando! Bueno sí, analizamos logs..."#
Una solución bastante popular para construir un sistema de monitorización es usar Prometheus para recopilar métricas. Asumimos que ya tienes este servicio instalado. Lo más probable es que lo alimentes a través del análisis de logs o uses exportadores de terceros.
En nuestro caso, hemos hecho una solución integrada para exportar métricas en formato Prometheus. Señalaré que tenemos plantillas flexiblemente configurables para que puedas añadir tu propio toque a la recopilación de métricas. La lista completa de métricas disponibles está recopilada en la plantilla all. El nuevo paquete ya incluye una plantilla con todas las métricas disponibles, por lo que será suficiente simplemente habilitar la entrega de estas métricas en una ubicación conveniente añadiendo la directiva "prometheus". Reinicie Angie: Y al solicitar la dirección /metrics/, veremos el formato familiar de Prometheus. Puede encontrar ejemplos en línea de exportación de métricas desde nginx usando njs. En nuestro caso, no se utiliza ningún runtime de js; el cálculo y la entrega ocurren en el runtime del servidor web con una sobrecarga mínima. Como ingeniero, me interesaba ver si había alguna diferencia entre visualizar las métricas a través de Prometheus+Grafana o a través de Console Light. Configuré un entorno de prueba simple, configuré el servidor web, las integraciones con Prometheus y Console Light. Creé carga artificial en el servidor web usando wrk y scripts. En las capturas de pantalla a continuación, puede comparar las métricas correspondientes. Resultó bastante interesante. En general, las métricas son similares en todo; las diferencias comienzan cuando se aumenta el intervalo de recopilación de métricas. Si Console Light obtiene métricas cada segundo, entonces en Grafana un intervalo de 2 minutos muestra métricas con un retraso y con alguna diferencia. Y, como resultado, hay diferencias en las capturas de pantalla. En el momento en que el uso del disco comenzó a crecer alarmantemente, Grafana todavía mostraba que todo estaba bien. Por supuesto, eventualmente los indicadores se alinearon. La situación con los indicadores de solicitudes en tiempo de ejecución es también similar. Mucho depende de la configuración de Grafana y Prometheus en sí; necesitará elegir intervalos que sean adecuados para usted. Pero esté preparado para que con intervalos más cortos, los servicios necesiten almacenar más datos en el disco.5.1. Cómo configurar Angie para la integración. "¿Cómo funciona esto sin njs?"#
location /metrics/ {
prometheus all;
}
sudo angie -t && sudo service angie reload
5.2. Comparación con Console Light. "¿Coinciden realmente los valores?"#
6. Conclusión. "¡Así que eso es lo que significa multifacético!"#
No se puede decir que exista una única forma correcta de organizar un sistema de monitorización de servidor web. Pero hemos intentado proporcionar flexibilidad en el servidor web Angie para configurar una solución que se adapte a usted.
Como ingeniero, a menudo me encuentro con situaciones en las que los usuarios piden ayuda cuando todo ya ha sucedido y la configuración aún no se ha realizado. Por lo tanto, permítame tomarme un momento para recordarle: es mejor realizar todas las configuraciones necesarias con anticipación para estar preparado para situaciones imprevistas. Afortunadamente, existen instrucciones detalladas para esto.
Entonces, sobre el enfoque de monitorización versátil. La naturaleza multifacética se expresa en el hecho de que puede continuar analizando logs, puede usar el servidor web Angie, que proporciona una API con métricas extendidas. Puede echar un vistazo al estado del servidor web en una página web simple, Console Light. Y finalmente, puede realizar una integración completa de la información del estado del servidor web en su sistema de recopilación de métricas basado en Prometheus.
¡Por favor, úselo! ¡Fue un placer ayudarle!
