2017-01-20 1 views
1

Ich habe Schwierigkeiten, nicht erfasste Ausnahmen zu protokollieren, wenn meine ASP.NET MVC 5-Anwendung in einem Azure App Service-Steckplatz bereitgestellt wird. Wenn eine nicht abgefangene Ausnahme auftritt, gibt die App zu Recht eine 500 und den Standardfehler "Fehler bei der Verarbeitung Ihrer Anfrage" auf der Seite "Error.cshtml" zurück, aber protokolliert niemals eine Erwähnung der Ausnahme in einem meiner Protokolle.ASP.NET MVC 5-Anwendung in Azure protokolliert keine Ausnahmen

Aktuelle Setup:

  • Azure Einstellungen:
    • Anwendungsprotokollierung: On, beide Dateisystem und Speicher Blobs Protokollierung auf der Informationsebene
    • Detaillierte Fehlermeldungen: Auf
    • Trace fehlgeschlagen: An
  • Setup-
  • Anwendung:
    • NLog Verwendung sowohl eine Datei zu schreiben und Ziele Trace, die an anderer Stelle arbeitet gut und gefangen Ausnahmen
    • nicht explizit gesetzt <customErrors /> in meinem web.configs, aber sie zeigen wie aus der Ferne an Ort und, wie erwartet, und gewünschten
    • hinzugefügt, um eine Überschreibung Application_ErrorGlobal.asax (siehe unten)
    • Added ein benutzerdefinierte ExceptionLoggingFilter (siehe unten) und registrierte es in meinem FilterConfig.cs pipepline als erstes Element

Application_Error Überschreibung in Global.asax:

protected void Application_Error(Object sender, EventArgs e) 
{ 
    Trace.TraceError("Uncaught exception bubbled up. Details: {0}", e); 

    Logger log = LogManager.GetCurrentClassLogger(); 
    Exception ex = Server.GetLastError(); 

    log.Fatal(ex, "Uncaught exception bubbled up to MVC root."); 
} 

Kunden ExceptionLoggingFilter in GlobalFilters registriert:

private static readonly Logger Logger = LogManager.GetCurrentClassLogger(); 

public void OnException(ExceptionContext filterContext) 
{ 
    var ex = filterContext.Exception; 
    var request = filterContext.HttpContext.Request; 

    Logger.Fatal(ex, "Uncaught exception bubbled up to MVC root."); 
} 

FilterConfig.cs:

public static void RegisterGlobalFilters(GlobalFilterCollection filters) 
{ 
    filters.Add(new ExceptionLoggerFilter()); 
    filters.Add(new HandleErrorAttribute()); 
} 

NLog.config:

... 
<targets async="true"> 
    <target xsi:type="File" name="f" fileName="${basedir}/logs/${shortdate}.log" layout="${longdate} ${uppercase:${level}} ${message} ${exception:format=tostring}" /> 
    <target xsi:type="Trace" name="trace" layout="${logger} ${message} ${exception:format=tostring}" /> 
    <!-- another target for sending data to Slack here... --> 
</targets> 
... 
<rules> 
    <logger name="*" minlevel="Debug" writeTo="f" /> 
    <logger name="*" minlevel="Trace" writeTo="trace" /> 
</rules> 
... 

Was ich habe versucht:

Ich habe eine Aktion, die absichtlich eine abgefangene Ausnahme auslöst (var neverResult = Convert.ToInt32("a");), und wenn ich zu, dass navigieren Seite Ich bekomme die benutzerdefinierte Fehlerseite. Das Implementieren von <customErrors mode="Off" /> in der Produktion auf Azure macht das, was ich erwarte: Ich kenne die vollständige Fehlermeldung und den Stack-Trace beim Navigieren zu dieser Beispielaktion. ABER ich erhalte keine Protokollierung, nicht von NLog, Traces, Überwachung der Streaming-Protokolle. Nada.

Ich habe versucht, die zusätzlichen Handler und Filter für die Protokollierung Fehler wie oben erläutert, und immer noch nichts, obwohl ich durch Remote-Debugging wissen, dass der Code in diesen zusätzlichen Handler ausgeführt wird. Lokal wird alles gut eingeloggt.

Hilfe!

Ich bin ein bisschen ein Verlust hier, auch wo ich als nächstes aussehen soll. Ich bin mir nicht sicher, ob ich Azure-Einstellungen betrachten muss, wie ASP.NET mit Dingen umgeht oder ob NLog deaktiviert ist (obwohl es alles andere gut protokolliert). Jede Richtung wird sehr geschätzt.

Update: Hinzugefügt tatsächlichen Filter Config und NLog Config.

+1

Können Sie Ihre FilterConfig zeigen? Weil die Exception-Filter zuletzt zum ersten laufen .. :) – juunas

+2

Und wie sieht die NLog-Konfiguration aus? – Julian

+0

Sicher, danke, dass du beide gefragt hast. Habe @junas nicht erkannt, dass Filter zuletzt zum ersten laufen, das überprüfe ich mal. – Joshua

Antwort

2

Ich habe dies tatsächlich mit Ihrer Konfiguration versucht und das Problem gefunden.

Wenn Sie Logger.Fatal verwenden, wird die Trace-Nachricht aus bestimmten Gründen in Verbose-Ebene geschrieben. Ändern Sie Ihre Logging-Filter, um die Fehler-Funktion:

Logger.Error(ex, "Uncaught exception bubbled up to MVC root."); 

Und auch Ausnahmefilter laufen in letzter to-first, so in Ihrem Fall HandleErrorAttribute zuerst ausgeführt wird. Es bedeutet jedoch nicht, dass Ihr Filter nicht ausgeführt wird (ASP.NET Core ist in dieser Hinsicht ein bisschen anders).

Die Fatal-Funktion von NLog ruft die Fail function der Trace-Klasse auf, die verwendet werden soll, um dem Benutzer in Windows-Umgebungen ein Meldungsfeld anzuzeigen. Aus irgendeinem Grund ist das auf Verbose-Ebene auf IIS.

TL; DR Verwenden Sie nicht Fatal(), verwenden Sie Error().

+0

Super, danke @juunas, das hat funktioniert! Das ist bizarr über Fatal -> Verbose auf IIS, klingt wie ein Bug. Danke für die Ankündigung der Ausnahmefilter, das war eine weitere Überraschung. – Joshua

Verwandte Themen