<?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: Splunk stop to process syslog messages every 7 days in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/Splunk-stop-to-process-syslog-messages-every-7-days/m-p/110646#M23232</link>
    <description>&lt;P&gt;thanks for your answer. for example, this is what was sent by the router, as the one event:&lt;/P&gt;

&lt;P&gt;Jan 14 10:26:21: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed&lt;BR /&gt;
        connection id=489, sequence number=1252&lt;/P&gt;

&lt;P&gt;And processed by the Splunk as the 3 events:&lt;BR /&gt;
_raw&lt;BR /&gt;
&amp;lt;140&amp;gt;2018: &lt;BR /&gt;
&amp;lt;140&amp;gt;2017:  connection id=489, sequence number=1252"&lt;BR /&gt;
&amp;lt;140&amp;gt;2016: Jan 14 10:26:21: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed&lt;/P&gt;

&lt;P&gt;So seems that router itself send wrong format of the syslog message. &lt;BR /&gt;
How can i protect it on the Splunk side, to either ignore it or process it ?&lt;/P&gt;

&lt;P&gt;Thanks&lt;/P&gt;</description>
    <pubDate>Mon, 28 Sep 2020 15:39:01 GMT</pubDate>
    <dc:creator>petpet</dc:creator>
    <dc:date>2020-09-28T15:39:01Z</dc:date>
    <item>
      <title>Splunk stop to process syslog messages every 7 days</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Splunk-stop-to-process-syslog-messages-every-7-days/m-p/110642#M23228</link>
      <description>&lt;P&gt;Hi &lt;BR /&gt;
i noticed that every seven days at 4:03 ( of the local time )splunk stop to process Syslog messages. then i need to restart the splunk and it start again.&lt;BR /&gt;
here is the excerpt log of the splunkd.log, when it stopped and when i restart it:&lt;/P&gt;

