Tagging is a powerful mechanism. However, to reap its benefits, tagging should be used carefully and in a meaningful way. To guide you towards this end, we provide you with specific recommendations and best practices, which are described below.
Host metadata & tagging
It's recommended that you define additional metadata at the deployed system of a host (
hostcustomproperties.conf for OneAgent versions 1.141 and above). You should send as much extra metadata as you can. This extra data can be used by Dynatrace to define tags, management zones, or dynamically within charts, dashboards, and more.
It's recommended also that you standardize some metadata about your organization. You can save them into the respective config file in an automated fashion during the deployment procedure. Important aspects to standardize are:
- Owner/team/business unit/line of business
- Environment: staging/production
- Version (if applicable)
- Importance/severity (relevant for alerting profiles)
It's not recommended that you define tags at the deployed system for hosts. The reason is that this is cumbersome and requires a lot of preplanning. It also makes it hard to make changes later. Only set tags at the host level if what you're tagging rarely changes and you need to create a global filter (for example, for importance/severity). Another case might be if your way of working requires that you define tagging at deployment time.
Application metadata and tagging
What's recommended for hosts is also valid for applications and processes. Typically, you should think about additional metadata and standard metadata and not about tags (i.e, labels).
For applications like WebSphere or Tomcat, you should use the environment variable
DT_CUSTOM_PROP to define your metadata. This variable needs to be present at the application startup. For WebSphere, you can do this in the WebSphere console in the JVM section. For Tomcat and others, simply define it as part of the startup script.
With Kubernetes, use Kubernetes annotations to define your metadata. Dynatrace will pick up all annotations automatically. The same is true for AWS. Dynatrace will also pick up AWS tags, but in this case as tags not as metadata. Of course, you can still use them to define additional tags or use them for any other purpose.
To define Dynatrace tags for Cloud Foundry, you can leverage one or more Cloud Foundry service instances that have the name
dynatrace as a substring.
It's recommended that you configure automated tagging rules, based on existing or custom metadata, to define your filter sets for charts, alerting, and more. These tags and rules can be changed and adapted any time and will apply almost immediately without any change to the monitored environment or applications.
CMDB, API and automation
If you have a CMDB where you want to define and maintain your tags, you can do so and use the API to synchronize those tags with Dynatrace. This means you can define tags and assign them to entities via the API. This should be used for common tags that you already maintain in a location outside of Dynatrace.
Management zones work in the same fashion as automated tags and offer even more flexibility. They also add a layer of security. It's recommended that you define zones for all teams that specify what they are supposed to view and the different lines of business. It also makes sense to add different zones for different support teams, so that the large amount of data is consumable and so that security layers are introduced. Every user can have access to multiple zones. Zones can overlap, so you don't need to worry about assigning one entity to a specific zone. Shared entities can therefore be in many or all zones.
Naming rules and naming conventions
Dynatrace automatically provides names, but they don’t enable you to quickly identify where an application or service belongs to. To achieve this, it's recommended that you use service naming rules and process group naming rules. This can be done in Dynatrace using metadata imported from the monitored applications.
It's highly recommended that you prefix process groups and applications with a designation related to business units (
LOB) or other owner designation. Such naming standard will be applied automatically to new and existing entities and can be enhanced in the future based on newly arising needs. This is also one of the reasons why it makes sense to define a minimal set of metadata that every application can provide.