@JohnGreggFrom what I've read, Java agents should be dividing by processor count: CPU millis / time / processor_count But if you're not seeing that in your K8s results, maybe the cluster agent works differently than regular Java agents? For the cluster agent metrics, I know it treats 1 CPU = 100%, so multi-core usage gives you >100%. Might be worth checking if you're looking at app agent metrics vs cluster agent metrics - they could calculate differently. If this helps, Please Upvote. ... View more

@oawill  mltk_ai_commander_dataset.csv is a training dataset that ships with MLTK 5.6.0 and higher specifically for hands-on exercises with the LLM integrations feature. This dataset contains example data used to train models to distinguish between malicious and benign PowerShell scripts. Since this is an example training dataset provided by Splunk for educational/demonstration purposes with the MLTK, the specific authorship and attribution details may not be extensively documented in the traditional dataset credits format. The dataset is designed as sample data for users to practice with the AI Commander functionality. If this Helps, Please Upvote. ... View more

@isoutamo is exactly right about the 9.2 changes! To help troubleshoot this further, you should check a few things to understand why the forwarders aren't connecting properly to the DS. Start by testing connectivity from each forwarder using telnet or netcat to make sure they can actually reach the deployment server on port 8089. Next, examine your serverclass.conf on the Deployment Server to verify that your forwarders match the whitelist criteria and that the client matching is configured properly. Many times the issue is that the serverclass isn't set up to recognize your specific forwarders. On the forwarder side, run btool deploymentclient to see what configuration is actually being applied. This will show you if there are any conflicting settings or if the deploymentclient.conf isn't pointing where you expect it to. If your deployment server is forwarding its internal logs to your indexer, you might also need to add the indexAndForward settings in outputs.conf on the DS, as this can affect how deployment client data appears in the management UI after 9.2. Just to confirm, are you also managing your Search Head and indexer through the Deployment Server? And is this truly a distributed setup with separate VMs, or multiple Splunk instances on one box? That architecture detail might help explain what you're seeing. If this Helps Please Upvote! ... View more

@heathramos Thanks for the update, glad it worked out.  ... View more

@heathramos  yeah this is going to be a fun one. You've got data model issues, which is way more involved than just fixing a macro. Data models are these complex hierarchical things with parent/child datasets that need to be built and accelerated properly - it's a whole thing. Looking at that search, it's trying to pull from datamodel=pan_firewall with specific node relationships. If that's not set up right (or at all), nothing's going to work. And troubleshooting data models means digging into dataset structures, field mappings, acceleration status - it's honestly not a quick fix. If you need this dashboard working soon and it's important to the business, you might want to just work with Splunk ondemand services. They can sort out your data models properly instead of you spending days figuring out why the acceleration isn't working or why the field extractions are wrong. If you want to try,  spend  some time in Settings > Data Models, checking what's actually there vs what the dashboard expects. You'll probably end up either rebuilding data models from scratch or rewriting all these tstats searches to use regular SPL. It's more like -audit your entire Palo Alto data ingestion and modeling setup. If this Helps Please Upvote.   ... View more

@heathramos  Since the p_index macro doesn't exist, here's how to dig into the dashboard and fix it: Edit the dashboard directly: Go to your  dashboard Click the Edit button (top right) Click on each panel/visualization that's not showing data Click Edit Search for each one magnifying glass You'll see searches that start with `p_index` sourcetype="pan:xdr_incident" Replace the macro with your actual index: Change `p_index` to index=pan (or whatever your actual Palo Alto index is called) So the search becomes: index=pan sourcetype="pan:xdr_incident" Do this for every search in the dashboard. There are probably 8-10 different searches based on your dashboard config. While you're in there, also check: Does sourcetype="pan:xdr_incident" match your actual data? Run index=pan | stats count by sourcetype first to confirm If your sourcetype is different (like pan:incident or cortex:xdr), update those too   ... View more

