cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Is it possible to create a management zone using the TAG value only?

_davidemascolo
Contributor

Hi there,
I've tagged all the entities of my application and now I would like to create a dedicated management zone.

I would like to avoid to "clone/replicate" all the entries made to tag the whole application.

I looked at entity selector document page (https://www.dynatrace.com/support/help/shortlink/api-entities-v2-selector) and I expected to find something similar to an entityname option (https://www.dynatrace.com/support/help/shortlink/api-entities-v2-selector#one-of-values-modification) that allow me to select multiple value - entityName.in("name1","name2")

I ask you if is it possible to recreate something like that in entity type selector.
As example: type("SERVICE","PROCESS_GROUP","HOST","APPLICATION"),tag("MYTAG")
would allow me to select all my application entities and create a management zone with a simple rule

Do you know if is it possible in any way?
Regards

Davide

I'm your friendly neighbourhood Spider-Man!™
- Davide
from Milan, Italy
7 REPLIES 7

ChadTurner
DynaMight Legend
DynaMight Legend

the Entity selector will only allow you to select one type of entity at a time, so you can create a set of rules for each, Host, Services, Process Groups, Process Instances. 

You can also use the monitored entity section and add in the rules for tags on each entity type: 

ChadTurner_0-1684327939122.png

 

-Chad

Hi Chad,
I already did it for previous apps.

now the number of applications is growing and the management of tags/mz becomes more and more time consuming. having to create at least 4/5 entries for each application in the mz configuration takes time.

perhaps an improvement on the entity selector side could be useful not only for me but for all those who have large environments to manage.

What do you think?
regards
Davide

I'm your friendly neighbourhood Spider-Man!™
- Davide
from Milan, Italy

Hi @_davidemascolo  I suggest you to use the API is more suitable for high volume recurrent tasks.

The true delight is in the finding out rather than in the knowing.

Hi @DanielS yes, this is a possible solution.
I asked through idea channel the possibility that an improvement is made to the type selector, as it already seems to be for the selector entityName
Basically the selector entityName does not accept multiple values, but on the contrary entityName.in does.
What I'm asking is to verify the feasibility of a type.in that I think would help the management of MZ for more people.

What do you think?

regards
Davide

I'm your friendly neighbourhood Spider-Man!™
- Davide
from Milan, Italy

I get your point, but the limitation I see is that when you use more than one type, the options you can use afterwards are limited, because "tags"/"managementZones"properties works perfectly for every type you can list in type.in, but not much more than that.

The true delight is in the finding out rather than in the knowing.

I would recommend creating an API template, this will allow you to add in new Rules and MZs really easily and quickly. 
In terms of the Entity Selector, you can only target one entity type at a time, which yes you can also create an API Template that allows you to plug and play this data into it. 

I highly recommend crating an API Template as it ensures uniformity and provides a streamlined process into posting the MZs. 

-Chad

cv_dewr
Guide

The API can be a bit of a burden for a one off job (perfect, and recommended either via scripting or monaco for automation use cases).

The UI designers have recently added in the ability to duplicate an existing config from within the UI, duplicate it, make the required updates and you can save the time writing a bunch of API calls for a new app.

e.g.

cv_dese_0-1684732583371.png

the click Duplicate, and you'll have that MZ definition copied as new items, with all the rules, ready for editing.

cv_dese_1-1684732639051.png



cv_dese_2-1684732668636.png

 

So if you already have a MZ built the way you want, and just want to re-use it for a new use case, just Duplicate it.

You can do this in other areas of Settings as well (anything supported by Settings 2.0 should work).

 

Having said all of this, a use case where I'd want a wildcard/multi-choice TYPE() selector is around Azure entities. being able to tag any kind of Azure entity based on a shared property (e.g. Subscription or resource name etc.), currently I need to create 99! different rules to do so, and more if in future more Azure service types become available.

Featured Posts