Hello, The reroute/addroute procedure was invented for such cases and it's nice to see it getting used. Adding failover support is on the roadmap, though there are various approaches that are considered: * DNS level If there are multiple IPs associated with a name, these could be used in a RR fashion. * List of names/ips in the config Similarly to the above try a list of servers in RR, though the list is provided in the config file instead of coming from DNS. * ExecOnFailure directive This would be similar to Exec, though it would be evaluated when the module is stopped (due connection errors or other failures). This would allow policy based decisions , e.g. using reroute() like in your example.
Regards, Botond On Wed, 11 Dec 2013 00:12:13 +0000 "Mitzimberg, Justin" <[email protected]> wrote: > So I've been wanting a failover solution for log receivers and currently > nxlog-ce doesn't have an answer, but I think I found a hack that might work: > the reroute() command. Here's what I did: > > The first thing that we need to do is to create the alternate route. In order > to create the route statement without errors, I created a NULL input. > Basically this route doesn't do anything until called upon later. > > <Input in_null> > Module im_null > </Input> > > <Route route_alternate> > Path in_null => out_alternative > </Route> > > The second thing we need to create is a buffer module. The buffer will sit > between the default input and the default output and act as the detection > method for problems. If the default output blocks (e.g. the tcp connection > dies), the buffer will start filling. > > <Processor buffer> > Module pm_buffer > MaxSize 2048 > Type Mem > Exec if buffer_count() > 2 reroute("route_alternative"); > </Processor> > > <Route route_default> > Path in_default => buffer => out_default > </Route> > > The EXEC statement in this block says that if the number of log entries in > the buffer exceeds a certain amount (in my test case, 2 messages), reroute > the message to the alternative path. > > With my limited testing, I see having 2 potential benefits with 1 potential > drawback. The first benefit is, of course, failover. If the default route > dies, the reroute statement will send the message elsewhere. The second > benefit is log spike protection. If a sudden spike in log messages happens > and the default route can't handle the load, the buffer will fill and the > alternative route will start processing messages. The only drawback I can see > is that there will be messages stuck in the buffer and when they finally > clear the buffer, might be late. This may cause problems with any real-time > process you may be doing on the backend (e.g. real-time alerts). > > Thoughts? > > Justin > ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ nxlog-ce-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nxlog-ce-users