@heathramos Your dashboard isn't populating because it's looking for data in places that don't exist in your environment.  The main culprit is probably the p_index macro. Your dashboard is using `p_index` but this macro either doesn't exist or isn't pointing to the right place. Go to Settings > Advanced Search > Search Macros and see if you have one called p_index. If not, create it. If yes, make sure it's set to your actual Palo Alto index. tip: When you're in the Search app, you can Cmd+Shift+E (Mac) or Ctrl+Shift+E (Windows) to expand macros in your search and see what they actually resolve to. This will show you exactly what `p_index` is doing. Second issue - sourcetype mismatch. The dashboard expects sourcetype="pan:xdr_incident" but your data probably has a different sourcetype. Run this to see what you actually have: index=pan | stats count by sourcetype Quick test: Try running the base search manually with your actual values instead of the tokens. Replace $severity$ with * and see if you get any results. The dashboard is basically looking for some field names like incident_id, severity, status etc. If your XDR data doesn't have these exact field names, nothing will show up. Most of these Palo Alto app dashboards assume you've configured everything exactly as Palo Alto intended, but real environments are messier. You'll probably need to either: Fix your data inputs to match what the dashboard expects, OR Edit the dashboard searches to match your actual data structure Start with that macro expansion trick and sourcetype check - those are usually the smoking guns. Good luck! If this Helps, Please Upvote. ... View more

@nareshkareeti try  | tstats summariesonly=true count FROM datamodel=Network_Traffic WHERE (All_Traffic.src_ip=* OR All_Traffic.dest_ip=*) BY All_Traffic.src_ip, All_Traffic.dest_ip | `drop_dm_object_name("All_Traffic")` ... View more

@GeneralBlack we might need to re-install the previous splunk version for this, best approach is to work with support. https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/9.3/administer-the-app-key-value-store/migrate-the-kv-store-storage-engine#Upgrade_KV_store_server_to_version_4.2 Try this go to login.splunk.com > support > support portal  > Need help? > Create a Case if this Helps, Please Upvote ... View more

@GeneralBlack Please work with splunk support, may be its missing the the mongod folder and it was not created after upgrade? ... View more

@Lien unfortunately, its not supported for the splunkcloud trial version. https://docs.splunk.com/Documentation/SplunkCloud/latest/Admin/TypesofSplunkClouddeployment       If this Helps, Please Upvote! ... View more

@ND1 It's not easy to troubleshoot without a screen share, but typically I recommend: Check the time filter on each dashboard panel Click the magnifying glass on the panel to view the search Expand the search to see what's actually running - you'll typically see macros there Expand those macros using Ctrl + Shift + E (Windows) or Cmd + Shift + E (Mac) Run the expanded search with a broader time range to see if data appears also check Time range mismatch: The ES dashboard is looking for recent data while your correlation search finds older events Data model acceleration: Your correlation search might need CIM-compliant field mappings Dashboard filters: Check if the dashboard has hidden drilldown tokens or filters applied check out this user guide: https://help.splunk.com/en/splunk-enterprise-security-8/user-guide/8.0/analytics/available-dashboards-in-splunk-enterprise-security Additional help: If you have Splunk OnDemand Services credits available, I'd recommend using them to walk through this issue with a Splunk expert who can troubleshoot in real-time. If this Helps, Pleas Upvote. ... View more

@ND1 Most probably when an incident is not showing up, it's either suppression blocking the events or the notable action not being properly configured. 1. Check if notable events are being created: index=notable earliest=-7d | search source="*your_correlation_search_name*" 2. Check suppression settings: | rest /services/saved/searches | search title="*your_correlation_search_name*" | table title, alert.suppress, alert.suppress.period Try below: If alert.suppress=1, try disabling suppression temporarily in ES > Content Management Edit your correlation search and ensure "Notable" action is checked and saved Test your correlation search manually first to confirm it returns results If this Helps, Please Upvote.   ... View more

  I think there is no easy way because, as @richgalloway  mentioned, there is no warning when a search tries to use an index that doesn't exist. Even if you choose result_count=0, you will get a lot of false positives. The best way is to run a search against the saved searches and validate with your existing indexes. The most reliable approach is the manual two-step method: Step 1: Get scheduled searches and their referenced indexes     | rest /services/saved/searches | search disabled=0 is_scheduled=1 | rex field=search "index\s*=\s*(?<referenced_index>[^\s\|]+)" | stats values(title) as searches by referenced_index Step 2: Get your current indexes     | rest /services/data/indexes | fields title If this Helps, Please Upvote. ... View more

@Kowshik looks like Splunk Observability Cloud could not connect with AWS. Review your authentication credentials and make sure you have proper access to all the regions on the list below. us-east-1 us-east-2 us-west-1 us-west-2 https://help.splunk.com/en/splunk-observability-cloud/get-started/service-description/splunk-observability-cloud-service-description#available-regions-or-realms-0 Refer: https://help.splunk.com/en/splunk-observability-cloud/manage-data/connect-to-your-cloud-service-provider/connect-to-aws/troubleshoot-your-aws-integration#splunk-observability-cloud-doesnt-work-as-expected-0   If this Helps, Please Upvote. ... View more

