Hi @ws, Is there a reason you're opposed to port redirection/forwarding? It's the least intrusive way to manage the traffic and works with SELinux etc. If you're using Linux with firewalld, run Splunk as a non-root user and configure a UDP input on any available port above 1023, e.g., 9514/udp. You can then configure firewalld to locally forward 514/udp traffic to 9514/udp: # add the forwarding rule sudo firewall-cmd --permanent --add-forward-port=port=514:proto=udp:toport=9514:toaddr= # enable the syslog service; see /usr/lib/firewalld/services/syslog.xml sudo firewall-cmd --permanent --add-service syslog # reload firewalld sudo firewall-cmd --reload Adapt the firewall-cmd arguments to zones if needed. ... View more

Hi @munang, Splunk is aware of fields through fields.conf, props.conf, and other settings. Search A can be optimized with the TERM() function: index=main TERM(192.168.172.10) [ AND 192.168.172.10 index::main ] All events with 192.168.1.172.10 as an indexed term will be returned. If src_ip is an indexed field, search B can be optimized using the :: operator or by modifying fields.conf (see fields.conf.spec for more information): index=main src_ip::192.168.172.10 [ AND index::main src_ip::192.168.172.10 ] If src_ip is not an indexed field but 192.168.172.10 is an indexed term, you can optimize by combining the = operator and the TERM() function: index=main src_ip=192.168.172.10 TERM(192.168.172.10) The lispy will vary with your configured field extractions, field aliases, etc., but it will begin with the IP address as an indexed term: [ AND 192.168.172.10 index::main [ ... ] ] If the IP address is an indexed term but src_ip is not equal to the IP address, the event will be scanned but not returned. Search terms are segmented similarly to indexed terms. See segmenters.conf.spec, https://help.splunk.com/en/splunk-enterprise/search/search-manual/10.2/search-primer/event-segmentation-and-searching, and https://help.splunk.com/en/splunk-enterprise/administer/manage-indexers-and-indexer-clusters/10.2/indexing-overview/index-time-versus-search-time for more information. ... View more

Hi @BradOH, You may find this app useful as a starting point for exploring other algorithms: https://github.com/groktrev/abydos Abydos is GPLv3, so the app is necessarily GPLv3 as well. To install the app, download and extract the repo to $SPLUNK_HOME/etc/apps/abydos/ or run the following command from the $SPLUNK_HOME/etc/apps/ directory: git clone https://github.com/groktrev/abydos.git After that, restart Splunk. I haven't packaged the app for Splunkbase. From the README I just drafted: Introduction Community App for Abydos is a Splunk wrapper for the Abydos library. The abydos streaming search command provides access to the abydos.distance, abydos.fingerprint, abydos.phonetic, abydos.stemmer, and abydos.tokenizer modules using default class parameters and the dist_abs(), fingerprint(), enocde_alpha() or encode(), stem(), and tokenize() functions, respectively. See the Abydos documentation for available algorithms. Algorithms requiring SyllabiPy, NLTK, PyLZSS, or paq are not implemented. Requirements Community App for Abydos requires a non-EOL version of Splunk Enterprise and Python for Scientific Computing: Python for Scientific Computing (for Linux 64-bit) Python for Scientific Computing (for Mac Apple Silicon) Python for Scientific Computing (for Mac Intel) Python for Scientific Computing (for Windows 64-bit) Examples Return the Levenshtein distance between two field values: | abydos module=distance algorithm=Levenshtein field1 field2 Return the skeleton key string fingerprint of a single field value: | abydos module=fingerprint algorithm=SkeletonKey field1 Return the Beider-Morse encodings of a single field value: | abydos module=phonetic algorithm=BeiderMorse field1 Return the English stem of a single field value: | abydos module=stemmer algorithm=Porter field1 Return the q-grams of a single field value: | abydos module=tokenizer algorithm=QGrams field1 ... View more

With the prototype in hand, any analyzer, codec, etc. could step in for metaphone. I've ironically just come off working with a competing product that makes searches like this trivial, but its out of the box limitations are similar to Jellyfish. ... View more

