Skip to main content

Metrics

The Metrics section provides a centralized suite for aggregating and visualizing traffic data across your network. These tools help you monitor performance, identify high-usage resources, and gather necessary data.

Metrics tab​

The primary Metrics tab focuses on network utilization and traffic volume. It provides a high-level summary of data movement through the network, allowing you to analyze traffic patterns over specific timelines.

View traffic by dimension​

The dashboard is highly interactive, allowing you to analyze network metrics through several distinct dimensions that update dynamically based on your selections.

The primary dimensions you can select are located on the left side of the screen:

  • Dialing endpoints: A list of the specific clients or identities that are generating traffic.
  • Hosting endpoints: A list of the specific destination identities where traffic was sent over the NetFoundry network.

Once you select a specific endpoint from these lists, the rest of the dashboard updates to represent that selection:

  • Usage by service: Located underneath the endpoint lists, this table updates to display only the services accessed by or hosted by the specific endpoint you selected.
  • Top usage by resource type: A set of interactive pie charts on the right summarizing the distribution of traffic across Dialing Endpoints, Hosting Endpoints, Services, and Edge Routers. You can hover over sections of these charts to see specific data points.
  • Time-series visualizations: The charts at the bottom right provide granular data trends over time, limited to the top 10 results. These charts feature four tabs that update dynamically if you select a different service or endpoint:
    • Usage by dialing endpoints: Shows traffic trends over time for specific source identities.
    • Usage by services: Focuses on traffic volume trends specific to the services being utilized.
    • Usage by hosting endpoints: Details traffic volume trends for the endpoints hosting your applications.
    • Usage by direction: Visualizes the flow of data, helping you distinguish between ingress and egress traffic volumes across the fabric.

Filtering metrics​

To refine the data displayed across these dimensions, you can apply these filters at the top of the dashboard:

  • By time: Select preset intervals to view data from the last 1h, 6h, 24h, 3d, or 7d.
  • Filter By Endpoint Attribute: Focus on specific groups or policy-based segments of your network.
  • Select Time Frame Define a custom date and time range for deep historical analysis.

Fabric latency tab​

Fabric latency measures router-to-router latency across the NetFoundry mesh. In Ziti, this is technically referred to as link latency—the delay measured between individual router links.

Each router in the mesh establishes bidirectional links (both outbound and inbound) with other routers. Fabric latency tracks the latency on each leg of these links, allowing you to see performance from any router's perspective.

For example, latency between routers within the same cloud provider (e.g., AWS to AWS) is typically excellent. Conversely, latency between different providers (e.g., AWS to Azure) tends to be higher and more prone to spikes because traffic must leave one provider's backbone to traverse another.

Configuration and filters​

The Fabric Latency tab allows you to isolate specific link performance using these selections:

  • Link source router: Use the dropdown to select a specific edge router as the starting point for link latency measurement.
  • Type: Filter the displayed data by statistical type, including Mean, Max, and P99.
  • Date filter: Select from several preset time intervals (e.g., Today) or use the adjacent Date Range Selection calendar tool to define a custom time frame for analysis.
  • Target routers: Choose to view All Links for the selected source router, or use the Select Edge Routers dropdown to specify up to 10 target routers for direct comparison.

Visualizing fabric latency​

The dashboard provides two primary interactive views of your fabric's health:

  • Network diagram: A visualization showing the selected Link Source Router and its bidirectional connections to target routers. Labels on the connection lines provide a real-time snapshot of latency (in milliseconds) for each specific path.
  • Time-series graph: A multi-line chart that plots latency trends over time (e.g., a 24-hour period at 1-hour intervals). Each line represents the latency between the source router and a different target router, allowing you to identify performance variability or spikes across the fabric.

Controller latency tab​

Controller latency measures the delay between the NetFoundry controller and all routers in the network.

Every router maintains an active connection with the controller through a control channel. This connection allows routers to:

  • Enforce network policies
  • Receive configuration updates
  • Communicate policy changes in real-time

When you make policy changes in the management interface, those changes flow to the controller and are then propagated down to all routers through these connections.

