Assign ownership teams to monitored entities

You can assign team owners to any monitored entity in Dynatrace using the main team identifier or supplementary identifiers (defined when setting up a team). This makes it easier to find the responsible team instantly and contact them if any issue arises with an entity, for example, if the entity is affected by a vulnerability.

You can apply ownership using several methods such as Kubernetes labels and annotations, host metadata, environment variables, and tags (including via the Dynatrace Custom tags API).

Supported methods of applying ownership

The following methods for applying ownership and entity types are supported.

Deployment or configuration metadata recommended

Method Entity types
Kubernetes labels and annotations All Kubernetes objects
Host metadata via oneagentctl or hostcustomproperties.conf Hosts
Environment variables Processes
Tags (manual, automated, and via API)—all monitored entities

Method	Entity types
Kubernetes labels and annotations	All Kubernetes objects
Host metadata via `oneagentctl` or `hostcustomproperties.conf`	Hosts
Environment variables	Processes

We highly recommend that you use the preferred method for applying ownership based on entity type, as described in the sections that follow.

Our recommendations are based on the most efficient methods to ensure that entities have adequate ownership coverage. See Best practices for entity ownership for more information.

Format for applying ownership information

Regardless of the method used, ownership information is applied to entities in key-value pairs. The default keys owner and dt.owner are available in every monitoring environment—see Settings > Ownership > Configuration. You can, however, change or delete the default keys and define your own.

The value is always the unique team identifier specified when creating a team. You can also use supplementary identifiers. (See Create and manage teams for entity ownership for more information on defining these values.)

An entity can have more than one ownership team. You can effect this by applying multiple key-value pairs, as shown in the sections that follow.

Custom keys for ownership information

You can define up to a maximum of five keys for applying ownership information.

Go to Settings > Ownership > Configure.
Select Add key.
Enter the key (Enabled by default).
Save changes.

Custom keys for ownership

When you disable or delete a key, entities assigned to teams via such keys will no longer display or hold ownership metadata. However, such keys will appear as regular tags applied to the entities.

Additional requirements for ownership keys

You can define a maximum of five and a minimum of one key.
You can use any of your defined keys as a prefix in key-value pairs. For example, for the keys owner and dt.owner, you can use owner-1 and dt.owner-test.

Kubernetes labels and annotations

You can specify team ownership for different Kubernetes objects such as Deployments, Pods, Services, or namespaces. To ensure that Kubernetes objects have adequate ownership coverage, which is especially important for short-lived entities like Pods, provide ownership information as Kubernetes labels or annotations with key-value pairs in the deployment specification file, for example, deployment.yaml.

We recommend defining ownership for the Deployment and all other objects for which you want ownership coverage. See also Best practices for entity ownership.

Setting a team identifier as a label or annotation for the Deployment, CronJob, Job, DaemonSet, or StatefulSet provides team ownership information for the respective CLOUD_APPLICATION entities. Note that this ownership is not propagated to the CLOUD_APPLICATION_INSTANCE.

In this example, dual ownership is set via two labels for the Deployment. Each label has a unique key. Unique keys are a requirement in Kubernetes labels and annotations.
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  labels:
    dt.owner-1: my-team-1 # Dual team ownership defined for the Deployment
    dt.owner-2: my-team-2
spec:
```
The sample code below shows an annotation for ownership at the Deployment level.
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
  annotations:
    dt.owner: my-team # Ownership defined for the Deployment
```

Set labels for Pods to specify ownership for the respective CLOUD_APPLICATION_INSTANCE entity. Specify ownership for each Pod.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
        dt.owner: my-team # Ownership defined for the Pod
    spec:

The sample code below shows the manifest for a Pod that has the annotation dt.owner: myTeam.

apiVersion: v1
kind: Pod
metadata:
  name: annotations-demo
  annotations:
    imageregistry: "https://hub.docker.com/"
    dt.owner: my-team
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

For a process, specify ownership using key-value pairs with the DT_CUSTOM_PROP environment variable, which is defined for the container.

