Hi @ChaoticMike, in Splunk you have: _time that's the event timestamp, _indextime that's the time whe the event is indexed. so you could calculate a difference between these two fields: index=* | eval diff=_indextime-_time | stats avg(diff) AS diff_avg max(diff) AS diff_max min(diff) AS diff_min BY index Ciao. Giuseppe

Try something like this [search ] earliest=-4w | eval current_day = strftime(now(), "%A") | eval log_day = strftime(_time, "%A") | where current_day == log_day | eval hour=strftime(_time, "%H") | eval day=strftime(_time, "%d") | stats count by hour day HTTP_STATUS_CODE | chart avg(count) as average by hour HTTP_STATUS_CODE

Hi @man03359, what do you mean with "src_ips that have mismatched src name and device name."? Maybe src_ips that have different src_name or different device_name? if this is your requirement, please try this: index="idx-network-firewall" (sourcetype="fgt_traffic" OR sourcetype="fortigate_traffic") | lookup Stores_Inventory src_ip OUTPUT Device | stats latest(_time) AS latest values(srcname) as srcname latest(app) as app dc(srcname) AS srcname_count dc(Device) AS Device_count BY src_ip | where srcname_count>1 OR Device_count>1 | table src_ip Device src app In this way you'll list all the src_ips with more than one name or device. Ciao. Giuseppe

| reverse | streamstats current=f window=1 latest(perc_change) as prev_value | reverse | fillnull value=0 | eval growing = if(perc_change< prev_value,1,0) | table _time GB change perc_change prev_value growing

I don't understand what the inputs have to do with the issues on web UI of Splunk. And before the update to 9.1.1 there were no issues like these. I think there's a bug with 9.1.1 causing these issues. If there would be a way to rollback by changing the inputs.conf file I would be fine testing this again. But repeating all the steps I had done yesterday is indiscutable. This is time wasting!

Probably the easiest way is go back to situation when you have done fresh installation and everything is working. Then just add inputs one by one and see which one broke your environment.  This is annoying and long time taking process, but still I thing that this is the easiest way.

You need to read up Linux user management, or ask your SysAdmin how to determine such matters. Understandably, Windows user management is totally different Unix and Linux user management.  Unless your system uses some uncommon admin overlay (which only your SysAdmin can tell you), userdel command can only be executed by root (uid 0).  A non-root user may have sudo privileges to execute commands as root, but this can only be executed as sudo usserdel.  Alternatively, if unprivileged user is allowed root shell, such a user can first use sudo su <shell name> to gain a root shell, then execute userdel in this shell as if it is user root. Most modern Linux systems log full command history.  You didn't say which Linux OS you are using.  You say "(syslog) only shows the name of the user account that was deleted," but without any context like which source file are you looking at.  In Unix-like systems, "syslog" is a OS facility that can be organized in many different ways, i.e., various messages (events) can go to various places. (If you are unsure, ask your SysAdmin.)  You didn't even illustrate a sample log entry. (You can always anonymize; but make sure to preserve formatting and other characteristics.)  Volunteers cannot possibly help with all these ambiguities.

What @PickleRick is trying to say is that you should tell volunteers what "other eventTypes" mean, how their data look like.  I'd like to add Example - If my src_ip=73.09.52.00, then the src_ip should search the other available eventType and filter the result if the user_id=*idp* What does "filter the result" mean?  In many contexts, this phrase is commonly used to mean "to exclude results satisfying such and such."  But in your case, I have a suspicion that you mean the exact opposite. In addition to this question, you also fail to tell volunteers which data do you expect to include AFTER "filter the result"?  Are you interested only in fields from "other eventTypes"?  Only in fields from eventTypes security.threat.detected and security.internal.threat.detected?  Or some fields from eventTypes security.threat.detected and security.internal.threat.detected, some fields from "other eventTypes"?  Which ones? When you ask a question in a user forum, you need to give all and precise relevant information in terms of data, desired results, and the logic between data and desired logic, and not make volunteers take wild guesses.