Add honeybadger_events appender

[trvsdnn]

Changelog

Entry added:

• Add appender for Honeybadger events/insights API

Description of changes

Adds an additional Honeybadger appender honeybadger_events for their events/insights API.

The appender uses the honeybadger gem and the Honeybadger.event method, which is intelligent about batching log lines and sending a single request.

[stympy]

I wonder if it would make sense to modify the existing appender instead of creating a new one. The non-exception branch of the log method could use Honeybadger.event to send the payload.

[trvsdnn]

I considered that – it's a bit odd to use semantic_logger for exceptions when the honeybadger gem does it already. Unless I'm missing some clear benefit.

The problem IMO is that it's a change in behavior for anyone using it and would/should require a major release I would think.

This approach felt similar to the NewRelic vs NewRelicLogs appenders.

[stympy]

I considered that – it's a bit odd to use semantic_logger for exceptions when the honeybadger gem does it already. Unless I'm missing some clear benefit.

Agreed :)

The problem IMO is that it's a change in behavior for anyone using it and would/should require a major release I would think.

This approach felt similar to the NewRelic vs NewRelicLogs appenders.

Yeah, that makes sense.

[stympy]

Suggested change

	SemanticLogger::Formatters::Raw.new(time_key: :ts, time_format: :rfc_3339)
	SemanticLogger::Formatters::Json.new(time_key: :ts, time_format: :rfc_3339)

[trvsdnn]

Honeybadger.event seems to use a string argument as the event_type and not treat it as an object.

Honeybadger.event('{"foo":"bar"}')

results in

@ts "2024-06-12 19:34:05.000"
event_type "{"foo":"bar"}"

vs

Honeybadger.event({foo:"bar"})

@ts "2024-06-12 19:37:29.000"
foo "bar"

[stympy]

Oh, right, ignore me :)

[trvsdnn]

Didn't even know it accepted a string... good to know!

[reidmorrison]

Looking at the Honeybadger documentation for the event api, the first argument is the event_type, and the second argument is a Hash. https://docs.honeybadger.io/lib/ruby/getting-started/sending-events-to-insights/#manually-sending-events

We could make the event_type the value from log.metric when present and something like event.semantic_logger when a log entry has no metric. Following the examples from the documentation: https://docs.honeybadger.io/lib/ruby/getting-started/sending-events-to-insights/#event-captures

[stympy]

It’s totally fine to pass a hash as the first argument and not specify an event type, if that makes more sense. 🙂

[trvsdnn]

It feels right to send event_type for instrumentation type events like process_action.action_controller – using the honeybadger gem to handle instrumentation gives you that.

For raw logging I don't like the idea of the appender deciding what you want to include in the log payload.

[reidmorrison]

Understandably we are calling it Honeybadger Events, since it uses the Event API, but they refer to overall solution as Honeybadger Insights: https://docs.honeybadger.io/guides/insights/
Can we rename the appender to HoneybadgerInsights ?

For anyone that first comes across the appender, Honeybadger Insights would be simpler to understand.

[stympy]

Understandably we are calling it Honeybadger Events, since it uses the Event API, but they refer to overall solution as Honeybadger Insights: https://docs.honeybadger.io/guides/insights/ Can we rename the appender to HoneybadgerInsights ?

For anyone that first comes across the appender, Honeybadger Insights would be simpler to understand.

👍