Expose new transforms and formatters design #25
Conversation
|
@unsign3d Sorry for the long delay - summer arrived here, the kids are out of school, and we've been doing our best to get out and enjoy it. This is the first of 2-3 PRs to rebuild what we had in #21. Once this is merged I'll get to work on adding the Thank you! |
stevenharman
force-pushed
the
expose_transforms_and_formatters
branch
from
fc38c6e to
cca4954
Compare
|
@unsign3d 👋 It's been a while and we're still running these changes in production, with great success. Are you still open to pulling them in? Thanks! |
Making the formatter available outside the IOTarget means other targets can also use it. This will be helpful when I add a LogTarget. This also adds some very basic tests (for my own sanity) for the IOTarget and JSONFormatter classes.
As it was, the formatters were doing both transforms on the keys (specific to a particular service) AND formatting the telemetry data. By separating those responsibilities, we can mix and match different Targets, Formatters, and Transforms to get the output needed for different consumers.
These are useful for custom targets that might not need/want any transforms for formatting, or to mix-and-match. For example, image a custom `LogTarget` that can be configured with a `:logger` option. It could be that the logger itself already knows how to format they telemetry data, (e.g., into key/value pairs), and so we don't want/need the Target to do any formatting. This allows this plugin's config to look like this: ```ruby Puma::Plugin::Telemetry.configure do |config| config.add_target(CustomLogTarget, logger: Logfmt.logger, transform: :cloud_watch, formatter: :noop) end ```
stevenharman
force-pushed
the
expose_transforms_and_formatters
branch
from
cca4954 to
f815fd8
Compare
|
Hello. 👋 I'm not sure what the current status of this plugin/Gem is, but we have been running it, including the modifications in #21 (broken up as incremental changes in #25, #26, and #37). Anyhow, we are quite interested in keeping this repo alive as we depend on it for our high-traffic production workloads. I'm happy talk through these changes (there's a good bit of context in #21) but the idea is to make the plugin more extensible by others, like my teams, so we'd not need to fork/rebase constantly to keep up to date. With all of that said, I'd be happy to help with maintaining this Gem if you'd like a hand. Either way, what do you think about starting to roll these changes in, giving us a solid base for user-extensible formatters and transforms? Thanks! |
1 participant
This work is an extraction of some of #21.
It includes a new base class (
BaseFormattingTarget) thatTargets can opt into, giving them access to theformatter:andtransform:options. It also extracts acloud_watchtransform andjsonformatter into discrete options, which can be mixed-and-matched with new:passthroughformatter and transform.This also keeps the existing
IOTargetbackwards compatible by defaulting toformatter: :jsonandtransform: :cloud_watch.It might be helpful to look at the changes/docs in the
READMEto get an idea of how these would be used.