iRule to set minimum threshold?

It may or may not utilize an iRule, but by "minimum threshold", what do you mean? Total requests per second, bytes per second, or something else? By "alert", do you mean an SNMP trap, or something else?

It may or may not utilize an iRule, but by "minimum threshold", what do you mean? Total requests per second, bytes per second, or something else? By "alert", do you mean an SNMP trap, or something else?

If you really want to do this with an iRule, that is also possible, but it'll be somewhat complicated and fairly expensive. The problem with this approach is that an iRule fires for each "connection" (TCP connection or UDP flow establishment), so you must coordinate between invocations to ensure that you trigger only once per period.

As an alternative, you may solve this by using SNMP to get

ltmVirtualServStatTotRequests

snmpget -c public -v 2c localhost ltmVirtualServStatTotRequests.17.47.67.111.109.109.111.110.47.118.115.45.115.105.112.45.48.49

In my case, this retrieves the total requests for a Virtual Server named "/Common/vs-sip-01". To figure out the table OID index for a particular Virtual Server, you can do this:

snmpbulkwalk -c public -v 2c localhost ltmVirtualServStatTotRequests

The output will be encoded in ASCII. To get the actual OID, compare that output to:

snmpbulkwalk -On -c public -v 2c localhost ltmVirtualServStatTotRequests

The OID for

ltmVirtualServStatTotRequests

.1.3.6.1.4.1.3375.2.2.10.2.3.1.27

Once you retrieve the value from this particular variable (it's a 64-bit counter), compute the RPS for the period of collection. Thus, if you collect every 10 seconds, the RPS is:

r = (L - c) / 10

where L is the counter value during the last collection, c is the current counter value and 10 is the period of collection. Naturally, this means you'd need to store the value from each collection somewhere.

You could do this collection on an external NMS, of course. If, however, you want to do this on the BIG-IP itself, and your version is at least 11.4.0, you could use an iCall periodic script:

• iCall - All New Event-Based Automation System

If you are using a version before 11.4.0, you could technically use cron, but you cannot guarantee that your cron job would survive upgrades. An alternative is to create an external monitor that performs the collection and computation. It would need to be associated with an object. Typically, I associate it with a pool member, and make it always return an "up" value (in which case, you'd also assign a "real" monitor to provide actual status).

Once you've collected and computed, if the value drops below your desired threshold, you could either alert/email directly, or you could write to syslog's local0 facility (that is /var/log/ltm unless you changed your syslog configuration [but don't do that :)]). Then, you can use alertd to perform some action (a trap, an email, or both):

• SOL3667: Configuring alerts to send email notifications
• SOL3727: Configuring custom SNMP traps

If you really want to do this with an iRule, that is also possible, but it'll be somewhat complicated and fairly expensive. The problem with this approach is that an iRule fires for each "connection" (TCP connection or UDP flow establishment), so you must coordinate between invocations to ensure that you trigger only once per period.

As an alternative, you may solve this by using SNMP to get

ltmVirtualServStatTotRequests

snmpget -c public -v 2c localhost ltmVirtualServStatTotRequests.17.47.67.111.109.109.111.110.47.118.115.45.115.105.112.45.48.49

In my case, this retrieves the total requests for a Virtual Server named "/Common/vs-sip-01". To figure out the table OID index for a particular Virtual Server, you can do this:

snmpbulkwalk -c public -v 2c localhost ltmVirtualServStatTotRequests

The output will be encoded in ASCII. To get the actual OID, compare that output to:

snmpbulkwalk -On -c public -v 2c localhost ltmVirtualServStatTotRequests

The OID for

ltmVirtualServStatTotRequests

.1.3.6.1.4.1.3375.2.2.10.2.3.1.27

Once you retrieve the value from this particular variable (it's a 64-bit counter), compute the RPS for the period of collection. Thus, if you collect every 10 seconds, the RPS is:

r = (L - c) / 10

where L is the counter value during the last collection, c is the current counter value and 10 is the period of collection. Naturally, this means you'd need to store the value from each collection somewhere.

You could do this collection on an external NMS, of course. If, however, you want to do this on the BIG-IP itself, and your version is at least 11.4.0, you could use an iCall periodic script:

• iCall - All New Event-Based Automation System

If you are using a version before 11.4.0, you could technically use cron, but you cannot guarantee that your cron job would survive upgrades. An alternative is to create an external monitor that performs the collection and computation. It would need to be associated with an object. Typically, I associate it with a pool member, and make it always return an "up" value (in which case, you'd also assign a "real" monitor to provide actual status).

Once you've collected and computed, if the value drops below your desired threshold, you could either alert/email directly, or you could write to syslog's local0 facility (that is /var/log/ltm unless you changed your syslog configuration [but don't do that :)]). Then, you can use alertd to perform some action (a trap, an email, or both):

• SOL3667: Configuring alerts to send email notifications
• SOL3727: Configuring custom SNMP traps