For some reason, the _time
for the ms:iis:auto
events are taken from the file change/create time, which seems to be either the creation or the daily rotation time.
In the file itself the date/stamp look just fine -
2017-07-01 00:00:00 10.106.180.47 GET /cl_includes/sitemin....
2017-07-01 00:00:00 10.106.180.47 GET /cl_includes/common_....
2017-07-01 00:00:00 10.106.180.47 GET /cl_includes/images/....
2017-07-01 00:00:00 10.106.180.47 GET /health.html - 443 -....
2017-07-01 00:00:01 10.106.180.47 GET /health.html - 443 -....
2017-07-01 00:00:06 10.106.180.47 GET /health.html - 443 -....
2017-07-01 00:00:06 10.106.180.47 GET /health.html - 443 -....
ms:iis:auto
doens't work for us while ms:iis:default
with TZ adjustment works - weird.
@ddrillic , mate did you find a working configuration?
We recently went through this and we found best luck with ms:iis:auto
but we only had to install the TA on the forwarders and search heads, not the indexers
Really interesting @jkat54.
I believe we did install it everywhere but the trick was that the universal forwarder needed it.
A colleague said -
When it comes to the IIS TA, only one of the sourcetypes will actually work on the indexers whereas the second sourcetype needs to have either the TA or a separate props.conf deployed to the forwarder since it’s using INDEXED_EXTRACTIONS
.
Deploying the full TA is overkill, IMO. Just need to throw in the following into a new props.conf
for the forwarder and you’re all set.
INDEXED_EXTRACTIONS = w3c
TIMESTAMP_FIELDS = date, time
agreed. The TA is not upto normal quality/standard
If you really wish, you can take the bits out of the TA and create your own and re-use the sourcetype.
how does your raw data look like? (or is the output above from raw file itself?)
Looks the same as the file itself above...
may be it is easier to extract timestamp and event_breaker yourself