Así es como se descubren la mayoría de las interrupciones de SharePoint: un ticket al servicio de ayuda. Alguien en finanzas no puede abrir una biblioteca de documentos, siguen tres tickets más, y para cuando el equipo de administración confirma el problema, la mitad de la empresa ya lo ha experimentado.
Probablemente los servidores de la granja estuvieron “arriba” todo el tiempo. Esa es la trampa con SharePoint Server. Una sola carga de página atraviesa los frontales de IIS, la cadena de autenticación, las aplicaciones de servicio y SQL Server. Cualquiera de esas capas puede degradarse mientras cada comprobación básica de disponibilidad permanece en verde.
Esta guía cubre qué monitorear realmente en una granja SharePoint, dónde se detienen las herramientas integradas, cómo configurar alertas que se disparan antes del primer ticket, y cómo transformar los datos de monitoreo en un informe SLA que su dirección aceptará.
Por qué los problemas de SharePoint llegan al servicio de ayuda antes que a usted
Las verificaciones de ping y puerto responden a una pregunta: ¿es el servidor accesible? SharePoint falla de formas que esa pregunta nunca toca.
Considere una tormenta de inicio de sesión un lunes por la mañana. Cientos de empleados se autentican a las 9 a.m., los servidores ADFS quedan rezagados, y los inicios de sesión que normalmente toman dos segundos, tardan cuarenta. Todos los servidores responden al ping. IIS devuelve 200s. Pero nadie puede acceder a la intranet, y comienzan los tickets.
O la versión más lenta: la latencia del disco en el volumen SQL que contiene su base de datos de contenido más grande aumenta gradualmente durante un mes. Las cargas de página pasan de un segundo a cuatro. No se activa ningún umbral, porque nadie estaba vigilando el número que se movía.
El patrón es el mismo en ambos casos. La capa que falla está entre “el servidor está activo” y “el usuario obtuvo su documento”, y ese territorio intermedio es exactamente lo que debe cubrir el monitoreo del servidor SharePoint.
Qué monitorear en una granja de servidores SharePoint
No necesita cientos de contadores. Necesita la lista corta que predice el dolor del usuario, vigilada de manera constante.
| Capa | Qué vigilar | Por qué |
|---|---|---|
| Frontales IIS | Longitud de cola de solicitudes, tasa 5xx, CPU y memoria, reciclajes del pool de aplicaciones | Las solicitudes en cola son la primera señal de que la granja no puede seguir el ritmo de la carga. |
| SQL Server | Latencia de lectura/escritura de disco en volúmenes de la base de datos de contenido, esperas bloqueantes, crecimiento del log de transacciones | Casi todas las operaciones de SharePoint terminan en SQL. Discos lentos aquí ralentizan todo. |
| Búsqueda | Actualización del rastreo, acumulación en la cola de rastreo, latencia de consultas | La búsqueda desactualizada o lenta es una de las quejas más reportadas de SharePoint, y se degrada en silencio. |
| Tareas programadas (Timer jobs) | Conteo de tareas fallidas, última ejecución en tareas críticas | Las tareas programadas fallidas rompen en silencio flujos de trabajo, sincronizaciones de perfil y reportes de uso. |
| Caché distribuida | Estado del host de caché en cada servidor que la ejecuta, salud del servicio AppFabric | Los tokens de inicio de sesión y los feeds viven aquí, y un host de caché defectuoso causa síntomas en toda la granja difíciles de rastrear. |
| Autenticación | Tiempo de ida y vuelta de inicio de sesión a través de AD, ADFS o Entra ID | La autenticación es un punto único de fallo en toda la granja que los contadores del servidor apenas reflejan. |
| Experiencia de usuario | Tiempo de inicio de sesión, carga de página en colecciones de sitios clave, respuesta de búsqueda, carga/descarga de documentos | Esto es lo que sienten los usuarios, y en los términos en que está escrito su SLA. |
La última fila es la que la mayoría de las configuraciones de monitoreo de SharePoint omiten. Los contadores del servidor le dicen que un componente está estresado. Solo una comprobación que se comporta como un usuario, iniciando sesión, abriendo una biblioteca, ejecutando una búsqueda, le dice si la granja realmente está funcionando. Dependiendo de la granja, también monitoree los pools de aplicaciones de servicio y, si todavía se usan flujos de trabajo legados, Workflow Manager.
Establezca una línea base para cada métrica durante una semana normal antes de configurar cualquier umbral. Un valor de CPU del 70% no significa nada hasta que sepa si lo normal es 40% o 65%.
Lo que capturan las herramientas integradas (y lo que no)
SharePoint Server incluye maquinaria real de monitoreo, y debería usarla. La documentación de monitoreo de Microsoft cubre tres piezas principales:
- Health Analyzer ejecuta verificaciones basadas en reglas contra la configuración de la granja y condiciones conocidas de fallo, y puede auto-reparar algunas de ellas.
- Registro diagnóstico (ULS) escribe registros de trazas detalladas que querrá durante cualquier búsqueda de la causa raíz.
- Recolección de datos de uso y salud recoge estadísticas de solicitudes y servicios en la base de datos de uso y registro.
Los equipos que usan System Center pueden agregar el paquete de administración de SharePoint y obtener alertas basadas en eventos además.
Pero observe lo que todos estos tienen en común: se ejecutan dentro de la granja y reportan sobre la granja. Ninguno puede decirle que el balanceador de carga está enviando usuarios a un nodo caído, que el certificado en el endpoint ADFS expiró, o que la carga de páginas tarda nueve segundos desde la oficina sucursal. Las reglas del Health Analyzer también se ejecutan en horarios, algunas diarias o semanales, por lo que un problema puede permanecer sin detectarse entre ejecuciones.
Las herramientas integradas son la mitad interior de una estrategia de monitoreo. La mitad exterior debe provenir de verificaciones que aborden SharePoint como lo hacen los usuarios.
Cómo monitorear lo que los usuarios realmente experimentan
La mitad exterior es el monitoreo sintético: verificaciones con guion que se ejecutan en un horario y realizan tareas reales de SharePoint. Un script útil para una granja SharePoint hace cuatro cosas:
- Paso 1: Iniciar sesión. Use una cuenta de monitoreo dedicada con acceso de menor privilegio. Cronometre el viaje de ida y vuelta completo de autenticación, incluidos los redireccionamientos SSO.
- Paso 2: Cargar una página. Abra su colección de sitios más concurrida o la página principal de la intranet y registre el tiempo de carga en un navegador real, no solo la respuesta HTML.
- Paso 3: Ejecutar una búsqueda. Consulte un término que debería devolver un documento conocido, y falle la comprobación si no lo hace. Esto detecta el retraso del índice que una vista del lado del servidor no marcaría como un problema para el usuario.
- Paso 4: Manipular un documento. Abra o descargue un archivo de prueba desde una biblioteca para validar toda la ruta a través de IIS, permisos y SQL.
Con Dotcom-Monitor, esta es una tarea de monitoreo de aplicaciones web grabada una vez con EveryStep scripting y reproducida desde dondequiera que estén sus usuarios. Para un despliegue orientado a internet o híbrido, eso significa nodos externos en las regiones de sus usuarios. Para una granja solo de intranet detrás del firewall, agentes privados ejecutan las mismas verificaciones con guion desde dentro de su red, por lo que un despliegue local no exime a la granja del monitoreo a nivel de usuario.
La autenticación merece planificación y no evitación. Si está en Entra ID (antes Azure AD), dé a la cuenta de monitoreo su propia política de acceso condicional que cambie el MFA por un rango de IP permitido para monitoreo. Donde quiera que esté la cuenta, guarde sus credenciales en una bóveda y rote las contraseñas según su calendario normal. Si su granja se autentica a través de ADFS o Entra ID, el paso de inicio de sesión también es una comprobación de salud de toda esa cadena. Cubrimos los detalles de configuración en monitoreo de aplicaciones que usan ADFS.
Y si parte de su infraestructura vive en Microsoft 365, el mismo enfoque con guiones aplica allí. Nuestra guía de monitoreo sintético de Office 365 lo explica. No puede ver los servidores de Microsoft, lo que hace que la verificación a nivel usuario sea la única medida de SharePoint Online que posee.
Cómo configurar alertas que lleguen antes que el primer ticket
El objetivo es una carrera específica: su alerta debe llegar antes que el primer ticket al servicio de ayuda. Tres prácticas deciden esto.
Alertar con el número que ve el usuario, diagnosticar con el del servidor. Llame al personal de guardia cuando el tiempo de inicio de sesión se triplique o falle la verificación de búsqueda, porque eso es lo que genera tickets. Deje que las métricas de CPU y disco anoten la alerta y no que la impulsen. Las alertas basadas en contadores del servidor hacen que los equipos terminen ignorando sus propias alertas. Dos reglas iniciales que funcionan: alertar cuando el tiempo de inicio de sesión sea el doble de su línea base en dos verificaciones consecutivas, y alertar cuando la verificación de búsqueda no devuelva el resultado conocido.
Verificar antes de despertar a alguien. Una comprobación que falla una vez desde una ubicación puede ser un fallo de red momentáneo. Una que falla desde dos ubicaciones, o dos veces seguidas, es un incidente. La mayoría del agotamiento por alertas se atribuye a saltarse este paso. Dotcom-Monitor realiza la re-verificación desde una segunda ubicación automáticamente antes de que salga una alerta.
Emparejar la frecuencia con las matemáticas del SLA. Si es responsable de un 99.9% de tiempo en línea, tiene aproximadamente 43 minutos de inactividad por mes. Una verificación que se ejecuta cada 15 minutos puede consumir un tercio de ese presupuesto antes de dispararse una vez. Ejecute verificaciones a nivel de usuario cada uno a cinco minutos en los flujos que importan, y programe ventanas de mantenimiento en la herramienta de monitoreo para que las noches de parcheo no alerten a nadie ni contaminen el registro de disponibilidad.
Cómo reportar el tiempo en línea de SharePoint contra su SLA
La mayoría de los equipos de SharePoint responden a un SLA, ya sea un compromiso contractual o una promesa interna al negocio. La configuración de monitoreo anterior produce la evidencia: un registro con sello de tiempo de cada verificación, cada fallo y cada tiempo de respuesta, independiente de los propios registros de la granja.
Esa independencia es importante. Cuando los registros de la granja dicen “saludable” y los usuarios dicen “lento”, un tercer registro medido desde el lado del usuario zanja la discusión. También le ofrece algo que los paneles de servicio de Microsoft nunca darán para entornos híbridos: un número continuo de disponibilidad que abarca instalaciones locales y la nube.
Un informe SLA mensual necesita tres cosas: tiempo medido contra el objetivo, tendencias de tiempo de respuesta en los flujos de usuario que usted programa, y una lista de incidentes con duración y causa raíz. Los informes de disponibilidad y SLA generan los dos primeros directamente desde el historial de verificaciones, programados para quien los necesite. La línea de tendencia se justifica entre incidentes. Una carga de página que pasa de un segundo a tres durante un trimestre es una advertencia temprana de capacidad en la que puede actuar antes de que se convierta en una avalancha de tickets.
Qué herramienta de monitoreo de SharePoint se adapta a su entorno
Diferentes herramientas vigilan diferentes mitades del problema, así que la comparación honesta es por punto de vista.
Herramientas integradas (gratis). Health Analyzer, registros ULS y recolección de datos de uso. Úselas independientemente de lo que compre. Configuran la granja correctamente y apoyan la investigación de causas raíz, pero no le alertarán en tiempo real ni medirán la experiencia del usuario.
Monitores de infraestructura basados en agentes. ManageEngine Applications Manager y SolarWinds Server & Application Monitor ofrecen plantillas SharePoint que recogen contadores de la granja: tamaños de base de datos, fallos de trabajos programados, salud de IIS y SQL, solicitudes por segundo. PRTG cubre terreno similar con sensores preconstruidos para Windows, IIS y SQL, extensibles con scripts personalizados. Opciones sólidas para las filas del lado servidor en la tabla anterior, y si ya usa uno para su entorno Windows, apúntelo a la granja. En tiendas con System Center, SCOM con el paquete de administración de SharePoint cubre el mismo terreno.
Plataformas de monitoreo sintético. Dotcom-Monitor funciona desde el lado del usuario: inicios de sesión con guion, cargas de página, búsquedas y transacciones de documentos desde nodos externos o agentes privados, con alertas e informes SLA integrados en esas verificaciones. Esta es la capa que gana la carrera contra el primer ticket, atrapa lo que las herramientas basadas en agentes estructuralmente no pueden, y para SharePoint Online es la única capa disponible.
La mayoría de los equipos que lo hacen bien terminan emparejando una herramienta interna con una externa. Lo que importa es que ambas mitades existan, porque el punto ciego de una es el cobertura principal de la otra.
Conclusión
El monitoreo de servidores SharePoint funciona cuando cubre ambas mitades: métricas de la granja que explican problemas y verificaciones a nivel de usuario que los detectan. Vigile la lista corta de contadores que predicen el dolor, grabe las cuatro acciones de usuario que importan, alerte sobre lo que sienten los usuarios con verificación integrada, y deje que el historial de verificaciones sirva también como su informe SLA.
