Naming your Applications, Deployments and Servers Best Practices

OverOps Experts
1

Naming your applications, deployments and servers is important. It allows us to aggregate your data and sort, view, and compare them from version over version.

It feeds into our dashboards and without using a naming convention your data loses value.

Application names

What is it?

Application name is a way to enable data aggregation by application

Why use it?

  • Allows the routing of alerts to the teams responsible for each application
  • If you have multiple applications, naming the application will help you quickly identify which application the error came from. It also allows to aggregate error counts by application.
  • Much of the reliability dashboards require good application naming and will be lacking context without it.

How to enable it

Pros

  • Complete context and aggregation of data based on application names
  • Application health over time
  • Code accountability to application teams
  • Routing of alerts to team responsible
  • Prioritization of issues by sensitivity / severity of application

Cons

  • None

Deployment naming

What is it?

Deployment naming is a way to tag code based on deployment and or release versions

Why use it?

  • Deployment naming allows users to see application health and reliability over time, as well as code and exception comparisons between different releases.
  • Much of the reliability dashboards are built around proper deployment naming and they will lack proper context without this.

How to enable it

  • Command line argument when attaching the OverOps agent to the application using the option -Dtakipi.deployment.name=<DEPLOYMENT_NAME> or
  • Recommended approach!
    Via the jar or war manifest file using the manifest property
    Takipi-Deployment-Name:
    (If you are not using the manifest file to name your deployment you will need to change the command line argument every time when you deploy a new version and restarting the application.)
  • Naming the Application, Server, and Deployment
  • Java Agent Properties

Pros

  • Complete context and aggregation of data based on deployment/release version
  • Application health and performance based on release
  • Code accountability targeted to release teams

Cons

  • None

Server names

What is it?

Server naming applies data aggregation and context based on tagging logical grouping of servers and/or containers

Why Use It?

  • Out of The Box OverOps will use the hostname from the server/container as server name. A more logical view or grouping of servers should be discussed to determine the best use of this tag
  • This could be a pod grouping, a customer grouping (meaning servers are deployed for a specific customer), east AWS, west AWS, etc.
  • If not set, hostname from the application will be used by default, and may be cryptic based on how your servers or containers are named.
  • Typically the individual server name is not helpful and we strongly suggest using either logical server group names or just default to a single value which in large deployments will help from a performance standpoint.

Example :

In a typical monolithic web application the actual server IP or VM names are very familiar and has meaning to you, but if you are running on a kubernetes cluster and 1000s of containers running in pods and are going up and down in an highly elastic manner the IPs mean nothing. In those cases your Server Grouping should be named after logical group instances.
Example: prod-app1, prod-api1, prod-api2, prod-service1, prod-sql1, etc.

How to enable?

Agent Naming:

Agent - Command line -Dtakipi.server.name=<YOUR SERVER NAME/GROUPING>

Collector Naming:

Collector - collector.properties file takipi.server.name=<YOUR COLLECTOR NAME/GROUPING>

Pros

  • Additional context and logical grouping of your data
  • Alert routing to server administrators or development teams that maintain the logical grouping that is used.

Cons

  • None