What’s new in F5 Insight for ADSP v1.1?
Introduction F5 Insight for ADSP, a key component of the F5 Application Delivery and Security Platform (ADSP), helps teams monitor and secure apps that are spread across hybrid, multi-cloud and AI environments. In this article, I’ll highlight some of the new features introduced in F5 Insight v1.1. Demo Video Disaster Recovery Now with enhanced User Workflows. The F5 Insight Disaster Recovery feature helps your system keep running even if one server fails. It works by maintaining two synchronized systems: Primary instance — Handles all active operations. Standby instance — A backup system that continuously syncs data from the primary. If the Primary fails or requires maintenance, you can “promote” the Standby to take over as the Primary. After fixing the first system, you can perform a “failback” to restore it to normal operation. Change to Default User Credentials on First Boot F5 Insight now supports a default user and random password login workflow. You can either use cloud-init (like previous version) or the default user credential option. NOTE: This applies to new installations, not upgrades. In previous versions of F5 Insight, the procedure to set the admin username/password involved utilizing the “cloud-init” function. There is now an alternative method for setting the admin username/password. A unique password will be generated at first boot, allowing administrators to log in for the first time using this password. This randomly generated password must be changed after initially logging in. UI Improvements Previous versions of F5 Insight dashboards with large data volumes could experience some performance degradation due to extensive configuration objects. This has been resolved by implementing comprehensive performance optimizations across the dashboard platform, enabling it to handle significantly larger datasets while maintaining a fast and responsive user experience. Upgrade Procedure You’ve probably never upgraded your F5 Insight version, so it’s time to learn how. First, download the updated software version from myf5.com. The updated software is distributed as a bundled gzipped tar file. Then, upload the new version to your F5 Insight from the About screen, then click Upgrade. After uploading the new version, select Start Upgrade. The upgrade will take several minutes. Conclusion The latest version of F5 Insight for ADSP offers expanded functionality with Disaster Recovery. It also provides a convenient alternative to “cloud-init” for setting the initial administrative username & password. Finally, there are several UI improvements aimed at making the user experience better and more seamless. Upgrade today to the latest version of F5 Insight for ADSP and enjoy the following benefits: Streamline the initial configuration of F5 Insight with the new default admin user and dynamically generated password. Enjoy expanded workflows with the Disaster Recovery feature. Benefit from the many UI improvements. Related Content Introducing F5 Insight for ADSP F5 Insight for ADSP – Initial Setup in VMware F5 Insight for ADSP - A Closer Look F5 Insight for ADSP Documentation F5 Insight Product Page F5 Insight Release Blog
F5 Insight for ADSP – Initial Setup in VMware
Demo Video Initial VMware Configuration Download the ova file from myf5.com. In VMware choose the Create/Register VM option and choose Deploy a virtual machine from an OVF or OVA file. Continue through the install wizard, which will upload the ova file to your VMware server. Uncheck the option to Power on automatically so you can edit the VM properties prior to boot. Note: Thick Provision Lazy Zeroed is recommended for performance Edit the Virtual Hardware options and set the hardware settings as follows: Note: A 600 GB disk formatted to Thick Provision Lazy Zeroed is recommended for performance Switch to the VM Options tab and expand Advanced Scroll down and click Edit Configuration Click Add parameter and add the following: guestinfo.userdata.encoding = base64 Create a local cloud-config.yml file to set the administrative username and password: Be sure to change the admin password and make a note of it. Then you need to base64 encode the file. Return to the VMware Configuration Parameters screen and Add another parameter named “guestinfo.userdata” and paste the base64 encoded text in the Value. Click OK when done. After saving the VM settings, you are ready to power on your VM for the first time! Note: Refer to the F5 Insight on VMware Deployment Guide for further details on this procedure. Post Boot VM Settings Open the VM Console and login to F5 Insight with the credentials specified in the cloud-config.yml file Configure the F5 Insight network settings using the following commands: Example: After hitting Enter, you will see the following: If no changes are needed, enter “y” to confirm. The output should look like the following: Note: Refer to the F5 Insight User Guide for further details on this procedure. Accessing the User Interface The initial configuration is complete and you can now log into the UI. You will see the Welcome screen. Click Next. Paste the text of the JWT Token and click Validate. If the license is activated, click Next. Enable the LLM Provider. Select your LLM Provider, Anthropic in this example. Enter your API Token/Key and the Enterprise API URL. Note that I am skipping TLS verification. Click Test Connection. Click Next if the test is successful On the next screen, select your preferred Setup Method. I’m using Start Fresh. Click Add Device Enter the Endpoint, Username and Password You can optionally configure a Certificate Authority and Data Center Select the Modules that are active and you want to monitor. Click Add Device. Click Next The configuration is complete. You can view the Home Page or the Device Settings. The Home Page should look like this: Conclusion F5 Insight for ADSP offers customizable visualizations and dashboards to help teams surface actionable metrics and KPIs tailored to your organization. It provides access to useful telemetry data for a deeper understanding of your environment, application behaviors, and complex BIG-IP deployments, all centralized in a single location. Identification of root causes during outages/tickets. Solve issues and struggles with Day 2 analysis of your BIG-IP Fleet and the applications therein. Mitigates the problem of a lack of detailed visual information on your BIG-IP Fleet. Set a foundation for the utilization of open-source tools and their benefits. Related Content Introducing F5 Insight for ADSP F5 Insight for ADSP - A Closer Look F5 Insight for ADSP Documentation F5 Insight Product Page F5 Insight Release Blog
HTTP Monitor cURL Basic POST
Problem this snippet solves: External HTTP monitor script that sends a POST request to the pool member to which it is applied, marking it up if the expected response is received. URI, POST data, and response string are user-configurable. cURL by default uses HTTP/1.1 and, since no hostname is specified in the cURL command, inserts the IP address in the Host header. NOTE: Use external monitors only when a built-in monitor won't do the trick. This monitor is intended as an example of using cURL (which offers a large number of other useful options) to perform a POST. More basic HTTP monitors are much more efficiently configured using the built-in HTTP monitor template instead. UPDATE: The script below had a logic error in it where by it was using the NODE and PORT variables to create a PID file before the variables were defined. This meant that if your monitor took long enough to run the PID running monitor was killed before it finished and a new process ran in its place. This gave the appearence of the monitor not functioning correctly. I have corrected this below. How to use this snippet: Create a new file containing the code below in /usr/bin/monitors on the LTM filesystem. Permissions on the file must be 700 or better, giving root rwx access to the file. Create a monitor profile of type "External" with the following values: External Program: . . the name of the script file created in step 1 Variables: Name.......Value URI . . . . .the URI to which the POST will be sent (URI only, no hostname) DATA . . . . the POST data to be sent to the server RECV . . . . the expected response Adjust the interval and timeout as appropriate for your application Jan 3 00:00:00 local/bigip err logger: EAV exceeded runtime needed to kill 10.0.0.10:80 If the interval and timeout is smaller then the execution time of the script, the monitor marks the element down and logs a message in /var/log/ltm. This is a false negative. To fix this, please increase the interval and timeout accordingly. Code : #!/bin/sh # # (c) Copyright 1996-2007 F5 Networks, Inc. # # This software is confidential and may contain trade secrets that are the # property of F5 Networks, Inc. No part of the software may be disclosed # to other parties without the express written consent of F5 Networks, Inc. # It is against the law to copy the software. No part of the software may # be reproduced, transmitted, or distributed in any form or by any means, # electronic or mechanical, including photocopying, recording, or information # storage and retrieval systems, for any purpose without the express written # permission of F5 Networks, Inc. Our services are only available for legal # users of the program, for instance in the event that we extend our services # by offering the updating of files via the Internet. # # @(#) $Id: http_monitor_cURL+POST,v 1.0 2007/06/28 16:36:11 deb Exp $ # (based on sample_monitor,v 1.3 2005/02/04 18:47:17 saxon) # # # these arguments supplied automatically for all external monitors: # $1 = IP (nnn.nnn.nnn.nnn notation) # $2 = port (decimal, host byte order) # # additional command line arguments ($3 and higher) may be specified in the monitor template # This example does not expect any additional command line arguments # # Name/Value pairs may also be specified in the monitor template # This example expects the following Name/Value pairs: # URI = the URI to which the POST will be sent # DATA = the POST data to send to the server # RECV = the expected response (not case sensitive) # # remove IPv6/IPv4 compatibility prefix (LTM passes addresses in IPv6 format) NODE=`echo ${1} | sed 's/::ffff://'` PORT=${2} PIDFILE="/var/run/`basename ${0}`.${NODE}_${PORT}.pid" # kill of the last instance of this monitor if hung and log current pid if [ -f $PIDFILE ] then echo "EAV exceeded runtime needed to kill ${IP}:${PORT}" | logger -p local0.error kill -9 `cat $PIDFILE` > /dev/null 2>&1 fi echo "$$" > $PIDFILE # send request & check for expected response curl -fNs http://${NODE}:${PORT}${URI} -d "${DATA}" | grep -i "${RECV}" 2>&1 > /dev/null # mark node UP if expected response was received if [ $? -eq 0 ] then # Remove the PID file rm -f $PIDFILE echo "UP" else # Remove the PID file rm -f $PIDFILE fi exit
F5 mssql health monitor failing
I am having an issue when configuring an mssql health monitor. I see a successful connection in the database, but the advance debug logs are showing receive string not matching. 2025-12-03 09:50:40,269-0500 [id750_DBPinger-1686] - DB connect succeeded. 2025-12-03 09:50:40,269-0500 [id750_DBPinger-1686] - Query message: SELECT @@SERVERNAME AS ServerName, SERVERPROPERTY('ServerName') AS InstanceName, SERVERPROPERTY('ProductVersion') AS ProductVersion 2025-12-03 09:50:40,270-0500 [id750_DBPinger-1686] - Send Query success 2025-12-03 09:50:40,274-0500 [id750_DBPinger-1686] - Response from server: ServerName: 'icscwsql1' , InstanceName: 'icscwsql1' , ProductVersion: '16.0.4215.2' 2025-12-03 09:50:40,277-0500 [id750_DBPinger-1686] - Checking for recv string: ServerName 2025-12-03 09:50:40,279-0500 [id750_DBPinger-1686] - Analyze Response failure Here is the configuration of the health monitor: ltm monitor mssql icscwsql.mssql.mon { debug no defaults-from mssql interval 30 password xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx recv ServerName: recv-column 1 recv-row 1 send "SELECT @@SERVERNAME AS ServerName, SERVERPROPERTY('ServerName') AS InstanceName, SERVERPROPERTY('ProductVersion') AS ProductVersion" time-until-up 0 timeout 91 username xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
using '--resolve' in the pool monitor health check
Hello, I am checking if it's possible to add the option '--resolve' in the health check monitor and avoid using a custom monitor (which consumes too much memory). For example: curl -kvs https://some_site_in_the_internet.com/ready --resolve some_site_in_the_internet.com:443:196.196.12.12 I know you can use curl -kvs https://196.196.12.12/ready --header "host: some_site_in_the_internet.com" But the path to the servers has some TLS requirements that' does not work. Any ideas are welcome Thanks
Big-IP sending Health Check to not-used Node-IP
Hello everyone, my customer recently noticed while checking traffic on his firewall that healt checks are send from the Big-IPs internal self-ip to an IP that fits into the address range of the nodes in use on the f5. This node ip is not known to the customer, and by searching the node table or looking in /var/log/ltm we were unable to find this ip-address. So either this node was used a while ago and the node object was deleted or the Big-IP send tries talking to this ip via 443 for some other reason. Pings & curls send from the Big-IP fail. Has anyone noticed something like this before? Or is there another way to see where health checks are sent? Thanks and regardsStandby Has Fewer Online VIPs Than Active – Requires Manual Monitor Reset
Hello F5 community, I’ll preface this by saying that networking has been verified as fully routable between the Active and Standby units. Both devices can ping and SSH to each other’s Self-IPs, and rebooting the Standby did not resolve the issue. Issue: Discrepancy in Online VIPs Between Active & Standby Despite being In-Sync, the Active and Standby units show a different number of Online VIPs. If I randomly select one or two VIPs that should be online, remove their monitors, and then re-add them—BOOM, the VIP comes online. The VIPs in question were both HTTPS (443). Side Note: Frequent TCP Monitor Failures In my environment, I also frequently see generic ‘TCP’ monitors failing, leading to outages. While I understand that TCP monitoring alone isn’t ideal, my hands are tied as all changes must go through upper management for approval. Has anyone encountered a similar issue where VIPs don’t come online until the monitor is manually reset? Any insights into potential root causes or troubleshooting steps would be greatly appreciated! Thanks in advance.
