Missing Auto-tagging rules in new tenant Gen 3 (only): Seeking efficient workflows for Process Tagging in Grail

[carlos_carreno]

With this new update and looking into Gen 3 (where no Gen 2 is available) I've been trying to figure out how to automate tagging as we did in the previous generation. In the past, it was very simple to use 'Auto-tagging' rules, which then propagated across different levels.

However, with the latest update, this option is no longer available in the Gen 3 settings. It has been a real challenge to tag processes; I have found some documentation, but it isn't clear. Could you please help me find a simple and efficient way to achieve this?

Primary Grail fields and tags enrichment through OneAgent — Dynatrace Docs

[AntonPineiro]

Hi,

Tagging rules in classic view and being applied. It means, tagging rules created in legacy app are visible in new apps.

Best regards

[Julius_Loman]

@AntonPineiro  not true. You have the Hybrid environment with classic app functionality. The new pureGen3 environment does not have the classic apps (except DEM), so no auto tagging rules are possible and won't be possible.

@carlos_carreno I recommend looking at primary grail tags and primary grail fields. Tagging itself is currently possible using DT_TAGS or OneAgent tagging configuration. I understand the pain. But you should rely more on the new concept with primary grail fields. It's a huge concept difference.

[AntonPineiro]

Hi,

Ohhh good point, I had not thought about a new and fresh environment, where only Gen3 is available.

Thank you! Let me modify tittle.

Best regards

[mdouds]

We're starting to explore this new concept as well. It seems like tagging done via API or CMDB integrations is not really possible or recommended in Gen3, unless we build an integration that can apply DT_TAG environment variables through our our source repositories. Is that your take as well? 

[AntonioSousa]

I still can't believe who had this magnificent idea of abandoning tagging!
Tags (or labels in k8s) are a foundational metadata layer...

[Julius_Loman]

@AntonioSousa I believe the idea comes from larger environments where metadata is typically already present on the source. I dislike maintaining a complex auto-tagging and mastering the data in Dynatrace somehow. It eventually breaks.

For k8s, you can already propagate labels or annotations into grail fields, so this sorts a lot of things already. But still, there are many gaps where tags are necessary.  Still, we need much better guidance and roadmap visibility for environment data segmentation.

[RSarafaniuk]

@Julius_Loman In case of ownership creation. We are trying to do ownership rules for one of the customers and it seems really hard to configure in the cause of tagging problem. Do you, or anyone else, have recommendation for ownership? We have k8s cluster and virtual hosts in the scope.

We know about two variants available: 1) Do API settings changes (but we are not sure that such method will have long existance); 2) Do changes on OS level using environment variables and oneagentctl. Each of variant is to complex in use and It would be good to have recommendations there.

[Julius_Loman]

In a pure Gen3 environment, I don't think we have any options besides DT_TAGS environment variable or OneAgent tags to add tags at this time (you can manage the oneagents remotely). Afaik APIs for manual tagging are not present in Pure Gen3.

I'm also unsure if and how we can at this time tag the additional entities like frontends, services, ... since DT_TAGS or OneAgent tags.

[MarwanC]

I would appreciate if someone could help clarify, in practical and reasonably simple terms, the difference between Gen 2 tagging and Gen 3 tagging.

Over the past period, we have put a significant amount of effort into establishing a consistent tagging strategy across our environment. This was not just a light exercise, but a coordinated effort involving automated scripts as well as auto tagging rules, with the goal of making tagging a reliable foundation for segmentation, filtering, and operational management.

Given that investment, we are now facing a concerning situation. We already made the decisions  to skip Management Zones at the beginning of the project, which effectively renders our current segmentation approach far less useful. Since our segmentation relies heavily on tagging semantics, this shift has a noticeable impact on how we structure and operate our environment.

At the moment, it is not entirely clear what the intended replacement model is, or how Gen 3 tagging fundamentally changes the way entities are attributed, queried, or grouped. It would be helpful to understand whether tags still play an active role in evaluation and scoping, or if they are now more passive metadata with reduced influence on access control and segmentation.

Another important point is the migration aspect. What is the recommended way to transition from a Gen 2 setup to Gen 3 without losing visibility, breaking existing dashboards and alerts, or re-doing a large portion of the tagging work? Is there a clear mapping between the two models, or any tooling that supports this transition at scale?

At the moment, this feels like a shift that partially invalidates previous engineering decisions, especially when tagging was designed and implemented as a core part of the system rather than an afterthought. If there is a new conceptual model behind Gen 3, it would be very useful to have it explained in a structured and concrete way.

If anyone has already gone through this transition or can provide detailed insights, it would be greatly appreciated. I would be happy to gather the information and write it up afterwards so others facing the same situation can benefit from a clearer explanation.