The accelerated data model gives you a rough implementation of a fuzzy match operator. Using the add-on's streaming command does give you search-time access to comparisons, but the command as published doesn't work as an alternative to Splunk's term analyzer. It's also a rare case where a fields.conf stanza is necessary. ... View more

I didn't call it out above, but encodings that accommodate Unicode look-alike characters would be a nice complement to phonetic encodings, particularly in threat hunting and detection engineering. ... View more

Hi @BradOH, Are you using JellyFisher from Splunkbase? We can use JellyFisher to build a prototype natural language data model based on various codecs, e.g., metaphone. Newer versions of the Jellyfish module or codecs with expanded language coverage, e.g., Beider-Morse as referenced by @bowesmana, can replace the external lookup described below. We could also blend in matching by similarity, e.g., Levenshtein distance, and stem. Start by downloading and installing JellyFisher. Verify JellyFisher with a simple search. I'm using variations on my given name: | makeresults format=csv data=" src_user,src_user_domain travis@example.com,example.com trefor, trev, trever@example.com,example.com trevon@example.com,example.com tr3v0r, trev0r, trevor, " | rex field=src_user "(?<src_user_local_part>[^@]+)" | jellyfisher metaphone(src_user_local_part) src_user src_user_domain src_user_local_part metaphone travis@example.com example.com travis TRFS trefor trefor TRFR trev trev TRF trever@example.com example.com trever TRFR trevon@example.com example.com trevon TRFN tr3v0r tr3v0r TRFR trev0r trev0r TRFR trevor trevor TRFR trefor, trever, tr3v0r, trev0r, and trevor are encoded as TRFR. I'll use this example throughout. Let's create an external lookup script to allow Splunk to automatically add JellyFisher output to events at search time. In $SPLUNK_HOME/etc/apps/jellyfisher/bin, create jellyfisher_lookup.py: #!/usr/bin/env python import csv import os import sys splunkhome = os.environ["SPLUNK_HOME"] sys.path.append(os.path.join(splunkhome, "etc", "apps", "jellyfisher", "lib")) import jellyfish def main(): if len(sys.argv) != 2: print("Usage: python jellyfisher_lookup_metaphone.py field", file=sys.stderr) sys.exit(1) field = sys.argv[1] infile = sys.stdin outfile = sys.stdout r = csv.DictReader(infile) w = csv.DictWriter(outfile, fieldnames=r.fieldnames + ['metaphone']) w.writeheader() for result in r: if result[field]: value = result[field] result['metaphone'] = jellyfish.metaphone(value).strip() w.writerow(result) main() We can test the script locally using the Splunk CLI: $ echo -e 'foo\ntrevor' | /opt/splunk/bin/splunk cmd python jellyfisher_lookup_metaphone.py foo foo,metaphone trevor,TRFR Edit $SPLUNK_HOME/etc/apps/jellyfisher/local/transforms.conf: [jellyfisher_metaphone] external_cmd = jellyfisher_lookup_metaphone.py field fields_list = field, metaphone python.version = python3 Restart Splunk. Verify the jellyfisher_metaphone lookup: | makeresults format=csv data=" src_user,src_user_domain travis@example.com,example.com trefor, trev, trever@example.com,example.com trevon@example.com,example.com tr3v0r, trev0r, trevor, " | rex field=src_user "(?<src_user_local_part>[^@]+)" | lookup jellyfisher_metaphone field as src_user_local_part output metaphone as src_user_phonetic src_user src_user_domain src_user_local_part src_user_phonetic travis@example.com example.com travis TRFS trefor trefor TRFR trev trev TRF trever@example.com example.com trever TRFR trevon@example.com example.com trevon TRFN tr3v0r tr3v0r TRFR trev0r trev0r TRFR trevor trevor TRFR To glue your mail server's add-on to the lookup, create a field extraction, field alias, or calculated field to extract a new field named src_user_local_part from your source events. For example, use SplunkWeb to add a calculated field to Splunk Add-on for Microsoft Office 365 (splunk_ta_o365): Destination app: splunk_ta_o365 Apply to: sourcetype named o365:reporting:messagetrace Name: src_user_local_part Eval expression: mvindex(split(src_user, "@"), 0) Edit permissions and export the object globally: Object should appear in: All apps (system) Set permissions by roles per your security schema. The default is typically read for everyone and write for admin and power. Alternatively, edit $SPLUNK_HOME/etc/apps/splunk_ta_o365/local/props.conf: [o365:reporting:messagetrace] EVAL-src_user_local_part = mvindex(split(src_user, "@"), 0) and $SPLUNK_HOME/etc/apps/splunk_ta_o365/metadata/local.meta: [props/o365%3Areporting%3Amessagetrace/EVAL-src_user_local_part] access = read : [ * ], write : [ admin, power ] export = system Create a new automatic lookup: Destination app: splunk_ta_o365 Name: jellyfisher_metaphone Lookup table: jellyfisher_metaphone Apply to: sourcetype named o365:reporting:messagetrace Lookup input fields: field = src_user_local_part Lookup output fields: metaphone = src_user_phonetic Edit permissions and export the object globally. Alternatively, edit $SPLUNK_HOME/etc/apps/splunk_ta_o365/local/props.conf: [o365:reporting:messagetrace] LOOKUP-jellyfisher_metaphone = jellyfisher_metaphone field AS src_user_local_part OUTPUTNEW metaphone AS src_user_phonetic and $SPLUNK_HOME/etc/apps/splunk_ta_o365/metadata/local.meta: [props/o365%3Areporting%3Amessagetrace/LOOKUP-jellyfisher_metaphone] access = read : [ * ], write : [ admin, power ] export = system Create an event type and tag to identify events with src_user_local_part: Destination App: splunk_ta_o365 Name: phonetic Search string: src_user_local_part_phonetic=* Tag(s): email,phonetic Color: none (or a color of your choice) Priority: 1 (Highest) Edit permissions and export the objects globally. Alternatively, edit $SPLUNK_HOME/etc/apps/splunk_ta_o365/local/eventypes.conf: [o365_reporting_messagetrace_phonetic] search = sourcetype=o365:reporting:messagetrace src_user_phonetic=* and $SPLUNK_HOME/etc/apps/splunk_ta_o365/local/tags.conf: [eventtype=o365_reporting_messagetrace_phonetic] email = enabled phonetic = enabled and $SPLUNK_HOME/etc/apps/splunk_ta_o365/metadata/local.meta: [tags/eventtype%3Do365_reporting_messagetrace_phonetic] access = read : [ * ], write : [ admin, power ] export = system To make the src_user_phonetic field searchable, edit $SPLUNK_HOME/etc/apps/splunk_ta_o365/local/fields.conf: [src_user_phonetic] INDEXED = false INDEXED_VALUE = false Restart Splunk. Verify the configuration: index=main sourcetype=o365:reporting:messagetrace src_user_phonetic=TRFR | table src_user src_user_local_part src_user_phonetic tag src_user src_user_local_part src_user_phonetic tag trefer@example.com trefer TRFR email phonetic trevor@example.com trevor TRFR email phonetic trever@example.com trever TRFR email phonetic To create a summary index of the src_user_phonetic field, we can create or edit a data model. Let's clone and edit the Splunk CIM Email data model for this example. In production, I recommend a custom data model. Data Model: Email New Title: Email Phonetic New ID: Email_Phonetic App: Search & Reporting (do not clone to Splunk Common Information Model) New Description: Email Phonetic Data Model Permissions: Clone Note that cloning the data model also clones the tags_whitelist setting, which does not include our new phonetic tag. To resolve this issue, edit $SPLUNK_HOME/etc/apps/search/local/datamodels.conf: [Email_Phonetic] tags_whitelist = cloud,content,delivery,filter,pci,phonetic SplunkWeb does not allow us to add extracted fields to child datasets. For simplicity here, we'll add the src_user_phonetic field to the root dataset. With the All Email dataset selected, click Add Field > Auto-Extracted. Select the src_user_phonetic field with type String and flag Optional, and then click Save. If the field is not visible, increase the sample size or verify field extractions, lookups, etc. are implemented correctly. With the All Email dataset selected, click Add Dataset > Child. Dataset Name: Email Phonetic Dataset ID: Phonetic Inherit From: All Email Additional Constraints: tag=phonetic Verify the data model: | datamodel Email_Phonetic Phonetic flat | search src_user_phonetic=TRFR | table src_user src_user_phonetic src_user src_user_phonetic trefer@example.com TRFR trevor@example.com TRFR trever@example.com TRFR Ensure the cim_Email_indexes macro references the correct indexes, accelerate the data model, wait for the summaries to build, and then verify the data model again: | datamodel Email_Phonetic Phonetic flat summariesonly=true | search src_user_phonetic=TRFR | table src_user src_user_phonetic src_user src_user_phonetic trefer@example.com TRFR trevor@example.com TRFR trever@example.com TRFR Finally, tie it together with a subsearch to dynamically generate the phonetic encoding: | datamodel Email_Phonetic Phonetic flat summariesonly=true | search [| makeresults | eval user="trevor" | lookup jellyfisher_metaphone field as user output metaphone as src_user_phonetic | table src_user_phonetic ] | table src_user src_user_phonetic src_user src_user_phonetic trefer@example.com TRFR trevor@example.com TRFR trever@example.com TRFR We can turn this into a macro for quick access: Destination app: search Name: email_by_src_user_phonetic(1) Definition: datamodel Email_Phonetic Phonetic flat summariesonly=true | search [| makeresults | eval user="$src_user$" | lookup jellyfisher_metaphone field as user output metaphone as src_user_phonetic | table src_user_phonetic ] | table src_user src_user_phonetic Arguments: src_user Edit permissions and export the macro globally. Verify the macro: | `email_by_src_user_phonetic(trevor)` src_user src_user_phonetic trefer@example.com TRFR trevor@example.com TRFR trever@example.com TRFR If the datamodel command is slow in your environment, use the tstats command: | tstats summariesonly=true count from datamodel=Email_Phonetic.All_Email where nodename=All_Email.Phonetic [| makeresults | eval user="trevor" | lookup jellyfisher_metaphone field as user output metaphone as All_Email.src_user_phonetic | table All_Email.src_user_phonetic ] by _time span=1s All_Email.src_user All_Email.src_user_phonetic _time All_Email.src_user All_Email.src_user_phonetic count 2026-01-19 12:25:30 trever@example.com TRFR 1 2026-01-19 12:25:36 trefer@example.com TRFR 1 2026-01-19 12:25:36 trevor@example.com TRFR 1   ... View more

