For a C# regression test simulation of some hardware we're using log4net to trace the execution of the simulation. Errors are logged every time something goes wrong, and there should be zero errors, of course. We use the error count to determine pass/fail of the test, currently we search the log for ERROR to determine this.
Is it possible to retrieve an error count from log4net that increments every time an error is logged? I see that it is possible to log errors to a separate file but this is not exactly what we want, although with some fiddling we could extract the information indirectly from it, of course.
Thanks in advance.
I would log directly to a database or create a routine to import the log files into a database. Once the logs are in a database table they can be easily queried with SQL.
I can not think of anything directly built into log4net.
Either use some built-in appender that will let you count error occurences as Jaime suggested or alternatively create your own appender that will do exactly you want.
It is not too complicated especially since you plan using log4net to automate your whole testing process.
As Konrad suggests, roll your own. You should subclassForwardingAppender, making it count messages on their way to the "real" appenders. The appender could log the actual counts to a separate appender.
Related
I'm using a JSON log sink which destructures complex properties. For some reason, Microsoft has this log built-in when you return a file content result from your controller action:
Executing {FileResultType}, sending file with download name '{FileDownloadName}' ...
Tat FileResultType has a nested property which includes the actual byte array, so my log space will be blown out if I don't get rid of this.
I know how to filter out a specific logger by name, so I can do that.. But I really just don't want this specific object to be logged out. I still find the rest of the message very helpful. I'm not sure if there's a flag I can toggle to bypass this or what since Microsoft is definitely aware that many people are using log sinks which serialize complex objects instead of just calling .ToString(), but I haven't found anything yet. I'm using NLog so I'm sure I can get creative there with some if conditions, but it'd be pretty inefficient because that check would have to run on every single log attempt.
I am using Log4net for logging into my web api application. I am using below code to log warnings and error in database.
public async Task<int> ExecuteNonQuery(string procedureName,params SqlParameter[] parameters)
{
try
{
this.logger.DebugFormat("{0} stating call",procedureName);
......
......
......
}
further code
When i ran fortify scan it gives me log forging issue. Is there any idea how we can resolve this issue. I tried below code but didn't work
procedureName = Regex.Replace(procedureName, "[^ A - Za - z0 - 9 $]", string.Empty);
Fortify is guarding against Log Forging/Log Injection, where a malicious user could get unescaped input into your system in such a way that it's written to your log file. The idea would be to add in mis-leading log entries that would throw automated or manual intrusion detection or intrusion investigation attempts off the scent of the malicious user and what they are really trying to accomplish.
In order to combat this, one must carefully control which portions of user input end up being used in a log file. How to do this varies by how strict you are. You could simply escape all user input in your log, stripping out things like newlines or control characters. To be extremely strict, one removes all user input from their logging statements and uses a set of pre-developed events that form a "whitelist" of events that can be logged in the system.
In your case, it sounds like Fortify isn't smart enough to know if procedureName comes from user input or not, so it flags your logging statement as potentially containing dynamic/user content. If you are positive that you know where procedureName comes from, then you can ignore this as a false positive. Otherwise, you can use one of the mitigation techniques I've listed to make your logging statement more secure.
The answer from Seafish might be a bit hard to dissect. For that I am going to try and answer this.
As Fortify will explain, the Log Forging issue is because Fortify believes you are using a value/property that came directly from a user. In such a case, the user, if they were a bad actor, might have set that value to confuse your logs which messes with your ability to perform a proper audit.
The resolutions are usually one or multiple of the following:
Stripping out newlines or control characters from all properties or variables coming from a user before it hits your logs.
Remove all User input from being put into the logs, and instead using predefined messages to output.
Along with the first method, you can wrap all user defined values within certain markers to identify a true log entry.
The last suggestion is more of something that Fortify will likely not understand, which is why I recommended doing so in combination with the first solution. Just like using double quotes to quote someone, you can use a series of brackets around values in logs to help make it harder to forge, as well as even encrypting the Date/time thats on each line and using that to start the line so you can confirm that the start of a line is where you have a properly decrypted date/time that matches the date/time in the output message.
I'm tasked of introducing logging to a larger project. I have the following requirements:
Logging to the same file must be enabled from Visual Studio's C++ products, C# products, desktop apps, windows services, and more than one process should be able to write to a log file at once.
Format of logs is custom (semi-colon delimited fields, something like "custom_date;custom_time;the_rest;of_the_fields").
Log files have limit in size.
There's main .log file and older .bak file. .bak file is deleted when new .log file is created and current .log is renamed to .bak.
In one special case name of log files depends on time of creation. There are no multi-process writes in this case.
Now, I can roll my own implementation, but it would be really nice if there are ready made free libraries that satisfy all of the requirements. Does any one know of such libraries?
Many of your requirements (I think all but the language independence) are fulfilled by log4net
As you want to use several software components to use the logger I would suggest to write a windows service by yourself as it can be used by all types of your client software (C++, C#, ...)
Maybe you could simply write to the Event Log.
I would recommend NLog, meets most of your requirements
Use Microsoft's Enterprise Exception and Logging Application blocks. It satisfies all of your requirements. Everything is configurable using the web.config or app.config and allows the use of templates to record specific details. Also note that Microsoft has included a rolling type logger that will automatically start a new file based upon size or date/time. It's a complete package for any type of logging you want to do, MSMQ, SQL, flat file, windows event log, etc.
Log4Net can help you with your 2 and 3 point, for your 1,4 and 5 point i suggest you write a WebService that do all the work for writting in the logs, create, delete, etc.
I have just begun working on a C# application (using log4net). I'm supposed to add logs to code written by someone else. Hence, it's not possible for me to understand well the context each time (too much code, too less time :) ).
I have been following a convention which seems quite crude. I display log level, datetime, class name, method name with every log. I print the log on entering and exiting every method (most of them, i try to exclude method within big loops), in constructors, some events and every catch statement.
I think I'm overdoing it at places but some degree of uniformity is required. Any suggestions on the right (or better) approach?
Logging the start and end of every method, and the constructors, is certainly overkill.
I'm afraid that if you don't understand the method you won't be able to log the appropriate issues.
At the very least log all exceptions, never catch an exception without doing something with it.
I suggest, you first of all find out what is the reason why the log is needed now. After all, the code you are working on was apperntly developed without much logging, so what is the reason they want you to add logging: do they have problems locating bugs (what kind of bugs?) do they want be able to see in retrospect when the program did something (what is this something?)?
From my pov it is okay to log every function/constructor with input parameters and results in debug.
But keep the log messages as brief as possible as most data can be added/changed via the log4net configuration. Thus log only parameter1: value1 parameter2: value2 and result:x
Maybe you should also consider to log important conditional statements and their branches (entries), such as if/else if/else, and switch/case/default etc. This will help you provide more logic details inside the methods.
I am making my switch from coding in C++ to C#. I need to replace my C++ error logging/reporting macro system with something similar in C#.
In my C++ source I can write
LOGERR("Some error");
or
LOGERR("Error with inputs %s and %d", stringvar, intvar);
The macro & supporting library code then passes the (possibly varargs) formatted message into a database along with the source file, source line, user name, and time. The same data is also stuffed into a data structure for later reporting to the user.
Does anybody have C# code snippets or pointers to examples that do this basic error reporting/logging?
Edit: At the time I asked this question I was really new to .NET and was unaware of System.Diagnostics.Trace. System.Diagnostics.Trace was what I needed at that time. Since then I have used log4net on projects where the logging requirements were larger and more complex. Just edit that 500 line XML configuration file and log4net will do everything you will ever need :)
Lots of log4net advocates here so I'm sure this will be ignored, but I'll add my own preference:
System.Diagnostics.Trace
This includes listeners that listen for your Trace() methods, and then write to a log file/output window/event log, ones in the framework that are included are DefaultTraceListener, TextWriterTraceListener and the EventLogTraceListener. It allows you to specify levels (Warning,Error,Info) and categories.
Trace class on MSDN
Writing to the Event Log in a Web Application
UdpTraceListener - write log4net compatible XML messages to a log viewer such as log2console
I would highly recommend looking at log4Net. This post covers the majority of what you need to get started.
Another good logging library is NLog, which can log to a lot of different places, such as files, databases, event logger etc.
I use The Object Guy's Logging Framework--as do most people who try it. This guy has some interesting comments about it.
Enterprise Library is a solid alternative to log4net and it offers a bunch of other capabilities as well (caching, exception handling, validation, etc...). I use it on just about every project I build.
Highly recommended.
Even though I personally hate it, log4net seems to be the de facto standard for C# logging. Sample usage:
log4net.ILog log = log4net.LogManager.GetLogger(typeof(Program));
log.Error(“Some error”);
log.ErrorFormat("Error with inputs {0} and {1}", stringvar, intvar);
As I said in another thread, we've been using The Object Guy's Logging Framework in multiple production apps for several years. It's super easy to use and extend.
Log4Net is a rather comprehensive logging framework that will allow you to log to different levels (Debug, Error, Fatal) and output these log statements to may different places (rolling file, web service, windows errors)
I am able to easily log anywhere by creating an instance of the logger
private static readonly ILog _log = LogManager.GetLogger(typeof([Class Name]));
and then logging the error.
_log.Error("Error messsage", ex);
Serilog is late to the party here, but brings some interesting options to the table. It looks much like classical text-based loggers to use:
Log.Information("Hello, {0}", username);
But, unlike earlier frameworks, it only renders the message and arguments into a string when writing text, e.g. to a file or the console.
The idea is that if you're using a 'NoSQL'-style data store for logs, you can record events like:
{
Timestamp: "2014-02-....",
Message: "Hello, nblumhardt",
Properties:
{
"0": "nblumhardt"
}
}
The .NET format string syntax is extended so you can write the above example as:
Log.Information("Hello, {Name}", username);
In this case the property will be called Name (rather than 0), making querying and correlation easier.
There are already a few good options for storage. MongoDB and Azure Table Storage seem to be quite popular for DIY. I originally built Serilog (though it is a community project) and I'm now working on a product called Seq, which provides storage and querying of these kinds of structured log events.
You can use built in .NET logging. Look into TraceSource and TraceListeners, they can be configured in the .config file.
Ditto for log4net. I'm adding my two bits because for actual use, it makes sense to look at some open source implementations to see real world code samples with some handy additions. For log4net, I'd suggest off the top of my head looking at subtext. Particularly take a look at the application start and assemblyinfo bits.
Further to the couple of comments realting to the use of the System.Diagnostics methods for logging, I would also like to point out that the DebugView tool is very neat for checking debug output when needed - unless you require it, there is no need for the apps to produce a log file, you just launch DebugView as and when needed.
The built in tracing in System.Diagnostics is fine in the .NET Framework and I use it on many applications. However, one of the primary reasons I still use log4net is that the built in .NET Framework tracing lacks many of the useful full featured appenders that log4net already supplies built in.
For instance there really isn't a good rolling file trace listener defined in the .NET Framework other than the one in a VB.NET dll which really is not all that full featured.
Depending on your development environment I would recommend using log4net unless 3rd party tools are not available, then I'd say use the System.Diagnostics tracing classes. If you really need a better appender/tracelistener you can always implement it yourself.
For instance many of our customers require that we do not use open source libraries when installed on their corporate machines, so in that case the .NET Framework tracing classes are a perfect fit.
Additionally - http://www.postsharp.org/ is an AOP library I'm looking into that may also assist in logging as demonstrated here on code project:http://www.codeproject.com/KB/dotnet/log4postsharp-intro.aspx.
ExceptionLess is one of the easiest nuget package available to use for logging. Its an open source project. It automatically takes care of unhandled exception, and options for manually logs are available. You can log to online or self host on local server.
Log4Net, as others have said, is fairly common and similar to Log4j which will help you if you ever do any Java.
You also have the option of using the Logging Application Block http://www.codeproject.com/KB/architecture/GetStartedLoggingBlock.aspx