&lt;P&gt;1-11-2014 23:00:06.249 +0100 WARN  DateParserVerbose - Failed to parse timestamp. Defaulting to timestamp of previous event (Sat Jan 11 23:00:05 2014). Context: source::Syslog|host::10.255.196.2|syslog|&lt;BR /&gt;
01-11-2014 23:04:06.251 +0100 WARN  DateParserVerbose - Failed to parse timestamp. Defaulting to timestamp of previous event (Sat Jan 11 23:04:05 2014). Context: source::Syslog|host::10.255.196.2|syslog|&lt;BR /&gt;
01-11-2014 23:23:17.335 +0100 WARN  DateParserVerbose - Failed to parse timestamp. Defaulting to timestamp of previous event (Sat Jan 11 19:23:16 2014). Context: source::Syslog|host::10.27.1.3|syslog|&lt;BR /&gt;
01-11-2014 23:28:28.082 +0100 WARN  DateParserVerbose - Failed to parse timestamp. Defaulting to timestamp of previous event (Sat Jan 11 19:28:26 2014). Context: source::Syslog|host::10.27.1.3|syslog|&lt;BR /&gt;
01-12-2014 00:00:00.984 +0100 INFO  LMStackMgr - should rollover=true because _lastRolloverTime=1389394800 lastRolloverDay=1389394800 snappedNow=1389481200&lt;BR /&gt;
01-12-2014 00:00:00.985 +0100 INFO  LMStackMgr - quotaExceededCount=0, lastExceedDate=0, peak=23676253, rolloverCount=6, totalCumulativeBytesAtRollover=23676253, todaysBytesIndexed=23676253, licenseSize=524288000&lt;BR /&gt;
01-12-2014 00:00:00.985 +0100 INFO  LMStackMgr - finished rollover, new lastRolloverTime=1389481200&lt;BR /&gt;
01-12-2014 00:00:41.985 +0100 INFO  LMSlaveInfo - Detected that masterTimeFromSlave(Sat Jan 11 23:59:41 2014) &amp;lt; lastRolloverTime(Sun Jan 12 00:00:00 2014), meaning that the master has already rolled over. Ignore slave persisted usage.&lt;BR /&gt;
01-12-2014 00:12:43.985 +0100 WARN  DateParserVerbose - Failed to parse timestamp. Defaulting to timestamp of previous event (Sat Jan 11 20:12:42 2014). Context: source::Syslog|host::10.27.1.3|syslog|&lt;BR /&gt;
01-12-2014 00:14:08.058 +0100 WARN  DateParserVerbose - Failed to parse timestamp. Defaulting to timestamp of previous event (Sat Jan 11 20:14:06 2014). Context: source::Syslog|host::10.27.1.3|syslog|&lt;BR /&gt;
01-12-2014 01:07:35.661 +0100 INFO  WatchedFile - Will begin reading at offset=0 for file='/opt/splunk/var/log/splunk/metrics.log'.&lt;BR /&gt;
01-12-2014 01:07:35.702 +0100 INFO  WatchedFile - Will begin reading at offset=24996941 for file='/opt/splunk/var/log/splunk/metrics.log.1'.&lt;BR /&gt;
01-12-2014 02:08:48.264 +0100 WARN  DateParserVerbose - Failed to parse timestamp. Defaulting to timestamp of previous event (Sat Jan 11 22:08:47 2014). Context: source::Syslog|host::10.27.1.3|syslog|&lt;BR /&gt;
01-12-2014 02:12:06.816 +0100 WARN  DateParserVerbose - Failed to parse timestamp. Defaulting to timestamp of previous event (Sat Jan 11 22:12:05 2014). Context: source::Syslog|host::10.27.1.3|syslog|&lt;BR /&gt;
01-12-2014 02:13:14.933 +0100 WARN  DateParserVerbose - Failed to parse timestamp. Defaulting to timestamp of previous event (Sat Jan 11 22:13:13 2014). Context: source::Syslog|host::10.27.1.3|syslog|&lt;BR /&gt;
01-12-2014 02:21:28.954 +0100 WARN  DateParserVerbose - Failed to parse timestamp. Defaulting to timestamp of previous event (Sat Jan 11 22:21:27 2014). Context: source::Syslog|host::10.27.1.3|syslog|&lt;BR /&gt;
01-12-2014 22:36:40.895 +0100 INFO  WatchedFile - Will begin reading at offset=0 for file='/opt/splunk/var/log/splunk/metrics.log'.&lt;BR /&gt;
01-12-2014 22:36:40.897 +0100 INFO  WatchedFile - Will begin reading at offset=24992775 for file='/opt/splunk/var/log/splunk/metrics.log.1'.&lt;BR /&gt;
01-13-2014 00:00:00.984 +0100 INFO  LMStackMgr - should rollover=true because _lastRolloverTime=1389481200 lastRolloverDay=1389481200 snappedNow=1389567600&lt;BR /&gt;
01-13-2014 00:00:00.985 +0100 INFO  LMStackMgr - quotaExceededCount=0, lastExceedDate=0, peak=4747595, rolloverCount=7, totalCumulativeBytesAtRollover=4747595, todaysBytesIndexed=4747595, licenseSize=524288000&lt;/P&gt;

&lt;P&gt;Many thanks for any advice&lt;/P&gt;

&lt;P&gt;Peter&lt;/P&gt;</description>
      <pubDate>Mon, 13 Jan 2014 10:50:21 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Splunk-stop-to-process-syslog-messages-every-7-days/m-p/110642#M23228</guid>
      <dc:creator>petpet</dc:creator>
      <dc:date>2014-01-13T10:50:21Z</dc:date>
    </item>
    <item>
      <title>Re: Splunk stop to process syslog messages every 7 days</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Splunk-stop-to-process-syslog-messages-every-7-days/m-p/110643#M23229</link>
      <description>&lt;P&gt;Those DateParser messages don't look good. Improper timestamp parsing can cause various problems. My advice is to fix that first of all before doing any further troubleshooting.&lt;/P&gt;</description>
      <pubDate>Mon, 13 Jan 2014 11:50:55 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Splunk-stop-to-process-syslog-messages-every-7-days/m-p/110643#M23229</guid>
      <dc:creator>Ayn</dc:creator>
      <dc:date>2014-01-13T11:50:55Z</dc:date>
    </item>
    <item>
      <title>Re: Splunk stop to process syslog messages every 7 days</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Splunk-stop-to-process-syslog-messages-every-7-days/m-p/110644#M23230</link>
      <description>&lt;P&gt;thank you for the answer&lt;BR /&gt;
