Skip to content
This repository has been archived by the owner on May 27, 2024. It is now read-only.

Refactor sinks to be stateful; Add a logger sink #1

Merged
merged 4 commits into from
Jul 30, 2020

Conversation

drinks
Copy link
Member

@drinks drinks commented Jul 30, 2020

Description

Currently this gem is only capable of writing to stdout via puts. I'd like to use it to emit from an EC2 instance into a log file, meaning I need to pass it an instance of a Logger to buffer output.

Changes

  • Refactor sinks to be stateful
  • Rename Lambda sink to Stdout for mental-model alignment with the new one (all sinks are now named after their output
    mechanism)
  • Add Logger sink to accept any Logger instance and a level kwarg
  • Beefed up test coverage around sinks

@@ -30,9 +32,14 @@ def reconfigure

def namespace
return @namespace if defined?(@namespace)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method is two lines long, did it need a paragraph break?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was holding most of my lint tweaks back for the next PR but this one got lumped into the min stageable chunk. It's ruby style to follow any guard clause with an empty line: https://github.com/rubocop-hq/rubocop/blob/master/lib/rubocop/cop/layout/empty_line_after_guard_clause.rb


### Changed

- `Lambda` sink renamed to `Stdout` to reflect its destination rather than its intended use
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's cool. The node one is Console and Python is Lambda. So this means we are more like the node lib.

README.md Outdated

```ruby
Aws::Embedded::Metrics.configure do |c|
c.sink = Aws::Embedded::Metrics::Sinks::Logger.new(Rails.logger, level: :info)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the pattern around the Node lib for CloudWatch on EC2 (https://github.com/awslabs/aws-embedded-metrics-python#configuration) is c.log_group_name and c.log_stream_name. Given that and knowing this is different, what do you think of this interface?

Aws::Embedded::Metrics.configure do |c|
  c.logger = Rails.logger
  c.logger_level = :info # This could be the default too.
  c.sink = :logger
end

I noticed this is very much how DHH likes to see things. Ex, when the attribute API was be written. Using symbols and objects vs having users construct object literals which might be private or refactored later. That way the sink getter or via a lookup_sink private helper looks for a symbol first. I'm fine either way.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 would we anticipate that other sinks might have different initialization options? I'm open to this but it means either the footprint of attr_accessors for the config class grows with the product of each supported init signature or we end up with some method_missing / hash type thing. No dog in this fight for me, lemme know what you prefer.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say just merge it.

README.md Outdated Show resolved Hide resolved
@drinks drinks merged commit a87fafe into master Jul 30, 2020
@delete-merged-branch delete-merged-branch bot deleted the drinks/logger-sink branch July 30, 2020 17:55
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants