Freigeben über

Problembehandlung für leere Berichte in System Center Operations Manager

Leere Berichte können ein häufiges Problem mit System Center Operations Manager sein. Diese werden aus vielen verschiedenen Gründen verursacht.

Ursprüngliche Produktversion: System Center 2012 Operations Manager
Ursprüngliche KB-Nummer: 2573329

In diesem Artikel befassen wir uns mit den folgenden häufigen Problemen:

Es gibt andere Gründe, warum Berichte möglicherweise leer zurückgegeben werden, aber sie liegen außerhalb des Gültigkeitsbereichs dieses Artikels. Für diese Probleme wird empfohlen, einen Supportfall mit dem Microsoft-Produktsupport zu öffnen und Unterstützung zu erhalten.

Der falsche Entitätstyp wurde als Berichtsziel ausgewählt.

Für dieses Problem und die anderen Probleme konzentrieren wir uns auf Leistungsberichte. Sie sind die häufigsten, um leer zurückzugeben, und die gleichen Schritte gelten normalerweise auch für die anderen Berichte. Der erste Schritt besteht darin, die Entität und den Leistungsindikator zu identifizieren, der die Berichtsdaten generiert. Die einfachste Möglichkeit, diese Informationen zu erhalten, besteht darin, die entsprechende Leistungsansicht in der Überwachung zu finden. Die Legende in der Leistungsansicht listet den Namen der Entität, des Leistungsindikators und der Leistungsauflistungsregel auf.

Wenn Sie z. B. die Problembehandlung für den Exchange Information Store-Nutzungsbericht aus dem Exchange 2003-Verwaltungspaket ausführen, wechseln Sie zur Überwachungsansicht , und öffnen Sie die Ansicht "IS-Leistungsdaten ". Der Pfad für diese Ansicht ist Microsoft Exchange Server/Exchange 2003/Components/IS Performance Data. In der Leistungsansicht zeigt die Legende die Ziel-, Leistungsindikator- und Sammlungsregel für die Leistungsdaten an. In der ANSICHT "IS-Leistungsdaten" ist das Ziel immer "Informationsspeicher", und der Pfad ist immer der Name eines Servers, auf dem der IS-Dienst ausgeführt wird. Wenn Sie das Kontrollkästchen für eine beliebige Zeile in der Legende aktivieren, werden die Leistungsdaten für diesen Zähler in diesem Informationsspeicher im Diagramm angezeigt. Wenn eine Linie im Diagramm angezeigt wird, werden die Daten erfasst.

In diesem Beispiel ist das Ziel immer der Informationsspeicher. Dies bedeutet, dass Sie Informationsspeicherentitäten nur auswählen müssen, wenn Sie den Bericht "Verwendung des Exchange-Informationsspeichers" ausführen. Jede andere Entität neben dem Informationsspeicher gibt keine Daten zurück. Wenn Sie daher ein Exchange 2003-Rollenobjekt auswählen, generieren Sie einen leeren Bericht. Wenn Sie eine Informationsspeicherentität als Berichtsziel auswählen möchten, wählen Sie "Objekt hinzufügen" aus, geben Sie den Informationsspeicher für die Suchzeichenfolge ein, und wählen Sie "Suchen" aus. Eine Liste aller Informationsspeicher wird angezeigt. Der Pfadwert in den Suchergebnissen gibt Ihnen den Servernamen, der den Informationsspeicher hosten soll.

Die gleichen Grundsätze gelten für die meisten anderen Berichte. Um probleme mit dem Exchange SMTP-Verwendungsbericht zu beheben, wechseln Sie zur Überwachung , und öffnen Sie die ANSICHT "SMTP-Leistungsdaten " unter Microsoft Exchange Server/Exchange 2003/SMTP. Sie sehen, dass das Ziel immer SMTP ist. Zur Problembehandlung des SQL Server-Datenbankbereichsberichts aus dem SQL Server 2005-Management Pack wechseln Sie zur Überwachung , und öffnen Sie die Leistungsansicht "Datenbankfreier Speicherplatz" unter SQL Server/Performance. Sie sehen, dass das Ziel immer der Datenbankname ist. Denken Sie daran, dass "Target " in der Legende die Suchzeichenfolge und das Ziel ist, das Sie beim Konfigurieren der Berichtsparameter verwenden müssen.

Die Leistungsauflistungsregel oder das Skript, das die Leistungsdaten generiert, ist für das Berichtsziel nicht aktiviert.

Auch hier verlassen Sie sich auf die Leistungsansicht in der Überwachung. Wenn die Leistungsdaten nicht gesammelt werden, sehen Sie eines von zwei Symptomen in der Leistungsansicht:

  • Die erwartete Entität wird in der Legende nicht aufgeführt.
  • Die Entität wird in der Legende aufgeführt, aber beim Aktivieren des Kontrollkästchens werden keine Daten angezeigt.

Wenn die erwartete Entität in der Legende der Leistungsansicht fehlt, bedeutet dies möglicherweise, dass die Entität nicht ermittelt wurde. Sie können beispielsweise über einen Informationsspeicher oder einen SQL Server 2005-Datenbank-Engine verfügen, der auf einem Agent ausgeführt wird, der nicht in der Liste angezeigt wird. Um dies zu überprüfen, öffnen Sie "Mein Arbeitsbereich", erstellen Sie eine neue Statusansicht, und konfigurieren Sie die Statusansicht, um Daten anzuzeigen, die sich auf diesen Entitätstyp beziehen. Wenn die erwartete Entität nicht in der Ansicht angezeigt wird, wurde sie nicht erkannt. Anschließend würden Sie dies als Ermittlungsproblem anstelle eines Berichtsproblems behandeln.

Wenn die erwartete Entität in der Legende der Leistungsansicht fehlt, kann dies auch bedeuten, dass die Leistungsauflistungsregel für diesen Leistungsindikator für dieses Ziel nicht aktiviert ist. Dies kann passieren, wenn die Regel deaktiviert ist. Einige Management Packs enthalten Standardmäßig deaktivierte Leistungssammlungsregeln und erfordern Außerkraftsetzungen, um sie zu aktivieren. Dies ist im Management Pack-Handbuch dokumentiert. Wenn Sie beispielsweise das Exchange 2003-Management Pack verwenden, müssen Sie Außerkraftsetzungen erstellen, um die Leistungsauflistungsregeln für die Nachrichtenverfolgung zu aktivieren. Wenn Sie dies nicht tun, werden keine Daten für die SMTP-Ausgabe - und SMTP-Nachrichten in Berichten gesammelt. Im Management Pack-Handbuch finden Sie Informationen dazu, welche Leistungssammlungsregeln aktiviert sind, sowie für alle manuellen Konfigurationsschritte, falls zutreffend.

Wenn Sie die Antwort im Management Pack-Handbuch nicht finden, suchen Sie die Leistungssammlungsregel in der Dokumenterstellung , und stellen Sie sicher, dass sie für die zielorientierte Entität aktiviert ist. Die einfachste Möglichkeit, die Regel zu finden, besteht darin, den Regelnamen in der Legende der Leistungsansicht zu identifizieren und dann das Suchtool in der Dokumenterstellung zu verwenden, um die Regel zu finden. So stellen Sie beispielsweise fest, dass Sie keine Daten konsistent für den Exchange-Datenträgerverwendungsbericht im Exchange 2003-Management Pack abrufen können. Sie wechseln zur Überwachung und öffnen die PhysischeDisk-Leistungsansicht unter Microsoft Exchange Server/Exchange 2003/Server Performance. Sie stellen fest, dass einige der Exchange-Server nicht in der Legende aufgeführt sind, aber andere sind dort. Die folgenden Regelnamen sind in der Legende aufgeführt:

  • Durchschnittliche Datenträgerwarteschlangenlänge (alle Datenträger)
  • Aktuelle Datenträgerwarteschlangenlänge (alle Datenträger)
  • Datenträgerlesevorgänge /sekunde (Alle Datenträger)
  • Datenträgerschreibvorgänge /Sekunde (Alle Datenträger)

