<?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: REST Api / Input Data / Multiple Indexers in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/REST-Api-Input-Data-Multiple-Indexers/m-p/67287#M13524</link>
    <description>&lt;P&gt;Thanks for the inputs.  Your answer answered another one of my question.  I was seeing very uneven indexing (in terms of volume of data indexed) across my two indexers even when all my forwarders know about both the indexers.  I think that what is happening is that one of my job servers (which is a heavy forwarder) runs scripted inputs and transfers large volumes of data into indexer.&lt;/P&gt;</description>
    <pubDate>Wed, 19 Dec 2012 23:39:07 GMT</pubDate>
    <dc:creator>adoshi</dc:creator>
    <dc:date>2012-12-19T23:39:07Z</dc:date>
    <item>
      <title>REST Api / Input Data / Multiple Indexers</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/REST-Api-Input-Data-Multiple-Indexers/m-p/67282#M13519</link>
      <description>&lt;P&gt;I have multiple indexers in production and I would like to use the rest api to input data using receivers/stream. &lt;/P&gt;

&lt;P&gt;The question I have is - should I send the rest api data to a forwarder which would then forward it to all the indexers ?  Or Can I only send the data to one indexer this way?&lt;/P&gt;</description>
      <pubDate>Tue, 18 Dec 2012 18:56:13 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/REST-Api-Input-Data-Multiple-Indexers/m-p/67282#M13519</guid>
      <dc:creator>adoshi</dc:creator>
      <dc:date>2012-12-18T18:56:13Z</dc:date>
    </item>
    <item>
      <title>Re: REST Api / Input Data / Multiple Indexers</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/REST-Api-Input-Data-Multiple-Indexers/m-p/67283#M13520</link>
      <description>&lt;P&gt;That is an architecture that I have implemented before.&lt;BR /&gt;
REST client -&amp;gt; Heavy/Light Forwarder -&amp;gt; auto load balanced into Indexer cluster.&lt;BR /&gt;
Otherwise your REST client would have to implement the auto load balancing logic itself.&lt;/P&gt;</description>
      <pubDate>Wed, 19 Dec 2012 03:09:42 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/REST-Api-Input-Data-Multiple-Indexers/m-p/67283#M13520</guid>
      <dc:creator>Damien_Dallimor</dc:creator>
      <dc:date>2012-12-19T03:09:42Z</dc:date>
    </item>
    <item>
      <title>Re: REST Api / Input Data / Multiple Indexers</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/REST-Api-Input-Data-Multiple-Indexers/m-p/67284#M13521</link>
      <description>&lt;P&gt;Using a Heavy/Light Weight forwarder in this context would insulate you against problems with an individual indexer, but it would not be a good architecture for properly load balancing across your indexers.  The forwarder will only rebalance to a new indexer every 30 seconds by default, meaning if you have only one forwarder, you'll only be intermittently loading data into each indexer.  You could create a pool of 1:1 relationship of forwarders to indexers and that would ensure all indexers were being fed data at any given time.  At that point, you're not gaining a lot from the forwarder but a smallish buffer (by default) in case the indexer is down.&lt;/P&gt;

&lt;P&gt;A better architecture would be to put a proper load balancer (F5, NetScaler, Cascade, nginx/apache in reverse proxy mode) that will offer intelligence load balancing and put that in front of splunkd.  The load balancer will have a number of available options, such as least connections, best response times, or simple round robin type load balancing methods of distributing load.  It can also be setup with a healthcheck to ensure Splunk is up and responding before sending any new connections to splunkd.&lt;/P&gt;</description>
      <pubDate>Wed, 19 Dec 2012 04:29:47 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/REST-Api-Input-Data-Multiple-Indexers/m-p/67284#M13521</guid>
      <dc:creator>csharp_splunk</dc:creator>
      <dc:date>2012-12-19T04:29:47Z</dc:date>
    </item>
    <item>
      <title>Re: REST Api / Input Data / Multiple Indexers</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/REST-Api-Input-Data-Multiple-Indexers/m-p/67285#M13522</link>
      <description>&lt;P&gt;The load balancer approach is good for tcp, splunktcp..but adoshi wants to use the receivers/stream REST endpoint to input data.So there has to be a point to point authenticated REST session between the REST client and the REST server(the forwarder in this case).You might be able to slot in a load balancer between the forwarder and the indexers however, as that traffic would be splunktcp.And the forwarder outputs.conf entry just points to the load balancers VIP.So the architecture would be : REST client -&amp;gt; Splunk Forwader -&amp;gt; Load Balancer -&amp;gt; Indexer Cluster&lt;/P&gt;</description>
      <pubDate>Wed, 19 Dec 2012 07:10:19 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/REST-Api-Input-Data-Multiple-Indexers/m-p/67285#M13522</guid>
      <dc:creator>Damien_Dallimor</dc:creator>
      <dc:date>2012-12-19T07:10:19Z</dc:date>
    </item>
    <item>
      <title>Re: REST Api / Input Data / Multiple Indexers</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/REST-Api-Input-Data-Multiple-Indexers/m-p/67286#M13523</link>
      <description>&lt;P&gt;Authentication is a good point, but I'd still recommend a load balancer approach in front of the Indexer, but just have the sessions remain sticky to one particular indexer.  If you want more distribution, have your application open multiple connections to the load balancer and you should get good distribution, even with sticky sessions.  The forwarder provides very little, if any, value in this scenario.  TCP based input will lose you a number of features, including the ability to define index/host/source/sourcetype on a per-POST basis.&lt;/P&gt;</description>
      <pubDate>Wed, 19 Dec 2012 14:47:54 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/REST-Api-Input-Data-Multiple-Indexers/m-p/67286#M13523</guid>
      <dc:creator>csharp_splunk</dc:creator>
      <dc:date>2012-12-19T14:47:54Z</dc:date>
    </item>
    <item>
      <title>Re: REST Api / Input Data / Multiple Indexers</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/REST-Api-Input-Data-Multiple-Indexers/m-p/67287#M13524</link>
      <description>&lt;P&gt;Thanks for the inputs.  Your answer answered another one of my question.  I was seeing very uneven indexing (in terms of volume of data indexed) across my two indexers even when all my forwarders know about both the indexers.  I think that what is happening is that one of my job servers (which is a heavy forwarder) runs scripted inputs and transfers large volumes of data into indexer.&lt;/P&gt;</description>
      <pubDate>Wed, 19 Dec 2012 23:39:07 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/REST-Api-Input-Data-Multiple-Indexers/m-p/67287#M13524</guid>
      <dc:creator>adoshi</dc:creator>
      <dc:date>2012-12-19T23:39:07Z</dc:date>
    </item>
    <item>
      <title>Re: REST Api / Input Data / Multiple Indexers</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/REST-Api-Input-Data-Multiple-Indexers/m-p/67288#M13525</link>
      <description>&lt;P&gt;Thanks this helps.  Can a Universal forwarder support the rest requests?&lt;/P&gt;</description>
      <pubDate>Wed, 19 Dec 2012 23:41:02 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/REST-Api-Input-Data-Multiple-Indexers/m-p/67288#M13525</guid>
      <dc:creator>adoshi</dc:creator>
      <dc:date>2012-12-19T23:41:02Z</dc:date>
    </item>
  </channel>
</rss>

