<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Forwarding events - Splunk stopps working when endpoint is not available in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/Forwarding-events-Splunk-stopps-working-when-endpoint-is-not/m-p/231055#M44975</link>
    <description>&lt;P&gt;If you take a look at this diagram:&lt;/P&gt;

&lt;P&gt;&lt;A href="https://wiki.splunk.com/Community:HowIndexingWorks"&gt;https://wiki.splunk.com/Community:HowIndexingWorks&lt;/A&gt;   &lt;/P&gt;

&lt;P&gt;"3. Detail Diagram - Standalone Splunk"&lt;/P&gt;

&lt;P&gt;You can see how the flow works.  When Splunk is unable to communicate with a 3rd party system the queue fills up, which causes us to start filling up in the pipeline going backwards to the point where eventually we no longer accept any new data, as we can't do anything with the data we have.&lt;/P&gt;

&lt;P&gt;2 of the main reasons why indexers stop indexing is because of:&lt;BR /&gt;
    1. We have an indexing loop.  E.G. an outputs that is configured to forward data to another indexer, and back&lt;BR /&gt;
     2. Forwarding of data configured to send to a 3rd party and there is an issue with the upstream system.&lt;/P&gt;

&lt;P&gt;You could play around with these settings out of outputs.conf, although these are just ideas and may not solve your issue / use case depending on how important it is that you get the data at the 3rd party:&lt;/P&gt;

&lt;P&gt;dropEventsOnQueueFull = &lt;BR /&gt;
* If set to a positive number, wait  seconds before throwing out&lt;BR /&gt;
  all new events until the output queue has space.&lt;BR /&gt;
* Setting this to -1 or 0 will cause the output queue to block when it gets&lt;BR /&gt;
  full, causing further blocking up the processing chain.&lt;BR /&gt;
* If any target group's queue is blocked, no more data will reach any other&lt;BR /&gt;
  target group.&lt;BR /&gt;
* Using auto load-balancing is the best way to minimize this condition,&lt;BR /&gt;
  because, in that case, multiple receivers must be down (or jammed up)&lt;BR /&gt;
  before queue blocking can occur.&lt;BR /&gt;
* Defaults to -1 (do not drop events).&lt;BR /&gt;
* DO NOT SET THIS VALUE TO A POSITIVE INTEGER IF YOU ARE MONITORING FILES!&lt;/P&gt;

&lt;P&gt;dropClonedEventsOnQueueFull = &lt;BR /&gt;
* If set to a positive number, do not block completely, but wait up to&lt;BR /&gt;
   seconds to queue events to a group. If it cannot enqueue to a&lt;BR /&gt;
  group for more than  seconds, begin dropping events for the&lt;BR /&gt;
  group. It makes sure that at least one group in the cloning configuration&lt;BR /&gt;
  will get events. It blocks if event cannot be delivered to any of the&lt;BR /&gt;
  cloned groups.&lt;BR /&gt;
* If set to -1, the TcpOutputProcessor will make sure that each group will&lt;BR /&gt;
  get all of the events.  If one of the groups is down, then Splunk will&lt;BR /&gt;
  block everything.&lt;BR /&gt;
* Defaults to 5.&lt;/P&gt;

&lt;P&gt;Others might recommend to increase the queue size, but if the 3rd party is down for an extended period of time the same issue will occur.&lt;/P&gt;

&lt;P&gt;You best bet is to figure out why the thrid party system is not taking data and fix that so it is more reliable.&lt;/P&gt;</description>
    <pubDate>Tue, 17 Jan 2017 13:30:31 GMT</pubDate>
    <dc:creator>jwelch_splunk</dc:creator>
    <dc:date>2017-01-17T13:30:31Z</dc:date>
    <item>
      <title>Forwarding events - Splunk stopps working when endpoint is not available</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Forwarding-events-Splunk-stopps-working-when-endpoint-is-not/m-p/231054#M44974</link>
      <description>&lt;P&gt;Hello&lt;/P&gt;

&lt;P&gt;We forward events using the outputs.conf on the indexers:&lt;/P&gt;

&lt;P&gt;&lt;STRONG&gt;outputs.conf&lt;/STRONG&gt;&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;[tcpout] 
defaultGroup = default 
disabled = 0 
indexAndForward = 1 

