Allow custom payload in request logger

[bigcommerce]

Allow custom payload in request logger

[splittingred]

There's not out of the box. It might be a good option. That said, you could fairly easily create a custom formatter:

require 'gruf'

class MyCustomFormatter < Gruf::Interceptors::Instrumentation::RequestLogging::Formatters::Base
  def format(payload)
    # do custom payload things here
    payload.merge!(format: 'json')
    payload.to_json
  end
end

Gruf.configure do |c|
  c.interceptors.use(
    Gruf::Interceptors::Instrumentation::RequestLogging::Interceptor,
    formatter: MyCustomFormatter
  )
end

[zinosama]

There's not out of the box. It might be a good option. That said, you could fairly easily create a custom formatter:

require 'gruf'

class MyCustomFormatter < Gruf::Interceptors::Instrumentation::RequestLogging::Formatters::Base
  def format(payload)
    # do custom payload things here
    payload.merge!(format: 'json')
    payload.to_json
  end
end

Gruf.configure do |c|
  c.interceptors.use(
    Gruf::Interceptors::Instrumentation::RequestLogging::Interceptor,
    formatter: MyCustomFormatter
  )
end

Thanks for the quick response. Though in my use case, I actually need to insert data from the response/result instead of simple static values.

A good example of what I’m looking for is the custom_payload option for lograge:

Rails.application.configure do
  config.lograge.enabled = true

  config.lograge.custom_payload do |controller|
    {
      host: controller.request.host,
      user_id: controller.current_user.try(:id)
    }
  end
end

[splittingred]

Got it. There's a couple of ways we could solve this:

• Create another configuration option that allows a block to be passed.
• Pass the request object into formatters to allow them access.

I think i'd prefer the latter, as that doesn't introduce a new abstraction layer or configuration element, and allows custom formatters more flexibility and options when dealing with data. Thoughts?

[zinosama]

Got it. There's a couple of ways we could solve this:

• Create another configuration option that allows a block to be passed.
• Pass the request object into formatters to allow them access.

I think i'd prefer the latter, as that doesn't introduce a new abstraction layer or configuration element, and allows custom formatters more flexibility and options when dealing with data. Thoughts?

I agree the latter is a better approach. It'd be weird to have gruf config options that are specific to an optional interceptor. Thanks for the quick response and getting this into PR.