So werden die meisten SharePoint-Ausfälle entdeckt: durch ein Helpdesk-Ticket. Jemand in der Finanzabteilung kann eine Dokumentbibliothek nicht öffnen, es folgen drei weitere Tickets und bis das Administratorenteam das Problem bestätigt, hat bereits die Hälfte der Firma es bemerkt.
Die Server der Farm waren wahrscheinlich die ganze Zeit „online“. Das ist die Falle bei SharePoint Server. Ein einzelner Seitenaufruf durchläuft die IIS-Frontends, die Authentifizierungskette, Serviceanwendungen und den SQL Server. Jede dieser Ebenen kann sich verschlechtern, während alle grundlegenden Verfügbarkeitsprüfungen weiterhin grün bleiben.
Dieser Leitfaden behandelt, was auf einer SharePoint-Farm tatsächlich überwacht werden muss, wo die integrierten Werkzeuge aufhören, wie man Alarme setzt, die vor dem ersten Ticket ausgelöst werden, und wie man Monitoring-Daten in einen SLA-Bericht umwandelt, den Ihr Management akzeptiert.
Warum SharePoint-Probleme das Helpdesk erreichen, bevor Sie es tun
Ping- und Portprüfungen beantworten eine Frage: Ist der Server erreichbar? SharePoint fällt auf Arten aus, die diese Frage nie berühren.
Betrachten wir einen Anmeldeansturm am Montagmorgen. Hunderte Mitarbeitende authentifizieren sich um 9 Uhr, die ADFS-Server kommen nicht hinterher und Anmeldungen, die normalerweise zwei Sekunden dauern, brauchen vierzig. Jeder Server antwortet auf Ping. IIS liefert 200er-Statuscodes. Aber niemand kann ins Intranet, und die Tickets beginnen.
Oder die langsamere Version: Die Festplattenlatenz auf dem SQL-Volume, das Ihre größte Inhaltsdatenbank hält, steigt über einen Monat hinweg an. Seitenladezeiten steigen von einer auf vier Sekunden. Keine Schwelle wird ausgelöst, da niemand die geänderte Zahl beobachtete.
Das Muster ist in beiden Fällen gleich. Die fehlerhafte Ebene sitzt zwischen „Server ist online“ und „Benutzer hat sein Dokument erhalten“ – und dieses Zwischengebiet muss genau das abdecken, was SharePoint-Server-Monitoring leisten muss.
Was auf einer SharePoint-Serverfarm überwacht werden sollte
Sie brauchen keine Hunderten von Zählern. Sie benötigen die kurze Liste, die Benutzerschmerz vorhersagt und konsequent überwacht wird.
| Ebene | Was zu beobachten ist | Warum |
|---|---|---|
| IIS-Frontends | Anfragewarteschlangenlänge, 5xx-Rate, CPU und Arbeitsspeicher, Recycling der App-Pools | Anstehende Anfragen sind das früheste Zeichen, dass die Farm mit der Last nicht mehr mithalten kann. |
| SQL Server | Festplatten-Lese-/Schreiblatenz auf Inhaltsdatenbank-Volumes, Sperr-Wartezeiten, Wachstum des Transaktionsprotokolls | Fast jede SharePoint-Operation endet in SQL. Langsame Festplatten verzögern alles. |
| Suche | Frische der Indizierung, Rückstand der Indexierwarteschlange, Suchlatenz | Veraltete oder langsame Suche ist eine der häufigsten SharePoint-Beschwerden und verschlechtert sich unbemerkt. |
| Timer-Jobs | Anzahl fehlgeschlagener Jobs, letzte Laufzeit kritischer Jobs | Fehlgeschlagene Timer-Jobs brechen still Workflows, Profilsynchronisationen und Nutzungsberichte. |
| Distributed Cache | Status des Cache-Hosts auf jedem Server, auf dem es läuft, Gesundheitszustand des AppFabric-Dienstes | Anmeldungstoken und Feeds leben hier, und ein schlechter Cache-Host verursacht farmweite Symptome, die schwer nachzuvollziehen sind. |
| Authentifizierung | Anmeldungs-Rundlaufzeit über AD, ADFS oder Entra ID | Authentifizierung ist ein farmweiter Single Point of Failure, den Servermetriken kaum widerspiegeln. |
| Benutzererfahrung | Anmeldezeit, Seitenladezeit auf wichtigen Site Collections, Suchantwortzeit, Dokumenten-Upload/-Download | Das fühlt der Nutzer tatsächlich, und so sind auch die Bedingungen in Ihrem SLA formuliert. |
Die letzte Zeile wird in den meisten SharePoint-Monitoring-Setups übersprungen. Server-Metriken sagen Ihnen, dass eine Komponente belastet ist. Nur eine Prüfung, die sich wie ein Benutzer verhält – Anmelden, Öffnen einer Bibliothek, Suchen – sagt Ihnen, ob die Farm tatsächlich liefert. Je nach Farm sollten Sie auch die Serviceanwendungspools beobachten und falls noch Legacy-Workflows genutzt werden, den Workflow Manager.
Legen Sie für jede Metrik eine Basislinie während einer normalen Woche fest, bevor Sie Schwellenwerte definieren. Ein CPU-Wert von 70 % sagt nichts aus, bis Sie wissen, ob normal 40 % oder 65 % sind.
Was die eingebauten Tools erfassen (und was sie verpassen)
SharePoint Server bringt echte Monitoring-Werkzeuge mit, und Sie sollten sie nutzen. Microsofts Monitoring-Dokumentation beschreibt drei Hauptkomponenten:
- Health Analyzer führt regelbasierte Prüfungen der Farmkonfiguration und bekannter Fehlerzustände durch und kann einige davon selbst reparieren.
- Diagnose- (ULS-) Protokollierung schreibt detaillierte Trace-Logs, die Sie bei der Ursachenforschung brauchen.
- Nutzungs- und Gesundheitsdaten-Erfassung sammelt Anforderungs- und Dienstestatistiken in der Nutzungs- und Protokolldatenbank.
Teams, die System Center verwenden, können das SharePoint-Management-Pack hinzufügen und ereignisgesteuerte Warnmeldungen erhalten.
Beachten Sie aber, was all diese gemeinsam haben: Sie laufen innerhalb der Farm und berichten über die Farm. Keines dieser Tools kann Ihnen sagen, dass der Load Balancer Benutzer auf einen ausgefallenen Knoten schickt, dass das Zertifikat am ADFS-Endpunkt abgelaufen ist oder dass Seitenladezeiten neun Sekunden vom Niederlassungsbüro betragen. Health Analyzer-Regeln laufen auch zeitgesteuert, manche täglich oder wöchentlich, sodass ein Problem zwischen den Läufen unentdeckt bleiben kann.
Die eingebauten Tools sind die Innenseite einer Monitoring-Strategie. Die Außenseite muss durch Prüfungen kommen, die SharePoint wie Nutzer behandeln.
Wie man das überwacht, was Nutzer tatsächlich erleben
Die Außenseite ist synthetisches Monitoring: Skript-basierte Prüfungen, die zeitgesteuert reale SharePoint-Aufgaben ausführen. Ein nützliches Skript für eine SharePoint-Farm macht vier Dinge:
- Schritt 1: Anmelden. Verwenden Sie ein dediziertes Monitoring-Konto mit minimalen Rechten. Messen Sie die gesamte Authentifizierungs-Rundlaufzeit, inklusive aller SSO-Umleitungen.
- Schritt 2: Eine Seite laden. Öffnen Sie Ihre meistgenutzte Site Collection oder die Intranet-Startseite und zeichnen Sie die Ladezeit in einem echten Browser auf, nicht nur die HTML-Antwort.
- Schritt 3: Eine Suche ausführen. Fragen Sie einen Begriff ab, der ein bekanntes Dokument zurückliefern sollte, und schlagen Sie fehl, wenn nicht. Das erkennt Indexverzögerungen, die eine serverseitige Ansicht nicht als Benutzerproblem meldet.
- Schritt 4: Ein Dokument berühren. Öffnen oder laden Sie eine Testdatei aus einer Bibliothek, um den vollständigen Pfad über IIS, Berechtigungen und SQL zu validieren.
Mit Dotcom-Monitor ist das eine Webanwendungsüberwachung, die einmal mit EveryStep-Scripting aufgezeichnet und von überall, wo Ihre Nutzer sind, wiedergegeben wird. Für eine internetbasierte oder hybride Installation bedeutet das externe Knoten in den Regionen Ihrer Nutzer. Für eine intranet-only Farm hinter der Firewall führen private Agents dieselben Skriptprüfungen innerhalb Ihres Netzwerks aus, sodass eine lokale Installation das User-Level-Monitoring nicht ausschließt.
Authentifizierung erfordert Planung, nicht Vermeidung. Wenn Sie Entra ID (ehemals Azure AD) verwenden, geben Sie dem Monitoring-Konto eine eigene Conditional Access Policy, die MFA gegen eine erlaubte Monitoring-IP-Range tauscht. Egal wo das Konto ist, speichern Sie seine Zugangsdaten in einem Tresor und rotieren diese nach Ihrem üblichen Plan. Wenn Ihre Farm über ADFS oder Entra ID authentifiziert, ist der Login-Schritt auch ein Gesundheitscheck dieser gesamten Kette. Details zur Einrichtung behandeln wir in Monitoring von Anwendungen, die ADFS verwenden.
Und wenn ein Teil Ihres Bestands in Microsoft 365 liegt, gilt der gleiche skriptbasierte Ansatz dort. Unser Leitfaden zur synthetischen Überwachung von Office 365 führt Sie durch den Prozess. Sie haben keinen Einblick in Microsofts Server, deshalb ist die User-Level-Prüfung die einzige Messgröße, die Sie für SharePoint Online besitzen.
Wie man Alarme setzt, die vor dem ersten Ticket kommen
Das Ziel ist ein klares Rennen: Ihr Alarm muss vor dem ersten Helpdesk-Ticket eintreffen. Drei Vorgehensweisen entscheiden darüber.
Alarmieren Sie auf der benutzerorientierten Metrik, diagnostizieren Sie mit der Server-Metrik. Rufen Sie den Bereitschaftsdienst, wenn die Anmeldezeit sich verdreifacht oder die Suche fehlschlägt, denn daraus entstehen die Tickets. Lassen Sie CPU- und Festplattenmetriken den Alarm ergänzen und nicht steuern. Paging basierend auf Serverzählern führt dazu, dass Teams ihre eigenen Alarme ignorieren. Zwei funktionierende Grundregeln: Rufen Sie an, wenn die Anmeldezeit für zwei aufeinanderfolgende Prüfungen das Doppelte der Basislinie erreicht, und rufen Sie an, wenn die Suchprüfung ein bekanntes Ergebnis verfehlt.
Überprüfen Sie, bevor Sie jemanden wecken. Ein einmaliger Prüfungsfehler an einem Standort kann ein Netzwerkproblem sein. Ein Fehler an zwei Standorten oder zweimal hintereinander ist ein Vorfall. Die meisten Alarmmüdigkeiten resultieren daraus, diesen Schritt zu überspringen. Dotcom-Monitor führt automatisch eine Nachprüfung von einem zweiten Standort durch, bevor ein Alarm ausgelöst wird.
Passen Sie die Frequenz an die SLA-Mathematik an. Für 99,9 % Verfügbarkeit haben Sie rund 43 Minuten Ausfallzeit pro Monat. Eine Prüfung, die alle 15 Minuten ausgeführt wird, kann ein Drittel dieses Budgets verbrauchen, bevor sie einmal anschlägt. Führen Sie User-Level-Prüfungen alle ein bis fünf Minuten auf den wichtigsten Abläufen durch und planen Sie Wartungsfenster im Monitoring-Tool, damit Patchnächte niemanden alarmieren oder die Verfügbarkeitsaufzeichnung verfälschen.
Wie man SharePoint-Verfügbarkeit gegen das SLA berichtet
Die meisten SharePoint-Teams sind einem SLA verpflichtet, sei es eine vertragliche Vereinbarung oder ein internes Versprechen an das Business. Die oben beschriebene Monitoring-Konfiguration liefert den Beweis: eine zeitgestempelte Aufzeichnung jeder Prüfung, jedes Fehlers und jeder Antwortzeit, unabhängig von den eigenen Logs der Farm.
Diese Unabhängigkeit ist wichtig. Wenn die Farmprotokolle „gesund“ sagen und die Nutzer „langsam“, schafft ein dritter, von der Nutzerseite gemessener Datensatz Klarheit im Streit. Er bietet Ihnen auch etwas, das Microsofts Service Dashboards für hybride Umgebungen nie bieten werden: eine durchgehende Verfügbarkeitszahl über On-Premises und Cloud.
Ein monatlicher SLA-Bericht benötigt drei Dinge: gemessene Verfügbarkeit gegenüber dem Ziel, Antwortzeittrends bei den von Ihnen geskripteten Nutzerabläufen und eine Liste der Vorfälle mit Dauer und Ursache. Verfügbarkeits- und SLA-Berichte erzeugen die ersten zwei direkt aus dem Prüfungsverlauf, zeitgesteuert an die Zuständigen. Die Trendlinie zahlt sich zwischen den Vorfällen aus. Eine Seitenladezeit, die über ein Quartal von einer auf drei Sekunden steigt, ist eine frühe Kapazitätswarnung, auf die Sie reagieren können, bevor es eine Flut an Tickets gibt.
Welches SharePoint-Monitoring-Tool passt zu Ihrer Umgebung
Verschiedene Tools überwachen unterschiedliche Teile des Problems, also ist der ehrliche Vergleich vom Blickwinkel abhängig.
Integrierte Tools (kostenlos). Health Analyzer, ULS-Protokolle und Nutzungsdatenerfassung. Nutzen Sie sie unabhängig von weiterer Software. Sie konfigurieren die Farm korrekt und unterstützen die Ursachenanalyse, lösen aber keine Echtzeit-Alerts aus und messen die Benutzererfahrung nicht.
Agent-basierte Infrastruktur-Monitore. ManageEngine Applications Manager und SolarWinds Server & Application Monitor bieten SharePoint-Templates zur Sammlung von Farmzählern: Datenbankgrößen, fehlgeschlagene Timerjobs, IIS- und SQL-Gesundheit, Anfragen pro Sekunde. PRTG deckt ähnliches mit vorkonfigurierten Sensoren für Windows, IIS und SQL ab, erweiterbar mit eigenen Skripten. Gute Wahl für die serverseitigen Zeilen der obigen Tabelle, und wenn Sie bereits einen für Ihre Windows-Umgebung einsetzen, richten Sie ihn auf die Farm aus. In System Center-Umgebungen deckt SCOM mit dem SharePoint Management Pack dasselbe ab.
Synthetische Monitoring-Plattformen. Dotcom-Monitor arbeitet von der Benutzerseite aus: geskriptete Anmeldungen, Seitenladezeiten, Suchen und Dokumenttransaktionen von externen Knoten oder privaten Agents mit Alarmierung und SLA-Bericht basierend auf diesen Prüfungen. Diese Schicht gewinnt das Rennen gegen das erste Ticket, erfasst was agent-basierte Tools strukturell nicht können, und ist für SharePoint Online die einzige verfügbare Schicht.
Die meisten Teams, die das gut machen, kombinieren ein internes Tool mit einem externen. Entscheidend ist, dass beide Hälften existieren, weil jede den blinden Fleck der anderen abdeckt.
Das Fazit
SharePoint-Server-Monitoring funktioniert, wenn es beide Seiten abdeckt: Farm-Metriken, die Probleme erklären, und Nutzerprüfungen, die sie erkennen. Beobachten Sie die kurze Liste an Zählern, die Schmerz vorhersagen, skripten Sie die vier wichtigen Nutzeraktionen, alarmieren Sie anhand dessen, was Nutzer fühlen, mit integrierter Verifikation, und lassen Sie den Prüfungsverlauf gleichzeitig Ihren SLA-Bericht sein.
