Estado de NGINX Stub: supervisar en tiempo real la actividad del servidor web

Qué indica el estado «stub» de NGINX

Estado de NGINX Stub Proporciona métricas básicas del servidor web en formato de texto a través de un punto final HTTP configurado. La respuesta describe la actividad del conjunto de procesos de NGINX consultado: en concreto, las conexiones de los clientes y el número total de solicitudes registradas. Puedes consultarla localmente y compararla repetidamente sin necesidad de utilizar un sistema de monitorización completo.

Para ello, debes distinguir entre dos tipos de valores: uno Instantánea muestra, por ejemplo, cuántas conexiones de cliente hay activas en ese momento. Los contadores totales como requests Por el contrario, indican el número total de consultas registradas. Solo la comparación de varias lecturas de contador en intervalos de tiempo conocidos permite determinar la tasa de consultas.

Estos valores no son una medición directa de la carga de la CPU o de la memoria, ni representan un porcentaje de la capacidad disponible del servidor web. Un gran número de conexiones abiertas puede deberse a diversas causas y tener distintos costes. Por lo tanto, para evaluar la carga real, necesitarás además métricas de recursos e información sobre los tiempos de respuesta y los errores.

El estado «Stub» no desglosa las cifras por sitio web virtual ni por URL solicitada. Si una instalación aloja varios sitios, a partir del punto final por sí solo no se puede determinar cuál de ellos es el responsable de un aumento. Si hay varias instancias de NGINX, debes registrar sus valores por separado y asignarlos de forma inequívoca.

La propia consulta de la página de estado es, en sí misma, una solicitud HTTP e influye ligeramente en los contadores observados. Esto hay que tenerlo en cuenta a la hora de interpretar volúmenes de solicitudes reducidos o consultas muy frecuentes. Una sola consulta solo ofrece, en cualquier caso, una visión parcial; solo la evolución a lo largo del tiempo muestra si la actividad ha cambiado.

Distinguir entre conexiones y consultas

El valor Conexiones activas Incluye las conexiones activas de los clientes, incluidas las conexiones en espera. Por lo tanto, no solo cuenta las conexiones a través de las cuales se está transmitiendo una respuesta en ese momento. Los estados «Reading», «Writing» y «Waiting» ayudan a contextualizar este número total, pero no describen ni el consumo de CPU ni el número de aplicaciones activas.

Cuando se recibe una solicitud, la conexión se encuentra en el estado «Reading» mientras NGINX lee el encabezado de la solicitud. Posteriormente, puede pasar al estado «Writing» cuando NGINX procesa o escribe la respuesta. Esto no significa que durante todo ese tiempo se estén enviando realmente bytes al cliente: la espera de una respuesta del servidor de origen también puede formar parte de este proceso.

Si una conexión permanece abierta tras una respuesta para recibir más solicitudes, puede considerarse como En espera aparecen. Este estado incluye las conexiones de cliente inactivas que esperan una nueva solicitud. Por lo tanto, un valor elevado de «Waiting» por sí solo no demuestra que haya una sobrecarga; también puede corresponder a un funcionamiento con muchas conexiones reutilizables.

Las conexiones y las solicitudes son magnitudes diferentes: a través de una conexión «keepalive» pueden ejecutarse varias solicitudes de forma sucesiva. En HTTP/2, se pueden transmitir varias solicitudes a través de una misma conexión. Por lo tanto, no se puede deducir un número fijo de solicitudes a partir del número de conexiones abiertas, y el contador de solicitudes no tiene por qué aumentar en la misma proporción que los contadores de conexiones.

Para una evaluación práctica, conviene realizar una comparación a lo largo de varias consultas: si el tiempo de espera aumenta, mientras que los tiempos de respuesta y los errores no presentan anomalías, se trata, en un primer momento, de una simple observación y no de un motivo de alarma. En el artículo sobre... se explica cómo se pueden configurar la reutilización y sus límites. Solicitudes Keepalive de NGINX.

Comprobar el módulo y la versión

Para utilizar Stub Status, necesitas una instalación de NGINX con el módulo ngx_http_stub_status_module, acceso a su configuración y, posteriormente, la posibilidad de consultar el punto final protegido desde el espacio de red previsto. El módulo no se incluye de forma predeterminada en la compilación de NGINX. Que un paquete de distribución lo contenga depende del paquete en cuestión y debe comprobarse in situ.

Comprueba en el terminal la versión y los parámetros de configuración del archivo binario de NGINX que utiliza realmente el servicio. El siguiente comando muestra esta información; entre los parámetros se indica --with-http_stub_status_module a la opción de compilación correspondiente.

nginx -V

El factor decisivo es la archivo binario correcto: Un programa iniciado a través de la ruta de búsqueda nginx puede tratarse de una instalación distinta a la que ejecuta el servicio. En caso de duda, comprueba la configuración del servicio y el programa de inicio que se utiliza en ella. A continuación, si es necesario, ejecuta explícitamente el archivo binario en cuestión, en lugar de deducir el servicio en producción a partir de la salida de otra instalación.

La versión también influye en la forma de escribir la directiva. Desde NGINX 1.7.5, se utiliza stub_status Se utiliza sin ningún argumento; las versiones anteriores requerían cualquier argumento, por ejemplo: on. El límite de versión es una indicación de compatibilidad, no una suposición sobre qué versión está instalada en tu sistema.

Si la opción de compilación no está presente en la instalación comprobada, antes de realizar cualquier cambio en la configuración debes aclarar qué paquete o compilación es la adecuada para tu entorno. Una ubicación de estado por sí sola no sustituye a un módulo que falte. Los cambios en los paquetes y en la configuración de los servicios deben seguir el procedimiento de operación y aprobación correspondiente.

Configurar el punto final de estado como protegido

Para consultar el estado de forma local, puedes utilizar un Escucha de bucle cerrado Configurar. El siguiente ejemplo es un archivo de configuración para el actual http-Contexto, no es un comando de terminal. Requiere que el módulo «stub-status» esté disponible y que el puerto de ejemplo 8088 en la dirección en cuestión no esté ya ocupado por otro servicio.

server {
    listen 127.0.0.1:8088;
    server_name localhost;

    location = /stub_status {
        stub_status;
        allow 127.0.0.1;
        deny all;
    }
}

La vinculación con 127.0.0.1 limita este listener a la interfaz de bucle cerrado IPv4 local. La ubicación exacta solo asigna la ruta indicada; la directiva stub_status proporciona allí los datos de estado. Por lo tanto, no se puede acceder al listener a través de otras interfaces IPv4, independientemente de si el resto de sitios web son públicos.

El Normas de acceso complementan la regla: NGINX las comprueba una tras otra hasta encontrar la primera que coincide. Se permite la dirección IPv4 local; todas las demás direcciones se rechazan. Dado que en esta ubicación hay reglas propias, no se heredan adicionalmente las reglas de acceso de un contexto superior. Por lo tanto, comprueba la configuración completa antes de aplicar el ejemplo.

En el caso de los contenedores, el espacio de red es fundamental: un exportador en un contenedor independiente accede a través de su propio localhost Normalmente no es la interfaz de bucle cerrado del contenedor de NGINX. Para realizar una consulta remota, necesitas una ruta de conexión privada planificada específicamente y los controles de acceso adecuados. No publiques la página de estado sin más; contiene información operativa.

Comprobar la configuración y consultar el estado

Una vez introducidos los datos, comprueba primero la configuración en el terminal. El siguiente comando comprueba la sintaxis e intenta abrir los archivos a los que se hace referencia. Para ello, utiliza el archivo binario de NGINX correspondiente al servicio y, si procede, su ruta de configuración específica; una comprobación satisfactoria no activa aún el cambio.

nginx -t

A Recarga autorizada Es un paso productivo independiente. Ejecútalo solo tras recibir la autorización y de acuerdo con los procedimientos operativos de tu entorno. Al realizar un reload, NGINX recarga la configuración, inicia nuevos workers con la nueva configuración y cierra los antiguos de forma ordenada. A continuación, comprueba que la operación se haya realizado correctamente y revisa los registros, en lugar de dar por hecho que el cambio se ha aplicado solo porque la comprobación sintáctica haya dado resultado positivo.

Una vez aprobada la activación, puedes acceder al punto final de forma local en el mismo espacio de red mediante curl consultar. El interruptor -i Muestra, además del cuerpo de la respuesta, el estado HTTP y los encabezados. El siguiente ejemplo da por hecho que el listener y la ruta se han definido en el archivo de configuración.

curl -i http://127.0.0.1:8088/stub_status

Se espera una respuesta HTTP correcta con datos de estado como Texto, no como JSON. En caso de error, el código de estado y los registros de NGINX ayudan a localizar el problema. Sin embargo, una consulta local satisfactoria solo demuestra que esa vía de acceso funciona: no garantiza que no haya otra configuración que permita acceder al punto final desde el exterior.

Leer valores de estado y calcular tasas

