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
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:
|
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 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
|
|
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
