For APM, what naming conventions are recommended?

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...!

NOTE | In 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
Overarching principles for naming conventions
Additional Resources

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}
All other tier types	Application teams to define a naming standard, with assistance from AppDynamics-knowledgeable resources. The naming standard should conform to the overarching naming principles: names 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
Redhat Openshift	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.

For APM, what naming conventions are recommended?