Sie öffnen die Dokumenterstellung und verwenden den Befehl "Suchen ", um die Regel namens "Durchschnittliche Datenträgerwarteschlangenlänge (Alle Datenträger)" zu finden. Sie öffnen die Regeleigenschaften und stellen fest, dass diese Regel deaktiviert ist, und es gibt eine Außerkraftsetzung, um die Regel nur für eine ausgewählte Gruppe von Exchange-Servern zu aktivieren. Dies erklärt, warum einige Exchange-Server keine Daten für diesen Bericht generieren. Sie müssen die Regelkonfiguration an alle Exchange-Server anstelle der benutzerdefinierten Gruppe anpassen.

Es gibt ein funktionales Problem mit dem Integritätsdienst auf dem Agent.

In einigen Fällen wird die erwartete Entität möglicherweise in der Legende der Leistungsansicht aufgeführt, aber beim Aktivieren des Kontrollkästchens werden keine Daten angezeigt. Dies kann auf Leistungs- oder Funktionsprobleme für den Agent hinweisen. Die Integritätsdienst auf dem Agent kann z. B. nicht ausgeführt werden, oder der Agent kann keine Verbindung mit seinem Verwaltungsserver herstellen. Versuchen Sie, den Zeitraum für die Leistungsansicht zu erhöhen, um einige Tage zurückzugehen. Dies kann Ihnen helfen, zu ermitteln, wann die Leistungsdaten nicht mehr erfasst wurden. Überprüfen Sie außerdem das Operations Manager-Ereignisprotokoll für den entsprechenden Agent, und suchen Sie nach Integritätsdienst und Integritätsdienst Modulfehlern. Suchen Sie insbesondere nach Ereignissen, die auf fehlende Leistungsindikatoren hinweisen. Suchen Sie außerdem nach Integritätsdienst Skript 6026- oder 6024-Ereignissen. Diese Ereignisse werden protokolliert, wenn die Integritätsdienst Schwellenwerte für private Bytes überschreitet oder anzahl behandelt und neu gestartet wird. Wenn dieses Problem auftritt, gibt es möglicherweise Lücken in der Leistungsdatensammlung.

Verwaltungsserver können keine Daten in die OperationsManagerDW-Datenbank einfügen.

Wenn ein oder mehrere Verwaltungsserver nicht in die OperationsManagerDW Datenbank schreiben können, sind die Symptome unterschiedlich und unvorhersehbar. Möglicherweise verfügen Sie über Berichterstellungsdaten für Agents, die einen Verwaltungsserver verwenden, aber nicht für Agents, die eine andere verwenden. Die Berichterstattung kann in allen Fällen fleckig sein.

Der erste Schritt bei der Identifizierung dieser Probleme besteht darin, das Operations Manager-Ereignisprotokoll auf allen Verwaltungsservern zu überprüfen. HealthService 2115-Ereignisse sind ein häufiges Symptom für Datenbankzugriffsprobleme. Diese Ereignisse werden vom Integritätsdienst auf einem Verwaltungsserver protokolliert, wenn der Server Daten sammelt, die er nicht in die Datenbank einfügen kann. Dies kann mit Betriebsdaten und berichtsdaten erfolgen. Im Allgemeinen gibt die Workflow-ID, die in der Ereignisbeschreibung aufgeführt ist, an, welche Art von Daten gesammelt wurden. Ein Workflow mit DataWarehouse in der ID bezieht sich auf Berichtsdaten. Behandeln Sie diese Art von Problem als Datenbankkonnektivitäts- oder Datenbankleistungsproblem. Eine bekannte Ursache für diesen Fehler ist in der Ereignis-ID 2115 dokumentiert, und ein Verwaltungsserver generiert eine Warnung "Daten kann nicht in das Data Warehouse geschrieben werden" in System Center Operations Manager 2007.

Wenn 2115-Ereignisse nicht angezeigt werden, konfigurieren Sie einen Filter im Ereignisprotokoll, um Warnungs- und Fehlerereignisse aus der Quelle Integritätsdienst Module und Kategorie Data Warehouse anzuzeigen. Diese werden protokolliert, wenn ein Data Warehouse-Workflow auf einem Verwaltungsserver fehlschlägt. Die Beschreibung für diese Ereignisse enthält häufig den SQL Server-Fehler, der zurückgegeben wurde, und den Workflownamen. Der Workflowname stellt möglicherweise einen Kontext für die betroffene Aufgabe bereit. Der benannte Microsoft.SystemCenter.DataWarehouse.CollectPerformanceData Workflow sammelt Leistungsdaten für die Berichterstellung und fügt die Daten in die Datenbank ein.

Daten bleiben in den Stagingtabellen in der OperationsManagerDW-Datenbank hängen

Überprüfen Sie zuerst das Operations Manager-Ereignisprotokoll auf dem Verwaltungsserver für die Ereignis-ID 31552 mit dem folgenden Workflownamen, der in der Ereignisbeschreibung aufgeführt ist:

Microsoft.SystemCenter.DataWarehouse.StandardDataSetMaintenance

StandardDataSetMaintenance ist der Workflow (auch als Regel bezeichnet), mit dem Daten im Data Warehouse gepflegt, optimiert und aggregiert werden. Wenn dieser Workflow fehlschlägt, bleiben die Daten möglicherweise in den Stagingtabellen hängen. Diese Regel führt eine gespeicherte Prozedur in der OperationsManagerDW Datenbank namens StandardDatasetMaintenanceaus, die andere gespeicherte Prozeduren aufruft, um Staging, Aggregat, Optimierung und Pflege der Standarddatensätze zu verarbeiten. Alle Namen der gespeicherten Prozedur beginnen mit StandardDataset. Standardmäßig wird die Regel alle 60 Sekunden ausgeführt. Wenn 31553 oder andere Fehlerereignisse angezeigt werden, kann dies auf ein Problem mit dem im Ereignis aufgeführten Dataset hinweisen. Lesen Sie weiter, um weitere Informationen zu diesem Thema zu erfahren, und führen Sie schritte zur Problembehandlung durch.

Verwaltungsserver fügen rohe Berichtsdaten in die Stagingtabellen in der OperationsManagerDW Datenbank ein. Anschließend wird ein weiterer Satz von Workflows ausgeführt, um die Daten aus den Stagingtabellen in die stündlich und täglichen Tabellen zu verschieben. Dies sind die Tabellen, die für die Berichte verwendet werden. Wenn die Leistungsdaten in den Stagingtabellen hängen bleiben, können Berichte daher keine Daten zurückgeben. Führen Sie die folgende Abfrage für die OperationsManagerDW Datenbank aus, um nach Leistungsdaten zu suchen, die in der Stagingtabelle hängen bleiben:

Use OperationsManagerDW
Select
   DateTime
From
   Perf.PerformanceStage
Order By
   DateTime

Datensätze in dieser Tabelle, die mehr als einen Tag oder zwei zurückkommen, können darauf hinweisen, dass die Daten nicht wie erwartet in die täglichen und stündliche Tabellen verschoben werden. Bevor wir fortfahren, lassen Sie uns nun ein wenig über die Wartung in der Datenbank sprechen. Die Wartung wird in die sogenannten Datasets unterteilt. Wenn die Wartung ausgeführt wird, führen wir sie für jeden Datensatz in der Datenbank aus. Führen Sie die folgende Abfrage aus, um dies besser zu sehen:

Use OperationsManagerDW;
With AggregationInfo As
(
   Select
      AggregationType =
      Case
         When
            AggregationTypeId = 0
         Then
            'Raw'
         When
            AggregationTypeId = 20
         Then
            'Hourly'
         When
            AggregationTypeId = 30
         Then
            'Daily'
         Else
            NULL
      End
   ,AggregationTypeId, MIN(AggregationDateTime) As 'TimeUTC_NextToAggregate'
   ,SUM(Cast (DirtyInd As Int)) As 'Count_OutstandingAggregations', DatasetId
   From
      StandardDatasetAggregationHistory
   Where
      LastAggregationDurationSeconds Is Not NULL
   Group By
      DatasetId, AggregationTypeId
)
   Select
      SDS.SchemaName,
      AI.AggregationType,
      AI.TimeUTC_NextToAggregate,
      Count_OutstandingAggregations,
      SDA.MaxDataAgeDays,
      SDA.LastGroomingDateTime,
      SDS.DebugLevel,
      AI.DataSetId
   From
      StandardDataSet As SDS WITH(NOLOCK)
      Join
         AggregationInfo As AI WITH(NOLOCK)
         On SDS.DatasetId = AI.DatasetId
      Join
         dbo.StandardDatasetAggregation As SDA WITH(NOLOCK)
         On SDA.DatasetId = SDS.DatasetId
         And SDA.AggregationTypeID = AI.AggregationTypeID
   Order By
      SchemaName Desc

Dadurch werden alle Datentypen und Informationen darüber angezeigt. Hier sind einige Informationen zu den angezeigten Spalten:

  • SchemaName: Dies ist der Name des Datasets (z. B. perf, Zustand, einige andere benutzerdefinierte Datensätze usw.). Sie werden feststellen, dass Warnungen und Ereignisse hier nicht angezeigt werden, und das liegt daran, dass diese Datensätze keine aggregierten Tabellen haben.
  • AggregationType: Datensätze können in unterschiedlichen Granularitätsebenen aggregiert werden, und diese Abfrage zeigt die Ergebnisse für jeden Aggregationstyp an (z. B. stündlich, täglich).
  • TimeUTC_NextToAggregate: Dies ist der Zeitstempel im UTC-Format des nächsten Zeitintervalls, das aggregiert werden soll. Für den täglichen Aggregationstyp können Sie einfach den JJJJ-MM-TT-Wert betrachten und den Rest ignorieren.
  • Count_OutstandingAggregations: Dies ist die Anzahl der Aggregationen, die das Dataset zugrunde liegt. Wenn Werte zwischen 1 und 3 angezeigt werden, werden Sie effektiv aufgefangen. Wenn (wie im Fall mit dem obigen Zustand) größere Zahlen angezeigt werden, sind Sie zurückgefallen.
  • MaxDataAgeDays: Dies ist die Aufbewahrungsrichtlinie, die für die Aggregation des angegebenen Datasets festgelegt ist.
  • LastGroomingDateTime: Ziemlich gerade vorwärts.
  • DebugLevel: Sie können die Debugebenen für Datensätze aufstellen und so etwas wie die Ablaufverfolgung erhalten, um Probleme zu diagnostizieren. Die wichtigsten Punkte sind hier: Sie möchten dies nur für kurze Zeiträume aktivieren und wenn ein Wert höher als 0 für einen Datensatz angezeigt wird, wird es nicht untersucht, und legen Sie ihn dann auf 0 zurück.
  • DataSetId: Dies ist die GUID des Datasets, die später nützlich sein wird.

Mit den oben genannten Informationen können wir jetzt sehen, ob eines unserer Datensätze hinterhergeht. Noch einmal werden wir das Leistungsdatenset für unser Beispiel verwenden. Führen wir diese Abfrage aus:

Use OperationsManagerDW
Select
   AggregationDateTime,
   LastAggregationDurationSeconds
From
   StandardDatasetAggregationHistory AS AH
   Inner Join
      StandardDataSet As DS
      On AH.DatasetId = DS.DatasetId
Where
   DS.SchemaName = 'Perf'
Order By
   AggregationDateTime Desc

Wenn Datensätze mit dem aktuellen Datum nicht angezeigt werden, gibt dies an, dass die Aggregation nicht auftritt. Hohe Werte für LastAggregationDurationSeconds die Angabe, dass die Aggregation langsam ist. Diese Arten von Problemen deuten in der Regel auf SQL Server-Konfigurations- oder Leistungsprobleme hin. Eine Überprüfung der SQL Server-Fehlerprotokolle und eine SQL Server-Leistungsanalyse ist ein guter Ausgangspunkt.

Alternativ können Sie überprüfen, was als Einträge bezeichnet DirtyInd wird. DirtyInd Einträge deuten auf ein etwas anderes Problem hin, bei dem Daten aggregiert werden, aber es gibt mehr Daten als das Verfahren. Standardmäßig verschiebt die Leistungsaggregation nur 100.000 Zeilen gleichzeitig. Wenn also eine Flut von Leistungsdaten vorhanden war, kann dies zu leeren oder unvollständigen Berichten führen. Führen Sie diese Abfrage aus, um nach Dirtyind Einträgen zu suchen:

Declare @DataSet as uniqueidentifier
Set
   @DataSet =
   (
      Select
         DataSetId
      From
         StandardDataSet
      Where
         SchemaName = 'Perf'
   )
   Select
      *
   From
      StandardDataSetAggregationHistory
   Where
      DataSetId = @DataSet
      And DirtyInd = 1

Wenn mehr als 4 bis 5 Einträge aus der obigen Abfrage angezeigt werden, können Sie die Wartung manuell ausführen. Bevor Sie sie manuell ausführen oder die nächsten Schritte ausführen, müssen Sie unsere Standardwartungsregel deaktivieren. Um die Regel zu deaktivieren, wechseln Sie zur Konsole, öffnen Sie "Dokumenterstellung", wählen Sie "Regeln" aus. Ändern Sie den Bereich in "Standarddatensatz". Überschreiben Sie die Regel für das Perf-Dataset (oder den Datensatz, den Sie behandeln). Warten Sie nun auf den Verwaltungsserver, um ein 1210-Ereignis zu erhalten, das bestätigt, dass die neue Konfiguration angewendet wurde, und fahren Sie mit den nächsten Schritten fort.

Führen Sie diese Abfrage aus, um die Wartung manuell auszuführen:

Declare @DataSet uniqueidentifier
Set
   @DataSet =
   (
      Select
         DataSetId
      From
         StandardDataset
      Where
         SchemaName = 'Perf'
   )
   Exec StandardDataSetMaintenance @DataSet

Fahren Sie mit der obigen Ausführung fort, bis Nur 1-3 Einträge vorhanden sind (dies ist normal, ein Eintrag für jeden Aggregationstyp). Wenn viele Einträge (mehr als 100) angezeigt werden, können Sie folgendes ausführen:

Declare @i int
Set
   @i = 0
   Declare @DataSet uniqueidentifier
   Set
      @DataSet =
      (
         Select
            DataSetId
         From
            StandardDataset
         Where
            SchemaName = 'Perf'
      )
      While(@i <= 500)
      Begin
         Exec StandardDataSetMaintenance @DataSet
         Set
            @i = @i + 1 Waitfor Delay '00:00:05'
      End

Dadurch wird die Wartung in einer Schleife basierend auf dem wert ausgeführt, für While(@i<=500)den Sie festgelegt haben. Sie können diesen Wert auf einen beliebigen Wert festlegen, es wird jedoch nicht empfohlen, höher als 500 zu gehen. Sie können den Fortschritt der Schleife überprüfen, indem Sie die Dirtyind Abfrage erneut ausführen, wodurch weniger Zeilen zurückgegeben werden sollen, während die Schleife voranschreitet. Nachdem das Skript abgeschlossen ist, überprüfen Sie die Dirtyind Einträge erneut, und wenn es jetzt aktuell ist, testen Sie Ihre Berichte. Wenn noch zu viele Einträge vorhanden sind, fahren Sie mit der Ausführung des Skripts fort, bis die Aggregation auf dem neuesten Stand ist.