@Raj_Splunk_Ing  try  | eval date_only=strftime(strptime(replace(ClintReqRcvdTime, "\s+", " "), "%a %d %b %Y %H:%M:%S :%N EDT"), "%m/%d/%Y") ... View more

Hey @Karthikeya , Yeah, this is a pretty common issue and you're on the right about concurrent searches and quotas. From what you're describing, it sounds like you're hitting some resource limits. Here's what's likely happening: Check your role-based search quotas first: Go to Settings > Access controls > Roles Look at the roles your affected users have Check their "srchDiskQuota" and "srchJobsQuota settings With 100 roles, you might have some with really restrictive limits The "no jobs showing up" thing is typical - users often can't see queued/background jobs in their job manager, especially if they're system-generated or from other sessions. Things to look at: Infrastructure capacity - Are you actually running out of search head resources? Check your monitoring console for search concurrency and resource usage Role quotas vs actual demand - Your users might need higher concurrent search limits than what their roles allow Dashboard design issues - Heavy dashboards with tons of panels and no base searches can eat up concurrent search slots fast Quick fixes to try: Temporarily increase disk quotas for affected roles (but watch your infrastructure) Have users refresh their dashboards less frequently Look for dashboards that could use base searches instead of running everything separately To see what's actually queuing up, check your internal logs for that exact message you mentioned: "The maximum number of concurrent historical searches for this user based on their role quota has been reached." Start with the role quotas - that's usually the quickest win.  refer: https://splunk.my.site.com/customer/s/article/Search-Concurrency-The-maximum-number-of-concurrent-has-been-reached If this Helps, please Upvote. ... View more

Hey @danielbb , Did you already check out the developer-supported Tenable App for Splunk? It should work with your sourcetypes: https://splunkbase.splunk.com/app/4061 Here's the docs for it: https://docs.tenable.com/integrations/Splunk/Content/Splunk2/TenableAppforSplunk.htm And there's also a full integration guide PDF that might be helpful: https://docs.tenable.com/integrations/Splunk/Content/PDF/Tenable_and_Splunk_Integration_Guide.pdf This might give you dashboards and visualizations for your Tenable.io data.  Cheers If this Helps, Please Upvote ... View more

Hey @mohsplunking , So a couple things on your setup: First, just to clarify - the UFs actually pull from the DS, not push to it. The deployment server is more like a config store that the forwarders check in with and grab their apps/configs from. And yeah, you're totally right about needing the Windows TA on your heavy forwarder. You might see data without it, but you definitely want it installed on whatever's doing the parsing - which is your HF in this case. Otherwise you'll miss out on proper field extractions and parsing. Here's the install doc: https://docs.splunk.com/Documentation/WindowsAddOn/8.1.2/User/Install Yes - Windows TA goes on the HF (since that's where parsing happens), and then your output app handles forwarding everything along to the indexers. Cheers If this Helps, please Upvote ... View more

@Nraj87 Please follow this: https://docs.splunk.com/Documentation/ES/7.3.3/User/Howurgencyisassigned#Modify_the_urgency_lookup_directly Modify the urgency lookup directly You can change which severity and priority values result in which calculated urgency values for notable events in Splunk Enterprise Security. Only specific values are valid for severity or priority values. Use only those values when modifying the lookup. Do not modify the names of the notable event urgency values. Valid severity values: unknown, informational, low, medium, high, critical. Valid priority values: unknown, low, medium, high, critical. Valid urgency values: informational, low, medium, high, critical. On the Enterprise Security menu bar, select Configure > Content > Content Management. Choose the Urgency Levels lookup. An editable, color coded table representing the urgency lookup file displays. In any row where the priority or severity is listed as unknown, review the assigned urgency. (Optional) Edit the table and change the urgency to another one of the accepted values. All urgency values must be lower case. Click Save. If this Helps, Please Upvote! ... View more

 @gopu  never used AppDynamics, in studio go to the json source code for each markdown. ... View more

@Gopikrishnan_Ra did you already try editing the source code and add explicit font settings like "fontSize": "medium", "fontType": "proportional" to each visualization? could be rendering issue ? What version are you on? If this helps, Please Upvote. ... View more