In environment variables, you can provide multiple values for the same key. In this example, dual ownership is defined using the key owner.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: demo
  template:
    spec:
      containers:
        - name: demo
          image: demo:1.0.0
          env:
            - name: DT_CUSTOM_PROP ## Environment variable
              value: "owner=team-automation owner=team-dev" # Dual ownership for the process; team IDs are team-automation and team-dev.

apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    dt.owner: team-a # Ownership defined for the Service
spec:
  selector:
  app.kubernetes.io/name: MyApp
ports:
  - protocol: TCP
    port: 80
    targetPort: 9376

apiVersion: v1
kind: Namespace
metadata:
  name: my-namespace
  labels:
    dt.owner: team-a # Ownership defined for the namespace

Host metadata

For hosts, we recommend using host metadata as the primary method of applying ownership.

You can also apply ownership to hosts using tags.

Via `oneagentctl`

OneAgent version 1.189+ For hosts with OneAgent version 1.189+, use the oneagenctl command-line interface after installation to set a metadata property for an individual host. Run oneagentctl with administrator or root privileges from these default locations.

Windows: %PROGRAMFILES%\dynatrace\oneagent\agent\tools
All Unix-like systems: /opt/dynatrace/oneagent/agent/tools

This example for Unix-like systems uses --set-host-property to set ownership with the key-value pair owner-1=team-automation, where team-automation is the main team identifier or a supplementary identifier.

./oneagentctl --set-host-property owner-1=team-automation

Via `hostcustomproperties.conf`

OneAgent version 1.187 and earlier For hosts on OneAgent 1.187 and earlier, create or edit the hostcustomproperties.conf OneAgent configuration file at these locations.

Windows: %PROGRAMDATA%\dynatrace\oneagent\agent\config
All Unix-like systems: /var/lib/dynatrace/oneagent/agent/config

This example for Unix-like systems sets host ownership with the key-value pair dt.owner-1=team-automation, where team-automation is the main team identifier or a supplementary identifier.

cat hostcustomproperties.conf dt.owner-1=team-automation

Process environment variables

For processes, we recommend specifying ownership in key-value pairs via the DT_CUSTOM_PROP environment variable.

We do not recommend using tags to apply ownership to processes or process groups.

Read more about defining process group metadata, for example, setting up the DT_CUSTOM_PROP environment variable for IIS and Windows.

View ownership information in the web UI

For hosts and all Kubernetes entities, select Owners on the entity details page to view ownership information.

This example shows a Kubernetes workload mapping to the CLOUD_APPLICATION entity. Expand a team name to view its details. Select in the Ownership card to edit team details in Settings.

Owner of a Kubernetes workload

This example shows ownership information for a Kubernetes Pod.

Owner of a Kubernetes Pod

On the Hosts page, you can search for hosts with ownership—filter by Tags with the key prefixes you have defined, for example, owner and dt-owner. Note that ownership key-value pairs must be applied to at least one host for the key to be available in the Tags filter. This method of searching for ownership is available on all entity group pages that can be filtered by tags.

Filter by ownership tags on entity group pages

In the example host details page below, the host has three team owners. One of the owners is marked Unknown team identifier. This is because even though the team identifier has been applied to the host (for example, via oneagentctl or a manual tag) in a key-value pair, the team doesn't exist. Invalid team identifier means that the team or supplementary ID was applied to the host in the wrong format.

Select Properties and tags to view all tags applied to the host.

Owners of a host

Select next to the unknown team and then select Add team to define team information in Settings. The entity is then automatically updated with the team definition.

Unknown team

Assign ownership teams to monitored entities

Supported methods of applying ownership

Format for applying ownership information

Custom keys for ownership information

Additional requirements for ownership keys

Kubernetes labels and annotations

Host metadata

Via oneagentctl

Via hostcustomproperties.conf

Process environment variables

Tags

Tagging methods

Permissions

View ownership information in the web UI

Related topics

Via `oneagentctl`

Via `hostcustomproperties.conf`