Español

English

Español

English

Alerts ​

0. AlertsSQL Server

UID: alertsVersión: 1.3.3 Paneles: ~10

Propósito ​

Este dashboard centraliza las alertas críticas del sistema de monitorización Coyote, proporcionando:

  • Monitorización de uptime del sistema
  • Estado del espacio en disco
  • Conexiones de usuario
  • Tamaño de logs de transacción
  • Estado de servicios SQL
  • Indicadores de bloqueos

Alertas Configuradas ​

System Up Time ​

System Up Time timeseries

El uptime del sistema ha caído por debajo de 24 horas.

Condición de alerta: El sistema puede haber experimentado un reinicio, mantenimiento programado o una interrupción inesperada.

Importancia: Un reinicio inesperado puede indicar problemas de hardware, actualizaciones automáticas no controladas, errores críticos del sistema operativo o fallos de energía. Si no se investiga, pueden ocurrir reinicios recurrentes que afecten la disponibilidad del servicio, pérdida de transacciones en vuelo y corrupción de datos si el apagado no fue limpio.

Runbook de Respuesta

Diagnóstico:

  1. Revisar el Event Viewer de Windows en System > buscar eventos con ID 1074 (apagado planificado) o 6008 (apagado inesperado)
  2. Verificar logs de SQL Server para errores previos al reinicio
  3. Comprobar si hubo Windows Update pendiente
  4. Revisar hardware: temperatura, voltaje, discos (SMART status)

Remediación:

  1. Si fue mantenimiento planificado: documentar y cerrar alerta
  2. Si fue inesperado: revisar dumps de memoria en C:\Windows\Minidump
  3. Verificar integridad de bases de datos con DBCC CHECKDB
  4. Comprobar que todos los servicios SQL están ejecutándose
  5. Validar que los jobs de SQL Agent se reanudaron correctamente

Escalamiento:

  • No escalar: Si fue mantenimiento planificado documentado
  • Escalar a Nivel 2: Si el reinicio fue inesperado y no hay causa clara en logs
  • Escalar a Nivel 3/Infraestructura: Si hay indicios de fallo de hardware o reinicios recurrentes (más de 2 en una semana)

Acciones recomendadas:

  1. Verificar la causa del reinicio
  2. Revisar logs de eventos de Windows
  3. Comprobar que todos los servicios estén funcionando

Disk Free Space ​

Disk Free Space bargauge

El espacio libre en disco ha caído por debajo del 20%.

Condición de alerta: El espacio disponible puede indicar crecimiento acelerado, uso ineficiente o acumulación inesperada de datos.

Importancia: El espacio en disco insuficiente es una de las causas más comunes de interrupciones no planificadas en SQL Server. Sin espacio disponible, las bases de datos no pueden crecer, los logs de transacción se llenan causando que las transacciones fallen, y los backups no pueden completarse. En casos extremos, SQL Server puede detenerse completamente, causando pérdida de servicio para todas las aplicaciones dependientes.

Umbrales:

Espacio LibreColorEstado
< 10%RojoCrítico
10% - 20%NaranjaAdvertencia
> 20%VerdeNormal

Runbook de Respuesta

Diagnóstico:

  1. Identificar qué disco está afectado usando la vista [Maintenance].[vwDisksFreeSpace]
  2. Analizar qué está consumiendo espacio: datos, logs, backups, tempdb
  3. Revisar tendencia de crecimiento de los últimos 30 días
  4. Verificar si hay archivos de backup antiguos sin purgar

Remediación inmediata (< 10%):

  1. Liberar espacio eliminando backups antiguos (mantener retención mínima requerida)
  2. Truncar logs de transacción si hay backups de log recientes
  3. Vaciar carpetas temporales del sistema
  4. Mover archivos de backup a almacenamiento secundario

Remediación planificada (10-20%):

  1. Implementar políticas de retención de backups
  2. Configurar shrink automático de logs (con precaución)
  3. Evaluar extensión de capacidad de almacenamiento
  4. Revisar índices duplicados o no utilizados que consumen espacio

Escalamiento:

  • No escalar: Si espacio > 15% y hay plan de limpieza en curso
  • Escalar a Nivel 2: Si espacio < 15% y la limpieza no libera suficiente espacio
  • Escalar a Infraestructura/Storage: Si espacio < 10% y se requiere extensión de almacenamiento urgente
  • Escalar a Gestión: Si el crecimiento indica necesidad de inversión en infraestructura

