What’s in an app name? How to create an app-naming convention

As a solutions architect at New Relic, I work with organizations of all sizes—enterprise and otherwise—to help them get started with the New Relic platform. One common issue I see when their applications and microservices pop up in application performance monitoring in New Relic is that no two teams seem to want to name their apps the same way.

So how do you name an application?

There's no one right way to name applications; rather, it’s about creating naming rules and conventions now so you don’t have to think about them in the future. With that in mind, I’d like to share some best practices for naming applications, particularly if you aim to monitor them with New Relic.

The goal here is to help you improve the way you monitor your applications, especially in large deployments. While application naming has no functional impact on your ability to use New Relic, adhering to a naming standard can enhance the organization of your application in our platform.

1. Use auto naming in New Relic, but be intentional with internal names

Many teams use auto naming to define application names in New Relic when their applications come online. Our automatic application naming feature is popular because it requires little to no configuration on the agent side, but choosing it is not always the best strategy. Often, it creates cryptic names based on internal application information that is not always clear and understandable.

Deployment names based on, say, internal Java deployment code can be helpful for developers but may not help other teams and users understand the purpose or use of an application. Instead, create an internal naming scheme and make sure all your teams are familiar with it and can easily identify apps using it.

2. Use a naming standards “questionnaire”

An app’s name should reflect, at minimum, its purpose in your organization. But it’s also useful for the name to indicate other information, such as the app’s location. Just as you would create a list of criteria to define business-related KPIs, you should create criteria before building your naming scheme.

Here are some common questions you could ask to define your app naming strategy:

• Is your app internal? What information do you want to use to identify a single internal app? Does the app have an internal name, code, or acronym used to identify it, for example:
  • phoenix
  • c/osd
• What service does the app (or microservice) provide?
  • deployment-controller
  • checkout
• Do you want to create naming standards based on particular groups or categories, such as grouping by customer type, data center, region, environment, or cloud provider?
  • authmanager-internal-DAL01-east
  • c/osd-public-azure-US
• Do you want to see dev, staging, and prod data in the same New Relic account? What are the logical groupings for those applications?
  • authentication-service-external-FRA-Europe (staging)
  • checkout-service-public-AWS-USEast (prod)

3. Use multiple rollup names

Using multiple rollup names for a single app breaks down app names into smaller chunks (for example, by data center) and then rolls them up to bigger buckets (for example by region or global location). This flexible strategy lets you track performance more granularly.

Pro tip: When you name your apps this way, remember to define app names from most to least specific. You should create:

• A unique rollup name
• A shared rollup name to aggregate data in the New Relic UI
• A general name New Relic uses to aggregate data into a single app

Examples:

If you have an app defined in four clusters, following this pattern:

You’d name your apps this way:

• app_name="MyApp-ClusterA;MyApp-US_SOUTH;MyApp-Global"
• app_name="MyApp-ClusterB;MyApp-US_SOUTH;MyApp-Global"
• app_name="MyApp-ClusterC;MyApp-UK_LONDON;MyApp-Global"

New Relic would then list these apps as follows:

• MyApp-ClusterA—a single app instance
• MyApp-ClusterB—a single app instance
• MyApp-ClusterC—a single app instance
• MyApp-US_SOUTH—a rollup of all app instances running in US_SOUTH (2)
• MyApp-UK_LONDON—a rollup of all app instances running on UK_LONDON (1)
• MyApp-Global—A global rollup

It’s important to note that this approach increases the number of app instances that will show under a single account. If you use this strategy, be careful and intentional with it to avoid creating useless apps and noise.

4. Use the New Relic agent’s multi-environment configuration to name apps

For some agents—including Java, Ruby, and Python—you can use an environment variable to declare the environment in which the agent will run. When you use this variable, agents can get different settings based on their environments.

Additionally, configuring the agent in this way helps maintain integration with the agent throughout the software development lifecycle. You can version control a single agent configuration file and use it throughout all stages of your development process. More specifically, you can use this variable to set different app names according to the environment in which the app will run.

5. Segregate New Relic accounts by environment

If you name your apps with the agent’s multi-environment configuration, your account could end up with hundreds of applications reporting to it. You won’t lose any functionality, but it does become a little more difficult to manage your apps and data when you have too much data flowing to one account.

In such cases, we recommend teams create multiple New Relic accounts (for example, Customer_Name_DEV, Customer_Name_Staging, etc.) and configure their app instances to report to the proper accounts. This requires no extra license and allows you to better manage permissions and give users some flexibility to "experiment" with settings in dev environments. Teams just need to be sure to use the correct license key for the given environment.

6. Choose a strategy and enforce it

The goal of proper app naming is to create a consistent and obvious pattern, so your teams don’t have to guess or pick names willy-nilly. You need to define a naming strategy that clearly articulates the purpose and organizational function of your apps, and then enforce it. If you use an app-deployment or configuration-management tool (like Chef, Ansible, or Puppet), you can apply templates to enforce naming.