As a great fan of the E2EVC events, I was given an early preview of all the cool new features in ControlUp Real-Time Console v7.1. And for those that know me and the work I’ve been doing these last couple of years it will be no surprise that I was thrilled to see the NetScaler monitoring option now integrated in the Console.
I’ve been testing the free NetScaler Monitor that was already released and already loved the intuitive interface that provides quick insights into the health of my NetScaler configuration. But having it integrated in my ControlUp Real-Time Console so that I can now monitor the health of the entire Citrix infrastructure is a very big plus in my view!
And I’m pretty sure you can imagine the happy grin on my face when I got the chance to be one of the early testers of the 7.1 version, and when I was asked to build additional Script Based Actions (SBAs) to make troubleshooting your NetScaler configurations easier. And even though I have had plenty of experience with PowerShell and NITRO (the RESTful API service of the NetScaler) I still needed to decide which useful metrics to retrieve first.
I am very proud to introduce the first batch of SBAs that will help you monitor your NetScaler health and aid in troubleshooting NetScaler configurations.
For this first batch I’ve looked at some of the common steps to check your NetScaler configuration and the statistical information that will help you during your root cause analysis.
You can simply download and install your SBAs from the Community SBAs repository and add them to your Organizational Actions.
One of the first actions in your root cause analysis is to check whether or not the NetScaler is correctly licensed. This SBA will check the license configuration on your NetScaler. When you have installed the SBA in your Organizational Actions, you can simply right click your NetScaler and run the SBA, just like you are used to do so for the Servers in the console.
The first thing you will notice is that each SBA is configured to automatically pass the NetScaler Management IP to the PowerShell script as the first parameter. But it will also automatically ask you to provide your NetScaler credentials as each REST API that is made must provide user credentials for authentication. And I did not want to assume that your Windows credentials would automatically authenticate you on the NetScaler too.
So I’ve build-in a Windows PowerShell credential request, which will state the management address of the NetScaler you are providing credentials for. This way if you selected multiple NetScalers to run the SBA for, you will know for which NetScaler you are providing credentials. As not all NetScalers might use the same user credentials.
After the credentials are provided and the script has successfully authenticated them, the metrics will be gathered.
In the above sample output you can see that the license type is determined first by the script.
The script can differentiate between a local license file, license server configuration or even the default Express license that is now included with the latest NetScaler releases. And will show additional information for each license type. With the local license file type, it will check if a license file can be found in the nsconfiglicense folder on the NetScaler and read detailed license information from each license file it finds.
This will show you what features are licenses and when the license file will expire.
The second sample output, shown above, shows the information when a license server type is configured for the NetScaler. The configured license server, as well as the grace status is shown to easily determine if the NetScaler can reach the license server or if the grace period for the license is active.
And as mentioned before, this SBA will also inform you if no license is configured and the default Express mode is active. As can be seen in the sample output below.
And as an added service, I’ve also created an SBA to delete any obsolete or expired license files if they might show up in the previous report. And to ensure it does not delete all license files in the nsconfig/license folder, it does require you to specify a license file name.
And provides you with a warning if no filename is specified.
One of the cool features in ControlUp is that it shows you how many days you are running your NetScaler with an unsaved running config.
And since there is no way to quickly save your running configuration, I build a quick SBA for it.
To make sure you take at least a moment to think about saving your running config, I’ve added a confirmation to the script …. Just to be sure ?
And after your confirmation, the command is sent to the NetScaler to save the running configuration:
And that red marker in your ControlUp console will disappear as well as the ‘days with unsaved config’ metric is reset back to 0.
I don’t know about you, but I have had those days where I was convinced I uploaded the right license file to my NetScaler only to discover, after more than a little time spent on troubleshooting, that I somehow got the MAC-address of the first NIC of my NetScaler appliance mixed up. I then find myself facing a mismatch between that MAC-address and the hostname in the license file, which brings me to an unlicensed NetScaler situation.
So after working on the script to retrieve details from a license file, I figured I might as well build an SBA to double-check the MAC-address and hostname information of my NetScaler to make sure the right license file is being used on the right NetScaler appliance.
As you can see in the below sample output, this SBA first checks the MAC address of the first NIC of the appliance, then it checks each license file in the /nsconfig/license to see of the hostname in the license file is a match to the MAC Address. And a warning is shown if the two do not match.
And then there are some basic SBAs available to gain some more insights into the NetScaler configuration, like viewing system settings, HA configurations, SSL statistics and service and servicegroup bindings that include monitor and probe information.
These SBAs can overwhelm you with a lot of information, so I made sure that the information can be trimmed down by providing an optional service(group) or vServer name.
This SBA gives you the bindings for one specified or all services configured on the NetScaler:
Including the last response of the monitor probe(s) attached to the service.
The same applies to the SBA to check the servicegroup bindings, though this does show a bit more details as the servicegroup member information is included in the output as well.
As ControlUp already shows a lot of metrics for each NetScaler, Service and ServiceGroup I tried to focus on some information that is not yet available in the console.
The first stats I created an SBA for is the system stats.
And yes there will be some overlap in the metrics shown in this SBA, as the console already gives you the current values for Packet CPU and Memory usage and traffic metrics too.
I just wanted to provide an overview, similar to the Statistics information screen you can view in the NetScaler management console. So this SBA will give you all the basics, including throughput metrics.
And some feature specific information:
For some more deep diving into the performance of our NetScaler and the SSL cards, there is also an SBA that focuses specifically on the SSL statistics:
Even splitting the information up into Frontend, Backend and Encryption specific metrics:
To help you quickly check if compromised protocols are used for the encryption of the SSL traffic, both the incoming and outgoing streams on the NetScaler.
Last but not least, I included an SBA for the High Availability configuration of the NetScaler.
That should also allow you to quickly identify the other NetScaler of the pair and whether or not HA heartbeat information is communicated correctly between both appliances.
This first batch of NetScaler SBAs does provide you with some basic metrics, statistical and configurational information to determine the health of your NetScaler configuration, but there still is so much more information to retrieve from these cool appliances.
So be on the lookout for even more NetScaler SBA releases in the near future as I’m currently working on some more scripts, like SBAs to:
To name just a few of the projects that are being tested as I write this blog.
And if you are in need of some additional SBAs to support your NetScaler monitoring, testing and troubleshooting activities, feel free to reach out and give me another excuse to geek out even more with PowerShell and NITRO to ensure that those NetScalers do not hold many secrets from us anymore ?