SharePoint 2010 : Contrôle de SharePoint

Article
08/24/2016

Don' t négliger vos efforts pour surveiller les événements SharePoint et enregistrement de données. Cela peut accroître vos performances de façon significative.

Steve Wright et Corey Erkes

Adapté de « Pro SharePoint 2010 Governance » (Apress)

Surveillance est un des aspects plus souvent négligés de l'exploitation d'une ferme SharePoint. Surveillance permet de que répondre à des questions comme, « comment bien il fonctionne? », etWill

Une partie importante de la gestion de n'importe quel système informatique recueille des informations de diagnostic que vous pouvez utiliser pour résoudre des problèmes ou de comprendre comment le système se comporte. Comme n'importe quelle application Windows, SharePoint écrit des événements importants dans les journaux des événements Windows. Ces messages contiennent des informations sur les processus qui ont démarré ou arrêté, les erreurs qui ont eu lieu et tout autre événement qui pourrait mettre en corrélation avec les événements non-SharePoint.

Fichiers de trace de SharePoint

Dossiers SharePoint retracer des informations avec un système appelé le système ULS (unifiée Logging). L'ULS est une collection de fichiers avec les données enregistrées par ses applications de services et de SharePoint. Vous pouvez également utiliser ces fichiers journaux pour les composants sur mesure pour enregistrer les opérations et les informations d'erreur d'une manière qui est automatiquement en corrélation avec d'autres événements qui se produisent au sein de la ferme.

SharePoint crée automatiquement un nouveau fichier de Journal ULS toutes les 30 minutes pour limiter la taille de chaque fichier. Ces fichiers peuvent encore devenir assez grandes, cependant. Ils sont stockés dans le répertoire des journaux sous la ruche-14 par défaut. En utilisant un chemin d'installation par défaut, le dossier est C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS.

Une des premières configurations faites dans une nouvelle batterie de serveurs de production est de déplacer ces fichiers vers un autre disque dur sur chaque serveur dans la batterie. Le disque C est critique pour le système d'exploitation en cours d'exécution. Malgré être compressés, les fichiers ULS peuvent rapidement remplir le disque et planter le système.

L'ULS peut et doit être configuré pour empêcher les données inutiles de remplissage d'espace disque. Vous pouvez accéder à ces paramètres à l'aide de l'Administration centrale (CA) sous surveillance | Configurer la journalisation des Diagnostics.

Vous pouvez définir le nombre de jours de fichiers journaux devrait être gardé sur chaque serveur. La valeur par défaut est de 14 jours. ULS fichiers plus vieux que ce nombre de jours seront automatiquement supprimés du système. Si vous avez besoin d'enregistrer de grandes quantités de données ou de maintenir une histoire indéfinie des fichiers journaux, il peut être préférable de sauvegarder et supprimer ces fichiers toutes les 30 minutes lorsque chaque fichier est fermé et le fichier suivant est créé.

Vous pouvez également configurer une quantité maximale d'espace disque. Lorsque cette limite est atteinte, les fichiers journaux plus anciens sont automatiquement supprimés pour libérer de l'espace. Journaux ULS sont rédigés sous forme de fichiers texte ordinaire, donc vous pouvez les lire à l'aide d'un éditeur de texte tel que le bloc-notes. Toutefois, ils peuvent être difficiles à lire directement car ils ne sont pas formatés commodément et peuvent être très importantes.

Pour simplifier le travail avec ces fichiers, Microsoft fournit un ULSViewer application, vous pouvez télécharger. Microsoft ne supporte pas le ULSViewer, mais il devrait répondre aux besoins des petites et moyennes fermes SharePoint. Organisations avec très grandes installations de SharePoint voudra investir dans Microsoft System Center ou des outils de gestion des systèmes tiers.

Limitation de l'événement

SharePoint est une plate-forme logicielle de vastes et complexes. Par conséquent, il peut produire une grande quantité de données de trace. Pour limiter l'impact de l'exploitation forestière de cette information, vous pouvez configurer SharePoint pour limiter la journalisation des événements basée sur la catégorie de l'événement, gravité de l'événement, et si l'événement est journalisé dans les journaux d'événements de fenêtre ou un fichier de trace ULS.