Hi @Ian0706, You can use a button to set lookup field tokens from input tokens and then reference the lookup field tokens in a visualization search. Using two sets of tokens prevents the visualization search from running until the dashboard user has clicked the button. It isn't pretty, but it works. Here's a simple example using inputlookup and outputlookup to prepend a row to a lookup file. By default, the outputlookup command is considered risky, and the user will be prompted to run the command. You can override this behavior for your dashboard by bundling the dashboard in a separate application and modifying the app default/commands.conf [outputlookup] stanza is_risky setting. # $SPLUNK_HOME/etc/apps/Ian0706_dashboard_app/default/commands.conf [outputlookup] is_risky = false { "title": "Ian0706_lookup_edit", "description": "", "inputs": { "input_AkAODjk5": { "options": { "defaultValue": "value3", "token": "text_field3" }, "title": "field3", "type": "input.text" }, "input_H4MpaoX8": { "eventHandlers": [ { "options": { "tokens": [ { "token": "field1_value", "value": "$text_field1$" }, { "token": "field2_value", "value": "$text_field2$" }, { "token": "field3_value", "value": "$text_field3$" } ] }, "type": "drilldown.setToken" } ], "options": { "label": "Add Row" }, "type": "input.button" }, "input_farf9Mcm": { "options": { "defaultValue": "value1", "token": "text_field1" }, "title": "field1", "type": "input.text" }, "input_m57JMGPh": { "options": { "defaultValue": "value2", "token": "text_field2" }, "title": "field2", "type": "input.text" } }, "visualizations": { "viz_rJEtNnZs": { "containerOptions": { "visibility": {} }, "dataSources": { "primary": "ds_aS8qB1WF" }, "type": "splunk.table" } }, "dataSources": { "ds_aS8qB1WF": { "name": "Search_1", "options": { "query": "| makeresults\n| eval field1=$field1_value|s$\n| eval field2=$field2_value|s$\n| eval field3=$field3_value|s$\n| inputlookup append=t Ian0706.csv\n| outputlookup Ian0706.csv", "queryParameters": { "earliest": "0", "latest": "" } }, "type": "ds.search" } }, "layout": { "globalInputs": [ "input_farf9Mcm", "input_m57JMGPh", "input_AkAODjk5", "input_H4MpaoX8" ], "layoutDefinitions": { "layout_1": { "options": { "height": 960, "width": 1440 }, "structure": [ { "item": "viz_rJEtNnZs", "position": { "h": 400, "w": 1440, "x": 0, "y": 0 }, "type": "block" } ], "type": "grid" } }, "options": {}, "tabs": { "items": [ { "label": "New tab", "layoutId": "layout_1" } ] } } }   ... View more

