Logování chyb v ASP.NET aplikacích

Uživatelsky srozumitelná chybová hlášení popsaná v předchozím článku jsou sice krásná věc, ale pokud se vzniklou chybou nebude zabývat tvůrce aplikace, jsou stejně k ničemu. Tentokrát vám předvedu několik způsobů, jak o vzniklých chybách aplikace informovat programátora nebo jejího správce.

V prostředí .NET Frameworku máme široký výběr, kam uložit informaci o chybovém stavu. Každý způsob má svoje specifika a možnosti použití:

• zaslání informace emailem
• zapsání informace do textového souboru
• zapsání informace do databáze
• zapsání informace do event logu stroje, na němž aplikace běží

O tom ,jak funguje zpracování výjimek v prostředí .NET Frameworku jsme již psali v článku Chybová hlášení v ASP.NET pod kontrolou. Po přečtení předchozího článku mi jistě dáte za pravdu, že nejvhodnější místo pro „logování“ chybových stavů je Application_Error. Dříve, než se pustím do vlastního popisu logování chyb, pokusím se vám přiblížit, jaké informace se dají o vzniklé chybě zjistit.

Díky tomuto článku budete mít sadu funkcí, které snadno zapracujete do své aplikace.

Zasílání chyb emailem

Nebudu se zde zaobírat tím, jak poslat z prostření .NET Frameworku email, ale rovnou uvedu kód, který email odešle. Pokud náhodou nerozumíte tomu, jak odesílaní emailu funguje, dovolím si vás odkázat na článek Web-mail služba pomocí ASP.NET.

void SendErrrorByMail(Exception chyba)
{
   MailMessage zprava = new MailMessage();
   zprava.From = „ondrej.kopp@interval.cz“;
   zprava.To = „ondrej.kopp@interval.cz“;
   zprava.Subject = „Chyba v aplikaci“;
   zprava.Body = chyba.ToString();
   SmtpMail.SmtpServer = „localhost“;
   SmtpMail.Send(zprava);
}

Výhodou tohoto řešení je možnost nechat si informace posílat jednoduše na mobilní telefon. Nevýhodou ovšem zůstává zaplněný mailbox, takže pokud vám virové spamy nestačí, klidně si tento způsob použijte.

Logování chyb do textového souboru

Nejméně vhodný způsob, ale kdo chce kam, pomozme mu tam. Následující příklad berte spíše jen jako ukázku, jak problém logování neřešit. Tento způsob poskytuje velice omezené možnosti následného zpracování logu (třídění podle času či typu), nehledě k tomu, že výsledný soubor bude velice rozsáhlý.

void WriteErrorToFile(Exception chyba)
{
   string soubor = Server.MapPath(„logfile.log“);
   string datumcas = DateTime.Now.ToShortDateString() + “ “ + DateTime.Now.ToLongTimeString();
   string message = datumcas + „\n“ + chyba.ToString() + „\n\n\n“;
   StreamWriter writer = new StreamWriter(soubor, true);
   writer.WriteLine(message);
   writer.WriteLine();
   writer.Close();
}

Zápis chyb do event logu webového stroje

Vhodné řešení, pokud vaše aplikace běží na serveru, který si spravujete sami. Máte tak totiž jak chyby vlastního serveru ,tak chyby aplikací na něm provozovaných na jednom místě a kontrola event logu patří mezi základní činnosti každého administrátora serveru.

void WriteErrorToEventLog(Exception chyba)
{
  EventLog ev = new EventLog(„Web Aplikace“);
  ev.Source = chyba.Message;
    if (!EventLog.SourceExists(ev.Source))
      EventLog.CreateEventSource(ev.Source,“Web Aplikace“);
    ev.WriteEntry(chyba.ToString(),EventLogEntryType.Error);
  ev = null;
}

Pokud však použijete tento kód, zjistíte, že do EventLogu se nic nezapsalo. Je to proto, že účet, pod kterým ASP.NET aplikace běží, nemá povolen zápis do EventLog. Návod, jak zápis povolit, najdete ve znalostní bázi Microsoftu. Řešení se liší podle prostředí, ve kterém pracujete, proto nemá smysl ho sem přepisovat.

Logování chyb do databáze

Logování chyb do databáze je podle mě tím nejlepším, co lze použít na hostingu. Ovšem řešení je o něco pracnější, jelikož si k němu musíte udělat i rozhraní, pomocí kterého si budete informace z databáze zobrazovat. Tvorba tohoto rozhraní sice zabere hodně času, na druhou stranu ale může poskytnout řadu nadstandardních funkcí, například přístup pomocí mobilních zařízení. Vzhledem k rozsáhlosti materiálu jsem se rozhodl toto řešení popsat v samostatném článku.

Chyba „404“ – logovat či nelogovat?

Toť otázka. V případě logování těchto chyb se vystavujete nebezpečí, že se stanete obětí vtipálka, který se snaží přistupovat na neexistující stránky. V opačné případě si však říkáte o problém, protože se o chybějící stránce či pouhém překlepu v URL nedozvíte. Osobně si myslím, že odladěná aplikace by tyto chyby neměla obsahovat v žádném případě a proto preferuji možnost programové volby, zda tyto chyby chci či nikoli. Ostatně, stejně tu zůstává log soubor IIS, kde se tyto chyby velice snadno odhalí.

Konečný výčet

Ve výčtu možností, kam logovat chybové stavy, jsem opomenul zmínit XML soubor. Tento způsob je podobný práci s databází a velmi intuitivní, takže by vám neměl dělat problémy. Pro další použití doporučuji vytvořit třídu, která bude obsahovat zde popisované metody. Získáte tak poměrně snadno dobrý nástroj pro analýzu chování aplikace.

Starší komentáře ke článku

Pokud máte zájem o starší komentáře k tomuto článku, naleznete je zde.