Hello I have a question. We have lots of indexes, and rather than specify each one, I use index=*proxy* to search across index=some_proxy1 and index=some_proxy2 I understand that obviously index=* is a bad thing to do, but does index=*proxy* really cause bad things to happen in Splunk? I've been using syntax like this for several years, and nothing bad has ever happened. I did a test on one index with index=*proxy* This search has completed and has returned 1,000 results by scanning 117,738 events in 7.115 seconds with index=some_proxy1 This search has completed and has returned 1,000 results by scanning 121,162 events in 7.318 seconds As you can see in the example using *proxy* over the same time period was actually quicker. ... View more

Hello. We have a large number of devices that send syslog to Splunk that we need to ingest. All devices and Splunk is on premis. There are many different type of syslog messages that we need to collect. As an example some of the source types are: web proxy logs firewall logs from different vendors web application logs dhcp logs and many many more... All devices currently send syslog to the same IP address and UDP port 514. Currently we manage this by having an rsyslog configration that is shared across servers using a puppet config. This allow us to edit the syslog configuration on one server and have it pushed out to all other servers. The rsyslog.conf file  identifies the type of syslog being received which file and directory the syslog message should be written to. The various files are written to disk and then an inputs.conf file is automatically updated to ensure that the file is ingested into Splunk. The file and directory path allows us to determine the index the data is written to and the sourcetype. This works, but is quite complex. The servers are currently based on centos 6 which is end of life in November. How do other people collect and manage syslog in their environments?  Thanks for your help.       ... View more

Hi I am new to Splunk Phantom and have so far far Triggered an alert in Splunk This send the data into Phantom Phantom then runs a playbook which queries some Carbon Black stuff I then want to send the results of this carbon black search back into Splunk I can see that i can use the Splunk App in Phantom and use the postdata command. However i only seem to be able to sned back one value at a time, with no futher remarks. Is it possible to send back the complete object from Phantom into Splunk as a JSON object? For example you would have the original data you sent to Phantom and then the enhancement that you have got from running the playbook against the original data. The reason is that Splunk is the front end tool, and it would be more convienient to view any results in Splunk. ... View more

Hello i have two windows event collectors. 3 domain controllers send their events to one event collector (WEC01), and three send their events to another event collector.(WEC02) From 8.00 onwards (eg the start of the working day) the events from WEC02 are getting progressively delayed up to about 20,000 seconds behind, before eventually catching up by about 4AM in the morning. Both systems have the same configurations on them, which are managed by a deployment server. I have looked at: https://answers.splunk.com/answers/224727/why-is-my-universal-forwarder-showing-extreme-lag.html?utm_source=typeahead&utm_medium=newquestion&utm_campaign=no_votes_sort_relev And various other posts and have the following set: limits.conf [thruput] maxKBps = 0 Outputs.conf There doesnt appear to be any blockage in terms of indexer queues as other events are indexed fine and there is no latency. CPU, Memory and Network is all fine on the virtual machine. I can see no obvious reason why there is a delay. Both Windows Event collectors are virtual machines. They may be on different physical hosts. There is a difference in latency in packets between the two hosts. Here is a screenshot from the resouce monitor, network activity. Slow Windows Event Collector (High Latency) Fast Windows Event Collector (low latency) ... View more