The Dashboard allows you to filter events from specific servers or applications. An application is defined as a group of JVMs sharing the same logical name (e.g. "consumer-service", "data-provider").
See also our related best practice: Naming your Application, Deployments and Server.
To assign an application name to any monitored JVM:
- On startup, add the following JVM argument:
Once the application is named, OverOps attaches it to every event thrown in this application, enabling you to filter and view relevant error data.
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
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 and Manifest, the JVM argument will take precedence.
The collector is running 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:
1a. Running the following command:
sudo /opt/takipi/etc/takipi-setup-machine-name <YourMachineName>
which will set the machine name in the collector properties.
Many application on various servers will connect to one or several remote collectors.
You set the machine name during the application startup as a JVM argument.
1b. On startup, add the following JVM argument:
- For changes to take effect, you have to restart the OverOps Collector or respectively the application associated with that Agent.
You can assign the same name to multiple machines, essentially grouping them under a combined "logical" machine name (e.g. "SparkCluster").
Once you've named your JVMs and/or machines you can filter the Dashboard to show only data coming from those sources, or create Views to display for instance
New events today in a selected application
AWS errors detected from a selected machine.
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:
- Using a JVM argument passed to your application at start-up
- Using a JAR manifest attribute within your packaged application JAR/WAR.
As the application, you can name the deployment by adding a JVM argument to the application command line:
A JVM restart is required for the new deployment name to take effect.
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:
This method does not require a JVM restart, but the attribute must be read before the JVM loads the new JAR/WAR file and its contained bytecode into memory.