Bienvenidos a un nuevo post en el blog de Coyote Monitor. Este verano no lo hemos usado para desconectar del todo: lo hemos aprovechado para seguir mejorando la herramienta, y hoy toca contarte el resultado. Hablamos de la nueva versión de nuestro panel de estado de procesos —disponible para SQL Server on-premises, Azure SQL Database, Azure SQL Managed Instance, Fabric SQL Database y Amazon RDS para SQL Server—, que convive con el clásico bajo el nombre de Process Status v2.
Si llevas unos años como DBA, seguro que te suena esta escena: te llama un compañero porque «la aplicación va lenta», abres SSMS, lanzas un par de consultas contra sys.dm_exec_requests y sys.dm_os_waiting_tasks, y con suerte pillas algo. Si llegas cinco minutos tarde, el bloqueo ya se resolvió solo y te quedas sin saber qué lo causó. Ese «llegar tarde» es justo el problema que Process Status v2 ataca desde otro ángulo.
Por qué hemos rediseñado el panel de procesos
El panel clásico de Process Status, dentro de las secciones de monitorización de SQL Server y de Azure SQL, ya hacía bastante: reunía tendencia de procesos, desglose de TempDB, long queries y tablas de bloqueados, deadlocks y consumo de TempDB para una fecha concreta.
Lo que cambia en v2 no es qué datos monitoriza, sino cómo se navegan, se filtran y se investigan: tablas sin buscador ni filtros, bloqueados y deadlocks mezclados en una tabla plana, y sin indicador único de estado. Este es el resumen:
| Process Status (clásico) | Process Status v2 | |
|---|---|---|
| Estado global de la instancia | Sin indicador único; solo colores por panel | Semáforo único: HEALTHY / TO CHECK / NO DATA / CRITICAL |
| Bloqueados y deadlocks | Una sola tabla plana, con el deadlock como flag | Dos pestañas separadas, cada una como árbol jerárquico |
| Deadlocks agrupados por ciclo | No, filas sueltas | Sí, una cabecera por ciclo detectado |
| Buscar y filtrar sesiones | No disponible en las tablas | Buscador de texto libre, filtro por estado y orden configurable |
| Ir de un pico al detalle | Manual, con el Time Selector | Los picos son clicables y abren la pestaña correspondiente |
| Plan de ejecución de una sesión | No disponible | Modal con pestañas Query y Execution Plan, y copia del XML |
| TempDB (tendencia y desglose por fecha) | Sí, en paneles propios | Sí, integrado en la misma vista de procesos |
Bloqueos, deadlocks, long queries y TempDB: un repaso rápido
Antes de seguir, un repaso rápido de los cuatro conceptos que vertebran el panel. Aplican igual estés en SQL Server on-premises, Azure SQL, Fabric SQL Database o Amazon RDS, porque todas estas plataformas comparten el mismo motor de base de datos.
Un bloqueo (blocking) ocurre cuando una sesión necesita un recurso que otra ya tiene retenido, y espera a que se libere; es normal en cualquier motor transaccional, el problema es cuando la espera se alarga.
Un deadlock es distinto: dos o más sesiones se bloquean mutuamente en círculo y ninguna puede avanzar. SQL Server lo detecta solo y elige una sesión «víctima» para romper el ciclo, como explica la guía oficial de deadlocks de Microsoft.
Una long query es una sesión activa durante un tiempo desproporcionado respecto al comportamiento habitual del servidor, sin estar necesariamente bloqueada.
Y TempDB es la base de datos de sistema compartida por la instancia, donde SQL Server guarda tablas temporales, resultados intermedios de sorts y hash joins, y las versiones de fila del row versioning, con matices bien documentados en la página oficial de TempDB. Es un recurso compartido: si una sesión abusa de él, lo nota toda la instancia.
Lo que de verdad cambia en el día a día
Un semáforo, no once colores distintos
La cabecera ahora muestra un estado global de la instancia —HEALTHY, TO CHECK, NO DATA o CRITICAL— calculado a partir de los bloqueos, long queries y deadlocks más recientes. Antes había que interpretar varios colores por panel para llegar a la misma conclusión.
Por fin, buscador y filtros en las tablas
Las pestañas de lista plana (All Process, Long Queries, TempDB Usage) incorporan un buscador de texto libre —que compara SPID, aplicación, login, base de datos, hostname, estado y el texto de la query—, filtros por estado y botones de ordenación. Es la mejora que más nos habéis pedido, y el panel clásico simplemente no la tenía.
Picos clicables en la tendencia
Los KPIs agregados del rango —pico de bloqueados, de sesiones activas, de long queries y total de deadlocks— son ahora clicables: pinchas en el momento de mayor congestión y saltas directo a la pestaña de detalle de ese instante, sin mover el Time Selector a mano.
Bloqueos y deadlocks, cada uno con su árbol
En el panel clásico, bloqueados y deadlocks compartían tabla, con el deadlock como una simple marca en la fila. En v2 son dos pestañas independientes: Blocked, con la cadena de bloqueo representada como árbol —bloqueante raíz arriba, sesiones bloqueadas en cascada debajo—, y Deadlocks, donde cada ciclo detectado se agrupa bajo su propia cabecera. Reconstruir a mano quién bloqueaba a quién deja de ser necesario.
TempDB Composition, ahora integrado
El desglose entre version store, objetos internos y objetos de usuario ya existía en el clásico como paneles propios. En v2 se integra en la misma vista que procesos y bloqueos, sin saltar de sección.
La novedad grande: plan de ejecución por sesión
Esta es, para mí, la mejora que más pesa. Cada fila del detalle se abre en un modal con la consulta completa formateada y, si se capturó uno, el plan de ejecución gráfico, con un botón para copiar el XML. El panel clásico solo mostraba la consulta implicada como texto dentro de la tabla; no había forma de ver el plan sin salir a SSMS. Cada fila añade además insignias de contexto (primary blocker, N blocked, blocked for Xs, plan, deadlock) que dicen de un vistazo qué papel juega esa sesión.
Por qué esto cambia el día a día de un DBA
En la práctica, lo que cambia es cuánto tardas en pasar de «algo va mal» a «esto es lo que lo está causando». El histórico ya estaba en el panel clásico, pero filtrar, separar bloqueos de deadlocks y llegar al plan de ejecución exigía pasos manuales fuera del propio panel. Con Process Status v2, ese camino se acorta bastante. No es casualidad que SanLucar Fruit —con David Carrasco Campos, su IT Manager— haya reportado una reducción del 70% en el tiempo de resolución de incidencias desde que monitoriza con Coyote Monitor; mejoras de navegación como estas ayudan a sostener ese número.
Disponibilidad: panel en beta
A fecha de esta publicación (15 de septiembre de 2026), Process Status v2 está en fase beta y convive con el panel clásico de Process Status, que sigue disponible sin cambios. La idea es que v2 termine sustituyendo al panel clásico, pero de momento no hay fecha fijada para retirar el antiguo: convivirán mientras recogemos vuestro feedback. Si detectas algo raro mientras lo pruebas, cuéntanoslo: es justo lo que necesitamos en esta fase.
Prueba Process Status v2 hoy mismo
Si ya eres cliente de Coyote Monitor, el panel está disponible desde tus instancias monitorizadas. Si todavía no lo eres, puedes probarlo con la prueba gratuita de 30 días, sin tarjeta de crédito, o solicitar una demo si prefieres que te lo enseñemos nosotros primero.
