Observations regarding Debug Session using Filters in Apigee

Hi All,

Apigee Trace is very useful when we try using filters in it.

We have tried using Predefined UI Filters for Response Codes, Headers, QueryParams, Path, Response Time Greater Than and Custom filters. 

As per the document: https://cloud.google.com/apigee/docs/api-platform/debug/trace

Few observations from our test results, PFB:

1)The response code is expected to be given in response.status.code == value, for example: response.status.code == 401.
It was observed that, it works for 200,400 HTTP status codes, but also expected to work for 401,405 and other status codes.

2)In some scenario's, the filters got useful and received the expected response but whenever tried to set for path, 
didn't found any scenario working for it and didn't got any response. Is there any scenario defined for path as well, in filters?

3)For Response Time Greater Than, it is expected to be 
target.duration > _value_ and client.duration > _value_
But, even when tried with Less Than, for example target.duration < 900 and client.duration < 900, 
it also works in Response Time Greater Than. Is it expected to be like this?

4)Another Scenario in Response Code, tried with response.status.code > '200' which gives response for 200,400 status codes, 
Is this expected to give response for greater than '200' status codes?

Please share your inputs on these observations.

Thank You!

@kurtkanaskie@dchiesa1@Sai Saran Vaidyanathan
@dknezic@ganadurai@Harish123@Manisha_Chennu@Peeyush_Singhai@markjkelly @shrenikkumar-s

2 7 410
7 REPLIES 7

I've seen some strange behavior as well using `request.status.code`, since it's used for happy path responses. When an error occurs, the response is through the error flow and uses `message.status.code`. Use that under Response Code

 

 

message.status.code == 404

 

 

This worked for path matching in Custom:

 

 

request.verb == "GET" && request.path MatchesPath "/oas/v3/persons/*" && message.status.code == "404"

 

 

Seems like the docs need to be updated with tested examples: https://cloud.google.com/apigee/docs/api-platform/debug/trace#use-filter

Thanks a lot @kurtkanaskie for the response. 

We have tried for the mentioned scenarios:

1)For 'message.status.code' in Response Code:

Got response as expected and when we changed values accordingly, it worked for all other status codes.

2)For path matching in Custom:

Got response for 404 as expected but, when we changed the values to check for other HTTP Status Codes, we got response for 401 and 405 status codes.

Wondering if there is any scenario for path matching, where we can expect response for a 200 or 400 status code as well?

This works:

request.verb == "GET" and request.path MatchesPath "/oas/v3/persons" and ((message.status.code Equals "200") or  (message.status.code Equals "400"))

For more details see: https://cloud.google.com/apigee/docs/api-platform/reference/conditions-reference#conditions-overview

 

Hi @kurtkanaskie  

Thanks for your response.
While working with Apigee Trace I'm looking to better understand how path filters work within this tool.

I am trying to find out the use-cases on this path filters,
I have tried with the above expression which was mentioned for success scenario and it did not worked for me-
request.verb == "GET" and request.path MatchesPath "/oas/v3/persons" and (message.status.code Equals "200")

I also tried making requests in a simpler way.
For Example : request.path MatchesPath "/oas/v3/persons/*"
This expression worked for 401,404,405 status codes. But whenever I make requests for 200 status code and with this expression in path filter , I was unable to find any response for it.

So I am trying to look if there is any scenario for success cases with simpler examples, which is easier to manage by all and also useful in the time of production.

As path filters play a significant role, It will be more helpful if we can find any working success scenarios.

Thanks a lot!

 

Not exactly sure what your trying to accomplish, but the above filter you provided:

request.verb == "GET" and request.path MatchesPath "/oas/v3/persons" and (message.status.code Equals "200")

That worked for me when I make requests to "GET $HOST/oas/v3/persons".

However a call to "GET $HOST/oas/v3/persons/P42" does not show in DEBUG because that path does not match the filter. Note that MatchesPath is used for path matching. You could use a wildcard to match everything after the basepath:

request.path MatchesPath "/oas/v3/persons/**" and (message.status.code Equals "200")

But that won't match "GET $HOST/oas/v3/persons" because that path does not match the request.

To match everything you could use the Matches operator:

request.path Matches "/oas/v3/persons*" and (message.status.code Equals "200")

But that's not actually filtering any path, it matches everything.

Hope that helps clarify things, please see the Pattern Matching docs  and compare MatchesPath and Matches operators.

 

First of all, thanks a lot @kurtkanaskie  for all your help & inputs.

We are trying to achieve is to filter a particular flow/operation's requests amongst multiple flows in an API Proxy.

So, simply request.path MatchesPath "/oas/v3/persons" or request.path Matches "/oas/v3/persons" should work where /oas/v3 is the basepath and /persons is the resourcepath.

We tried with this and it doesn't work with filter Custom/Path for any 200/400 scenarios.

We check the working of filters in this way-

We have 2 trace sessions opened, the one is without filter which accepts all types of transactions and the other one is with the selected filter.
So for a particular request, when we receive the request in the trace which is without filter and in other trace we don't receive the same response for the selected filter, so definitely the filter isn't working for me.

Does the runtime version matter in this case, the Apigee runtime version which we have is 1-11-0-apigee-5. Since it works for you, could you please confirm the the runtime version you have? We can take this input and raise a case if required.

I'm sorry you're having difficulty, it's working as expected for me and I'm running "1-11-0-apigee-5".

I ran 2 debug sessions, the one on the left has the expression in Custom Filter:

 

request.path MatchesPath "/oas/v3/persons"

 

kurtkanaskie_0-1696449719296.png

I made 2 calls to my proxy and they were both recorded in each debug session.