I would like to know if it is possible to write the logs to another target if the message that we want to write begins with certain words, a prefix.
I can't do it at the class level right now, that's why I'm checking if it's possible to get what I want in an easier way than modifying the code
Yes, this is possible.
It could be configured like this:
<logger name="*" writeTo="target-only-if-message-has-prefix">
<filters defaultAction='Ignore'>
<when condition="starts-with('${message}', 'MyPrefix')" action="Log" />
</filters>
</logger>
See
https://github.com/NLog/NLog/wiki/Filtering-log-messages
https://github.com/NLog/NLog/wiki/When-filter
I have an issue where I need to write logs to an Azure table using Nlog, but the connection string could change depending on the environment (i.e. Dev/UAT etc.), so I need to take this from another config file. My Nlog 'targets' section currently looks like the following:
<targets>
<target xsi:type="File" name="allfile" fileName="${var:configDir}\nlog-all.log"
layout="${longdate}|${event-properties:item=EventId.Id}|${logger}|${uppercase:${level}}|${message} ${exception}" />
<target xsi:type="AzureTableStorage"
connectionString="${var:myNLogConnectionString}"
name="NLogAzureTable"
layout="${longdate}|${event-properties:item=EventId.Id}|${logger}|${uppercase:${level}}|${message} ${exception}"
tableName="MyTestLogs"
logTimeStampFormat="O" />
</targets>
My Api looks as follows:
ILoggerFactory logger = new LoggerFactory().AddNLog();
var nlogConfigSection = config.Settings.Sections["MyService_NlogSettings"];
LogManager.LoadConfiguration("nlog.config");
LogManager.Configuration = new XmlLoggingConfiguration("nlog.config");
LogManager.Configuration.Variables["configDir"] = nlogConfigSection.Parameters["FileLocation"].Value;
LogManager.Configuration.Variables["myNLogConnectionString"] = nlogConfigSection.Parameters["environmentNLogConnectionString"].Value;
I can see from debugging that the config.settings values are all being retrieved as required, and even that the variables in the configuration are all being populated appropriately. I've found that if I write locally to the 'allfile' text file, it's managing to retrieve and populate 'configDir', since that's where the text file appears!
However, if I switch to using Azure, I can see as previously mentioned that the variable is being set in the Configuration, but when I look at the Nlog Internal Log file, I can see that it thinks that the connection string is blank.
Is there anything obvious that I'm doing wrong here?!? I've seen solutions for similar problems, but they invariably seem to involve doing what I've already done, but I'm getting no joy!
Try doing this instead:
ILoggerFactory logger = new LoggerFactory().AddNLog();
var nlogConfigSection = config.Settings.Sections["MyService_NlogSettings"];
// Configure global settings before loading NLog.config
NLog.GlobalDiagnosticsContext.Set("configDir", nlogConfigSection.Parameters["FileLocation"].Value);
NLog.GlobalDiagnosticsContext.Set("myNLogConnectionString", nlogConfigSection.Parameters["environmentNLogConnectionString"].Value);
NLog.LogManager.Configuration = new XmlLoggingConfiguration("nlog.config");
With the following NLog.config, replacing ${var with ${gdc:
<targets>
<target xsi:type="File" name="allfile" fileName="${var:configDir}\nlog-all.log"
layout="${longdate}|${event-properties:item=EventId.Id}|${logger}|${uppercase:${level}}|${message} ${exception}" />
<target xsi:type="AzureTableStorage"
connectionString="${gdc:myNLogConnectionString}"
name="NLogAzureTable"
layout="${longdate}|${event-properties:item=EventId.Id}|${logger}|${uppercase:${level}}|${message} ${exception}"
tableName="MyTestLogs"
logTimeStampFormat="O" />
</targets>
I use nlog logger in my project.
My program generates xml files based on data which i getting from sql server. I'm doing this with PLINQ. But also i have to log tracing info to be able make some investigations on exceptional cases on prod environment.
Result logs looks awful, when it came from multiple threads. For example:
Operation 1 started
Deserializing XXX
Operation 2 started
Deserializing XXX finished with status X
Filling XXX with data from Z
Deserializing YYY....
And its just for degree of parallelism 2.
I'd like to see result like this:
Operation 1 started
Deserializing XXX
Deserializing XXX finished with status X
Filling XXX with data from Z
Operation 1 finished
Operation 2 started
Deserializing YYY....
I see some solutions, but they're not looking good enough:
Save logging data to some buffer and flush it when parallel task ends - I will be ought to pass context to all inner methods (looks terrible!).
Add some kind of prefix to logging message to help getting context for some messages - i have to pass prefix to every inner message (also looks terrible).
Is there some clean solutions for this problem?
In NLog config files, there is the ${threadid} syntax. Use it like this:
<target name="file" xsi:type="File"
layout="${longdate} [${threadid}] ${level:uppercase=true} ${message} ${exception:format=tostring}"
fileName="${basedir}/logs/log.txt"
archiveFileName="${basedir}/logs/log.{#####}.txt"
archiveAboveSize="10485760"
archiveNumbering="Sequence"
concurrentWrites="true"
keepFileOpen="false" />
More info:
https://github.com/NLog/NLog/wiki/ThreadId-Layout-Renderer
I used it in production and generally it works. It is not perfect, but all operations (which I logged) is in sequence and this threadid describe which operation is in which ThreadId.
I'm reworking an existing logging system to use NLog Instead. I've manually added a reference to NLog in my configuration file:
<targets>
<target xsi:type="File" name="fileLogger" fileName="${basedir}\TRACE\${date:format=yyyy-MM-dd}.log" layout="TimeStamp:[${date}]|${message}" />
<target xsi:type="Memory" name="MemLogger" layout="TimeStamp:[${date}]|${message}|${Type}" />
</targets>
<rules>
<logger name="ApplicationLogger" levels="Info,Warn,Error" writeTo="fileLogger" />
<logger name="ApplicationLogger" levels="Info,Warn,Error" writeTo="fileLogger" />
</rules>
What I want to do is in code pull out the MemLogger Logs and access the different parts (Type, Message, Timestamp). How would I accomplish this? I've seen how to create a new log from scratch, but I don't want to create a new memorytarget, I want to access the existing one in my config, pull the log data out of it, and then clear the memory (so that I don't have a memory leak).
How to I access the MemLogger MemoryTarget in C#?
Unfortunately you cannot access different parts of log. Logs stored as rendered strings, with all layout renderers already replaced with their values. All you can do is manually parse each log string. E.g.
var target =(MemoryTarget)LogManager.Configuration.FindTargetByName("MemLogger");
foreach (string log in target.Logs)
{
var parts = log.Split('|');
var date = parts[0].Replace("TimeStamp:[", "").TrimEnd(']');
var message = parts[1];
var type = parts[2];
//...
}
Something like this:
var target = LogManager.Configuration.FindTargetByName("MemLogger");
Optionally, you can cast received target to MemoryTarget type.
I've just had to do this myself:
Natively:
IList<string> logs = LogManager.Configuration.FindTargetByName<MemoryTarget>("MyTarget").Logs;
or using a Cast:
IList<string> logs = ((MemoryTarget)LogManager.Configuration.FindTargetByName("MyTarget")).Logs;
I'm developing a complicated distributed service that makes iterative synchronization process. It synchronise every 10 seconds business entities in different information systems. One iteration is consist of bunch of 3d party service calls to retrieve current state of business objects (count of customers, goods, certain customer and goods details etc.), queries to local DB and then get differences between them and smooth out, synchronize this differences.
There are different types of iterations. They are fast (only changes in set of objects) and slow iterations (full revieweing of data). Fast are every 10 seconds and slow are once a day.
So, how can I log this processes using NLog? I'm using SQLite for storing data. But I'm stuck in DB design for logs.
So I want to log flow of every iteration:
1. Request for current state of objects to 3d party service
2. Query the local database for current state of objects
3. Get differences list
4. Invoke external service to commit insufficient data
5. Update local database for insufficient data
But there is so many kinds of info to log so I can't just put it into one TEXT field.
At the moment I'm using such structure for logs:
CREATE TABLE [Log] (
[id] INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
[ts] TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
[iteration_id] varchar,
[request_response_pair] varchar,
[type] VARCHAR NOT NULL,
[level] TEXT NOT NULL,
[server_id] VARCHAR,
[server_alias] VARCHAR,
[description] TEXT,
[error] Text);
So every service request and response puts to description and request_response_pair is a key to link every response to every request.
Here is my NLog config:
<?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" internalLogFile="D:\nlog.txt" internalLogLevel="Trace">
<targets>
<target name="Database" xsi:type="Database" keepConnection="false"
useTransactions="false"
dbProvider="System.Data.SQLite.SQLiteConnection, System.Data.SQLite, Version=1.0.82.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139"
connectionString="Data Source=${basedir}\SyncLog.db;Version=3;"
commandText="INSERT into Log(iteration_id, request_response_pair, type, level, server_id, server_alias, description, error) values(#Iteration_id, #Request_response_pair, #Type, #Loglevel, #server_id, #server_alias, #Description, #Error)">
<parameter name="#Type" layout="${message}"/>
<parameter name="#Loglevel" layout="${level:uppercase=true}"/>
<parameter name="#Request_response_pair" layout="${event-context:item=request_response_pair}"/>
<parameter name="#Iteration_id" layout="${event-context:item=iteration_id}"/>
<parameter name="#server_id" layout="${event-context:item=server_id}"/>
<parameter name="#server_alias" layout="${event-context:item=server_alias}"/>
<parameter name="#Description" layout="${event-context:item=description}"/>
<parameter name="#Error" layout="${event-context:item=error}"/>
</target>
</targets>
<rules>
<logger name="*" minlevel="Trace" writeTo="Database" />
</rules>
</nlog>
Here is how I log:
namespace NLog
{
public static class LoggerExtensions
{
public static void InfoEx(this Logger l, string message, Dictionary<string, object> contextParams)
{
LogEventInfo eventInfo = new LogEventInfo(LogLevel.Info, "", message);
foreach (KeyValuePair<string, object> kvp in contextParams)
{
eventInfo.Properties.Add(kvp.Key, kvp.Value);
}
l.Log(eventInfo);
}
public static void InfoEx(this Logger l, string message, string server_id, string server_alias, Dictionary<string, object> contextParams = null)
{
Dictionary<string, object> p = new Dictionary<string, object>();
p.Add("server_id", server_id);
p.Add("server_alias", server_alias);
if (contextParams != null)
{
foreach (KeyValuePair<string, object> kvp in contextParams)
{
p.Add(kvp.Key, kvp.Value);
}
}
l.InfoEx(message, p);
}
}
}
I know about logging levels but I need all this verbose logs, so I log it as info. I can't find any tutorial how to log these complicated, structured logs. Only plain dumb log messges.
I am assuming, you are talking about "Logs" for the typical "log things so we have something to look at if we need to inspect our workflow (errors/performance)". I assume that you do NOT mean logs as e.g. in "We need accounting information and the log is part of our domain data and is included in the workflow."
And from what I got from your posting, you are worrying about the backend storage format on the logs, so that you can later process them and use for said diagnostics?
Then I'd recommend that you make the logging code independend of the domain specifics.
Question: How will the logs you create be processed? Do you really need to access them all over the place so you need the database to provide you a structured view? Is it in any kind relevant how fast you can filter your logs? Or will they end up in one big log-analyzer application anyway, that is ran only ever second week when something bad happened?
In my opinion, the biggest reasons you want to avoid any domain specifics in the log are that "logs should work if things go wrong" and "logs should work after things changed".
Logs should work if things go wrong
If you have columns in your log table for domain specific values like "Request_response_pair", and there is no pair, then to write the log itself might fail (e.g. if its an index field). Of course, you can make sure to not have non-null columns and no restrictions in your DB-design, but take a step back and ask: Why do you want the structure in your log database anyway? Logs are meant to work as reliable as possible, so any kind of template you press them on may restrict the use cases or may make you not be able to log crucial information.
Logs should work after things changed
Especially if you need logs for detecting and fixing bugs or improve performance, that means that you will regulary compare logs from "before the change" to logs from "after the change". If you need to change the structure of your log database, because you changed your domain data, this is going to hurt you when you need to compare the logs.
True, if you make a data structure change, you probably still need to update some tools like log analyzer and such, but there is usually a large part of logging/analyzing code that is completely agnostic to the actual structure of the domain.
Many systems (including complex ones) can live with "just log one simple string" and later write tools to take the string apart again, if they need to filter or process the logs.
Other systems write logs in simple string key/value pairs. The log function itself is not domain specific but just accepts a string dictionary and writes it off (or even easier, a params string[] which should have an even number of parameters and you use every second parameter as key - if you aren't scared by that proposition :-D).
Of course, you will probably start writing another tooling layer on top of the base log functions that knows about domain specific data structures and then composes the string dictionary and pass it on. You certainly don't want to copy the decomposing code all place around. But make the base functions available at all places where you might want to log something. Its really helpfull if you indeed run into "strange" situations (exception handler) where some information is missing.