P-DEM Enterprise Dashboards 

Sites Overview

Main usage

The “Sites Overview” dashboard is the standard entry point for your corporate sites performance monitoring. It provides you with all information you need to assess the overall network connectivity performance of your monitored sites and users, identify any degradation and determine its scope in terms of number of impacted monitored sites and users. You can also measure whether network degradation directly affects the overall monitored applications performance.

Summary

The “Summary” widget provides an overview of the monitored users, Netskope POPs, and global performance indicators. These reflect the selected time period, and are updated automatically when you select another time period or when you apply some filters.

ValueDescription
UsersNumber of NSClients from which Network Probes and App Probes data are being collected.
Note: When the NSClient does not perform any Network Probe or App Probe test, the corresponding user cannot be counted in the list of monitored users.
POPsNumber of Netskope POPs that are being used by monitored sites and users.
Connectivity Perf.Network latency (RTT – Round Trip Time) between the corporate sites/users and the Netskope POPs.
Applications Perf.Time To First Byte (TTFB), which is a good indicator of the global application performance.

Monitoring Scope

The “Monitoring Scope” widget on the other hand corresponds to the configuration.

It means that the values do not vary according to the possible applied filters. 

It provides the number of Sites, IPSec/GRE tunnels and number of applications that are being configured in the system. 

These are not dependent on the select time period and will not be affected by the filters.

Sites Overview

The map shows either the location of the sites/users or the location of the Netskope POPs your sites and users were connected to for the specific selected time period (1).

You can choose to visualize all monitored sites and users or only users that are either working from corporate sites or working from home (2).

The POP connectivity metric corresponds to the network latency between your sites/users and the Netskope POPs they are connected to. 

Notes:The map uses a color gradient to show either sites/users or Netskope POPs.
The gradient starts with the blue, indicating the lowest values and evolves to the purple for the highest values observed in the selected time period.
So the purple color does not mean the corresponding site/users/POP experiences degradation per se. This simply indicates the highest values in the map.
A gray color means that the site/user is geo located but that there is no associated collected performance metric during the selected time period.
A circle corresponds to a grouping of sites located in the same region.
Mouseover it to see the number of corresponding sites.

Zoom (use the zoom bar at the right of the map or directly click on the circle) to see each site or user’s locations in more detail.

Note that a site count can also be related to remote users.
In the screenshot above, 25 users were reported. When zooming, you see that 23 users are working from home, while there are two distinct corporate sites also identified on the map.

Summary table of information provided in the map:

DataDescriptionExample
TitleCorporate site name (for single site location)
“REMOTE” in case of remote users location
“X Sites ” in case of multiple sites in the same geography.
Single site:

Remote users:

Multiple sites:
UsersNumber of monitored users on the specific location. “Monitored users” means that their NSClient is steering traffic and is DEM-enabled.
POP connectivityRTT measurement between NSClients and/or Enterprise Stations performing Network Probe tests to the Netskope POPs.
Tests CountNumber of Network Probe tests performed from that location to the Netskope POPs the site/users is/are connected to during the selected time period.

Connectivity performance

The “Connectivity Performance” table provides the list of all monitored corporate sites during the selected time period. For each site, you can identify the number of Netskope POPs your users were connected to (1) as well as the number of users working from it (2).

The main objective of this table is to let you identify whether specific sites are being impacted by network connectivity degradation. A degradation can be due to a high latency to connect to Netskope POPs (3) or to high packet loss (4). 

Clicking on any of the columns will sort the values accordingly. You can sort in descending or ascending mode by just clicking again on the column title.

The data can be grouped by geolocation (Continent, Country, Region and city) or by Site (5).

Once you have identified an impacted site or any site of interest, simply click on its name in the first column to automatically navigate to the “Site Details” dashboard.

The site called “REMOTE” identifies all users that are working from home (or any location that is not part of the corporate sites’ configuration).

Application Performance

The “Applications Performance” table is used to measure the applications performance perceived by each corporate site or users locations. Data can be grouped by geo locations or sites.