This section displays a network diagram showing routers and their latency connections to the controller, along with a time-series graph showing latency trends.

note

With the introduction of high availability (HA) controllers, there may be multiple controllers maintaining connections to routers.

Configuration and filters​

The Controller Latency tab provides filtering and selection options similar to the Fabric Latency tab, allowing you to isolate control plane performance:

  • Type: Filter the displayed data by statistical type, including Mean, Max, and P99.
  • Date Filter: Select from preset time intervals or use the adjacent calendar tool to define a custom date range for deep historical analysis.
  • Target Routers: Choose to view All Links for the controller, or use the Select Edge Routers dropdown to specify up to 10 target routers for direct comparison.

Visualizing controller latency​

The dashboard provides two primary interactive views of your control plane's health:

  • Network diagram: A radial visualization showing the central controller's active connections to each edge router. Labels on the connection lines provide a real-time snapshot of latency (in milliseconds) for that specific path.
  • Time-series graph: A multi-line chart that plots latency trends over time (e.g., a 24-hour period at 1-hour intervals). Each line represents a different router, allowing you to identify if specific geographic regions are experiencing control plane lag.

Latency timeouts tab​

Latency timeouts track instances where network requests fail to complete within the allotted time. This data is essentially a filtered search of link latency data where values exceed a certain limit, equating to a timeout. Monitoring these timeouts helps identify failing paths or overloaded routers before they impact the broader user base.

Configuration and filters​

The Latency Timeouts tab allows you to isolate specific failure points using these selections:

  • Source: Use the dropdown to select the originating router for the request that timed out.
  • Target: Use the dropdown to select the destination router that failed to respond in time.
  • Date Filter: Use the calendar tool to select a specific date for which to view timeout events.

Traffic analysis tab​

Traffic analysis is designed to help with microsegmentation by revealing what traffic is actually flowing through your network when using ingress and egress gateways.

note

In ZTNA deployments, edge routers function like traditional hardware routers, creating a "funnel-to-funnel" connection between networks. Because the zero-trust domain ends at the private edge routers, the segments between clients/applications and their nearest routers remain unencrypted. Traffic analysis provides visibility into these unprotected connections, allowing you to observe actual network traffic patterns before implementing tighter microsegmentation.

Use case: Network discovery and microsegmentation​

Traffic analysis helps when you need connectivity between two networks but don't know exactly what needs to communicate (e.g., when connecting two VPCs where specific communication requirements are unknown):

  1. Deploy ingress and egress gateways to funnel traffic between the networks.
  2. Use traffic analysis to observe what's actually communicating (source IPs, destination IPs, ports).
  3. Convert these observations into granular NetFoundry policies and services.
  4. Implement proper microsegmentation by moving from wide "funnel" access to explicit policies based on real usage.

This approach is particularly valuable when dealing with flat networks where traffic patterns aren't well understood or in "brownfield" deployments where NetFoundry software hasn't yet been deployed to all hosts. Verification via traffic analysis is necessary to ensure that external routing configurations (like load balancers or static routes) are correctly directing traffic toward the NetFoundry fabric.

Configuration and filters​

The Traffic Analysis tab provides specific filtering and view options to help you parse high volumes of network traffic:

  • Date selection: Define a specific time window for analysis using the calendar tool.
  • Filter by service: Isolate traffic associated with a specific defined service.
  • Filter by identity: View traffic associated with specific originating or destination identities.
  • More filters: Opens a dropdown to add granular filters for Ingress IPs, Egress IPs, or Egress Ports.
  • View toggle: On the far right, you can toggle the view between a comprehensive table showing both ingress and egress, or select specific Ingress or Egress views from the icon dropdown to update the table accordingly.

This section displays a detailed table of network connections with this information:

  • Ingress IP: The source IP address initiating the connection
  • Egress IP: The destination IP address
  • Egress Port: The destination port number
  • Ingress Entity Name: The identity of the source endpoint
  • Egress Entity Name: The identity of the destination endpoint
  • Service Name: The associated service, if defined
  • Circuits: The number of circuits using this connection

More info​

Read more on OpenZiti docs: