top of page

Automating Citrix ADC/NetScaler Virtual Server Monitoring End-To-End with NITRO API

Automation is a great way to manage repeatable tasks. Scripts can do repetitive tasks quickly and without error. This can lead to quicker response times and shorter outage windows. Automation also frees up your team to continually innovate.

This is especially valuable if you manage mission critical applications. Applications that receive high traffic levels each day will need some sort of load balancing between servers. Citrix ADC/NetScaler is one option for load balancing the traffic between multiple backend servers. It does this by creating one “Virtual IP Address” that consumers use to access the site. From the virtual IP Address, the NetScaler uses various types of logic to balance all backend servers, so the workload is equal. This allows for you to “build out” backend services, rather than “build up”.

With adding a load balancer of sorts, you increase complexity within the environment. You have another layer to troubleshoot when it comes to outages. With the environment being more complex, the outages can waste hours of time troubleshooting to find the root cause. Valuable time can be spent just identifying which ADC, Load Balanced, or Content Switched vServer is responsible for the specific outage. Many times, the ADC is not the cause, it is often a change or failure on the applications/servers bound to the service groups.

After watching this occur repeatedly with many of our customers, we decided to find a more efficient way to identify possible root causes.

Built into each ADC/NetScaler is a REST API, called NITRO API. This can be found on the Documentation tab after logging in. On the top you will find materials on how to use the NITRO API, as well as a client to test and build requests. The NITRO API allows for us to use automation tools to run checks or set values on the ADC/NetScaler via a script, rather than logging into the CLI or GUI.

Throughout this blog, we will discuss how we leveraged the Citrix ADC NITRO API to enumerate the ADC resources, namely:

  • LB vServer Names

  • Service Groups Names

  • Backend Servers

  • Backend Server States

  • Monitors

  • HTTP Requests for testing with a 200 “OK” response expected

We use this information and test the services end-to-end. This gives us an accurate view of what is happening in the environment for every object. This allows us to identify precisely where the issue or error exists.

Development Process Overview

The first step I took to build out the automated workflow was writing some simple pseudocode. We need to identify the steps required to complete our process before we jump in and start writing our script. The following steps were used to gather all the information needed to check monitor and backend server status:

  • Understand Business Case

- The purpose of creating a script to check vServer status is to reduce the time to resolve and troubleshoot issues

- The output will provide detailed information about resource to all stakeholders during an outage and can effectively centralize communication

  • Build Use-Case

- Connect

- Login

- Get list of all Load Balanced (LB) vServers

- For each LB vServer, enumerate the Service Group

- For each Service Group, enumerate the bound servers

-Get the backend server IP, Port, Name, and Current State

- For each Service Group, enumerate the bound LB Monitors

- Get any custom HTTP Request strings

- Test each backend server to ensure the Monitor(s) bound are functioning as expected

  • Once the workflow/pseudocode was designed, I needed to build and configure the lab to prototype the solution for testing

  • This required exploring the Citrix NITRO API, a tool that comes built-in to any NetScaler. It is used by third-party management tools to interface with your Citrix ADC/NetScalers. The NITRO API has many capabilities and is well documented. Checking Server states is only scratching the surface of what is possible.

  • During the exploration I used the built-in NITRO API Client to complete testing.

  • Now, I was ready to build the script in Python.

  • Once built, I needed to test the script

  • Finally, document and post the script

Lab Overview

This script was built and tested in my lab environment. The lab consists of a few simple components as shown in the diagram below:

  • Workstation: Ubuntu 20.04.1 LTS

  • Python 3.8

    • Libraries


- This will be used to load the json responses to parse for the needed data


- Form the GET requests sent to the ADC


- Formatting


- Parsing through arrays of data received from ADC


- Bypass any ssl certificate errors when connecting to ADC or backend servers


- Open, write, and close the csv file


- Hide password input when connecting to the ADC

  • NetScaler (Hosted on VMWare ESXi)

