Flume, mail # user - Re: Embedded Agent vs Client SDK - 2014-02-14, 04:34
 Search Hadoop and all its subprojects:

Switch to Threaded View
Copy link to this message
Re: Embedded Agent vs Client SDK

I'm going to just quote the design doc here:


1. A Flume Embedded agent would be useful to applications which send
data to a Flume agent acting as a "collector". Currently using the
RPCClient or HTTPSource, if there is a burst of events or the
collector is unavailable the application is responsible for queueing
the events. By embedding a Flume agent the application would be
configured with a Flume channel alleviating the need to buff�er in the
client application.

2. A similar but su�fficiently diff�erent use case would be to replace
a Flume agent deployed on the source system. In some environments
Flume agents maybe deployed on the source systems simply to have a
buff�er crossing the network boundry. In these scenarios the amount of
work on the operations team could be reduced by simply embedding a
simple agent in the source application. In a similar vane,there are
environments where deploying anything but a J2EE application on
application servers is troublesome.

They are both should be relatively simple to implement.
Hope this helps.


On Thu, Feb 13, 2014 at 8:14 PM, Gary Malouf <[EMAIL PROTECTED]> wrote:

NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB