Das IaaS Usage Metering & Reporting für das Windows Azure Pack zu konfigurieren ist schon eine Kür für sich.
Hat man dieses dann erst einmal ans Laufen bekommen kann man sich darüber freuen. Allerdings wird man auch währenddessen immer wieder zum Troubleshooting gezwungen sein. Ich habe einmal die vier häufigsten Ursachen für ein nicht funktionierendes Usage Metering & Reporting im Zusammenhang mit den Komponenten SCOM, SPF und WAP zusammengetragen.
- SPF: Kein SSL Zertifikat ist der Website im IIS zugewiesen
- SPF: Doppeltes Port Binding für die Website im IIS
- SPF: Gestoppte SPF Website im IIS
- WAP: Gestoppter MgmtSvc-UsageCollector Application Pool
Wie leicht lassen sich diese Fehler in der Konfiguration identifizieren ohne dabei sich auf die Server zu verbinden oder sämtliche Logs zu analysiseren?
Die Antwort folgt jetzt und ist recht simpel. Man verbindet sich mit dem SQL Management Studio auf die WAP SQL Instanz und öffnet die Tabellen UsageDiagnostics.ProviderCollectionCycles sowie UsageDiagnostics.CollectionCycles der DB Microsoft.MgmtSvc.Usage. Die Tabelle UsageDiagnostics.CollectionCycles benötigen wir nur für den letzten Fall des gestoppten Application Pools, dazu aber später mehr.
Um festzustellen, ob überhaupt ein Fehler aufgetreten ist oder das Usage Metering & Reporting ordnungsgemäß funktioniert öffnet man als erstes die Tabelle UsageDiagnostics.ProviderCollectionCycles.
Bei einem funktionierendem Usage Metering & Reporting sollten die drei aufeinander folgenden Zeilen so aussehen.
| ResourceProviderHostName | DownloadStatus | Error |
| https://srv-5:30010/ | 1 | NULL |
| https://srv-5:30012/ | 1 | NULL |
| https://srv-2:8090/Usage/ | 1 | NULL |
Solange bei allen Dreien der DownloadStatus 1 und der Error NULL ist, funktioniert das Usage Metering & Reporting. Sollte der DownloadStatus dagegen 2 sein, so wird in der Spalte Error die detaillierte Fehlermeldung ausgegeben (siehe Screenshot). Diese kann mittels Copy & Paste zur besseren Lesbarkeit nach Notepad etc. übertragen werden.
SPF: Kein SSL Zertifikat oder das falsche SSL Zertifikat ist der Website im IIS zugewiesen
Sollte für die SPF Website kein SSL Zertifikat oder das falsche SSL Zertifikat ausgewählt sein, so wird man in der Spalte Error in der Tabelle UsageDiagnostics.ProviderCollectionCycles folgende Fehlermeldung sehen.
System.Net.Http.HttpRequestException: An error occurred while sending the request. —> System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
Das kein SSL Zertifikat oder gar das falsche SSL Zertifikat ausgewählt ist, kann im Zusammenhang mit der Installation des Update Rollup 2 für die SPF auftreten. Dieser Fehler steht im Zusammenhang mit dem nächsten Problem.
SPF: Doppeltes Port Binding für die Website im IIS
Das doppelte Port Binding tritt ebenfalls im Zusammenhang mit der Installation des Update Rollup 2 auf. Mein MVP Kollege Christopher Keyaert hat es in seinem Blogartikel beschrieben.
-> http://www.vnext.be/2014/04/25/service-provider-foundation-kb2932939-bindings-issue/
Diesen Fehler kann man natürlich auch mittels der Tabelle UsageDiagnostics.ProviderCollectionCycles identifizieren, da die SPF Website bei einem doppelten Port Binding nicht startet und im gestoppten Status verweilt.
SPF: Gestoppte SPF Website im IIS
Sollte aus irgendeinem Grund die SPF Website im gestoppen Zustand sein, so lässt sich dies ebenfalls sehr leicht anhand der folgenden Fehlermeldung identifizieren.
System.Net.Http.HttpRequestException: An error occurred while sending the request. —> System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 10.0.0.6:8090
Die Fehlermeldung kann aber auch im Zusammenhang mit einer falsch konfigurierten Firewall auftreten, denn dann ist der Zugriff ebenfalls nicht möglich.
WAP: Gestoppter MgmtSvc-UsageCollector Application Pool
Um den gestoppten Application Pool MgmtSvc-UsageCollector als Ursache zu identifizieren wird diesmal die Tabelle UsageDiagnostics.CollectionCycles herangezogen.
Der Zyklus für das Abrufen der Metering Daten erfolgt im Turnus von 9 Minuten. Sollte also in der Tabelle in der letzten Zeile in der Spalte NextCycleRun Datum und Zeit in der Vergangenheit liegen, so wird vermutlich der Application Pool im Status Stopped sein. Die Zeitangabe erfolgt hier im Format UTC! Das heißt, dass wir in Deutschland +1 oder +2 Stunden dazu addieren müssen, je nachdem ob gerade Winter- oder Sommerzeit ist.
Um den Application Pool MgmtSvc-UsageCollector zu starten wird in die IIS Manager Console gewechselt.
Sobald der Application Pool gestartet wurde, sollte in der Tabelle UsageDiagnostics.CollectionCycles ein neuer Eintrag erscheinen und je nachdem wie lange der Application Pool still stand die alten Einträge gelöscht werden.
