Optionally log file and line number with each statement. about semantic_logger HOT 8 CLOSED

I looked into this capability and agree that it would be very useful. The challenge is that __FILE__ and __LINE__ are defined at the point in the code they are used. I.e. By using these values inside of SemanticLogger would cause it to return the SemanticLogger file and line number rather than the file and line number of the caller.

The only place I have seen someone grab the file and line number without forcing the caller to pass it on every log entry would be to grab the stack trace by creating a new Exception. Unfortunately grabbing the stack trace is a relatively expensive operation.

Otherwise the only way to do it right now is to add it to every log entry:

logger.info("Hello there", file: __FILE__, line: __LINE__)

Running the above in a Rails console:

 Rails.logger.info("Hello there", file: __FILE__, line: __LINE__)

Results in the correct filename and line number be written to the log file:

2015-09-15 19:51:27.706031 I [13857:70365821133320] Rails -- Hello there -- {:file=>"(irb)", :line=>2}

from semantic_logger.

Makes sense, and matches my understanding of the issue. I made a clunky workaround by using a method proxy around the logger which injects the line number using the caller kernel method. Works well enough, though performance isn't a huge issue for me. Here's what it looks like:

class Proxy
  def initialize(logger)
    @logger = logger
  end

  def method_missing(m, *args, &block)
    location = caller[0].split('/').last
    file, line = location.split(':')

    args[0] = "(#{file}:#{line}) #{args[0]}"
    @logger.send(m, *args, &block)
  end  
end

from semantic_logger.

Great idea to help narrow down log messages.

I just researched Kernel#caller and it is unfortunately expensive. Maybe we could limit it to error and above log messages.

What we have done is to give every class it's own logger instance using 'include SemanticLogger::Loggable' so that the class is added to every log message and then we can search for the message in that file. Not a perfect solution but it avoids the expense of calculating the stack trace. In our batch environment we were processing over 11,000 log messages per second ( before silencing info level messages ).

Wish there was a way in Ruby to quickly get to the caller without the need for obtaining a full stack trace.

from semantic_logger.

Another use case where the stack trace would be very useful is when submitting an error to Bugsnag it would be nice to know where the error came from.

We could create a global configuration option to set the level at which to collect stack traces. If the stack trace is present, then it could log the filename and line number. And for Bugsnag or other event systems we can forward the stack trace directly to them.

So in low volume environments it could be dropped to :debug or :info and then in production it would be set to :error level.

from semantic_logger.

Busy with the change to support capturing stack traces within the context of the caller. In Rails add the following to config/environments/development.rb:

  # Log level, suggest :trace or :debug in develooment
  config.semantic_logger.default_level = :trace
  # To add the filename and line number to all log messages
  # Recommend :error, :warn, or :fatal in production
  config.semantic_logger.backtrace_level = :trace

Or if running standalone:

  SemanticLogger.default_level = :trace
  # To add the filename and line number to all log messages
  # Recommend :error, :warn, or :fatal in production
  SemanticLogger.backtrace_level = :trace

from semantic_logger.

@UnquietCode Can you give the master branch on github a try and let me know what you think about the implementation and if you have any feedback?

from semantic_logger.

I am currently running on master and this feature is working great! I'm trying to debug another issue where using payloads is causing the logging statement to fail silently. Not sure what's causing that yet.

from semantic_logger.

Ok, that issue was unrelated (#19). This is working well for me. Thanks for adding the level-based configuration option which, as you say, lets me squeeze a little more performance out of production environments.

from semantic_logger.