Hi @man03359 .. the metricName can be either CPUPercentage or MemoryPercentage.  and then, how do you get the value of either CPUPercentage or MemoryPercentage   or.. if you have the values for either CPUPercentage or MemoryPercentage.. then you should be able to run: index=idx-cloud-azure "*09406b3b-b643-4e86-876e-4cd5f5a8be57*" | chart count by index, metricName | where CpuPercentage > 85 AND MemoryPercentage > 85  when you run this Search query, do you get results as you expected ah.. if yes, then you can save it as an alert.  Please let us know if this about search works fine.. if its not working, pls update us how to get the values of either cpu or memory percentage. thanks. 

Hi @AL3Z .. in linux, using the find and grep commands.. you can find all the blacklisted lines recursively.     find . -name '*.conf' -exec grep -i 'blacklist' {}\; -print   grep -Ril "text-to-find-here" / i stands for ignore case (optional in your case). R stands for recursive. l stands for "show the file name, not the result itself". / stands for starting at the root of your machine.    

Hello @inventsekar, Thank you for your response and for sharing the details. I searched about healthcheckup and found it gives information related to configuration changes. I check Job Details dashboard and fetched details of average indexer time which is around 0.9 seconds and time taken by the search to run on each indexer which varied between 0.8 to 1.5 seconds. Thus, can you please share if its suitable to run the scheduled search over Splunk infrastructure or if it can lead to negative implications and issues? The reason to ask is because its scheduled search and cannot afford search failure or infrastructure breakdown, and thus, want to be sure of using the approach. Thank you

This doesn't really answer the question. How about this (to try and clarify what your events mean): Is the count always 1? If so, it appears that average, minimum, maximum and total will always be the same number, right? That is, any one of them could be used as the value for the event? If not, which value do you want to use as the value for the event?

@ITWhisperer  Yes, each event has metricName, listed like this- CpuPercentage and MemoryPercentage are one of the values of metricName. The query has to be built in such a way that it calculates the % of CPU utilization and throws an alert when the CPUPercentage is more than 85%., similarly for MemoryPercentage also.

Hello @isoutamo, Thank you for your response. The scheduled SPL is a report scheduled to run each minute to fetch datapoints for different conditions in each iteration and store them in lookup file so that later I can use the lookup file to directly read data for my analysis and also in dashboards and alerts. This helps to access data faster and load dashboard with all relevant information with lesser time than reading and displaying the data from index. This also helps to access required historical data faster than fetching from index. So as I understand from your inputs, in my current situation all relevant Splunk components are reserved for the scheduled search each minute for 4 seconds for the period of 1 hour. And thus, it works as a normal historical scheduled search with no extra resource workload or causing slowness, breakdowns in Splunk infrastructure due to its implementation. Please share if there is anything else that I need to correct or understand with this implementation. Thank you

Hi @Taruchit ... Some details about Splunk searches: On the Monitoring Console, you can run a healthcheck, which will tell you how the systems performance looks like.  The limits.conf file got settings for controlling how many searches the search head can run(for all types - real time, historical, concurrent, etc)   https://docs.splunk.com/Documentation/Splunk/9.1.1/admin/limitsconf#limits.conf.example [scheduler] # Percent of total concurrent searches that will be used by scheduler is # total concurrency x max_searches_perc = 20 x 60% = 12 scheduled searches # User default value (needed only if different from system/default value) when # no max_searches_perc.<n>.when (if any) below matches. max_searches_perc = 60 # Increase the value between midnight-5AM. max_searches_perc.0 = 75 max_searches_perc.0.when = * 0-5 * * * # More specifically, increase it even more on weekends. max_searches_perc.1 = 85 max_searches_perc.1.when = * 0-5 * * 0,6 # Maximum number of concurrent searches is enforced cluster-wide by the # captain for scheduled searches. For a 3 node SHC total concurrent # searches = 3 x 20 = 60. The total searches (adhoc + scheduled) = 60, then # no more scheduled searches can start until some slots are free. shc_syswide_quota_enforcement = true  

Hi @ChrisValibia ... the Splunk enterprise (on-prim) supports "Duo" multi factor authenticator.  and Splunk Cloud does not support Duo or any multi factor authenticators.    Splunk Docs for your reference: https://docs.splunk.com/Documentation/Splunk/9.1.1/Security/AboutMultiFactorAuth About multifactor authentication with Duo Security Multifactor authentication lets you configure a primary and secondary login for your Splunk Enterprise users. Duo Security multifactor authentication secures Splunk Web logins. Splunk Cloud Platform does not support multifactor authentication with Duo Security.

Try something like this (to avoid joins) index=main source="/media/ssd1/ip_command_log/command_log.log" | eval exec_time=strptime(exec_time, "%a %b %d %H:%M:%S %Y") | rename ip_execut as Access_IP | table Access_IP, exec_time, executed_command | append [ search index=main source="/media/ssd1/splunk_wtmp_output.txt" | dedup Access_time | eval Access_time=strptime(Access_time, "%a %b %d %H:%M:%S %Y") | eval Logoff_time=if(Logoff_time="still logged in", now(), strptime(Logoff_time, "%a %b %d %H:%M:%S %Y")) | table Access_IP, Access_time, Logoff_time ] | eval event_time=coalesce(Access_time, exec_time) | sort 0 event_time | streamstats global=f latest(Access_time) as Access_time latest(Logoff_time) as Logoff_time by Access_IP | where exec_time>=Access_time AND exec_time<=coalesce(Logoff_time,now()) | table Access_IP, Access_time, Logoff_time, exec_time, executed_command

Hi It's like @gcusello said, but I want to add one comment. You should never use splunk as an syslog receiver even it can do it. You will lose event more or less. It's much better to use real syslog servers to manage centralised syslog server. You you could use e.g. rsyslog, syslog-ng or SC4S (Syslog connector for splunk). r. Ismo

Thanks, Does not work.  Also know following. If  src_sg_info does not exist then we know that it's no active VPN user. Does not know how to test src_sg_info existance.  Thnaks again.    Rgds Geir