It's the Splunk context that's important, though, and a null JSON value would be equivalent to a null/undefined Splunk field. If one is using Splunk as an immutable persistence layer for serialized JSON objects, then the difference is important, but in that case, you're likely just working with _raw and not using Splunk field extractions or SPL. For the relatively brief time Splunk bundled Node.js, this might have been interesting, but Python is king apparently. ... View more

INDEXED_EXTRACTIONS and KV_MODE both interpret null values as the string "null." Would I prefer all Splunk JSON extraction methods treat null values as null? Yes! But it would break more than a decade of prior art. If I know my source data does not use "null" in string values, i.e., the following is forbidden: {"foo": "null"} I treat the string "null" as null: index=main foo=* foo!=null index=main | eval foo=nullif(foo, "null") Having used Splunk before native support for JSON field extractions was added, I'm fine with the workarounds given the convenience. See https://ideas.splunk.com/ideas/EID-I-2311 for another complication! Perhaps a new Splunk Idea advocating for a "strict" extraction mode is warranted? E.g.: # props.conf [foo] INDEXED_EXTRACTIONS = JSON # default JSON_MODE = relaxed JSON_MODE = strict [bar] KV_MODE = json JSON_MODE = strict | spath input=_raw output=foo path="foo" mode=strict ``` default mode=relaxed ``` | eval foo=json_extract_strict(_raw, "foo") and the opposite for the makeresults command: | makeresults format=json mode=relaxed data="{\"foo\": null}" ``` default mode=strict ``` As a concession to existing code, it could be a new, internal search directive accessible through the noop command: | noop json_mode=strict   ... View more

