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¶
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:
|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|
|Windows||TCP (JMX)||1099||Metrics agent|
|IIS||TCP (JMX)||1099||Metrics agent|
|SQL Server||TCP (JMX)||1099||Metrics 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:
agentId.txtfile on the host,
Put a random uuid inside it,
Add it to the container through a volume:
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.
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.
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.
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.
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.
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 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.