The main goal is to determine the impact any network related degradation may have on the applications performance. 

Again, simply click on a site name (when grouping on sites) of interest to automatically navigate to the corresponding “Site Details” view.

Site Details

Main usage

The “Site Details” dashboard is usually used when you want to better understand how a specific corporate site is performing in terms of connectivity to the NewEdge cloud and determine whether this network performance may affect how applications are being delivered to the end users.

From this view, you can detect when a corporate site experiences network connectivity issues, identify their connectivity context (to which Netskope POPs they were connected during the degradation), and how this possibility affects applications performance.

You can easily pivot your viewing angle by focusing your analysis on specific Netskope POPs while considering all corporate sites and users locations, or you can directly navigate to either network troubleshooting dashboard or more applications-centric dashboard to continue your analysis.

Summary

The “Summary” widget provides an overview of the monitored users, Netskope POPs, and global networks and applications performance indicators. These reflect the selected time period, and are updated automatically when you select another time period or when you apply some filters.

ValueDescription
UsersNumber of NSClients from which Network Probes and App Probes data are being collected.
Note: When the NSClient does not perform any Network Probe or App Probe test, the corresponding user cannot be counted in the list of monitored users.
POPsNumber of Netskope POPs that are being used by monitored sites and users.
Monitored AppsNumber of monitored applications through App Probe tests.
Connectivity Perf.Network latency (RTT – Round Trip Time) between the corporate sites/users and the Netskope POPs.
Applications Perf.Time To First Byte (TTFB), which is a good indicator of the global application performance.

Network Connectivity

This table provides the main network performance metrics (POP connectivity and packet loss), grouped per site and associated Netskope POPs.

It lets you identify any network degradation that may be specific to particular Netskope POPs connectivity.

In addition to the performance metrics, each line provides the site name, it’s location, the associated POP, as well as the number of monitored users that are connected to the associated POP.

From this table, you can either select a specific Netskope POP by clicking on the filter icon next to its name, or click on a site name to navigate to the “Path Performance” dashboard.

Applications Performance

This table provides the list of monitored applications through App Probe tests, as well as the main application performance metrics (availability and TTFB).

It allows you to quickly identify any degraded application for the site you are focusing your attention on.

From this table, you can also compare the performance of specific applications for multiple sites by adapting the filters accordingly.

From this table, you can either navigate to the “Path Performance” dashboard by clicking on the site name, or navigate to the “Application Details” dashboard by clicking on one of the applications names.

POPs Connectivity – Packet Loss – Transit Time

These time series respectively provide the POPs connectivity, POPs packet loss and POPs transit time evolution over time. It allows you to quickly narrow down your analysis to most degraded time periods by using the focus mode. 

Path Performance

Main Usage

The “Path Performance” dashboard lets you troubleshoot connectivity issues between your corporate sites and the Netskope NewEdge cloud. So even if this is not a strict requirement, it will be usually used when first filtering on a specific site.

It provides a comprehensive visualization of all network paths between corporate sites and the Netskope POPs they were connected to during a selected time period. It allows you to identify all ISP networks that were traversed by the traffic and troubleshoot network connectivity issues (local connectivity, ISPs peering, ISP backbones).

Time series and distribution graphs

At the top of the dashboard, you can see the evolution over time of the network latency, packet loss and path length metrics.

The time series also clearly distinguish between each individual Netskope POP being accessed, and the corresponding connectivity performances.

Clicking on the filter icon at the left of any Netskope POP name (1) lets you focus on this specific POP and corresponding performance evolution.

You can switch between the Netskope POP name identification and its public IP address by clicking on the “Target IP” switchbox (2).

The distribution graphs show the number of Network Probe tests performed (Y axis) and the corresponding metric values (X axis). You can adjust the scale of the X axis by using the slide bar (3).

In some circumstances, the Netskope POP could be unreachable. In such cases, you’ll see “partial” metrics appearing (4). This means that the corresponding metric has been measured from the site up to the furthest discovered routing node in the network path.

The network path visualization

