Skip to content

Server Monitoring

Monitoring the infrastructure while running a load tests provides invaluable information about what's happening server side. Understanding which requests are slow is only part of the answer. Monitoring provides the missing part: understanding which part of the infrastructure (Web server, Database, Operating System..) is the bottleneck.

Octoperf supports monitoring a variety of web servers, application servers, databases, operating systems and more. Correlate load testing metrics like response times with backend monitoring metrics like CPU usage in the same report.

How it works

Monitoring Schema

Monitoring Schema

The monitoring agent runs on an on-premise machine. The monitoring agent is basically a docker container which makes regular requests to OctoPerf. The monitoring agent contains everything to monitor web servers, application servers, operating systems and more.

The agent performs only outgoing requests to our platform. This configuration passes through firewalls in most cases. The monitoring agent automatically starts and stops monitoring servers when running load tests.

Overview of prerequisites

Since we use existing components, each technology has its own prerequisites. Here is a summary table, but each more details are available on the dedicated page of each monitor:

Monitoring Protocol Default port Other
Generic JMX TCP (JMX) 9004 Activate remote JMX on JVM
Apache HTTPD HTTP/S 80/443 Activate mod status
Apache tomcat TCP (JMX) 9004 Activate remote JMX on JVM
Lighttpd HTTP/S 80/443 Activate mod status
NGINX HTTP/S 80/443 Activate mod status
MongoDB TCP 27017  Login/password
MySQL TCP (JDBC) 3306 Login/password
Oracle TCP (JDBC) 1521 Login/password
PostgreSQL TCP (JDBC) 5432 Login/password
Linux SSH 22 Login/password
Windows TCP (JMX) 1099 Metrics agent
IIS TCP (JMX) 1099 Metrics agent
SQL Server TCP (JMX) 1099 Metrics agent
Prometheus HTTP/S 80/443
New relic HTTPS 443

Docker Agent

Docker Logo

Octoperf's monitoring agent is packed into a single docker image. This agent contains all the necessary libraries to connect and monitor your infrastructure. Docker containers are flexible and easy to run.

Note that once created, every monitoring connection will be tied to a particular agent. If you remove or recreate the agent, then the monitoring connection will be orphaned. A simple way to fix this is to edit the monitoring connection and save it. This way the next available agent will be used instead.

If you want to make this process automatic, you need to ensure that when you recreate the agent he gets the exact same ID. That can be achieved by overriding the agentId manually:

  • Create an agentId.txt file on the host,

  • Put a random uuid inside it,

  • Add it to the container through a volume: -v ./agentId.txt:/home/octoperf/agentId.txt


Make sure the agentId.txt file doesn't contain any new line or special char otherwise they will be picked as part of the agentId and create unpredictable behavior.

Resources Selection

Linux Applications

Some monitoring modules like Linux can monitor specific disks, network interfaces and more. During the monitor configuration, a step allows to choose which resource should be monitored.

Predefined Counters

Knowing which metrics to monitor when monitoring servers requires a high level expertise. Each monitoring module ships with the most relevant counters. These counters have been carefully selected to immediately provide the best insight about your server health.

This allows to quickly understand performance issues on backend without any specific knowledge required.

Preselected counters

Apache Tomcat Counters

Each monitoring module provides numerous counters and metrics which can be collected. Selecting the right counters can be a tedious and time consuming task, especially if you don't have expertise in that domain.

Each monitoring module pre-selects most relevant counters. The counter selection can be customized to meet advanced user needs.

Computed counters

Some counters are computed using values from multiple other counters such as percentage, substractions or per second conversions. Monitored servers are often exposing raw metrics which need to be reworked before being easily understandable.

Predefined Thresholds

Predefined Thresholds

Each monitoring module ships with pre-defined thresholds. Thresholds raise alerts depending on the value of the counter and how many times it reached the threshold. Threshold allow to quickly pinpoint issues on backend by concentrating on failing counter metrics.

Thresholds can be customized to specific needs and set on any counter. Each monitoring module ships with pre-defined thresholds coming from known industry standards.

Textual counters

Textual Counters

Textual counters provide information like database version, JVM version, thread pool configuration etc. These counters have been designed to keep track of configuration changes across multiple load test. See the impact of a configuration change on response times.

Real Time Monitoring

Monitored counter metrics and threshold alarms are available in real-time during the load test. Knowing server-side performance issues as they occur saves time.

Threshold Alarms Line Chart

Line chart showing % Busy workers and associated threshold alarms raised during the test.