Splunk Search

REST Search API with WHERE condition

someone4321
Explorer

I'm using Splunks REST API to post a search job and then get the results. Ideally I would like to use a where condition in the search, but for some reason the query does not produce any results with that condition even though the same search with the cloud search app produces several results. If I remove that where condition against the REST API, then I get back all the results - so the query seems to work fine, just not with the where clause. Any reason why I don't get results with the where condition.

Here is a the query:

index="my-index" host="my-host" sourcetype=log4j "Some Event" 
| rex field=_raw "(?=[^S]*(?:Some Event:|S.*Some Event:))^(?:[^ \n]* ){9}(?P<summary>.+)" 
| rex field=summary "{\"field1\":\"(?<myField>.+)\",\"value1\":(?<counter>[0-9]+)," 
| where counter > 1 
| fields summary

Note, there are several of events with counter > 1.

0 Karma

efavreau
Motivator

The ">" isn't encoded and is stopping your curl command. You're missing the --data-urlencode parameter.

From the documentation: https://docs.splunk.com/Documentation/Splunk/latest/RESTUM/RESTusing

curl -k -u admin:pass https://localhost:8089/services/saved/searches \
     -d name=MySavedSearch                                           \ 
     --data-urlencode search="index=_internal source=*metrics.log"
###

If this reply helps you, an upvote would be appreciated.
0 Karma

someone4321
Explorer

I'm not actually using curl, it's through a Python script. I was just using that example for illustrative purposes. Also, there is no error from the REST request. The query appears to complete (i.e. dispatch_state reaches 'DONE'), so I don't think encoding is the issue.

0 Karma

efavreau
Motivator

You're not giving us enough information. How are you invoking the REST API? What's your script? How do you know it's not an encoding issue? The details so far point to the ">" as the culprit.
1) Provide the full scenario of what you are doing, what you have tried, and what you have ruled out.
2) assuming the counter will return if it equals 1, try this to rule out the ">": | where counter="1"

###

If this reply helps you, an upvote would be appreciated.
0 Karma

someone4321
Explorer

I'm fairly sure it's not an encoding issue since the search would fail and the REST response would indicate that with a FAILED status and details about a malformed search expression. This is not the case - it actually completes to a status of DONE, but the response results field is empty. As per you suggestion, I changed the expression to = with a known value and I get the same empty results field. The only thing that produces results, is removing the where clause.

As for the script, it's a Python script using the Request library which makes use of POST /search/jobs/ to create the search job, and then GET /search/jobs/{search_id}/results to get the results. The GET request has the following request params: {output_mode': 'json', 'f':'summary', 'count':'0'}. For details on this API, see:
https://docs.splunk.com/Documentation/Splunk/7.2.4/RESTREF/RESTsearch#search.2Fjobs.2F.7Bsearch_id.7...

0 Karma

richgalloway
SplunkTrust
SplunkTrust

There is no rest command in your query.

---
If this reply helps you, Karma would be appreciated.
0 Karma

someone4321
Explorer

Not sure what REST command you are referring to but the search query is posted in the request body against API /search/jobs/. For example,

curl -u user:pwd -k https://localhost:8089/services/search/jobs -d search="search <my_search_string>"
0 Karma
Get Updates on the Splunk Community!

New Case Study Shows the Value of Partnering with Splunk Academic Alliance

The University of Nevada, Las Vegas (UNLV) is another premier research institution helping to shape the next ...

How to Monitor Google Kubernetes Engine (GKE)

We’ve looked at how to integrate Kubernetes environments with Splunk Observability Cloud, but what about ...

Index This | How can you make 45 using only 4?

October 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with this ...