- VM: NetScaler 12.1 Build

  • VM (Hosted on VMWare ESXi)

- JSONPlaceHolder docker image (3x)

The table below gives you a general idea of what the minimal configuration should be on the NetScaler. This can be used to set up your own lab environment. The configuration includes the following:

  • Enabling the Load Balancing Feature

  • Setting the hostname and Subnet IP Address (SNIP)

  • Creating some backend servers

  • Creating (3) load balancing vServers

  • Creating (3) Service Groups

  • Creating a monitor

  • Binding the monitors, backend servers, and Service Groups to the LB vServers

NetScaler Configuration (Base Config)

set   ns config -IPAddress -netmask
enable ns feature WL LB CH
set ns hostName NS
add ns ip   -vServer DISABLED
add server server01
add server server02
add server server03
add serviceGroup SVG-TEST1 HTTP   -maxClient 0 -maxReq 0 -cip ENABLED X-Forwarded-For -usip NO -useproxyport   YES -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP YES
add serviceGroup SVG-TEST2 HTTP   -maxClient 0 -maxReq 0 -cip ENABLED X-Forwarded-For -usip NO -useproxyport   YES -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP YES
add serviceGroup SVG-TEST3 HTTP   -maxClient 0 -maxReq 0 -cip ENABLED X-Forwarded-For -usip NO -useproxyport   YES -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP YES
add lb vserver VS-LB-TEST1 HTTP 80 -persistenceType NONE -cltTimeout 180
add lb vserver VS-LB-TEST2 HTTP 80 -persistenceType NONE -cltTimeout 180
add lb vserver VS-LB-TEST3 HTTP 80 -persistenceType NONE -cltTimeout 180
bind lb vserver VS-LB-TEST1 SVG-TEST1
bind lb vserver VS-LB-TEST2 SVG-TEST2
bind lb vserver VS-LB-TEST3 SVG-TEST3
add dns nameServer
add dns nameServer
add lb monitor MON-TEST1 HTTP -respCode   200 -httpRequest "GET /posts"
bind serviceGroup SVG-TEST1 server02 80
bind serviceGroup SVG-TEST1 server03 80
bind serviceGroup SVG-TEST1 server01 80
bind serviceGroup SVG-TEST1   -monitorName MON-TEST1
bind serviceGroup SVG-TEST2 server02 80
bind serviceGroup SVG-TEST2 server03 80
bind serviceGroup SVG-TEST2 server01 80

Exploring the Citrix NTIRO API with Citrix Developer Docs

Before starting the script, I wanted to get an idea of what is possible with the NITRO API. Citrix’s Developer Docs are a great resource for documentation of each of the commands. The docs layout examples that outline the request verbs (GET, PUT, DELETE, etc…), syntax, and payloads.

NOTE: There were some examples on GitHub as well, but they seemed a bit too contrived for my needs.

The Developer Docs you will use might differ slightly for your environment. The link referenced above is for 12.0, which is the NetScaler build in my lab.

Figure 1: Citrix Developer Docs

The documentation provides detailed explanations for each endpoint and parameter that can be sent, along with their payloads. I was able to quickly navigate through the reference guide to find my starting point for the script, enumerating all LB vServers. The URL required to complete this, can be found in Figure 2 below.

Figure 2 Load Balanced vServers get (all)

Continuing with the psudocode, we need to figure out how to find the Service Group bindings for each of the LB vServers listed above. This can be accomplished by using the ”/nitro/v1/config/lbvserver_servicegroup_binding” URL. (Figure 3)

Figure 3 Load Balancer Service Group Binding

The process continues until we have all the following objects:

  • Load Balanced vServer

  • Service Group Binding

  • Service Group Members Servers

  • Service Group Monitor bindings

Figure 4 Service Group Member Bindings

Testing the NITRO API with NITRO Client

As you may have noticed, all the commands we need are GET’s. I find it easiest to use the native NITRO Client for this particular application. I would use Postman for testing POST requests, but for this particular case it is not necessary.

Figure 5 NITRO Client

After getting to the NITRO Client, I began by checking the output of each of the commands I identified earlier. I begin with displaying all LB vServers and looking for the fields that are interesting. Some interesting fields include “name” and “curstate”. The output, as shown in Figure 6 can be a little cumbersome. To make viewing the info slightly easier, I find it best to open a new tab on my browser and copying the URL, seen in Figure 7.

Figure 6 NITRO Client LB vServer output
Figure 7 New Browser Tab Output <NetScaler IP Address>/nitro/v1/config/lbvserver

The process will continue with the following endpoints to identify all the fields we will need to complete and output to a .csv file. See a list of all endpoints we GET for use in the script below:

  • “/nitro/v1/config/lbvserver_servicegroup_binding/<LB vServer Name>”

  • “/nitro/v1/config/servicegroup_lbmonitor_binding/<Service Group Name>”

  • “/nitro/v1/config/servicegroup_servicegroupmember_binding/<Service Group Name>”

  • “/nitro/v1/config/lbmonitor/<monitor name>”

This should be all the data we need from the NetScaler to give us an effective method for enumerating resources. Next in the blog, we will discuss the script, as well as testing the backend servers.

Scripted Workflow Overview

At this point I have dissected and tested the NITRO API for my purposes. Now it is time to build the script, so I can automate the process. The process is simple and documented in the table below:

  • Connect

  • Login

  • Get list of all Load Balancers

  • Get Service Group bindings for each Load Balancer

  • Get Service Group Members for each Load Balancer

  • Get Monitors for each Service Group

  • Check state of backend servers according to LB Monitor “HTTP-ECV” GET requests

  • Send request to backend server to verify the service is up or down on the actual host

  • Write the output to .csv file. You can put the output anywhere you like especially if you plan to incorporate this into your CI/CD pipeline tool (i.e., Jenkins)

After I made it through getting all the data needed from the NetScaler, I needed to find a way to actually test the backend server state. With a combination of the HTTP ECV URL/Endpoint, the server IP Address, and Server Port, I was able to complete a simple test URI to send with a “requests.get” function. Depending on the response code received, we can determine if the backend server and endpoint are up and listening on the URI.

Once everything is tested, we output to a .csv file. This will allow the support and deployment teams to get a quick “birds eye view” of what services could be causing any issues and cut the time to resolve down. This approach minimizes the analysis and offending component from the equation and allows the correct support person to identify the root cause and resolve the issue.

If there is any interest, I may add the steps to incorporate this into Jenkins and JIRA. The goal would be to automate the testing during and CI/CD pipeline testing and send the output to JIRA and create an issue for the deployment team…

Once I verified all the positive result use cases were completed, I needed to account for Load Balancers that are not configured the way we expect. Some issues could be no backend servers are bound, a monitor is not bound, or there is not a specific http request required for the monitor. To resolve this issue, I implemented “IF ELSE” logic for each loop in the script. The table below includes the content of the script I created. This is a working prototype and can be easily modified to suit any other environment.

Citrix NetScaler NITRO API Backend Service Checks

import   json
import requests, sys,   collections
import urllib3
import csv
import getpass

#Get a list of LB vServers,   Service Group Bindings, Server Group members, 
#Service Group Member Ports,   Service Group Monitors, Service Group Monitor HTTP Requests, LB vServer   Status, Backend Server Status
#Get list of LB vServers
#Loop through each LB vServer to   get Service Group Binding
#Loop though each Service Group   to get Service Group Members and monitors
#Loop though each monitor to get   HTTP Request parameter
#Send request to backend server 
#Write output to .csv

#Disable SSL Warnings if cert is   untrusted

#User input server IP Address
NITRO_SERVER=input("Server   IP: ")

#User input username
NITRO_USER=input("Username:   ")

#User input password
except Exception as error:
 print ('ERROR',error)

#Open a .csv file and create a   new line 
with   open('monitor_status.csv','w', newline='') as f:
 writer = csv.writer(f)

 #write headings for each column
 writer.writerow(['vServer   Name','ServiceGroup Name', 'Server Name', 'Port', 'Monitor Name', 'HTTP   Request', 'LB VIP Status', 'Server Status', 'Backend Server State'])

 #send first request to NITRO API to get   list of Load Balancing vServser
 lbvs_response=requests.get("https://%s/nitro/v1/config/lbvserver"%(NITRO_SERVER),auth=(NITRO_USER,   NITRO_PWD),verify=False)
 #for each lbvserver in lbvs_data get the   name and current state
 for j in lbvs_data['lbvserver']:

 #send request to get Service Group   bindings for each Load Balancing vServer
 svg_response=requests.get("https://%s/nitro/v1/config/lbvserver_servicegroup_binding/%s"%(NITRO_SERVER,lbvs_name),auth=(NITRO_USER,   NITRO_PWD),verify=False)

 svg_data =   json.loads(svg_response.text)

 #if there is a Service Group binding,   get the monitor name and Service Group members
 if 'lbvserver_servicegroup_binding' in   svg_data:
 for k in   svg_data['lbvserver_servicegroup_binding']:

 svgmon_response=requests.get("https://%s/nitro/v1/config/servicegroup_lbmonitor_binding/%s"%(NITRO_SERVER,svg_grpname),auth=(NITRO_USER,   NITRO_PWD),verify=False)

 member_response=requests.get("https://%s/nitro/v1/config/servicegroup_servicegroupmember_binding/%s"%(NITRO_SERVER,svg_grpname),auth=(NITRO_USER,   NITRO_PWD),verify=False)

 #if there is a monitor bound, get   the port, backend server name, and backend server state
 if   'servicegroup_lbmonitor_binding' in svgmon_data:

 for l in   mr_data['servicegroup_servicegroupmember_binding']:


 #for each monitor, get   the monitor name 
 for m in   svgmon_data['servicegroup_lbmonitor_binding']:

 mon_response=requests.get("https://%s/nitro/v1/config/lbmonitor/%s"%(NITRO_SERVER,monname),auth=(NITRO_USER,   NITRO_PWD),verify=False)

 for n in   mon_data["lbmonitor"]:

  #if there is a http   request field
 if 'httprequest'   in mon_data["lbmonitor"][0]:
 httpreq=str.replace(httpreq,'GET ','')
 if( mon_sec   == 'NO'):
 #create   test uri 
 response   = requests.get(test_uri)
  if(response.status_code ==   200):
 backend = 'UP'
 backend = 'DOWN'
 response   = requests.get(test_uri)
 if(response.status_code == 200):
 backend = 'UP'
  backend = 'DOWN'
 #else assign   httpreq to none

 #write to   .csv file 



 for l in mr_data['servicegroup_servicegroupmember_binding']:



 port ='N/A'

This prototype script can be added to any job scheduler or automation engine (Jenkins), with some production ready refinements, to quickly check the entire NetScaler for service states on all load balancers.

Maybe later I will introduce some functionality for GSLB vServers or checking for only specific Load Balancers. For now, this is merely a prototype you can use to get up and running with quick “health checks” on your NetScaler. Seconds count when there is a Production outage.

Script/Solution Overview

If you plan on using this script you will want to make sure you have the following:

  • Install Python

  • Install and create a Python Virtual Environment

  • Clone the repository

  • Test Functions (IN A TESTING ENVIRONMENT, don’t be that guy/girl!)

Script Download/Source

Disclaimer: While this may go without saying, Do NOT test this in your production environment

You can access this script and supporting files at the following location. Simply “git clone” the repository and run it against your test environment.

Script Execution and Testing


NOTE: You will be prompted for <server IP> <username> <password>


bottom of page