Supervisión de instancias de App Service mediante la comprobación de estado

En este artículo se usa la comprobación de estado en Azure Portal para supervisar las instancias de App Service. La comprobación de estado aumenta la disponibilidad de la aplicación al volver a enrutar las solicitudes fuera de las instancias en estado incorrecto y reemplazar las instancias si siguen en estado incorrecto. Para ello, ancle cada minuto una ruta de acceso de la aplicación web que prefiera.

Tenga en cuenta que /api/health es solo un ejemplo agregado con fines ilustrativos. De forma predeterminada, no se crea una ruta de acceso de comprobación de estado. Debe asegurarse de que la ruta de acceso que está seleccionando es una ruta de acceso válida que existe en la aplicación

Lo que hace App Service con las comprobaciones de estado

• Cuando se proporciona una ruta de acceso en la aplicación, la comprobación de estado hace ping en esta ruta de acceso a todas las instancias de la aplicación App Service en intervalos de 1 minuto.
• Si una aplicación web que se ejecuta en una instancia determinada no responde con un código de estado entre 200 y 299 (ambos incluidos) después de 10 solicitudes, App Service determina que presenta un estado incorrecto y la quita del equilibrador de carga para esta aplicación web. El número necesario de solicitudes con error para que una instancia se considere en estado incorrecto se puede configurar para un mínimo de dos solicitudes.
• Después de la eliminación, la comprobación de estado sigue haciendo ping a la instancia incorrecta. Si la instancia comienza a responder con un código de estado de mantenimiento (200-299), la instancia se devuelve al equilibrador de carga.
• Si la aplicación web que se ejecuta en una instancia sigue siendo incorrecta durante una hora, la instancia se reemplaza por una nueva.
• Al escalar horizontalmente, App Service hace ping a la ruta de acceso de comprobación de estado para asegurarse de que las nuevas instancias estén listas.

Nota

• La comprobación de estado no sigue 302 redirecciones.
• A lo sumo, se reemplaza una instancia por hora, con un máximo de tres instancias al día por plan de App Service.
• Si la comprobación de estado muestra el estado Waiting for health check response, es probable que se deba a un error en la comprobación debido a un código de estado HTTP 307, lo que puede ocurrir si tiene habilitada la redirección HTTPS pero se ha deshabilitado HTTPS Only.

Habilitación de la comprobación de estado

1. Para habilitar la comprobación de estado, vaya a Azure Portal y seleccione la aplicación App Service.
2. En Supervisión, seleccione Comprobación de estado.
3. Seleccione Habilitar y proporcione una ruta de acceso válida a una dirección URL en la aplicación, por ejemplo, /health o /api/health.
4. Seleccione Guardar.

Nota

• El plan de App Service se debe escalar a dos o más instancias para utilizar completamente la comprobación de estado.
• La ruta de acceso de comprobación de estado debe comprobar los componentes críticos de la aplicación. Por ejemplo, si la aplicación depende de una base de datos y de un sistema de mensajería, el punto de conexión de comprobación de estado debe conectarse a esos componentes. Si la aplicación no se puede conectar a un componente crítico, la ruta de acceso debe devolver un código de respuesta de nivel 500 para indicar que la aplicación tiene un estado incorrecto. Además, si la ruta de acceso no devuelve una respuesta en el plazo de 1 minuto, el anclaje de comprobación de estado se considera incorrecto.
• Al seleccionar la ruta de acceso de comprobación de estado, asegúrese de seleccionar una ruta de acceso que devuelva un código de estado 200 solo cuando la aplicación esté totalmente activada.
• Para usar la comprobación de estado en la aplicación de funciones, debe usar un plan de hospedaje premium o dedicado.
• Puede encontrar detalles sobre la comprobación de estado en las aplicaciones de funciones aquí: Supervisión de aplicaciones de funciones mediante comprobación de estado.

Precaución

Los cambios de configuración de la comprobación de estado reinician la aplicación. Para minimizar el impacto en las aplicaciones de producción, se recomienda configurar los espacios de ensayo y cambiar a producción.

Configuración

Además de configurar las opciones de la comprobación de estado, también puede configurar las siguientes opciones de la aplicación:

