Is there anyway to get http request logs easily from Splunk created apps?

[Dave_Burns]

Is there anyway to get http request logs easily from Splunk created apps? 

There is a failure in communicating w/ zscaler. The error msg seems to be generated on their side, but they are pushing hard for the body of the message that was sent to their api. 

Since the app was created by Splunk, I'm dis-inclined to hack that into their app just to get this intermittent data for Zscaler. 

any suggestions by the community? 

[phanTom]

If Test connectivity passes then that is usually a thorough indication that the comms are good and you can authenticate (usually) against the API. 

You should be able to tell how the package/data is sent by the respective action and shouldn't need the HTTP packets off the wire to show as with the test connectivity working, knowing the endpoint that the action hits and an example JSON they should be able to work out where the issue lays. 

Good luck mate as sounds like they are just stalling rather than helping!

[phanTom]

Yeah understood but what I mean is, if you can validate the app code isn't doing anything weird then you can say it's unlikely to be the SOAR App and rather something outside SOAR causing the connection issues. 

You mention you get an error back from Zscaler? Do you have it? Is it generated from the initial `Test Connectivity` or another action? If another action, does test connectivity pass?

I suspect it's still either some network object in between or something on the Zscaler API side that is at fault. 

[Dave_Burns]

@phanTom 

Its generated by another action (block_url). Never have a problem w/ test connectivity. 

The error response is 
Another custom url operation is in progress. Please try again.

The logic in the app appears to get the current list data, appends the new item, send the whole list back. 

Majority of the time, it works. 

Had one failure of this type in Jan where we lost some of the data in the list.  
The failure that just happened a few days meant the almost entire list was lost.  (13XX entries down to 3xx) 

All that said, @phanTom I personally agree w/ you that its on the Zscaler side. But they are claiming that they need the body that generated the message as to perform debugging or even isolate. 

 ¯\_(ツ)_/¯

[phanTom]

@Dave_Burns Two things I would do:

1. Check the app code for the relevant action (start with test connectivity) and confirm that the api endpoint and any possible payload (if a POST) is correct. If it's just a GET then as long as SOAR is using the correct API endpoint and possibly some header info too then it's just a simple HTTP Request and if the error you get back is not SOAR related it can be either a network item in between causing issues, or Zscaler itself. 

2. Check the spawn.log once the action  has run as this may contain more information about the call (you may need to turn logging up to get more verbosity). 

They should also be able to see if it's atleast getting to the Zscaler endpoint and/or use the HTTP response value to work out what might be the issue, but you will only get this if you can reach Zscaler. 

[Dave_Burns]

It is a post, but its a post baked into the app.

If it was just the post action in a playbook, yeah. I've crafted bad bodies before that way and debugged them.  Definite possibility if we were  using that method. 🤣

But this is the function in the connector  that we are trying to grab data from. 

If turning up the logging does the same for the urllib3 module like this

requests_log = logging.getLogger("requests.packages.urllib3")
requests_log.setLevel(logging.DEBUG)
requests_log.propagate = True

 
I'll do that. but given the interment nature of this error, its not something that we can expect to happen right away. 

[Dave_Burns]

https://splunkbase.splunk.com/app/5872

this is the app in Soar, not splunk. Sorry thought I had indicated that previously. 

As you can see above, Splunk created the app.

[shivanshu1593]

My bad. Should have read the question and tags thoroughly. Based on my experience with Splunk, if you just pass along the requirement posted by Zscaler to them by filing a support case as the add-on is Splunk supported, they should be able to provide you the format of the packet that they are sending to the Zscaler API. That would be the best and fastest way to approach this problem.

[Dave_Burns]

All good. I had added the soar one after you commented to make it clearer to others. Have a karma point!

[shivanshu1593]

Which add-on are you using to get the data? As far as I can see, all the apps/add-ons for Zscaler on SplunkBase are built by Zscaler themselves and tagged as developer supported, which means that they should be answering the question about the body of the message that was sent to their API.