<?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 Syslog data is lost in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/Syslog-data-is-lost/m-p/41994#M7792</link>
    <description>&lt;P&gt;Hi,&lt;BR /&gt;
 I saw several posts about this problem, but none with a valid answer.&lt;BR /&gt;
My problem is that I have a running Splunk 4.2.2 on Win64 that is receiving syslog messages from our switches since several months. It worked fine.&lt;BR /&gt;
Today I configured some IP phones to log to it, using the same UDP 514 port I use for everything.&lt;BR /&gt;
I cannot find any data making searches about phones (IP addresses, raw data, ...).&lt;BR /&gt;
To separate things, I created a new UDP port 8514 listener, and I see in metrics.log that it is receiving data, I see data in Wireshark, but then it is lost.&lt;BR /&gt;
I also created a specific index bound to this source, and the index contains no data.&lt;BR /&gt;
No firewall involved in any network path.&lt;BR /&gt;
No license limits hit. Logging to another syslog works ok.&lt;/P&gt;

&lt;P&gt;How can I track where the data is going and have it indexed?&lt;/P&gt;

&lt;P&gt;Some added debug&lt;/P&gt;

&lt;P&gt;The port is open for listening&lt;/P&gt;

&lt;P&gt;C:\Users\bigboss&amp;gt;netstat -an | grep 8514&lt;/P&gt;

&lt;P&gt;UDP    0.0.0.0:8514           &lt;EM&gt;:&lt;/EM&gt;&lt;/P&gt;

&lt;P&gt;phones is the index I created and bound to the udp 8514 listener:&lt;/P&gt;

&lt;P&gt;07-13-2011 12:47:54.346 +0200 INFO  Metrics - group=per_index_thruput, series="phones", kbps=0.040134, eps=0.903226, kb=1.244141, ev=28, avg_age=40007.000000, max_age=40007&lt;/P&gt;

&lt;P&gt;8514 UDP is my new listener&lt;/P&gt;

&lt;P&gt;07-13-2011 12:47:54.346 +0200 INFO  Metrics - group=udpin_connections, 8514, sourcePort=8514, _udp_bps=41.55, _udp_kbps=0.04, _udp_avg_thruput=0.04, _udp_kprocessed=80.00, _udp_eps=0.45&lt;/P&gt;

&lt;P&gt;&lt;STRONG&gt;UPDATE&lt;/STRONG&gt;&lt;BR /&gt;
I found dozen of this in splunkd.log&lt;/P&gt;

&lt;P&gt;137 similar messages suppressed.&lt;BR /&gt;&lt;BR /&gt;
First occurred at: Wed Jul 13 12:52:20 2011&lt;BR /&gt;
07-13-2011 12:57:30.201 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;07-13-2011 12:57:30.217 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;07-13-2011 12:57:30.217 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;07-13-2011 12:57:30.217 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;07-13-2011 12:57:30.217 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;07-13-2011 12:57:30.217 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;07-13-2011 12:57:49.811 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;07-13-2011 12:57:49.826 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;07-13-2011 12:57:49.826 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;07-13-2011 12:57:49.826 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;The format of one log is like (yes it is on two lines):&lt;/P&gt;

&lt;P&gt;01:58:33.070000 Refresh: (UI) FUNC: UiManager::Refresh, Leave&lt;/P&gt;

&lt;P&gt;mac:00-08-5D-27-3F-AB&lt;/P&gt;

&lt;P&gt;I'm not interested in parsing that timestamp it is wrong on each reboot of the phone, I could set it to the time Splunk received the message. Is there a way to do it?&lt;/P&gt;</description>
    <pubDate>Mon, 28 Sep 2020 09:44:04 GMT</pubDate>
    <dc:creator>imbuto</dc:creator>
    <dc:date>2020-09-28T09:44:04Z</dc:date>
    <item>
      <title>Syslog data is lost</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Syslog-data-is-lost/m-p/41994#M7792</link>
      <description>&lt;P&gt;Hi,&lt;BR /&gt;
 I saw several posts about this problem, but none with a valid answer.&lt;BR /&gt;
My problem is that I have a running Splunk 4.2.2 on Win64 that is receiving syslog messages from our switches since several months. It worked fine.&lt;BR /&gt;
Today I configured some IP phones to log to it, using the same UDP 514 port I use for everything.&lt;BR /&gt;
I cannot find any data making searches about phones (IP addresses, raw data, ...).&lt;BR /&gt;
To separate things, I created a new UDP port 8514 listener, and I see in metrics.log that it is receiving data, I see data in Wireshark, but then it is lost.&lt;BR /&gt;
I also created a specific index bound to this source, and the index contains no data.&lt;BR /&gt;
No firewall involved in any network path.&lt;BR /&gt;
No license limits hit. Logging to another syslog works ok.&lt;/P&gt;

