Load-balancer connectors

This page covers the load-balancer connectors other than F5 (which has its own page): Citrix NetScaler / ADC, HAProxy, nginx, Kemp LoadMaster, A10 Thunder ADC,…

This page covers the load-balancer connectors other than F5 (which has its own page): Citrix NetScaler / ADC, HAProxy, nginx, Kemp LoadMaster, A10 Thunder ADC, and Radware Alteon. Load balancers are where most legacy SOAP traffic actually flows, so they are the primary discovery tier.

Each connector has up to two sides — discovery (a read-only poll of the vendor's management API where one exists) and traffic ingest (the vendor's traffic log feed). The exact mechanism differs per vendor because each platform exposes something different; the connector uses whatever that platform actually offers.

A note on vendor names. This page names the load-balancer products SOAP-2-REST integrates with. That is interoperability information, not a comparison. Each capability below reflects what is implemented in the product.

At a glance

| Connector | Discovery | Traffic ingest | Client-IP injection | |---|---|---|---| | Citrix NetScaler / ADC | NITRO REST API | Syslog | Rewrite policy | | HAProxy | Data Plane API (Enterprise) / stats socket (OSS) | Access-log feed (syslog transport) | http-request set-header | | nginx | Management API (Plus) / config parsing (OSS) | access_log feed (syslog transport) | proxy_set_header | | Kemp LoadMaster | REST API | Syslog access logs | Content rule (add-header) | | A10 Thunder ADC | aXAPI REST API | Syslog | aFleX (iRule-compatible) | | Radware Alteon | Vision REST API | Syslog | AppShape++ script |

For body-level capture, see What is captured below.

Citrix NetScaler / ADC

Discovery — the NITRO REST API enumerates load-balancing virtual servers (lbvserver), backend services (service), and their bindings, returning names, IPs, ports, and protocols. A read-only API user is sufficient.
Ingest — NetScaler forwards syslog to the relay; the connector parses both the RFC 3164 free-form HTTPREQUEST lines and the RFC 5424 structured form (modern firmware).

Client-IP injection — a rewrite policy that inserts the source IP into a client-IP header:

add rewrite action act_inject_client_ip INSERT_HTTP_HEADER "X-Client-IP" "CLIENT.IP.SRC"
add rewrite policy pol_inject_client_ip TRUE act_inject_client_ip
bind lb vserver `<vserver-name>` -policyName pol_inject_client_ip -type REQUEST

CLIENT.IP.SRC is the TCP-level source IP (the NetScaler equivalent of F5's [IP::client_addr]).

HAProxy

Discovery — HAProxy Enterprise exposes a Data Plane API (REST) that returns the configured frontends and backends as JSON. Open-source HAProxy has no management REST API; the platform discovers from the stats socket instead.
Ingest — HAProxy's access log (the well-known httplog format, or a custom log-format string) is forwarded over syslog transport to the relay and parsed into the canonical shape. HAProxy 2.7+ structured-data syslog is also supported.
Client-IP injection — a native directive, no scripting required:
```
frontend my-soap-frontend
    http-request set-header X-Client-IP %[src]
```
%[src] is the TCP-level source IP.

nginx

Discovery — nginx Plus exposes a management/stats REST API that lists upstream groups and server zones. Open-source nginx has no management REST API; the platform discovers by parsing the nginx configuration (server blocks define front-ends, upstream blocks define backend pools).
Ingest — nginx feeds traffic via its access_log, configured with a SOAP-relevant log_format and emitted over syslog transport to the relay. (nginx does not use a separate syslog event feed — the traffic signal is the access log; a JSON-escaped log_format is recommended.)
Client-IP injection — a native directive:
```
proxy_set_header X-Client-IP $remote_addr;
```
$remote_addr is the TCP-level source IP (use $proxy_protocol_addr in PROXY-protocol environments).

Kemp LoadMaster

Discovery — LoadMaster exposes a RESTful API that lists virtual services (listvs / showvs) with their IPs, ports, protocols, names, and real-server pools. A read-only API user is sufficient.
Ingest — LoadMaster forwards access logs over syslog to the relay. The extended access-log template (enabled in the WUI) carries client IP, virtual service, real server, URI, status, and latency.
Client-IP injection — a content rule with an add-header action attached to the virtual service injects the client IP (X-Client-IP).

A10 Thunder ADC

Discovery — the aXAPI REST API enumerates virtual servers (slb/virtual-server), backend servers (slb/server), and service groups (slb/service-group). Authentication is token-based.
Ingest — A10 ACOS forwards syslog to the relay; an HTTP-policy template with a custom access-log format produces the L7 transaction lines the connector parses.
Client-IP injection — aFleX scripting is intentionally TCL/iRule-compatible, so the F5 iRule ports across nearly verbatim:
```
when HTTP_REQUEST {
    HTTP::header remove "X-Client-IP"
    HTTP::header insert "X-Client-IP" [IP::client_addr]
}
```

Radware Alteon

Discovery — the Alteon Vision REST API enumerates virtual servers and real servers with their IPs, ports, and state. A read-only API user is sufficient.
Ingest — Alteon forwards syslog to the relay; the connector parses the Apache Combined Log Format web-access log, the Alteon custom log template, and key=value HTTP log forms.
Client-IP injection — AppShape++ scripts (Alteon's request/response scripting engine) add the client-IP header, analogous to F5 iRules.

What is captured

For the load balancers above, the baseline ingest tier captures the transaction metadata — front-end URI, back-end endpoint, virtual-server names, client IP, status, method, and latency — which is everything discovery, dashboards, and SLO reports need.

Request/response body capture is not native to most load balancers' standard logging. Capturing bodies requires the vendor's scripting layer at the edge (for example, HAProxy Lua, nginx njs, A10 aFleX, or Radware AppShape++) to POST the full transaction. In the standard product the load-balancer connectors are URI-level; body-level capture for load balancers is a higher-fidelity option layered on through scripting. (F5, with the relay path, captures bodies and headers — see the F5 page.)

Client-IP attribution and fallback

Across every load-balancer connector, the platform resolves the consumer from the forwarded-header chain (X-Client-IP, then X-Forwarded-For, then Forwarded) and takes the first candidate that is not the load balancer's own hop. If no client-IP header is injected, attribution falls back to the load balancer's own address — the transaction is still ingested and discovered, only per-consumer fidelity degrades. The per-vendor injection snippets above restore accurate attribution. See Consumer attribution.

Scope

Each connector targets mainstream, current-generation firmware over HTTP/HTTPS (for example, NITRO-capable NetScaler 11.x+, HAProxy 2.0+, nginx 1.14+, Kemp LMOS with the REST API, A10 ACOS with aXAPI v3, and Alteon firmware with the Vision REST API). Older firmware and bespoke log formats are handled as targeted engagements — see Scope — the mainstream 80%. Some vendors' exact log-token names are operator-configurable and finalized against the first customer running that platform.

All Specaria SOAP to REST docs

Loading…