Cómo monitorear Azure App Service sin puntos ciegos

En pocas palabras: Monitoreá Azure App Service con dos capas: el health check nativo de Azure, que pinga tu app cada minuto y saca la instancia enferma del load balancer tras 10 fallos seguidos, más Vigilmon, que la prueba desde afuera como un usuario real.

Para monitorear Azure App Service de verdad necesitás dos capas: el health check nativo de Azure (que pinga tu app cada minuto y saca del load balancer la instancia enferma tras 10 fallos seguidos) y un monitoreo externo tipo Vigilmon que prueba tu app desde afuera, como la ve un usuario real. Con una sola capa te quedan puntos ciegos.

Azure App Service es el servicio de Microsoft para desplegar aplicaciones web, APIs y backends sin manejar servidores a mano. Te abstrae la infraestructura, pero no te vuelve inmune a caídas: cold starts, un deploy que devuelve 500, un certificado SSL vencido o una base de datos inalcanzable pueden tirar tu app cuando menos lo esperás. Monitorear bien es saber que algo se rompió antes que tu cliente.

¿Qué problemas comunes tiene Azure App Service y cómo afectan la disponibilidad?

Los failure modes más típicos de Azure App Service son cinco: cold starts, deploys defectuosos, vencimiento de certificados SSL, lag del autoscaling y caídas de dependencias. Ninguno avisa antes. Y varios dejan tu app “arriba” a los ojos del panel de Azure mientras el usuario recibe errores.

Ponele que tenés una API en un plan basic que casi nadie toca de madrugada. Llega la primera request a las 7 de la mañana y tarda 25 segundos porque la instancia estaba fría. El usuario ya se fue. Eso es un cold start, y según la guía de Vigilmon pasa sobre todo en los tiers free y basic tras períodos de inactividad.

• Deploys que rompen: un release malo puede crashear la app o devolver 500 en cadena.
• SSL vencido: los certificados de dominios personalizados expiran si nadie los renueva.
• Autoscaling lento: durante un pico de tráfico, el escalado puede llegar tarde.
• Dependencias caídas: tu app responde, pero no se conecta a Azure SQL, Cosmos DB o una API externa. Está “viva” y a la vez inservible.

¿Qué es un health check endpoint y por qué mi app necesita uno?

Un health check endpoint es una URL de tu aplicación (por convención /health) que reporta el estado real del servicio, incluyendo si sus dependencias críticas están disponibles. Devuelve 200 cuando todo anda, 503 cuando algo importante está caído, y responde en menos de un segundo. Azure App Service integra la función, pero el endpoint lo tenés que exponer vos.

Acá conviene distinguir dos cosas que la gente mezcla. Liveness es “la app está viva” (el proceso corre). Readiness es “la app está lista para servir” (además conecta con la DB, el cache y las APIs que necesita). Un endpoint que solo retorna 200 sin chequear nada es liveness disfrazado, y es peor que no tener nada: te da un verde falso mientras la base de datos está muerta. Tema relacionado: al comparar plataformas de integración continua.

¿Por qué peor que nada? Porque un monitoreo que nunca se pone en rojo te entrena para ignorarlo. El día que de verdad se cae algo, ya perdiste la costumbre de mirarlo.

¿Cómo implementar un health check endpoint personalizado en tu aplicación?

Un buen health check verifica cada dependencia crítica antes de responder y usa el código de estado como semáforo: 200-299 sana, 503 degradada, respuesta con error para caída. En Express.js lo armás con una ruta que consulte la DB y el cache; en ASP.NET Core hay un framework de health checks integrado que hace el trabajo pesado.

Ejemplo en Express.js (Node)

router.get('/health', async (req, res) => {
 try {
 await db.query('SELECT 1'); // ¿responde la base?
 await redis.ping(); // ¿responde el cache?
 res.status(200).json({ status: 'healthy' });
 } catch (err) {
 res.status(503).json({ status: 'degraded', error: err.message });
 }
});

Ejemplo en ASP.NET Core

ASP.NET Core trae el paquete de health checks de fábrica. Registrás las verificaciones (SQL Server, Redis, un endpoint externo) y exponés la ruta:

builder.Services.AddHealthChecks()
 .AddSqlServer(connectionString)
 .AddRedis(redisConnection);

