Monitis has recently launched a great monitoring feature called “JMeter Monitor," with which we can continuously monitor the status of various types of samplers/requests coded in JMeter script, e.g. HTTP/FTP/TCP/JDBC/JMS (Message Queue), etc.
This post is mainly focused on the API calls (HTTP requests) monitoring. I will share my personal experience and how it helped me to overcome a few issues in my application.
Let’s get started!
How to Setup JMeter Monitoring in Monitis
Before getting into the details of the use cases, let’s see how the setup of the JMeter monitor is done.
To add this feature, go to the Monitors top menu and select Application Monitors -> JMeter.
In the opened JMeter monitor window, fill in the necessary information:
- Upload your JMeter Script (.jmx file).
- Enter limit for timeout (Maximum Response Time in seconds from the server after which it will be considered unresponsive).
- Name the monitor.
- Set check interval (frequency to execute JMeter Script).
- Provide a location from where you want to execute the script.
Step 3: Alert Configuration
How to set up alerting preferences:
- Send alert to all contacts: all the contacts in your account will be notified upon an error/warning.
- Custom configuration: send alerts to selected contacts.
- No Alerts: if you prefer alertless monitoring.
Step 4: Threshold Configuration
When the Alert Rules window opens, you need to set up thresholds in your monitor. The threshold indicates the health status of the application. In Monitis, there are two severity level thresholds:
First, a user needs to choose whether to be alerted upon a Warning or a Critical issue and then set up rules for each of these types. A user needs to define conditions (one or more) for the monitor when adding a threshold to it.
For JMeter monitoring, the threshold condition is a composite parameter that consists of 2 parts: availability and performance, which are connected with logical OR.
As you can see, you can select either the availability part only (“Result is error”), the performance part only (“ANY/ALL metrics match the condition below”), or both the availability and performance tied by a logical OR for the threshold.
Once the condition is selected, preferred conditions need to be set based on which alerts will be received.
- Success Flag = False or True: Any request from JMeter is passed or failed.
- Latency (ms) = Violation of Response Time SLA.
Both these rules will allow you to set the state as “Critical” or “Warning” depending upon the number of consecutive checks.
Now you are all set for your JMeter Monitoring. Let’s start with a practical use-case.
JMeter Monitoring Use-Case
We have a few application APIs which are being accessed 24*7 by several 3rd party vendors from the USA and India. Hence, we always need continuous monitoring to make sure that these API calls are up and running from business-critical locations.
For our TELECOM partners, we have developed the following few REST APIs which help them to track the customer and their corresponding SIM information.
- SIM API
- SIM Usage and Cost Information
- SIM History
- Update SIM Data
- Allocate SIM
- Activate SIM
- Suspend SIM
- Resume SIM
We have some other customers who use our API for sending messages(Text/Binary).
- SMS API:
- Bulk Text SMS Send
- Bulk Binary SMS Send, etc.
Here is a snippet of these API calls coded in JMeter script.
I uploaded my JMeter script, set the execution interval to every 5 minutes, set the proper alert technique along with the rules (Threshold) and, voila, it provides me the execution result after every 5 minutes, both day and night!
Whenever the threshold is violated, e.g. a response time SLA breach or a failure in API calls after several consecutive checks, it sends me an email saying, “Critical Threshold Violated.”
JMeter Monitor Data View on Dashboard
On your Monitis dashboard, you can observe an overview of all the samples (taken after 5 minutes) collected by the JMeter script execution for a predefined duration.
The JMeter monitor has a table view, where you can see:
- The status of the API call: green is for a pass, green with blue is a warning (which means Threshold Violated), red is for threshold violated a consecutive (N) number of times.
- Sample date and time.
- Response time (in ms): total time for JMeter script execution.
- Status Flag: Request is failed or passed.
If the threshold you set is violated for a consecutive, pre-defined number of times, then all those samples will be shown in red. If you click on any of the samples, it will show the detailed view with the requestst that both passed and failed. If you click on any failed API request, it will display the HTTP request, HTTP response, and Sample Load Time.
If all the API calls are within the threshold limit, then the status of each sample will be shown in green.
Note: Corresponding request/response will not be visible for any passed sample.
How It Helped Me to Identify a Performance Issue
As I already mentioned, our application API calls are being accessed by a few 3rd party vendors within India and the USA, hence it’s always important to always keep these calls available at any given moment.
We were running our coded JMeter script from India in our own infrastructure, and for the USA it was done using Monitis.
We were able to successfully simulate these API calls in JMeter. For each of the operations, we have added separate HTTP Requests (Sampler) and a Header Manager. In each HTTP Request, we have passed:
- An API end-point.
- A corresponding path to access the functionality:
- Sample Request
- A Request Header (e.g. Authentication Token).
These API calls are accessible only with a proper “Authentication Token” which can be generated using 'Generate Bearer Token API.' Once the token is created, it has to be passed with the header of subsequent API calls.
In JMeter, using the Regular Expression Extractor, we can easily capture any value from the response body/header of any request, and pass it to the subsequent requests.
Here’s how it’s actually done.
Even after adding all the required extractors and assertions, the problem we faced is when we were running the script from India, we observed a “Connection Timeout” error for every single API call, but the same script was running absolutely fine from the USA.
After a thorough examination, we found out that this issue was occurring due to a network firewall misconfiguration. We changed the firewall configuration, and it worked perfectly fine from India too!
Monitis JMeter Monitoring is really an awesome tool for continuous health check-ups of your Application API calls, but with a few limitations. Here is an overview of the benefits and limitations of JMeter Monitoring:
- Constant Working Script: Once you upload the JMeter script with the proper execution frequency and alert rules, no further manual intervention will be required. You can monitor the health status at any time
- Root Cause Analysis: If any of the API calls fail during execution, you can easily dig into it to discover the root cause by comparing the failed HTTP response against the passed one.
- Incident Management: Monitis has an automated alert technique which can be easily configured to receive notification whenever your monitor(s) report a problem. Monitis’s Alert Management technique is available 24*7, hence any warning/critical issue reported at any time will automatically be notified.
- Monitoring from multiple locations: You can check the health status of your application from any business critical location. Currently, JMeter monitoring supports USA-based locations only, but soon the EU and Asia will be onboard.
- JMeter Monitoring supports execution with only a single user, and that is to avoid DOS attacks and other security reasons. Monitis has a separate monitoring feature called “Web Stress Tester” for load/stress testing of any application with multiple concurrent users.
- Sample collection time of the JMeter script is by default set to a minimum of 5 minutes, though a shorter time span is available upon request.