Hi, Did you ever get to the bottom of this? I have the same issue. ... View more

Hi, Did you manage it resolve this (I appreciate it was a while back). ... View more

Hi, I appreciate this was a while ago but did you figure this out? I have a similar issue. Cheers. ... View more

I think you'd have to establish a procedure/contingency for that for sure 😉 ... View more

... or as follows (during relevant time window) ... sourcetype="firewall" action="denied" | stats count | where count>1000 ... View more

This limits.conf might help you: list_maxsize = <int> * Maximum number of list items to emit when using the list() function stats/sistats * Defaults to 100 ... View more

You could also check if the user Splunk is running as has permission to write to the file & directory concerned: $SPLUNK_HOME$/apps/ /local/inputs.conf. This is because when you use the UI to create inputs, as jconger mentioned, the REST API is being used by the IPS app to update the inputs.conf file for you. As well as updating the file manually as mentioned previously, you could rename the inputs.conf file then try again to see if there's something strange going wrong with any inputs file already in place. I.e. let the IPS app create the inputs.conf file again from scratch, in a format it's happy with. The other file this app writes to is app.conf (also in local dir) so the same advice applies here also. Just a couple of ideas. ... View more

There isn't a v6 version yet but it's apparently on its way, I asked the same question a while back - the Cisco Security Suite is gradually being v6'd! Great news. See this post For the time being the v5 version will actually grab the logs for you with v6 Splunk still (I've tried this). You just may find that some elements of the shipped dashboards don't look as good as they would in v5 due to version differences. Deprecated Cisco IPS App Download ... View more

Hi, The indexes are definitely created on the indexer(s) already right? (have to ask just in case). So does the output of the following command from $SPLUNK_HOME$/bin folder have the index and sourcetype set as desired? Sounds like you have checked this bit but just checking for this exact usage. ./splunk cmd btool inputs list --debug Have you got any props and transforms on the indexer that could be overriding the index and sourcetype to the wrong values? I.e. if you run ./splunk cmd btool props list --debug is there anything picking up that folder/source and overriding the index and/or sourcetype. What's the sourcetype being set to for a given example from the inputs.conf above. ... View more

Hi, I think the key point is that you're talking about two separate data input types, UDP and file monitor, so it's conceivable that they will be treated differently. Each UDP message comes from one specific source (i.e. could be many devices but each device is unique) so the UDP monitor can easily set the host on the event in Splunk - it's where the UDP message came from, easy. The other reason it may work is that Splunk may well be seeing your UDP source and correctly assuming the sourcetype of "syslog" which it knows how to extract the host for (done at an event parsing level for you - see more info on this below). Or you may have specified sourcetype as syslog on the UDP input. Once you change the input to write to a shared file Splunk does not necessarily know which host the message is from, i.e. many hosts all logging to one file, lots of different hosts. Splunk does recognise certain formats as a pretrained sourcetypes, syslog being one of them, i.e. it will stamp a sourcetype of "syslog" on syslog messages if they fit the expected format for syslog messages. Depending on the sourcetype, when sourcetype has been stamped on the event, the pre-canned props and transforms Splunk ships with will parse/interrogate the event and try to stamp the correct host on the event, using pattern matching defined for that sourcetype. Don't expect this to just work for all events for all types of data though, often you will need to define this logic yourself. This parsing logic is provided by the props.conf and transforms.comf in etc/system/default for sourcetype "syslog". As you can see, the "syslog-host" transform is performing the host definition : - Props: [syslog] pulldown_type = true maxDist = 3 TIME_FORMAT = %b %d %H:%M:%S MAX_TIMESTAMP_LOOKAHEAD = 32 TRANSFORMS = syslog-host REPORT-syslog = syslog-extractions SHOULD_LINEMERGE = False Transforms: - [syslog-host] DEST_KEY = MetaData:Host REGEX = :\d\d\s+(?:\d+\s+|(?:user|daemon|local.?)\.\w+\s+)*\[?(\w[\w\.\-]{2,})\]?\s FORMAT = host::$1 Probably what is happening here is that because they are being seen as apache messages you are not getting a sourcetype of "syslog" stamped as they are recognised as something else. As such, the host isn't extracted because whatever sourcetype is being set doesn't have pre-canned props and transforms defined. You will either need to define these or find an app that has them for you. Alternatively you could just set "sourcetype = syslog" on your inputs.conf entry for the syslog file(s) you are monitoring. However you might want your breakdowns less general than this, i.e. have a range of syslog_<vendor> sourcetypes so that you can search and perform field extractions on those sourcetypes later on in the Splunk UI. A good way to set host is to try and do it at a source wide level (more efficient than event-by-event parsing, i.e. if you have the same host value for every event in a file you are monitoring then there's no need to make Splunk parse each event. With syslog you can achieve this by configuring your syslog server to write to a different folder for each host where the folder name reflects the name of the host. E.g. so you end up with folders like below. /mnt/logs/192.168.1.1/syslog.log /mnt/logs/192.168.1.2/syslog.log /mnt/logs/192.168.1.3/syslog.log In the inputs.conf where you specify the data collection you can tell it to look at a particular segment of the file name for the host. E.g. the inputs.conf definition for the syslog file monitor would look something like this where the host is wildcarded by the "*": [monitor:///mnt/logs/*/syslog.log] host_segment = 3 Hope this helps! ... View more

Alternatively you could put all of the saved searches that drive the alerts in an app on their own then disable the app and hence all searches via the "manage apps" page (on v6) in the UI during a maintenance window. That would then capture all alerts in one go. ... View more

No worries glad to have helped. ... View more

It'd probably be worth auto-extracting the response time into a field so that whenever you search for sourcetype "sfe" you have a field that represents response time. Then you'll have a field that you can perform statistical commands on, such as max, min, avg etc. With that in mind I'd create props.conf entry to hook into sourcetype sfe. Something like the below: props.conf: [sfe] EXTRACT_sfe_resp_time = ,(?<resp_time>\d{1,6})ms Then you could run your search through a timechart command something like this: sourcetype=sfe search.action | timechart avg(resp_time) by host ... View more

Ok great, many thanks for the quick answer. ... View more

I noticed this issue also on v6 but am yet to work out why it happens. I thought maybe it was due to a capability being required (in Splunk roles) but there doesn't seem to be anything relating to alerts in the available list. I'll post again if I work it out though not sure what it could be currently. ... View more

It sounds like you've got where you want to be now though it's worth also checking out this link for some useful ways of troubleshooting license usage - some more searches. In addition to this, Splunk Deployment Monitor app and Splunk on Splunk apps provide some useful dashboards for tracking usage and splitting it by host, sourcetype etc. These apps are free and available on Splunkbase. Another place to look is in the search app under the Status > Index Activity menu option. There are some useful dashboards there also, notably Index Volume. ... View more

No I'm afraid I ended up working around it. ... View more

I already had a whitelist at the serverclass level (under [serverClass:namehere] stanza in the example above). It was at the app level ([serverClass:namehere:app:namehere] in e.g. above), where I needed to add a whitelist entry. Once both of these were done, the expected behaviour resumed. This seems to be slightly different than the old machineTypes way of doing things where the serverClass whitelist would have been inherited I think. Your comment led me to realise this so thanks gekoner. ... View more

I've noticed that when using v5.0.1 this issue still seems to exist. Only by using machineTypes (rather than machineTypesFilter) do apps successfully deploy in my environment. ... View more