The network path visualization widget shows all network paths that were taken during the selected time period. In the example below, you can see that the corporate site was connected to three Netskope POPs.

Each node in the path corresponds to a router (or any network component delivering the routing service).

Each color identifies an AS (Autonomous System). In other words, this color identifies the ISP being traversed.

For each node, we identify its:

  • location based on its RIR (Regional Internet Registry) registration
  • AS name
  • ISP name

For each node, we also provide the number of Network Probe tests that passed through it as well as its delay and packet loss.

Sometimes, intermediate routers may not react to the Network Probe sollicitations and remain unknown. 

These are still detected on the path but no information can be provided. These unknown nodes are shown in gray.

Other nodes may have private IP addresses. 

In such a case, they are not owned by any specific ISP and cannot be geolocated.

These are identified by lined grayed nodes.

Some consecutive nodes on a single path could be unknown. 

Instead of showing a line with multiple unknown nodes, they are grouped all together (hexagon icon).

The thickness of a link shows its usage. A thick line means that this path has been taken in a significant amount of Network Probe tests. On the other hand, a thin line means that the link has not been used much.

Mousover any link on the path to see corresponding metrics, which are:

  • The number and percentage of Network Probe tests that went through this link
  • The packet loss
  • The minimum delay

When the Netskope POP is not reached, the link between the furthest discovered node and the Netskope POP is represented as a stripped line. This means that there may still be additional intermediate nodes in between, but these have not been identified.

Some visualization options lets you simplify the network paths view when it becomes too complex to remain relevant.

First, you can group all nodes from the same ISP AS together by selecting the “Group By AS” option from the dropdown list at the left of the widget.

You can also take the most used links into consideration by selecting either “Threshold 10%” or “Threshold 25%” options from the same dropdown list.

For example, selecting the “Threshold 25%” will remove all links that were traversed by less than 25% of all Network Probe tests from the network path visualization. This lets you focus on the most used links that may be degraded and that are most prevalent to network connectivity degradation.

If you want to see the last network path taken from the selected time period, select the “Last Path” option from the second dropdown list. The last network path will be highlighted.

If you want to identify all links that introduce the highest network latency, select the “Delay” option from the same dropdown list:

Note:The highest values are highlighted in red.
However, this does not mean that these links are problematic per se. It simply indicates the highest value from all links.

You can also focus on the link experiencing the highest packet loss ratio by selecting the “Loss” option from the dropdown list:

Troubleshooting a connectivity issue

You can make use of the network path visualization highlighting tools (like Delay and Packet loss) to troubleshoot network connectivity performance issues, but the simplest way will definitely be to use the focus mode.

The following example shows how it is possible to combine focus mode on both time series and distribution graphs.

First, we focus on the Network Probe tests for which the end-to-end packet loss was about 80% (1).

From the results (do not forget that the focus mode will update all data shown on the dashboard), we take the Network Probe tests corresponding to the highest end-to-end latency (2).

As a result, the network path visualization will highlight the corresponding network path(s).

This example highlights the specific network path that was causing the network connectivity degradation. Thanks to this view, you can:

  • Identify the Netskope POP used at the time of the degradation
  • Identify all ISPs involved in the network path
  • Distinguish between BGP peering, ISP routing, link and nodes degradation

Applications Overview

Applications Overview

Main usage

The “Applications Overview” dashboard is your typical entry point for your business applications performance monitoring. 

It provides you with all information you need to assess the overall SaaS applications performance for your monitored sites and users, identify any degradation and determine its scope in terms of number of impacted monitored sites and users.

Summary

The “Summary” widget provides an overview of the monitored applications (including the number of users and sites that are monitoring them) and their global performance indicators. These reflect the selected time period, and are updated automatically when you select another time period or when you apply some filters. 

ValueDescription
AvailabilityPercentage of applications’ availability.
TTFBTime To First Byte (TTFB), which is a good indicator of the global application performance.
ServerServer response time, which is a good indicator of the specific server performance.
UsersNumber of NSClients from which Network Probes and App Probes data are being collected.
Note: When the NSClient does not perform any Network Probe or App Probe test, the corresponding user cannot be counted in the list of monitored users.
SitesNumber of corporate sites from which the applications are being monitored through App Probe tests.
Monitored AppsNumber of monitored applications through App Probe tests.