Hi @ARC1, If you're not a federal employee or contractor, you'll need to contact Splunk or a Splunk partner for more information re: FedRAMP. If you are a federal employee or contractor, you can work with your agency's FedRAMP approver to request access to FedRAMP security packages from the public FedRAMP marketplace: Splunk Cloud Platform for FedRAMP Moderate  Splunk Cloud Platform for FedRAMP High  For on-premises deployments, you can review FIPS and Common Criteria compliance at https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.0/establish-and-maintain-compliance-with-fips-and-common-criteria-in-splunk-enterprise/best-practice-for-maintaining-compliance-with-fips-and-common-criteria-in-your-splunk-enterprise-environment. ... View more

Hi @chenfan, I can't reproduce the issue using your layers configuration in Splunk Enterprise 10.0. Which version of Splunk are you using? Can you post a redacted version of your search? You could try appending an eval after geostats to insert zero values when a field is missing, null, or empty: | geostats count by status ``` latfield=lat longfield=lon ``` | eval normal=coalesce(tonumber(trim(normal)), 0), warning=coalesce(tonumber(trim(warning)), 0), critical=coalesce(tonumber(trim(critical)), 0)  You can vary the eval command to fit whatever validation logic you prefer, e.g.: | eval normal=if(isnull(nullif(normal, "")) OR NOT isint(normal), 0, normal), warning=if(isnull(nullif(warning, "")) OR NOT isint(warning), 0, warning), critical=if(isnull(nullif(critical, "")) OR NOT isint(critical), 0, critical)   ... View more

