Re: New features in NLog - please read and make comments

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: New features in NLog - please read and make comments

Jarek Kowalski
Administrator
[hidden email] wrote:

> I think I tried using NLog in a way it wasn't intended, but hopefully this will help reveal what we could use.  I configured  my log target like this:
>
>       <target name='RTObjects_CSLoggerFileTarget' type='File'
>               layout='${longdate}|${level}|${threadname}|${logger}|${message}'
>               filename='RTObjects_CS--${machinename}--${shortdate}.log'
>               archiveEvery='Day'
>               archiveFileName='RTObjects_CS--${machinename}--${shortdate}.log'
>               maxArchiveFiles='2'
>               enableFileDelete='True'
>               />
>
> From here I ran a unit test, saw a file with the current date, then changed the date to the next date, then ran the unit test again, etc., 4 times.  The old files were never deleted.  Note that once the unit test finished, it was unloaded.  This is the kind of scenario we have in the field--one log file per date is usually sufficient, but after a certain number of days (maybe 30 or 60) it would be nice to get the old ones to automatically delete.  We don't care for archive file names or anything like that--and the system will generally be shut down every night.
>
> If it's possible I'm just doing something wrong, please let me know.  I'm assuming it is just a sort of corner case or missing feature for now.  If you do intend to accommodate this need at some point, please let me know.  BTW, I used the nlog-20060904-src.zip for my logging tests.
>  
I believe you should just exclude the ${shortdate} from the filename and
remove archivefilename attribute completely.
Enablefiledelete is not necessary - it just allows you to delete the
files manually in the middle of the day.

It is not a missing feature, actually it's by design. "archiveEvery" is
considered for each written file separately, when your file name
includes current date, there is no chance someone could write to it
after midnight, so the files will never be rotated. When you set the
archiveEvery to "Hour" you should observe NLog to move the contents of
the file to archive every hour. The files should be named:

RTObjects_CS--MYMACHINE-2006-09-07.log - main log file from today
RTObjects_CS--MYMACHINE-2006-09-07.1.log - archive #1
RTObjects_CS--MYMACHINE-2006-09-07.2.log - archive #2
RTObjects_CS--MYMACHINE-2006-09-06.log - main log file from yesterday
RTObjects_CS--MYMACHINE-2006-09-06.1.log - archive #1
RTObjects_CS--MYMACHINE-2006-09-06.2.log - archive #2
RTObjects_CS--MYMACHINE-2006-09-05.log - main log file
RTObjects_CS--MYMACHINE-2006-09-05.1.log - archive #1
RTObjects_CS--MYMACHINE-2006-09-05.2.log - archive #2

The archive files will contain one hour of logs each and main log file
will have logs from the last hour only, so 2006-09-06.log will contain
logs from 2006-09-06 23:00:00 until 2006-09-06 23:59:59 and so on.

If you remove the ${shortdate} from the filename, set archiveEvery="Day"
and maxArchiveFiles="7" you should get your last week of logs archived:

RTObjects_CS--MYMACHINE.log - today's log
RTObjects_CS--MYMACHINE.1.log - yesterday's log
RTObjects_CS--MYMACHINE.2.log - logs from two days ago
RTObjects_CS--MYMACHINE.3.log
RTObjects_CS--MYMACHINE.4.log
RTObjects_CS--MYMACHINE.5.log
RTObjects_CS--MYMACHINE.6.log
RTObjects_CS--MYMACHINE.7.log ... and so on

Hope it helps,

Jarek

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Nlog-list mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list
NLog Blog
Reply | Threaded
Open this post in threaded view
|

Re: New features in NLog - please read and make comments

Jarek Kowalski
Administrator
Gleason, Todd wrote:

> I think I understand your point, but what I'm saying is that it would be
> nice to have the archive removal feature, without the requirement to use
> the numerical naming scheme.  We really do like to encode the date as
> part of the file name, and not mess with a .1., .2., etc. which will
> just confuse people.  But, having old files be cleaned up automatically
> would be extremely useful as well.
>
> The funny thing is that you wrote this at
> http://www.nabble.com/New-features-in-NLog---please-read-and-make-commen
> ts-t1844701s6167.html :
>
> The good news it works with any fancy filenaming scheme you may invent.
> You
> may use layout renderers in both file and archive names. The only
> requirement is that archives for a single filename are kept in a single
> directory.
>
> Our "fancy filenaming scheme" is to use the date, and not to use the
> archive placeholder...yet this doesn't work.
>
> Does that help to understand where I'm coming from?
>  
Yes. Unfortunately NLog does not support exactly this approach with
proper cleanup.

Perhaps there should be an option to remove files older than N days in
some particular directory? Wouldn't it be just what you're trying to
achieve? This feature may be added post-1.0 final (which I hope to
release this week).

Regards,

Jarek

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Nlog-list mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list
NLog Blog
Reply | Threaded
Open this post in threaded view
|

Re: New features in NLog - please read and make comments

