v2.0.0

honeycomb-beeline v2.0.0

This version of the Ruby Beeline includes a number of changes and enhancements designed to address specific use cases and make some aspects of the various beelines more consistent. Included in this release:

• The Rails generator now produces a configuration that excludes redis.command, sql.active_record.binds and sql.active_record.type_casted_binds by default. The purpose of this change is to highlight the ability to scrub potentially sensitive fields from being automatically sent to Honeycomb if desired. #74

• The beeline now exposes the following class methods:

  • Honeycomb.libhoney returns the underlying libhoney-rb instance. #70
  • Honeycomb.current_span now returns the currently instrumented span. #46
  • Honeycomb.current_trace returns the currently instrumented trace. #46

• Added auto_instrumentation fields to be more in line with other beelines. #69

  • meta.instrumentations_count - The number of integrations included in the config (i.e. redis, aws, etc)
  • meta.instrumentations - A list of the integrations that are included
  • request.header.accept - The value of the Accept header from the incoming request
  • request.header.content_type - The value of the Content-Type header from the incoming request
  • request.secure- Is the request secure (https or wss)
  • request.xhr- Is this request an XMLHTTPRequest?
  • response.content_type - The value of the Content-Type header on the outgoing response

• Refactored Rails integration which avoids extraneous query string parsing fixing a number of bugs. #73

• Better handling of bad request params fixing bug that caused rails middleware to break on bad params. #50

• Fixed bug preventing Redis client from being disabled. #60

• Changed order of ActionDispatch::ShowExceptions insertion to ensure correct HTTP status error codes are returned by Rails (400s instead of 500s). #49

• AWS params are exploded properly into separate keys instead of being mashed into a single aws.params field. #44

• request.error and request.error_detail are now error and error_detail when used in a non-request context. Consistent with other beelines. #63

• Unpacks hashes in ActionController::Parameters ensuring that the nested data is parsed by Honeycomb. #75

This release features contributions from @martin308 @paulosman @lizthegrey @ajvondrak @polotek and @cade . Thank you all!

Backwards Incompatibilities

Because this is a major version bump, backwards incompatible changes should be expected. The following changes specifically are important to be aware of:

• #75 - A result of this change is that ActionController::Parameters is instrumented as a nested hash, resulting in JSON unfurling based on how the Honeycomb dataset is configured. You'll see more fields added to your dataset and different values for fields that used to contain nested values. This is important if you have any queries that rely on fields instrumented from ActionController::Parameters.

• #44 - AWS parameters are now exploded so that they are instrumented as separate fields in a dataset. It used to be that aws.params would be a string-ified object. Now parameters are instrumented as their own fields (i.e. aws.params.bucket). The result of this is that new fields will appear and aws.params will go away in datasets that use the aws integration.

• #63 - This change moved fields around a bit, specifically request.error becomes error and request.error_detail becomes error_detail. Queries may need to be updated and custom instrumentation that does not use the app namespace could possibly introduce collisions.

• #69 - Amongst other changes, this change results in request.protocol becoming request.scheme in order to be more consistent with other beelines. Queries may need to be updated.