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

OctoPerf SaaSOctoPerf EE

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

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

Warning

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

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

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

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 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.

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