Tags vs metadata

DESK differentiates between tags and metadata. Metadata properties are key/value pairs that are inherent to any monitored entity. Tags in DESK are labels or markers that do not belong to an entity. Tags however may also have a key/value structure. For example, you can define a tag with key SecurityIsolationLevel that has a different value for different entities. Once a tag and its rules are defined, DESK will apply the tags to new entities automatically.

How are tags and metadata created

Metadata is detected during startup or discovery of a monitored entity and is immutable from within DESK. Metadata is shown in the Properties section of any entity (see the image below).

For processes, all metadata is discovered during startup of each process. Metadata is typically not refreshed until a process is restarted. Metadata is considered part of the deployed application or deployed entity and is discovered and/or configured as part of that deployed application. Metadata can't be changed using the DESK web UI.

Tags, on the other hand, aren't information about an entity and don't belong to one specific entity. Tags are used to find/filter/designate sets of entities. Tags in DESK can be changed without changing the deployment itself. They are configurable from within the DESK web UI.

There are several ways to create tags for monitored entities. The best option for you depends on your environment and your needs. The easiest way is to use the DESK web UI to manually apply tags to your entities. However, the manual approach forces you to manually tag each new entity. This maintenance challenge makes it difficult to enforce a standard and is impractical within larger environments. Therefore, within larger environments, it's recommended that you use a combination of auto-tagging based on metadata and tags that are part of the monitored deployment. Through this approach, tags can be dynamically assigned within DESK, based on immutable metadata that come from the monitored system.

With this in mind, note that a Name or a Version is not a tag in DESK. Rather, these are regarded as metadata. An example for tags would be one called Production and another called Staging. A deployment designation like blue/green is metadata but might often make sense as a tag—it's not intrinsic information but rather is used to look at either the blue or the green set of applications.

Importing tags/metadata from external sources

DESK not only discovers all processes running on a host, it also identifies their nature. As part of this, DESK captures the most important domain-specific metadata. If DESK discovers, for example, an Oracle WebLogic entity, the entity will also have metadata about the WebLogic Domain, the WebLogic Server name and the WebLogic Cluster. If DESK identifies a Kubernetes environment, then every process will have metadata concerning its pod name and namespace. The same is true for VMWare and AWS hosts.

DESK only knows about a subset of domain-specific information. This is why we also enable you to enrich this information with your own metadata as well as with additional metadata from other sources. In particular:

• Kubernetes and OpenShift annotations are automatically reflected as metadata on processes and process groups in DESK.
• You can use system environment variables to define your own metadata on any kind of process.
• DESK adds custom metadata for hosts as well.
• DESK adds custom metadata for Cloud Foundry.

This metadata is shown in the properties of each entity within the DESK UI and it's part of the data when you access these entities via the API.

You may also have existing tags in 3rd-party systems that you rely on and that you want to ensure are the same across your organization in an automated fashion. DESK recommends providing such tags via the different means at the time of deployment (Kubernetes annotations, Cloud Foundry tags, AWS tags, environment variables) or set up an integration to send them via the DESK API. These tags will be “read only” in DESK and therefore you won't be able to configure them via the UI.

Where to use tags and metadata

Tags involve a wide spectrum of usages, but in principle they are used to find certain types of entities or to filter views and actions for certain entities. As tags have predominantly an organizational and management purpose within DESK, they are useful for:

• Filtering lists
• Defining which entities you want to chart in a custom chart or dashboard.
• Specifying where to send problem notification based on problem context in alerting profiles.
• Defining custom alerts.
• Accessing metric data via the REST API.
• Finding and inspecting monitoring results via DESK search.
• Defining a maintenance window.

As mentioned above, tags can have a key/value structure as well. Therefore, you can define, for example, a tag User and assign username as a value dynamically. You can do the same for email, owner and many other properties. However, you will rarely use such key/value pairs for the purposes described above. This would also clutter the DESK UI. Tags are meant for organization, not for defining extra information for your entities. It is therefore important to consider whether something is really a tag (a label or marker) or simply metadata and additional information. When you're in doubt, we recommend that you create metadata, as you can always use the DESK tagging engine to create a tag based on metadata and assign the value dynamically. You can find further guidance in Best practices and recommendations for tagging.

You can use metadata to

• Apply tags to entities via rules.
• Apply naming schemes to your process groups and services.
• Define Management zones.