cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Claudia.Landivar
Community Manager

What naming conventions are recommended when defining configuration objects for APM?

 

We highly recommend the following standard naming conventions for different configuration items used in AppDynamics because sound naming standards are an important practice for:

  • Efficient identification of objects
  • Understanding data context
  • Navigation
  • Searching
  • Housekeeping
  • Decommissioning efforts

plus more...!

 

NOTEIn this article, we are specifying standards for setting configuration items' values, rather than methods. See more below.
These recommendations are based on standard configurations and is not intended to be a universal solution, and therefore may not work with custom-configured instances.

 

In this article...


 

Naming conventions for APM

Successful naming is based on emphasizing the use of common standards. So, where available, use nomenclature that already exists, whether public or company-based. The following tables contain naming best practices for business applications, tiers, nodes, business transactions, database backends, as well as remote services, service endpoints, and information points.

 

Business Application naming conventions

{Country}-{<Customer> Application name}-{Environment}
  • {Country} should reflect the country the application is for, or a region if it serves more than a single country
  • {<Customer> Application name} should reflect the <Customer> application name as recorded in the ITEM NAME field in the CMDB. Contact the Center of Excellence or Administrator if a name other than the CMDB name needs to be used.
  • {Environment} should be one of the following:
    • Dev
    • QA
    • UAT
    • PREPROD
    • PROD

Back to Contents

 

 

Naming conventions for tiers
What constitutes a tier?

A tier is a cluster of nodes that do the exact same thing, serving the same customer base, executing the same functionality, having the same dataset;
In the end, a cluster of processes.

.NET Agent tiers

 

For .NET, allow the agent to automatically name tiers where possible (i.e., where all IIS sites are monitored and they are already well named)

  • Manually name .NET tiers using environment variables when only a single tier is required
  • Use config.xml if multiple tiers are required on a single server
All other tier types
{To be decided by the application teams, 
with assistance from AppDynamics-knowledgeable resources}
  • Application teams to define a naming standard, with assistance from AppDynamics-knowledgeable resources.
  • The naming standard should conform to the overarching naming principlesnames chosen for any configuration item should be a sensible, non-technical description

Back to Contents

 

 

Naming conventions for nodes

.NET Agent nodes

Allow the agent to automatically name nodes where possible, to reduce configuration maintenance. 

Alternatively: 

  • If a single node is required, manually name .NET nodes using environment variables
  • If multiple nodes are required on a single server, use config.xml
All other Agent-type nodes

{Server Hostname} - {Tier or JVM type}

Dynamic or
auto-scaling scenarios 

 

When servers are scaled up and down at regular intervals due to demand, use
reuse node name to avoid node explosion.

  • Node Name must be BLANK
  • Set reuse node name
    Instructions: Java or .NET
  • Set node name prefix
    Instructions: Java or .NET

If historical data must be retained for specific nodes and this must be easily identified, then do not use the reuse node name functionality. This functionality creates a new node using a unique host identifier for each instance that is started with the AppDynamics agent.

Redhat Openshift

{ProjectID}-{ServiceName}-{ClusterNumber-{DataCentre}-{PodID}-{ContainerID}

Example: 7786-CSPEPSCUSTCREATE01-gl-16-x3o0n

Use this naming standard for nodes deployed on RedHat Openshift, with the following guidelines: 

  • Not all of the properties must be used
  • The node name must be unique and identify the underlying container or pod 
  • {ContainerID} is optional and only required if there are multiple containers per pod

Reference: Find the definitions of these Redhat Openshift terms here.

Back to Contents

 

 

Naming conventions for Business Transactions

{To be decided by the application teams, with assistance from AppDynamics knowledgeable resources}

  • Business Transactions (BTs)  should reflect (as closely as possible) the primary function of the business consuming this BT. Naming should therefore also be related to that functionality.

    For example, if you have a payment function, call it /Pay/Swift

  • As Custom Match rules names are also used as the name for matching business transactions, the Custom Match Rule names should conform to the above-specified standard for Business Transaction conventions.
  • As required to conform to the overarching naming principles, use manual renaming or custom match rules: names chosen for any configuration item should be a sensible, non-technical description

Back to Contents

 

 

Naming conventions for database backends

{Country} - {DB name} - {Environment}

  • {DB name} should be the CMDB name of the Database, unless the CMDB name does not adhere to the overarching naming principles. In this case, the {DB name} should be decided by the application teams with assistance from AppDynamics-knowledgeable resources
  • As required to conform to the overarching naming principles, use manual renaming or custom match rules: names chosen for any configuration item should be a sensible, non-technical description
  • Database collector names and APM database back-end names for the same database should match (or be very similar) whenever possible

Back to Contents

 

 

Remote Services, Service Endpoints, and Information Points

{To be decided by the application teams, with assistance from AppDynamics-knowledgeable resources}

  • As required to conform to the overarching naming principle, use manual renaming or custom match rules: names chosen for any configuration item should be a sensible, non-technical description
  • When defining backend names, make sure that the backend is unique from a functionality perspective. Also, take care to keep naming simple.
  • If names are not unique, e.g., with a central load balancer, there will be issues with tier to tier correlation. Unique naming offers benefits you would be left without.

    For example:
    https://LoadBalancer/serviceA
    https://LoadBalancer/serviceB

    It makes sense to enable  at least the first segment because
    • the routing will be two different things
    • if the backend shows, you know which specific service is affected by poor performance

Back to Contents

 

Overarching principles for naming conventions

Some configuration items do not specify a strict pattern or convention. Instead, we leave it up to you to decide. In such cases the following principle should always apply:

 

Names chosen for any configuration item should be a sensible, non-technical description.

 

DO THIS

NOT THIS

Use plain language

Avoid too-formal, distancing language

Be descriptive, but concise

Don’t be verbose—or curt

Use business terminology where possible

Don’t use technical terms

Make it meaningful to all intended users

Avoid jargon that won’t be familiar to all of the intended users.
When in doubt, leave it out.

 

PLEASE NOTE: In this article, we are not specifying the method of setting values for configuration items, only standards for the values themselves. In the case of agent configuration properties, use one of the following methods to set the values:

  • Configuration files
  • System Properties
  • Environment Variables

Let us know in the comments below if you have further questions on methods.


 

Additional Resources

 

Need to go deeper? Reach out to Call a Consultant

Version history
Last update:
‎02-03-2022 09:06 PM
Updated by: