Conditionally writing to stdout or stderr depending on log level with current version

[firxworx]

It's a common practice for production apps to write logs to stdout (e.g. for log entries that are at levels less severe than warning) or stderr (e.g. for warning/error/fatal levels) however I am not sure how to implement this with the current version of rails_semantic_logger.

Per the changelog, in v4.8.0+ a check was apparently added to appenders.rb: "Prevent multiple console (stdout or stderr) appenders from being added". It doesn't seem to care if what is being written to stdout and stderr are mutually exclusive.

Running the following example in a Rails app using the current version of rails_semantic_logger, the following error is produced: SemanticLogger::Appenders -- Ignoring attempt to add a second console appender: SemanticLogger::Appender::IO since it would result in duplicate console output

  config.semantic_logger.add_appender(
    io: $stdout,
    formatter: Example::StructuredLogFormatter.new, # config.rails_semantic_logger.format, # :json,
    level: :info,
    filter: ->(log) { log.level != :warn && log.level != :error && log.level != :fatal },
  )

  # SemanticLogger::Appenders -- logs: "Ignoring attempt to add a second console appender"
  config.semantic_logger.add_appender(
    io: $stderr,
    formatter: :json,
    level: :error,
    filter: ->(log) { log.level == :warn || log.level == :error || log.level == :fatal },
  )

My understanding is that without this built-in block, I could otherwise use the filter argument of add_appender to ensure that appenders for the respective$stdout and $stderr are don't overlap, and that no log entries would be duplicated in console output.

Please advise if there's a good way to handle this case, or if perhaps this would be better classified as a bug/issue. If there's a reason you don't think it matters and that I should log everything to stdout I'd be interested to know why??

[reidmorrison]

Planning on including this feature in Semantic Logger v5: reidmorrison/semantic_logger#203