Catégorie d'événement décrit où les événements sont venus et à ce qu'elle se rapporte. Par exemple, un événement peut être consigné par l'Application Excel Services et se rapportent à l'accès aux données externes. Vous pouvez configurer chaque catégorie séparément ou conjointement avec d'autres types d'événements.

Gravité de l'événement fait référence à son impact probable sur le reste du système. Événements destinés aux journaux des événements Windows sont assignés à des niveaux croissants de gravité, y compris les commentaires, informations, avertissement, erreur ou critique. Les journaux ULS utilisent Verbose, moyen, élevé, suivi et inattendu comme niveaux de gravité.

Lorsque vous configurez la journalisation des événements, désigner un de ces niveaux comme le niveau minimal pour être enregistré. Par exemple, si vous vous connectez un événement au niveau informations, tous les événements sont enregistrés à l'exception de celles au niveau Verbose. Un niveau de gravité distinct est configuré pour chaque catégorie d'événements et de la destination enregistrement d'événement. Cela vous permet de limiter la quantité d'informations de trace générées lors de la capture de l'information la plus importante.

Par défaut, tous les événements avec un niveau de gravité ou plus de renseignements sont enregistrés dans les journaux des événements Windows. Événements à ou au-dessus du niveau de la moyens sont enregistrées dans les fichiers de trace ULS. Ces paramètres produisent la journalisation du suivi important, mais le trafic minimale journal des événements. Cela convient pour la plupart des fermes.

Protection contre les inondations de journal des événements

SharePoint 2010 peut empêcher les inondations de l'événement d'écrasant vos fichiers journaux. Un déluge d'événement se produit lorsqu'un composant détecte un problème, le signale et continue de subir le même problème. Cela peut rapidement remplir les journaux d'événements de serveur. Il peut être presque comique quand vous perdez la cause initiale d'une erreur, parce que le journal des événements a été écrasé par les erreurs résultant d'un effet secondaire du problème réel.

Pour éviter cette situation, SharePoint 2010 surveille la fréquence avec laquelle chaque événement est enregistré. S'il voit le même message enregistré plus de cinq fois en deux minutes, il enregistre le fait dans le journal et cesser l'enregistrement de chaque occurrence de cet événement. Il écrira ensuite un événement Résumé chefs événement supprimé toutes les deux minutes jusqu'à ce que disparaisse le déluge. Il retourne alors à l'enregistrement de chaque événement.

Journal des événements des inondations s'applique uniquement pour les journaux des événements Windows et pas les fichiers journaux ULS trace. Cette fonctionnalité est activée par défaut. Vous pouvez désactiver il sur la même page où vous configurez la limitation de l'événement. Vous pouvez également définir le nombre de seuil et période calme pour détection de crues des événements à l'aide de Windows PowerShell, mais pas de CA.

ID de corrélation

Comme les divers composants SharePoint peuvent générer un flot de données d'événement et trace, il peut être difficile de dire quels événements sont associés à un autre. Journaux sont stockés dans l'ordre comme éléments sont écrits pour eux. Demandes traitées en même temps peuvent générer des événements qui sont mélangés dans la séquence de journal. SharePoint résout ce problème en utilisant les ID de corrélation.

Un ID de corrélation est un GUID assigné à chaque processus SharePoint demandé. Un événement enregistré par SharePoint par suite d'une demande sera associé à cet ID de corrélation demande. ID de corrélation est également inclus dans certains messages d'erreur, les entrées de journal des événements et d'autres interfaces comme le tableau de bord développeur. Le tableau de bord développeur est un panneau de diagnostic que vous pouvez allumer pour déboguer les problèmes sur une page SharePoint.

Base de données SharePoint

SharePoint 2010 introduit une nouvelle forme de proactive enregistrement appelé la journalisation de base de données SharePoint. Cette base de données recueille un large éventail de données de tous les serveurs de la batterie. Cela vous donne une seule source pour cette information sans devoir explicitement activer la journalisation ou combiner les fichiers journaux.