Yes, although be mindful of the (minimal) local overhead. Enabling event breaker will minimize pipeline stalls and improve load balancing if you're sending to multiple receivers. Throughput will still be limited by the limits.conf [thurput] stanza maxKBps setting, ingest pipelines, queues, receiver capacity, etc. ... View more

Hi @chenfan, You've used the correct syntax for bubbleSize and seriesColor to select a data frame by series names and match the index of each series name to its corresponding color. Assuming "normal" is the dominant status, the screenshot looks correct. Which part isn't working? As an aside, Splunk's legacy default RGB values for red, yellow/amber, and green are #cba700, #d41f1f, and #118832, respectively. ... View more

Hi @splunkreal, Yes, it should. See the product documentation and the following thread for common certificate-related issues and solutions: https://community.splunk.com/t5/Splunk-Enterprise/KV-store-failing-to-start-in-9-4-3/m-p/748407. ... View more

Hi @Nraj87, You can probe the services/collector/health endpoint on the HEC port for current service, ack, and token status. See https://help.splunk.com/en/splunk-enterprise/leverage-rest-apis/rest-api-reference/10.0/input-endpoints/input-endpoint-descriptions or your version's documentation for more information. HEC metrics are available in index=_introspection with sourcetype=http_event_collector_metrics, e.g.: index=_introspection sourcetype=http_event_collector_metrics component=HttpEventCollector data.series=http_event_collector index=_introspection sourcetype=http_event_collector_metrics component=HttpEventCollector data.series=http_event_collector_token | tstats latest(data.num_of_events) as num_of_events latest(data.num_of_requests) as num_of_requests where index=_introspection sourcetype=http_event_collector_metrics component=HttpEventCollector data.series=http_event_collector | tstats sum(data.num_of_events) as num_of_events sum(data.num_of_requests) as num_of_requests where index=_introspection sourcetype=http_event_collector_metrics component=HttpEventCollector data.series=http_event_collector_token data.token_name=foo by _time Introspection metrics are relative to the report window, i.e., data.num_of_events is the number of events received over the last 60 seconds using the default limits.conf [http_input] stanza settings. Token-level introspection events are only generated when activity occurs over the report window. See https://help.splunk.com/en/splunk-enterprise/get-started/get-data-in/10.0/get-data-with-http-event-collector/troubleshoot-http-event-collector for more information. ... View more

They're usually interested in mapping the business logic to the monitored content, e.g., an audit log entry corresponding to a NIST control and the corresponding design and implementation of transformations, identification rules, human readable elements, etc. ... View more

As an aside, this is a common question posed by auditors in compliance and cybersecurity verticals. If you need to track and implement workarounds for the various problems identified across everyone's answers, a script in Python or your language of choice is a better solution. There might be an exposed method to render search strings the same way the internal dashboard code does, but I haven't looked for one. ... View more

This will eat/discard "Running," though: LINE_BREAKER = ([\r\n]Running) and the event will be: : Yes Safe Mode: No Plugins loaded: Yes ... In my own work with Nessus Agent, with or without Splunk, I take an approach similar to @PrewinThomas's suggestion and convert, e.g., the output of 'nessuscli agent status --local --show-uuid' to a PowerShell object, a JSON object, or whatever format makes sense for the consumer. If I were doing this today in Splunk, I would use JSON and an accelerated data model (not INDEXED_EXTRACTIONS) or field/value transformations like field_name=field_value that work with tstats and PREFIX(). ... View more

Hi @uagraw01, Edit: Take @richgalloway's advice. My answer is from the perspective of a single instance. If you're forwarding data, the cooked event from INDEXED_EXTRACTIONS will bypass the receiver's parsing, agg, and typing queues. You can combine the two with force_local_processing on a universal forwarder, but it's not necessary here. Timestamps are extracted from _raw during aggregation/merging, so you'll want to use a TIME_PREFIX value relative to the event text: TIME_PREFIX = [+-]\d{2}:\d{2},[^,]+, MAX_TIMESTAMP_LOOKAHEAD = 25 TIME_FORMAT = %F %T%:z The default MAX_DAYS_AGO value is 2000, but if your reports are older than that, you'll want to increase that value as well. If you have a column named "_time" in your CSV file and the value is a Unix epoch time, that value will be the initial value for _time, and a second clean field named "time" without an underscore will be indexed with the original value; however, default timestamp extraction settings will still scan _raw for a timestamp. In your case, 2026-01-16 06:00:00+00:00 would be (or at least should be) extracted absent TIME_PREFIX and TIME_FORMAT settings, overriding any value found by INDEXED_EXTRACTIONS. ... View more

