Arbeitendes Azure-Logging-Setup

Question

Ich versuche schon seit geraumer Zeit, Trace-Logging einzurichten und es gelingt mir einfach nicht, es richtig zum Laufen zu bringen. Es hilft nicht, dass es so viele falsche/veraltete Artikel zu diesem Thema gibt. Aber bitte kann mir jemand eine gute und praktische Einrichtung für Trace-Logging & Anzeige für Azure (1.6) geben?

Alles, was ich tun möchte, ist die Möglichkeit, Trace-Nachrichten von meiner App aufzuzeichnen und anzuzeigen.

Ich habe angefangen mit dem standardmäßigen DiagnosticMonitorTraceListener, aber das landet in der Tabellenspeicherung. Ich kann einfach nicht herausfinden, wie ich mit den Logs in der Tabellenspeicherung interagieren soll. In Visual Studio kann ich sie 'anzeigen', aber es ist so unglaublich umständlich, sie zu verwenden, dass sie praktisch nutzlos ist. Keine Sortierung, ich muss umständliche Datumsfilter schreiben, die die Hälfte der Zeit nicht funktionieren.

Benutzerdefinierte Logs scheinen der richtige Weg zu sein. Ich habe viel mit log4net gearbeitet, also habe ich das ausgewählt. Du kannst log4net auf Trace umleiten, aber dann landest du wieder bei der gleichen grottenschlechten Tabellenspeicherung. Eigene Logdatei ist die Lösung. Jetzt bin ich schon verwirrt, ob das unterstützt wird oder nicht. Einige Artikel erwähnen diagnostische Dateisperren, die alle möglichen Probleme verursachen. Ich bin mir nicht sicher, ob das immer noch ein Problem ist, aber es ist merkwürdig, warum die Fähigkeit zur Übertragung von benutzerdefinierten Logs geben, wenn man die Logs nicht lesen/schreiben kann?! Wie auch immer, ich hatte keine Probleme beim Schreiben ins Log (die ich bemerkt habe).

Die Einrichtung erfolgt gemäß den MSDN-Artikeln (übrigens sehr vage und weit verstreut). Definiere das LocalStorage-Element in der ServiceDefinition (128Mb). Füge beim Start der Rolle das Verzeichnis für die Log-Übertragung hinzu. Los geht's. Das scheint zu funktionieren. Bis nach einer Weile die Rolle bei einem Neustart mit der Meldung "OverallQuota ist nicht ausreichend groß" abstürzt und die Rolle einfach abstirbt und sich weigert, wieder hochzufahren. Auch innerhalb von 4080Mb ist sooo viel Platz verfügbar, das ergibt einfach keinen Sinn.

Habe wiederum Artikel befolgt, um die Quote zu erhöhen, aber das schien die Dinge nur noch schlimmer zu machen. Setze die Größe des DiagnosticStore auf 8Gb in der ServiceDefinition. Funktioniert nicht. Stürzt immer noch ab, nur mit der höheren Zahl. Auch das Setzen des OverallQuota auf 8Gb hilft nicht. Aus irgendeinem Grund funktioniert eine Neuinstallation auf einem sauberen Image einwandfrei, aber bei einem Neustart oder einem Update entscheidet es sich, die Quoten anders zu berechnen. Unabhängig von der Größe des DiagnosticsStore ist der 'berechnete' Wert immer OverallQuota + Log4Net LocalStorage. Nichts, was ich tue, scheint das zu ändern. Extrem frustrierend, weil es zu funktionieren scheint, nur um später irgendwann zu sterben.

Habe auch diagnostics.wadcfg ausprobiert, aber konnte Azure nicht dazu bringen, sie zu erkennen. Ich habe darauf geachtet, dass sie in den Root-Output-Ordner kopiert wurden und alle Änderungen am Monitor aus meinem Code entfernt wurden. Nichts, absolut nichts... ich habe alle Logdateien durchsucht, die ich auf der Instanz finden konnte. Nirgendwo wurde auch nur eine Erwähnung oder ein Fehler gefunden.

