I use KEMP load balancers in our IT infrastructure and would like to monitor our KEMP devices. In particular I want to monitor a KEMP LoadMaster.
How can I monitor my KEMP LoadMaster with PRTG?
Votes:
I use KEMP load balancers in our IT infrastructure and would like to monitor our KEMP devices. In particular I want to monitor a KEMP LoadMaster.
How can I monitor my KEMP LoadMaster with PRTG?
1 Reply
Votes:
This article applies to PRTG Network Monitor 17.4.35 or later
PRTG provides some sensor types that work with Kemp LoadMasters by default, for example, the SNMP Traffic sensor and the SNMP System Uptime sensor. If you need KEMP sensors with more detailed and specific metrics, follow the instructions in this article.
You can use the device template that we provide below to automatically create custom sensors with the PRTG auto-discovery.
The metrics that are available can vary. The sensors can monitor the following if the data is available:
In particular, these are the sensors that measure the statistics related to the reverse proxy that does the SSL offloading for a PRTG remote probe and the PRTG web interface.
The device template creates the available and compatible sensors based on the data at hand. The sensors implement default alerts whenever possible, but you can still fine-tune most channels by defining additional limits in the sensor channel settings or by modifying the lookups that are included by default.
The created sensors look like this:
KEMP LoadMaster Health Sensor (enlarge)
KEMP LoadMaster Status Sensor (enlarge)
KEMP LoadMaster Device (enlarge)
Have any issues? Please don't hesitate to contact us by replying to this post or via a support ticket. Please make sure to mention this article. Read ahead for troubleshooting steps that you can take in advance.
Your auto-discovery log tells you a lot about what went wrong during the sensor's deployment. You can troubleshoot the auto-discovery by inspecting the auto-discovery log. If you get entries like the one below (NOT FOUND), it means that the required protocol or Object Identifier (OID) is not available and the sensors can't be deployed.
[...]
12/8/2017 2:37:59 PM: Template Loaded; Device ID: 2828; Name: Kemp-LM
12/8/2017 2:38:00 PM: Template Check; Device ID: 2828; Check ID: ping; FOUND
12/8/2017 2:38:01 PM: Template Check; Device ID: 2828; Check ID: snmp; FOUND
12/8/2017 2:38:02 PM: Template Check; Device ID: 2828; Check ID: snmpkemplm_rstable_index; NOT FOUND
[...]
In the example above, some sensors were skipped because the device did not respond to the snmpkemplm_rstable_index check. This means that this data is probably not available on your device. You can track this data by looking for the name after snmp_. In this case, a search for kemplm_rstable_index will tell you what OID from what MIB is missing.
You can also use this log to identify if the discovery was interrupted because the device did not respond to ping or to a basic SNMP check.
If the discovery log is not sufficient, you can review the SNMP data directly from your device. To do so, save the text below (in the white box) as .txt and use it with the Scan Script option in our SNMP Tester. This will allow you to review which SNMP queries succeed and which do not deliver any data. Please have this information at hand when contacting our support team.
--------
Walk Default
--------
Uptime
walk=1.3.6.1.2.1.1.3
--------
MIB-2 System
walk=1.3.6.1.2.1.1
--------
Sensor Specific Queries
---
-->kemplm_health
Deamon State LKUP
walk=1.3.6.1.4.1.12196.13.0.7
---
HA State
walk=1.3.6.1.4.1.12196.13.0.9
---
Num Services
walk=1.3.6.1.4.1.12196.13.0.2
---
Current SSL TPS
walk=1.3.6.1.4.1.12196.13.0.12
---
Total Current TPS
walk=1.3.6.1.4.1.12196.13.0.11
---
CPU Usage
walk=1.3.6.1.4.1.2021.10.1.3
---
Total Memory
walk=1.3.6.1.4.1.2021.4.5
---
Available Memory
walk=1.3.6.1.4.1.2021.4.6
---
Uptime
walk=1.3.6.1.2.1.1.3
---
-->kemplm_rstable
rSstate
walk=1.3.6.1.4.1.12196.13.2.1.8
---
rSActiveConns
walk=1.3.6.1.4.1.12196.13.2.1.17
---
rSConns
walk=1.3.6.1.4.1.12196.13.2.1.12
---
rSInPkts
walk=1.3.6.1.4.1.12196.13.2.1.13
---
rSOutPkts
walk=1.3.6.1.4.1.12196.13.2.1.14
---
-->kemplm_vstable
vSstate
walk=1.3.6.1.4.1.12196.13.1.1.14
---
vSActiveConns
walk=1.3.6.1.4.1.12196.13.1.1.21
---
vSConns
walk=1.3.6.1.4.1.12196.13.1.1.16
---
vSInPkts
walk=1.3.6.1.4.1.12196.13.1.1.17
---
vSOutPkts
walk=1.3.6.1.4.1.12196.13.1.1.18
Created on Dec 14, 2017 3:49:57 PM by
Gerald Schoch [Paessler Support]
Last change on Aug 13, 2018 12:38:22 PM by
Noah Loskarn [Paessler Support]
(1)
●2
©2024 Paessler AG Terms & Conditions Privacy Policy Legal Notice Download & Install
Add comment