Nombre del valor de configuración de la aplicación	Valores permitidos	Descripción
WEBSITE_HEALTHCHECK_MAXPINGFAILURES	2 - 10	Número necesario de solicitudes con error para que una instancia se considere en estado incorrecto y se quite del equilibrador de carga. Por ejemplo, si se establecen en 2, las instancias se quitarán después de 2 pings con error. (El valor predeterminado es 10).
WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT	1 - 100	De forma predeterminada, no se excluirá más de la mitad de las instancias del equilibrador de carga a la vez para evitar sobrecargar las instancias en estado correcto restantes. Por ejemplo, si un plan de App Service se escala a cuatro instancias y tres son incorrectas, se excluirán dos. Las otras dos instancias (una correcta y otra incorrecta) seguirán recibiendo solicitudes. En el peor de los casos, si todas las instancias están en estado incorrecto, no se excluye ninguna. Para invalidar este comportamiento, establezca la configuración de la aplicación en un valor entre 1 y 100. Un valor mayor significa que se quitarán más instancias incorrectas (el valor predeterminado es 50).

Autenticación y seguridad

La comprobación de estado se integra con las características de autenticación y autorización de App Service. No se requiere ninguna configuración adicional si estas características de seguridad están habilitadas.

Si usa un sistema de autenticación propio, la ruta de comprobación de estado debe permitir el acceso anónimo. Para proteger el punto de conexión de la comprobación de estado, primero debe usar características como restricciones de IP, certificados de cliente o una red virtual para restringir el acceso a la aplicación. Una vez que tenga esas características preparadas, podrá autenticar la solicitud de comprobación de estado mediante la inspección del encabezado, x-ms-auth-internal-token, así como mediante la validación de que este coincida con el hash SHA256 de la variable de entorno WEBSITE_AUTH_ENCRYPTION_KEY. Si estos elementos coinciden, significará que la solicitud de comprobación de estado es válida y se ha originado en App Service.

Nota:

Específicamente para la autenticación de Azure Functions, la función que actúa como punto de conexión de comprobación de estado debe permitir el acceso anónimo.

.NET

using System;
using System.Text;

/// <summary>
/// Method <c>HeaderMatchesEnvVar</c> returns true if <c>headerValue</c> matches WEBSITE_AUTH_ENCRYPTION_KEY.
/// </summary>
public Boolean HeaderMatchesEnvVar(string headerValue) {
    var sha = System.Security.Cryptography.SHA256.Create();
    String envVar = Environment.GetEnvironmentVariable("WEBSITE_AUTH_ENCRYPTION_KEY");
    String hash = System.Convert.ToBase64String(sha.ComputeHash(Encoding.UTF8.GetBytes(envVar)));
    return hash == headerValue;
}

Python

from hashlib import sha256
import base64
import os

def header_matches_env_var(header_value):
    """
    Returns true if SHA256 of header_value matches WEBSITE_AUTH_ENCRYPTION_KEY.
    
    :param header_value: Value of the x-ms-auth-internal-token header.
    """
    
    env_var = os.getenv('WEBSITE_AUTH_ENCRYPTION_KEY')
    hash = base64.b64encode(sha256(env_var.encode('utf-8')).digest()).decode('utf-8')
    return hash == header_value

Java

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Base64;
import java.nio.charset.StandardCharsets;

public static Boolean headerMatchesEnvVar(String headerValue) throws NoSuchAlgorithmException {
    MessageDigest digest = MessageDigest.getInstance("SHA-256");
    String envVar = System.getenv("WEBSITE_AUTH_ENCRYPTION_KEY");
    String hash = new String(Base64.getDecoder().decode(digest.digest(envVar.getBytes(StandardCharsets.UTF_8))));
    return hash.equals(headerValue);
}

Node.js

var crypto = require('crypto');

function envVarMatchesHeader(headerValue) {
    let envVar = process.env.WEBSITE_AUTH_ENCRYPTION_KEY;
    let hash = crypto.createHash('sha256').update(envVar).digest('base64');
    return hash == headerValue;
}

Nota

El encabezado x-ms-auth-internal-token solo está disponible en Windows App Service.

Instancias

