<?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: How to ensure logs generated during Universal Forwarder upgrade are not lost or duplicated? in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/How-to-ensure-logs-generated-during-Universal-Forwarder-upgrade/m-p/306732#M57837</link>
    <description>&lt;P&gt;Not a problem, you can send feedback to the documentation team if it is not clear enough, they are usually happy to take feedback...&lt;/P&gt;</description>
    <pubDate>Tue, 23 May 2017 23:33:39 GMT</pubDate>
    <dc:creator>gjanders</dc:creator>
    <dc:date>2017-05-23T23:33:39Z</dc:date>
    <item>
      <title>How to ensure logs generated during Universal Forwarder upgrade are not lost or duplicated?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/How-to-ensure-logs-generated-during-Universal-Forwarder-upgrade/m-p/306729#M57834</link>
      <description>&lt;P&gt;We are about to upgrade several hundred Universal Forwarders (UF) in our environment. We want to make sure that any logs that were generated during the upgrade of the UF would not be lost or duplicated. I did find info on  &lt;CODE&gt;current_only&lt;/CODE&gt;, however it seem this is only for the &lt;STRONG&gt;&lt;EM&gt;Windows Event Log Monitor&lt;/EM&gt;&lt;/STRONG&gt;, and not the &lt;STRONG&gt;&lt;EM&gt;MONITOR:&lt;/EM&gt;&lt;/STRONG&gt;. &lt;/P&gt;

&lt;P&gt;Is there anything we need to make sure we have in place? &lt;/P&gt;

&lt;P&gt;How will the UF know where the old version left off?&lt;/P&gt;

&lt;P&gt;I have tried to look this up, but with all the posts just named &lt;EM&gt;Universal Forwarder&lt;/EM&gt;, I could have overlooked if this has been asked before.&lt;/P&gt;</description>
      <pubDate>Mon, 22 May 2017 16:24:55 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/How-to-ensure-logs-generated-during-Universal-Forwarder-upgrade/m-p/306729#M57834</guid>
      <dc:creator>cboillot</dc:creator>
      <dc:date>2017-05-22T16:24:55Z</dc:date>
    </item>
    <item>
      <title>Re: How to ensure logs generated during Universal Forwarder upgrade are not lost or duplicated?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/How-to-ensure-logs-generated-during-Universal-Forwarder-upgrade/m-p/306730#M57835</link>
      <description>&lt;P&gt;What you are referring to is inbuilt Splunk functionality, as per &lt;A href="https://docs.splunk.com/Documentation/Splunk/6.6.0/Data/Monitorfilesanddirectories"&gt;Monitor files and directories&lt;/A&gt; &lt;/P&gt;

&lt;BLOCKQUOTE&gt;
&lt;P&gt;When the Splunk server is restarted,&lt;BR /&gt;
it continues processing files where it&lt;BR /&gt;
left off. It first checks for the file&lt;BR /&gt;
or directory specified in a monitor&lt;BR /&gt;
configuration. If the file or&lt;BR /&gt;
directory is not present on start,&lt;BR /&gt;
Splunk Enterprise checks for it every&lt;BR /&gt;
24 hours from the time of the last&lt;BR /&gt;
restart. The monitor process scans&lt;BR /&gt;
subdirectories of monitored&lt;BR /&gt;
directories continuously.&lt;/P&gt;
&lt;/BLOCKQUOTE&gt;

&lt;P&gt;Effectively Splunk keeps a checkpoint of where it got to in a file in the fishbucket (an internal filestore within the forwarder), so unless your wiping out the Splunk installation directory an upgrade will not cause any issues as the files will not be deleted by upgrades.&lt;/P&gt;

&lt;P&gt;You do have some controls around determining if the file has been seen before in the &lt;A href="https://docs.splunk.com/Documentation/Splunk/6.6.0/Admin/Inputsconf"&gt;inputs.conf&lt;/A&gt; , in particular refer to initCrcLength . You only need to adjust this if you see issues in the splunkd.log from the forwarder, by default this functionality should just work!&lt;/P&gt;</description>
      <pubDate>Mon, 22 May 2017 23:06:18 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/How-to-ensure-logs-generated-during-Universal-Forwarder-upgrade/m-p/306730#M57835</guid>
      <dc:creator>gjanders</dc:creator>
      <dc:date>2017-05-22T23:06:18Z</dc:date>
    </item>
    <item>
      <title>Re: How to ensure logs generated during Universal Forwarder upgrade are not lost or duplicated?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/How-to-ensure-logs-generated-during-Universal-Forwarder-upgrade/m-p/306731#M57836</link>
      <description>&lt;P&gt;Thank you! This is what I thought, but was asked to get verification.&lt;/P&gt;</description>
      <pubDate>Tue, 23 May 2017 13:08:28 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/How-to-ensure-logs-generated-during-Universal-Forwarder-upgrade/m-p/306731#M57836</guid>
      <dc:creator>cboillot</dc:creator>
      <dc:date>2017-05-23T13:08:28Z</dc:date>
    </item>
    <item>
      <title>Re: How to ensure logs generated during Universal Forwarder upgrade are not lost or duplicated?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/How-to-ensure-logs-generated-during-Universal-Forwarder-upgrade/m-p/306732#M57837</link>
      <description>&lt;P&gt;Not a problem, you can send feedback to the documentation team if it is not clear enough, they are usually happy to take feedback...&lt;/P&gt;</description>
      <pubDate>Tue, 23 May 2017 23:33:39 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/How-to-ensure-logs-generated-during-Universal-Forwarder-upgrade/m-p/306732#M57837</guid>
      <dc:creator>gjanders</dc:creator>
      <dc:date>2017-05-23T23:33:39Z</dc:date>
    </item>
  </channel>
</rss>

