<?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: Choosing an approach for sending metrics to Splunk in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/Choosing-an-approach-for-sending-metrics-to-Splunk/m-p/344311#M63344</link>
    <description>&lt;P&gt;Well, first ill comment on #3...&lt;/P&gt;

&lt;P&gt;TCP is a transport, and HTTP is an application on top of the Transport.. HTTP/S is over TCP. This is how the OSI model works ( 7 layers of the OSI, Google that and you’ll get a better feeling for what this means.)&lt;/P&gt;

&lt;P&gt;Now the meat of your question..&lt;/P&gt;

&lt;P&gt;Typically microservices provide some sort of logging out facitility, syslog is common, but some form of JSON out over HTTP is more prevalent. This is where the Splunk HEC comes into play. We have the capability to listen over HTTP/S and collect events in raw or JSON format and index them, in the same manner we would with a UF installed and reading a file.&lt;/P&gt;

&lt;P&gt;I would look at this as an option for a microservice based world. As you mention, installing a UF requires some type of application footprint ( memory / cpu / storage.) Where as a logging endpoint is typically just a configuration setting, Awesome stuff! &lt;/P&gt;

&lt;P&gt;REST API is another option, I don’t have a lot of thoughts on this except that customers at large scale are or pushing TBs+ of data per day over HEC or UF, and not REST... REST would entail writing some custom apps via shell or SDK though. While doable, HEC is much better suited here..&lt;/P&gt;</description>
    <pubDate>Mon, 06 Nov 2017 15:21:15 GMT</pubDate>
    <dc:creator>esix_splunk</dc:creator>
    <dc:date>2017-11-06T15:21:15Z</dc:date>
    <item>
      <title>Choosing an approach for sending metrics to Splunk</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Choosing-an-approach-for-sending-metrics-to-Splunk/m-p/344310#M63343</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;

&lt;P&gt;I have just started exploring Splunk.&lt;/P&gt;

&lt;P&gt;My requirement is to capture metrics from the a set of micro services running in our environment.&lt;/P&gt;

&lt;P&gt;I see splunk provides multiple options for this. I am not clear  which one is the right one to use.&lt;/P&gt;

&lt;OL&gt;
&lt;LI&gt; I see REST API exposed by Splunk with  endpoints for both CollectD and   StatsD line protocols.&lt;/LI&gt;
&lt;LI&gt; Also I see there is a Universal   forwarder which needs to be installed  in the different host machines and
 that will forward to splunk indexer.  I feel installing a forwarder on all machines might be a constraint but  might have better 
 performance but,  I  am not sure how we can send metrics  to Universal Forwarder.  Is there a  REST API for that.&lt;/LI&gt;
&lt;LI&gt;Also, there is an option to use TCP instead of HTTP. I am also not sure how I can send using TCP.  Also, would TCP give better 
performance than HTTP.&lt;/LI&gt;
&lt;/OL&gt;

&lt;P&gt;Can someone please guide me on the right approach for the right scenario?&lt;/P&gt;</description>
      <pubDate>Mon, 06 Nov 2017 11:45:51 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Choosing-an-approach-for-sending-metrics-to-Splunk/m-p/344310#M63343</guid>
      <dc:creator>sri420</dc:creator>
      <dc:date>2017-11-06T11:45:51Z</dc:date>
    </item>
    <item>
      <title>Re: Choosing an approach for sending metrics to Splunk</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Choosing-an-approach-for-sending-metrics-to-Splunk/m-p/344311#M63344</link>
      <description>&lt;P&gt;Well, first ill comment on #3...&lt;/P&gt;

&lt;P&gt;TCP is a transport, and HTTP is an application on top of the Transport.. HTTP/S is over TCP. This is how the OSI model works ( 7 layers of the OSI, Google that and you’ll get a better feeling for what this means.)&lt;/P&gt;

&lt;P&gt;Now the meat of your question..&lt;/P&gt;

&lt;P&gt;Typically microservices provide some sort of logging out facitility, syslog is common, but some form of JSON out over HTTP is more prevalent. This is where the Splunk HEC comes into play. We have the capability to listen over HTTP/S and collect events in raw or JSON format and index them, in the same manner we would with a UF installed and reading a file.&lt;/P&gt;

&lt;P&gt;I would look at this as an option for a microservice based world. As you mention, installing a UF requires some type of application footprint ( memory / cpu / storage.) Where as a logging endpoint is typically just a configuration setting, Awesome stuff! &lt;/P&gt;

&lt;P&gt;REST API is another option, I don’t have a lot of thoughts on this except that customers at large scale are or pushing TBs+ of data per day over HEC or UF, and not REST... REST would entail writing some custom apps via shell or SDK though. While doable, HEC is much better suited here..&lt;/P&gt;</description>
      <pubDate>Mon, 06 Nov 2017 15:21:15 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Choosing-an-approach-for-sending-metrics-to-Splunk/m-p/344311#M63344</guid>
      <dc:creator>esix_splunk</dc:creator>
      <dc:date>2017-11-06T15:21:15Z</dc:date>
    </item>
  </channel>
</rss>