Una vez habilitado Health Check, puede reiniciar y supervisar el estado de las instancias de su aplicación a través de la pestaña de instancias. La pestaña de instancias muestra el nombre de su instancia, el estado de la instancia de esa aplicación y le da la opción de reiniciar manualmente la instancia.

Si el estado de su instancia de aplicación no es seguro, puede reiniciar la instancia manualmente utilizando el botón de reinicio de la tabla. Tenga en cuenta que cualquier otra aplicación hospedada en el mismo plan de App Service que la instancia también se verá afectada por el reinicio. Si hay otras aplicaciones que usan el mismo plan de App Service que la instancia, se mostrarán en la hoja de apertura del botón Reiniciar.

Si reinicia la instancia y se produce un error en el proceso de reinicio, se le dará la opción de reemplazar al trabajo (solo se puede reemplazar 1 instancia por hora). Esto también afectará a las aplicaciones que usen el mismo plan de App Service.

Las aplicaciones de Windows también tendrán la opción de ver los procesos a través del Explorador de procesos. Esto proporciona más información sobre los procesos de la instancia, incluido el recuento de subprocesos, la memoria privada y el tiempo total de CPU.

Recopilación de la información de diagnóstico

En el caso de las aplicaciones de Windows, tiene la opción de recopilar información de diagnóstico en la pestaña Comprobación de estado. La habilitación de la recopilación de diagnósticos agregará una regla de recuperación automática que crea volcados de memoria para las instancias incorrectas y la guarda en una cuenta de almacenamiento designada. Al habilitar esta opción, se cambiarán las configuraciones de recuperación automática. Si ya existen reglas de recuperación automática, se recomienda configurarlas a través de los diagnósticos de App Service.

Una vez habilitada la recopilación de diagnósticos, puede crear o elegir una cuenta de almacenamiento existente para los archivos. Solo puede seleccionar cuentas de almacenamiento en la misma región que la aplicación. Tenga en cuenta que, al guardar, se reiniciará la aplicación. Después de guardar, si se detecta que las instancias del sitio son incorrectas después de ping continuos, puede ir al recurso de la cuenta de almacenamiento y ver los volcados de memoria.

Supervisión

Después de proporcionar la ruta de acceso de la comprobación de estado de la aplicación, puede supervisar el estado del sitio mediante Azure Monitor. En la hoja Comprobación de estado del portal, seleccione Métricas en la barra de herramientas superior. Se abre una nueva hoja donde puede ver el estado de mantenimiento histórico del sitio y la opción de crear una regla de alerta. Las métricas de comprobación de estado agregarán los pings correctos y mostrarán errores solo cuando se considere que la instancia tiene un estado incorrecto en función de la configuración de comprobación de estado. Para obtener más información sobre la supervisión de sitios, vea la guía sobre Azure Monitor.

Limitaciones

• La comprobación de estado se puede habilitar para los planes de App Service Gratis y Compartido, por lo que puede tener métricas del estado del sitio y configurar alertas, pero como los sitios de los planes Gratis y Compartido no se pueden escalar horizontalmente, no se sustituirán las instancias incorrectas. Debe escalar verticalmente al nivel Básico o superior para poder escalar horizontalmente a 2 o más instancias y usar todas las ventajas de la comprobación de estado. Esto se recomienda para las aplicaciones orientadas a producción, ya que aumentará la disponibilidad y el rendimiento de la aplicación.
• El plan de App Service puede tener un máximo de una instancia incorrecta reemplazada por hora y, como máximo, tres instancias al día.
• Hay un límite no configurable en la cantidad total de instancias reemplazadas por comprobación de estado por unidad de escalado. Si se alcanza este límite, no se reemplazarán las instancias con estado incorrecto. Este valor se restablece cada 12 horas.

Preguntas más frecuentes

¿Qué ocurre si mi aplicación se ejecuta en una sola instancia?

Si la aplicación solo se escala a una instancia y queda en estado incorrecto, no se quitará del equilibrador de carga, ya que eso haría que la aplicación se quede completamente fuera de servicio. Sin embargo, después de una hora de pings incorrectos continuos, la instancia se reemplaza. Escale horizontalmente a dos o más instancias para obtener la ventaja de volver a enrutar que ofrece la comprobación de estado. Si la aplicación se ejecuta en una sola instancia, todavía puede usar la característica de supervisión de la comprobación de estado para realizar un seguimiento del estado de la aplicación.