app.MapHealthChecks("/health");

El tema es que el endpoint tiene que responder rápido. Si tu chequeo de dependencias tarda más de un segundo, Azure lo va a leer como fallo y vas a tener falsos positivos. Chequeá lo crítico, no todo lo que se te ocurra.

¿Cómo configurar el health check de Azure App Service en el portal?

En el portal de Azure vas a App Service → Monitoring → Health check, activás la función e ingresás el path de tu endpoint (por ejemplo /health). Azure lo va a pingear cada minuto de forma automática desde cada instancia. Es la configuración base que documenta Microsoft Learn.

¿Qué pasa cuando una instancia falla? Si devuelve un estado no sano en 10 chequeos consecutivos, Azure la saca del load balancer y deja de mandarle tráfico. Si la instancia se recupera, la reintegra. Ojo con esto: la reincorporación puede tardar hasta 10 minutos, así que no esperes que el semáforo pase a verde al toque. Cubrimos ese tema en detalle en proteger tus repositorios del malware.

Es el mismo patrón de “health endpoint monitoring” que Microsoft recomienda a nivel arquitectura para servicios distribuidos. Un endpoint, un chequeo periódico, una acción de remediación cuando falla.

¿El monitoreo interno de Azure alcanza o necesito monitoreo externo?

No alcanza con el interno. Azure Monitor y Application Insights ven las métricas de adentro (CPU, memoria, requests, excepciones), pero no detectan problemas de DNS, de CDN, de certificados SSL desde la óptica del cliente, ni un outage de la propia plataforma. El monitoreo externo prueba tu app como un usuario real que entra desde afuera. Son capas distintas y complementarias.

Pensalo así: el interno te dice qué pasa adentro de la casa, el externo te dice si se puede tocar el timbre desde la vereda. Y hay un detalle que suele doler: los status pages de los cloud providers (AWS, Azure, Google Cloud incluidos) se actualizan con retraso. Cuando el proveedor admite el incidente, vos ya lo sabías hace 20 minutos porque tu monitor externo se puso en rojo.

Si además estás corriendo infraestructura web propia o pensás mover parte del stack a un VPS o hosting administrado, en donweb.com tenés opciones en Argentina para complementar lo que ya tenés en la nube.

¿Qué herramientas hay para monitorear Azure App Service además de Azure Monitor?

Hay opciones nativas y de terceros, y la mayoría integra alertas por email o Slack. La regla práctica: combiná una capa interna (métricas y APM) con una externa (uptime desde afuera) para reducir los puntos ciegos. Esta es la comparativa rápida.

Herramienta	Tipo	Fuerte en	Límite
Azure Monitor	Nativa	Métricas internas, integrada al portal	No ve DNS, SSL ni outages de plataforma
Application Insights	Nativa (APM)	Trazas, excepciones, performance del código	Sigue siendo visión interna
New Relic	APM externo	APM completo, agente para App Service	Curva de setup, plan pago según volumen
ManageEngine Applications Manager	Externo	Monitoreo de servicios Azure, dashboards	Suite pesada para casos chicos
Site24x7	Uptime externo	Chequeos desde múltiples ubicaciones	Enfoque más de uptime que de APM
Vigilmon	Externo (health check)	Especializada en probar tu endpoint desde afuera	Herramienta joven, menos ecosistema

No existe la herramienta única que lo resuelva todo. Lo que funciona es apilar capas: métricas internas con Azure Monitor o Application Insights, y uptime externo con la que más te cierre. Esto se conecta con lo que analizamos en garantizar la disponibilidad DNS de tu aplicación.

¿Cómo resolver los problemas más comunes del monitoreo de Azure App Service?

La mayoría de los problemas de monitoreo salen de cuatro lugares: un endpoint lento, dependencias que no se verifican, certificados vencidos y cold starts que disparan falsas alertas. Los cuatro se previenen con ajustes concretos, no con más herramientas.

El health endpoint tarda más de 1 segundo

Si tu chequeo hace queries pesadas, Azure lo lee como fallo y saca la instancia sin motivo. Chequeá solo lo crítico y cacheá lo que puedas. Un SELECT 1 alcanza para saber si la DB responde; no hace falta contar toda una tabla.

La app se reporta sana con la base caída

