NetScaler ADC¶

Clarity Transform reads the load-balancing topology from a Citrix NetScaler ADC over the NITRO API: every load-balancing virtual server with its algorithm, state and bound services, resolving each backend to a discovered device.

Where to find it¶

Go to Discover → Integrations, then select the NetScaler ADC card. The card's category label is Network. The integration's page has the Endpoints and History tabs; Integrations describes the page, its grid and its row actions.

Why we do this¶

A migration wave that splits a load-balanced application produces an outage nobody predicted, because the servers looked unrelated.

What we collect¶

The appliance itself
Every load-balancing virtual server, with its virtual IP and port, algorithm and state
The services bound to each virtual server, with each backend address resolved to a discovered device

There is no pool object on a NetScaler

An lbvserver binds services directly rather than through a pool, so the algorithm and state are read from the virtual server itself. If you are comparing this integration with the F5 one, that is the structural difference between them.

What it adds¶

Load balancers hide a structural truth that network traffic alone obscures. Clients connect to a single published virtual service; behind it sits a set of servers that are functionally one application.

Without this, a load-balanced application looks like a set of unrelated servers that happen to receive similar traffic. With it, there is explicit evidence for grouping them from the outset. It also makes the published entry point visible, which matters for sequencing: the virtual service is usually what has to be cut over, rather than the individual members.

Stronger evidence than a firewall rule

A firewall rule states that traffic is permitted. A virtual server states that traffic is actually forwarded to a named set of backends. That is a structural dependency rather than a permission, so it is materially better evidence when working out which devices make up an application.

What is deliberately not inferred¶

Deliberate decisions, some of which would be easy to get wrong:

Backends are recorded whether or not they pass their monitor. A backend currently failing its monitor is still a configured dependency, because the appliance will forward to it the moment it passes again. Filtering on health would make the discovered topology depend on what happened to be running at the moment discovery ran.
No dependency is inferred between peers. Two servers behind the same virtual service are load-balanced peers; neither calls the other. Clarity records that both sit behind that service, which is a strong grouping signal, but does not invent a relationship between them.
The caller is not inferred. The appliance knows where it forwards traffic, not who sends it. That question is answered by observed traffic instead.
No traffic, connection or statistics data. Configuration only.
No certificates, keys or policy expressions.
No Gateway, AAA or content-switching configuration. Load balancing only.
Nothing is written.

What we require¶

The requirement below is read from rb-pautol-netscaler-connect.ps1 in the Runbooks repository, which is where it is maintained. If it is wrong, the runbook is what gets corrected and this page follows on the next build.

Account required: a system user bound to a command policy granting read. The binding matters as much as the account, and is the step most often missed.

Connectivity: HTTPS on TCP 443 from Clarity to the management address.

Without a command policy binding the account authenticates successfully and then every read returns an empty result with HTTP 200 - indistinguishable from an appliance with nothing configured on it. If discovery reports zero virtual servers from a NetScaler you know has plenty, check the binding before anything else.

On an appliance using admin partitions the account needs access to each partition whose virtual servers should be discovered.

Discovery reads load-balancing configuration only and never writes.

Verification before handover¶

Confirm the account authenticates. Log in over NITRO as the account.
Confirm a read returns data rather than an empty success. This is the check that matters. Read the lbvserver collection. Without a command policy binding the account authenticates and every read returns an empty result with HTTP 200, which is indistinguishable from an appliance with nothing configured on it.
Confirm every partition in scope is covered. On an appliance using admin partitions, repeat the read in each partition whose virtual servers should be discovered.

Configuring the endpoint¶

On the integration's Endpoints tab, select the add icon (Create New Integration Endpoints). The Create new entry form opens with these fields, in this order:

Field	Value
Name	A name for the endpoint
End Point	The management hostname or IP
Credential	The stored credential for the system user bound to a read command policy
Job Schedule	A five-field cron expression, for example `0 2 * * *` (daily). Virtual server membership changes more often than firewall policy
Enabled	Ticked. The box is unticked when the form opens

The help texts: End Point "FQDN or IP Address of management system for technology e.g. vCenter, Nutanix Prism"; Credential "Credentials can be configured under Settings/Identity and Access Management/Credentials."; Job Schedule "Cron schedule – Use five fields: 〈mm〉〈hh〉〈day-of-month〉〈month〉〈weekday〉".

The Credential list offers the credentials stored under Settings → Identity & Access Management → Credentials, so create the credential there first.

No field is marked as required. Technology is set by the card and is hidden in the form. Select Save to create the endpoint, or Cancel to close the form. The edit icon opens the same fields as Edit entry.

Removing the access¶

Unbind the command policy and delete the system user. Then, in Clarity, remove the endpoint (select its row on the Endpoints tab, then Remove selected) or clear its Enabled box, and remove the credential under Settings → Identity & Access Management → Credentials.

Troubleshooting¶

Symptom	Cause
Zero virtual servers on an appliance you know has plenty	The account has no command policy binding. Check the binding before anything else: this failure returns an empty success rather than an error, so it looks like an empty appliance.
Nothing discovered in a non-default partition	The account has no access to that admin partition.
Backends do not resolve to devices	Their addresses are not in the CMDB yet. Run the hypervisor and operating system integrations first.
A backend is recorded that is currently down	Deliberate. Backends are recorded whether or not they pass their monitor, because a backend failing its monitor is still a configured dependency.