Team Foundation Server Monitoring mit SCOM

Der Team Foundation Servers (TFS) wird heute nicht mehr nur zur Source Code Verwaltung verwendet, vielmehr unterstützt TFS die Entwickler durchgehend von der ersten Dokumentation der Anforderungen bis hin zum Release der fertigen Software. Dank der Unterstützung des gesamten Application Lifecycle ist TFS zur zentralen Komponente in der Software Entwicklung gereift. Ein Ausfall der TFS Infrastruktur hat den Stillstand der Entwicklung zur Folge, verursacht damit finanziellen Schaden und Release Termine können gefährdet werden. Daher ist es von zentraler Bedeutung, die TFS Infrastruktur adäquat zu überwachen. In diesem Beitrag möchte ich aufzeigen, wie eine solche Überwachung mit System Center Operations Manager möglich ist.

System Center Operations Manager

Der System Center Operations Manager (SCOM) ist ein Produkt der Microsoft System Center Suite. Mit Microsoft System Center kann ein IT Administrator seine IT Infrastruktur wie Netzwerke, Server und Applikationen effizient verwalten. Dazu gehört neben Installation / Deployment, Virtualisierung, Automatisierung und Backup auch das Monitoring dazu – was mit SCOM realisiert wird. SCOM selbst kann als Infrastruktur Framework betrachtet werden: Es stellt alle Komponenten zur Verfügung, um ein Monitoring überhaupt zu ermöglichen. Auf dieser Infrastruktur werden anschliessend die Monitoring-Funktionen selbst mit Management Packs nachgerüstet. Mehr dazu gleich, zuerst einen kurzen Überblick über die zentralen Komponenten der SCOM Infrastruktur:

• SCOM Datenbank
  Die zentrale SQL Datenbank speichert alle anfallenden Daten. Dies sind unter anderem Informationen zu den überwachten Komponenten, Konfiguration der Monitors und Rules, aktuelle Alerts, Leistungsdaten und die Management Packs selbst. Eine zweite SQL Datenbank (das Data Warehouse) ist dazu da, Alerts und gemessene Daten längerfristig zu speichern.
• SCOM Management Server
  Die Management Server Rolle ist die zentrale Drehscheibe in SCOM. Sowohl die Agents als auch die Verwaltungskonsolen verwenden die APIs des Management Servers. Zudem prüft der Management Server regelmässig, dass alle Zielsysteme online sind. Falls nicht, wird ein Alert geworfen. Zusätzlich alarmiert SCOM je nach Bedarf via E-Mail, SMS oder weitere Kommunikationskanäle.
• SCOM Reporting Server
  Basierend auf SQL Server Reporting Services können Reports für SCOM erstellt werden, die zum Bespiel die Auslastung eines Servers über eine gewisse Zeit oder die Einhaltung der definierten Service-Level Agreements (SLA) / Service-Level Objective (SLO) aufzeigen
• SCOM Agents
  Die SCOM Agents werden auf den Zielsystemen installiert, welche effektiv überwacht werden sollen. Die Agents prüfen lokal den Status des eigenen und der relevanten Subsysteme und kommunizieren die Monitoring-Resultate dem Management Server. Die Agents ermöglichen ein tiefergehendes Monitoring, d.h. das System wird nicht nur von aussen überwacht, sondern direkt auf den Zielsystemen selbst, wodurch ein genauerer Einblick in die zu überwachenden Applikationen möglich ist.
• SCOM Konsole
  Mithilfe der Konsole kann der IT Administrator auf SCOM zugreifen. In der Konsole wird der Status der Systeme abgefragt, aktive Alerts werden angezeigt und können durch den IT Administrator bearbeitet werden. Die Konsole bietet auch die Möglichkeit, SCOM in der Funktionalität zu erweitern und Reports zu erstellen.
