Best-Practice - Naming your Applications, Deployments and Servers Follow

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

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.

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

Comments

0 comments