I'm supporting a system where we have deployed servers that are uploading their IIS logs to a central location. The indexer is configured to monitor the central location where each deployed server has its own uniquely named folder structure. The deployed servers are configured to upload their IIS logs every 12 hours. The IIS logs are configured to roll every day, but because the servers are uploading the logs twice a day, that means each log should be updated at least once.
So far, we've not had any issues (that I'm aware of) with duplicate events. However, some logs are simply not being indexed, and checking the _internal log today, I noticed a lot of these entries for the "missing" logs:
File will not be read, seekptr checksum did not match (file=\FILESERVER\SHARE\DEPT\UNIQUE_SVR_NAME\_admin\iislogs\u_ex170518.log). Last time we saw this initcrc, filename was different. You may wish to use larger initCrcLen for this sourcetype, or a CRC salt on this source.
And also some of these, which I assume just means the total log length was shorter than the default 256 byte initCrcLength value?
File will not be read, is too small to match seekptr checksum (file=\FILESERVER\SHARE\DEPT\UNIQUE_SVR_NAME\_admin\iislogs\u_ex170515.log). Last time we saw this initcrc, filename was different. You may wish to use larger initCrcLen for this sourcetype, or a CRC salt on this source.
The vast majority of these logs are being indexed just fine. What need I do to cleaned up these outliers? Just set the initCrcLength to something longer? I don't want any duplication, but I do want to be sure all of the logs are being indexed. I'm reading the documentation, but not really grasping how the CrcSalt and initCrcLength work to know exactly what to do with them or if they would actually solve this problem.
... View more