Jarek Kowalski
Administrator
In reply to this post by Jarek Kowalski
Gleason, Todd wrote:
> Such a "deleteFilesOlderThan" option would be roughly what we'd like,
> but it would have to do so according to the filename pattern...so you'd
> probably have to transform ${shortdate} into an appropriate regex match,
> and only delete matching filenames older than the specified date.  It is
> possible that different loggers would need different values, or that
> there might exist non-log files in the same directory.
>  
I'll give it some though. I don't think it can be that simple.

> One other, unrelated question:  Looking at
> http://www.nlog-project.org/target.Database.html , there's an important
> security issue for us.  We would love to be able to use NLog to log to
> our DB, and we could provide the appropriate SQL I'm sure.  But, while
> we would like to provide the connectionString, we cannot do so in the
> .config file.  Our connection information is in a user-accessible file,
> and so we encrypt it.  We decrypt it at runtime and plug it in.
>
> What would be nice here would be able to use the standard XML
> configuration, but "plug in" to it at runtime.  There are a few
> possibilities for this that occur to me now:
>
> 1. Instead of connectionString, we could provide a static property name,
> callable via reflection from NLog.  NLog would find this property and
> use its value as the connectionString.  Easy for us, not too hard for
> NLog, don't know if others could use such a feature.
> 2. We could intercept the XML in some way and "plug in" to add the
> connectionString node.  This seems a little painful to me but if there
> are examples of doing this general thing it would help a lot.
> 3. Conceivably we could let the XML configuration run, and then go to
> the config object and alter it programmatically.  I don't know that this
> is even allowed, but if so, an example would help.  It might be easier
> than altering the XML.
> 4. We could read the XML ourselves, add to it, and then plug that into
> NLog.  This seems to be the most painful and I'd like to avoid it.
>  
NLog (latest versions only, this is not 1.0RC1) support nesting of
layout renderers + there is ${file-contents} which can be used to read
the contents of a file.
Assuming you can write your own layout renderer that decrypts the
cntents of the file (${mydecrypt} might not be a bad name) you should be
able to use it like this:

<target name="db" type="Database"
connectionString="${decrypt:${file-contents:${basedir}/connectionString.txt}}"
... />

For an example of "decryption" layout renderer see ${rot13}:

http://svn.nlog-project.org/repos/nlog/trunk/NLog/src/NLog/LayoutRenderers/Rot13.cs

Jarek

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Nlog-list mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list
NLog Blog
Reply | Threaded
Open this post in threaded view
|

Re: New features in NLog - please read and make comments

Jarek Kowalski
Administrator
Jaroslaw Kowalski wrote:
Gleason, Todd wrote:
  
Such a "deleteFilesOlderThan" option would be roughly what we'd like,
but it would have to do so according to the filename pattern...so you'd
probably have to transform ${shortdate} into an appropriate regex match,
and only delete matching filenames older than the specified date.  It is
possible that different loggers would need different values, or that
there might exist non-log files in the same directory.
  
    
I'll give it some though. I don't think it can be that simple.

  
One other, unrelated question:  Looking at
http://www.nlog-project.org/target.Database.html , there's an important
security issue for us.  We would love to be able to use NLog to log to
our DB, and we could provide the appropriate SQL I'm sure.  But, while
we would like to provide the connectionString, we cannot do so in the
.config file.  Our connection information is in a user-accessible file,
and so we encrypt it.  We decrypt it at runtime and plug it in.

What would be nice here would be able to use the standard XML
configuration, but "plug in" to it at runtime.  There are a few
possibilities for this that occur to me now:

1. Instead of connectionString, we could provide a static property name,
callable via reflection from NLog.  NLog would find this property and
use its value as the connectionString.  Easy for us, not too hard for
NLog, don't know if others could use such a feature.
2. We could intercept the XML in some way and "plug in" to add the
connectionString node.  This seems a little painful to me but if there
are examples of doing this general thing it would help a lot.
3. Conceivably we could let the XML configuration run, and then go to
the config object and alter it programmatically.  I don't know that this
is even allowed, but if so, an example would help.  It might be easier
than altering the XML.
4. We could read the XML ourselves, add to it, and then plug that into
NLog.  This seems to be the most painful and I'd like to avoid it.
  
    
NLog (latest versions only, this is not 1.0RC1) support nesting of 
layout renderers + there is ${file-contents} which can be used to read 
the contents of a file.
Assuming you can write your own layout renderer that decrypts the 
cntents of the file (${mydecrypt} might not be a bad name) you should be 
able to use it like this:

<target name="db" type="Database" 
connectionString="${decrypt:${file-contents:${basedir}/connectionString.txt}}" 
... />

For an example of "decryption" layout renderer see ${rot13}:

http://svn.nlog-project.org/repos/nlog/trunk/NLog/src/NLog/LayoutRenderers/Rot13.cs
  
Oops, sorry. I've just noticed that connectionString does not accept layouts. I'll fix it in a moment.

Jarek

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Nlog-list mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list
NLog Blog