Acciones recomendadas:

  1. Revisar uso de disco
  2. Limpiar archivos innecesarios
  3. Extender capacidad si es necesario
  4. Verificar crecimiento de logs

User Connections ​

User Connections timeseries

Las conexiones activas han superado las 25,000.

Condición de alerta: El exceso de conexiones puede indicar:

  • Actividad de aplicación inusualmente alta
  • Problemas de connection pooling
  • Proceso desbocado

Importancia: SQL Server tiene un límite máximo de 32,767 conexiones. Alcanzar este límite impide que nuevos usuarios o aplicaciones se conecten, causando errores inmediatos en las aplicaciones. Además, un número excesivo de conexiones consume memoria del servidor (cada conexión usa aproximadamente 1-2 MB), puede degradar el rendimiento general y dificulta la gestión de recursos del sistema.

Umbrales:

ConexionesEstado
< 25,000Normal
>= 25,000Crítico (límite SQL: 32,767)

Runbook de Respuesta

Diagnóstico:

  1. Identificar las aplicaciones con más conexiones usando sys.dm_exec_sessions agrupado por program_name y host_name
  2. Revisar si hay conexiones huérfanas o en estado sleeping prolongado
  3. Verificar configuración de connection pooling en aplicaciones .NET (Min/Max Pool Size)
  4. Analizar si hay procesos batch ejecutándose que abren múltiples conexiones

Remediación:

  1. Contactar a los equipos de desarrollo de las aplicaciones con más conexiones
  2. Cerrar conexiones inactivas con más de X minutos usando KILL (con precaución)
  3. Revisar y ajustar configuración de connection pooling:
    • Reducir Max Pool Size en connection strings
    • Habilitar Connection Lifetime para reciclar conexiones
  4. Implementar retry logic con exponential backoff en aplicaciones
  5. Considerar Resource Governor para limitar conexiones por grupo de carga

Escalamiento:

  • No escalar: Si las conexiones están entre 20,000-25,000 y estables
  • Escalar a Desarrollo: Si se identifica una aplicación específica causando el problema
  • Escalar a Nivel 2: Si las conexiones superan 28,000 y siguen creciendo
  • Escalar a Gestión: Si se requiere intervención de terceros (vendors) para ajustar aplicaciones

Acciones recomendadas:

  1. Revisar patrones de carga de trabajo
  2. Verificar connection pooling
  3. Identificar aplicaciones con muchas conexiones

Used Log Size ​

Used Log Size timeseries

El tamaño del log de transacciones ha superado los 80 GB.

Condición de alerta: Puede ocurrir debido a:

  • Transacciones de larga duración
  • Backups de log insuficientes
  • Operaciones con alto logging

Importancia: Un log de transacciones excesivamente grande puede llenar el disco, causando que la base de datos deje de aceptar transacciones (error 9002). Esto detiene completamente las operaciones de escritura en la base de datos. Además, los backups de log tardarán más tiempo, los restore serán más lentos, y si el log sigue creciendo sin control, puede indicar un problema más grave como una transacción huérfana o replicación rota.

Umbral:

Tamaño LogColorEstado
< 80 GBVerdeNormal
>= 80 GBRojoCrítico

Runbook de Respuesta

Diagnóstico:

  1. Identificar qué base de datos tiene el log grande usando sys.master_files
  2. Verificar el modelo de recuperación (FULL requiere backups de log frecuentes)
  3. Buscar transacciones activas de larga duración con DBCC OPENTRAN
  4. Revisar si hay replicación, mirroring o AlwaysOn con retrasos
  5. Comprobar el estado de log_reuse_wait_desc en sys.databases

Remediación:

  1. Si log_reuse_wait_desc = 'LOG_BACKUP': ejecutar backup de log inmediatamente
  2. Si log_reuse_wait_desc = 'ACTIVE_TRANSACTION': identificar y resolver la transacción bloqueante
  3. Si log_reuse_wait_desc = 'REPLICATION': verificar estado del Log Reader Agent
  4. Después de liberar espacio, considerar shrink del log (solo si es necesario)
  5. Ajustar frecuencia de backups de log (cada 15-30 minutos para bases activas)

Escalamiento:

  • No escalar: Si el backup de log resuelve el problema y el log se reduce
  • Escalar a Nivel 2: Si el log sigue creciendo después del backup o hay transacción bloqueante que no se puede resolver
  • Escalar a DBA Senior: Si está relacionado con replicación o AlwaysOn
  • Escalar a Infraestructura: Si el disco está en riesgo de llenarse antes de poder resolver

Acciones recomendadas:

  1. Validar jobs de backup de logs
  2. Monitorizar transacciones activas
  3. Asegurar mantenimiento apropiado de logs

SQL Alerts Global ​

SQL Alerts Global table

Tabla resumen del estado de alertas SQL.

Indicadores:

IndicadorOKKO
Blocked0>= 1
Long_Blocked0>= 1
SQL Agent Status0>= 1
SQL Mail Status0>= 1

Blocked / Long_Blocked ​

Importancia: Los bloqueos en SQL Server pueden causar timeouts en aplicaciones, degradación del rendimiento y en casos severos, deadlocks que abortan transacciones. Los bloqueos prolongados (Long_Blocked) son especialmente críticos porque afectan a múltiples usuarios y pueden indicar problemas de diseño de aplicación o índices faltantes.

Runbook de Respuesta - Bloqueos

Diagnóstico:

  1. Identificar la cadena de bloqueo usando sys.dm_exec_requests y sys.dm_os_waiting_tasks
  2. Obtener el query del proceso bloqueante con sys.dm_exec_sql_text
  3. Revisar si el bloqueo es por lock escalation o página/fila específica

Remediación:

  1. Si es una transacción olvidada: contactar al usuario/aplicación para commit o rollback
  2. Si es un proceso batch: considerar ejecutarlo en horario de bajo uso
  3. Implementar READ_COMMITTED_SNAPSHOT para reducir bloqueos de lectura
  4. Revisar índices para reducir lock escalation
  5. Como último recurso: KILL del proceso bloqueante (coordinando con el negocio)

Escalamiento para Bloqueos:

  • No escalar: Bloqueos menores de 30 segundos que se resuelven solos
  • Escalar a Nivel 2: Bloqueos mayores de 5 minutos o que afectan múltiples usuarios
  • Escalar a Desarrollo: Si el bloqueo es causado por código de aplicación deficiente
  • Escalar a Gestión: Si se requiere matar un proceso de negocio crítico

SQL Agent Status ​

Importancia: SQL Server Agent es responsable de ejecutar jobs programados incluyendo backups, mantenimiento de índices, y procesos ETL. Si el servicio está detenido, ningún job se ejecutará, lo que puede resultar en backups faltantes (incumplimiento de RPO), datos desactualizados en reportes, y acumulación de tareas de mantenimiento.

Runbook de Respuesta - SQL Agent

Diagnóstico:

  1. Verificar el estado del servicio en Windows Services
  2. Revisar el Event Log de Windows para errores del servicio
  3. Comprobar el SQL Server Agent Error Log
  4. Verificar que la cuenta de servicio tenga permisos válidos

Remediación:

  1. Intentar reiniciar el servicio SQL Server Agent
  2. Si falla el inicio, revisar los logs para identificar la causa
  3. Verificar que la cuenta de servicio no esté bloqueada o con contraseña expirada
  4. Comprobar conectividad a la base de datos msdb
  5. Si persiste, reiniciar SQL Server como último recurso (coordinando el impacto)

Escalamiento para SQL Agent:

  • No escalar: Si el reinicio del servicio resuelve el problema
  • Escalar a Nivel 2: Si el servicio no inicia después del reinicio
  • Escalar a Infraestructura: Si hay problemas con la cuenta de servicio o permisos
  • Escalar a Gestión: Si se requiere reinicio de SQL Server en horario de producción

SQL Mail Status ​

Importancia: Database Mail es el mecanismo para enviar notificaciones de alertas, reportes programados y confirmaciones de jobs. Si está fallando, el equipo de operaciones no recibirá alertas críticas, lo que puede resultar en problemas no detectados a tiempo y violación de SLAs.

Runbook de Respuesta - SQL Mail

Diagnóstico:

  1. Verificar el estado de Database Mail con sysmail_help_status_sp
  2. Revisar la cola de correos fallidos en sysmail_faileditems
  3. Comprobar la configuración SMTP en sysmail_help_account_sp
  4. Verificar conectividad de red al servidor SMTP

Remediación:

  1. Reiniciar Database Mail: EXEC msdb.dbo.sysmail_stop_sp; EXEC msdb.dbo.sysmail_start_sp;
  2. Verificar que el servidor SMTP acepta conexiones desde SQL Server
  3. Comprobar que no hay cambios en credenciales SMTP
  4. Revisar límites de envío (algunos SMTP tienen rate limiting)
  5. Reenviar correos fallidos desde la cola si es necesario

