Do NOT remove this file unless you also change the indexer GUID using splunk clone-prep-clear-config or it will possible corrupt previously uploaded buckets that have been evicted from the local cache. clone-prep-clear-config is safe to use because it emulates a new indexer being added to the cluster and it will not upload buckets that already exist that were uploaded by a different indexer. If there is any possibility that your data on the indexer is not 100% complete due to eviction, you MUST change the guid when removing .buckets_synced_to_remote_storage ... View more

The problem with the null field value is not just a problem for the TA, but a bigger problem with ingesting the logs over the network. The null character causes syslog or whatever network listener you are using to mark the end of the payload, the rest of the message is considered the start of a new message. The "Splunk" workaround is to use LINE_BREAKER and EVENT_BREAKER and set them both to something similar to: <\d+>\w{3}\s+\d+\s+\d{2}:\d{2}:\d{2}\s+\S+\s+\S+\s+\d+\s+\d+\s+0\s matches: <181>Dec 11 12:07:18 hostname CISE_RADIUS_Accounting 0007734788 1 0 where the first part is the syslog priority and the date/time stamp (yours could be different), but this pattern defines the start of a new event and will ignore the nulls that have been written to the file as newlines. The events will look a little ugly, but at least all the fields will be in one event. This also will re-assemble the multi-part messages that are sent by ISE at index time. This WILL NOT WORK if you are doing any sort of load-balancing of your syslog servers that might cause the different parts of the multi-part message to be logged to different servers, in those cases you will have to assemble the parts at search time. ... View more

The problem with the null field value is not just a problem for the TA, but a bigger problem with ingesting the logs over the network. The null character causes syslog or whatever network listener you are using to mark the end of the payload, the rest of the message is considered the start of a new message. The "Splunk" workaround is to use LINE_BREAKER and EVENT_BREAKER and set them both to something similar to: <\d+>\w{3}\s+\d+\s+\d{2}:\d{2}:\d{2}\s+\S+\s+\S+\s+\d+\s+\d+\s+0\s matches: <181>Dec 11 12:07:18 hostname CISE_RADIUS_Accounting 0007734788 1 0 where the first part is the syslog priority and the date/time stamp (yours could be different), but this pattern defines the start of a new event and will ignore the nulls that have been written to the file as newlines. The events will look a little ugly, but at least all the fields will be in one event. ... View more