Home | About | Sematext search-lucene.com search-hadoop.com
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
 Search Hadoop and all its subprojects:

Switch to Threaded View
Flume >> mail # user >> Embedded Agent vs Client SDK


Copy link to this message
-
Re: Embedded Agent vs Client SDK
Gary,

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

https://issues.apache.org/jira/secure/attachment/12560587/embedded-agent-3.pdf

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.

Best,

Jeff
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