Warum ist das auf Azure so schwierig? Trace-Logs sind das grundlegendste Logging-Tool für jede Anwendung. Das ruiniert wirklich die Azure-Erfahrung.

Answer 1

Wir verwenden auch Log4Net auf Azure

Kleiner Warnhinweis: Wenn mehrere Rollen pro Instanz ausgeführt werden, konnte ich bisher nur eine Rolle [Hauptrolle] tatsächlich erfolgreich Logs schreiben lassen... [nicht gut!!!]

Wie man es einrichtet... Ganz einfach.

In Global.asax wie gewohnt log4net konfigurieren

protected void Application_Start()
{
    log4net.Config.XmlConfigurator.Configure();
}

In Ihrem Rolleneinstiegspunkt... führen Sie ebenfalls die Konfiguration aus. Keine Ahnung warum, aber wenn Sie es nicht an beiden Stellen tun, funktioniert es nicht (zumindest bei mir nicht)

public override void Run()
{
    log4net.Config.XmlConfigurator.Configure();
}

Dann in Ihren Konfigurationsdateien

Vergewissern Sie sich, dass das Azure-Tracing aktiviert ist

Wir haben uns entschieden, Storage Studio nicht zu verwenden, weil für alle Daten, die aus Azure kommen, bezahlt wird... Datenübertragungen innerhalb von Azure sind kostenlos, die Anbindung an die Tabellenspeicherung ist einfach, also haben wir einen Bildschirm gebaut, um Logs anzuzeigen, hat 2/3 Stunden gedauert, funktioniert wie eine Bombe

Answer 2

Wir verwenden log4net recht erfolgreich mit Azure, wobei wir Daten in Azure Table Storage ablegen. Es ist definitiv eine skalierbarere Lösung. Ich empfehle Ihnen dringend, eine Lizenz für Cerebrata's (jetzt RedGates) Storage Studio zu erwerben, um den Umgang mit Azure Table Storage zu erleichtern, und deren Diagnostics Manager zu erleichtern, um sich das Ansehen von Trace-Protokollen zu erleichtern.

Answer 3

Für Szenarien, in denen große Mengen an Protokolldaten vorhanden sind, haben wir versucht, die Daten in Blobs zu leiten - teilweise unter Verwendung des EtwTraceListener, sowie wichtige Informationen, auf die wir reagieren müssen, an Table Storage zu senden. Wir verwenden sowohl den AzureStorageTraceListener als auch haben einen benutzerdefinierten TraceListener erstellt, der die Daten in unsere eigene Azure-Tabelle leitet - weil das Standard-Schema nicht unseren Anforderungen entsprach. Da WADLogsTable schnell wachsen kann und wir eine Möglichkeit benötigen, sie zu kürzen, ohne hohe Speichertransaktionskosten zu verursachen oder das Tracing offline zu nehmen, während wir die Tabelle löschen/neu erstellen, verwenden wir unsere benutzerdefinierte Tabelle, die für jeden Monat eine andere Tabelle erstellt.

Ranjith
http://www/opstera.com

Answer 4

Ich verwende benutzerdefiniertes Logging, um Protokolldaten in die Azure-Tabellenspeicherung für alle meine Websites zu schreiben. Wie Sie jedoch zu Recht feststellen, ist das Abrufen der Daten aus den Tabellen der schwierige Teil. Daher betreibe ich auch eine lokale interne Website, die nur von uns genutzt wird und die Daten aus den Azure-Tabellen abruft und in eine lokale Datenbank speichert. Obwohl Sie für die Übertragung von Daten aus dem Azure-System zahlen müssen, sind die Kosten minimal. Unsere Logging-Lösung für alle unsere Websites kostet uns weniger als £1 pro Monat.

Wenn die Daten in eine lokale Datenbank verschoben werden, sind sie unendlich abfragbarer als wenn sie im Azure-System bleiben würden. Ich führe eine Diskussion über Azure-Logging, die viele der oben genannten Probleme anspricht und auch Links zu Codebeispielen bereitstellt.