Hi @shashankk, Choropleth maps use arrays of latitude and longitude vertices to draw polygons. The Splunk geom search command uses lookups to map feature identifiers to shapes, typically aligned to something represented by the underlying map data. For example: | makeresults format=csv data="src_ip 8.8.8.8 8.8.4.4" | iplocation src_ip | stats count by Region | geom geo_us_states featureIdField="Region" will produce geometry for the state of California: In your example, choose a feature representing your normalized magnitude (count, density, etc.) and then use the geom command with an appropriate lookup: | stats count as total_events by country | geom geo_countries allFeatures=true featureIdField="country" If you want to display multiple statistics, use the geostats search command with the Cluster Map visualization: | geostats globallimit=0 latfield=latitude longfield=longitude count as total_events, count(eval(Priority="High")) as high_count, count(eval(Priority="Medium")) as medium_count The General visualization settings allow you to set the map center using directly entered latitude and longitude values. To center on Switzerland, for example, use latitude 46.801 and longitude 8.227:   ... View more

Hi @darrfang, You can use CSS to manipulate cell foreground and background colors. This example uses the duration_diff field's style as a key, changes the duration1 and duration2 cell colors, and then hides the duration_diff field's associated th and td elements: <dashboard version="1.1" theme="light"> <label>range_table</label> <row> <panel> <html id="my_html"> <style> #my_table td:not([data-cell-index="0"]):has(~ .color-formatted[style="color: rgb(255, 255, 255); background-color: rgb(212, 31, 31);"]) { color: rgb(255, 255, 255); background-color: rgb(212, 31, 31); } #my_table td.color-formatted { display: none !important; } #my_table th[data-sort-key="duration_diff"] { display: none !important; } #my_html { display: none !important; } </style> </html> <table id="my_table"> <search> <query>| makeresults | eval data="ABC,10,15;DEF,12,13;GHI,11,14" | makemv delim=";" data | mvexpand data | eval label=mvindex(split(data,","),0) | eval duration1=tonumber(mvindex(split(data,","),1)) | eval duration2=tonumber(mvindex(split(data,","),2)) | eval duration_diff=abs(duration1 - duration2) | table _time duration1 duration2 duration_diff</query> <earliest>0</earliest> <latest>now</latest> <sampleRatio>1</sampleRatio> </search> <format type="color" field="duration_diff"> <colorPalette type="list">[#FFFFFF,#D41F1F]</colorPalette> <scale type="threshold">2</scale> </format> </table> </panel> </row> </dashboard>   ... View more

* Except, unfortunately, (presumably US) customers with DoD IL5 or FedRAMP Moderate Splunk Cloud subscriptions or Splunk Enterprise running in FIPS mode. ... View more

Hi @JohnEGones, An analysis of week-over-week change over the last 30 days probably requires 44 days of data: 30 days of recent data, 7 days of additional historical data for week-over-week coverage, and another 7 days of historical data for moving averages. The trendline and autoregress commands are sometimes easier to manage than streamstats. Try: index=firewall sourcetype=firewall_traffic earliest=-44d@d latest=@d | timechart span=1d sum(bytes_out) as daily_bytes | trendline sma7(daily_bytes) as week_avg | autoregress week_avg p=7 | where _time>=relative_time(now(), "-30d@d") AND _time<relative_time(now(), "@d") | eval w_o_w_change=100*(week_avg-week_avg_p7)/week_avg_p7 | eval state=case( w_o_w_change > 50, "CRITICAL - 50%+ increase", w_o_w_change > 30, "HIGH - 30%+ increase", w_o_w_change > 20, "MED - 20%+ increase", 1=1, "LOW") | table _time daily_bytes week_avg w_o_w_change state | sort - w_o_w_change ... View more