I see from the latest release notes that the recommended sourcetype is ms:iis:auto and the others have been deprecated, presumably to go away at some future point.
What I don't see is the reasoning behind this, in view of the known disadvantages of indexed inputs on the forwarder:
--no further parsing possible
--greatly increases storage requirements
--others of lesser importance e.g. less flexible if the log is reconfigured
Does anyone know of compelling reasons why this has been done? Personally I will always use search-time field extraction unless there is a really good reason not to. It seems to be a wrong turn, unless I've missed something.
Charles
As far as I remember the IIS output logs, the problem with them is that they are CSV without a fixed column order. So you have to rely on the header row to extract the data in proper order. And that's possible only with indexed extractions. The other solution would be to create an external script reading the file, reformatting it and ingesting it as something else (json? k/v pairs?). That could work but it would mean that you weren't indexing the original event which might be important if you needed to use that as evidence - the event would already have been tampered with.
You can also define the column names when using the standard csv wizard, by manual editing.
I suppose it depends on how often your column order gets modified by the system owner. Theoretically, this could happen any time. Does anyone have a feel for how often it happens in practice?
cm
I'm not familiar with how the IIS logs are exported. If it is as you say - you can define manually which columns are exported and you're gonna keep it that way then yes, you could define the field order manually within props.conf and that would work OK.
I suppose creators of the add-on didn't want to make assumptions and just did it so that it works whatever fields and in whatever order are exported.
I can understand that. What I can't understand is why the other methods have been deprecated because once they go away, if you need to do any additional parsing of IIS logs, you can't using this app, which becomes useless and you're back to doing it all yourself anyway.
Anybody connected with the care and feeding of this app care to chime in?
Charles