• Management Packs
  In den Management Packs (MP) werden die entsprechenden Monitoring-Funktionen selbst implementiert. Zum Beispiel kann in einem Management Pack ein Überwchungsskript definiert werden, welches anschliessend durch die SCOM Agents ausgeführt wird (sogenannte Rules und Monitors). Für nahezu alle Microsoft Produkte stellt Microsoft selbst entsprechende MPs zur Verfügung, die bereits eine Vielzahl an Monitoren und Regeln mit vordefinierten Schwellwerten nach Microsoft Best-Practice enthalten. Diese MPs können direkt in SCOM importiert und verwendet werden.

Dies hört sich alles nach vielen Komponenten und einem äusserst komplexen Setup an. Für kleinere Umgebungen kann SCOM aber ohne weiteres auf einem einzelnen Server betrieben werden. Für grössere Umgebungen besteht die Möglichkeit, die SCOM Komponenten auf verschiedenen Servern zu betreiben was eine bessere Skalierbarkeit gewährleistet.

TFS Monitoring

Wir wissen nun, was SCOM ist – doch wie können wir damit unsere TFS Umgebung überwachen? Die Antwort liegt auf der Hand: Microsoft stellt ein entsprechendes Management Pack für Team Foundation Server in den Versionen 2010, 2012 und 2013 zur Verfügung.

• Visual Studio 2010 Team Foundation Server Monitoring Management Pack:
  http://www.microsoft.com/en-us/download/details.aspx?id=6325
• Visual Studio 2012 Team Foundation Server Monitoring Management Pack:
  http://www.microsoft.com/en-us/download/details.aspx?id=35773
• SCOM Management Pack for Team Foundation Server 2013:
  http://www.microsoft.com/en-us/download/details.aspx?id=41696

Nachdem Import des entsprechenden TFS Management Packs in SCOM, muss dies entsprechend für die Umgebung konfiguriert werden. Ein sogenannter „RunAs“ Account muss in SCOM hinterlegt und mit dem entsprechenden „TFS Profile“ verknüpft werden. Nach Möglichkeit sollte für das TFS Monitoring ein dedizierter Active Directory Account verwendet werden. Der hinterlegte Account muss im TFS als „Team Foundation Administrator“ konfiguriert werden. Dies wird benötigt, damit SCOM auf alle TFS Komponenten zugreifen kann. Zusätzlich ist zu beachten, dass auf allen TFS Servern inklusive aller Build Server der SCOM Agent installiert sein muss.

Nach der Konfiguration führt SCOM im Hintergrund ein sogenanntes „Discovery“ aus. Dieses erkennt die installierte TFS Umgebung und beginnt direkt mit dem Monitoring. Unter anderen werden folgende Komponenten in SCOM registriert:

• TFS Installation
  Das Root-Objekt einer TFS Umgebung. Alle weiteren Komponenten werden mit diesem Objekt innerhalb von SCOM verknüpft. Dies ermöglicht es, auf einen Blick den Zustand der TFS Umgebung zu erkennen.
• TFS Application Tier
  Dies ist der TFS Applikationsserver, mit welchem sich die Endbenutzer des TFS verbinden. Bei grossen TFS Umgebungen ist es durchaus üblich, dass mehrere TFS Applikationsserver zwecks Lastverteilung und besserer Verfügbarkeit im Einsatz sind.
• TFS Team Project Collection
  Die einzelnen Team Project Collections, wie zum Beispiel die Standardmässig installierte DefaultCollection.
• TFS Proxy Server
  Alle Server, die einen TFS Proxy installiert und konfiguriert haben, werden ebenfalls durch SOCM überwacht.
• TFS Build Controllers und Agents
  Server die einen Build Controller und/oder Agents hosten.

Nachdem das erste Discovery erfolgreich abgeschlossen ist, beginnt SCOM alle oben aufgeführten TFS Komponenten zu überwachen. Im Management Pack wurden durch Microsoft Rules und Monitors erstellt, welche die Überwachung der Komponenten durchführen. Hier eine Zusammenfassung der wichtigsten:

