Eigene Berichte für Operations Manager: So gelingt der Einstieg

Die Standardberichte reichen nicht? Mit verknüpften Berichten, gezielten Abfragen auf das Data Warehouse und Berichtsabonnements bauen Sie Auswertungen, die wirklich gelesen werden.

Operations Manager sammelt über Monate und Jahre Leistungs-, Verfügbarkeits- und Alarmdaten im Data Warehouse. Die mitgelieferten Berichte decken viele Standardfälle ab – doch spätestens wenn das Management „die CPU-Auslastung aller SQL-Server der letzten 30 Tage mit Schwellwertlinie“ sehen möchte, geht es um eigene Berichte. Aus einer umfangreichen Linksammlung unserer Community haben wir die wichtigsten Wege zusammengefasst.

Weg 1: Verknüpfte Berichte (Linked Reports)

Der einfachste Einstieg: Einen vorhandenen generischen Bericht – etwa Performance oder Performance Top Objects – mit festen Parametern speichern. In der Konsole wählen Sie dazu Objekte, Leistungsindikatoren und Zeitraum aus und speichern das Ergebnis als Favoriten oder veröffentlichen es als eigenen Bericht. Für alle Benutzer verfügbar wird er, wenn Sie ihn in einem Management Pack als Linked Report hinterlegen.

Tipp: Statt einzelner Server sollten Sie im Bericht Gruppen auswählen. Dann wächst der Bericht automatisch mit, wenn neue Server hinzukommen.

Weg 2: Eigene Abfragen auf das Data Warehouse

Für alles, was die generischen Berichte nicht können, schreiben Sie eigene SQL-Abfragen gegen die Datenbank OperationsManagerDW und bauen daraus einen Bericht in SQL Server Reporting Services (SSRS) bzw. Report Builder. Verwenden Sie dabei ausschließlich die dokumentierten Views. Ein Beispiel für die stündliche CPU-Auslastung der letzten sieben Tage:

SELECT  me.Path              AS Server,
        pr.ObjectName, pr.CounterName,
        ph.[DateTime],
        ph.AverageValue, ph.MaxValue
FROM    Perf.vPerfHourly ph
JOIN    dbo.vPerformanceRuleInstance pri ON pri.PerformanceRuleInstanceRowId = ph.PerformanceRuleInstanceRowId
JOIN    dbo.vPerformanceRule pr          ON pr.RuleRowId = pri.RuleRowId
JOIN    dbo.vManagedEntity me            ON me.ManagedEntityRowId = ph.ManagedEntityRowId
WHERE   pr.ObjectName  = 'Processor Information'
  AND   pr.CounterName = '% Processor Time'
  AND   ph.[DateTime] > DATEADD(DAY, -7, GETUTCDATE())
ORDER BY me.Path, ph.[DateTime];

Die Aggregationstabellen vPerfHourly und vPerfDaily sind für Berichte über längere Zeiträume deutlich performanter als die Rohdaten (vPerfRaw). Eine Schwellwertlinie fügen Sie im Diagramm einfach als zusätzliche, konstante Datenreihe hinzu.

Weg 3: Berichte automatisch zustellen

Jeder Bericht lässt sich in der Konsole abonnieren (Schedule): als E-Mail-Anhang, auf eine Dateifreigabe oder – über SSRS – in eine Dokumentbibliothek. So landet der Monatsbericht pünktlich beim Empfänger, ohne dass jemand die Konsole öffnen muss.

Nützliche Grundlagen

• Das Schema des Data Warehouse ist dokumentiert; die wichtigsten Views sind vManagedEntity, vPerformanceRule(Instance), vAlert und vStateHourly/vStateDaily für Verfügbarkeit.
• Daten werden je nach Datensatz unterschiedlich lange aufbewahrt. Für Jahresvergleiche muss die Aufbewahrung im Data Warehouse ggf. angepasst werden.
• Das Logical Disk Extension-Prinzip – zusätzliche Indikatoren sammeln, um sie später auszuwerten – gilt allgemein: Ein Bericht kann nur zeigen, was vorher gesammelt wurde.