Firehose topic for IncidentLogger (take 2) #124

wants to merge 33 commits into


None yet

2 participants

grantr commented Nov 20, 2012

See #96.

Also adds specs for IncidentLogger and benchmarks.

grantr added some commits Nov 21, 2012
@grantr grantr rename firehose to just events
FirehoseConsumer is now EventReporter. Firehose was always awkward and
this makes more sense anyway.
@grantr grantr allow calling Severity methods directly 716951d
@grantr grantr implement to_hash for easy serialization 0a3db4a
@grantr grantr tighten IncidentReporter subscription 13d9a6d
@grantr grantr refactor IncidentReporter a bit
Move silencing and the logging formatter so they can be shared by other log
@grantr grantr publish all events to a firehose topic
Without a firehose the IncidentLogger can't satisfy cases where every
log message needs to be captured.

Now would be a good time to do some benchmarks on the fanout notifier.
@grantr grantr add example FirehoseConsumer
Wraps a Logger instance, same as IncidentReporter.
@grantr grantr update docs f8e3f45
@grantr grantr allow firehose to be turned off 62f9f16
@grantr grantr make sizelimit and buffers readonly
sizelimit can't be changed after initialize, and buffers shouldn't be
changed directly.
@grantr grantr return nil for events under level
There's no event and no id to return.
@grantr grantr add buffer_for and buffers_for
Makes it slightly easier to test buffer contents.
@grantr grantr use a test incident reporter for testing
Don't need the default incident reporter for tests. Instead
use TestIncidentReporter which collects incidents into an array.
@grantr grantr first pass at incident logger specs 4c921f7
@grantr grantr allow setting fallback_logger 7629060
@grantr grantr specs for fallback and buffer cycling f4ef0ef
@grantr grantr add firehose specs c55381e
@grantr grantr add a logger benchmark

* Ruby standard logger
* IncidentLogger with no consumers
* IncidentLogger with one reporter only
* IncidentLogger with reporter and firehose consumer

IO::NULL is used for all log devices.
@grantr grantr use a new logger for every scenario f2a0994
@grantr grantr add sleeps so parallel vms pass tests 131d1bc
@grantr grantr Squash test reporters into a single consumer
Start a new consumer for each test to minimize dependencies
@grantr grantr link reporters to notifier
If the notifier crashes, subscribers lose their subscriptions. Reporters
need to be linked to the notifier so they crash too and resubscribe.
@grantr grantr allow log event containers to be created without args
Mostly useful for testing.
@grantr grantr round out incident logging specs 2e8c3fa
@grantr grantr don't launch the incident reporter by default
Since the IncidentLogger is not used by default, let the users who are
interested start the reporter themselves.
grantr commented Jan 11, 2013

This is ready for review.

Unlike the previous attempt, this doesn't change the default logger. Users who want to try it out can start a logger and reporter(s) themselves.

Benchmarks show a moderate slowdown versus Logger, but still fast enough for most people.

grantr commented Jan 11, 2013

Intermittent travis failures are due to timing issues. One of the tests ensures that reporters resubscribe in the event of a notifier crash, which requires the notifier and all reporters to crash and restart during the test. I don't know how to verify the restart has completed. If there's a better way than sleeping (or a better sleep time), let me know.

grantr added some commits Jan 11, 2013
@grantr grantr simplify logger benchmark
Just run the test for the most likely scenario.
@grantr grantr add level to event reporter
Allows debug messages to be logged for incidents but be ignored by event
@grantr grantr add peek to IncidentLogger
allows peeking into buffers without flushing them. Useful when you want
to see if anything is happening, but you don't need a full-fledged event
@grantr grantr add trace to Celluloid::Logger 966cf03
@grantr grantr log received event to fallback logger
Otherwise log messages are lost if the notifier is down. This way at
least the message is logged somewhere.

@grantr is this possible to squash and then rebase on master?


This is quite old and needs to be rebased to take into account all the new features.

@halorgium halorgium closed this Apr 19, 2013
grantr commented Apr 19, 2013

@halorgium It's definitely possible to rebase, but I think it's fair to close this for now until supervision strategy is worked out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment