I am trying to figure out why NLog logs my error twice.
here is my config file:
<nlog xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<targets>
<target name="debug" xsi:type="File" FileName="DebugTestFile.log" layout="${message} ${exception:format=tostring}" />
</targets>
<rules>
<logger name="*" level="Debug" writeTo="debug" />
</rules>
</nlog>
Now when I call NLog.Debug(myException); the output is my exception gets printed twice.
If I call NLog.Debug(myException, "My Test Message String"); then the error gets printed out once along with my test message.
What exactly am I doing wrong? According to https://github.com/NLog/NLog/wiki/How-to-Log-Exceptions my configuration is correct.
I tried changing my layout to the following: layout="${message} and when I ran NLog.Debug(myException); it only printed the error once.
However now when I ran NLog.Debug(myException, "My Test Message String"); it only printed my message without the error that comes from exception.
Could this be a bug with NLog?
Updated Answer
NLog.Web.AspNetCore v4.8.6 changes registration of NLog Logging Provider, so one is now allowed to call both AddNLog and UseNLog without experiencing double logging.
NLog 5.0 implements validation of incorrect duplicate target configuration, so one will not experience double logging when using incorrect NLog configuration.
Original Answer
If you are using NLog in AspNetCore, then the problem can be caused by calling UseNLog together with AddNLog or ConfigureNLog.
You should only use UseNLog together with NLog.Web.LogBuilder.ConfigureNLog (Stop using AddNLog):
https://github.com/NLog/NLog/wiki/Getting-started-with-ASP.NET-Core-2#4-update-programcs
This is seems to be because of rule in config file, just change writeTo for each logger, in my case I was able to reolve this issue by following same steps:
Example:
Earlier config file which was having issue:
<rules>
<logger name="*" minlevel="Info" writeTo="console" />
<logger name="*" minlevel="Error" writeTo="console" />
</rules>
Corrected config file:
<rules>
<logger name="*" minlevel="Info" writeTo="console" />
<logger name="*" minlevel="Error" writeTo="console1" />
</rules>
Related
I would like to setup filters in my nlog.config in such a way that a log entry should go to one file (defined by the file target domainTarget) if a message contains a substring and to another file (defined by the file target technicalTarget) if it does not.
Put in another way: Whatever is included in domainTarget (no matter how complex its rules are) should never show up in technicalTarget.
This is what I tried:
<rules>
<logger name="*" minlevel="Trace" writeTo="domainTarget">
<filters>
<when condition="contains('${message}', 'mysubstring')" action="LogFinal"/>
</filters>
</logger>
<logger name="*" minlevel="Trace" writeTo="technicalTarget"/>
</rules>
With these settings it logs everything to domainTarget. And also logs everything to technicalTarget except messages with the substring.
Can someone
Explain the algorithm how those filters are applied.
Show me the right filter settings to achieve my above goal.
Have you tried to use defaultAction introduced with NLog 4.6?
<logger name="*" minlevel="Trace" writeTo="domainTarget">
<filters defaultAction="Ignore">
<when condition="contains('${message}', 'mysubstring')" action="LogFinal" />
</filters>
</logger>
<logger name="*" minlevel="Trace" writeTo="technicalTarget"/>
I'm confused by NLog logging level fallbacks. I have this set of rules:
<rules>
<!-- Send Microsoft into a black hole to hide their logs -->
<logger name="Microsoft.*" maxLevel="Warn" final="true" />
<logger name="commands" minlevel="Info" writeTo="logger" final="true" />
<logger name="*" minlevel="Trace" writeTo="logger" />
<logger name="exception" minlevel="Error" writeTo="publisher" final="true" />
</rules>
What I expect to happen is that anything with a logger name of "commands" will only be logged at Info level or above. Any other logger name will be logged regardless.
What's happening is that when I get the logger for "commands" and I check its properties every log level is enabled, so if I provide a log level of Debug, then it's still logged. From what I understand, this shouldn't be the case.
I think this is something to do with my fallback logger (the name="*") I believe the "final=true" on the "commmand" logger should any further logging checks.
This is running in .net core
Am I misunderstanding how this works?
Maybe this will work:
<rules>
<!-- Send Microsoft into a black hole to hide their logs -->
<logger name="Microsoft.*" maxLevel="Warn" final="true" />
<logger name="commands" maxLevel="Debug" final="true" />
<logger name="commands" minlevel="Info" writeTo="logger" final="true" />
<logger name="*" minlevel="Trace" writeTo="logger" />
<logger name="exception" minlevel="Error" writeTo="publisher" final="true" />
</rules>
I have a scenario where I want to log in a file only if the database fails for some reason.
Is it possible to achieve that using NLog ?
Yes, you could use the FallbackGroup target for that. In the fallback group you should configure the database and file target.
e.g.
<target xsi:type="FallbackGroup" name="all" returnToFirstOnSuccess="true">
<target name="target1" xsi:type="Database" ... />
<target name="target2" xsi:type="File" ... />
</target>
<rules>
<logger name="*" minlevel="Trace" writeTo="all" />
</rules>
See https://github.com/NLog/NLog/wiki/FallbackGroup-target
My application is using NLog configured with NLog.config shown below. It also uses RavenDB database which by default uses active NLog settings for logging.
It produces a lot of DEBUG and INFO messages that pollute the log. I do want to log ERROR and WARN messages. All of the records created by RavenDB come from namespaces that start with Raven.
I created the rules as shown below. Basically there is a final rule that prevents INFO/DEBUG messages that come from Raven.* namespace to get written into the log file. Everything was working well until I upgraded the NuGet packages to NLog 4.0. Now all the RavenDB messages are written into the log file.
Is this a bug or there is some configuration change happened across the NLog versions?
<?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">
<targets>
<target name="file" xsi:type="AsyncWrapper" queueLimit="1000" overflowAction="Discard">
<target
name="file"
xsi:type="File"
layout="${longdate} - ${level:upperCase=true} - ${identity} - ${logger} - ${message}${onexception:inner=${newline}${exception:format=tostring}${newline}}"
fileName="D:/Logs/AppName/${shortdate}.log" />
</target>
</targets>
<rules>
<logger name="Raven.*" writeTo="file" minlevel="Warn" final="true" />
<logger name="*" writeTo="file" minlevel="Debug" />
</rules>
</nlog>
Apparently there was a logic change in NLog 4. It does not mark messages from Raven namespace with level below the Warn final any longer.
http://nlog-project.org/2015/06/09/nlog-4-has-been-released.html
So the rule would have to change to send messages in the Raven.* namespace with maxlevel="INFO" into a null target.
I am not very familiar with NLOG, so I am hoping someone can point me in the right direction to solving this problem. I don't want NLOG to create a debug.txt file. I thought simple updating the minlevel to "Info", would solve it, but it does not.
Here are the settings in my app.config file that point NLOG:
<section name="nlog" type="NLog.Config.ConfigSectionHandler, NLog" />
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" autoReload="true">
<variable name="applicationName" value="TheNameOfMyApplication" />
<include file="\\<PathToNlogConfig>\NLog.config" />
</nlog>
And in my NLog.config file in the rules section:
<logger name="Name.Space.Apps.*" minlevel="Info" writeTo="consoleapps" final="true" />
<logger name="*" minlevel="Info" writeTo="fileOut" />
What else do I need to configure to stop this debug.txt file from being created?
Thanks
Solved it. Turns out we were using a library to log to NLOG, and NLOG was grabbing the namespace from that library, and hence hitting a different rule.