Getting Data In

striptime not parsing time stamps

smudge797
Path Finder

Im having trouble with data previewer not recognizing the striptime in my logs. Any help would be much welcome! Thanks in advance.

In my props.conf have tried:

[test_data]
TIME_FORMAT=%d %b %Y %H:%M:%S,%3N
TIME_PREFIX =) 

Sample data:

FATAL http-bio-7779-exec-12 com.mydomain.bux.common.client.HttpServiceInvoker (HttpServiceResult.java:90) 30 Aug 2013 00:24:16,407 - Http Service Calling Failed. Http Calling Context: 

FATAL http-bio-7779-exec-12 com.mydomain.bux.common.client.HttpServiceInvoker (HttpServiceResult.java:90) 30 Aug 2013 00:24:16,431 - Http Service Calling Failed. Http Calling Context: 

FATAL http-bio-7779-exec-12 com.mydomain.bux.common.client.HttpServiceInvoker (HttpServiceResult.java:90) 30 Aug 2013 00:24:16,437 - Http Service Calling Failed. Http Calling Context: 

ERROR http-bio-7779-exec-12 com.mydomain.bux.webservice.callstoactionsvc.serviceclients.MyServiceClientImpl (LoggingUtils.java:56) 30 Aug 2013 00:24:16,475 - CallsToActionSvcException occurs when trying to process the reqeust.

ERROR http-bio-7779-exec-12 com.mydomain.bux.webservice.callstoactionsvc.serviceclients.YourServiceClientImpl (LoggingUtils.java:56) 30 Aug 2013 00:24:16,525 - CallsToActionSvcException occurs when trying to process the reqeust.

ERROR http-bio-7779-exec-12 com.mydomain.bux.webservice.callstoactionsvc.serviceclients.MyServiceClientImpl (LoggingUtils.java:56) 30 Aug 2013 00:24:16,569 - CallsToActionSvcException occurs when trying to process the reqeust.

FATAL http-bio-7779-exec-12 com.mydomain.bux.common.client.HttpServiceInvoker (HttpServiceResult.java:90) 30 Aug 2013 00:24:30,316 - Http Service Calling Failed. Http Calling Context: 

FATAL http-bio-7779-exec-12 com.mydomain.bux.common.client.HttpServiceInvoker (HttpServiceResult.java:90) 30 Aug 2013 00:24:30,323 - Http Service Calling Failed. Http Calling Context: 
0 Karma

kristian_kolb
Ultra Champion

The TIME_FORMAT looks OK, and these are all just single line events, right? And the timestamp will always come within the first 150 characters of the event, right?

The only thing left to test should be to escape the closing parenthesis in your TIME_PREFIX, as parentheses have special meaning in regex, and also add that whitespace for good measure;

TIME_PREFIX = \)\s

And you are aware that this change will only affect new events coming in for indexing. You might have to restart splunk, since this affects index-time operations.

Hope this helps,

K

0 Karma

smudge797
Path Finder

Worked great thanks!

0 Karma

kristian_kolb
Ultra Champion

Please mark it as answered if your problem was solved. Vote up if you want to.

Thanks,
K

smudge797
Path Finder

Work great thanks!

0 Karma

rturk
Builder

Hi Smudge,

Try this:

[test_data]
MAX_TIMESTAMP_LOOKAHEAD = 200
NO_BINARY_CHECK = 1
SHOULD_LINEMERGE = false
TIME_FORMAT = %d %b %Y %H:%M:%S,%3N

I think your problem is that on some lines the timestamp is more than 150 characters into the event (which by default is where Splunk will search to.

Let me know how you get along 🙂

Ref: http://docs.splunk.com/Documentation/Splunk/5.0.4/Data/Configuretimestamprecognition#Timestamp_attri...

0 Karma

kristian_kolb
Ultra Champion

Good point on the SHOULD_LINEMERGE part. Didn't look like it was past the 150-mark to me, though.

Career Survey
First 500 qualified respondents will receive a $20 gift card! Tell us about your professional Splunk journey.
Get Updates on the Splunk Community!

Thanks for the Memories! Splunk University, .conf25, and our Community

Thank you to everyone in the Splunk Community who joined us for .conf25, which kicked off with our iconic ...

Data Persistence in the OpenTelemetry Collector

This blog post is part of an ongoing series on OpenTelemetry. What happens if the OpenTelemetry collector ...

Introducing Splunk 10.0: Smarter, Faster, and More Powerful Than Ever

Now On Demand Whether you're managing complex deployments or looking to future-proof your data ...