I see what you mean. I would change your bin span to 12 hours and then try and focus the earliest time of your search in the time range picker to start at either 6pm or 6am on a given day. That might trigger the 12 hour buckets to start at 6am/6pm. ... View more

You could try creating two searches, then appending them together and charting them on the same chart. There may be easier ways of doing this and I have not fully tested the method below but you would try something like: some search (date_hour<6 OR date_hour>18) | eval hours="NON-WORKING" | fillnull value=novalue | timechart count span=24h by hours | append [some search (date_hour>6 OR date_hour<18) | eval hours="WORKING" | fillnull value=novalue | timechart count span=24h by hours] | timechart span=24h sum(count) by hours This way you will have two series on your graph. One for "NON-WORKING and one for "WORKING". ... View more

Ah I see. Looks like you got your answer above! Good luck! 🙂 ... View more

Well, that is only true if "test" and "hello" are not individual tokens. I.E. If I search as follows: index=X test hello @ | rex email="test.*hello@.*" This will NOT return any results IF the data you are looking for is something like "testworldhello@something.com" This is because you cannot search for "test" or "hello" on their own if they are just a part of a larger token (testworldhello). The search above WILL return results if the data looks like: "test.world-hello@something.com" The main point I am trying to make is that to create better search efficiency you can provide as many actual tokens as you can, up front. Tokens are separated by things like dots, dashes, slashes, etc. To see how tokens are identified and separated in Splunk you can research segmenters.conf which shows you how Splunk breaks out tokens in any event. ... View more

From quickly scanning through some documentation, it seems that "rex" is actually a "distributed streaming" command which means it can be run on the indexer itself so you don't have to worry about innefficiencies with map-reduce. However, to better structure your search you can provide all the "known search tokens" to your search and you could do something like this: index=x test @ | regex email="test@.*" What this does is it passes the known "search tokens" of "test" and "@" as search tokens to the indexer which allows the indexer to pull out only events with those two tokens anywhere in the event. THEN the "rex" will do the specific pattern match. I dont think doing the rex on it's own will allow the indexer to search for events where ONLY "test" and "@" are present. It will have to search ALL events first. So the search above reduces inefficiencies because it puts everything that you know you need before the first pipe and then allows the rex to do the pattern matching afterwards. ... View more

"Data inputs -> forwarded Inputs - > files and directories" is used when you wish to monitor a LOCAL file/directory on that server and then forward the data from that monitoring to another server (such as an indexer) In a distributed environment, this feature of the UI is going to provide you little to no value. On your question as to where to configure the process of monitoring files on forwarders, you should configure "apps" in the deployment server and then deploy these apps to all of your forwarders machines. (Assuming that you have configured your forwarders as clients of the deployment server and to periodically check in with the deployment server to check for new "apps" to download). There is plenty of documentation on Splunk's website for this. Here are some helpful links: About Deployment Server Deployment Server Architecture ... View more