Best practices for entity ownership
These best practices and tips for ownership are designed to help you:
Capture ownership for short-lived entities such as process group instances and Kubernetes Pods.
Minimize the time taken for tagging runs.
Scale the assignment of ownership effectively for large, complex environments.
Provide ownership coverage for entities by assigning teams at the time of deployment.
Maintain adequate team information for routing and display.
Ownership assignment
We recommend that you assign owners to critical entities. These are entities that experience a high number of outages or security issues, have high throughput, are business critical, or are customer facing.
Use these recommended methods for applying ownership based on entity type; while you can use tags to apply ownership to any monitored entity, these recommended methods are the most efficient ways to assign entities to owners.
Kubernetes
For Kubernetes objects, define ownership simultaneously for all desired Kubernetes objects. This ensures that all your Kubernetes objects have adequate ownership coverage at the time of deployment.
- Always apply labels for the Deployment.
- We recommend specifying ownership for at least the
CLOUD_APPLICATION(for example, the Deployment, Job, CronJob, or DaemonSet) and theCLOUD_APPLICATION_INSTANCE(Pods) entities. - Unique keys are a requirement in key-value pairs in Kubernetes labels. Keys must begin with the custom key names you define for ownership information. For example, you can use
owneranddt.owneras prefixes to create unique keys.
apiVersion: apps/v1kind: Deploymentmetadata:name: demolabels:dt.owner-1: my-team-1 # Dual team ownership defined for the Deploymentdt.owner-2: my-team-2spec:replicas: 1selector:matchLabels:app: demotemplate:metadata:labels:app: demodt.owner-1: my-team-1 # Ownership defined for the Podspec:containers:- name: demoimage: demo:1.0.0ports:- containerPort: 8888env:- name: DT_CUSTOM_PROP # Environment variablevalue: 'dt.owner-1=my-team-1' # Ownership defined for the process
Tags
Use tags to apply ownership only for entities that aren't covered by other methods.
Advantages and uses of tags
- Tags are appropriate for assigning a few stable entities (for example, an application and the synthetic monitors running against it) to specific ownership teams.
- Manual tagging or the Custom tags API are effective in applying ownership to existing (already deployed) entities.
- Automatic tagging rules have the advantage of capturing new entities that match your tagging rules. Automatically applied tags also can't be removed manually from individual services, process groups, process group instances, applications, or hosts.
- While the Custom tags API and automatic tagging rules both use the powerful and flexible entity selector for selecting entities, the Custom tags API call is executed immediately. This is a major advantage over automatic tagging rules that are scheduled via the Dynatrace tagging process. This helps you speed up execution time when complex tagging rules are necessary.
Important considerations when using tags for ownership
- Manual tagging doesn't scale adequately for assigning ownership in large, dynamic monitoring environments. Manual tags can also be removed manually.
- While (web UI–based) automatic tagging rules are designed for complexity, automatic tagging runs can take a long time to be completed, depending on the complexity of your rules and the size of your environment. Meanwhile, a critical entity experiencing an issue could miss being tagged with ownership. Read more about optimizing tagging in Best practices for scaling tagging and management-zone rules.
- While the Custom tags API call is executed immediately, the tradeoff is that it's a one-time operation. Depending on the frequency of your tagging runs, new or short-lived entities could miss being tagged with ownership information entirely, making it difficult to find owners in case of vulnerabilities or outages.
- We do not recommend using tags to apply ownership to processes or process groups.
Team information
While only the Team name and Team identifier fields are required for creating an ownership team, here are some suggestions and best uses of other fields.
-
When defining custom keys for ownership identifiers, use specific, easily understandable names that are not likely to be used for other tagging needs.
-
Always add a team Description—this is displayed along with the team name on the Ownership teams settings page and helps to differentiate teams at a glance. Teams with no description or a poor name (team 1) offer no clues as to their role in your organization. Teams with descriptions (2 and 3) are more identifiable.
-
Supplementary identifiers—you can define up to three per team—are especially useful when:
Your team name changes—you can add a supplementary identifier to reflect the name change while leaving the main team identifier unchanged. (Once created, the main team identifier cannot be edited or changed.)
- You want to define sub-teams. Create a supplementary ID for each sub-team—you can use the main team ID as a prefix. For example, for the main team ID
team1, create the supplementary IDsteam1-taskforceandteam1-planning.
Supplementary identifiers give you more flexibility.
Whether you apply a team's main ID or supplementary ID to an entity, it's marked as belonging to the same named team.
Supplementary IDs may be changed and deleted.
A supplementary identifier can be the same as the main or supplementary identifier of another team. In such a case, both teams are marked as owners when the supplementary identifier is applied to an entity.
-
Always select team Responsibilities, even though they aren't required. Responsibilities are displayed prominently along with team descriptions on an entity's Ownership card. These pieces of team information are key indicators for adding contact information for message routing and escalations.
-
Define at least one email or Slack channel per team in Contact details so you can create an automated workflow with a targeted notification or simply extract any monitored entity's contact information when you need to.
-
For Additional information, while you can define custom key-value pairs ad hoc, we recommend rationalizing the keys across teams so they can be reused for the same kinds of information. For example, use the same or related keys to define cost center information and another set of keys across your organization to define team hierarchies and relationships.