Escalamiento para SQL Mail:

  • No escalar: Si el reinicio de Database Mail resuelve el problema
  • Escalar a Infraestructura/Redes: Si hay problemas de conectividad al SMTP
  • Escalar a Nivel 2: Si hay problemas de configuración o credenciales

Código de Colores de Alertas ​

ColorCódigoSignificado
Verde#00db88 / #6be38dOK - Estado normal
Naranja#ff780aWarning - Advertencia
Magenta#ad21d8e8KO - Requiere atención
Rojo#E02F44Critical - Acción inmediata

Guía de Respuesta a Alertas ​

Prioridad Alta ​

AlertaAcción Inmediata
Disk < 10%Liberar espacio urgentemente
Log > 80 GBEjecutar backup de log
User Connections > 25000Investigar aplicaciones

Prioridad Media ​

AlertaAcción Planificada
Disk 10-20%Planificar limpieza
Uptime < 24hInvestigar causa de reinicio
SQL Agent KOReiniciar servicio

Mejores Prácticas de Configuración de Alertas ​

Evitar Alert Fatigue ​

La "fatiga de alertas" ocurre cuando el equipo recibe tantas notificaciones que comienza a ignorarlas, incluyendo las críticas. Para evitarlo:

  1. Clasificar alertas por severidad: No todas las alertas deben notificar igual

    • Críticas: Notificación inmediata (SMS, llamada, Teams)
    • Advertencia: Email con revisión en 4 horas
    • Informativas: Dashboard solo, sin notificación activa

  2. Configurar umbrales progresivos: Escalar la urgencia según la gravedad

    • Disco 20%: Advertencia en dashboard
    • Disco 15%: Email al equipo
    • Disco 10%: Notificación Teams + ticket automático
    • Disco 5%: Llamada al on-call

  3. Agrupar alertas relacionadas: Una falla de disco puede generar múltiples alertas (disco, log, backup). Configurar supresión de alertas secundarias.

  4. Revisar y ajustar umbrales regularmente: Lo que era crítico para un servidor pequeño puede ser normal para uno más grande.

Umbrales Recomendados ​

MétricaAdvertenciaCríticoNotas
Disco libre< 20%< 10%Ajustar según tamaño total
Log de transacciones> 50 GB> 80 GBDepende del volumen transaccional
Conexiones> 20,000> 25,000Considerar el baseline normal
Bloqueos> 30 seg> 5 minLong_Blocked es siempre crítico
CPU SQL> 80% (5 min)> 95% (5 min)Sostenido, no picos
PLE< 300 seg< 100 segDepende de la memoria total

Documentación y Runbooks ​

  1. Mantener runbooks actualizados: Cada alerta debe tener pasos claros de diagnóstico y remediación
  2. Registrar acciones tomadas: Documentar qué se hizo para resolver cada alerta
  3. Post-mortem de incidentes: Después de incidentes mayores, revisar si las alertas fueron efectivas
  4. Entrenar al equipo: Asegurar que todos conozcan los runbooks y sepan cuándo escalar

Horarios y Guardias ​

  1. Definir horarios de notificación: Algunas alertas de advertencia pueden esperar hasta horario laboral
  2. Rotación de on-call: Distribuir la carga para evitar burnout
  3. Escalamiento automático: Si una alerta crítica no se reconoce en X minutos, escalar automáticamente

Vistas Utilizadas ​

VistaDescripción
[Maintenance].[vwDisksFreeSpace]Espacio libre en discos
[Alert].[vwSQLAlertsGlobal]Estado global de alertas SQL

Tablas de Performance Counters ​

ContadorDescripción
Seconds Since StartTiempo desde inicio del sistema
User ConnectionsConexiones activas
Log File(s) Used Size (KB)Tamaño utilizado de logs

Configuración de Notificaciones ​

Las alertas de Grafana pueden configurarse para enviar notificaciones a través de:

  • Email: Envío directo a administradores
  • Teams/Slack: Canales de notificación
  • Webhook: Integración con sistemas externos

Referencias de Microsoft ​

Documentación Oficial de Monitorización ​

Gestión de Espacio y Logs ​

Bloqueos y Rendimiento ​

SQL Server Agent ​

Database Mail ​

Mejores Prácticas ​

© 2025 Coyote Monitor by Aleson ITC