Plus utile NLog configurations

Certains de ces tombent dans la catégorie générale NLog (ou l'enregistrement) des conseils plutôt que strictement configuration des suggestions.

Voici quelques journalisation des liens à partir d'ici, DONC (vous pourriez avoir vu une partie ou la totalité de ces déjà):

log4net vs Nlog

La journalisation des meilleures pratiques

Quel est le point de journalisation de façade?

Pourquoi ne enregistreurs de recommander à l'aide d'un enregistreur par classe?

Utiliser le même schéma de nommage de votre enregistreur basé sur la classe Logger logger = LogManager.GetCurrentClassLogger(). Cela vous donne un haut degré de granularité dans votre bûcherons et vous donne une grande flexibilité dans la configuration des enregistreurs (contrôle à l'échelle mondiale, par l'espace de noms, par nom de l'enregistreur, etc).

Utilisation non-classname à base de bûcherons, le cas échéant. Peut-être que vous avez une fonction pour laquelle vous voulez vraiment pour contrôler l'enregistrement séparément. Peut-être que vous avez quelques transversale de la journalisation des préoccupations (enregistrement des performances).

Si vous n'utilisez pas classname l'enregistrement, envisager la possibilité de nommer vos bûcherons dans une sorte de structure hiérarchique (peut-être par domaine fonctionnel), de sorte que vous pouvez maintenir une plus grande flexibilité dans votre configuration. Par exemple, vous pourriez avoir une "base de données" domaine fonctionnel, une "analyse" de la FA, et une "interface utilisateur" FA. Chacun de ces pourrait avoir des sous-domaines. Alors, vous pourriez vous demander bûcherons comme ceci:

Logger logger = LogManager.GetLogger("Database.Connect");
Logger logger = LogManager.GetLogger("Database.Query");
Logger logger = LogManager.GetLogger("Database.SQL");
Logger logger = LogManager.GetLogger("Analysis.Financial");
Logger logger = LogManager.GetLogger("Analysis.Personnel");
Logger logger = LogManager.GetLogger("Analysis.Inventory");

Et ainsi de suite. Avec hiérarchique des bûcherons, vous pouvez configurer la journalisation à l'échelle mondiale (le "*" à la racine ou enregistreur), par FA (Base de données, l'Analyse, l'INTERFACE utilisateur), ou par sous-zone (Base de données.Se connecter, etc).

Enregistreurs de nombreuses options de configuration sont:

<logger name="Name.Space.Class1" minlevel="Debug" writeTo="f1" /> 
<logger name="Name.Space.Class1" levels="Debug,Error" writeTo="f1" /> 
<logger name="Name.Space.*" writeTo="f3,f4" />
<logger name="Name.Space.*" minlevel="Debug" maxlevel="Error" final="true" /> 

Voir le NLog aider pour plus d'info sur exactement ce que chacune des options de moyens. Probablement les éléments les plus notables ici sont la capacité d'générique enregistreur de règles, le concept que plusieurs enregistreur de règles peut "exécuter" pour une seule déclaration logging, et qu'un enregistreur de règle peut être marquée comme "final" donc, les règles suivantes s'exécute pas pour une déclaration logging.

Utiliser le GlobalDiagnosticContext, MappedDiagnosticContext, et NestedDiagnosticContext pour ajouter un contexte supplémentaire à votre sortie.

Utiliser "variable" dans votre fichier de config pour simplifier. Par exemple, vous pouvez définir des variables pour vos mises en page, puis de référence de la variable dans la configuration cible plutôt que de spécifier la mise en page directement.

  <variable name="brief" value="${longdate} | ${level} | ${logger} | ${message}"/>
  <variable name="verbose" value="${longdate} | ${machinename} | ${processid} | ${processname} | ${level} | ${logger} | ${message}"/>
  <targets>
    <target name="file" xsi:type="File" layout="${verbose}" fileName="${basedir}/${shortdate}.log" />
    <target name="console" xsi:type="ColoredConsole" layout="${brief}" />
  </targets>

Ou, vous pouvez créer une "coutume" ensemble de propriétés à ajouter à une mise en page.

  <variable name="mycontext" value="${gdc:item=appname} , ${mdc:item=threadprop}"/>
  <variable name="fmt1withcontext" value="${longdate} | ${level} | ${logger} | [${mycontext}] |${message}"/>
  <variable name="fmt2withcontext" value="${shortdate} | ${level} | ${logger} | [${mycontext}] |${message}"/>

Ou, vous pouvez faire des choses comme créer "jour" ou "mois" convertisseurs de mise en page strictement via la configuration:

  <variable name="day" value="${date:format=dddd}"/>
  <variable name="month" value="${date:format=MMMM}"/>
  <variable name="fmt" value="${longdate} | ${level} | ${logger} | ${day} | ${month} | ${message}"/>
  <targets>
    <target name="console" xsi:type="ColoredConsole" layout="${fmt}" />
  </targets>

Vous pouvez également utiliser la mise en page rend à définir votre nom de fichier:

  <variable name="day" value="${date:format=dddd}"/>
  <targets>
    <target name="file" xsi:type="File" layout="${verbose}" fileName="${basedir}/${day}.log" />
  </targets>

Si vous roulez votre fichier de tous les jours, le fichier pourrait être nommée "lundi.journal", "mardi.journal", etc.

N'hésitez pas à écrire votre propre convertisseur de mise en page. Il est facile et vous permet d'ajouter vos propres informations de contexte pour le fichier journal à l'aide de la configuration. Par exemple, voici un convertisseur de mise en page (basé sur NLog 1.de x, et non 2.0) qui peuvent ajouter à la Trace.CorrelationManager.ActivityId pour le journal:

  [LayoutRenderer("ActivityId")]
  class ActivityIdLayoutRenderer : LayoutRenderer
  {
    int estimatedSize = Guid.Empty.ToString().Length;

    protected override void Append(StringBuilder builder, LogEventInfo logEvent)
    {
      builder.Append(Trace.CorrelationManager.ActivityId);
    }

    protected override int GetEstimatedBufferSize(LogEventInfo logEvent)
    {
      return estimatedSize;
    }
  }

Dire NLog où votre NLog (extensions de ce que l'assemblée) comme ceci:

  <extensions>
    <add assembly="MyNLogExtensions"/>
  </extensions>

Utiliser l'outil de convertisseur de mise en page comme ceci:

  <variable name="fmt" value="${longdate} | ${ActivityId} | ${message}"/>

Utiliser asynchrone objectifs:

<nlog>
  <targets async="true">
    <!-- all targets in this section will automatically be asynchronous -->
  </targets>
</nlog>

Et de la cible par défaut wrappers:

<nlog>  
  <targets>  
    <default-wrapper xsi:type="BufferingWrapper" bufferSize="100"/>  
    <target name="f1" xsi:type="File" fileName="f1.txt"/>  
    <target name="f2" xsi:type="File" fileName="f2.txt"/>  
  </targets>  
  <targets>  
    <default-wrapper xsi:type="AsyncWrapper">  
      <wrapper xsi:type="RetryingWrapper"/>  
    </default-wrapper>  
    <target name="n1" xsi:type="Network" address="tcp://localhost:4001"/>  
    <target name="n2" xsi:type="Network" address="tcp://localhost:4002"/>  
    <target name="n3" xsi:type="Network" address="tcp://localhost:4003"/>  
  </targets>  
</nlog>

le cas échéant. Voir la NLog docs pour plus d'informations sur ceux-ci.

Dire NLog à regarder et à recharger automatiquement la configuration en cas de changement:

<nlog autoReload="true" /> 

Il y a plusieurs options de configuration pour aider à la résolution des problèmes NLog

<nlog throwExceptions="true" />
<nlog internalLogFile="file.txt" />
<nlog internalLogLevel="Trace|Debug|Info|Warn|Error|Fatal" />
<nlog internalLogToConsole="false|true" />
<nlog internalLogToConsoleError="false|true" />

Voir NLog Aide pour plus d'informations.

NLog 2.0 ajoute LayoutRenderer des emballages qui permettent un traitement supplémentaire à effectuer sur la sortie d'un convertisseur de mise en page (telles que couper la les espaces, uppercasing, la mise en minuscules, etc).

N'hésitez pas à envelopper l'enregistreur si vous souhaitez isoler votre code à partir d'une unité de dépendance sur NLog, mais les envelopper correctement. Il existe des exemples de la façon d'envelopper dans la NLog dépôt github. Une autre raison pour envelopper peut-être que vous souhaitez ajouter automatiquement des informations de contexte spécifiques à chaque connecté message (en le plaçant dans un LogEventInfo.Contexte).

Il y a des avantages et des inconvénients à l'enchaînement (ou abstraction) NLog (ou de toute autre structure de journalisation d'ailleurs). Avec un peu d'effort, vous pouvez trouver beaucoup d'info ici AFIN de présenter les deux côtés.

Si vous envisagez d'emballage, pensez à utiliser Commun.La journalisation. Il fonctionne très bien et permet de changer facilement de journalisation si vous le désir de le faire. Aussi, si vous envisagez d'emballage, pensez à comment vous allez gérer le contexte des objets (GDC, MDC, NDC). Commun.La journalisation n'est pas actuellement en charge d'une couche d'abstraction pour eux, mais il est censé être dans la file d'attente de fonctionnalités à ajouter.

Apparemment, vous pouvez maintenant utiliser NLog avec Growl pour Windows.

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <extensions>
        <add assembly="NLog.Targets.GrowlNotify" />
    </extensions>

    <targets>
        <target name="growl" type="GrowlNotify" password="" host="" port="" />
    </targets>

    <rules>
        <logger name="*" minLevel="Trace" appendTo="growl"/>
    </rules>

</nlog>

La journalisation des niveaux différents selon qu'il existe ou non une erreur

Cet exemple vous permet d'obtenir plus d'informations quand il ya une erreur dans votre code. En gros, c'tampons de messages et sorties seulement ceux qui, à un certain niveau de log (par exemple, Avertir) sauf une certaine condition est remplie (par exemple, il y a eu une erreur, de sorte que le niveau de journalisation est >= Erreur), alors il sera de sortie plus d'informations (par exemple, tous les messages de journal des niveaux >= Trace). Parce que les messages sont mises en mémoire tampon, ce qui permet de recueillir des informations de trace de ce qui s'est passé avant une Erreur ou ErrorException a été connecté très utile!

J'ai adapté de celui de la un exemple dans le code source. J'ai été expulsé à la première parce que j'ai quitté le AspNetBufferingWrapper (car le mien n'est pas un ASP app) - il s'avère que le PostFilteringWrapper nécessite quelques tampon cible. Notez que le target-ref élément utilisé dans le ci-dessus lié exemple ne peut pas être utilisé dans NLog 1.0 (je suis en utilisant 1.0 de Rafraîchissement pour une .NET 4.0 app); il est nécessaire de mettre votre cible à l'intérieur de l'emballage du bloc. Notez également que la logique de la syntaxe (c'est à dire supérieur ou inférieur symboles, < et >) a l'utilisation des symboles, pas le XML s'échappe de ces symboles (c'est à dire > et <) ou d'autre NLog l'erreur.

app.config:

<?xml version="1.0"?>
<configuration>
<configSections>
<section name="nlog" type="NLog.Config.ConfigSectionHandler, NLog"/>
</configSections>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
throwExceptions="true" internalLogToConsole="true" internalLogLevel="Warn" internalLogFile="nlog.log">
<variable name="appTitle" value="My app"/>
<variable name="csvPath" value="${specialfolder:folder=Desktop:file=${appTitle} log.csv}"/>
<targets async="true">
<!--The following will keep the default number of log messages in a buffer and write out certain levels if there is an error and other levels if there is not. Messages that appeared before the error (in code) will be included, since they are buffered.-->
<wrapper-target xsi:type="BufferingWrapper" name="smartLog">
<wrapper-target xsi:type="PostFilteringWrapper">
<!--<target-ref name="fileAsCsv"/>-->
<target xsi:type="File" fileName="${csvPath}"
archiveAboveSize="4194304" concurrentWrites="false" maxArchiveFiles="1" archiveNumbering="Sequence"
>
<layout xsi:type="CsvLayout" delimiter="Tab" withHeader="false">
<column name="time" layout="${longdate}" />
<column name="level" layout="${level:upperCase=true}"/>
<column name="message" layout="${message}" />
<column name="callsite" layout="${callsite:includeSourcePath=true}" />
<column name="stacktrace" layout="${stacktrace:topFrames=10}" />
<column name="exception" layout="${exception:format=ToString}"/>
<!--<column name="logger" layout="${logger}"/>-->
</layout>
</target>
<!--during normal execution only log certain messages--> 
<defaultFilter>level >= LogLevel.Warn</defaultFilter>
<!--if there is at least one error, log everything from trace level--> 
<when exists="level >= LogLevel.Error" filter="level >= LogLevel.Trace" />
</wrapper-target>
</wrapper-target>
</targets>
<rules>
<logger name="*" minlevel="Trace" writeTo="smartLog"/>
</rules>
</nlog>
</configuration>

Connecter à Twitter

Basé sur ce post sur un log4net Twitter Appender, j'ai pensé que je voudrais m'essayer à l'écriture d'un NLog Twitter Cible (à l'aide de NLog 1.0 actualisation, pas 2.0). Hélas, jusqu'à présent, je n'ai pas été en mesure d'obtenir un Tweet à fait post avec succès. Je ne sais pas si c'est quelque chose qui cloche dans mon code, Twitter, notre société de connexion internet/pare-feu, ou quoi. Je vous poste le code ici au cas où quelqu'un est intéressé, en l'essayant. Notez qu'il existe trois différents "Post" méthodes. Le premier que j'ai essayé est PostMessageToTwitter. PostMessageToTwitter est essentiellement la même que PostLoggingEvent dans l'original post. Si j'utilise que je reçois un 401 exception. PostMessageBasic obtient la même exception. PostMessage s'exécute sans erreur, mais le message n'est toujours pas le faire à Twitter. PostMessage et PostMessageBasic sont fondées sur des exemples que j'ai trouvé ici sur DONC.

FYI - je viens de trouvé un commentaire de @Jason Diller, d'une réponse dans ce post qui dit que twitter va désactiver l'authentification de base "le mois prochain". C'était en Mai 2010 et il est maintenant en décembre 2010, donc je suppose que peut-être pourquoi cela ne fonctionne pas.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Net;
using System.Web;
using System.IO;
using NLog;
using NLog.Targets;
using NLog.Config;
namespace NLogExtensions
{
[Target("TwitterTarget")]
public class TwitterTarget : TargetWithLayout
{
private const string REQUEST_CONTENT_TYPE = "application/x-www-form-urlencoded";  
private const string REQUEST_METHOD = "POST";  
//The source attribute has been removed from the Twitter API,  
//unless you're using OAuth.  
//Even if you are using OAuth, there's still an approval process.  
//Not worth it; "API" will work for now!  
//private const string TWITTER_SOURCE_NAME = "Log4Net";  
private const string TWITTER_UPDATE_URL_FORMAT = "http://twitter.com/statuses/update.xml?status={0}";  
[RequiredParameter]
public string TwitterUserName { get; set; }
[RequiredParameter]
public string TwitterPassword { get; set; }
protected override void Write(LogEventInfo logEvent)
{
if (string.IsNullOrWhiteSpace(TwitterUserName) || string.IsNullOrWhiteSpace(TwitterPassword)) return;
string msg = this.CompiledLayout.GetFormattedMessage(logEvent);
if (string.IsNullOrWhiteSpace(msg)) return;
try
{
//PostMessageToTwitter(msg);
PostMessageBasic(msg);
}
catch (Exception ex)
{
//Should probably do something here ...
}
}
private void PostMessageBasic(string msg)
{
//Create a webclient with the twitter account credentials, which will be used to set the HTTP header for basic authentication 
WebClient client = new WebClient { Credentials = new NetworkCredential { UserName = TwitterUserName, Password = TwitterPassword } };
//Don't wait to receive a 100 Continue HTTP response from the server before sending out the message body 
ServicePointManager.Expect100Continue = false;
//Construct the message body 
byte[] messageBody = Encoding.ASCII.GetBytes("status=" + msg);
//Send the HTTP headers and message body (a.k.a. Post the data) 
client.UploadData(@"http://twitter.com/statuses/update.xml", messageBody);
}
private void PostMessage(string msg)
{
string user = Convert.ToBase64String(System.Text.Encoding.UTF8.GetBytes(TwitterUserName + ":" + TwitterPassword));
byte [] bytes = System.Text.Encoding.UTF8.GetBytes("status=" + msg.ToTweet());
HttpWebRequest request = (HttpWebRequest)WebRequest.Create("http://twitter.com/statuses/update.xml");
request.Method = "POST";
request.ServicePoint.Expect100Continue = false;
request.Headers.Add("Authorization", "Basic " + user);
request.ContentType = "application/x-www-form-urlencoded";
request.ContentLength = bytes.Length;
Stream reqStream = request.GetRequestStream();
reqStream.Write(bytes, 0, bytes.Length);
reqStream.Close();
}
private void PostMessageToTwitter(string msg)
{
var updateRequest = HttpWebRequest.Create(string.Format(TWITTER_UPDATE_URL_FORMAT,
HttpUtility.UrlEncode(msg.ToTweet()))) as HttpWebRequest;
updateRequest.ContentLength = 0;
updateRequest.ContentType = REQUEST_CONTENT_TYPE;
updateRequest.Credentials = new NetworkCredential(TwitterUserName, TwitterPassword);
updateRequest.Method = REQUEST_METHOD;
updateRequest.ServicePoint.Expect100Continue = false;
var updateResponse = updateRequest.GetResponse() as HttpWebResponse;
if (updateResponse.StatusCode != HttpStatusCode.OK && updateResponse.StatusCode != HttpStatusCode.Continue)
{
throw new Exception(string.Format("An error occurred while invoking the Twitter REST API [Response Code: {0}]", updateResponse.StatusCode));
}
}
}
public static class Extensions
{
public static string ToTweet(this string s)
{
if (string.IsNullOrEmpty(s) || s.Length < 140)
{
return s;
}
return s.Substring(0, 137) + "...";
}
}
}

Le configurer comme ceci:

Dire NLog l'assemblée contenant la cible:

<extensions>
<add assembly="NLogExtensions"/>
</extensions>

Configurer la cible:

<targets>
<target name="twitter" type="TwitterTarget" TwitterUserName="yourtwittername" TwitterPassword="yourtwitterpassword" layout="${longdate} ${logger} ${level} ${message}" />
</targets>

Si quelqu'un essaie cela et a du succès, post de retour avec vos conclusions.

Moyen plus facile Pour vous Connecter à chaque niveau de journal avec une mise en page différente Conditionnelle à l'aide de Mises en page

<variable name="VerboseLayout" value="${level:uppercase=true}: ${longdate} | ${logger}    : 
${when:when=level == LogLevel.Trace:inner=MONITOR_TRACE ${message}} 
${when:when=level == LogLevel.Debug:inner=MONITOR_DEBUG ${message}} 
${when:when=level == LogLevel.Info:inner=MONITOR_INFO ${message}} 
${when:when=level == LogLevel.Warn:inner=MONITOR_WARN ${message}} 
${when:when=level == LogLevel.Error:inner=MONITOR_ERROR ${message}} 
${when:when=level == LogLevel.Fatal:inner=MONITOR_CRITICAL ${message}} |     
${exception:format=tostring} | ${newline} ${newline}" />

Voir https://github.com/NLog/NLog/wiki/When-Filter pour la syntaxe