Customizable naming for auto-detected server-side services

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 meta data 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 you want 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. For an explanation of applying conditions, see Can I organize services, process groups, & hosts with tags?
   

   
   

   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 meta data 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.

All the process groups in this example include the string dynatrace-<CODE>-<Name>. This rule uses <CODE> as a prefix for service names. To do this, use the placeholder {ProcessGroup:DetectedName}. When you use one of the defined placeholders you can add a regex to extract a portion of the detected value.

To extract something from {ProcessGroup:DetectedName} you could use {ProcessGroup:DetectedName/REGEX}. The regex simply extracts the complete match. It doesn’t allow capture groups, only atomic and lookaround groups.

In the example below, the regex looks like (?<=dynatrace-)[^-]++. While this all may look rather complicated, all it does is capture the portion of the string between dynatrace- and the next instance of -. This regex uses a lookbehind for dynatrace- and a matches everything until the next -.

The result speaks for itself. 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.