The network view was released in Unleash 4.21. It is available to Pro and Enterprise users.
You must configure the data source to activate the feature.
The Unleash admin UI contains a network view as part of the admin configuration pages. This network view was designed to give you an overview and understanding of incoming requests to your Unleash instance. It makes it possible to pinpoint sources of sudden request surges, and can therefore also help you identify issues with SDK setups1.
Because Unleash doesn't store this kind of data itself, the network view requires you to configure an external data source for the network overview to work. The network view is only available if you tell Unleash where it can find the data (refer to the data source section).
The network view is intended to provide a simple and Unleash-centric overview that serves basic use cases. If you need detailed metrics and connection graphs, you may be better off using specialized network monitoring tools.
Both the network overview and the network traffic diagrams show you applications that have made requests to the Unleash instance. An application is defined as anything that sends requests to the Unleash client API, the Unleash front-end API, the Unleash admin API, or any other API that Unleash exposes. This includes Unleash SDKs, Unleash Edge, the Unleash proxy, and even the admin UI.
Requests that come from Unleash SDKs and other official Unleash applications will always have an application name defined. But you might sometimes see some applications listed as "unknown" in the diagrams.
This happens when Unleash receives requests that don't contain an application name header (
UNLEASH_APPNAME). This can happen, for instance, if you make HTTP requests from the command line to test Unleash connections or if you write your own HTTP client for Unleash that doesn't provide an application name.
Because Unleash can't separate these based on their application names, all "unknown" clients will get lumped together as one application in the overview.
Each application shown on the diagram has:
- An application name
- the average number of requests per second (req/s) that we have registered over the last five minutes.
The network traffic diagram is a line chart that presents requests that have used the most network traffic over the last six hours, grouped by client and base URL for the request. For legibility, this chart only shows the ten groups that have caused the most traffic over the last six hours.
Unleash aggregates requests by client (using application name) and base URL. Base URLs are batched together using the first two path segments following the
/api part of the URL. In essence, that means:
- Separate requests by API: Admin API requests are separate from client API requests.
- Within each of these groups, group all requests by their next URL path segment. For instance:
/client/features/feature-aare grouped together, while
/admin/featuresare separate groups.
The network view was written to be used with Prometheus and is therefore compatible with Prometheus' API.
Other services that offer the same capabilities and the same API may work as substitutes, but we make no guarantees.
This section will refer to the external source as Prometheus for simplicity.
The network view uses an external Prometheus-like API to create diagrams. Because of this, Unleash will not enable the network view feature unless you set the
PROMETHEUS_API environment variable.
PROMETHEUS_API environment variable should point to the base path of the Prometheus installation, and Prometheus should be configured to get its data from Unleash's internal backstage API. This can for example be done via a scraping job2:
- job_name: unleash_internal_metrics
- targets: ['unleash-url']
This setup means that there is a mutual dependency between Unleash and Prometheus, where Prometheus regularly fetches data from Unleash's backstage API and Unleash fetches and displays this data when you use the network view. This diagram provides a visual representation of that.
- For instance: when using Unleash in an API setting, a common mistake is to instantiate a new SDK for every request instead of sharing a single instance across requests. This would be visible in the network overview graph as a large number of requests from the same app.↩
- How to set up Prometheus to collect metrics from that API is outside of the scope of this document.↩