What is happening here is that you are hitting a mongodb limitation, as described here: https://docs.mongodb.com/manual/core/index-multikey/#limitations This happens if more than one to-be-indexed field in the collection is an array. This potentially can happen if you first define a collection without any accelerated fields and then feed the collection with some SPL creating 2 or more multivalue fields like: | makeresults  | eval Field1="andy, matteo, john, brian", Field2="greg, daviann, zofnat, devon"  | makemv delim="," Field1  | makemv delim="," Field2  | outputlookup MG_Collection append=t  Once you define the field acceleration within collections.conf and then restart, you will hit the problem. If instead you define straight away the field acceleration in collections.conf and you attempt to save 2 or more multivalue fields within that KVstore collection, the search will fail and not store the data. Hope this helps. ... View more

This can be solved by following one of the 3 possible approaches listed in this documentation article: http://docs.splunk.com/Documentation/Splunk/6.2.1/Knowledge/Aboutsummaryindexing i.e. Report acceleration - Uses automatically-created summaries to speed up completion times for certain kinds of reports. Data model acceleration - Uses automatically-created summaries to speed up completion times for pivots. Summary indexing - Enables acceleration of searches and reports through the manual creation of separate summary indexes that exist separately from your main indexes. Hope this helps. ... View more

Issue has been fixed and actually logs were not lost, also considering that useACK was enabled and no further connectivity issues were reported. The timestamp extraction configuration on a couple of new IDXs was wrong. These IDXs didn't get the right props.conf configuration as the necessary setting had neither been deployed manually nor put on the DS to be pushed out. After correcting props.conf on the involved IDXs and restarting them, the issue was solved. ... View more

Given csv files with 30k to 60k lines, the performance is pretty good here and there isn't anything special really in order to improve that. Lots of other customer have the same load times having csv files with just a few hundreds of lines in them. Hope this helps. ... View more

If you would like to use the "Subject Alternate Names" in SSL certificates, then Splunk provides following parameters which should cover the use-case you are referring to: outputs.conf: sslAltNameToCheck = <string> * Check the alternate name of the server's certificate against this name. * If there is no match, assume that Splunk is not authenticated against this server. * You must specify this setting if sslVerifyServerCert is true. sslVerifyServerCert = [true|false] * If true, you must make sure that the server you are connecting to is a valid one (authenticated). * Both the common name and the alternate name of the server are then checked for a match. * Defaults to false. More details here: http://docs.splunk.com/Documentation/Splunk/6.1.4/Admin/Outputsconf In addition in server.conf: sslAltNameToCheck = <alternateName1>, <alternateName2>, ... * If this value is set, and 'sslVerifyServerCert' is set to true, splunkd will also be willing to verify certificates which have a so-called "Subject Alternate Name" that matches any of the alternate names in this list. * Subject Alternate Names are effectively extended descriptive fields in SSL certs beyond the commonName. A common practice for HTTPS certs is to use these values to store additional valid hostnames or domains where the cert should be considered valid. * Accepts a comma-separated list of Subject Alternate Names to consider valid. * Items in this list are never validated against the SSL Common Name. * This feature does not work with the deployment server and client communication over SSL. * Optional. Defaults to no alternate name checking sslVerifyServerCert = true|false * Used by distributed search: when making a search request to another server in the search cluster. * Used by distributed deployment clients: when polling a deployment server. * If this is set to true, you should make sure that the server that is being connected to is a valid one (authenticated). Both the common name and the alternate name of the server are then checked for a match if they are specified in this configuration file. A certificiate is considered verified if either is matched. * Default is false. More details here: http://docs.splunk.com/Documentation/Splunk/6.1.4/Admin/Serverconf ... View more

Yes, there is an open bug for it, currently under analysis, but unfortunately not fixed yet. As soon as there are more details about it, I will update it here. As a workaround, if your eventtypes.conf looks like this: [test] search = sourcetype=testST Message="Русский текст" you could try to look up the field as explained here: http://docs.splunk.com/Documentation/Splunk/6.1.1/SearchTutorial/Usefieldlookups Hope this helps. ... View more

That's correct. "default" and "local" folders have to be all lowercases in Splunk. Otherwise their content will not be applied. In general if you have doubts about conf files being applied, it's always a good idea to use the btool command to do the first troubleshooting in order to figure out if Splunk is missing or is doing anything wrong, for example because of a typo. See also the official btool documentation article for further details: http://docs.splunk.com/Documentation/Splunk/6.0.1/Troubleshooting/Usebtooltotroubleshootconfigurations ... View more

After cleaning up the whole customer configuration (there were several unnecessary/unused/improper apps), it turned out to be something much more simple: a specific filtering (using props.conf and transforms.conf) had been put in place by the customer long time ago (he totally forgot about) for some type of Security events and for some specific UFs, so that those events were filtered out. As these UFs were not generating any other type of Security events than the ones filtered out, the customer began to think that Windows Security Logs were not collected at all, while the truth is that it has always been working as expected. Thanks all for your support. ... View more