<?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 Splunk unexpected timestamp parsing behavior in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/Splunk-unexpected-timestamp-parsing-behavior/m-p/461612#M79648</link>
    <description>&lt;P&gt;Greetings,&lt;/P&gt;

&lt;P&gt;In my environment, I have set up an Universal Forwarder that is monitoring a single server .log file, which is then forwarded to a Splunk indexer instance for parsing etc. as a specific sourcetype(log4j). My Universal Forwarder configuration is as follows: &lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;inputs.conf
[default]
host = 1
[monitor://server.log]
sourcetype=log4j
index= targetIndex
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;On the indexer, I have noticed several issues, both with timestamp parsing and event breaking. As you can see in the following image, there are events mixed in with local timestamps dating 3 hours ago, but Splunk has assigned the current time for said event. On top of that, Splunk has made a separate event for the Headers: and Payload:  entries, which should have been a part of the event below. Note that these events all come from the same host and all have the same sourcetype. &lt;span class="lia-inline-image-display-wrapper" image-alt="alt text"&gt;&lt;img src="https://community.splunk.com/t5/image/serverpage/image-id/7573i56C569B95F1481A5/image-size/large?v=v2&amp;amp;px=999" role="button" title="alt text" alt="alt text" /&gt;&lt;/span&gt;&lt;BR /&gt;
For additional context, the following image visualizes the format of the .log file as seen on the forwarding instance. Note how there is a slight gap between the second event's Content-Type and Headers fields, which, I believe, is what is causing Splunk to assign it to a separate event.&lt;BR /&gt;
 &lt;span class="lia-inline-image-display-wrapper" image-alt="alt text"&gt;&lt;img src="https://community.splunk.com/t5/image/serverpage/image-id/7574i1F40E04CDAB5705F/image-size/large?v=v2&amp;amp;px=999" role="button" title="alt text" alt="alt text" /&gt;&lt;/span&gt;&lt;/P&gt;

&lt;P&gt;Here is the props.conf that I currently have set on my indexer instance:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;[log4j]
BREAK_ONLY_BEFORE=\d\d\d\d-\d\d-\d\d\s\d\d:\d\d:\d\d.\d\d\d
MAX_TIMESTAMP_LOOKAHEAD=23
TZ=Europe/Riga
TIME_FORMAT=%Y-%m-%d %H:%M:%S.%3NZ
TIME_PREFIX=^
SHOULD_LINEMERGE=true
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;As well as the limits.conf, although, to my understanding, it shouldn't affect the parsing behavior:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;limits.conf
[search]
max_rawsize_perchunk = 0
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;To summarize:&lt;/P&gt;

&lt;OL&gt;
&lt;LI&gt;Splunk is unexpectedly breaking up events;&lt;/LI&gt;
&lt;LI&gt;There are events dated back exactly 3 hours mixed in with current events;&lt;/LI&gt;
&lt;/OL&gt;

&lt;P&gt;Could this be a timezone issue? Both of the instances seem to have the same timezone (EEST), but there seem to be events dated back exactly 3 hours mixed in with current events. What could be the possible cause of this?&lt;/P&gt;

&lt;P&gt;Thanks in advance!&lt;/P&gt;</description>
    <pubDate>Mon, 26 Aug 2019 13:42:29 GMT</pubDate>
    <dc:creator>sendijsd</dc:creator>
    <dc:date>2019-08-26T13:42:29Z</dc:date>
    <item>
      <title>Splunk unexpected timestamp parsing behavior</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Splunk-unexpected-timestamp-parsing-behavior/m-p/461612#M79648</link>
      <description>&lt;P&gt;Greetings,&lt;/P&gt;

&lt;P&gt;In my environment, I have set up an Universal Forwarder that is monitoring a single server .log file, which is then forwarded to a Splunk indexer instance for parsing etc. as a specific sourcetype(log4j). My Universal Forwarder configuration is as follows: &lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;inputs.conf
[default]
host = 1
[monitor://server.log]
sourcetype=log4j
index= targetIndex
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;On the indexer, I have noticed several issues, both with timestamp parsing and event breaking. As you can see in the following image, there are events mixed in with local timestamps dating 3 hours ago, but Splunk has assigned the current time for said event. On top of that, Splunk has made a separate event for the Headers: and Payload:  entries, which should have been a part of the event below. Note that these events all come from the same host and all have the same sourcetype. &lt;span class="lia-inline-image-display-wrapper" image-alt="alt text"&gt;&lt;img src="https://community.splunk.com/t5/image/serverpage/image-id/7573i56C569B95F1481A5/image-size/large?v=v2&amp;amp;px=999" role="button" title="alt text" alt="alt text" /&gt;&lt;/span&gt;&lt;BR /&gt;
For additional context, the following image visualizes the format of the .log file as seen on the forwarding instance. Note how there is a slight gap between the second event's Content-Type and Headers fields, which, I believe, is what is causing Splunk to assign it to a separate event.&lt;BR /&gt;
 &lt;span class="lia-inline-image-display-wrapper" image-alt="alt text"&gt;&lt;img src="https://community.splunk.com/t5/image/serverpage/image-id/7574i1F40E04CDAB5705F/image-size/large?v=v2&amp;amp;px=999" role="button" title="alt text" alt="alt text" /&gt;&lt;/span&gt;&lt;/P&gt;

&lt;P&gt;Here is the props.conf that I currently have set on my indexer instance:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;[log4j]
BREAK_ONLY_BEFORE=\d\d\d\d-\d\d-\d\d\s\d\d:\d\d:\d\d.\d\d\d
MAX_TIMESTAMP_LOOKAHEAD=23
TZ=Europe/Riga
TIME_FORMAT=%Y-%m-%d %H:%M:%S.%3NZ
TIME_PREFIX=^
SHOULD_LINEMERGE=true
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;As well as the limits.conf, although, to my understanding, it shouldn't affect the parsing behavior:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;limits.conf
[search]
max_rawsize_perchunk = 0
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;To summarize:&lt;/P&gt;

&lt;OL&gt;
&lt;LI&gt;Splunk is unexpectedly breaking up events;&lt;/LI&gt;
&lt;LI&gt;There are events dated back exactly 3 hours mixed in with current events;&lt;/LI&gt;
&lt;/OL&gt;

&lt;P&gt;Could this be a timezone issue? Both of the instances seem to have the same timezone (EEST), but there seem to be events dated back exactly 3 hours mixed in with current events. What could be the possible cause of this?&lt;/P&gt;

&lt;P&gt;Thanks in advance!&lt;/P&gt;</description>
      <pubDate>Mon, 26 Aug 2019 13:42:29 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Splunk-unexpected-timestamp-parsing-behavior/m-p/461612#M79648</guid>
      <dc:creator>sendijsd</dc:creator>
      <dc:date>2019-08-26T13:42:29Z</dc:date>
    </item>
    <item>
      <title>Re: Splunk unexpected timestamp parsing behavior</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Splunk-unexpected-timestamp-parsing-behavior/m-p/461613#M79649</link>
      <description>&lt;P&gt;It looks to me like the TIME_FORMAT setting does not exactly match the sample data.  Try &lt;CODE&gt;TIME_FORMAT = %Y-%m-%d %H:%M:%S,%3N&lt;/CODE&gt;.&lt;/P&gt;</description>
      <pubDate>Wed, 30 Sep 2020 01:53:53 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Splunk-unexpected-timestamp-parsing-behavior/m-p/461613#M79649</guid>
      <dc:creator>richgalloway</dc:creator>
      <dc:date>2020-09-30T01:53:53Z</dc:date>
    </item>
    <item>
      <title>Re: Splunk unexpected timestamp parsing behavior</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Splunk-unexpected-timestamp-parsing-behavior/m-p/461614#M79650</link>
      <description>&lt;P&gt;Thank you very much, that did it! &lt;/P&gt;</description>
      <pubDate>Mon, 26 Aug 2019 17:19:08 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Splunk-unexpected-timestamp-parsing-behavior/m-p/461614#M79650</guid>
      <dc:creator>sendijsd</dc:creator>
      <dc:date>2019-08-26T17:19:08Z</dc:date>
    </item>
  </channel>
</rss>