[tcpout-server://x.x.x.x:601]
[tcpout:default] 
disabled = 0 
server = x.x.x.x:601
sendCookedData = false
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;When the endpoint (x.x.x.x) is not available splunk stopps all listeners:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;12-21-2016 12:02:45.982 +0100 WARN  TcpOutputProc - Write operation timed out for 10.128.16.36:601 in 300 seconds.
12-21-2016 12:02:45.982 +0100 INFO  TcpOutputProc - Connected to idx=10.128.16.36:601
12-21-2016 12:02:45.982 +0100 WARN  TcpOutputProc - Forwarding to indexer group default blocked for 300 seconds.
12-21-2016 12:02:56.871 +0100 INFO  TcpInputProc - Stopping IPv4 port 514
12-21-2016 12:02:56.871 +0100 INFO  TcpInputProc - Stopping IPv4 port 1514
12-21-2016 12:02:56.871 +0100 INFO  TcpInputProc - Stopping IPv4 port 2514
12-21-2016 12:02:56.871 +0100 INFO  TcpInputProc - Stopping IPv4 port 4514
12-21-2016 12:02:56.871 +0100 INFO  TcpInputProc - Stopping IPv4 port 5514
12-21-2016 12:02:56.871 +0100 INFO  TcpInputProc - Stopping IPv4 port 3514
12-21-2016 12:02:56.871 +0100 INFO  TcpInputProc - Stopping IPv4 port 9997
12-21-2016 12:02:56.871 +0100 WARN  TcpInputProc - Stopping all listening ports. Queues blocked for more than 300 seconds
12-21-2016 12:03:11.816 +0100 WARN  TcpOutputProc - Forwarding to indexer group default blocked for 400 seconds.
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;I don't know why this happens. Any hints?&lt;/P&gt;

&lt;P&gt;Thanks &amp;amp; Regards&lt;BR /&gt;
Nicolas&lt;/P&gt;</description>
      <pubDate>Tue, 17 Jan 2017 12:50:04 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Forwarding-events-Splunk-stopps-working-when-endpoint-is-not/m-p/231054#M44974</guid>
      <dc:creator>nicocin</dc:creator>
      <dc:date>2017-01-17T12:50:04Z</dc:date>
    </item>
    <item>
      <title>Re: Forwarding events - Splunk stopps working when endpoint is not available</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Forwarding-events-Splunk-stopps-working-when-endpoint-is-not/m-p/231055#M44975</link>
      <description>&lt;P&gt;If you take a look at this diagram:&lt;/P&gt;

&lt;P&gt;&lt;A href="https://wiki.splunk.com/Community:HowIndexingWorks"&gt;https://wiki.splunk.com/Community:HowIndexingWorks&lt;/A&gt;   &lt;/P&gt;

&lt;P&gt;"3. Detail Diagram - Standalone Splunk"&lt;/P&gt;

&lt;P&gt;You can see how the flow works.  When Splunk is unable to communicate with a 3rd party system the queue fills up, which causes us to start filling up in the pipeline going backwards to the point where eventually we no longer accept any new data, as we can't do anything with the data we have.&lt;/P&gt;

&lt;P&gt;2 of the main reasons why indexers stop indexing is because of:&lt;BR /&gt;
    1. We have an indexing loop.  E.G. an outputs that is configured to forward data to another indexer, and back&lt;BR /&gt;
     2. Forwarding of data configured to send to a 3rd party and there is an issue with the upstream system.&lt;/P&gt;

&lt;P&gt;You could play around with these settings out of outputs.conf, although these are just ideas and may not solve your issue / use case depending on how important it is that you get the data at the 3rd party:&lt;/P&gt;

&lt;P&gt;dropEventsOnQueueFull = &lt;BR /&gt;
* If set to a positive number, wait  seconds before throwing out&lt;BR /&gt;
  all new events until the output queue has space.&lt;BR /&gt;
* Setting this to -1 or 0 will cause the output queue to block when it gets&lt;BR /&gt;
  full, causing further blocking up the processing chain.&lt;BR /&gt;
* If any target group's queue is blocked, no more data will reach any other&lt;BR /&gt;
  target group.&lt;BR /&gt;
* Using auto load-balancing is the best way to minimize this condition,&lt;BR /&gt;
  because, in that case, multiple receivers must be down (or jammed up)&lt;BR /&gt;
  before queue blocking can occur.&lt;BR /&gt;
* Defaults to -1 (do not drop events).&lt;BR /&gt;
* DO NOT SET THIS VALUE TO A POSITIVE INTEGER IF YOU ARE MONITORING FILES!&lt;/P&gt;

&lt;P&gt;dropClonedEventsOnQueueFull = &lt;BR /&gt;
* If set to a positive number, do not block completely, but wait up to&lt;BR /&gt;
   seconds to queue events to a group. If it cannot enqueue to a&lt;BR /&gt;
  group for more than  seconds, begin dropping events for the&lt;BR /&gt;
  group. It makes sure that at least one group in the cloning configuration&lt;BR /&gt;
  will get events. It blocks if event cannot be delivered to any of the&lt;BR /&gt;
  cloned groups.&lt;BR /&gt;
* If set to -1, the TcpOutputProcessor will make sure that each group will&lt;BR /&gt;
  get all of the events.  If one of the groups is down, then Splunk will&lt;BR /&gt;
  block everything.&lt;BR /&gt;
* Defaults to 5.&lt;/P&gt;

&lt;P&gt;Others might recommend to increase the queue size, but if the 3rd party is down for an extended period of time the same issue will occur.&lt;/P&gt;

&lt;P&gt;You best bet is to figure out why the thrid party system is not taking data and fix that so it is more reliable.&lt;/P&gt;</description>
      <pubDate>Tue, 17 Jan 2017 13:30:31 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Forwarding-events-Splunk-stopps-working-when-endpoint-is-not/m-p/231055#M44975</guid>
      <dc:creator>jwelch_splunk</dc:creator>
      <dc:date>2017-01-17T13:30:31Z</dc:date>
    </item>
  </channel>
</rss>