La base de données est stockée sur le SQL Server dans une base de données appelée WSS_Logging. Il existe de nombreux tableaux dans cette base de données, et ils sont difficiles à interroger directement. Heureusement, Microsoft a fourni une série de vues pour simplifier la récupération d'informations provenant de ces tables.

Une grande partie des données qui sont placées dans cette base de données est collectée par un ensemble de travaux du minuteur. Pour empêcher la collecte de données fugueur dans une nouvelle batterie de serveurs, ces emplois sont désactivés par défaut. Pour collecter les informations fournies par ces fournisseurs de données diagnostiques, activez simplement les travaux du minuteur dans CA :

Fournisseur de données de diagnostic : Journal des événements
Fournisseur de données de diagnostic : Compteurs de performance - les serveurs de base de données
Fournisseur de données de diagnostic : Compteurs de performance - Web frontaux
Fournisseur de données de diagnostic : SQL en bloquant des requêtes
Fournisseur de données de diagnostic : SQL DMV
Fournisseur de données de diagnostic : Mémoire SQL DMV
Fournisseur de données de diagnostic : Journal de suivi

Il existe plusieurs catégories d'informations que vous pouvez rapporter de la base de données de journalisation. Contrairement aux journaux des événements ULS ou Windows, ces vues contiennent des informations provenant de tous les serveurs de la batterie. Ces données couvrent la totalité du contenu de la ferme ainsi que les informations d'utilisation de diagnostic, de santé et de fonctionnalité :

Journaux ULS
Journaux d'événements Windows
Les compteurs de performance pour la mémoire, e/s et CPU utilization
SQL Server Vues de gestion dynamique (DMV)
Informations sur l'utilisation de diverses fonctionnalités
Service de recherche rampant et l'interrogation
Travaux du minuteur

Don' t suppose que les seules données disponibles dans cette base de données se reflète dans les points de vue actuellement présents. Lorsque vous configurez un nouveau type d'information pour la collecte, vues et nouvelles tables apparaîtra dans WSS_Logging pour contenir cette information. Ces objets de base de données sont créés sur demande selon les besoins.

Il est important de se rappeler que la base de données de journalisation est remplie en plus les journaux des événements ULS et Windows, pas à la place d'eux. Tournant sur grandes quantités de journalisation dans l'ou l'autre mécanisme peut générer des quantités ingérables de données du journal. Considérer les outils que vous utilisez pour certaines fins et configurez-les en conséquence. N'oubliez pas de prévoir de l'espace de stockage requis pour les fichiers journaux et de base de données lorsque vous utilisez pleinement les. Manquer d'espace pour ces journaux peut entraîner la perte des informations critiques à l'époque de la pire possible.

Les informations contenues dans ces tableaux sont utiles pour diagnostiquer les problèmes et planification des fonctionnalités et mises à niveau futures. Cette base de données recueille des données au fil du temps que vous pouvez utiliser pour une tendance de performance, de son utilisation et de recherche de performance.

Steve Wright

Steve Wright est un cadre supérieur en Business Intelligence Management (BIM) pour Sogeti USA LLC à Omaha, au Nebraska. Dernière plus de 20 ans, Wright a travaillé sur le contrôle du trafic aérien, financier, d'assurance et une multitude d'autres types de systèmes. Il a été auteur et effectué des examens techniques pour nombreux titres précédents portant sur les produits Microsoft, notamment Windows, SharePoint, SQL Server et BizTalk.

Corey Erkes J'ais consultant manager pour Sogeti USA LLC à Omaha, au Nebraska. Erkes a travaillé avec un large éventail de sociétés à différents points dans les cycles de vie deleurs implémentations de SharePoint. Il est également l'un des membres fondateurs du groupe d'utilisateurs de SharePoint Omaha.**

© 2012 Apress Inc. Tous droits réservés. Imprimé avec l'autorisation d'Apress. Copyright 2012. “Pro gouvernance de SharePoint 2012" par SteveWright et CoreyErkes. Pour plus d'informations sur ce titre et autres ouvrages similaires, veuillez visiter apress.com.