Templates for Kemp Loadbalancer and Vircom Modusgate

Using the Kemp Technologies Load Master MIBs you can define your own Application Template using SAM's SNMP Monitor or NPM's Universal Device Pollers for monitoring these devices.

Did either of you ever create a template?  If so, I'd love to see what you did as I need to define something and I'd rather not start from scratch.

I am working on developing my own Application Monitors and Alerts using Powershell and OIDs.  Slow going, but we're getting information now.

The problem here is that the VIP OIDs change, because we all create different Virtual services and real servers, so all your OID's are going to be different for any of those things.  That being said, using the MIB browser is the only way to go.

Here are a few standard OIDs you can use with current VLM (Virtual Load Master):

TCP Connections:  1.3.6.1.2.1.6.9.0  (64k is the critical fail point unless you do SSL offloading, and then it's half that)  Ask support if you need this, but there are only a few use cases where this is even important.  I happen to have one of those use cases.

SSL TPS:  1.3.6.1.4.1.12196.13.0.12.0

TCP Resets:  1.3.6.1.2.1.6.8.0

TCP Attempt Fails:  1.3.6.1.2.1.6.7.0

HA State:  1.3.6.1.4.1.12196.13.0.9.0 (the different states are represented by numbers)

there are different OID's for each real server and each Virtual service, which are the most salient pieces of data you are looking for, but they are not static, so putting them here is nearly pointless. MIB Browser rules

Here's two examples so that you can use the MIB browser and identify where to look:

VLM:   1.3.6.1.4.1.12196.13.1.1.21.3

LM 3400:  1.3.6.1.4.1.12196.13.1.1.21.1

If you find these, you will know what a virtual service looks like in the MIB tree and you can take it from there.

Here are some of the custom views that we are using:

Monitors on individual VS& RS:

Then I created a Application Monitor for VS Monitor Details and we get alerts if more than 2 RS are down on a VS.

Would you happen to have anything new to share on your Kemp-associated creations?

We haven't done anything beyond what I originally did.  My team is great at asking for me to monitor something, then not using what I produce!  What were you looking for?

OK,

While some of these comments are moderately helpful, including my own; we did actually dig into this and since nobody who has already figured this out is sharing anything other than images of the GUI results, (which by itself is pretty infuriating...)

I also grabbed a bunch of the technical notes and details from a few MIB lists online, but that was a while ago and I have forgotten where those were.

Here it is:

Monitoring Kemp Load Balancers via SNMP

This reflects SolarWinds monitors currently in use. See appendixes below.

Monitoring System Levels

There are a base set of OID’s that are useful when monitoring a Kemp Load Master via SNMP:

1. tcpCurrEstab    -From a previous Thwack post. Not validated as reliable.

OID:  1.3.6.1.2.1.6.9

Use:  Currently established connections.

Technical desc.:  "The number of TCP connections for which the current state is either ESTABLISHED or CLOSE-WAIT."

Method:  GET NEXT

1. sslTps -From a previous Thwack post. Validated as reliable

OID:  1.3.6.1.4.1.12196.13.0.12

Use:  Kemp Load Balancers have an internal cap on TPS connections:  Consult your Kemp support for details.  You are in much better shape if you are using a virtual Device in this case, since you can adjust CPU & RAM resources on your own.  Either way, you’ll want to keep an eye on this for capacity planning and respond accordingly.

Technical desc.: “Current SSL TPS”

Method:  GET

1. tcpEstabResets  -From a previous Thwack post. Not validated as reliable.

OID:  1.3.6.1.2.1.6.8

Use:  Excessive resets can be an indicator of connectivity, or other network issues being experienced by clients attempting to use your Virtual Services.

Technical desc.:  The number of times that TCP connections have made a direct

transition to the CLOSED state from either the ESTABLISHED

state or the CLOSE-WAIT state.

Method: GET NEXT

1. tcpAttemptFails  -From a previous Thwack post. Not validated as reliable.

OID:  1.3.6.1.2.1.6.7

Use:  Failed client connection attempts. Combined with other indicators, such as low current established connections, this could help identify possible problem areas.

Technical desc.:  The number of times that TCP connections have made a direct transition to the CLOSED state from either the SYN-SENT state or the SYN-RCVD state, plus the number of times that TCP connections have made a direct transition to the LISTEN state from the SYN-RCVD state.

Method: GET NEXT

1. hAstate  -From a previous Thwack post. Validated as reliable

OID:  1.3.6.1.4.1.12196.13.0.9

Use:  When you don’t have an HA indicator, such as with SolarWinds monitoring; this can give you that visual cue you are looking for. 

If you have an HA pair of Load Balancers, setting the alert state to “2”(Secondary) or “3” (Passive) and the critical alert state to “0,” you can alert when HA is broken, and you get a visual indicator from your monitoring software which device is currently holding the master role.

Technical desc.:  This returns the current HA state of this device.  Configuring your alert levels correctly utilizing the 4 available status codes should result in the following:

• An Up status indicates this device is currently the in the HA master device state. 
• A warning status indicates that this device is currently in the HA Secondary device state
• A critical status indicates that this device is not in any HA state which may indicate HA fail-over is broken

Method: GET

Critical note: For SolarWinds SAM or NPM, you have to add “.0” to the end in order for the monitor to work, but you will only find these in an MIB Browser search without the trailing “.0”

Monitoring Virtual Services and Real Servers

Virtual Services

Now most Sys-Admin type folks want to know about those Virtual Services and Real Servers.  How can those be monitored?

Use the MIB browser to go here: 1.3.6.1.4.1.12196.13.1

(BTW you can search for b100VSTable to get here too) 

Here you find a list of things to use, the 2 most useful will be vSidx and vSname.  Both list all the currently configured Virtual Services (VS) on your Kemp Load balancer by ID and by name and both lists are in the same order, so can paste both lists side-by-side in excel and now have you have something to actually work with, because these ID's are used in the OID's too.

Now that you have a list to work with, you can build your monitors and collect ports, IP addresses, persistence settings; the works. 

I'll give you 2 examples here:

VS WidgetSite-BETA: is listed on ID #1 and you want to monitor the status.

Label your new monitor WidgetSite-BETA

Use this IOD as a base: 

OID: 1.3.6.1.4.1.12196.13.1.1.14

Now add the ID to the end of it and you use this OID to monitor the status of the “WidgetSite-BETA” Virtual Service.

OID: 1.3.6.1.4.1.12196.13.1.1.14.1

Now you have a monitored Virtual Service in place and you can duplicate that process for all your Virtual Services.

Real Servers

Monitoring Real Servers is done pretty much the same way. You can search your MIB Browser for b100RSTable and find that section, or you can just go to OID 1.3.6.1.4.1.12196.13.2 and start from there.

You will find a lot of options under rsEntry and just like with the Virtual Services, find the ID and Name. 

Lastly; you can also find VS, RS and HA state change OID’s at 1.3.6.1.4.1.12196.13.3.1 (b100Notifications)