Splunk Search

IIS Logs not Parsing as expected

djreschke
Communicator

I have a props conf file that is not parsing data as i expected. I can see in the raw log that the IIS log has the header information in it. 

 

[sourcetype]

DATETIME_CONFIG =
INDEXED_EXTRACTIONS = w3c
LINE_BREAKER = ([\r\n]+)
MAX_TIMESTAMP_LOOKAHEAD = 32
NO_BINARY_CHECK = true
SHOULD_LINEMERGE = false
category = Web
description = W3C Extended log format produced by the Microsoft Internet Information Services (IIS) web server
detect_trailing_nulls = auto
disabled = false
pulldown_type = true

 

When i manual upload the log file and assigning it to it will parse out the log with the same settings.

 

[sourcetypeA]
DATETIME_CONFIG =
INDEXED_EXTRACTIONS = w3c
LINE_BREAKER = ([\r\n]+)
MAX_TIMESTAMP_LOOKAHEAD = 32
NO_BINARY_CHECK = true
SHOULD_LINEMERGE = false
category = Web
description = W3C Extended log format produced by the Microsoft Internet Information Services (IIS) web server
detect_trailing_nulls = auto
disabled = false
pulldown_type = true

 

This props is on the searchhead were i am searching the data. The IIS logs is being capture via a UF.

 

Has anyone run into this before?

Labels (1)
Tags (1)
0 Karma
1 Solution

djreschke
Communicator

Needed to create a transforms to fix the issue. 

 

View solution in original post

0 Karma

djreschke
Communicator

Needed to create a transforms to fix the issue. 

 

0 Karma
Get Updates on the Splunk Community!

Automatic Discovery Part 1: What is Automatic Discovery in Splunk Observability Cloud ...

If you’ve ever deployed a new database cluster, spun up a caching layer, or added a load balancer, you know it ...

Real-Time Fraud Detection: How Splunk Dashboards Protect Financial Institutions

Financial fraud isn't slowing down. If anything, it's getting more sophisticated. Account takeovers, credit ...

Splunk + ThousandEyes: Correlate frontend, app, and network data to troubleshoot ...

 Are you tired of troubleshooting delays caused by siloed frontend, application, and network data? We've got a ...