You can gat the table to sort correctly by using a (hidden) sort field... <your query here> | eval sortTime=strptime(YourTimeField,"YourConversion") | sort + sortTime | table your,fields,without,sortTime This way Splunk first sorts the events by the sortTime field, which is Unix TImestamp, so in correct order, and then just not displays it. ... View more

You can modify you input like this: <input type="radio" token="priv_login" searchWhenChanged="true"> <label>Login Status</label> <choice value="4624">Successful</choice> <choice value="4625">Failed</choice> <initialValue>4624</initialValue> <change> <set token="panellabel">$label$</set> <condition value="4624"> <set token="additional_search">yoursecondfield=something</set> </condition> </change> </input> Then you can include $additional_search$ in your search query ... View more

Assuming both searches have the field "key" and "data" you could go like this... <your_main_search> | rename data as data1 | join type=outer max=0 key [<your_second_search> | rename data as data2] | eval data=coalesce(data2, data1) | table key data ... View more

If you want to have all raw events in your results table as well, you can simply include this in your stats command. Just add a list(_raw) as RawEvents to the already existing SPL, which powers the shown search. Just be aware, that this might enlarge your results table quite a bit 🙂 ... View more

Regarding your limits.conf - this setting is needed on the indexing tier, as structured field extraction happens in the Typing Tier of the indexing pipeline, which will always be on the indexer. This is stated in the Wiki reference you provided as well. (It doesn't mention limits.conf exactly, but field extraction is done during the typing, hence it is affected by the limits you want to set). ... View more

You could include a lookup in your search, which maps the recipient email address according to the filename: index=mlbso_changelog (crash_context OR crash_stack OR crash_shortinfo) AND source="*crash*" NOT "Table of contents" | rex field=source "(?<filename>[\w\d\.-]+$)" | lookup email_mapping filename OUTPUT recipient_mail Then use the variable in your alert by setting the recipient field as $result.recipient_mail$ See https://docs.splunk.com/Documentation/Splunk/latest/Alert/EmailNotificationTokens for further details ... View more

1) and 2) Thats highly depending on how you have configured your standalone instance before. If you have all configurations in $SPLUNK_HOME/etc/system/local it might be a bit tedious to distinguish which files you need to copy. If (what is best practice anyway) you stored your configs in $SPLUNK_HOME/etc/apps in one or more dedicated config app(s), you just need to copy the complete apps subfolder. You can copy indexer-only configs to the search head as well, it will just ignore the parameters which are not necessary. Yes, you might have indexes created on the search head in that case, but they will be unused. It's still a possibility to remove the unneccessary configs in a later stage. 3) You should configure the Monitoring Console on one instance only - in that case most probably the search head, as it is a good practice to disable web access to indexers. If you start to configure the MC in distributed mode, you can add other instances there as search peers and this will give you the overview over your complete environment. 4) After initial config this is normal, as without further configuration a search head will store (index) its internal logs. You should configure internal event forwarding for your search head, and then set up the roles in MC as so it is not longer treated as an indexer. ... View more