Support stack overview

The NetFoundry support stack is a collection of interoperating software components designed to empower users to leverage all telemetry and events available in Ziti, providing observability and troubleshooting capabilities.

This deployment relies on a proprietary Helm chart and is only available with a private access token issued from NetFoundry. Support stack components are pre-configured to work together to provide viable support for the Ziti installation, as well as providing rich visibility into how the network is being used. This includes pre-configured telemetry dashboards and searchable application logs. The subcomponents within the support stack are outlined below:

Stack components

• Elasticsearch: Telemetry and Log storage and searchability. Also provides an API for all log and telemetry data.
• Logstash: Flexible data processing and shipping. Future iterations will allow extensions to be configured by the user to stream metrics to additional systems.
• Kibana: UI for Elasticsearch, used to view the raw log and telemetry data and provides a full featured search mechanism. Ships pre-configured organized data sources.
• Grafana: Industry standard dashboard tool for viewing and analyzing metrics. Ships pre-configured with all data sources and standard dashboards that we use internally at NetFoundry.
• RabbitMQ: Provides a buffer for Ziti metrics and events. The metrics are consumed and processed by Logstash. This can also be extended if customers want to create additional queues and stream metrics to their own systems.
• Beats Agents: These are micro-containers that run as data collectors on all Kubernetes nodes as a DaemonSet. They collect logs and metrics from all containers in the support and Open Ziti namespaces.
• Ziti Edge Tunnel (Optional): By default, none of the support tools are exposed externally. Users have control as to how these support services are exposed, but we recommend making the support tools accessible over Ziti, and using the Ziti Edge Tunnel as the primary access method. This eliminates any extra open ports from the support installation, and satisfies most compliance audits.

Resource requirements

The support stack requires a minimum of 4 CPU cores available in the cluster. The installer checks available cores before installation and skips the support stack if this threshold is not met. All other Ziti components still install normally.

Storage and index lifecycle defaults vary based on the deployment type:

Setting	K3s (single-node)	Multi-node cluster
Elasticsearch storage	30Gi	100Gi
Index rollover size	1GB	3GB
Index rollover age	1d	3d
Max index age	7d	7d
RabbitMQ storage	3Gi	3Gi

Data flow

Telemetry and event data flows through the support stack as follows:

1. The Ziti controller publishes events and metrics via AMQP to RabbitMQ.
2. Logstash consumes messages from RabbitMQ, processes them, and writes to Elasticsearch.
3. Beats agents (running as DaemonSets) collect container logs and metrics from all pods in the ziti and support namespaces and ship them to Elasticsearch.
4. Grafana and Kibana read from Elasticsearch to provide dashboards and searchable log views.

Configuration

The installer generates a support-values.yml file with default settings based on your deployment type (K3s or production). If the file already exists, it is left unchanged. Key settings:

elasticsearch:
  node_count: 1
  node_storage: 100Gi        # 30Gi for K3s
  max_index_age: 7d
  rollover_index_age: 3d     # 1d for K3s
  rollover_index_size: 3GB   # 1GB for K3s

rabbitmq:
  storage: 3Gi

• node_count — Number of Elasticsearch nodes. Increase for production high-availability.
• node_storage — Persistent volume size per Elasticsearch node.
• max_index_age — Maximum age before an index is deleted by the ILM policy.
• rollover_index_age / rollover_index_size — Triggers for creating a new index when the current one reaches the specified age or size.
• rabbitmq.storage — Persistent volume size for the RabbitMQ message buffer.

To apply configuration changes after installation:

helm upgrade --install support ./helm-charts/support/ --values support-values.yml -n support

Accessing support tools

By default, none of the support tools are exposed externally. The installer creates Ziti services for each tool, making them accessible over the Ziti network at the following intercept addresses:

Tool	Intercept address	Port
Grafana	grafana.ziti	80 (HTTP)
Kibana	kibana.ziti	443 (HTTPS)
Elasticsearch	elasticsearch.ziti	443 (HTTPS)

During installation, a support-user.jwt enrollment token is generated for client access. To reach the support tools:

1. Enroll the support-user.jwt token with a Ziti client (Desktop Edge, mobile tunneler, or CLI tunneler).
2. Once connected, access the tools at the intercept addresses above (e.g., http://grafana.ziti in your browser).

This approach eliminates the need for any externally exposed ports and satisfies most compliance requirements.

Default credentials

Tool	Username	Password
Grafana	admin	admin (you will be prompted to change this on first login)
Elasticsearch / Kibana	elastic	Auto-generated during installation

To retrieve the Elasticsearch / Kibana password:

kubectl get secrets "elasticsearch-es-elastic-user" -n support \
  -o go-template='{{index .data "elastic" | base64decode}}'

Additional support tools

• Ziti Database Snapshots: Regular snapshots of the Ziti database are captured and stored on a separate PVC volume.

• Support bundle: This script gathers diagnostic information including recent logs and stack dumps from the Ziti controller and router and places them in a zip file that can easily be sent to NetFoundry support for analysis.