Hi thanks for the feeback,
Yes, we tried unsetting by setting it to blank and ("unset") - both actually caused iis to no longer be collected on the 6.1.4 (6.x) UFs
e.g. In our troubleshooting we distributed a new UFs props.conf to the 6.x UFs - both did not work and actually caused iis to stop being collected on the 6.x UFs.
[iis]
INDEXED_EXTRACTIONS =
and also tried
[iis]
INDEXED_EXTRACTIONS = unset
in both the cases the 6.x UFs actually stopped forwarding the IIS data due this setting being incorrect.
Additionally, since the only workaround appears to be using a custom sourcetype on the UFs then changing it at the indexers, the UFs (correctly) re-index all the data since it is a new sourcetype... (blew out our license over the weekend - no choice since alternative is to have randomly munged data where it never was before)
There must be a way to turn off INDEXED_EXTRACTIONS so this scenario does not play out with other data-types as well (e.g. access_combined, json, etc) - For Splunk users migrating to 6.x of the UFs (from 5.x and earlier) this is going to pose a huge issue since the INDEXED_EXTRACTIONS settings that are done by default on well known sourcetypes.
The munged _raw data from the UFs is seemingly random, in our shop about 0.5% of the rows coming in for iis sourcetype - just enough to get every user lighting torches and gathering pitchforks, since various reports/alerts/queries/etc now have bogus data peppered through them
Defaulting INDEXED_EXTRACTIONS on the 6.x UFs for those migrating from earlier versions is not pretty -- the only workarounds seems to be rewrite all of our working field-extractions, to setup a distributed application to update etc/system/default/props.conf on all the UFs (anytime one is spun up), or change the sourcetype name on the UFs and change it back on the indexers thus avoiding re-indexing the data (unless the default setting on the 6.x UFs for INDEXED_EXTRACTIONS can be turned back off somehow?)
Appreciate any and all inputs
thanks again
-tom
... View more