setting filter for "api/v2/synthetic/monitors" endpoint tags will return ANY matched entities

[jun_phoon]

Hi,

In the Dynatrace REST API reference it says

"To set several criteria, separate them with a comma (,). Only results matching all criteria are included in the response."

if i try to filter by tags i.e 

tag(key1:value1,key2:value2)   it will return results matching ANY of the tags instead of only entities matching ALL

here is the uri : /api/v2/synthetic/monitors?monitorSelector=tag%28key1%3Avalue1%2Ckey2%3Avalue2%29%C2%A0%20

Am I doing something wrong? is there a toggle for only returning matching for ALL?

[t_pawlak]

Hi
The key is how monitorSelector interprets values inside one criterion vs multiple criteria.

From the Dynatrace docs (paraphrased): doc1 doc2 

If you give multiple values in one criterion, they are combined with OR.

If you give multiple criteria separated by commas, they are combined with AND.

So:

What you did: monitorSelector=tag(key1:value1,key2:value2)

This is one tag(...) criterion with two values, so Dynatrace treats it as:

tag is (key1:value1 OR key2:value2)

That’s why you get monitors that match any of those tags.

What you want (match ALL)

You need to split this into two criteria.
Try this:
/api/v2/synthetic/monitors?monitorSelector=tag(key1:value1),tag(key2:value2)
Now Dynatrace reads it as:

(tag = key1:value1) AND (tag = key2:value2)

and returns only monitors that have both tags.

[jun_phoon]

Hi @t_pawlak 

That was my expectation of the results,

I have just retried it as you laid it out but it is still returning ALL -have you tested it practically? 

Can you test this scenario? 

key1:value1  is a tag we would use on a group of monitors

key2:value2 is a tag we use on the specific monitor

i.e within the group of monitors tagged with key1:value1 - key2:value2 is unique  

In this case - the expected results of monitorSelector=tag(key1:value1),tag(key2:value2)  should return a single entry. 

I am still getting ALL monitors with key1:value1

[t_pawlak]

Hi,
yeah, I tested it right now. 
My mistake. The documentation is correct, but the key part is the definition of the word criteria.

type, enabled, managementZoneId, tag, and location are different criteria types.

The AND logic applies only when you combine different criteria types:

type(BROWSER),enabled(true)   → AND
managementZoneId(1),type(HTTP) → AND

However, multiple tag(...) selectors are not considered multiple criteria.
They are considered multiple values of the same criterion type.

Therefore:

tag(a),tag(b) is treated exactly the same as tag(a,b)→ both resolve to OR, not AND.

This is specific to the /api/v2/synthetic/monitors endpoint, which uses a simplified selector engine.
Other Dynatrace APIs (services, hosts, processes) support AND across multiple tag selectors, but Synthetic does not.

[t_pawlak]

@jun_phoon 
I have ideaa.

Since the monitorSelector in /api/v2/synthetic/monitors treats multiple tag(...) filters as OR (because they are values of the same criterion type), there is a reliable workaround if you really need proper AND logic across tags. Use entitySelector instead of monitorSelector.
Like this:
/api/v2/entities?entitySelector=type("SYNTHETIC_TEST"),tag("key1:value1"),tag("key2:value2")

This returns only the monitors that have ALL the tags, exactly as expected.

If key1:value1 is on many monitors, and key2:value2 is on only one of them
I tested it:
here i use 3 tags:

And here I use 2 tags as filter:

And now you can write simple script that retrieves only the Synthetic Monitors that match ALL required tags

[jun_phoon]

Im trying to query for MULTI_PROTOCOL entity types - which is not valid entity for  /api/v2/entities  endpoint - so the workaround does not work (well i cannot get it to work)

Thanks for the insight re: simplified selector engine - something as a consumer we dont know about.    

The expectation is that the behaviour for matching criteria using entity selector should be the same across all the endpoints. 

It does feel the new GEN3 additions are just "clipped on"  re: APIv2 without ensuring consistency across whatever mechanics dynatrace has currently