You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flume.apache.org by "Ashish Paliwal (JIRA)" <ji...@apache.org> on 2014/11/05 12:32:34 UTC

[jira] [Resolved] (FLUME-1191) Would like autoE2EChain to have the ability to handle different classes of agents

     [ https://issues.apache.org/jira/browse/FLUME-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ashish Paliwal resolved FLUME-1191.
-----------------------------------
       Resolution: Won't Fix
    Fix Version/s: v0.9.5

Won't fix. 0.X branch not maintained anymore

> Would like autoE2EChain to have the ability to handle different classes of agents
> ---------------------------------------------------------------------------------
>
>                 Key: FLUME-1191
>                 URL: https://issues.apache.org/jira/browse/FLUME-1191
>             Project: Flume
>          Issue Type: New Feature
>          Components: Sinks+Sources
>    Affects Versions: v0.9.4
>         Environment: CentOS
> Flume build:
> Flume 0.9.4-cdh3u3
> Git repository https://github.com/cloudera/flume/flume-core
>  rev unknown
> Compiled by jenkins on 20120126-1114
>            Reporter: Thomas Andrews
>             Fix For: v0.9.5
>
>
> We have an agent running on each of our servers, and our servers are writing audit data to these agents.  The agents are configured to use autoE2EChain for their sinks.
> The problem is, out of 60+ servers, five of them generate the vast majority of the traffic, and, with this many agents configured to write to our two collectors, this means that there is a high probability (about one in three) ofautoE2EChain assigning four or five of those servers to write to one collector.
> Ideally, we'd have a way to set the sink as: autoE2EChain("high-traffic") so that some 'class' of agents would be assigned to collectors separately.
> Alternatively, I suppose, autoE2EChain could pass a weight in: autoE2EChain(20).
> I realize most work on the NG Flume, so perhaps the terminology will be different there, but the idea is likely still applicable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)