Added console reporter

[ianzy]

The console reporter is the counterpart of "metrics" projects' reporting tool. It generates metrics report to a IO stream and it can work together with agent.

Example code working together with agent would look like this,
@metrics = Metrics::Agent.new
@metrics.start
@reporter = Metrics::ConsoleReporter.new
@reporter.start
counter = @metrics.counter :my_counter
counter.incr
counter.incr

or it can be used individually as a reporting tool
out = File.new('metrics.report', 'w')
@reporter = Metrics::ConsoleReporter.new(out)
@reporter.start(20)
counter = @reporter.counter :my_counter
counter.incr
counter.incr

Hope this is helpful~

[johnewart]

Could we maybe refactor this so that the agent can have a modular output?

i.e there's only one "agent" but it can export via HTTP, dump to IO stream, push data to some collection system, etc.

[ianzy]

Sounds like a good idea, the reporter is actually quite similar to the
agent.

On Thu, Apr 21, 2011 at 1:20 PM, johnewart <
[email protected]>wrote:

Could we maybe refactor this so that the agent can have a modular output?

i.e there's only one "agent" but it can export via HTTP, dump to IO stream,
push data to some collection system, etc.

Reply to this email directly or view it on GitHub:
#15 (comment)

[johnewart]

Exactly -- it seems like they should all just channel through one place to keep things tidy. Thanks for this!

[ianzy]

Hi John,

Do you want to discuss more about the refactoring? I am not exactly sure how
you want things to be organized. What I can think of is using some sort of
command pattern to isolate the output logic. So the agent will take a object
with start_daemon_thread() method as parameter. The code would look
something like this,

module Metrics
class Agent
include Logging
include Instruments::TypeMethods

attr_reader :instruments

def initialize(Reporter = Metrics::HTTPReporter)
  @reporter = Reporter.new
end

def start
  @reporter.start_daemon_thread
end

end
end

module Metrics
class HTTPReporter
def initialize(port = 8001)
logger.debug "Initializing Metrics..."
@instruments = Metrics::Instruments
@PORT = port
end

def start_daemon_thread(connection_options = {})

logger.debug "Creating Metrics daemon thread."
@daemon_thread = Thread.new do
begin
server = WEBrick::HTTPServer.new ({:Port => @PORT})
server.mount "/status", Status, @instruments
server.start
rescue Exception => e
logger.error "Error in worker thread: #{e.class.name}: #{e}\n
#{e.backtrace.join("\n ")}"
end # begin
end # thread new
end

other output class...

class ConsoleReporter

end
end

What do you think?

On Thu, Apr 21, 2011 at 1:43 PM, johnewart <
[email protected]>wrote:

Exactly -- it seems like they should all just channel through one place to
keep things tidy. Thanks for this!

Reply to this email directly or view it on GitHub:
#15 (comment)

[johnewart]

Ian, Matt was working on some integration changes so I was waiting for those to be ready before I responded. Take a look at the new code in lib/ruby-metrics/integration/webrick.rb for how the webrick integration mechanism works and mimic that for your console output. Matt's changes are similar to the ones you proposed in that it generalizes the metrics output interface.

I think that a console logger will be a great feature for dumping to the console and files easily!

Thanks again!

[ianzy]

Sure, I will look into that.

Ian

On Tue, Apr 26, 2011 at 10:43 AM, johnewart <
[email protected]>wrote:

Ian, Matt was working on some integration changes so I was waiting for
those to be ready before I responded. Take a look at the new code in
lib/ruby-metrics/integration/webrick.rb for how the webrick integration
mechanism works and mimic that for your console output. Matt's changes are
similar to the ones you proposed in that it generalizes the metrics output
interface.

I think that a console logger will be a great feature for dumping to the
console and files easily!

Thanks again!

Reply to this email directly or view it on GitHub:
#15 (comment)

[mtodd]

So I had the idea that metrics would be either consumed or published. Consuming includes the webrick where outside agents (processes or humans) can query for them. Publishing include something like this, maybe publishing to an AMQP queue, log files, etc.

`collectd' would consume the data from the processes, etc.

I'd like something that is generic enough where whatever needs to be published to or consumed by it requires a consistent but simple interface to make happen. I can also see multiple of these producers being active: the middleware for visual checking but publishing to a backend for aggregation.

The design I went with for the integration modules was that the agent was passed around since it contains the data and then it was queried for the data when needed. So the Rack endpoint just returned the JSON version of the metrics, and another module could publish to its own output channel with the same agent.

So, this could easily just be another way to integrate the metrics into the application and could belong in the integration batch. But this may the an opportunity to take a step back and make a good design for this type of publishing/consuming model.

What do you think?