You have two options. Either use the | rex mode=sed "s/find/replace/g" at runtime, or use a SEDCMD at index time, like so: In props.conf : [my_source_type] SEDCMD = s/find/replace/g Now, if if you are asking if you case setup something like a SEDCMD that gets run at search time, then the answer is no. Here is a possible workaround: If your sed command is really long and ugly and you simply don't want to see it or don't want to repeat it in multiple searches, then I would suggest that you create a macro with your rex . I think that's the best you can do. ... View more

Some random thoughts. In no particularly organized order. Double check your eval field renaming approach ( eval code=Error ) I would try either rename Error as code or eval code=coalesce(Error,code) since you may only want to conditionally rename a field. (If you have the "Error" field in some events and "code" in other events) Instead of trying to pull together events based on date_* fields, you really should look into using transactions instead, which have a building in time correlation effect. You may find that using a dashboard with multiple panels would be a simpler approach to correlating this information manually. (Maybe not, just a thought) If you want to jump into some really advanced XML, you can really customize the drill-down actions in Splunk 4.1. Take a look at the 3-level drill down provided in the search app: http://localhost:8000/en-US/app/search/indexing_volume (click on an index, then on an time in the timechart, and you see those events load. This is a really cool way to drill down into your log data, but it does take work to setup.) Consider using workflow actions (based on eventtypes or field combinations) to let the user drill down from one search to another. See Create workflow actions in Splunk Web. Combine all your sourcetypes into one big massive single search and use transaction to pull it all together. You hinted at this in your question. I made some notes in the following section... For an all in one type search approach, you may find if useful to mentally split your search into separate phases. Each phase will contain at least one search command, but often more than one. It's generally helpful to develop your search starting with the first phase, and not moving on to the next until your sure the current phase is working properly. Trying to write this all in one shot will just cause lots of frustration. Hopefully when it all comes together you'll have a working search when your done, but it doesn't always work out that way. (Hints: Sometime I find it helpful to take a portion of the search an run it in a separate browser session and then copy it back into my full search once I have the desired change. Also, if you find some part of the search isn't working the way you expect, it's often easier to go build a simple test case with a simpler search, make sure your understand how/why works the way it does, and then go back to your massive search and adjust accordingly.) Here's some suggested phases for this type of search: Determine your base search criteria - This should include all host restrictions and all the sorucetypes your are looking for. Possibly leveraging eventtypes if you have them setup. Tags are also helpful in this step. Common field tweaking - This is where you will have to do any field extractions, field renaming, or other search-based field interactions necessary. The idea here is to make sure that all of your events have enough common values to build a transaction. In your example this will probably be something like 'clientip' and possibly 'sessionid'. Some examples of things that would need to be fixed in this phase would be: (1) different events have different fields names for the same value. (2) Some values appear in different cAsE, or you see "True" when other times you get a "1". (3) you have to conditionally create a field based on a search term... All of these can easily be accomplished with the eval command. (If you really want to get fancy, you can event compensate for a fixed clock-drift between your hosts in this phase) build the transaction - Use the transaction command to correlate all your related events into transaction post-transaction search - Use a search command to filter out non-error events. You could also put some kind of statistical analysis here if you want (e.g. stats or chart like command) ... View more

Are you talking specifically sourcetype=syslog or just any events from a host? It's easy to do any events from a host with something like this: | metadata index=main type=hosts | eval age = now()-lastTime | where age > (2*86400) | sort age d | convert ctime(lastTime) | fields age,host,lastTime Does that work for you? ... View more

Yes. This is very doable. I would recommend checking out the following search commands to get started: stats chart timechart If you are pretty new to splunk. Check out How search commands work and go from there. There is also a basic search tutorial that is very helpful in walking though basic commands too. ... View more