what does it mean to fix the timestamp parsing ? &lt;BR /&gt;
I'm collecting the syslog messages from the routers from around the world from different timezones&lt;BR /&gt;
I'm using newest default Splunk installation, just created new data source name Syslog &lt;/P&gt;

&lt;P&gt;thanks&lt;/P&gt;</description>
      <pubDate>Mon, 13 Jan 2014 13:49:43 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Splunk-stop-to-process-syslog-messages-every-7-days/m-p/110644#M23230</guid>
      <dc:creator>petpet</dc:creator>
      <dc:date>2014-01-13T13:49:43Z</dc:date>
    </item>
    <item>
      <title>Re: Splunk stop to process syslog messages every 7 days</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Splunk-stop-to-process-syslog-messages-every-7-days/m-p/110645#M23231</link>
      <description>&lt;P&gt;To check the timestamp parsing.&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;Export a sample of the events in a file on the search-head, and index them using the data preview.
Apply the syslog sourcetype, verify the timestamp extraction.&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;FYI, syslog events are supposed to be single line events, starting with a timestamp, then the host, then the events.&lt;/P&gt;

&lt;P&gt;Verify that your data is actual syslog format (check that the host present and correctly extracted from the events.&lt;BR /&gt;
If your events are not all syslog, use a different sourcetype.&lt;BR /&gt;
The best solution is to create multiple listening ports, one for each format, and redirect your devices to the correct port.&lt;/P&gt;</description>
      <pubDate>Mon, 13 Jan 2014 19:20:06 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Splunk-stop-to-process-syslog-messages-every-7-days/m-p/110645#M23231</guid>
      <dc:creator>yannK</dc:creator>
      <dc:date>2014-01-13T19:20:06Z</dc:date>
    </item>
    <item>
      <title>Re: Splunk stop to process syslog messages every 7 days</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Splunk-stop-to-process-syslog-messages-every-7-days/m-p/110646#M23232</link>
      <description>&lt;P&gt;thanks for your answer. for example, this is what was sent by the router, as the one event:&lt;/P&gt;

&lt;P&gt;Jan 14 10:26:21: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed&lt;BR /&gt;
        connection id=489, sequence number=1252&lt;/P&gt;

&lt;P&gt;And processed by the Splunk as the 3 events:&lt;BR /&gt;
_raw&lt;BR /&gt;
&amp;lt;140&amp;gt;2018: &lt;BR /&gt;
&amp;lt;140&amp;gt;2017:  connection id=489, sequence number=1252"&lt;BR /&gt;
&amp;lt;140&amp;gt;2016: Jan 14 10:26:21: %CRYPTO-4-PKT_REPLAY_ERR: decrypt: replay check failed&lt;/P&gt;

&lt;P&gt;So seems that router itself send wrong format of the syslog message. &lt;BR /&gt;
How can i protect it on the Splunk side, to either ignore it or process it ?&lt;/P&gt;

&lt;P&gt;Thanks&lt;/P&gt;</description>
      <pubDate>Mon, 28 Sep 2020 15:39:01 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Splunk-stop-to-process-syslog-messages-every-7-days/m-p/110646#M23232</guid>
      <dc:creator>petpet</dc:creator>
      <dc:date>2020-09-28T15:39:01Z</dc:date>
    </item>
    <item>
      <title>Re: Splunk stop to process syslog messages every 7 days</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Splunk-stop-to-process-syslog-messages-every-7-days/m-p/110647#M23233</link>
      <description>&lt;P&gt;Hi&lt;BR /&gt;
actually i was not able to fix the wrong messages from the Cisco routers, however this is still strange why the Splunk stops to process Syslog events every 7 days at 4:03 AM.&lt;BR /&gt;
Of course there is a solution to set the corn to restart the splunk at 4:05 AM, however i think there must be something more than the parsers&lt;BR /&gt;
thanks for any hint &lt;/P&gt;</description>
      <pubDate>Mon, 10 Feb 2014 09:23:52 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Splunk-stop-to-process-syslog-messages-every-7-days/m-p/110647#M23233</guid>
      <dc:creator>petpet</dc:creator>
      <dc:date>2014-02-10T09:23:52Z</dc:date>
    </item>
  </channel>
</rss>