&lt;P&gt;How can I track where the data is going and have it indexed?&lt;/P&gt;

&lt;P&gt;Some added debug&lt;/P&gt;

&lt;P&gt;The port is open for listening&lt;/P&gt;

&lt;P&gt;C:\Users\bigboss&amp;gt;netstat -an | grep 8514&lt;/P&gt;

&lt;P&gt;UDP    0.0.0.0:8514           &lt;EM&gt;:&lt;/EM&gt;&lt;/P&gt;

&lt;P&gt;phones is the index I created and bound to the udp 8514 listener:&lt;/P&gt;

&lt;P&gt;07-13-2011 12:47:54.346 +0200 INFO  Metrics - group=per_index_thruput, series="phones", kbps=0.040134, eps=0.903226, kb=1.244141, ev=28, avg_age=40007.000000, max_age=40007&lt;/P&gt;

&lt;P&gt;8514 UDP is my new listener&lt;/P&gt;

&lt;P&gt;07-13-2011 12:47:54.346 +0200 INFO  Metrics - group=udpin_connections, 8514, sourcePort=8514, _udp_bps=41.55, _udp_kbps=0.04, _udp_avg_thruput=0.04, _udp_kprocessed=80.00, _udp_eps=0.45&lt;/P&gt;

&lt;P&gt;&lt;STRONG&gt;UPDATE&lt;/STRONG&gt;&lt;BR /&gt;
I found dozen of this in splunkd.log&lt;/P&gt;

&lt;P&gt;137 similar messages suppressed.&lt;BR /&gt;&lt;BR /&gt;
First occurred at: Wed Jul 13 12:52:20 2011&lt;BR /&gt;
07-13-2011 12:57:30.201 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;07-13-2011 12:57:30.217 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;07-13-2011 12:57:30.217 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;07-13-2011 12:57:30.217 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;07-13-2011 12:57:30.217 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;07-13-2011 12:57:30.217 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;07-13-2011 12:57:49.811 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;07-13-2011 12:57:49.826 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;07-13-2011 12:57:49.826 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;07-13-2011 12:57:49.826 +0200 WARN  DateParserVerbose - Failed to parse timestamp for event.  Context="source::Tel3|host::SRV-SYSLOG|syslog|" Text="mac:00-08-5D-27-3F-AB..."&lt;/P&gt;

&lt;P&gt;The format of one log is like (yes it is on two lines):&lt;/P&gt;

&lt;P&gt;01:58:33.070000 Refresh: (UI) FUNC: UiManager::Refresh, Leave&lt;/P&gt;

&lt;P&gt;mac:00-08-5D-27-3F-AB&lt;/P&gt;

&lt;P&gt;I'm not interested in parsing that timestamp it is wrong on each reboot of the phone, I could set it to the time Splunk received the message. Is there a way to do it?&lt;/P&gt;</description>
      <pubDate>Mon, 28 Sep 2020 09:44:04 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Syslog-data-is-lost/m-p/41994#M7792</guid>
      <dc:creator>imbuto</dc:creator>
      <dc:date>2020-09-28T09:44:04Z</dc:date>
    </item>
    <item>
      <title>Re: Syslog data is lost</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Syslog-data-is-lost/m-p/41995#M7793</link>
      <description>&lt;P&gt;It sounds to me like your syslog data is coming into the index, it is just being indexed in a way that you do not expect. Perhaps the wrong year is being applied to the data. I would do a all time(real-time) search against the phone index and see if data is streaming in. If it is, then you'll likely need to configure timestamp recognition in props.conf with TIME_FORMAT and MAX_TIMESTAMP_LOOKAHEAD. &lt;/P&gt;

&lt;P&gt;You may also want to take a look at MAX_DAYS_AGO and MAX_DAYS_HENCE in props.conf to tell splunk not to look past 30 days in the past for an event. Based on the format of your event, I think you should also be using BREAK_ONLY_BEFORE and MUST_BREAK_AFTER in props.conf to tell splunk how you'd like the events to be broken. &lt;/P&gt;

&lt;P&gt;I hope this helps!&lt;/P&gt;</description>
      <pubDate>Mon, 28 Sep 2020 09:44:10 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Syslog-data-is-lost/m-p/41995#M7793</guid>
      <dc:creator>jbsplunk</dc:creator>
      <dc:date>2020-09-28T09:44:10Z</dc:date>
    </item>
  </channel>
</rss>

