iHealth Upgrade Advisor: Making upgrades a little easier
Whether it is upgrading the firmware on a switch, the OS on a server, an important business application or the software on a BIG-IP, performing upgrades is something that makes almost all IT Admins and Network Engineers nervous. We’ve learned from (sometimes painful) experience that things don’t always go as planned. Good preparation greatly increases the likelihood that an upgrade will be successful, which is why F5 has created the iHealth Upgrade Advisor. Its goal is to provide an additional service from F5 that will complement your existing upgrade preparations, increasing the predictability of the upgrade while reducing your upgrade time. The iHealth Upgrade Advisor service provides a way for users to gain insight into potential issues with a BIG-IP upgrade before they attempt the upgrade. It provides guidance that is specific to a BIG-IP based on its configuration, the version of software it is currently running and the version you are planning to upgrade to. When an issue can be avoided by making a configuration change prior to upgrading, the Upgrade Advisor will tell you exactly what to change. For some issues, it will list the corrective actions to take after the upgrade. Demo Video This short video demonstrating the Upgrade Advisor shows you how to use it and some examples of the guidance it provides. Accessing the Upgrade Advisor The next time you are preparing to upgrade a BIG-IP, login to ihealth.f5.com, upload a .qkview file from that BIG-IP and then view the qkview after iHealth has analyzed it. The Upgrade Advisor can be accessed by clicking on its tab in the left-hand menu. Simply select the version of BIG-IP you are planning to upgrade to in the advisor and review the results. Here is a screenshot of the Upgrade Advisor: Give it a Try Try out the F5 upgrade Advisor today and let us know what you think using the feedback option (circled in red on the right side of the screenshot above).
Health check via URL
Hi, Wanted to setup a load balancer which can check the health of a node based on the URL (not by pinging just host and port). For example: The LB should check the following URLs and if the HTTP response is 200 (OK) and the response text contains keyword as “PASS” then that particular node is good otherwise don’t send any request to that node. https://mysite.com:22301/ws/healthmonitor https://mysiteb:22301/ws/healthmonitor
monitor to turn off pool member if http response is 501 or 502 0r 503
Hi Friends, Following is the path to be used in GET field "/monitoring/health.svc" The monitor is expected to turn server offline only when http response code is 501/502/503. Please help me configuring the send and receive string for the monitor in standard format. I am running 10.4 version LTM Thanks
OpenText EIM Redirect Issue
I am trying to setup a VIP for a OpenText EIM solution. I have a standard vip for port 443. However, the server keeps doing a redirect for another FDQN. So in this case, I am putting in https://content.companya.com and the browser is getting redirected to https://servera.host.local (the domain name for the server itself). If I go to the FQDN of the server itself (servera.host.local), it works fine. According to OpenText, this is an issue with the OpenText Directory Services (OTDS) as the this is the expected behaviour as during the installation of OTDS, it is required that we have to use the FQDN and use certificates that have been created against that hostname of the server. A reverse proxy must be used to translate requests between different top-level domains. So what type of iRule do I need to setup to make the translation work?Enterprise Manager VS Big IQ
I used to be under the assumption that BigIQ was replacing Enterprise Manager, but I am not sure that is the case. What is the the real differences between the products because they seem to have overlapping feature sets and I am not sure why one customer would pick one appliance over the other. I see that there are different options (or maybe modules) for BigIQ, but I have no idea what its purpose is in relation the EM.
iHealth API Part 2 - An Introduction to REST
In the last article, we got some ideas of the kinds of data that iHealth can provide by exploring the wealth of information through a standard web UI. This is a quick easy way to get answers about a couple of your F5 machines, or to do a one-off check of something, or if you are looking for a particular problem, or working with F5 Support to resolve an issue or answer a question. If you have a couple machines, or maybe many many more, however, and you want to do something periodically, like, say, check for new Diagnostics results (remember, we generally update them once a week), then you'll quickly find that opening your browser, logging in, uploading the QKViews, and then reading through the Diagnostics is not necessarily the most efficient method. It can become annoying and tedious for even one or two machines. Since iHealth is a web application, it made the most sense to make the iHealth API a web API as well. There is a dogs breakfast of different types of web APIs, but one of the most prevalent conceptual frameworks in use today is called Representational State Transfer, or REST. The wikipedia entry on Roy Fielding has links to his dissertation if you want to up your street cred significantly. REST provides a nice clean way of retrieving, modifying and deleting things using HTTP in all (well most all) of it's glory. It's hidden from most users (as it should be), and unless you are a web developer, or someone who is dealing with web traffic a lot, there isn't any reason you would need to know this, but the HTTP protocol specifies a number of different ways to ask the server to do something. Now that you will be working with an HTTP API, you're going to have to know a little more about HTTP. Generally the two verbs that a developer will be familiar with is GET and POST. But HTTP has many other verbs, and we'll use most of them in this article series (GET, POST, PUT, and DELETE for now, although there are others), REST gives us a framework for using those verbs to make changes, or view the properties of things on the web. They generally do what they sound like: GET - get information (generally read-only) POST - create a new object (or modify an existing object repeatedly) PUT - modify an object idempotently so that multiple PUTs will result in the same state DELETE - delete an object This is all very abstract, so let's come up with an extremely contrived example: imagine a barn full of goats ( yes, my first job was as a farmhand ). Let's say that you had a robot that you wanted to perform various tasks relating to this barn full of goats. Maybe the first one would be a survey of all the goats in the barn. If the robot spoke REST, then you might send a text message to your robot that looked like this: GET /barn/1/goats Because the robot knows that in REST, that means that you want to know about all the goats in barn 1, your robot would trundle off (or fly, or crawl) to barn 1, and might come back with this data: goat 1: name: Dopey goat 2: name: Speedy Maybe then you wanted to know more about Speedy, so you'd text your robot this: GET /barn/1/goats/2 and your robot would gather up some more information about goat 2: goat 2: name : Speedy eats : Himalayan Blackberry hates : Dopey Okay, so what the hell do goats and barns have to do with iHealth? Well, if we substitute in QKViews for goats, we can start to see some information about our data in the same way that we were able to examine our herds of goats: GET /qkview-analyzer/api/qkviews Will show us a list of the qkviews that we have in our account: This is a sample, and there is a special QKView that isn't show in the listing, but that you should always have in your account, a QKView with an ID of 0. It's a sample QKView that we allow everyone access to in order to see how iHealth works with requireing you to upload anything of your own. So let's pick QKView 0 and load it up. We'll see some details about that QKView: GET /qkview-analyzer/api/qkviews/0 Feel free to poke around. At the bottom of the listing are some "discovery" URLs. Load them up in your browser; there is a ton to explore here, and you can get an idea of the kind of data you can work with without writing a single line of code. Code will come later, as you'll need it for things like adding to your QKView collections, and modifying existing QKView entries, which are tricky to do with just a browser.iHealth API Part 1 - An Introduction to iHealth
Welcome to the inaugural iHealth post (for the http nerds, yes, pun intended). This series will be an exploration and explanation of the iHealth Application Programming Interface (API), and how making the iHealth API a part of your datacenter ecosystem can bring you good fortune, reduce your downtime, help prevent emergency RMAs, and cook your emergency bacon. But before we get to the emergency bacon (spoiler: there is no emergency bacon), let's start with the basic building blocks and concepts that we'll be talking about, just so there is no regrettable misunderstandings later in the series. Let's start with the foundation of this series: iHealth. iHealth If you've spent much time with F5 gear (actual hardware or virtual editions it doesn't matter) in the last couple years, or had any interactions with the F5 support teams, you may have at least heard of iHealth. iHealth is a free, F5 hosted web application that provides deep inspection of BIG-IP, BIG-IQ, and Enterprise Manager system data. We want to help you monitor your systems, tune up your configurations, provide a distant early warning system, and help you keep on top of any issues or opportunities we can. The most important part of that deep inspection that iHealth provides are our Diagnostics. As of this writing, we've got over 900 diagnostic tests that are run against all that system data. Each diagnostic is specifically targeted to look for a very specific issue, or inform you about a particular configuration optimization, or warn you about a particular security vulnerability. We don't just warn you, or offer generic advice however. We also provide the specific items in your configuration that might be susceptible, or in need of a little love, and we provide extensive [Ask F5] solution articles to back up each Diagnostic to ensure that you have all the context, details, and knowledge to get things fixed up before they become a bigger problem. The F5 iHealth team releases new and updated Diagnostics every week, so the list of Diagnostics that are 'hits' (identify your gear as exhibiting the symptoms the diagnostic is looking for), may change from week to week. We get ideas for Diagnostics from all over F5, as well as from our customers (that's you). Got an idea of something you want iHealth to check for on all your machines? Jump into iHealth and hit the feedback button, and describe what you want to do. That feedback button creates a ticket that the F5 iHealth team will follow up on. The far-seeing among us might postulate that doing weekly checks of our gear might be a great way to keep our ship running tight with very little cost. That would be an astute observation indeed, and this article series will address that observation in some detail in the weeks to follow. iHealth has lots of other uses as well, but the Diagnostics are the crown jewel in the iHealth tiara. You can start using this tool, if you haven't already, by visiting https://ihealth.f5.com/. You might have to create a (free) account, but that's the only obstacle. We'll be depending on your access to your iHealth account for the duration of this series, so if you don't have an account, go sign up for one now. After you get your account, you can access https://ihealth.f5.com/ and you'll notice there is a sample QKView in your account already. We provision a sample in there to give you something to work with immediately, and, conveniently, it will give us a data set to use for the rest of this series. The UI is fairly extensive, and gives you lots of information about your machine, including things like End of Life notices for your hardware and software, if you've got a support contract, we let you know when that contract ends, as well as displaying lots of information about your F5 gear. Customizable performance graphs? Yup. Command-line output at the moment the QKView was taken? Yup. Diagnostics? Yup, we already covered that. Configuration information? Yup. So if all that data is already available, why am I bothering with an API? Well, the rest of the series should help illuminate the answer to that question, and you'll end up writing a basic application to make use of all the data iHealth provides, which should give you plenty of ideas about how iHealth in all it's forms can be an incredibly helpful tool.
Upload QKviews to Internet via PROXY
Hello, I am trying to use the new function in V13 on F5 to upload the qkviews to ihealth. As we use a proxy for internet access I set it up with the: tmsh modify /sys db proxy.host value 10.x.xx.xxx modify /sys db proxy.port value 80 modify /sys db proxy.protocol value http We do not use authentication from this host. So user & password were not set. We tried access with a curl on the CLI to www.google.com and it worked fine. We get the following errors on the GUI qkview: Your device may not have access to the Internet. Verify that you can access api.f5.com and ihealth-api.f5.com and try your upload again. I do not see any traffic on a capture of this. Am i mssing something ? Thx in advance, Luc
