Logging

[QuiCM]

What do we want our logger to do?

[tylerjwatson]

log stuff

Edit: In all seriousness though, here is my wishlist for the logging facility:

[ ] Create seperate logging facilities per module instance: Each plugin gets its own little neat logger that it writes stuff to, this logger has its own level, they gotta stand up and tear down at any time.
[ ] Different appenders per facility that may be turned on and off per config
[ ] Logrotate engine that splits logs up into predetermined info, will also be handy if it compresses them
[ ] Different log destination implementations, eg. disk? sql? Datadog? Splunk?

[SignatureBeef]

As discussed, here is a short comparison of how OTA.Logging.ProgramLog in OTAPI can assist.

In short there are two main sections of how ProgramLog works.
Firstly, ProgramLog typically writes everything to the main server log (created by OTA) and facilitates the writing to the console and child LogLargets.
Secondly, there is LogChannel which is intended for use on a per module basis.

1. Log facilities can be created using a new instance of the OTA.Logging.LogChannel class.
   By default it will only print the to console, but can have a LogTarget attached. A LogTarget is an abstract implementation for use with custom targets such as the ones you mentioned above. The only built-in LogTargets are for disk and TextWriters though can be expanded on (i.e. sql and so on).
   Note, the only thing left for LogChannel is to complete closing, as it needs to be done via ProgramLog.

Here is a quick example how to create and use a custom LogChannel. In general, ProgamLog.Log can be used in a similar fashion (eg ProgramLog.Log).

var logger = new LogChannel("MyLogger", ConsoleColor.Cyan, System.Diagnostics.TraceLevel.Info)
{ 
    Target = new FileOutputTarget(Path.Combine(Globals.LogFolderPath, "myloggger.log"), true /*Log rotation*/)
};

logger.Log("Something has occurred");
logger.Log("Today is... {0:dd/MM/yyyy}", DateTime.Now);

try
{
    throw new Exception("Test exception 1");
}
catch (Exception e)
{
    logger.Log(e);
}

try
{
    throw new InvalidOperationException("Test exception 2");
}
catch (Exception e)
{
    logger.Log(e, "Oh noes Test exception 2");
}

logger.Log("Finishing");
logger.Close();

Contents of server_20160121_1420.log

21/01/2016 2:20:46 PM Run Info> Logging started to file "SNIP/Data/Logs/server_20160121_1420.log".
21/01/2016 2:20:47 PM Run Info> Initialising database for provider System.Data.SQLite
21/01/2016 2:20:47 PM Run Info> Something has occurred
21/01/2016 2:20:47 PM Run Info> Today is... 21/01/2016
21/01/2016 2:20:47 PM Run Info> System.Exception: Test exception 1
  at OTA.Callbacks.MainCallback.TestLogging () <0x5514fa8 + 0x001af> in <filename unknown>:0 
21/01/2016 2:20:47 PM Run Info> Oh noes Test exception 2:
System.InvalidOperationException: Test exception 2
  at OTA.Callbacks.MainCallback.TestLogging () <0x5514fa8 + 0x0021f> in <filename unknown>:0 
21/01/2016 2:20:47 PM Run Info> Finishing

Contents of myloggger_20160121_1420.log:

21/01/2016 2:20:47 PM Run Info> Something has occurred
21/01/2016 2:20:47 PM Run Info> Today is... 21/01/2016
21/01/2016 2:20:47 PM Run Info> System.Exception: Test exception 1
  at OTA.Callbacks.MainCallback.TestLogging () <0x5514fa8 + 0x001af> in <filename unknown>:0 
21/01/2016 2:20:47 PM Run Info> Oh noes Test exception 2:
System.InvalidOperationException: Test exception 2
  at OTA.Callbacks.MainCallback.TestLogging () <0x5514fa8 + 0x0021f> in <filename unknown>:0 
21/01/2016 2:20:47 PM Run Info> Finishing

Console output:

2. Appenders - I believe this would be a LogTarget in OTA (correct me if wrong). As per the first point, currently LogChannels only support 1 LogTarget but I am more than happy to change this to accomodate. All in all, I don't believe it should be too difficult to implement.
   In regards to configuration (if the following is what you mean), ProgramLog was not designed to be configurable by xml as like log4net is, so consider that as a bit of a downside. I'd be interested if you wish to help implement this, if it is truely required.

3. Log rotating is currently a simple task. It's not limited to file size, rather a a time stamp (which can be pointless if you have a 100% uptime server... lol). I have been meaning to implement this better, so if we go this route consider this on the TODO list. Compression will be included if so, amongst other suggestions.

4. See point 2) as it covers this.

[kevzhao2]

An external library like Serilog is probably our best bet.