Configure Splunk observability

Last published : Nov 02, 2026
The NetScaler® MCP Gateway can export analytics for every MCP transaction — target server, method, tool name, latency, and status — to Splunk. NetScaler emits these records through AppFlow and Web Insight and delivers them to a Splunk HTTP Event Collector (HEC) endpoint.
You enable this by adding an analytics configuration (NS_ANALYTICS_CONFIG) to the ConfigMap that the Gateway Controller watches, and by supplying the Splunk HEC token in a Kubernetes Secret. No per-route change is required — the controller binds the analytics profile to every MCP route automatically.

Prerequisites

  • NetScaler Kubernetes Gateway Controller deployed and an MCP Gateway with one or more MCP routes already serving traffic. See Configure MCP routing.
  • A running Splunk deployment with an HTTP Event Collector (HEC) enabled, and a HEC token.
  • The Splunk HEC endpoint reachable from the NetScaler that terminates the MCP traffic (see Platform support).

How analytics is exported

The Gateway Controller reads NS_ANALYTICS_CONFIG from the ConfigMap it was launched to watch and programs a Web Insight analytics profile on NetScaler with the MCP summary record set (mcpSummary) enabled. NetScaler batches the records and exports them to the Splunk HEC endpoint /services/collector on the AppFlow flush interval, which is approximately 60 seconds.
Note:
The controller auto-binds the analytics profile to every MCP route's load balancing virtual server. Do not add a per-route analytics annotation — a second profile against the same collector can conflict with the one the ConfigMap programs.

Platform support

Feature NetScaler CPX (in-cluster) NetScaler VPX / MPX / BLX (external)
MCP analytics to Splunk HEC Supported Supported
NetScaler CPX and NetScaler VPX/MPX/BLX both export MCP analytics to a Splunk HEC endpoint. Because an external appliance originates the HEC connection from its own SNIP/management network, point it at an external Splunk endpoint that is reachable from that network, and give the collector an IP that is not already configured as a backend server on the appliance — a reused address is rejected as already in use, so no records are delivered.

Configuration

Create the HEC token Secret

Create a Kubernetes Secret that holds the Splunk HEC token. The NS_ANALYTICS_CONFIG references this Secret by name, and the token value never appears in the ConfigMap. The data key must be authToken.
kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: mcp-hec-token
  namespace: default
type: Opaque
stringData:
  authToken: "<your-splunk-hec-token>"   # replace with your Splunk HEC token
EOF

Enable MCP analytics in the controller ConfigMap

Add the NS_ANALYTICS_CONFIG key to the ConfigMap the Gateway Controller watches. The configuration turns on Splunk export (enable: 'true'), points AppFlow at the Splunk HEC endpoint (endpoint, port, and analyticsEndpointUrl: /services/collector), references the HEC token Secret, and enables the MCP summary record set (mcpSummary: ENABLED) on the Web Insight profile.
Important:
This is the controller's own ConfigMap. Applying a ConfigMap replaces its data section wholesale, so merge NS_ANALYTICS_CONFIG into the existing ConfigMap rather than blind-applying a fresh one. NS_ANALYTICS_CONFIG is read only from the ConfigMap that the controller's --configmap argument names. Applied under any other name, it has no effect and raises no error.
Replace cic-configmap with the name of the ConfigMap your controller watches, and set the endpoint and port to your Splunk HEC listener.
kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: cic-configmap
  namespace: default
data:
  NS_ANALYTICS_CONFIG: |
    splunk:
      enable: 'true'
      servers:
        - name: mcp-splunk
          endpoint: '<your-splunk-hec-host>'
          port: 8088
          authToken:
            name: mcp-hec-token
          profiles:
            webinsight:
              httpURL: ENABLED
              httpHost: ENABLED
              dataFormatFile: splunk_format.txt
              mcpSummary: ENABLED
              analyticsEndpointUrl: "/services/collector"
              analyticsEndpointContentType: "application/json"
EOF
If you installed the Gateway Controller with the netscaler-kubernetes-gateway-controller or netscaler-cpx-with-gateway-controller Helm chart, the chart creates this ConfigMap. Set the same configuration in the Helm values instead of editing the ConfigMap:
gatewayController:
  analyticsConfig:
    required: true
    splunk:
      enable: true
      servers:
        - name: mcp-splunk
          endpoint: '<your-splunk-hec-host>'
          port: 8088
          authToken:
            name: mcp-hec-token
            namespace: default
          profiles:
            webinsight:
              httpURL: ENABLED
              httpHost: ENABLED
              dataFormatFile: splunk_format.txt
              mcpSummary: ENABLED
              analyticsEndpointUrl: "/services/collector"
              analyticsEndpointContentType: "application/json"
Warning:
dataFormatFile must name a file that exists on the appliance. The stock splunk_format.txt ships with NetScaler; keep it. A missing data-format file fails the analytics profile programming and rolls the whole analytics configuration back.

Verify

After the controller programs the profile, drive MCP traffic through the Gateway, then wait past one AppFlow flush interval (approximately 60 seconds) before checking Splunk — records are batched, not sent per request.
Confirm the analytics configuration and Secret are in place:
kubectl -n default get configmap cic-configmap -o jsonpath='{.data.NS_ANALYTICS_CONFIG}'
kubectl -n default get secret mcp-hec-token
On NetScaler, a Web Insight analytics profile with MCP Summary: ENABLED, Endpoint URL: /services/collector, and a reference count equal to the number of MCP routes indicates the configuration is programmed. In Splunk, each MCP transaction arrives as an event carrying the target server, method, tool name, status, and latency.
Note:
Between flushes, the only connections to the collector are the service group's health-check probes. These are not analytics records — wait for the AppFlow flush before concluding that delivery is not working.

Reference