Applications

The map shows either the location of the sites/users (from which App Probe tests are run) or the location of the servers that are delivering the applications for the specific selected time period (1).

You can choose to visualize all monitored sites and users or only users that are either working from corporate sites or working from home (2).

The availability metric corresponds to the percentage of applications availability. 

Notes:The map uses a color gradient to show the applications or servers availability (depending on the chosen location (1).
The gradient starts with the red, indicating the lowest values and moves to the green for the highest values observed in the selected time period. 
A grey color means that the site/user or the server is geo located but that there is no associated collected performance metric during the selected time period.
A circle corresponds to a grouping of sites/servers located in the same region.
Mouseover it to see the number of corresponding sites/servers.

Zoom to see each site/users or servers locations in more detail.

Note that a site count can also be related to remote users.
In the screenshot above, seven users are working from home, while there are three distinct corporate sites also identified on the map.

From this map view, you can already click on a specific site or server of interest (typically one experiencing low availability) to automatically navigate to the “Application Details” dashboard and continue your analysis.

Summary table of information provided in the map:

DataDescriptionExample
UsersNumber of monitored users on the specific location. “Monitored users” means that their NSClient is steering traffic, is DEM-enabled and performs App Probe tests.
AvailabilityPercentage of application’s or server’s availability for the corresponding located users/sites
Tests CountNumber of App Probe tests performed from that location to the monitored applications during the selected time period.

Top Applications

The top applications table provides some details on a per-monitored application basis.

It helps you answer the following questions:

  1. Which applications are having poor performance?
    The provided metrics are availability, TTFB, and server.
  2. How many corporate sites and users may be impacted by an application performance degradation?
  3. How many servers are delivering the monitored application(s)?

From this table, you can simply click on one of the applications name to automatically navigate to the corresponding “Application Details” dashboard.

Applications Details

Main Usage

The “Application Details” dashboard is usually used when you want to better understand how a specific application is performing and diagnose degradations.

From this dashboard you can understand the reasons why an application may be unavailable.

You can also determine the root cause of any performance degradation (meaning the application is available but does not perform properly) by identifying the origin of the problem. This may be due to:

  • Connectivity issue and/or network services problems between the sites/users and the Netskope POPs
  • Abnormal transit time within the Netskope infrastructure itself
  • Connectivity issue between the Netskope POPs and the servers that are delivering the application
  • Server issue

Overview

This overview widget makes more sense when you filter on a specific application.

It provides the overall availability and lets you identify when the monitored application was unavailable, as well as the total number of App Probe tests issued during the selected time period.

You can make use of the focus mode to filter data on specific service degradation moments.

Performance Metrics Summary

All App Probes performance telemetry is represented in this static view. The goal is to provide an schematic overview of the end-to-end application performance and help identify the values that may trigger your attention in case the application is deemed degraded.

There are four categories of App Probe performance data:

  1. Between the Sites/Users and the Netskope POPs
    This category includes all network performance indicators between the sites/users and the Netskope POPs:
    1. DNS resolution time
    2. Connection time 
    3. TLS time
  1. Inside the Netskope POPs
    The Transit Time corresponds to the time spent within the Netskope NSProxy itself.
  1. Between the Netskope POPs and the Applications
    This category includes all network performance indicators between the Netskope POPs and the monitored application (Connection time and TLS time). It also includes the time it takes for the server to process the request (Server time).
  1. End-to-end measurements
    This category includes all performance metrics that are computed by the NSClients/Enterprise Stations and correspond to end-to-end measurements:
    1. Redirect
    2. TTFB
    3. TTLB
    4. Data Transfer
    5. Transfer size

Sites

This table provides all App Probe telemetry details on a per location (1) (continent, country, region, city and site) and potentially per Netskope POP basis. By default, all Netskope POPs for a specific site are being grouped.

Performance data can be shown or hidden by category (2).

Servers

The “Servers” table provides the same level of information as the “Sites” table, but this time the performance telemetry is grouped by IP address of the servers that are delivering the monitored application(s).

The column “Target Country” is used to geo locate the server based on its public IP address.

In case you have focused your analysis on multiple applications, you can activate the “Application” switch to identify them:

As one application is made up of multiple domains/URLs, you can also get the data on a per domain/URL basis by activating “URL”:

Errors

When an App Probe test is not successful (meaning it does not end up by getting the expected response code from the server), then it triggers an error, which is taken into consideration for the application’s availability metric. 

The “Error” table provides the list of the encountered errors, their percentage (compared to the total number of performed App Probe tests during the selected time period) and count.

Supported errors messages are:

Error messageDescription
CONNECTThe tester was unable to connect to the target
DNSThe tester was unable to resolve the targeted domain name
GOT_NOTHINGThe Tester did not receive any response from the target. However, the connection was correctly established and terminated.
HTTP2_STREAMStream error in the HTTP/2 framing layer
PARTIAL_FILEThe target sent an unexpected response size (mismatch between announced size and transferred size)
PLAIN_HTTPThe redirection ended up targeting a URL in HTTP
PROTOCOLThe redirection ended up using an invalid or unsupported protocol
RECVMay happen when the connection to the server is closed while still receiving response from the server
REDIRECT_URLThe redirection ended up targeting an invalid URL
STATUSThe response code was not in the range of configured expected status codes
SENDMay happen when the connection to the server is closed while still uploading data to the server
TIMEOUTThe target did not respond within the time frame configured in the “timeout” parameter
TLSThe tester was unable to establish a secure connection with the target
TOO_MANY_REDIRECTSThere were too many redirections before reaching the target, as configured in the “Redirect” parameter
The “tester” refers to either the “NSClient” or the “Enterprise Station”.

The Error details columns provide the list of errors encountered per category. 

You can get the details of each error by ungrouping the data in this column.

Response Status

When the application you are monitoring is unavailable due to “STATUS” related errors, it means that the targeted server did send a response code, but this one was different from:

  • The range 200-299 for App Probes tests configured for NSClients
  • The range you configured in the App Probes tests for Enterprise Stations.

In such a case, the “Response Status” time series provides the list of received response codes as well as their occurrence over time.

Simply click on the filter icon corresponding to one response code to automatically focus on corresponding performance data. This will help you identify the servers that are triggering this response code, or the impacted applications in case you did not filter on a specific application when looking at “Application Details” data.

Performances

This time series shows all performance metrics evolution over time.

In order not to overload the graph with too many metrics at once, you can first select the metric category (1). Then you can also highlight one specific metric by clicking on its name (2). Hold SHIFT and click on multiple metrics to show them simultaneously.

The focus mode will help you here to focus on a more specific period of time corresponding to a performance degradation.

For example, select the “End-to-End” category and select TTFB as the main metric to show. If you notice a peak of TTFB value, select it through the focus mode.

In order to see whether this application performance degradation was due to a bad site/users connectivity to the Netskope POPs, select the category “Sites to POPs” and observe the curves during the selected period. If you observe a peak of Netskope POP connectivity, then pivot your viewing angle by navigating to the Site Details dashboard that will provide more insights about network performance.

Distribution Graphs

The distribution graphs show the number of tests (vertical axis) and corresponding performance value (horizontal axis).

For the Site to POPs graph, you can choose between DNS, Connection and TLS metrics.

For the POPs to Apps graph, you can choose between Connection, TLS and Server metrics.

The POPs graph shows the Transit Time.

For the End-to-End graph, you can choose between Redirect, TTFB, TTLB, Data transfer, Duration and Transfer size.

The slider can help you adjust the scale of the horizontal axis if required.

You can make use of the focus mode feature from this graph.

You can combine multiple focus modes from different distribution graphs and combine them with focus modes set on time series.

Share this Doc

P-DEM Enterprise Dashboards 

Or copy link

In this topic ...