¿Por qué no se muestran las solicitudes de comprobación de estado en mis registros de servidor web?

Las solicitudes de comprobación de estado se envían al sitio internamente, por lo que no se mostrarán en los registros de servidor web. Puede agregar instrucciones de registro en el código de comprobación de estado para mantener registros de cuándo se hace ping a la ruta de acceso de la comprobación de estado.

¿Las solicitudes de comprobación de estado se envían mediante HTTP o HTTPS?

En Windows App Service, las solicitudes de comprobación de estado se envían mediante HTTPS cuando la opción Solo HTTPS está habilitada en el sitio. De lo contrario, se envían mediante HTTP. En Linux App Service, las solicitudes de comprobación de estado solo se envían a través de HTTP y no se pueden enviar a través de HTTPS en este momento.

¿La comprobación de estado sigue el código de aplicación configurado? Es decir, ¿redirige entre el dominio predeterminado y el dominio personalizado?

No, la característica Comprobación de estado hace ping a la ruta de acceso del dominio predeterminado de la aplicación web. Si hay una redirección del dominio predeterminado a un dominio personalizado, el código de estado que devuelve la comprobación de estado no va a ser 200, sino un redireccionamiento (301), que marcará el estado incorrecto del trabajo.

¿Qué ocurre si tengo varias aplicaciones en el mismo plan de App Service?

Las instancias en estado incorrecto se quitarán siempre de la rotación del equilibrador de carga, independientemente de otras aplicaciones del plan de App Service (hasta el porcentaje especificado en WEBSITE_HEALTHCHECK_MAXUNHEALTHYWORKERPERCENT). Cuando una aplicación de una instancia permanece en estado incorrecto durante más de una hora, la instancia solo se reemplazará si todas las demás aplicaciones con la comprobación de estado habilitada también tienen un estado incorrecto. Las aplicaciones que no tienen habilitada la comprobación de estado no se tendrán en cuenta.

Ejemplo

Imagine que tiene dos aplicaciones (o una aplicación con una ranura) con la comprobación de estado habilitada, llamadas Aplicación A y Aplicación B. Están en el mismo plan de App Service y el plan se escala horizontalmente a cuatro instancias. Si la Aplicación A tiene un estado incorrecto en dos instancias, el equilibrador de carga dejará de enviar solicitudes a la Aplicación A en esas dos instancias. Las solicitudes se seguirán enrutando a la Aplicación B en esas instancias, suponiendo que la Aplicación B esté en estado correcto. Si la Aplicación A permanece en estado incorrecto durante más de una hora en esas dos instancias, esas instancias solo se reemplazarán si la Aplicación B también tiene un estado incorrecto en esas instancias. Si la Aplicación B tiene un estado correcto, la instancia no se reemplazará.

Nota

Si hubiera otro sitio o ranura en el plan (sitio C) sin la comprobación de estado habilitada, no se tendría en cuenta para la sustitución de la instancia.

¿Qué ocurre si todas mis instancias tienen un estado incorrecto?

En el escenario en el que todas las instancias de la aplicación tienen un estado incorrecto, App Service no quitará las instancias del equilibrador de carga. En este escenario, si se quitaran todas las instancias de la aplicación con estado incorrecto de la rotación del equilibrador de carga, esto provocaría una interrupción de la aplicación. Sin embargo, el reemplazo de instancias aún se levará a cabo.

¿Funciona la comprobación de estado en instancias de App Service Environment?

Sí, la comprobación de estado está disponible para App Service Environment v3, pero no para las versiones 1 o 2. Si usa las versiones anteriores de App Service Environment, puede utilizar la característica de migración para migrar App Service Environment a la versión 3.

Pasos siguientes

• Creación de una alerta de registro de actividades para supervisar todas las operaciones del motor de escalado automático en su suscripción
• Creación de una alerta de registro de actividades para supervisar todas las operaciones erróneas de escalado automático y reducción horizontal en su suscripción
• Variables de entorno y configuración de la aplicación en Azure App Service