I'm trying to use the REST API Mod Input to persist a timestamp parameter. Each time I make a request of the API I'm working with, it responds with the authoritative end timestamp that it is returning data for. Between subsequent executions, I need to store this value, so it can be provided with the next execution. I've read most of the threads here on Answers, trying to find someone doing what I'm looking for. I can't seem to find anywhere there or in the Python code of the app that shows handling persistent tokens across REST input executions. Is this just unsupported? I have another API where I'd use this, but the checkpoint that API provides is a UUID that operates in the same way - each subsequent API call needs to provide the UUID sent in the previous response. ... View more

I have a group of users to monitor. They create actions on a fairly regular basis, but they do not all follow the same pattern. Some perform this particular action 4x/hour, some 2x/hour, and some only 2x/day. What I would like to do is create a search that allows me to compare the previous hour of activity to the last 30 days and determine whether the past hour of activity is within "normal" or if their activity has dropped below a threshold. So my thought is to calculate the avg and stdev for each hour of the day (0-23), per user. Then I could compare that data in the same search to the previous hour and see whether historical_avg_for_given_user_for_given_hour - historical_stdev_for_given_user_for_given_hour > activity_count_for_given_user_for_last_hour and if so, raise an alert for that user. So that's the goal. I have been looking at "Time After Time – Comparing Time Ranges in Splunk" from @Anonymous, but I'm not sure how to apply that to a multi-user scenario. Here's what I have so far: [base search] earliest=-14d@d latest=-1d@d | eval time_hour = strftime(_time, "%H") | eval time_day = strftime(_time, "%D") | stats count AS count_perhour_perday_peruser BY time_hour, time_day, userName | chart limit=0 avg(count_perhour_perday_peruser) BY time_hour, userName ... View more