doc.overops.com

Naming the Application, Server, and Deployment

Naming the Application

The Dashboard allows you to filter events from specific servers or applications. An application is defined as a group of VMs (JVMs or CLRs) sharing the same logical name (e.g. "consumer-service", "data-provider").

Naming the Java Application

To assign an application name to any monitored JVM:

  1. On startup, add the following JVM argument or agent property:
-Dtakipi.application.name=<APPLICATION_NAME>
takipi.application.name=<APPLICATION_NAME>

Once the application is named, OverOps attaches it to every event thrown in this application, enabling you to filter and view relevant error data.

  1. To filter events from this application, check it in the Servers/Apps filters menu:
Filtering the Dashboard to visualize data from specific applications or machines

Filtering the Dashboard to visualize data from specific applications or machines

Naming the .NET Application

The application name for .NET applications is set through the agent.property takipi.application.name. When using an IIS web application, the application pool name is detected automatically and applied to the name of the application.

Naming the Server

OverOps automatically detects the names of the servers based on their IP address, and allows you to filter events originating from specific machines.

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.

Machine names can be set in two different ways depending on if you are using a Local Collector or a Remote Collector.

Note on setting the deployment name:

If you're setting the deployment name in both a JVM argument/agent property and Manifest, the former will take precedence.

Local Collector

The Collector runs on the same machine as your application.
The machine name can be set in the collector.properties.
To change those names and send OverOps different names for your servers, run the following command:

  sudo /opt/takipi/etc/takipi-setup-machine-name <YourMachineName>

which will set the machine name in the collector properties.

Remote Collector

Many application on various servers will connect to one or several remote collectors.
Set the machine name during the application startup as a JVM argument/agent property:

  1. On startup, add the following JVM argument or agent property:
-Dtakipi.server.name=<Server-Name/Logical-Server-Group>
takipi.server.name=<Server-Name/Logical-Server-Group>
  1. For the changes to take effect, you'll need to restart the OverOps Collector or the application associated with the Micro-Agent.
  2. You can assign the same name to multiple machines, essentially grouping them under a combined "logical" machine name (e.g., "SparkCluster").
  3. Once you've named your VMs and/or machines you can filter the dashboard to show only data coming from those sources, or create Views for them, for example:
    • New events today in a selected application
    • AWS errors detected from a selected machine

Naming the Deployment

OverOps allows you to filter dashboard data by different code versions and deployments. Whenever you deploy new code to your application, you can mark the deployment with a distinct name that will show up in the OverOps Dashboard and allow you to view events coming from this version of the code only, to see which events originated from the deployment, and more.

There are two ways to name your deployment:

  1. Using a JVM argument/agent property passed to your application at start-up
  2. Using a JAR manifest attribute within your packaged application JAR/WAR (Java only)

Naming the Deployment using a JVM Argument or Agent Property

Similarly to the way you can name your application, you can also name the deployment by adding a JVM argument to the application command line (for Java) or by updating the agent property (for both Java and .NET):

  1. On startup, add the following JVM argument or agent property:
 -Dtakipi.deployment.name=<DEPLOYMENT_NAME>
 takipi.deployment.name=<DEPLOYMENT_NAME>
  1. Restart the VM for the new deployment name to take effect.

Naming the Deployment using a JAR or WAR Manifest Attribute (for Java)

If you prefer to bundle the deployment name with the deployed artifacts (for example, during your build process), you can do so by adding a line to your artifact's JAR or WAR manifest. The JAR/WAR manifest is a textual metadata file within your application's JAR/WAR file which describes different properties of your application.
You can find more details here.

To name your deployment via your JAR/WAR's manifest:
Add the following attribute to the file:

Takipi-Deployment-Name: <YourDeploymentName>

This method does not require a VM restart, but the attribute must be read before the VM loads the new JAR/WAR file and its contained bytecode into memory.

Related articles

Introduction to the Event Explorer

Best Practice

See also our related best practice: Naming your Application, Deployments and Server.

Updated about a month ago

Naming the Application, Server, and Deployment


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.