Monitis has recently launched a great monitoring feature called “JMeter Monitor” using 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 blog is mainly focused on the API calls (HTTP requests) monitoring. I will share my personal experience how it helped me to overcome few issues in my application.
Let’s get started to discover the importance of this feature.
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 server after which it will be considered unresponsive)
- Name the monitor
- Set check interval (frequency to execute JMeter Script)
- Provide location from where you want to execute the script
How to setup 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 alert-less monitoring
When the Alert Rules window opens, you need to set up thresholds in your monitor. Threshold indicates 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 setup 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 for the threshold 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.
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 few application APIs which are being accessed 24*7 by several 3rd party vendors from USA-mid & India. Hence, we always need continuous monitoring to make sure that these API calls are up & running from business critical locations.
For our TELECOM partners, we have developed following few REST APIs which help them to track the customer and their corresponding SIM information.
- SIM API
- SIM Usage & 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 of 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 for day & night!
Whenever the threshold is violated, e.g. Response Time SLA breach or Failure in API calls after consecutive several 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 JMeter script execution for a predefined duration.
JMeter monitor has a table view, where you can see:
- Status of the API call: Green is for Pass, Green with blue is a warning, means Threshold Violated), Red is for Threshold Violated for consecutive N number of times
- Sample Date & 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 consecutive, pre-defined number of times, then all those samples will be shown in red color. If you click on any of the samples, it will show the detailed view with the passed and failed requests. If you click on any failed API request, it will display the HTTP request, HTTP response, Sample Load Time.
If all the API calls are within the threshold limit, then the status of each sample will be shown as 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 & USA, hence it’s always important to keep these calls always 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 Header Manager. In each HTTP Request, we have passed
- API End-point,
- Corresponding path to access the functionality,
- Sample Request,
- 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 Regular Expression Extractor we can easily capture any value from the response body/header of any request & pass it to the subsequent requests.
Here’s how it’s actually done.
Even after adding all the required extractors, assertions, the problem we faced is when we were running the script from India, we observed “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! Kudos to Monitis 🙂
Monitis JMeter Monitoring is really an awesome tool for continuous health check-up of your Application API calls, but with a few limitations. Here is an overview of benefits & limitations of JMeter Monitoring:
- Constant Working Script: Once you upload the JMeter script with proper execution frequency and proper alert rules, no manual intervention will be required anymore. 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-mid location only, but soon EU & 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 minimum 5 minutes through a shorter time span is available upon request.
To try JMeter by Monitis now, login to your dashboard
(or create an account if you still don’t have one)!