Assuming you have fields extracted, have you tried: YourSearch | stats first(DefNumber) by host First will grab the first log that Splunk finds, which should always the most recent event, in this scenario. ... View more

Porting my answer to the new splunk-base: I believe what you want in your props.conf is: [imd-log] REPORT-PullTSVFields = imd-header-fields You also stated sourcetype=imd-logs whereas you have imd-log in the header. You'll need to make sure that the stanza header in props.conf matches your sourcetype exactly. In the old answers site, you followed-up with: Thank for the reply. Also, is there a way for splunk to replace it's internal date (i.e. the ones that shows up in the 'search' app) with the date specified by 'logdate'?) Splunk should automatically pick that up. What are you seeing as the time when you do a search? ... View more

Since it appears there is no good way to do that, I've taken the following tact: Outside of Splunk, I have a script that parses the log files, and outputs only new or changed entries to the end of a logfile that Splunk monitors. My data then looks like: Timestamp,Datacenter,Hits,Misses "2011-01-01 01:10:00","Singapore",3553,245 "2011-01-01 01:20:00","Singapore",5253,386 "2011-01-01 01:30:00","Singapore",1253,124 "2011-01-01 01:20:00","Singapore",1449,154 I have it go to a separate index. This log source happens to be very small, and putting it in a different index allows one bucket to contain a lot of data. My (unverified) theory is that if it went to main, it would mess with the date range timestamps on the very busy buckets, and create inefficiencies. That may not be true, but creating a separate index works for both performance and erring on the side of caution. All of my searches first execute a | bucket _time span=10m | stats first(Hits) as Hits, first(Misses) as Misses by datacenter, _time . That way I can use my normal searches, without dealing with old or duplicate data. I have a nightly crontab that will delete my summary indexes for the last few days ( earliest=-3d@d | delete ) and then re-index them. That will also produce some bucket-time issues, but it hasn't been a big problem so far. ... View more

I would go with an appendcols here, which is similar to a join. The way you can get around the time issue is by overriding the time for the second search: index=summary source="dailysearch" earliest=-7d@d latest=@d | stats count as TotalA | appendcols [search index=summary source="hourlysearch" earliest=@d latest=now | stats count as TotalB] | eval Total=TotalA+TotalB | fields Total The only complication here is that you'll need to specify an earliest in the first search. At least in the test I just ran, specifying only a latest overrode both the latest and the earliest. If you're trying to put this in a dashboard with a timepicker, that might not work for you. One way around this would be to code up a custom time picker, a la this answers, but you'd lose the dynamic (and standardized) power of timepicker that way. You could also get around it this way: index=summary source="dailysearch" | eval ItemA=if(_time < relative_time(now(), "@d"),1,0) | stats sum(ItemA) as TotalA | appendcols [search index=summary source="hourlysearch" earliest=@d latest=now | stats count as TotalB] | eval Total=TotalA+TotalB But this would add the inefficiency of running the dailysearch from @d to now. Based on the notion of it being for summary indexes, I'd imagine that's not going to have a significant performance impact for you. ... View more

If you don't care about the domain (as in, it's always going to be *user.org and you're just looking for jsmith), I would probably go the route of pulling out just the user addresses. Depending on the variance in your logs, you could either go generically: YourSearch | rex field=_raw "(?<Username>\S*)@\S*" or more specifically: YourSearch | rex field=MAIL_TO "(?<Username>\S*)@" | rex field=SMTP_RCPT_TO "(?<Username>\S*)@" You can also convert the username to lowercase: YourSearch | rex field=MAIL_TO "(?<Username>\S*)@" | rex field=SMTP_RCPT_TO "(?<Username>\S*)@" | eval Username=lower(Username) If you are concerned about grabbing other domains, and really only care about a particular domain, you could alter the regex: YourSearch | rex field=MAIL_TO "(?<Username>\S*)@\S*user.org" | rex field=SMTP_RCPT_TO "(?<Username>\S*)@\S*user.org" | eval Username=lower(Username) That doesn't get you 100% of the way there, as you'll still need a | search Username=foo OR Username=bar at the end, but it should get you closer, certainly. ... View more

The right way to do it is to first have the nonce extracted in your props.conf (this simplifies the rest), such as: [YourSourcetype] EXTRACT-nonce-failure = Failed with nonce (?<nonce>[0-9a-z-]*) EXTRACT-nonce-created = nonce created : (?<nonce>[0-9a-z-]*) You can then do a subsearch first for the failure nonces, and send that to the main search: sourcetype="log4j" source="*server*" | transaction thread startswith="startTx" endswith="closeTx" | search [search sourcetype="log4j" failed nonce | fields nonce] I believe that should work, at least. What is more efficient, though, assuming that the nonce failure messages also reference the thread field, is to first isolate the failure threads, and then search for the transactions where they're there: [search sourcetype="log4j" failed nonce | fields thread] sourcetype="log4j" source="*server*" | transaction thread startswith="startTx" endswith="closeTx" That should give you a shortcut to a transaction that includes only the threads that have failed nonces. One bit of minutia is that depending on the number of threads that are re-used, you might need to re-run the limiting search at the end: [search sourcetype="log4j" failed nonce | fields thread] sourcetype="log4j" source="*server*" | transaction thread startswith="startTx" endswith="closeTx" | search "Failed with nonce" The reason why it's more efficient to limit what hits the transaction command is that transaction is very slow. Let me know if that works for you. ... View more

This doesn't appear to be possible at this juncture, but has been filed as an enhancement request. Rationale provided for the change: As it currently stands, this is messy and a disincentive to publishing Apps to Splunkbase. It's a hassle to maintain two copies for an app -- one for Splunkbase and one for internal consumption, so exporting views is valuable. But filling the nav on user-facing apps with lots of totally unrelated objects makes it difficult to use, and makes users less likely to actually use Splunk for anything but pre-canned reports. ... View more