• Verfügbarkeit
  Es wird regelmässig geprüft, ob die oben beschriebenen TFS Komponenten verfügbar sind. Dies ist nicht ein einfacher Ping-Test oder ähnlich, sondern es wird mittels Skripts und entsprechenden Abfragen die Applikationslogik und das Ergebnis mitgeprüft.
• Performance
  Auf den TFS Applikationsserver werden diverse Leistungsdaten mithilfe von Schwellwerten geprüft, zum Beispiel ob die durchschnittliche Antwortzeit des Servers in Ordnung ist. Diese Schwellwerte können an die eigene Umgebung angepasst werden.
• Ereignisse
  Es werden alle relevanten Event Log Einträge, die Fehler innerhalb von TFS anzeigen, geprüft. Sobald ein solcher Event auf einem Server auftritt – wird dieser zusätzlich in SCOM als Alert angezeigt.

Mit SCOM ist es möglich, auf Basis des Monitorings und der antretenden Fehler direkt Aktionen auszuführen, um diese Fehler zu beheben. Im TFS MP sind dazu für den TFS Job Agent und die TFS Build Services jeweils Aktionen vordefiniert, die diese im Fehlerfall neu starten. Da dies ein Eingriff in die produktive Infrastruktur ist, sind solche sogenannte Recovery Tasks standardmässig deaktiviert und müssen durch den IT Administrator explizit aktiviert werden.

Dependencies Monitoring

Nun überwachen wir unsere TFS Umgebung mit dem Management Pack von Microsoft. Fällt eine Komponente aus, werden wir von SCOM informiert. Doch für ein vollständiges Monitoring der TFS Umgebung, müssen auch alle Subsysteme überwacht werden. Damit TFS funktioniert, müssen folgende Systeme ebenfalls Fehlerfrei laufen:

• Windows Betriebssystem
• SQL Server
• IIS Web Server
• System Center Virtual Machine Manager (SCVMM) & Hyper-V bei Nutzung von Lab Management
• IT Basisinfrastruktur (Active Directory, DNS, Netzwerk, …)

Auch für diese Komponenten existieren bereits Management Packs von Microsoft. Diese sollten ebenfalls Importiert und entsprechend Konfiguriert werden. Die erwähnten MPs sind sehr umfangreich, daher nur zwei Beispiele: Das Monitoring des „Windows Operating System“ überwacht, ob der verfügbare Speicherplatz einer Disk knapp wird und informiert entsprechend, wenn der Schwellwert (Standardmässig 10%) erreicht wird. Das MP des SQL Servers überwacht unter anderem die Verfügbarkeit und Performance des SQL Servers und aller darauf gehosteten Datenbanken.

Resultat

Was gewinnen wir nun mit einem Monitoring? Wir können in Zukunft proaktiv arbeiten! Mithilfe des Monitoring bemerken wird ein Problem bereits bevor es zu einem Ausfall führt: Der Speicherplatz kann erweitert oder bereinigt werden, bevor eine Disk komplett voll ist und dadurch Ausfall verursacht. Dank des Monitorings kann die Verfügbarkeit und Stabilität der TFS Umgebung gesteigert werden. Wenn trotzdem etwas ausfällt, wird dies mithilfe des Monitorings schnell entdeckt, der IT Administrator wird bei der Fehlersuche unterstützt, und somit die Ausfallzeit möglichst kurz gehalten.

Neben der technischen Umsetzung des Monitorings, darf der organisatorische Teil nicht vergessen werden. Die auftretenden Fehler müssen durch einen IT Administrator abgearbeitet und behoben werden. Bleiben diese Liegen, nützt das Monitoring nichts. Weiter ist es zentral, dass das Monitoring an alle Systemveränderungen angepasst wird. Denn nur wenn die aktuellen Systeme überwacht werden, kann der Nutzen des Monitoring voll ausgeschöpft werden.