Federated search examples
This topic provides example federated queries that run against Imply Lumi events from Splunk®.
Each example demonstrates a supported SPL command, with output shown where it helps illustrate the result. You can run the queries against the example data for tutorials.
Federated search queries event data only, not system attributes.
Basic event searches
Use these commands to filter, sort, and refine search results for Lumi events.
fields
Find all HTTP 400 (Bad Request) events, displaying only the host, source, and method fields in the results:
index="federated:lumi_main" status=400 | fields host, source, method
head
Search for events where method is either GET or POST, and show the five most recent results:
index="federated:lumi_main" method IN (GET, POST) | head 5
rename
Count events by status code and rename the status field to http_status for clearer labeling in the output:
index="federated:lumi_main"
| stats count by status
| rename status AS http_status
replace
Replace common HTTP methods with more readable action labels and show matching events with method, client IP, and URI path.
index="federated:lumi_main"
| replace GET with "Read" POST with "Submit" PUT with "Update" DELETE with "Remove" IN method
| table method clientip uri_path
Example output:
method | clientip | uri_path |
|---|---|---|
Submit | 237.215.7.11 | /cart |
Update | 183.245.119.215 | /categories/smart-lighting/color-changing-bulb |
Read | 117.107.171.174 | /categories/indoor-lighting/aurora-chandelier |
Remove | 140.199.252.124 | /categories/outdoor-lighting/moonlit-garden-lamp |
search
The search keyword is implied at the beginning of a query.
Use search explicitly in nested searches and when filtering later in a query.
Count events by HTTP status, then filter the result to only the 200 and 404 rows:
index="federated:lumi_main"
| stats count by status
| search status=200 OR status=404
Example output:
status | count |
|---|---|
200 | 10 |
400 | 6 |
sort
Retrieve all HTTP 400 (Bad Request) events, show the host, source, and method fields only, and sort the results alphabetically by host:
index="federated:lumi_main"
| status=400
| fields host, source, method
| sort host
tail
Search for all HTTP 400 (Bad Request) events, returning only the last three matching events:
index="federated:lumi_main" status=400 | tail 3
where
Retrieve events where the host is 10.0.1.19 and the status is 200:
index="federated:lumi_main"
| WHERE host = "10.0.1.19" AND status = 200
Filtering and matching
Use these commands to extract, compare, and transform field values for more precise filtering.
eval
Check if the useragent exactly matches Google's bot identifier and count how many events are from bots versus non-bots:
index="federated:lumi_main"
| eval is_bot=if(useragent="Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)", "yes", "no")
| stats count by is_bot
Example output:
is_bot | count |
|---|---|
no | 254 |
yes | 54 |
regex
Show only those events where the uri_path matches a two-level category path under /categories/. Display the user and uri_path.
index="federated:lumi_main"
| regex uri_path="^/categories/[^/]+/[^/]+"
| table user uri_path
Example output:
user | uri_path |
|---|---|
alice997 | /categories/indoor-lighting/eclipse-wall-sconce |
kennethjohnson | /categories/smart-lighting/voice-controlled-bulb |
dorothy3321 | /categories/outdoor-lighting/solar-path-light |
rex
Extract the operating system from the useragent string and display it alongside the user:
index="federated:lumi_main"
| rex field=useragent "\((?<os>[^;]+);"
| table user os useragent
Example output:
user | os | useragent |
|---|---|---|
admin728 | Windows NT 10.0 | Mozilla/5.0 (Windows NT 10.0; Win64; x64)... |
parkeranthony | Linux | Mozilla/5.0 (Linux; Android 5.1.1; Nexus 5)... |
kramercosmo | Macintosh | Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6)... |
setfields
Set the host, status, and uri fields to specific values and display the results in a table:
index="federated:lumi_main"
| setfields host="10.0.1.19", status="200", uri="/shipping-policy"
| table host, status, uri, _time
Time and aggregation
Use these commands to group, bucket, and summarize Lumi events over time or by key fields.
bin
Group events into 1-hour time intervals and count how many events occur in each interval:
index="federated:lumi_main"
| bin _time span=1h
| stats count by _time
| sort _time
Example output:
_time | count |
|---|---|
2025-07-15 00:00:00 | 17 |
2025-07-15 01:00:00 | 22 |
2025-07-15 02:00:00 | 9 |
2025-07-15 03:00:00 | 14 |
bucket
Round each event’s timestamp down to the nearest hour (3600 seconds), count how many events occurred in each hour, sort them chronologically, and show the first 4 results:
index="federated:lumi_main"
| bucket _time span=3600
| stats count by _time
| sort _time
| head 4
Example output:
_time | count |
|---|---|
2025-10-17 01:00 | 4 |
2025-10-17 02:00 | 1 |
2025-10-17 03:00 | 5 |
2025-10-17 04:00 | 5 |
chart
Create a chart showing the request count for each method, broken down by status code over the past 5 days.
index="federated:lumi_main" earliest=-5d@d
| chart count over method by status
Example output:
eventstats
Add a field to every event showing how many events its user has in the result set:
index="federated:lumi_main"
| eventstats count as user_event_count by user
stats
Count the total number of successful requests and the number of unique client IPs:
index="federated:lumi_main" status=200
| stats count AS total_requests, dc(clientip) AS unique_ips
Example output:
total_requests | unique_ips |
|---|---|
171 | 145 |
streamstats
Show a running count of events per user over time, excluding anonymous users, to track how each user’s activity accumulates chronologically:
index="federated:lumi_main"
| where user != "-"
| streamstats count as user_request_count by user
timechart
Create a line chart showing the daily count of events over the past 5 days, with each data point representing a 24-hour period:
index="federated:lumi_main" earliest=-5d@d
| timechart span=24h count as requests
Example output:
tstats
Count the number of events per host using the Web object from the Splunk Web data model:
tstats count AS host_event_count BY host
FROM datamodel=Web.Web
WHERE index="federated:lumi_main"
Example output:
host | host_event_count |
|---|---|
web-01 | 854 |
Text and field extraction
These commands help you extract data from JSON or text fields and format it for analysis.
fillnull
Count events grouped by referer and replace any missing referer values with NULL:
index="federated:lumi_main" | stats count by referer
| fillnull
Example output:
referer | count |
|---|---|
https://www.pinterest.com/ | 1 |
https://www.ebay.com/ | 3 |
NULL | 5 |
iplocation
Look up the geographic location of each clientip and display the IP with its city, country, region, latitude, and longitude for the last 4 matching events:
index="federated:lumi_main"
| iplocation clientip
| table clientip City Country Region lat lon
| tail 4
Example output:
clientip | City | Country | Region | lat | lon |
|---|---|---|---|---|---|
62.1.162.192 | Athens | Greece | Attica | 37.9838 | 23.7275 |
218.29.115.104 | Zhengzhou | China | Henan | 34.7472 | 113.625 |
192.135.23.153 | Bologna | Italy | Emilia-Romagna | 44.5004 | 11.3568 |
52.79.96.163 | Seoul | South Korea | Seoul | 37.5665 | 126.978 |
spath
Extract the response_time_ms value from JSON data in the api_response field and put it in a new latency field.
Filter to only show events where latency exceeds 500 milliseconds:
index="federated:lumi_main"
| spath output=latency input=api_response path=response_time_ms
| where latency > 500
Example output:
_time | latency | api_response |
|---|---|---|
2024-09-22 10:15:23 | 750 | {"user":"sallyosborne","status":"success","response_time_ms":750} |
2024-09-22 10:15:24 | 1200 | {"user":"bernd74","status":"error","response_time_ms":1200} |
2024-09-22 10:15:25 | 650 | {"user":"miltonle","status":"success","response_time_ms":650} |
table
Display a table of selected fields for easy viewing and analysis:
index="federated:lumi_main"
| table _time, clientip, status, user
Example output:
_time | clientip | status | user |
|---|---|---|---|
2025-05-13 14:22:21 | 53.3.39.88 | ok | sanderskimberley |
2025-05-13 14:22:36 | 147.197.48.174 145 | ok | kevin10 |
2025-05-13 14:22:58 | 154.24.52.81 145 | ok | cheryl33 |
Error and performance analysis
Use these commands to identify common or rare values, detect anomalies, and analyze performance trends.
rare
Find the two least common combinations of uri and user, excluding events where the user is - and the uri is /:
index="federated:lumi_main"
| where user != "-" AND uri != "/"
| eval combo = uri . " - " . user
| rare limit=2 combo
Example output:
combo | count | percent |
|---|---|---|
/.bash_history - admin374 | 1 | 0.217865 |
/.bash_history - elaine554 | 1 | 0.217865 |
sirare
Find and display statistically rare users among successful requests, excluding anonymous ones:
index="federated:lumi_main"
| where user != "-" AND status=200
| sirare user
| table user
sitop
Identify statistically significant URIs that start with /admin/ and returned a 200 status:
index="federated:lumi_main"
| where status=200 AND match(uri_path, "^/admin/")
| sitop uri_path
top
Show the most common URIs accessed in the index, with how often they appear and their percentage of total events:
index="federated:lumi_main" | top uri
Example output:
uri | count | percent |
|---|---|---|
/home | 524 | 23.4% |
/shipping-policy | 312 | 13.9% |
/contact | 290 | 12.9% |
Learn more
- How to search events with Splunk to walk through federated search setup and run example queries.
- Federated search reference for supported SPL commands, syntax, and operators in federated search.
- Monitor search performance to use the Splunk job inspector to examine aspects of a search.