Better logging

[Blacksmoke16]

Currently Athena does not log incoming requests, non handled errors that happened (500s that otherwise are just swallowed), etc.

Ideally these should be logged to a file, and optionally STDOUT (if in development env) in some standardized way so that the developer could see whats wrong, but user would not get any insight to the issue. Could utilize IO::MultiWriter for this, possibly also some configuration via the config file?

The format should be configurable, probably using a Logger.formatter override.

Some way to rotate the log files?

[Blacksmoke16]

After some additional thought here is the current plan:

• Create a new logging section in athena.yml config file.
  • Use it to store global/env specific settings.
• Create some structure similar to HTTP::Handler, but for logging.
  • This would allow users to have a "pipeline" that gets executed when something is logged. Which could include things like log to a file, send errors to ES, send emails, etc.
  • Athena will come with some built in handlers, primarily log to STDOUT in develop mode, and corresponding file in dev/prod mode.
• Wrap the standard lib's Logger class to allow for a log method, and to allow standard .info etc to accept context, which would be a hash of data that would be passed along.
  • Useful for including metadata around a message. Would be json encoded at end of the log message.
• Would be a global module that is included into both cli and routing modules.
  • Sub modules could extend the logging methods to include context specific things, like the current action etc.
• Support custom formatters
  • Global ~/env/handler specific?~
• ~Have some method of rolling log files~
  • ~Config could include number to keep and size limit~
  • ~While file is open, check the size and run the rolling logic if needed~

[Blacksmoke16]

Basically modeling this off of monolog.

• Build out a new Logger class, based (roughly?) on RFC5424
  • Implement concepts:
  • processor - allows adding additional data to the log record
  • handler - writes/sends the log record somewhere (basically just a class that implements a write method)
    • STDOUT/file/ES/email etc
  • formatter - changes the output style of a handler
  • Allow logger methods to allow for a hash of contextual data
  • Possibly create some sort of logger registry such that Athena.logger would be the default, but Athena.logger("foo") would use a logger registered with the name "foo". This would allow different customizable "pipelines" each with their own, or shared, set of handlers, formatters, and processors.
  • Ideally we could also use the YAML config file to define these, but would have to investigate that more.

[Blacksmoke16]

This will be fixed via an implementation of Crylog once I get things fledged out a bit more.