F5 Load Traffic Manager – 10 Best Practices for Application Monitoring
The F5 Networks BIG-IP platform allows you to manage network traffic so applications are always fast, available, and secure. In a large environment, it is important that your F5 devices are configured correctly, and when an issue occurs administrators can respond quickly so that internal and external customer experiences are not impacted. With the Indeni Platform engineering and operations are able to automatically check for the symptoms if / when they happen again in the future.
Here are some of the top best practices to monitor applications with F5 Networks Load Traffic Manager:
Server up/down
A node marked as down by a monitor, or disabled by an administrator, results in reduced pool capacity or in a worst-case scenario, downtime. Disabling nodes is common during ie. a maintenance window but it is easily forgotten. Without Indeni an administrator would login to the device’s web interface and click on “Local Traffic” -> “Nodes”. This would show a list of the nodes and their statuses. In case the configuration is divided into multiple partitions changing to the “All [Read-only]” partition is recommended. Indeni will do this for the admin, and alert one or more servers that the load balancer is directing traffic to is down.
View source code
Syslog Servers In Use
In case of a successful intrusion attempt, it is imperative to be able to trust the log files. In order to be able to do that it is good to have a remote syslog server configured. That way the attacker would have a harder time to hide the tracks. Also, in case of an outage or hardware failure, a remote syslog server could be critical in order to find the root cause. Indeni can verify that certain syslog servers are configured on a monitored device.
View source code
Server / Pool high response times
Nodes that have slow response times may be indicative of an application health issue. It is important to measure the response time of each node against a calculated average to note if it’s too high. Indeni will alert if the ping from the load balancer to specific servers is too high.
View source code
Pool members unavailable
A node disabled by an administrator results in reduced pool capacity or in a worst-case scenario, downtime. Disabling nodes is common during ie. a maintenance but it is easily forgotten. This metric would warn administrators when a node is not ready to accept traffic. Indeni will generate a warning message if a pool member which should be available is not.
View source code
Pools operating at a low capacity
A pool that is not running with full capacity could cause slowness in the application, service disruption, or in worst case downtime. Indeni tracks this by measuring the available members of the pool in percent. Indeni will alert if the number of members available in the pool is too low based on the percentage of members available out of the total. This proactive alert gives you advance notice to correct the problem before service is impacted.
View source code
SNAT pool exhaustion warning
A SNAT (Secure Network Address Translation) pool represents a pool of translation addresses that you configure on the BIG-IP system. A SNAT address can only have 65,512 connections each, this can cause service disruption. Indeni will alert if exhaustion warnings is found in the log files.
SNAT pool near maximum allocated
SNAT pool exhaustion could be a problem in environments that have large amounts of connections and too few resource NAT IP’s. If all available port combinations are exhausted, it will lead to connections being dropped by the system.
SNAT translation has an indefinite timeout configured
The default SNAT idle timeout is ‘indefinite’. A SNAT translation object with an indefinite idle timeout could result in stalled connections and resource exhaustion. The recommended best practice is to set a timeout to the smallest possible finite value that your applications allow. Indeni will issue a warning if the idle timeout for the SNAT translation object is indefinite.
Default Action on Service Down configured
The Action On Service Down feature allows the BIG-IP system to choose another pool member and rebind the client connection to a new server connection if the target pool member becomes unavailable. The default option is set to “None”. The BIG-IP system takes no action on existing connections and it expects the clients to resume gracefully on their own. With a good monitor, you can determine the status of a pool member. A better option is set to “Reject”. Once the target pool member is deemed unavailable, the BIG-IP system immediately alerts the client by resetting the connection, causing the client to attempt a new connection. This ensures that the client has an optimal chance of connecting to a functioning pool member. Indeni will alert when the device configuration does not follow this best practice.
Default Node Monitor is not configured
It is good practice to have a basic check for node monitors as it is easier to correlate between multiple failing members during an outage. Indeni will alert if Default Node Monitor is not enabled.
Want more networking best practices? Download Indeni today.