La salida combina los estados actuales de las conexiones con los valores acumulados. A la hora de interpretar los datos, esta distinción es más importante que el valor absoluto de un dato concreto: un valor actual describe el estado en el momento de la consulta; un contador general que recoge los eventos contabilizados hasta ese momento. La tabla clasifica los distintos campos y los errores típicos.

Del contador requests se puede calcular una media Índice de consultas Para calcularlo en un intervalo: resta el primer valor del segundo y divide la diferencia entre los segundos transcurridos. Ejemplo ilustrativo de cálculo, no se trata de una medición: si el valor pasa de 12 000 a 12 600 en 60 segundos, 600 dividido entre 60 da una media de 10 solicitudes por segundo.

Este promedio no muestra ni el pico máximo a corto plazo ni qué URL se han visitado. Anota, para cada consulta, la hora y la instancia consultada. Si el contador desciende o si cambias de instancia, no debes interpretar la diferencia simple como tasa sin comprobarla; inicia una nueva serie comparativa para la instancia en cuestión.

Si comparas intervalos de diferente duración, utiliza siempre el tiempo realmente transcurrido en lugar del intervalo de consulta previsto. Por ejemplo, una consulta retrasada dos minutos requiere un divisor diferente al de una consulta tras un minuto. Un análisis a más largo plazo suaviza en mayor medida las fluctuaciones a corto plazo; los intervalos cortos hacen que los cambios sean más visibles, pero aumentan la proporción de consultas de estado.

La propia consulta de estado es también una solicitud HTTP e influye ligeramente en los contadores observados. Esto cobra especial relevancia cuando el tráfico es muy bajo o las consultas son frecuentes. Un intervalo de consulta regular y documentado facilita tener en cuenta estos componentes de monitorización a la hora de interpretar los datos.

Si hay varias instancias, primero debes calcular la tasa a partir de los valores sucesivos de cada una de ellas. Solo después se pueden agrupar las tasas correspondientes a períodos comparables. Si falta una lectura o cambia la asignación de una instancia, la brecha resultante debe seguir siendo visible, en lugar de simular una evolución aparentemente continua.

Analizar los errores y las limitaciones

Si el punto final de estado responde con un código HTTP 403, comprueba primero la dirección de origen que realmente llega a NGINX y las reglas de acceso de la ubicación. allow y deny Se evalúan por orden hasta que se produzca la primera coincidencia. Las reglas propias de la ubicación sustituyen, en su caso, a las reglas heredadas; no las complementan automáticamente.

En el caso de un error HTTP 404, lo primero es buscar el problema en otro sitio: ¿son correctos el puerto y el listener, la ruta solicitada y el bloque de servidores seleccionado? Comprueba también si la configuración prevista está realmente activa tras la recarga. El hecho de que la llamada local se realice correctamente en otro puerto o ruta no garantiza que se haya accedido a la ubicación deseada.

Si no se produce ninguna respuesta HTTP, distingue entre la accesibilidad del listener y una respuesta con código de error. Comprueba en primer lugar la dirección, el puerto y el espacio de red del proceso solicitante, así como el estado del servicio. Solo cuando se establezca una conexión con el listener correcto, el estado HTTP y la ubicación seleccionada ayudarán a delimitar aún más el problema.

Para el análisis continuo de errores, conviene comparar los contadores totales acepta y gestiona. Normalmente son iguales. Si la diferencia aumenta, puede deberse a que se ha alcanzado un límite de recursos; sin embargo, la comparación de los contadores por sí sola no revela ni la causa concreta ni el número de solicitudes HTTP rechazadas. Por lo tanto, incluye los registros de errores y la configuración en la investigación.

Una diferencia ya existente solo indica, en un primer momento, la diferencia entre los dos contadores totales. Para evaluar si la situación ha cambiado durante el periodo de observación, compara esta diferencia al consultar varias veces la misma instancia. Anota el periodo en cuestión para que puedas buscar las entradas de registro y los eventos operativos correspondientes.

La directiva worker_connections limita las conexiones por trabajador, no solo las conexiones de los clientes. Esto incluye, por ejemplo, las conexiones a servidores proxy; además, los límites de descriptores de archivo también pueden suponer una restricción. Se calcula dividiendo el número de conexiones activas entre el número de trabajadores y multiplicando el resultado por worker_connections Por lo tanto, no se obtiene una imagen fiable de la utilización de la capacidad. En su lugar, comprueba los límites reales y el resto del consumo de recursos en su contexto.

Un cambio en los límites de conexión no debe basarse únicamente en un valor de estado elevado. Aclara primero si realmente se ha alcanzado un límite y qué otros recursos o conexiones de origen están implicados. Planifica los posibles cambios teniendo en cuenta la supervisión de los errores y los tiempos de respuesta, y compruébalos siguiendo el procedimiento operativo previsto.

