Customize service naming

Dynatrace automatically detects and names your applications’ server-side services based on basic properties of your application deployment and configuration. These properties and the resulting service names should be intuitive to you because they reflect your service landscape. In some cases however, the default naming scheme may not be to your liking or may not adequately reflect your service landscape. In other instances, you may want to add certain process or service metadata to a service name to improve usability. Our new service naming rules enable you to customize and enhance the automated naming of your services.

To define a service naming rule

  1. Go to Settings > Server-side service monitoring > Service naming rules.

  2. Click the Add new custom rule button.

  3. Type a Rule name.

  4. Define the Service name format including any static text string to be included that describes the named service. Optional placeholders are available to make it easy to dynamically include specific service and process group properties in the automated service name.

  5. Consider whether or not to restrict this naming rule to a specific process group, technology, or service type. While this step is optional, it provides a quick means of reducing the number of services that a rule applies to. To reduce the list of applicable services even further, you can add Conditions to the new rule.
    Note: If within the name format you reference a property that doesn’t exist in a service that the rule applies to, the placeholder will be replaced with an empty string. You can ensure that the rule only applies to services where the property exists by adding an exists condition for the desired property.

  6. Click Save.

Customize naming standards for your services

Service name format options enable you to build complex naming standards for the services in your environment. The example below includes a CloudFoundry space name as the prefix for automated service naming ({ProcessGroup:CloudFoundrySpaceName}). This naming pattern will only be applied to process groups that have the specified CloudFoundry space name property. The space name placeholder will be replaced with the specific value of the respective process group when the service is named. Also note that because a CloudFoundry space condition has been created, this rule will only be applied to process groups that have the specified CloudFoundry space name.

Every monitored service that is discovered in this CloudFoundry space will be named using the same rule defined above. You can use any property that is displayed within the Properties & tags section of each service page (see Available placeholders list below). You can also include any property of the underlying process in your automated service naming.

You can even extract portions of process and service names for inclusion in service names. Consider that your processes follow a naming logic that contains a qualifier (for example, dynatrace). You can use regex in the references to metadata in names to extract portions of a detected process or service name.

The example rule below looks for services that run in process groups whose name starts with the string dynatrace. All the process groups that this rule applies to follow the pattern dynatrace-<CODE>-<Name>. This is what the regex dynatrace-[^-]++-.* indicates in the condition example below.

service name format

If an open and closed parenthesis is detected in a process group, the corresponding process will be renamed with the contents within the parenthesis. For instance, a process named Apache Tomcat (/Frontend) would be renamed to /Frontend.

To extract something from {ProcessGroup:DetectedName} you can use {ProcessGroup:DetectedName/REGEX}. The regex simply extracts the complete match. It doesn’t allow to capture groups, only atomic and lookaround groups. The resulting service names are all prefixed with the desired environment code.

This functionality, combined with the tagging rules, enables you to organize and categorize your services in ways that are intuitive to you and your team. You can even use regex to adjust the default naming schemes of built-in rules.

We’ve decided to simply document the default behavior in the same fashion as custom rules. This is what the built-in rules are—they aren’t configurable. They simply describe how and why certain services are named as they are.