Es el error clásico: el endpoint devuelve 200 sin verificar nada. Agregá los chequeos de dependencias reales (DB, cache Redis, APIs externas) y hacé que devuelva 503 si alguna falla. Verde tiene que significar verde.

Certificado SSL que vence de sorpresa

Los certificados administrados de Azure se renuevan solos si tenés Auto Renew activado, cerca de un mes antes del vencimiento. El problema aparece con certificados manuales sin renovación. Podés listarlos y chequear fechas con PowerShell:

Get-AzWebAppCertificate | Select-Object Name, ExpirationDate

Cold starts que disparan falsas alertas

En tiers bajos, la primera request tras inactividad tarda y tu monitor la marca como caída. Activá “Always On” en el plan que lo soporte o ajustá el timeout del monitor para que tolere el arranque. Azure Advisor, además, tira recomendaciones preventivas que conviene mirar cada tanto. En orquestar despliegues automáticos en Azure profundizamos sobre esto.

Errores comunes al monitorear Azure App Service

• Creer que el health check nativo reemplaza al monitoreo externo: el nativo actúa dentro de Azure. Si Azure tiene un outage regional, nadie te avisa desde adentro. Sumá una prueba externa.
• Poner un endpoint que solo devuelve 200: sin verificar dependencias, el monitor te miente. Chequeá DB, cache y APIs de verdad.
• Ignorar que la reincorporación tarda hasta 10 minutos: si esperás que la instancia vuelva al instante, vas a pensar que algo sigue roto cuando en realidad Azure todavía la está reintegrando.
• Alertar sobre todo: si te llegan 40 notificaciones por día, las vas a silenciar. Alertá sobre lo que importa y con umbrales sensatos.

Preguntas Frecuentes

¿Cómo monitoreo la disponibilidad de mi app en Azure App Service?

Combinando el health check nativo de Azure (App Service → Monitoring → Health check, que pinga cada minuto) con un monitor externo que prueba tu app desde afuera. El nativo saca del load balancer la instancia enferma; el externo detecta lo que Azure no ve, como DNS o SSL.

¿Qué es un health check endpoint?

Es una URL de tu aplicación (por convención /health) que reporta el estado real del servicio y verifica que sus dependencias críticas estén disponibles. Devuelve 200 si todo anda, 503 si algo importante está caído, y debe responder en menos de un segundo.

¿Cada cuánto pinga Azure el health check?

Azure App Service pinga el path configurado una vez por minuto desde cada instancia. Si una instancia devuelve un estado no sano en 10 chequeos consecutivos, la saca del load balancer. La reintegra cuando se recupera, aunque eso puede tardar hasta 10 minutos.

¿Necesito monitoreo externo si ya uso Azure Monitor?

Sí. Azure Monitor y Application Insights ven métricas internas, pero no detectan problemas de DNS, CDN, certificados desde la óptica del usuario ni outages de la plataforma. El monitoreo externo prueba tu app como lo haría un cliente real desde afuera.

¿Cómo verifico que mi base de datos está disponible desde el health check?

Hacé que el endpoint corra una consulta liviana antes de responder, como un SELECT 1 contra la DB y un ping contra Redis. Si alguna falla, devolvés 503. Así el verde significa que las dependencias reales están arriba, no solo el proceso web.

Conclusión

Monitorear Azure App Service bien no es activar una casilla en el portal y olvidarte. Es exponer un health check honesto que verifique tus dependencias, configurar el chequeo nativo de Azure para que saque las instancias enfermas, y sumar una capa externa que vea tu app como la ve un usuario. Cada capa tapa el punto ciego de la otra.

Si arrancás de cero, hacé tres cosas hoy: escribí un endpoint /health que chequee DB y cache y responda en menos de un segundo, activalo en App Service → Monitoring → Health check, y contratá un monitor externo con alertas a un canal que de verdad mires. Con eso ya vas a enterarte de las caídas antes que tus clientes, que es de lo que se trata.

Fuentes

• Microsoft Learn – Health check en Azure App Service (documentación oficial)
• Microsoft Learn – Patrón Health Endpoint Monitoring
• Microsoft Learn – Diagnóstico de degradación de performance en App Service
• Vigilmon – Cómo monitorear Azure App Service (guía original)
• New Relic – Monitoreo de Azure App Service con APM