Clasificar las tendencias y los problemas en las fases iniciales

Una consulta de estado aislada solo muestra un momento concreto. En cambio, las consultas repetidas a intervalos fijos ayudan a detectar si los estados de conexión superan un nivel normal o si, tras un pico, vuelven a descender. Registra varias instancias de NGINX por separado y anota qué instancia corresponde a cada serie temporal; de lo contrario, los cambios entre puntos finales pueden distorsionar la evolución.

Un alto Valor de espera Describe las conexiones de clientes en espera, inactivas en ese momento. Por sí solo, no es indicativo de sobrecarga: en el caso de las conexiones reutilizadas, los clientes pueden estar a la espera de nuevas solicitudes. Un aumento cobra mayor relevancia si lo comparas con los tiempos de respuesta, los errores y las métricas de recursos correspondientes al mismo periodo.

Queda Redacción Si el estado «Stub» se mantiene elevado durante un periodo prolongado, comprueba tanto los tiempos de transmisión como el comportamiento de los clientes. Este estado no significa que se estén enviando bytes de forma continua; también puede incluir el tiempo de espera de una respuesta de upstream. El estado «Stub» no identifica ni el servicio backend afectado ni la causa del retraso.

Para la identificación, resultan útiles los datos complementarios: los registros de acceso y los tiempos de upstream registrados muestran qué solicitudes y backends son sospechosos; los registros de errores proporcionan indicios sobre las conexiones fallidas. Si se trata de una sobrecarga de la CPU o de la memoria, necesitarás las métricas del sistema correspondientes. Si el análisis se centra en el establecimiento repetido de conexiones con el backend, el artículo sobre Keepalive de NGINX en el upstream la configuración de conexiones upstream reutilizables.

Del estado al seguimiento

Para un diagnóstico puntual, puede bastar con una consulta de estado local protegida. Esta consulta indica qué valores básicos está notificando en ese momento la instancia consultada, pero no almacena ningún historial. Si necesitas comparar la evolución de los datos o recibir notificaciones en caso de anomalías persistentes, necesitarás un registro periódico y un sistema de series temporales y alertas.

El oficial Exportador de NGINX para Prometheus Para ello existe un componente independiente: este recupera el estado del stub y proporciona los datos como métricas de Prometheus. A continuación, Prometheus recupera el punto final del exportador. Planifica la accesibilidad y las restricciones de acceso para ambas vías, es decir, tanto para el punto final de estado como para la salida de métricas del exportador.

Durante la configuración, documenta qué exportador consulta qué instancia de NGINX y desde dónde accede Prometheus al exportador. Especialmente en el caso de contenedores independientes, se trata de dos rutas de red diferentes. Por lo tanto, el mero hecho de que un punto final del exportador sea accesible no sustituye la comprobación de si el exportador, por su parte, puede recuperar correctamente la página de estado adecuada.

El registro adicional no convierte los valores básicos en métricas detalladas sobre tiempos de respuesta o clases de estado HTTP. Para analizar URL lentas, respuestas con error o conexiones ascendentes concretas, se necesitan registros de acceso adecuados y otros datos de telemetría. También la más exhaustiva API de NGINX Plus Hay que distinguir entre «Stub Status» y NGINX Open Source; su disponibilidad y configuración no son intercambiables.

Selecciona datos adicionales en función de la cuestión concreta: para detectar un aumento en el número de consultas, basta, en un primer momento, con comparar los valores del contador a lo largo del tiempo. Sin embargo, si se trata de respuestas lentas o de un servicio de backend concreto, necesitarás datos de latencia y de tráfico de salida correspondientes a ese periodo. La página de estado puede servir de punto de partida para la investigación, pero no basta por sí sola para identificar la causa.

Los umbrales de alarma deben basarse en el comportamiento normal de la instancia en cuestión y en los objetivos del servicio, no en una cifra general para «Waiting» o «Writing». Compara las anomalías con las latencias, los errores y los recursos disponibles, y comprueba si una alarma requiere realmente una intervención. De este modo, un único indicador se convierte en un motivo para realizar un análisis específico, en lugar de un diagnóstico precipitado.

A la hora de planificar las alarmas, ten en cuenta también el fallo de la vía de recopilación: la falta de datos no es lo mismo que cero solicitudes o cero conexiones. Una comprobación independiente de la accesibilidad ayuda a distinguir una consulta fallida de una actividad realmente baja. Además, determina quién se encarga de gestionar una alarma y qué otros datos deben estar disponibles para el diagnóstico.