Voici comment la plupart des pannes SharePoint sont découvertes : un ticket au service d’assistance. Quelqu’un des finances ne peut pas ouvrir une bibliothèque de documents, trois autres tickets suivent, et au moment où l’équipe d’administration confirme le problème, la moitié de l’entreprise en est déjà impactée.
Les serveurs de la ferme étaient probablement “en ligne” tout le temps. C’est le piège avec SharePoint Server. Un seul chargement de page traverse les frontaux IIS, la chaîne d’authentification, les applications de service et SQL Server. N’importe laquelle de ces couches peut se dégrader tandis que tous les contrôles de disponibilité de base restent verts.
Ce guide explique ce qu’il faut réellement surveiller sur une ferme SharePoint, où s’arrêtent les outils intégrés, comment configurer des alertes qui se déclenchent avant le premier ticket, et comment transformer les données de surveillance en un rapport SLA que votre direction acceptera.
Pourquoi les problèmes SharePoint arrivent au service d’assistance avant vous
Les contrôles ping et port répondent à une seule question : le serveur est-il joignable ? SharePoint échoue de façons que cette question ne touche jamais.
Considérez une tempête de connexions un lundi matin. Des centaines d’employés s’authentifient à 9 h, les serveurs ADFS prennent du retard, et les connexions qui prennent habituellement deux secondes en prennent quarante. Tous les serveurs répondent au ping. IIS renvoie des 200. Mais personne ne peut accéder à l’intranet, et les tickets commencent.
Ou la version plus lente : la latence disque sur le volume SQL contenant votre plus grande base de contenu augmente progressivement sur un mois. Le temps de chargement passe d’une à quatre secondes. Aucun seuil n’est dépassé, parce que personne ne surveillait ce chiffre mouvant.
Le schéma est le même dans les deux cas. La couche défaillante se trouve entre « le serveur est en ligne » et « l’utilisateur a obtenu son document », et ce territoire intermédiaire est exactement ce que la surveillance de serveur SharePoint doit couvrir.
Ce qu’il faut surveiller sur une ferme SharePoint Server
Vous n’avez pas besoin de centaines de compteurs. Vous avez besoin de la liste courte qui prédit la douleur utilisateur, surveillée régulièrement.
| Couche | À surveiller | Pourquoi |
|---|---|---|
| Frontaux IIS | Longueur de la file d’attente des requêtes, taux 5xx, CPU et mémoire, recyclages des pools d’applications | Les requêtes en file d’attente sont le premier signe que la ferme ne peut pas suivre la charge. |
| SQL Server | Latence des lectures/écritures disque sur les volumes de base de contenu, attentes de blocage, croissance du journal de transaction | Presque toutes les opérations SharePoint se terminent dans SQL. Des disques lents ici ralentissent tout. |
| Recherche | Fraîcheur du crawl, arriéré de la file d’attente de crawl, latence des requêtes | Une recherche obsolète ou lente est l’une des plaintes SharePoint les plus rapportées, et se dégrade silencieusement. |
| Tâches planifiées | Nombre de tâches échouées, dernière exécution des tâches critiques | Les tâches planifiées échouées cassent silencieusement les flux de travail, la synchronisation des profils et les rapports d’utilisation. |
| Cache Distribué | Statut de l’hôte cache sur chaque serveur qui l’exécute, santé du service AppFabric | Les jetons de connexion et flux résident ici, et un mauvais hôte cache provoque des symptômes dans toute la ferme difficiles à tracer. |
| Authentification | Temps aller-retour de connexion via AD, ADFS ou Entra ID | L’authentification est un point unique de défaillance sur toute la ferme que les compteurs serveur reflètent à peine. |
| Expérience utilisateur | Temps de connexion, chargement de page sur les collections de sites clés, réponse de recherche, téléchargement/upload de document | C’est ce que ressentent les utilisateurs, et en quels termes votre SLA est rédigé. |
La dernière ligne est celle que la plupart des installations de surveillance SharePoint sautent. Les compteurs serveur vous disent qu’un composant est stressé. Seul un contrôle qui se comporte comme un utilisateur, se connectant, ouvrant une bibliothèque, lançant une recherche, vous dit si la ferme livre réellement. Selon la ferme, surveillez aussi les pools d’applications des services, et, si des flux de travail hérités sont encore utilisés, Workflow Manager.
Établissez une baseline pour chaque métrique pendant une semaine normale avant de définir des seuils. Une lecture CPU à 70 % ne signifie rien tant que vous ne savez pas si la normale est à 40 % ou 65 %.
Ce que les outils intégrés captent (et ce qu’ils manquent)
SharePoint Server est livré avec un vrai moteur de surveillance, et vous devriez l’utiliser. La documentation de Microsoft sur la surveillance couvre trois éléments principaux :
- Health Analyzer exécute des contrôles basés sur des règles contre la configuration de la ferme et les conditions d’échec connues, et peut en auto-réparer certaines.
- Logging diagnostique (ULS) écrit des journaux de trace détaillés dont vous aurez besoin lors de toute recherche de cause racine.
- Collecte des données d’usage et de santé rassemble les statistiques de requêtes et de services dans la base de données d’usage et de journalisation.
Les équipes utilisant System Center peuvent ajouter le pack de gestion SharePoint et obtenir des alertes basées sur les événements en plus.
Mais remarquez ce qu’ils ont en commun : ils s’exécutent à l’intérieur de la ferme et rapportent sur la ferme. Aucun ne peut vous dire que le répartiteur de charge envoie les utilisateurs vers un nœud mort, que le certificat sur le point de terminaison ADFS a expiré, ou que les chargements de page prennent neuf secondes depuis un bureau distant. Les règles de Health Analyzer s’exécutent aussi sur des horaires, certains quotidiens ou hebdomadaires, donc un problème peut rester non détecté entre les exécutions.
Les outils intégrés représentent la moitié interne d’une stratégie de surveillance. L’autre moitié doit venir de contrôles qui abordent SharePoint comme les utilisateurs.
Comment surveiller ce que les utilisateurs expérimentent réellement
La moitié extérieure est la surveillance synthétique : des contrôles scriptés qui s’exécutent selon un planning et effectuent de vraies tâches SharePoint. Un script utile pour une ferme SharePoint fait quatre choses :
- Étape 1 : Se connecter. Utilisez un compte de surveillance dédié avec un accès au moindre privilège. Mesurez le temps complet du tour d’authentification, incluant tous les redirections SSO.
- Étape 2 : Charger une page. Ouvrez votre collection de sites la plus fréquentée ou la page d’accueil intranet et enregistrez le temps de chargement dans un vrai navigateur, pas juste la réponse HTML.
- Étape 3 : Effectuer une recherche. Interrogez un terme qui devrait retourner un document connu, et échouez le contrôle s’il ne le fait pas. Cela détecte un retard d’index que la vue côté serveur ne signalerait pas comme un problème utilisateur.
- Étape 4 : Manipuler un document. Ouvrez ou téléchargez un fichier test d’une bibliothèque pour valider le chemin complet à travers IIS, les permissions et SQL.
Avec Dotcom-Monitor, il s’agit d’une surveillance d’application web enregistrée une fois avec le scripting EveryStep et rejouée depuis vos zones utilisateurs. Pour un déploiement externe ou hybride, cela signifie des nœuds externes dans les régions de vos utilisateurs. Pour une ferme intranet uniquement derrière le pare-feu, les agents privés exécutent les mêmes contrôles scriptés en interne pour que le déploiement sur site ne dispense pas la ferme d’une surveillance au niveau utilisateur.
L’authentification mérite une planification plutôt qu’une évitement. Si vous êtes sur Entra ID (anciennement Azure AD), donnez au compte de surveillance sa propre politique d’accès conditionnel qui remplace la MFA par une plage IP de surveillance autorisée. Où que soit le compte, stockez ses identifiants dans un coffre-fort et faites-les tourner selon votre planning habituel. Si votre ferme authentifie via ADFS ou Entra ID, l’étape de connexion fait aussi office de contrôle de santé sur toute cette chaîne. Nous couvrons les détails d’installation dans la surveillance des applications utilisant ADFS.
Et si une partie de votre parc vit dans Microsoft 365, la même approche scriptée s’y applique. Notre guide de la surveillance synthétique Office 365 l’explicite. Vous ne pouvez pas voir les serveurs de Microsoft, ce qui fait du contrôle utilisateur le seul indicateur de SharePoint Online dont vous disposez.
Comment configurer des alertes qui surviennent avant le premier ticket
Le but est une course spécifique : votre alerte doit arriver avant le premier ticket support. Trois pratiques en décident.
Alertez sur le chiffre ressenti par l’utilisateur, diagnostiquez avec les chiffres serveur. Avertissez l’équipe de garde quand le temps de connexion triple ou que le contrôle de recherche échoue, car c’est ce qui génère des tickets. Laissez les métriques CPU et disque annoter l’alerte plutôt que la piloter. Les alertes sur compteurs serveur sont la raison pour laquelle les équipes finissent par ignorer leurs propres alertes. Deux règles de départ qui fonctionnent : alerter quand le temps de connexion dépasse deux fois la baseline pendant deux contrôles consécutifs, et alerter quand le contrôle de recherche rate son résultat connu.
Vérifiez avant de réveiller quelqu’un. Un contrôle qui échoue une fois depuis un emplacement peut être un petit problème réseau. Un contrôle qui échoue depuis deux emplacements, ou deux fois de suite, est un incident. La plupart de la fatigue d’alerte vient de sauter cette étape. Dotcom-Monitor refait automatiquement le contrôle depuis un second emplacement avant qu’une alerte soit envoyée.
Adaptez la fréquence aux calculs SLA. Si vous êtes responsable d’un temps de disponibilité de 99,9 %, vous avez environ 43 minutes d’indisponibilité par mois. Un contrôle toutes les 15 minutes peut brûler un tiers de ce budget avant de se déclencher une fois. Exécutez des contrôles au niveau utilisateur toutes les une à cinq minutes sur les flux qui comptent, et planifiez des fenêtres de maintenance dans l’outil de surveillance afin que les mises à jour nocturnes ne réveillent personne ni n’altèrent la mesure de disponibilité.
Comment rendre compte de la disponibilité SharePoint par rapport à votre SLA
La plupart des équipes SharePoint répondent à un SLA, qu’il soit un engagement contractuel ou une promesse interne à l’entreprise. La configuration de surveillance ci-dessus produit les preuves : un enregistrement horodaté de chaque contrôle, chaque échec, et chaque temps de réponse, indépendant des propres journaux de la ferme.
Cette indépendance est importante. Quand les journaux de la ferme disent « sain » et que les utilisateurs disent « lent », un troisième enregistrement mesuré côté utilisateur tranche le débat. Il vous donne aussi ce que les tableaux de bord de service Microsoft ne fourniront jamais pour les environnements hybrides : un seul chiffre continu de disponibilité à travers les on-premises et le cloud.
Un rapport SLA mensuel nécessite trois éléments : la disponibilité mesurée contre la cible, les tendances des temps de réponse sur les flux utilisateur que vous scriptiez, et une liste des incidents avec durée et cause racine. Les rapports de disponibilité et SLA génèrent directement les deux premiers à partir des historiques de contrôle, planifiés pour quiconque en a besoin. La ligne de tendance justifie son existence entre les incidents. Un chargement de page qui passe d’une seconde à trois sur un trimestre est un avertissement précoce de capacité que vous pouvez agir avant qu’il ne devienne une inondation de tickets.
Quel outil de surveillance SharePoint correspond à votre environnement
Différents outils surveillent différentes parties du problème, donc la comparaison honnête se fait par point de vue.
Outils intégrés (gratuits). Health Analyzer, journaux ULS et collecte des données d’usage. Utilisez-les quel que soit ce que vous achetez d’autre. Ils configurent correctement la ferme et soutiennent les travaux d’analyse des causes, mais ne vous alertent pas en temps réel ni ne mesurent l’expérience utilisateur.
Outils de surveillance d’infrastructure agents. ManageEngine Applications Manager et SolarWinds Server & Application Monitor proposent tous deux des modèles SharePoint capturant des compteurs de ferme : tailles de base de données, échecs des tâches, santé IIS et SQL, requêtes par seconde. PRTG couvre des domaines similaires avec des capteurs préconstruits pour Windows, IIS et SQL, extensibles par des scripts personnalisés. De bons choix pour les lignes côté serveur du tableau ci-dessus, et si vous en utilisez déjà un pour votre parc Windows, pointez-le sur la ferme. Dans les environnements System Center, SCOM avec le pack de gestion SharePoint couvre le même terrain.
Plateformes de surveillance synthétique. Dotcom-Monitor agit côté utilisateur : connexions scriptées, chargements de page, recherches et transactions de documents depuis des nœuds externes ou agents privés, avec alertes et rapports SLA intégrés à ces contrôles. C’est la couche qui gagne la course contre le premier ticket, attrape ce que les agents ne peuvent pas, et pour SharePoint Online c’est la seule couche disponible.
La plupart des équipes qui réussissent cela finissent par associer un outil interne et un outil externe. Ce qui compte c’est que les deux moitiés existent, puisque chaque angle mort de l’un est la couverture principale de l’autre.
L’essentiel
La surveillance du serveur SharePoint fonctionne quand elle couvre les deux moitiés : des métriques de ferme qui expliquent les problèmes, et des contrôles au niveau utilisateur qui les détectent. Surveillez la liste courte de compteurs qui prédisent la douleur, script les quatre actions utilisateur qui comptent, alertez sur ce que les utilisateurs ressentent avec vérification intégrée, et laissez l’historique des contrôles faire aussi office de rapport SLA.
