/api/v1/platform/login'
- ```
-
-
-
-
-To use the [NGINX Controller REST API]({{< ref "/controller/api/_index.md" >}}) to download your NGINX Plus certificate and key bundle as a gzip or JSON file, send a GET request to the `/platform/licenses/nginx-plus-licenses/controller-provided` endpoint.
-
-For example:
-
-- Download JSON file:
-
- ```bash
- curl -b cookie.txt -c cookie.txt --header 'Content-Type: application/json' -X GET --url 'https://192.0.2.0/api/v1/platform/licenses/nginx-plus-licenses/controller-provided' --output nginx-plus-certs.json
- ```
-
-- Download GZIP file:
-
- ```bash
- curl -b cookie.txt -c cookie.txt -X GET --url 'https://192.0.2.0/api/v1/platform/licenses/nginx-plus-licenses/controller-provided' --output nginx-plus-certs.gz
- ```
-
-{{< call-out "note" >}}
-If you are using a self-signed certificate you will need to add `-k` (allow insecure connections) to your curl command to be able to download your NGINX Plus certificate and key bundle.
-{{< /call-out >}}
-
-
-Once you have downloaded your certificate and key bundle you will need to expand the `.gz` file to get your certificate and key pair.
-
-For example:
-
-```bash
-gunzip nginx-plus-certs.gz
-```
-
-### Deploy NGINX App Protect
-
-
-
-Install NGINX App Protect on a host accessible by your NGINX Controller instance by following the appropriate steps for your operating system in the [Using NGINX App Protect with NGINX Controller]({{< ref "controller/admin-guides/install/install-for-controller.md" >}}) guide.
-
-{{< call-out "note" >}}
-If you install NGINX App Protect by using any of the OS-specific install guides, **do not make changes to the `nginx.conf` file**.
-The NGINX Controller Agent manages `nginx.conf` settings and will make the appropriate adjustments for you.
-{{< /call-out >}}
-
-
-
-
-
----
-
-## Add the NGINX App Protect Instance to NGINX Controller
-
-{{< include "controller/add-existing-instance.md" >}}
-
-
-
----
-
-## What's Next
-
-You should now be ready to start your NGINX Controller with App Security trial. Refer to the following topics to get started:
-
-- [Configure the NGINX Controller Agent]({{< ref "/controller/admin-guides/config-agent/configure-the-agent.md" >}})
-- [Set Up Metrics Collection]({{< ref "/controller/admin-guides/config-agent/configure-metrics-collection.md" >}})
-- [Forward Metrics Data to an External Service]({{< ref "/controller/analytics/forwarders/_index.md" >}})
-- [Set up NGINX Controller Services]({{< ref "/controller/services/overview.md" >}})
-
-{{< versions "3.0" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/admin-guides/install/try-nginx-controller.md b/content/controller/admin-guides/install/try-nginx-controller.md
deleted file mode 100644
index e77bf343f..000000000
--- a/content/controller/admin-guides/install/try-nginx-controller.md
+++ /dev/null
@@ -1,279 +0,0 @@
----
-description: This quick-start tutorial shows you how to get started using F5 NGINX
- Controller with NGINX Plus.
-nd-docs: DOCS-260
-title: Trial NGINX Controller with NGINX Plus
-toc: true
-weight: 110
-type:
-- tutorial
----
-
-## Overview
-
-This quick-start tutorial shows you how to get started using F5 NGINX Controller with NGINX Plus.
-
-{{< call-out "caution" >}}In this tutorial, NGINX Controller will install an embedded, self-hosted PostgreSQL database suitable for demo and trial purposes only. **These instructions are not meant for use in production environments**.{{< /call-out >}}
-
-{{< call-out "note" >}}If you want to try out NGINX Controller with the Application Security add-on, refer to [Trial NGINX Controller with App Security]({{< ref "/controller/admin-guides/install/try-nginx-controller-app-sec.md" >}}).{{< /call-out>}}
-
-
-
----
-
-## Technical Requirements
-
-Make sure to review the [NGINX Controller Technical Specifications Guide]({{< ref "/controller/admin-guides/install/nginx-controller-tech-specs.md" >}}) for the requirements for your distribution and desired configuration.
-
-### Supported Distributions
-
-NGINX Controller, the NGINX Controller Agent, and the NGINX Controller Application Security Add-on support the following distributions and architectures.
-
-{{< call-out "note" >}}Refer to the [NGINX Plus Technical Specifications](https://docs.nginx.com/nginx/technical-specs/) guide for the distributions that NGINX Plus supports.{{< /call-out>}}
-
-{{< bootstrap-table "table table-striped table-bordered" >}}
-
-|Distribution
and Version|NGINX Controller
(Control Plane)|Agent
(Data Plane)|ADC App. Sec.
(Data Plane)|APIM Adv. Sec.
(Data Plane)|Notes|
-|--- |--- |--- |--- |--- |--- |
-|Amazon Linux
2
(x86_64)| Not supported|v3.0+ |Not supported|Not supported| |
-|Amazon Linux
2017.09+
(x86_64)| Not supported |v3.0+|Not supported |Not supported| |
-|CentOS
6.5+
(x86_64)| Not supported |v3.0+| Not supported |Not supported| • CentOS 6.5 and later versions in the CentOS 6 family are partially supported.
• This distribution does not support AVRD.|
-|CentOS
7.4+
(x86_64)|v3.0+|v3.0+ | v3.12+ |v3.19+| • CentOS 7.4 and later versions in the CentOS 7 family are supported.|
-|Debian
8
(x86_64)| Not supported |v3.0–3.21|Not supported|Not supported|• This distribution does not support AVRD.|
-|Debian
9
(x86_64)|v3.0+|v3.0–3.21 | v3.12+ |v3.19+ | |
-|Debian
10
(x86_64)| Not supported |v3.17+ | v3.17+ |v3.19+| See the [NGINX Plus Admin Guide](https://docs.nginx.com/nginx/) for requirements for Debian 10. |
-|Red Hat Enterprise Linux
6.5+| Not supported |v3.0+| Not supported | Not supported| • RHEL 6.5 and later versions in the RHEL 6 family are partially supported.|
-|Red Hat Enterprise Linux
7.4+
(x86_64)|v3.5+|v3.5+ | v3.12+|v3.19+| • RHEL 7.4 and later versions in the RHEL 7 family are supported.
• SELinux may interfere with NGINX Controller installation and operation. If you do enable SELinux, it must use permissive mode. Use of enforcing mode is not supported. |
-|Red Hat Enterprise Linux
8.0+
(x86_64)|v3.22+|v3.22+ | v3.22+| Not supported | • RHEL 8.0 and later versions in the RHEL 8 family are supported.
• SELinux may interfere with NGINX Controller installation and operation. If you do enable SELinux, it must use permissive mode. Use of enforcing mode is not supported. |
-|Ubuntu
18.04 LTS
(x86_64)|v3.0+|v3.0+ |v3.13+|v3.19+| |
-|Ubuntu
20.04 LTS
(x86_64)|v3.20+|v3.12+|v3.16.1+|v3.19+| |
-
-{{< /bootstrap-table >}}
-
-
-
-#### Analytics, Visibility, and Reporting Daemon (AVRD)
-
-NGINX Controller v3.1 and later use an Analytics, Visibility, and Reporting daemon (AVRD) to aggregate and report app-centric metrics, which you can use to track and check the health of your apps. To learn more about these metrics, see the [NGINX Metrics Catalog]({{< ref "/controller/analytics/catalogs/metrics.md" >}}) topic.
-
-### Hardware Specs
-
-The following minimum hardware specifications are required for each node running NGINX Controller:
-
-- RAM: 8 GB RAM
-- CPU: 8-Core CPU @ 2.40 GHz or similar
-- Disk space: 155–255 GB free disk space. 255 GB of free space is recommended if NGINX Controller App Security is enabled. See the [Storage Requirements]({{< ref "/controller/admin-guides/install/nginx-controller-tech-specs.md#storage-requirements" >}}) section for a categorized list of the storage requirements.
-
-### Supported NGINX Plus Versions
-
-NGINX Controller supports the following [NGINX Plus](https://www.f5.com/products/nginx/nginx-plus) versions:
-
-{{< bootstrap-table "table table-striped table-bordered" >}}
-
-| NGINX Plus | NGINX Controller | NGINX Controller ADC | NGINX Controller APIM |
-|------------|------------------|----------------------|-----------------------|
-| R30 | Not supported | 3.22.9+ | Not supported |
-| R29 | Not supported | 3.22.9+ | 3.19.6+ |
-| R28 | Not supported | 3.22.6+ | 3.19.6+ |
-| R27 | Not supported | 3.22.4+ | 3.19.6+ |
-| R26 | Not supported | 3.22.2+ | 3.19.6+ |
-| R25 | Not supported | 3.20.1+ | 3.19.2+ |
-| R24 | 3.17+ | 3.20+ | 3.18+ |
-| R23 | 3.12+ | 3.20.0 - 3.22.2 | 3.18+ |
-| R22 | 3.5+ | 3.20.0 - 3.22.1 | 3.18+ |
-| R21 | 3.5 - 3.12 | Not supported | Not supported |
-| R20 | 3.0 - 3.12 | Not supported | Not supported |
-| R19 | 2.6 - 3.5 | Not supported | Not supported |
-
-{{< /bootstrap-table >}}
-
----
-
-## Sign Up for a Trial License
-
-First, you need to sign up for a trial license for NGINX Controller. The trial includes access to NGINX Plus, the NGINX Controller Application Delivery module, and the Application Security add-on.
-
-1. Go to [MyF5](https://account.f5.com/myf5) and create a new account.
-1. Verify your account and log in to MyF5.
-1. On the MyF5 landing page, activate the NGINX Controller free trial.
-1. On the MyF5 **Trials** page, select Launch Your Trial.
-1. Download the NGINX Controller package.
-1. Make note of your Association Token. You will use this to [license your NGINX Controller instance]({{< ref "/controller/platform/licensing-controller.md#add-a-license-to-nginx-controller" >}}).
-
-
-
----
-
-## Install NGINX Controller Prerequisites
-
-{{< include "controller/helper-script-prereqs.md" >}}
-
-
-
----
-
-## Install NGINX Controller
-
-Install NGINX Controller on a dedicated node that **does not** already have Kubernetes configured. NGINX Controller does not support pre-configured Kubernetes implementations at this time. The installer for NGINX Controller will install and configure Kubernetes for you.
-
-{{< call-out "important" >}}Before installing NGINX Controller, you must **disable swap on the host**; this is required by Kubernetes in order for the kubelet to work properly. Refer to your Linux distribution documentation for specific instructions for disabling swap for your system. For more information about this requirement, see the AskF5 knowledge base article [K82655201](https://support.f5.com/csp/article/K82655201) and the [kubeadm installation guide](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) in the Kubernetes documentation.{{< /call-out >}}
-
-{{< call-out "caution" >}}**For RHEL 8 deployments**, complete the additional prerequisite steps in the [Installing NGINX on RHEL 8]({{< ref "/controller/admin-guides/install/install-nginx-controller-rhel-8.md" >}}) guide before installing NGINX Controller. RHEL 8 support is a **beta** feature.{{< /call-out >}}
-
-To install NGINX Controller, take the following steps:
-
-1. Download the NGINX Controller installer package from the [MyF5 Customer Portal](https://my.f5.com/manage/s/downloads).
-1. Extract the installer package files:
-
- ```bash
- tar xzf controller-installer-.tar.gz
- ```
-
-1. Run the installation script:
-
- ```bash
- cd controller-installer
- ./install.sh
- ```
-
-1. When prompted to use an embedded config DB, type `y`.
-
-1. The installation script walks through a series of steps and asks for the following inputs:
-
- - **Config database volume type**: Specify the type of volume to use to store the config database: local, NFS, or AWS. We recommend choosing `local` for demo and trial purposes.
-
- {{< call-out "note" >}}Refer to the [NGINX Controller Technical Specifications Guide]({{< ref "/controller/admin-guides/install/nginx-controller-tech-specs.md#local-or-external-storage" >}}) for more information about the volume options and requirements.{{< /call-out>}}
-
- - **Analytics database volume type**: Specify the type of volume to use to store the analytics database: local, NFS, or AWS. We recommend choosing `local` for demo and trial purposes.
- - **EULA**: Read the end-user license agreement. Type either `y` to accept or `n` to exit.
- - **SMTP**
- - **SMTP Host**: Provide the host name or IP address of an SMTP server. This is used to send password recovery emails. For trial purposes, if you don't need to receive these communications, you can enter a value of "example.com" or something similar.
- - **SMTP Port**: The port of the SMTP server.
- - **SMTP Authentication**: Select `y` or `n` to authenticate when connecting to the SMTP server.
- - **Use TLS for SMTP Communication**: Select `y` or `n` to use SSL for SMTP server connections.
- - **Do not reply email address**: The sender's email address. For example, `donotreply@example.com`.
- - **Admin**
- - **First name**: The first name for the initial admin user.
- - **Last name**: The last name for the initial admin user.
- - **Email address**: The contact email address for the initial admin user.
- - **Password**: The initial admin's password. Passwords must be 6-64 characters long and must include letters and digits.
- - **FQDN**: Fully qualified domain name (FQDN) -- a resolvable domain name for the NGINX Controller server. You can use the FQDN to access the NGINX Controller web interface.
- Additionally, the FQDN is used by Controller Agents when connecting to NGINX Controller.
- - **SSL/TLS certificates**: Type `y` to generate and use self-signed certs for running NGINX Controller over HTTPS, or type `n` to provide your own certs.
-
- {{< call-out "important" >}}
-If you provide your own SSL/TLS certificates, you'll need a complete certificate chain file, with the intermediate CA cert appended to the server cert; the server certificate must appear **before** the chained certificates in the combined file.
- {{< /call-out >}}
-
-1. Log in to NGINX Controller at `https:///login`. Use the admin email address and password that you provided during the installation process.
-
-1. Once NGINX Controller is installed, you may safely delete the installer package that you downloaded and extracted.
-
-
-
----
-
-## License NGINX Controller
-
-To add a license to NGINX Controller, take the following steps:
-
-1. Go to `https:///platform/license` and log in.
-1. In the **Upload a license** section, select an upload option:
-
- - **Upload license file** -- Locate and select your license file in the file explorer.
- - **Paste your Association Token or license file** -- Paste your customer Association Token or the contents of your NGINX Controller license file. These are available on the [MyF5 Customer Portal](https://account.f5.com/myf5).
-
-1. Select **Save license**.
-
-{{< call-out "note" >}}
-To add a license using the [NGINX Controller REST API]({{< ref "/controller/api/_index.md" >}}), send a PUT request to the `/platform/license` endpoint. Provide your CAT or NGINX Controller license as a base64-encoded string in the JSON request body.
-{{< /call-out>}}
-
-
-
-
----
-
-## Install NGINX Plus
-
-### Prerequisites
-
-- Make sure to review the [NGINX Plus Technical Specifications Guide](https://docs.nginx.com/nginx/technical-specs/) for the requirements for your distribution and desired configuration.
-- You'll need the NGINX Plus certificate and public key files (`nginx-repo.crt` and `nginx-repo.key`) that were provided when you signed up for the trial license. If you don't have these files, you can use the [NGINX Controller REST API]({{< ref "/controller/api/_index.md" >}}) to download them.
-
-#### How to Download the NGINX Plus Cert and Key using the NGINX Controller API
-
-The NGINX Controller API uses session cookies to authenticate requests. The session cookie is returned in response to a `GET /api/v1/platform/login` request. See the Login endpoint in the [NGINX Controller API Reference]({{< ref "/controller/api/_index.md" >}}) documentation for information about session cookie timeouts and invalidation.
-
-{{< call-out "tip" >}}
-You can send a GET request to the login endpoint to find the status of the session token.
-{{< /call-out >}}
-
-For example:
-
-- Login and capture the session cookie:
-
- ```curl
- curl -c cookie.txt -X POST --url 'https://198.51.100.10/api/v1/platform/login' --header 'Content-Type: application/json' --data '{"credentials": {"type": "BASIC","username": "arthur@example.net","password": ""}}'
- ```
-
-- Use the session cookie to authenticate and get the session status:
-
- ```curl
- curl -b cookie.txt -c cookie.txt -X GET --url 'https://198.51.100.10/api/v1/platform/login'
- ```
-
-
-
-
-To use the [NGINX Controller REST API]({{< ref "/controller/api/_index.md" >}}) to download your NGINX Plus certificate and key bundle as a gzip or JSON file, send a GET request to the `/platform/licenses/nginx-plus-licenses/controller-provided` endpoint.
-
-For example:
-
-- Download JSON file:
-
- ```bash
- curl -b cookie.txt -c cookie.txt --header 'Content-Type: application/json' -X GET --url 'https://192.0.2.0/api/v1/platform/licenses/nginx-plus-licenses/controller-provided' --output nginx-plus-certs.json
- ```
-
-- Download GZIP file:
-
- ```bash
- curl -b cookie.txt -c cookie.txt -X GET --url 'https://192.0.2.0/api/v1/platform/licenses/nginx-plus-licenses/controller-provided' --output nginx-plus-certs.gz
- ```
-
-{{< call-out "note" >}}
-If you are using a self-signed certificate you will need to add `-k` (allow insecure connections) to your curl command to be able to download your NGINX Plus certificate and key bundle.
-{{< /call-out >}}
-
-
-Once you have downloaded your certificate and key bundle you will need to expand the `.gz` file to get your certificate and key pair.
-
-For example:
-
-```bash
-gunzip nginx-plus-certs.gz
-```
-
-### Steps
-
-Take the following steps to install NGINX Plus:
-
-{{< call-out "important" >}}
-You need the NGINX Plus certificate and public key files (`nginx-repo.crt` and `nginx-repo.key`) that were provided when you signed up for the trial license.
-{{< /call-out >}}
-
-1. First, make sure to review the [NGINX Plus Technical Specifications Guide](https://docs.nginx.com/nginx/technical-specs/) for the requirements for your distribution and desired configuration.
-2. To install NGINX Plus, follow the instructions in the [NGINX Plus Installation Guide](https://docs.nginx.com/nginx/admin-guide/installing-nginx/installing-nginx-plus/). Refer to the relevant section for your distribution.
-
-
-
----
-
-## Add an NGINX Plus Instance to NGINX Controller
-
-{{< include "controller/add-existing-instance.md" >}}
-
-{{< versions "3.0" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/admin-guides/install/using-helper-script.md b/content/controller/admin-guides/install/using-helper-script.md
deleted file mode 100644
index 830602bb7..000000000
--- a/content/controller/admin-guides/install/using-helper-script.md
+++ /dev/null
@@ -1,448 +0,0 @@
----
-description: Learn how to update F5 NGINX Controller installation settings and manage
- the NGINX Controller service using the helper.sh script.
-nd-docs: DOCS-261
-title: Update NGINX Controller Settings with helper.sh
-toc: true
-weight: 200
-type:
-- how-to
----
-
-## Overview
-
-You can use the F5 NGINX Controller `helper.sh` script to update NGINX Controller installation settings and manage the NGINX Controller process. This tutorial shows you how to use `helper.sh` to perform the following tasks:
-
-- Install the NGINX Controller prerequisites
-- View the version of NGINX Controller that's installed and running
-- Start, stop, and restart NGINX Controller
-- Back up and restore the NGINX Controller config and encryption keys
-- Restore the embedded config database
-- Get the NGINX Plus repository key and certificate files (deprecated for `helper.sh` in NGINX Controller v3.9)
-- Update the SMTP settings
-- Update the database settings
-- Update or replace the TLS certificates
-- Print the NGINX Controller logs
-- Create a support package
-
-## Install NGINX Controller Prerequisites
-
-
-
-{{< include "controller/helper-script-prereqs.md" >}}
-
-
-
-
-
----
-
-## View the Installed NGINX Version
-
-To see which version of NGINX Controller is installed and running, type the following command:
-
-``` bash
-/opt/nginx-controller/helper.sh version
-```
-
-The output looks similar to the following:
-
-``` bash
-Installed version: 3.14.0
-Running version: 3.14.0
-```
-
-
-
----
-
-## Start, Stop, and Restart NGINX Controller
-
-
-You can use the `helper.sh` script to start, stop, restart, and check the status of the NGINX Controller process.
-
-``` bash
-/opt/nginx-controller/helper.sh controller start
-/opt/nginx-controller/helper.sh controller stop
-/opt/nginx-controller/helper.sh controller restart
-/opt/nginx-controller/helper.sh controller status
-```
-
-
-
----
-
-## Back Up and Restore Config and Encryption Keys
-
-
-
-After installing NGINX Controller, you should back up the cluster config and encryption keys. You'll need these if you ever need to restore the NGINX config database on top of a new NGINX Controller installation.
-
-- To back up the NGINX Controller cluster configuration and encryption keys:
-
- ```bash
- /opt/nginx-controller/helper.sh cluster-config save
- ```
-
- The file is saved to `/opt/nginx-controller/cluster-config.tgz`.
-
-- To restore the cluster's config and encryption keys, take the following steps:
-
- ```bash
- /opt/nginx-controller/helper.sh cluster-config load
- ```
-
-
-
-
-
----
-
-## Restore Embedded Config Database
-
-
-
-This section explains how to restore the embedded config database from the latest backup file or a specific, timestamped file.
-
-{{< call-out "important" >}}If you restore the config database on top of a new installation of NGINX Controller, make sure to follow the steps to [restore your NGINX config and encryption keys]({{< ref "/controller/admin-guides/backup-restore/backup-restore-cluster-config.md" >}}) afterward. {{< /call-out >}}
-
-- To restore the embedded NGINX Controller config database **from the latest automated backup**, run the following command:
-
- ```bash
- /opt/nginx-controller/helper.sh backup restore
- ```
-
-- To restore the embedded config database from **a specific backup file**:
-
- ```bash
- /opt/nginx-controller/helper.sh backup restore
- ```
-
- - If you installed the embedded config database on a **local volume**, the backup files are located in `/opt/nginx-controller/postgres_data/`.
-
- - If you installed the embedded config database on an **NFS volume**, follow the steps in [(NFS) Copy Config Database Backup to Local Volume for Restoration]({{< ref "/controller/admin-guides/backup-restore/backup-restore-embedded-config-db.md#nfs-copy-config-database-backup-to-local-volume-for-restoration" >}}) to download the backup file to your local volume, and then use the `helper.sh` script to restore from it.
-
-
-
-
-
----
-
-## Get NGINX Plus Repository Key and Certificate
-
-To install NGINX Plus as a data plane for NGINX Controller, you need to have the NGINX repository key and certificate files.
-
-{{< deprecated >}}Using the helper.sh script to download your NGINX Plus certificate and key bundle is deprecated in in NGINX Controller v3.9.{{< /deprecated >}}
-
-{{< call-out "note" >}}If you're running NGINX Controller v3.10+, you can use the REST API to [Download the NGINX Plus Cert and Key Bundle]({{< ref "/controller/admin-guides/install/get-n-plus-cert-and-key.md" >}}). {{< /call-out>}}
-
-If you're running NGINX Controller 3.9 or earlier, use the `helper.sh` script to extract the NGINX repository key and certificate files:
-
-```bash
-/opt/nginx-controller/helper.sh repository-cred [-c|--cert ] [-k|--key ]
-```
-
-{{< call-out "important" >}}
-
-Make sure that you've [uploaded your license in NGINX Controller]({{< ref "licensing-controller.md" >}}) first before running the `helper.sh repository-cred` command to extract the repository files.
-
-{{< /call-out >}}
-
-
-
-| Options | Description |
-|----------|-------------|
-| `-c` \| `--cert` | Creates a certificate called ``. The default file name is `nginx-repo.crt` in the current directory.|
-| `-k` \| `--key` | Creates a key called ``. The default file name is `nginx-repo.key` in the current directory. |
-
-
-
----
-
-## Update SMTP Settings
-
-Use the `helper.sh` script to change the SMTP address; port; TLS; sender; and optionally, the username and password.
-
-``` bash
-/opt/nginx-controller/helper.sh configsmtp [auth] [username] [password]
-```
-
-For example:
-
-``` bash
-/opt/nginx-controller/helper.sh configsmtp 192.0.2.0 25 false noreply@example.com true user1
-```
-
-
-
-| Options | Description |
-|----------|-------------|
-| `address` | The host name or IP address of the SMTP server. |
-| `port` | The port of the SMTP server. |
-| `tls` | `true` or `false`. Set to `true` to require SSL for connections to the SMTP server. |
-| `from` | Sender's email address. |
-| `auth` | `true` or `false`. Set to `true` to authenticate when connecting to the SMTP server. |
-| `username` | The username to use for access to the SMTP server. |
-| `password` | The password to use for access to the SMTP server. |
-
-
-
-### Environment Variables
-
-We strongly recommend that you use environment variables, especially for passwords, to prevent exposing sensitive information in system processes (for example, `ps`, `top`) and the bash history.
-
-You use these SMTP environment variables with NGINX Controller:
-
-| Environment Variables | Description |
-|----------|-------------|
-| `CTR_SMTP_HOST` | The host name or IP address of the SMTP server. |
-| `CTR_SMTP_PORT` | The port of the SMTP server.|
-| `CTR_SMTP_TLS` | `true` or `false`; Set to `true` to require SSL for connections to the SMTP server. |
-| `CTR_SMTP_FROM` | Sender's email address. |
-| `CTR_SMTP_AUTH` | `true` or `false`; Set to `true` to authenticate when connecting to the SMTP server. |
-| `CTR_SMTP_USER` | The username to use for access to the SMTP server. |
-| `CTR_SMTP_PASS` | The password to use for access to the SMTP server. |
-
-For example:
-
-``` bash
-CTR_SMTP_HOST=192.0.2.0 \
-CTR_SMTP_PORT=25 \
-CTR_SMTP_TLS=false \
-CTR_SMTP_FROM=noreply@nginx.test \
-CTR_SMTP_AUTH=true CTR_SMTP_USER=user1 CTR_SMTP_PASS= \
-/opt/nginx-controller/helper.sh configsmtp
-```
-
-
-
----
-
-## Update Database Settings
-
-Use the `helper.sh` script to change the external config database address; port; and optionally, the username, password, and certificate authentication. However, if your current installation uses an internal config database, then these settings are read-only and cannot be modified using the `helper.sh` script (password and certificates will be automatically rotated with each Controller update).
-
-``` bash
-/opt/nginx-controller/helper.sh configdb [username] [password] [ssl] [ca] [cert] [key]
-```
-
-For example:
-
-``` bash
-/opt/nginx-controller/helper.sh configdb 192.0.2.1 5432 user1 false
-```
-
-
-
-| Options | Description |
-|----------|-------------|
-| `address` | The host name or IP address of config database. |
-| `port` | The port of the database. |
-| `username` | The username to use for access to the config database. |
-| `password` | The password to use for access to the config database. |
-| `ssl` | `true` or `false`. Set to 'true' to require SSL for connections to the config database. |
-| `ca` | CA certificate file path. |
-| `cert` | Certificate file path. |
-| `key` | Key file path. |
-
-
-
-### Environment Variables
-
-We strongly recommend that you use environment variables, especially for passwords, to prevent exposing sensitive information in system processes (for example, `ps`, `top`) and the bash history.
-
-You can use these database environment variables with NGINX Controller:
-
-| Environment Variables | Description |
-|----------|-------------|
-| `CTR_DB_HOST` | The host name or IP address of the config database. |
-| `CTR_DB_PORT` | The port of the config database used for incoming connections. |
-| `CTR_DB_USER` | The username for the account to use for access to the config database; must be provided with password. |
-| `CTR_DB_PASS` | The password for the account to use for access to the config database; must be provided with username. |
-| `CTR_DB_ENABLE_SSL` | `true` or `false`; Set to `true` to require SSL for connections to the config database. |
-| `CTR_DB_CA` | CA certificate file path. |
-| `CTR_DB_CLIENT_CERT` | Certificate file path. |
-| `CTR_DB_CLIENT_KEY` | Key file path. |
-
-For example:
-
-```bash
-CTR_DB_HOST=192.0.2.1 \
-CTR_DB_PORT=5432 \
-CTR_DB_USER=user1 \
-CTR_DB_PASS= \
-CTR_DB_ENABLE_SSL=false \
-/opt/nginx-controller/helper.sh configdb
-```
-
-
-
----
-
-## Update or Replace TLS Certificates
-
-Use the `helper.sh` script to update or replace the TLS certificates that are used to connect to NGINX Controller.
-
-``` bash
-/opt/nginx-controller/helper.sh configtls
-```
-
-
-
-| Options | Description |
-|----------|-------------|
-| `cert_file` | Certificate file path. |
-| `key_file` | Key file path. |
-
-
-
----
-
-## Print NGINX Controller Logs
-
-To print the NGINX Controller logs, enter the following command:
-
-``` bash
-/opt/nginx-controller/helper.sh logs
-```
-
-
-
----
-
-## Add a Custom Logo
-
-The NGINX Controller logo in the user interface is replaceable with a custom logo. The requirements being:
-
-- The logo file is in SVG format.
-- The logo is square in shape.
-
-{{< call-out "note" >}} The above steps modify the logo in the top left corner and in the menu, not the favicon. {{< /call-out >}}
-
-Follow the steps below to replace the logo:
-
-1. Connect to the NGINX Controller host using 'ssh'.
-1. Transfer the logo file to NGINX Controller using one of the following methods:
- 1. Method 1: Download the file using curl after connecting to the host using the command `curl https://example.com/custom-logo.svg`.
- 1. Method 2: Upload the logo to the host using SCP: `scp /local/path/custom-logo.svg user@controller-host:/remote/path`.
- 1. Method 3: Copy/Paste the logo file.
- 1. Copy the logo file to the clipboard before connecting to the host.
- 1. After connecting to the host, paste the file.
-1. Run `helper.sh setlogo ` ( is the name of the SVG file).
-1. Wait for approximately five minutes for the cache to clear and the logo to appear in the user interface.
-1. Re-run the `setlogo` command on each NGINX Controller node. This has to be done after an upgrade or reinstallation.
-
-
-
----
-
-## Create a Support Package
-
-You can create a support package for NGINX Controller that you can use to diagnose issues.
-
-{{< call-out "note" >}}
-You will need to provide a support package if you open a ticket with NGINX Support via the [MyF5 Customer Portal](https://account.f5.com/myf5).
-{{< /call-out >}}
-
-```bash
-/opt/nginx-controller/helper.sh supportpkg [-o|--output ] [-s|--skip-db-dump] [-t|--timeseries-dump ]
-```
-
-
-
-| Options | Description |
-|----------|-------------|
-| `-o` \| `--output` | Save the support package file to ``. |
-| `-s` \| `--skip-db-dump` | Don't include the database dump in the support package. |
-| `-t` \| `--timeseries-dump ` | Include the last `` of timeseries data in the support package (default 12 hours). |
-
-Take the following steps to create a support package:
-
-1. Open a secure shell (SSH) connection to the NGINX Controller host and log in as an administrator.
-
-1. Run the `helper.sh` utility with the `supportpkg` option:
-
- ```bash
- /opt/nginx-controller/helper.sh supportpkg
- ```
-
- The support package is saved to:
-
- `/var/tmp/supportpkg-.tar.gz`
-
- For example:
-
- `/var/tmp/supportpkg-20200127T063000PST.tar.gz`
-
-1. Run the following command on the machine where you want to download the support package to:
-
- ``` bash
- scp @:/var/tmp/supportpkg-.tar.gz /local/path
- ```
-
-### Support Package Details
-
-{{< include "controller/helper-script-support-package-details.md" >}}
-
-
-
-
-
-{{< versions "3.0" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/_index.md b/content/controller/analytics/_index.md
deleted file mode 100644
index 885c42874..000000000
--- a/content/controller/analytics/_index.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-description: Learn about the F5 NGINX Controller Analytics module.
-title: Analytics
-weight: 120
-url: /nginx-controller/analytics/
----
-
diff --git a/content/controller/analytics/alerts/_index.md b/content/controller/analytics/alerts/_index.md
deleted file mode 100644
index 272f87c87..000000000
--- a/content/controller/analytics/alerts/_index.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-description: Learn about F5 NGINX Controller alerts and notifications.
-title: Alerts
-weight: 100
-url: /nginx-controller/analytics/alerts/
----
-
diff --git a/content/controller/analytics/alerts/about-alerts.md b/content/controller/analytics/alerts/about-alerts.md
deleted file mode 100644
index 60a735d32..000000000
--- a/content/controller/analytics/alerts/about-alerts.md
+++ /dev/null
@@ -1,224 +0,0 @@
----
-description: Learn about NGINX Controller Alerts and Notifications.
-nd-docs: DOCS-520
-title: About Alerts
-toc: true
-weight: 100
-type:
-- concept
----
-
-## Overview
-
-The F5 NGINX Controller Analytics module lets you configure alerts and notifications, so you can stay informed about your system and app performance. In this topic, you'll learn about [alerts](#alerts), [alert rules](#alert-rules), and [alert notifications](#alert-notifications).
-
-{{< call-out "note" >}}
-Refer to [Manage Alerts]({{< ref "/controller/analytics/alerts/manage-alerts.md" >}}) to learn how to set up alerts.
-{{< /call-out>}}
-
-## Alerts
-
-An *alert* is generated when the criteria for an alert rule are met.
-All alerts contain the following information:
-
-
-
-| Name | Description |
-|---|---|
-| `started_timestamp` | The time at which the alert was triggered.|
-| `last_checked_timestamp` | The time at which the last alert check occurred.|
-| `started_value` | The value of the alert metric at the time the alert was triggered.|
-| `last_checked_value` | The value of the alert metric when it was last checked.|
-| `dimensions` | The list of dimension values for which the alert was triggered.|
-
-## Alert Rules
-
-An *Alert Rule* defines the conditions that will trigger an alert. NGINX Controller generates names for alert rules automatically. An alert rule consists of the following information:
-
-
-
-| Name | Description |
-|---|---|
-| `name` | A unique identifier for the alert rule.|
-| `display name` | A human-friendly name that helps you identify what the alert rule does. |
-| `metric` | The [metric]({{< ref "/controller/analytics/catalogs/metrics.md" >}}) that you want to monitor.
{{< call-out "note" >}}An alert rule can monitor one metric.{{< /call-out >}}|
-| `operator` | The operator that will be applied to the value of the metric to check if an alert should be triggered. There are two available operators: `le` - less or equal and `ge` - greater or equal.|
-| `threshold` | Defines the value that, when exceeded, will trigger an alert.
{{< call-out "tip" >}}You can find the allowed threshold value(s) for each metric in the **unit** field of the metric's entry in the [Metrics Catalogs Reference]({{< ref "/controller/analytics/catalogs/metrics.md" >}}). Select the "Index" button to access the list of all available metrics and jump directly to that item in the catalog.{{< /call-out >}} |
-| `period` | Defines the time window in which you want to calculate the aggregated metric value.
- The maximum possible time window is `24h`.
- The minimum possible time window is `2m`.|
-| `filter` | Lets you refine the alert rule for a more specific set of metric values, based on dimensions.
If no filter is provided, all collected data will be used when calculating the alert rule status.|
-| `group by` | Groups results according to the specified dimension(s). A separate alert will be triggered for each result group. You can provide multiple dimension names as a comma-separated list.
{{< call-out "note" >}}Using a dimension with a high cardinality of values might result in a high volume of alerts.{{< /call-out >}}|
-| `notification type` | Defines how you want to receive alert notifications. |
-| `email addresses` | A comma-separated list of email addresses that should receive alert notifications.|
-| `mute` | Boolean; turns alert notifications on and off. Set to 'on' to mute notifications. |
-
-If you leave any rule parameter blank, NGINX Controller will take all relevant data for the parameter into account in the alert rule calculation.
-
-Each Alert Rule has a status that describes the current state of the alert rule. It contains the following information:
-
-
-
-
-
-| Name | Description |
-|---|---|
-| `alerts count` | The total number of triggered alerts for the Alert Rule since its creation.|
-| `status: ok` | The rule has not triggered any alerts, or that all triggered alerts have expired.|
-| `status: ongoing` | At least one alert for the alert rule is currently ongoing.|
-| `lastCheckedTimestamp` | The time when the alert rule was last checked successfully.|
-| `lastStartedTimestamp` | The time when alert rule status has changed from 'ok' to 'ongoing'.|
-| `lastExpiredTimestamp` | The time when alert rule status has changed from 'ongoing' to 'ok'.|
-
-
-
-Alert rules work in the following manner:
-
-1. Incoming metric updates are continuously monitored against the set of alert rules.
-2. The most recent metric value is checked against the threshold defined in the alert rule.
-3. If the threshold is met, an alert notification is generated and the rule will continue to be monitored. In the [Alerts Status]({{< ref "/controller/analytics/alerts/manage-alerts.md#view-alert-rule-status" >}}) pane, the alert instance's status will be displayed as "ongoing".
-4. If subsequent metric updates show that the metric no longer violates the threshold for the configured period, the alert expires.
-
-## Alert Notifications
-
-An *Alert notification* is a message either displayed in the NGINX Controller user interface or sent via email. Alert notifications are sent when an alert is triggered or expired, depending on the alert rule criteria.
-
-- The **Notifications** feed contains information about all changes in the system, including alert changes. To access the Notifications feed, select the bell icon next to the **Account Settings** menu.
-- A notification appears in the Notifications feed immediately when an alert is triggered or expires.
-- Alert instance emails notify you when a single alert instance starts or expires.
-
-If you want to stop receiving notifications for an alert rule, but you don't want to delete it, you can [mute the alert rule]({{< ref "/controller/analytics/alerts/manage-alerts.md#mute-or-unmute-an-alert-rule" >}}).
-Likewise, if you want to stop receiving emails for an alert rule, but you do want to continue receiving the user interface notifications, [edit the alert rule]({{< ref "/controller/analytics/alerts/manage-alerts.md#edit-an-alert-rule" >}}) and remove your email address.
-
-{{< call-out "note" >}}If you mute an alert rule while the alert rule status is "ongoing", you will not receive any further alert notifications, including when the alert rule status changes.{{< /call-out >}}
-
-### Email notifications
-
-{{< call-out "important" >}}
-You must [verify your email address]({{< ref "/controller/analytics/alerts/manage-registered-emails.md" >}}) in order to receive alert notification emails.
-{{< /call-out >}}
-
-When an alert rule's conditions are met, NGINX Controller sends an alert email with the subject "[controller-alert] Alert started: " to all of the email addresses that are specified in the alert rule.
-
-If multiple alerts are triggered in a single calculation period, NGINX Controller sends a summary email message that contains all of the alerts for the time period.
-
-When an alert instance expires, NGINX Controller sends a message with subject "[controller-alert] Alert expired: " to all of the email addresses that are specified in the alert rule.
-
-The notification uses the automatically-generated name that was assigned by the system when the rule was created.
-
-NGINX Controller sends summary emails once every hour. These emails contain alerts that have been triggered or expired since the last summary email was sent. If no alerts started or expired in that timeframe, then the summary will not be sent.
-
-### How Many Notifications to Expect
-
-As an example, let's say that you have three instances configured in the NGINX Controller. You want to monitor all three instances based on the `http.request.count` metric.
-
-Assuming that traffic is constantly flowing through all three instances, and the threshold is exceeded for all three, the system will return three alerts (one per instance). In this case, you would receive one email, containing three alert notices, and three user interface notifications.
-
-If the threshold is exceeded for one instance, then you will receive one alert email and one notification in the user interface.
-
-## How Alerts Work
-
-NGINX Controller checks the list of configured alert rules every 30 seconds. Then, it queries the [Metrics API]({{< ref "/controller/analytics/metrics/metrics-api.md" >}}) for the data defined in each alert rule.
-
-The API query uses the following template:
-
-`?names=()&startTime=now-&endTime=now<&additional-alert-rule-parameters>"`
-
-where
-
-- `` is the appropriate [aggregation function]({{< ref "/controller/analytics/metrics/metrics-api.md#aggregations" >}}) for the metric. You can find this information in the [Metrics Catalog Reference]({{< ref "/controller/analytics/catalogs/metrics.md" >}}).
- - `AVG` applies to `gauge` metrics. Gauges are averaged over the time period configured in the alert rule.
- - `MAX` applies to `counter` metrics.
- - `SUM` applies to `incremental` metrics.
-
-- The `` and `` parameters are read from the alert rule configuration.
-- `<&additional-alert-rule-parameters>` e.g. `filter` or `groupBy` parameters read from the alert rule configuration.
-
-NGINX Controller checks the value returned by the Metrics API against the configured threshold, then takes the appropriate action:
-
-
-
-| Conditions | Action |
-|---|---|
-| - threshold is exceeded
- "ongoing" alert does not exist | Triggers new alert. |
-| - threshold is exceeded
- "ongoing" alert exists | Updates existing alert's `last_checked_timestamp` and `last_checked_value`. |
-| - threshold *is not* exceeded
- "ongoing" alert exists | Expires alert.|
-| - threshold *is not* exceeded
- "ongoing" does not exist | No action.|
-
-Next, the alert rule status is updated. Each alert rule will be updated with a new `last_checked_timestamp` and new `status`, if applicable.
-
-Finally, the alert notifications for newly-created or expired alerts will be sent for any rules that are not muted.
-
-{{< call-out "important" >}}
-If the [Metrics API]({{< ref "/controller/analytics/metrics/metrics-api.md" >}}) query does not return any data -- for example, if there was no traffic through the instance and therefore no metric value -- NGINX Controller assumes a value of `0`. In such cases, the threshold will be compared to `0`.
-{{< /call-out >}}
-
-## Alert special cases
-
-### Alerts for the controller.agent.status metric
-
-The `controller.agent.status` is a special metric representing the heartbeat of the NGINX Agent running on the instance.
-The metric is reported every 1 minute by the NGINX Agent to the NGINX Controller and may only have a value of 1 if the NGINX Agent is healthy.
-If the NGINX Agent is unhealthy it is not reporting the heartbeat and effectively no values for the `controller.agent.status` are stored by the NGINX Controller.
-Based on this metric it is possible to create an alert rule and receive notifications whenever the total number of heartbeats reported by a certain NGINX Agent in a recent period is below or equal (or above or equal) certain threshold.
-
-For example, you would like to receive notifications whenever the NGINX Agent availability at any instance is less or equal 70%.
-To achieve that:
-
-1. Create an alert rule for the `controller.agent.status` metric.
-2. Set the period to at least 10 minutes (recommended, to avoid flapping conditions). Heartbeats arrive every minute while the alert status is evaluated every 30 seconds.
-3. Set the threshold to 7 of the NGINX Agent availability (7 heartbeats received in the last 10 min).
-4. Set the operator to below or equal.
-5. Break out by the instance dimension to get notified about the NGINX Agent availability per instance.
-
-## What's Next
-
-- [Create and Manage Alert Rules]({{< ref "/controller/analytics/alerts/manage-alerts.md" >}})
-- [Manage Registered Emails]({{< ref "/controller/analytics/alerts/manage-registered-emails.md" >}})
-- [NGINX Controller REST API Reference]({{< ref "/controller/api/_index.md" >}})
-
-{{< versions "3.13" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/alerts/manage-alerts.md b/content/controller/analytics/alerts/manage-alerts.md
deleted file mode 100644
index 56482ef12..000000000
--- a/content/controller/analytics/alerts/manage-alerts.md
+++ /dev/null
@@ -1,102 +0,0 @@
----
-description: Learn how to view, add, mute, and delete Alerts.
-nd-docs: DOCS-521
-title: Manage Alerts
-toc: true
-weight: 200
-type:
-- concept
----
-
-## Overview
-
-[Alerts]({{< ref "/controller/analytics/alerts/about-alerts.md" >}}) are notifications about the F5 NGINX Controller system and your applications' performance.
-
-[Alert rules]({{< ref "/controller/analytics/alerts/about-alerts.md#alert-rules" >}}) let you specify what you want to be alerted about. This includes which metrics you want to monitor; the trigger conditions and threshold to meet; the instance(s) to monitor; and the email address(es) to use for notifications.
-
-## Add an Alert Rule
-
-To add an alert rule:
-
-1. Open the NGINX Controller user interface and log in.
-1. On the Analytics menu, select **Alerts > Alert Rules**.
-1. Select **Create Alert Rule**.
-1. Define your alert rule by providing the following information:
-
- - Name
- - (Optional) Display Name
- - Metric
- - Condition, Threshold, and Time Period
- - Filter
- - (Optional) Breakout
- - Email Notification Address(es):
-
- - Select the desired address(es) from the list provided, or
- - Select **Manage Email Addresses** to add a new address, then take the steps below:
-
- 1. Select **Add Email Address**.
- 1. Provide the desired email address.
- 1. Select the submit (plus sign) icon.
- 1. Select **Done** to close the Manage Email Addresses panel.
-
- {{< call-out "note" >}}You will need to verify the email address before it can begin receiving alerts.{{< /call-out >}}
-
-1. (Optional) Select **Mute Alert Rule** if you want to create the alert rule but not receive any associated notifications.
-1. Select **Create**.
-
-## View Alerts
-
-To view all **alerts** that are triggered by alert rules:
-
-1. Open the NGINX Controller user interface and log in.
-1. On the Analytics menu, select **Alerts > Alerts**.
-
-All alert rules and triggered alerts are displayed on this page. You can use the search bar to filter the alerts that are displayed.
-
-## Edit an Alert Rule
-
-To edit an alert:
-
-1. Open the NGINX Controller user interface and log in.
-1. On the Analytics menu, select **Alerts > Alert Rules**.
-1. Select the alert rule that you want to edit.
-1. Select the edit (pencil) icon for the alert rule.
-1. Make the desired changes to the alert rule, then select **Save**.
-
-{{< call-out "important" >}}
-When you edit an alert rule, any ongoing alerts which previously met that rule will expire immediately.
-
-If the threshold is still exceeded in the new alert rule configuration, new alerts will be triggered.
-{{< /call-out >}}
-
-## Mute or Unmute an Alert Rule
-
-If you want to stop receiving notifications for an alert rule without deleting it, you can mute it. Likewise, you can unmute alert rules for which you want to resume receiving notifications.
-
-To mute or unmute an alert:
-
-1. Open the NGINX Controller user interface and log in.
-1. On the Analytics menu, select **Alerts > Alert Rules**.
-1. Select the alert rule that you want to mute or unmute.
-1. Select the mute (volume) icon to mute or unmute the alert rule.
-
-## Delete an Alert Rule
-
-To delete an alert rule:
-
-1. Open the NGINX Controller user interface and log in.
-1. On the Analytics menu, select **Alerts > Alert Rules**.
-1. Select the alert rule that you want to delete.
-1. Select the delete (trash can) icon to delete the alert rule.
-1. Select **Delete** in the pop-up box to confirm that you want to proceed.
-
-## What's Next
-
-- Learn more [About Alerts]({{< ref "/controller/analytics/alerts/about-alerts.md" >}})
-- Learn more about [Metrics and Metadata]({{< ref "/controller/analytics/metrics/overview-metrics-metadata.md" >}})
-- Learn more about [Traffic Metrics]({{< ref "/controller/analytics/metrics/overview-traffic-metrics.md" >}})
-- [Manage Registered Emails]({{< ref "/controller/analytics/alerts/manage-registered-emails.md" >}})
-
-{{< versions "3.0" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/alerts/manage-registered-emails.md b/content/controller/analytics/alerts/manage-registered-emails.md
deleted file mode 100644
index e864f4e77..000000000
--- a/content/controller/analytics/alerts/manage-registered-emails.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-description: Learn how to manage the email addresses that receive automatic alert
- notifications.
-nd-docs: DOCS-522
-title: Manage Registered Email Addresses
-toc: true
-weight: 310
-type:
-- concept
----
-
-## Overview
-
-In order to receive email notifications for [Alerts]({{< ref "/controller/analytics/alerts/about-alerts.md" >}}), you need to provide a valid email address and complete the verification process.
-
-{{< call-out "important" >}}
-You will not receive any alert notifications via email until you verify your email address. Any alert notification emails that were triggered by alert rules prior to the email address being verified will not be re-sent.
-{{< /call-out >}}
-
-## List Registered Email Addresses
-
-To find the list of registered email addresses:
-
-1. Open the F5 NGINX Controller user interface and log in.
-1. On the **Analytics** menu, select **Alerts**.
-1. On the **Alert Rules Overview** page, select **Manage Email Addresses**.
-1. All registered email addresses are displayed in the Manage Email Addresses panel. To close the panel, select **Done**.
-
-{{< call-out "important" >}}The **Manage Email Addresses** button is not displayed if you don't have any Alerts configured. If this is the case, you can add a new email address when you [create an alert rule]({{< ref "/controller/analytics/alerts/manage-alerts.md#add-an-alert-rule" >}}).{{< /call-out >}}
-
-## Add a New Email Address
-
-To add a new email address:
-
-1. Open the NGINX Controller user interface and log in.
-1. On the **Analytics** menu, select **Alerts**.
-1. On the **Alert Rules Overview** page, select **Manage Email Addresses**.
-1. In the **Manage Email Addresses** panel:
-1. Select **Add Email Address**.
-1. Provide the desired email address.
-1. Select the submit (plus sign) icon.
-1. Select **Done** to close the Manage Email Addresses panel.
-1. Check your email inbox for a message with the subject `[controller-team] Email verification`.
-1. Click on the link provided in the email to complete the verification process.
-
-## Re-send a Verification Email
-
-To re-send a verification email to a newly-registered email address:
-
-1. Open the NGINX Controller user interface and log in.
-1. On the **Analytics** menu, select **Alerts**.
-1. On the **Alert Rules Overview** page, select **Manage Email Addresses**.
-1. Select the Resend verification (circular arrows) icon to the right of the email address.
-1. Select **Done** to close the Manage Email Addresses panel.
-
-## Remove a Registered Email Address
-
-To remove a registered email address:
-
-1. Open the NGINX Controller user interface and log in.
-1. On the **Analytics** menu, select **Alerts**.
-1. On the **Alert Rules Overview** page, select **Manage Email Addresses**.
-1. On the **Manage Email Addresses** panel, select the Delete email address (trash can) icon to the right of the email address that you want to remove.
-1. In the **Delete Email Address** pop-up window, select **Delete** to confirm.
-1. Select **Done** to close the Manage Email Addresses panel.
-
-{{< versions "3.0" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/alerts/service-now-notifications.md b/content/controller/analytics/alerts/service-now-notifications.md
deleted file mode 100644
index b3c96f2cc..000000000
--- a/content/controller/analytics/alerts/service-now-notifications.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-description: Set up Alerts Integration with ServiceNow. Deprecated in v3.13.
-nd-docs: DOCS-523
-title: ServiceNow Alerts Integration
-toc: true
-weight: 600
-type:
-- how-to
----
-
-## ServiceNow Alert Integration
-
-{{< deprecated >}}
-**The ServiceNow Alert Integration is deprecated in F5 NGINX Controller v3.13.**
-{{< /deprecated >}}
-
-The ServiceNow integration sends all notifications from NGINX Controller to the Incidents table in your ServiceNow account. Follow the steps below to set up the integration.
-
-1. Install Python3 on your machine.
-2. In your ServiceNow instance, go to **System OAuth > Application Registry** and create a new OAuth API endpoint for external clients.
-
- Fill out the form and specify a long refresh token lifespan. Consider aligning the token lifespan with the expiry date of your NGINX Controller license.
-
- {{< call-out "important" >}} The ServiceNow integration will fail once the refresh token expires.{{< /call-out >}}
-
-3. Select the **Configure ServiceNow** button. In the prompt, provide the requested information for the ServiceNow client and select **Save**.
-
- - **ServiceNow Instance** - The instance ID for your ServiceNow account.
- - **Client ID** - Client ID from ServiceNow (from Step 2).
- - **Client Secret** - Client Secret from ServiceNow (from Step 2).
- - **Username** - Your ServiceNow username; this is used to generate the access token and will not be stored.
- - **Password** - Your ServiceNow password; this is used to generate the access token and will not be stored.
- - **Controller host** - The URL of your NGINX Controller instance.
- - **Controller email** - The email that you use to log in to Controller.
- - **Controller password** - The password that you use to log in to Controller.
- - **Controller port** - The port on which NGINX Controller is running; the default is 80.
- - **Company name** - The name of your company; this is used to create the ServiceNow transport.
-
-4. Watch Controller alerts come through as incidents in ServiceNow.
-
- Mapping of Controller Alerts to ServiceNow Priority:
-
- - ('alerts', 'created') → 1
- - ('alerts', 'cleared') → 3
- - ('agent', 'nginx_not_found') → 1
- - ('agent', 'nginx_config_parsing_error') → 1
- - ('ssl_expiration', 'ssl_cert_has_expired') → 1
- - ('ssl_expiration', 'ssl_cert_will_expire') → 2
- - ('agent', 'agent_version_old') → 2
- - ('agent', 'agent_version_obsoleted') → 1
- - ('group_actions', 'group_action_completed') → 3
-
-{{< versions "3.0" "3.13" "ctrlvers" >}}
-
diff --git a/content/controller/analytics/catalogs/_index.md b/content/controller/analytics/catalogs/_index.md
deleted file mode 100644
index 6edb79a50..000000000
--- a/content/controller/analytics/catalogs/_index.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-description: Reference information for F5 NGINX Controller Catalogs.
-title: Catalogs Reference
-weight: 210
-url: /nginx-controller/analytics/catalogs/
----
-
diff --git a/content/controller/analytics/catalogs/dimensions.md b/content/controller/analytics/catalogs/dimensions.md
deleted file mode 100644
index 4ed5ea5b4..000000000
--- a/content/controller/analytics/catalogs/dimensions.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-description: Information about all of the Dimensions collected by F5 NGINX Controller
- Agent.
-nd-docs: DOCS-524
-title: NGINX Controller Dimensions Catalog
-toc: false
-weight: 20
-type:
-- reference
----
-
-{{< dimensions path="/static/ctlr/catalogs/dimensions-catalog.json" >}}
-
-{{< versions "3.0" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/catalogs/metrics.md b/content/controller/analytics/catalogs/metrics.md
deleted file mode 100644
index ff4c9b25b..000000000
--- a/content/controller/analytics/catalogs/metrics.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-description: Information about all of the Metrics collected by F5 NGINX Controller
- Agent.
-nd-docs: DOCS-525
-title: NGINX Controller Metrics Catalog
-toc: false
-weight: 20
-type:
-- reference
----
-
-{{< metrics path="/static/ctlr/catalogs/metrics-catalog.json" >}}
-
-{{< versions "3.0" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/dashboards/_index.md b/content/controller/analytics/dashboards/_index.md
deleted file mode 100644
index 88cfef7a1..000000000
--- a/content/controller/analytics/dashboards/_index.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-description: Learn about F5 NGINX Controller Dashboards.
-title: Dashboards
-weight: 120
-url: /nginx-controller/analytics/dashboards/
----
-
diff --git a/content/controller/analytics/dashboards/application-health-score.md b/content/controller/analytics/dashboards/application-health-score.md
deleted file mode 100644
index 9e27b8b3e..000000000
--- a/content/controller/analytics/dashboards/application-health-score.md
+++ /dev/null
@@ -1,93 +0,0 @@
----
-description: View and understand the Application Health Score for your application.
-nd-docs: DOCS-526
-title: Understanding the Application Health Score
-toc: true
-weight: 20
-type:
-- concept
----
-
-## Overview
-
-When you log in to the F5 NGINX Controller user interface, you will see the **Analytics Dashboard Overview** page. This page contains an Application Health Score (AHS) that reflects your application's performance.
-
-The AHS is a customizable [Apdex-like numerical measure](https://www.apdex.org/) that can be used to estimate the quality of experience for your web application. It lets you configure service-level monitoring for your applications.
-
-You can select any combination of the following three service-level indicators (SLI) to create your AHS:
-
-- Successful requests (selected by default),
-- (Optional) Request time (95th percentile), and
-- (Optional) NGINX Controller Agent availability.
-
-Successful requests are determined according to the total observed average request time (P95) either below the low threshold (100% satisfying) or between the low and high threshold (partially satisfying).
-
-A simplified formula for AHS is as follows:
-
-`AHS = (Successful Requests %) * (Timely Requests %) * (Agent Availability %)`
-
-When you select the Request Time (95th percentile) for inclusion in the AHS, you can set two thresholds for the total observed average request time (P95):
-
-- Low threshold for satisfying requests.
-- High threshold for partially satisfying requests.
-
-If the average request time (P95) for the selected time period is below the low threshold, this is considered as a "100% satisfying" state of requests.
-
-If the request time is above the low threshold and below the high threshold, a "satisfaction ratio" is calculated accordingly.
-Requests above the high threshold are considered to be "0%", or "unsatisfying".
-
-For example: If the low threshold is 0.2s and the high threshold is 1s, a request time greater than 1s would be considered unsatisfying and the resulting score would be 0%.
-
-The algorithm for calculating the AHS is as follows. Here, `T1` represents the low threshold and `T2` represents the high threshold.
-
-```nginx
-successful_req_pct = (nginx.http.request.count - nginx.http.status.5xx) / nginx.http.request.count
-
-if (nginx.http.request.time.pctl95 < T1)
- timely_req_pct = 1
-else
- if (nginx.http.request.time.pctl95 < T2)
- timely_req_pct = 1 - (nginx.http.request.time.pctl95 - T1) / (T2 - T1)
- else
- timely_req_pct = 0
-
-m1 = successful_req_pct
-m2 = timely_req_pct
-m3 = agent_up_pct
-
-app_health_score = m1 * m2 * m3
-```
-
-## Customize the Application Health Score
-
-Take the steps below to customize the Application Health Score (AHS) that displays on the Overview page.
-
-{{< call-out "note" >}}
-By default, the AHS and other metrics on the **Overview** page are calculated for all of the Instances monitored by the Controller Agent.
-{{< /call-out >}}
-
-1. Open the NGINX Controller user interface and log in.
-2. On the **Overview** page, select the Settings (gear) icon in the Application Health Score panel.
-3. In the **Service Level Monitoring** window, define the following:
-
- - (Optional) Create a custom name for the monitor (replaces "Application Health Score").
- - (Optional) Select tags to narrow the data source(s) to a specific Instance or set of Instances.
- - Select the Service Indicators that you want to include in the score calculation.
-
- - Successful requests (selected by default).
- - Request time (95th percentile): Set a low threshold and a high threshold, in seconds.
- - Agent availability.
-
-4. Select **Save**.
-
-## What's Next
-
-- [Overview of metrics and metadata]({{< ref "/controller/analytics/metrics/overview-metrics-metadata.md" >}})
-- [Set up Metrics Collection]({{< ref "/controller/admin-guides/config-agent/configure-metrics-collection.md" >}})
-- [Metrics Catalog Reference]({{< ref "/controller/analytics/catalogs/metrics.md" >}})
-- [Dimensions Catalog Reference]({{< ref "/controller/analytics/catalogs/dimensions.md" >}})
-- [Custom Dashboards]({{< ref "/controller/analytics/dashboards/custom-dashboards.md" >}})
-
-{{< versions "3.0" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/dashboards/custom-dashboards.md b/content/controller/analytics/dashboards/custom-dashboards.md
deleted file mode 100644
index a4cc10730..000000000
--- a/content/controller/analytics/dashboards/custom-dashboards.md
+++ /dev/null
@@ -1,139 +0,0 @@
----
-description: Create custom dashboards to view custom graphs.
-nd-docs: DOCS-527
-title: Create Custom Dashboards
-toc: true
-weight: 20
-type:
-- how-to
----
-
-## Overview
-
-You can use the F5 NGINX Controller user interface to create your own Dashboards populated with customizable graphs of NGINX and system-level metrics.
-
-{{< call-out "note" >}}
-
-- You can add up to 30 Elements to Dashboard.
-- Dashboards are accessible by all Users.
-
-{{< /call-out >}}
-
-## Before You Begin
-
-- [Install the NGINX Controller Agent on instances that you want to monitor]({{< ref "/controller/admin-guides/install/install-nginx-controller-agent.md" >}})
-- [Configure Metrics collection on your NGINX instances]({{< ref "/controller/admin-guides/config-agent/configure-metrics-collection.md" >}})
-
-## Dashboards
-
-In NGINX Controller, you can create dashboards to display custom graphs. Some use cases for custom graphs include the following:
-
-- Checking NGINX performance for a particular application or microservice, for example, based on the URI path
-- Displaying metrics per virtual server
-- Visualizing the performance of a group of NGINX servers, for example, front-end load-balancers or an NGINX edge caching layer
-- Analyzing a detailed breakdown of HTTP status codes per application
-
-When building a custom graph, metrics can be summed or averaged across NGINX servers. By using metric filters, it is possible to create additional "metric dimensions", for example, reporting the number of POST requests for a specific URI.
-
- {{< call-out "note" >}}
-
-The functionality of user-defined dashboards recently changed in NGINX Controller. Some of the functionalities that were present in the
-previous version might not be currently present or work differently. Your old dashboards were not migrated to the new version.
-
- {{< /call-out >}}
-
-## Create a Custom Dashboard
-
-To create a custom dashboard:
-
-1. Open the NGINX Controller user interface and log in.
-2. The first page you will see is the **Analytics Overview** page.
-3. Select the Dashboards tab to see the **My Dashboards** list page.
-4. To create a new dashboard - use **Create** button and provide required information.
-
-### Add a Dashboard Element
-
-To add an Element to a Dashboard:
-
-1. Create a new Dashboard or select the edit icon to edit an existing Dashboard.
-2. Select **Add element** button.
-3. Provide a title.
-4. (Optional) Enter a description of the Element.
-5. Select the type of Element to add:
-
- - **Line chart** displays data for a specific time period
- - **Stat** displays the metric's most recent value
-
-6. Select a metric from the drop-down menu.
-7. Select the aggregation method for the selected metric.
- {{< call-out "note" >}}
-For more information about metrics and supported aggregation methods, see the [Metrics Catalog Reference]({{< ref "/controller/analytics/catalogs/metrics.md" >}}).
- {{< /call-out>}}
-8. (Optional) Add a filter to refine the data. For example, you can limit the data to a specific App or Environment.
-9. (Optional) Select **Add metrics** to add more metrics.
- {{< call-out "note" >}}
-Additional metrics can only be added to a **Line chart** Element.
- {{< /call-out >}}
-10. (Optional) Select the **Override Default Time Settings** option to select a time range for the Element.
-
- - The default time range is the last seven days.
- - You can select a new pre-defined time range or select **Custom time range** to define a new time range.
-
-11. Select **Create** or **Edit** to save your Element settings.
-
-## Filter Metrics
-
-You can use the filtering functionality for NGINX metrics. If you select **Add filter**, you can add multiple criteria to define specific "metric dimensions".
-
-The filter consists of one or more expressions in a form of:
-
-`dimensionName operator value`
-
-where:
-
-- `dimensionName` is a name of the dimension from the dimensions catalog
-- `operator` is a comparison rule (equality, likeliness, etc.)
-- `value` is a value to which we want compare the dimensions value
-
-Filters can be used in conjunction using `AND` or `OR` logical operators. There is no possibility of nesting these expressions.
-
-Filters are used to narrow down the data set presented on the chart/stat. For example, you may not want to display the data for all of your applications, but only for the particular one.
-
-## Limitations
-
-- You are not able to add more than 30 elements to the single dashboard.
-- All dashboards are accessible for all users.
-- Dashboards defined in the old custom dashboards view are not migrated to the new dashboards view.
-
-## Clone a Custom Dashboard
-
-To clone an existing dashboard from the Dashboards page, select the **Clone** icon on a dashboard's row, or select **Clone** from the toolbar above the table (you need to select a dashboard first).
-
-You can also clone a dashboard from the elements view using the **Clone Dashboard** button. This button is not available in "edit" mode, so make sure you finish editing a dashboard before cloning it.
-
-When you clone a dashboard, the new one will have the same display name as the original dashboard + the current date. For example, if you clone the "My system graphs" dashboard, the cloned dashboard's display name will be something like "My system graphs Aug 24, 2021, 14:37:32". You can change the display name later on the Edit Config page.
-
-## Predefined Dashboards
-
-You can find predefined dashboards on the Dashboards page. Predefined dashboards have a special "Read Only" tag, include elements to show the most common metrics, and cover some common cases. The predefined dashboards might be helpful in learning how custom dashboards work. You can clone any of the predefined dashboards and then modify them as needed.
-
-Predefined dashboards cannot be deleted or modified.
-
-{{< call-out "note" >}}
-
-- Predefined dashboards were introduced in NGINX Controller 3.21.
-- If you already have custom dashboards, the predefined ones should appear at the end of the list when default sorting is applied.
-
-{{< /call-out >}}
-
-## What's Next
-
-- [Overview Dashboard]({{< ref "/controller/analytics/dashboards/overview-dashboard.md" >}})
-- [Overview of Metrics and Metadata]({{< ref "/controller/analytics/metrics/overview-metrics-metadata.md" >}})
-- [Set up Metrics Collection]({{< ref "/controller/admin-guides/config-agent/configure-metrics-collection.md" >}})
-- [Metrics Catalog Reference]({{< ref "/controller/analytics/catalogs/metrics.md" >}})
-- [Dimensions Catalog Reference]({{< ref "/controller/analytics/catalogs/dimensions.md" >}})
-
-{{< versions "3.0" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/dashboards/overview-dashboard.md b/content/controller/analytics/dashboards/overview-dashboard.md
deleted file mode 100644
index 2693c0f2b..000000000
--- a/content/controller/analytics/dashboards/overview-dashboard.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-description: Learn about the Dashboards that displays cumulative metrics for your
- NGINX Instances.
-nd-docs: DOCS-528
-title: Analytics Overview
-toc: true
-weight: 10
-type:
-- how-to
----
-
-## Overview
-
-The **Analytics Dashboards** provides an at-a-glance summary of the state of your F5 NGINX infrastructure and your application performance.
-
-## Before You Begin
-
-- [Install the NGINX Controller Agent on Instances that you want to monitor]({{< ref "/controller/admin-guides/install/install-nginx-controller-agent.md" >}})
-
-## Overview Dashboard
-
-When you log in to the NGINX Controller user interface, the **Analytics Overview** page displays first by default. Select the Dashboards tab to see the **My Dashboards** list page. On the **Dashboard Overview** page, you can view the key indicators noted below. By default, the graphs display metrics for the last hour. You can select any of the default time periods -- one hour, four hours, one day, two days, or one week -- to get a better idea of your apps' overall health and performance. To view metrics over longer time periods, you can create a [custom dashboard]({{< ref "/controller/analytics/dashboards/custom-dashboards.md" >}}).
-
-The cumulative [metrics]({{< ref "/controller/analytics/metrics/overview-metrics-metadata.md" >}}) displayed on the **Analytics Overview** page are:
-
-### System Metrics
-
-- [Application Health Score]({{< ref "/controller/analytics/dashboards/application-health-score.md" >}}): the health score for your application.
-- Average CPU: 100 - AVG of the system.cpu.idle (CPU spent in an idle state)
-- Average Memory: AVG of the `system.mem.used` metric
-
-### Application Metrics
-
-- Time to First Byte: AVG of the `client.ttfb.latency.max` metric
-- Bytes In/s (Bytes In per second): RATE of the `http.request.bytes_rcvd` metric
-- Bytes Out/s (Bytes Out per second): RATE of the `http.request.bytes_sent` metric
-
-- Total Requests: SUM of the `nginx.http.request.count` metric.
-- HTTP 5XX Errors: SUM of the `nginx.http.status.5xx` metric.
-- HTTP 4XX Errors: SUM of the `nginx.http.status.4xx` metric.
-- Request time (P95): AVG of the `nginx.http.request.time.pctl95` metric.
-
-- Avg Client Response Latency: AVG of the `client.response.latency.max` metric
-- Avg Upstream Response Latency: AVG of the `upstream.response.latency.max` metric
-- Avg Client Network Latency: AVG of the `client.network.latency.max` metric.
-
-{{< call-out "note" >}}
-
-By default, the metrics are calculated for **all** of your Controller Agent-monitored Instances.
-
-To display metrics for a specific set of hosts (for example, only for "production"), select the gear icon on the Application Health Score panel, then add a tag or tags by which you want to filter the results.
-
-{{< /call-out >}}
-
-## What's Next
-
-- [Overview of metrics and metadata]({{< ref "/controller/analytics/metrics/overview-metrics-metadata.md" >}})
-- [Metrics Catalog Reference]({{< ref "/controller/analytics/catalogs/metrics.md" >}})
-- [Dimensions Catalog Reference]({{< ref "/controller/analytics/catalogs/dimensions.md" >}})
-- [Application Health Score]({{< ref "/controller/analytics/dashboards/application-health-score.md" >}})
-- [Custom Dashboards]({{< ref "/controller/analytics/dashboards/custom-dashboards.md" >}})
-
-{{< versions "3.0" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/data-explorer/_index.md b/content/controller/analytics/data-explorer/_index.md
deleted file mode 100644
index ce3a033f6..000000000
--- a/content/controller/analytics/data-explorer/_index.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-description: Learn about F5 NGINX Controller Data Explorer.
-title: Data Explorer
-weight: 120
-url: /nginx-controller/analytics/data-explorer/
----
-
diff --git a/content/controller/analytics/data-explorer/how-to-use.md b/content/controller/analytics/data-explorer/how-to-use.md
deleted file mode 100644
index bc9471d26..000000000
--- a/content/controller/analytics/data-explorer/how-to-use.md
+++ /dev/null
@@ -1,149 +0,0 @@
----
-description: Use the Data Explorer to examine the metrics that F5 NGINX Controller
- collects.
-nd-docs: DOCS-529
-title: How To Use the Data Explorer
-toc: true
-weight: 20
-type:
-- how-to
----
-
-## Overview
-
-This topic explains how to use the Data Explorer to view the metrics that F5 NGINX Controller collects.
-
-The Data Explorer lets you perform these following tasks:
-
-- Easily switch between contexts, metrics, and dimensions
-- Specify a time range of interest
-- Set the aggregation mode
-- Compare results to previous periods
-- Export the query that's used to generate the charts as a URL, which you can use outside of NGINX Controller
-
-
-
-## Select the Context
-
-To get started with the Data Explorer, you need to select the context for the data you want to view.
-
-1. Open the NGINX Controller user interface and log in.
-1. Select the NGINX Controller menu icon, then select **Analytics > Explorer**.
-1. On the Data Explorer detail page, select a context area -- **Instances**, **Environments**, **Gateways**, or **Apps** -- for which you want to view data.
-
-{{< call-out "note" >}}
-When you access the Data Explorer from other areas of the browser interface, the context is already defined. So, for example, if you select Data Explorer from within the Instances module (**Infrastructure > Instances > Data Explorer**), the data for your instances is displayed. When you switch between contexts, the metrics options, such as `system.cpu.idle` or `system.load.5`, are updated.
-{{< /call-out >}}
-
-
-
-## Select a Resource
-
-When you [select the context](#select-the-context) for the Data Explorer, a list of related resources is shown. If there aren't any related resources for the selected context, you'll see the message "No Data" on the Data Explorer detail page.
-
-{{< call-out "note" >}}
-
-If you don't see a resource in the list, but you expect it to be there, check the [selected metric](#metrics) and the [selected time range](#time-range). When a resource doesn't have the data for the [selected time range](#time-range) it won't be added to the resources list.
-
-{{< /call-out >}}
-
-To view data for a resource, select the resource's name from the resource list.
-
-{{< img src="/ctlr/img/data-explorer_resource.png">}}
-
-## Metrics
-
-The [list of metrics]({{< ref "/controller/analytics/catalogs/metrics.md" >}}) is sorted alphabetically, and you can use the search feature to filter the list. As previously mentioned, the list of metrics depends on the context you've selected for the Data Explorer. For example, if you've chosen Instances for the context, then the list of metrics will be for instances.
-
-{{< img src="/ctlr/img/data-explorer_metric.png">}}
-
-When the selected metric changes, the **Aggregation** and **Group By** selectors are updated correspondingly (as well as the [list of resources](#select-a-resource) and the [Dimensions panel](#dimensions-panel)). Some metrics have different lists of **Aggregation** and **Group By** values. For example, the `http.response_code` dimension, which is a valid **Group By** value for the `http.request.count` metric, is not available for the `nginx.workers.cpu.user` metric because these items are from different contexts and aren't related to each other.
-
-## Aggregation Mode
-
-Use the Aggregation selector -- the Σ symbol with possible values of `AVG`, `MAX`, `MIN`, `RATE`, and `SUM` -- to [aggregate the data]({{< ref "/controller/analytics/metrics/metrics-api.md#aggregations" >}}). The list of possible aggregation values depends on the metrics that's selected.
-
-{{< img src="/ctlr/img/data-explorer_aggregation.png">}}
-
-## Group by Dimension
-
-Use the **Group By** selector to [group the data by a chosen dimension]({{< ref "/controller/analytics/metrics/metrics-api.md#groupby" >}}).
-
-In the following example image, the data for the `bytes_rcvd` metric is grouped by the dimension `http.request_method`, which displays a data series for the HTTP methods `DELETE`, `GET`, `LINK`, and so on.
-
-{{< img src="/ctlr/img/data-explorer_group-by.png">}}
-
-When a **Group By** selection is applied, the chart displays a top-10 data series. For example, let's say you want to check disk usage, so you select the metric `system.disk.total` and `file_path` as the dimension to group by. The chart would then display the top-10 mount points with the highest values. If you have more than 10 mount points, you'll see the top-10 mount points plus an 11th data series that's an aggregation of the rest of the data using the same selection criteria. In other words, you'll see a chart of the 10 most used mount points plus a chart of all the other mount points aggregated into one data series. When a **Group By** dimension is selected, and there are more than 10 dimensions, the 11th data series is named "Other."
-
-{{< call-out "note" >}} When MIN is selected as the aggregation method, the top-10 series are sorted ascending, lowest-to-highest. For all of the other aggregation methods, the top-10 values are sorted descending, highest-to-lowest. {{< /call-out >}}
-
-
-
-## Time Range
-
-Use the time range selector above the chart to select the time range you want to examine. You can specify a custom time range if the predefined options aren't what you need.
-
-The granularity of the data series is based on the selected time range and can vary from 30 seconds to five days to make the chart easier to read.
-
-When you change the time range, the [list of resources](#select-a-resource) is updated correspondingly and it only includes the resources which have the data for the selected time range.
-
-## Compare To
-
-Next to the [time range](#time-range) selector, you'll find the `Compare To` list of options. This list allows you to compare data for the selected time frame with data from an earlier period. For example, you may want to view CPU usage for the last hour and compare the results to the same time from yesterday, last week, or even the previous year.
-
-{{< img src="/ctlr/img/data-explorer_comparison.png">}}
-
-{{< call-out "note" >}}
-
-- When comparison is turned on for a data series, the data have the suffix "Compare" in their names.
-- If there is no data available for a comparison period, the comparison data series is not shown.
-- When a Group By dimension is applied, data comparisons are made only with the top-10 data series and not with the "Other" series, if there is one. See the [Group By](#group-by) section for a discussion of the top-10 and "Other" series.
-{{< /call-out >}}
-
-
-
-## Show Query
-
-On the Data Explorer details page, you can select the **Show Query** button (eye icon) to view the URL that's used to query the Metrics API to get the data you see in the chart. If you copy the query and use it outside of NGINX Controller, you'll get the same data but in JSON format.
-
-The query updates whenever the selection options change. The query doesn't include requests for comparison data.
-
-{{< call-out "note" >}}
-For instructions on how to understand the Metrics API response, refer to the topic [Using the Metrics API]({{< ref "/controller/analytics/metrics/metrics-api#understanding-the-metrics-api-response" >}}).
-{{< /call-out>}}
-
-
-
-## Dimensions panel
-
-On the right of the screen there is a panel with the list of dimensions available for the [selected metric](#metrics).
-
-{{< img src="/ctlr/img/data-explorer_dimensions-drawer.png">}}
-
-Each dimension is presented as a section in which you can expand and see the values for it. The values are aggregated with the [selected aggregation method](#aggregation-mode) for the [selected time range](#time-range). They depend on the following selected parameters:
-
-- [context](#select-the-context)
-- [resource](#select-a-resource)
-- [metric](#metrics)
-- [aggregation](#aggregation-mode)
-- [time range](#time-range)
-
-When one of the parameters changes, you'll see the values for expanded dimensions are also updated.
-
-You can see only top-10 values for each dimension, and based on the [selected aggregation](#aggregation-mode), they are sorted in following ways:
-
-- When MIN is selected as the aggregation method, the top-10 series are sorted ascending, lowest-to-highest.
-- For all of the other aggregation methods, the top-10 values are sorted descending, highest-to-lowest.
-
-{{< call-out "note" >}}
-
-- When the selected metric changes, the list of dimensions may change as well, and some of the dimensions you recently explored may disappear from the panel.
-- This panel was added in NGINX Controller v3.18.
-
-{{< /call-out >}}
-
-
-
-{{< versions "3.17" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/events/_index.md b/content/controller/analytics/events/_index.md
deleted file mode 100644
index 5a1be006d..000000000
--- a/content/controller/analytics/events/_index.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-description: View system events and audit logs.
-title: Events
-weight: 140
-url: /nginx-controller/analytics/events/
----
-
diff --git a/content/controller/analytics/events/view-events.md b/content/controller/analytics/events/view-events.md
deleted file mode 100644
index a2baabfbe..000000000
--- a/content/controller/analytics/events/view-events.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-description: View the audit log of system and user actions.
-nd-docs: DOCS-530
-title: View Events
-toc: true
-weight: 20
-type:
-- how-to
----
-
-## Overview
-
-The Events page shows a log of the system and user actions for F5 NGINX Controller. The logs are organized by event categories and levels, making it easy to identify and review issues.
-
-## View Events
-
-Take the steps below to view NGINX Controller events:
-
-1. Open the NGINX Controller user interface and log in.
-1. On the Analytics menu, select **Events**.
-1. To view additional information about a particular event, select the event from the list to open the details pane.
-
-You can filter the events by typing a keyword in the search box and/or by selecting a time period. You can filter the results further by [Event Categories](#event-categories) or [Event Levels](#event-levels).
-
-## Event Categories
-
-You can select from the following Event Categories:
-
-- Agent Events;
-- Agent Status Events;
-- Controller Events;
-- Audit Events -- a log of all actions performed by NGINX Controller users;
-- Forwarder Notifications -- events emitted by [Data Forwarders]({{< ref "/controller/analytics/forwarders/_index.md" >}})
-- Workload Health Events -- events emitted by the Controller Agent when the health of an upstream server changes;
-
-To view the logs for a specific category, select the category name from the **Event Categories** list.
-
-## Event Levels
-
-Event levels sort events according to their information level: Debug, Info, Error, Warning, and Critical.
-
-To view the logs for a specific level, select the level name from the **Event Levels** list.
-
-{{< versions "3.0" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/forwarders/_index.md b/content/controller/analytics/forwarders/_index.md
deleted file mode 100644
index 4fa75a092..000000000
--- a/content/controller/analytics/forwarders/_index.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-description: Learn how to forward data from F5 NGINX Controller to external services.
-title: Data Forwarders
-weight: 130
-url: /nginx-controller/analytics/forwarders/
----
-
diff --git a/content/controller/analytics/forwarders/forward-analytics-to-datadog.md b/content/controller/analytics/forwarders/forward-analytics-to-datadog.md
deleted file mode 100644
index 660e8eeb6..000000000
--- a/content/controller/analytics/forwarders/forward-analytics-to-datadog.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-description: How to forward Analytics data to Datadog.
-nd-docs: DOCS-531
-title: Forward Analytics Data to Datadog
-toc: true
-weight: 100
-type:
-- tutorial
----
-
-## Overview
-
-Follow the steps in this guide to set up an F5 NGINX Controller Integration that forwards data to [Datadog](https://www.datadoghq.com/).
-
-## Before You Begin
-
-This guide assumes that you are already an active Datadog user. If you haven't already done so, you will need to [install and configure Datadog](https://docs.datadoghq.com/) before you proceed.
-
-You will also need to [Create an Integration]({{< ref "/controller/platform/integrations/datadog-integration.md" >}}) for your Datadog forwarder.
-
-## Create a Forwarder
-
-Take the following steps to create a Forwarder for Datadog:
-
-1. Open the NGINX Controller user interface and log in.
-2. Select the NGINX Controller menu icon, then select **Platform**.
-3. On the **Platform** menu, select **Data Forwarders**.
-4. On the **Data Forwarders** menu, select the **Create Data Forwarder** quick action.
-5. Add a name.
-6. (Optional) Add a display name.
-7. (Optional) Add a description.
-8. Select your **Integration Reference** from the dropdown menu or select **Create New** to create a new Integration.
-9. In the **Collector Type** list, select `DATADOG`.
-10. In the **Source** list, select the type of data to forward: `metrics` or `events`.
-11. In the **Output Format** list, select `DATADOG`.
-12. The **Selector** field consists of the following query parameters (optional):
-
-- `names` (inapplicable for `EVENTS`): The list of metrics names that you want to forward.
-- `excluded_names` (inapplicable for `EVENTS`): The list of metric names that you don't want to forward.
-- `filter`: The conditions to use to refine the metrics or events data.
-- Example usage when selecting metrics: `"names=nginx.*&excluded_names=nginx.upstream.*filter=app='myapp'"`
-- Example usage when selecting events: `"filter=type='security violation' AND app='my-app'"`
-
-13. (Optional) Add additional **Streams** as required using the **Add Stream** button.
-
-{{< call-out "important" >}}
-
-Each metric will be prefixed with a common namespace -- such as "nginx-controller" -- before it is sent to Datadog. This prefix is used by Datadog only and is not applied to any of the internal NGINX Controller metrics. Refer to the [metrics catalog]({{< ref "/controller/analytics/catalogs/metrics.md" >}}) for the full list of valid metric names.
-
-For events, the "nginx-controller" namespace is added to the ["ddsource" key](https://docs.datadoghq.com/api/v1/logs/#send-logs).
-
-{{< /call-out >}}
-
-NGINX Controller events are sent to Datadog as logs and NGINX Controller dimensions are sent as tags. The Forwarder converts the dimension data to comply with the Datadog [tags format](https://docs.datadoghq.com/getting_started/tagging/#defining-tags) prior to forwarding it. In some cases, the original dimension value may be transformed to fit the tag requirements. This includes replacing comma characters (`,`) with semicolons (`;`) to ensure that Datadog will properly handle the incoming payload.
-
-{{< call-out "note" >}}
-
-See the [NGINX Controller Metrics]({{< ref "/controller/analytics/metrics/_index.md" >}}) docs for more information.
-
-{{< /call-out>}}
-
-## Verification
-
-Soon after you create the Datadog forwarder, you can view the selected metrics in Datadog.
-
-1. Log into the [Datadog web interface](https://app.datadoghq.com/).
-2. On the navigation menu, select **Metrics** > **Summary**.
-
-## What's Next
-
-- Refer to [Troubleshooting Forwaders]({{< ref "/controller/support/troubleshooting-forwarders.md" >}}) for tips on resolving common issues.
-
-{{< versions "3.8" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/forwarders/forward-analytics-to-otlp.md b/content/controller/analytics/forwarders/forward-analytics-to-otlp.md
deleted file mode 100644
index e8dcdd18e..000000000
--- a/content/controller/analytics/forwarders/forward-analytics-to-otlp.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-description: How to forward Analytics Metrics to OpenTelemetry Collector.
-nd-docs: DOCS-532
-title: Forward Analytics Metrics to OpenTelemetry Collector
-toc: true
-weight: 201
-type:
-- tutorial
----
-
-## Overview
-
-Follow the steps in this guide to set up an F5 NGINX Controller integration that forwards metrics to OpenTelemetry Collector.
-
-## Before You Begin
-
-This guide assumes that you already have a working instance of any OpenTelemetry Collector.
-
-You will also need to [Create an Integration]({{< ref "/controller/platform/integrations/otlp-integration.md" >}}) for your OpenTelemetry Collector forwarder.
-
-## Create a Forwarder
-
-Take the following steps to create a forwarder for OpenTelemetry Collector:
-
-1. Open the NGINX Controller user interface and log in.
-2. Select the NGINX Controller menu icon, then select **Platform**.
-3. On the **Platform** menu, select **Data Forwarders**.
-4. On the **Data Forwarders** menu, select **Create Data Forwarder**.
-5. Add a name.
-6. (Optional) Add a display name.
-7. (Optional) Add a description.
-8. Select your **Integration Reference** from the dropdown list, or select **Create New** to create a new integration.
-9. In the **Collector Type** list, select `OTLP_HTTP` or `OTLP_GRPC`.
-10. In the **Source** list, select the type of data to forward: `METRICS`.
-11. In the **Output Format** list, select `OTLP`.
-12. The **Selector** field consists of the following query parameters (optional):
-
-- `names`: The list of metrics names that you want to forward.
-- `excluded_names`: The list of metric names that you don't want to forward.
-- `filter`: The conditions to use to refine the metrics data.
-- Example usage when selecting metrics: `"names=nginx.*&excluded_names=nginx.upstream.*&filter=app='myapp'"`
-
-13. (Optional) Select **Add Stream** to add additional streams, as needed.
-
-{{< call-out "important" >}}
-
-Each metric is prefixed with a common namespace -- for example, "nginx-controller" -- before it's sent to OpenTelemetry Collector. This prefix is used only by OpenTelemetry Collector and is not applied to any internal NGINX Controller metrics. Refer to the [metrics catalog]({{< ref "/controller/analytics/catalogs/metrics.md" >}}) for the full list of valid metric names.
-
-We have tested compatability with OTLP collector v0.33.0. We will most likely support versions higher than this, assuming backwards compatability from OTLP.
-
-{{< /call-out >}}
-
-{{< call-out "note" >}}
-
-See the [NGINX Controller Metrics]({{< ref "/controller/analytics/metrics/_index.md" >}}) docs for more information.
-
-{{< /call-out>}}
-
-## What's Next
-
-- Refer to [Troubleshooting Forwaders]({{< ref "/controller/support/troubleshooting-forwarders.md" >}}) for tips on resolving common issues.
-
-{{< versions "3.16" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/forwarders/forward-analytics-to-splunk.md b/content/controller/analytics/forwarders/forward-analytics-to-splunk.md
deleted file mode 100644
index fc62eccf5..000000000
--- a/content/controller/analytics/forwarders/forward-analytics-to-splunk.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-description: How to forward Analytics data to Splunk.
-nd-docs: DOCS-533
-title: Forward Analytics Data to Splunk
-toc: true
-weight: 200
-type:
-- tutorial
----
-
-## Overview
-
-Follow the steps in this guide to set up an F5 NGINX Controller Integration that forwards data to [Splunk](https://www.splunk.com/).
-
-## Before You Begin
-
-This guide assumes that you are already an active Splunk user. If you haven't already done so, you will need to [install and configure Splunk](https://docs.splunk.com/Documentation) before you proceed.
-
-You will also need to [Create an Integration]({{< ref "/controller/platform/integrations/splunk-integration.md" >}}) for your Splunk forwarder.
-
-## Create a Forwarder
-
-Take the following steps to create a Forwarder for Splunk:
-
-1. Open the NGINX Controller user interface and log in.
-1. Select the NGINX Controller menu icon, then select **Platform**.
-1. On the **Platform** menu, select **Data Forwarders**.
-1. On the **Data Forwarders** menu, select the **Create Data Forwarder** quick action.
-1. Add a name.
-1. (Optional) Add a display name.
-1. (Optional) Add a description.
-1. Select your **Integration Reference** from the dropdown menu or select **Create New** to create a new Integration.
-1. In the **Collector Type** list, select `SPLUNK`.
-1. In the **Source** list, select the type of data to forward: `metrics` or `events`.
-1. In the **Output Format** list, select `SPLUNK`.
-1. The **Selector** field consists of the following query parameters (optional):
-
- - `names` (inapplicable for `EVENTS`): The list of metrics names that you want to forward.
- - `excluded_names` (inapplicable for `EVENTS`): The list of metric names that you don't want to forward.
- - `filter`: The conditions to use to refine the metrics or events data.
- - Example usage when selecting metrics: `"names=nginx.*&excluded_names=nginx.upstream.*filter=app='myapp'"`
- - Example usage when selecting events: `"filter=type='security violation' AND app='my-app'"`
-
-1. (Optional) Add additional **Streams** as required using the **Add Stream** button.
-
-{{< call-out "important" >}}
-
-Each metric will be prefixed with a common namespace -- such as `nginx-controller` -- before it is sent to Splunk. This prefix is used by Splunk only and is not applied to any of the internal NGINX Controller metrics. Refer to the [metrics catalog]({{< ref "/controller/analytics/catalogs/metrics.md" >}}) for the full list of valid metric names.
-
-In case of events, the "nginx-controller" namespace will be placed in the ["source" key](https://docs.splunk.com/Documentation/Splunk/8.1.1/Data/FormateventsforHTTPEventCollector#Event_metadata) and sent with each event.
-
-{{< /call-out >}}
-
-{{< call-out "note" >}}
-
-See the [NGINX Controller Metrics]({{< ref "/controller/analytics/metrics/_index.md" >}}) docs for more information.
-
-{{< /call-out>}}
-
-## What's Next
-
-- Refer to [Troubleshooting Forwaders]({{< ref "/controller/support/troubleshooting-forwarders.md" >}}) for tips on resolving common issues.
-
-{{< versions "3.6" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/forwarders/forward-analytics-to-syslog.md b/content/controller/analytics/forwarders/forward-analytics-to-syslog.md
deleted file mode 100644
index f135c3322..000000000
--- a/content/controller/analytics/forwarders/forward-analytics-to-syslog.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-description: How to forward Analytics Events to Syslog.
-nd-docs: DOCS-534
-title: Forward Analytics Events to Syslog
-toc: true
-weight: 201
-type:
-- tutorial
----
-
-## Overview
-
-Follow the steps in this guide to set up a F5 NGINX Controller Integration that forwards events to a syslog server.
-
-## Before You Begin
-
-This guide assumes that you already have a working instance of any syslog server.
-
-If you haven't already done so, you can use an open-source version of [Syslog-NG](https://www.syslog-ng.com/products/open-source-log-management/).
-
-You will also need to [Create an Integration]({{< ref "/controller/platform/integrations/syslog-integration.md" >}}) for your Syslog forwarder.
-
-## Create a Forwarder
-
-Take the following steps to create a Forwarder for Splunk:
-
-1. Open the NGINX Controller user interface and log in.
-1. Select the NGINX Controller menu icon, then select **Platform**.
-1. On the **Platform** menu, select **Data Forwarders**.
-1. On the **Data Forwarders** menu, select the **Create Data Forwarder** quick action.
-1. Add a name.
-1. (Optional) Add a display name.
-1. (Optional) Add a description.
-1. Select your **Integration Reference** from the dropdown menu or select **Create New** to create a new Integration.
-1. In the **Collector Type** list, select `SYSLOG`.
-1. In the **Source** list, select the type of data to forward: `events`. NGINX Controller can forward only `EVENTS` data to syslog.
-1. In the **Output Format** list, select `SYSLOG`.
-1. The **Selector** field consists of the following query parameters (optional):
-
- - `filter`: The conditions to use to refine the metrics or events data.
- - Example usage: `"filter=type='security violation' AND app='my-app'"`
-
-1. (Optional) Add additional **Streams** as required using the **Add Stream** button.
-
-## What's Next
-
-- Refer to [Troubleshooting Forwaders]({{< ref "/controller/support/troubleshooting-forwarders.md" >}}) for tips on resolving common issues.
-
-{{< versions "3.16" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/metrics/_index.md b/content/controller/analytics/metrics/_index.md
deleted file mode 100644
index 841c2b5b5..000000000
--- a/content/controller/analytics/metrics/_index.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-description: Learn about F5 NGINX Controller Metrics.
-title: Metrics
-weight: 150
-url: /nginx-controller/analytics/metrics/
----
-
diff --git a/content/controller/analytics/metrics/metrics-api.md b/content/controller/analytics/metrics/metrics-api.md
deleted file mode 100644
index 900da4362..000000000
--- a/content/controller/analytics/metrics/metrics-api.md
+++ /dev/null
@@ -1,479 +0,0 @@
----
-description: Tips and tricks for using the Metrics API query parameters to refine
- your data.
-nd-docs: DOCS-535
-title: Using the Metrics API
-toc: true
-weight: 50
-type:
-- tutorial
----
-
-## Overview
-
-You can use the F5 NGINX Controller Analytics module to monitor your NGINX instances and evaluate your applications' performance. The [Metrics API]({{< ref "/controller/api/_index.md" >}}) query parameters let you fine-tune your system data based on parameters such as time window, aggregation, time resolution, and filter.
-
-By using different combinations of these query parameters, you can gather information that lets you:
-
-- Identify which of your Apps receives the most traffic -- query for the highest number of requests among all apps.
-- Understand the behavior of your back-end server(s) -- query for upstream latency by instance or location.
-- Monitor your application performance -- filter on HTTP response codes to track the number of successful or failed requests by app and environment.
-- Understand how your App behavior and/or usage changes across version releases -- compare data like the examples above across different versions of your application.
-
-## Usage
-
-You can use the NGINX Controller [Metrics API]({{< ref "/controller/api/_index.md" >}}) to query for desired metric names and fine-tune the data returned based on the following parameters:
-
-- time window (`startTime` and `endTime`)
-- `filter`
-- `resolution`
-- `groupBy`
-- `seriesLimit`
-- `orderSeriesBy`
-- `dimensions`
-
-{{< call-out "note" >}}
-Because NGINX Controller is constantly evolving, these example metrics and dimensions may differ from what you see with your NGINX Controller instance. Some metrics may require pre-configured applications to be visible in the API.
-{{< /call-out >}}
-
-### Understanding the Metrics API Response
-
-The [Metrics API]({{< ref "/controller/api/_index.md" >}}) response consists of query metadata and an array of `metrics` -- one array element for each queried metric.
-
-- The **metric** object includes the queried metric name and an array of data series associated with the metric.
-- The **series** object groups metrics data according to dimension values. The series consists of dimensions (key-value map), timestamps, and the timestamps' metric values.
-
-```json
-{
- "metrics":[
- {
- "name":"http.request.count",
- "series":[
- {
- "dimensions":{
- "app":"app-name",
- "component":"component-name",
- "environment":"environment-name",
- "gateway":"gateway-name",
- "instance":"instance-name"
- },
- "timestamps":[
- "2020-07-01T12:00:00Z"
- ],
- "values":[
- 1000
- ]
- },
- {
- "dimensions":{
- "app":"app-name-2",
- "component":"component-name",
- "environment":"environment-name",
- "gateway":"gateway-name",
- "instance":"instance-name"
- },
- "timestamps":[
- "2020-07-01T12:00:00Z"
- ],
- "values":[
- 2000
- ]
- }
- ]
- }
- ],
- "queryMetadata":{
- "endTime":"2020-07-01T12:00:00.970106672Z"
- }
-}
-```
-
-In the preceding example, there are two data series for the queried metric. The differentiator between the two series is the "app" name. This name is what makes NGINX metrics app-centric: you can easily distinguish metrics based on their dimensions' values, such as an App, Environment, or Gateway name.
-
-You can view the full list of the supported metrics and dimensions, with detailed descriptions, by querying the Catalog API:
-
-```curl
-curl -X GET --cookie "session=" --url "{controller-IP}/api/v1/analytics/catalogs/metrics"
-```
-
-Likewise, you can get a full list of the available dimensions by querying the Catalogs API:
-
-```curl
-curl -X GET --cookie "session=" --url "{controller-IP}/api/v1/analytics/catalogs/dimensions"
-```
-
-This information is also provided in the [Catalogs Reference]({{< ref "/controller/analytics/catalogs/_index.md" >}})).
-
-### Querying the Metrics API
-
-This section provides an overview of each query parameter and examples of using the parameters together to refine your data.
-
-The examples progress from basic usage to more advanced API queries.
-
-#### Names
-
-The `names` parameter is the only required parameter in the [Metrics API]({{< ref "/controller/api/_index.md" >}}).
-
-The following example query returns a response with the last recorded value for the queried metric: `http.request.count`:
-
-```curl
-curl -X GET --cookie "session=" --url "{controller-IP}/api/v1/analytics/metrics?names=http.request.count"
-```
-
-If the dimension values differ, the `series` array in the response will contain multiple items.
-
-It is possible to query the API for several metrics simultaneously. To do so, provide the metric names as a comma-separated list:
-
-```curl
-curl -X GET --cookie "session=" --url "{controller-IP}/api/v1/analytics/metrics?names=http.request.count,http.request.bytes_rcvd"
-```
-
-#### Time Window
-
-To get more than the last recorded value for the queried metric, use the following time window parameters:
-
-- `startTime` indicates the start of the time window to include metrics from (inclusive).
-- `endTime` means the end of the time window to include metrics from (non-inclusive).
-
-There are a few rules to remember when working with time window parameters:
-
-- If you provide an `endTime`, you must also provide a `startTime`;
-- `endTime` must be greater than `startTime`;
-- If you give a `startTime` but don't give an `endTime`, the `endTime` defaults to the current time.
-
-You can define time using the `ISO 8601` format or as an offset (for example, `2020-07-14T13:07:11Z`). An offset is a string that starts with `+` or `-`, followed by a number and a unit of time: `y`, `M`, `w`, `d`, `h`, `m`, or `s`. You can also use `now` to indicate the current timestamp.
-
-The following example request returns all the recorded metric values for the last three hours.
-
-```curl
-curl -X GET --cookie "session=" --url "{controller-IP}/api/v1/analytics/metrics?names=http.request.count&startTime=now-3h"
-```
-
-The following example query contains a fully defined time window:
-
-```curl
-curl -X GET --cookie "session=" --url "{controller-IP}/api/v1/analytics/metrics?names=http.request.count&startTime=now-5h&endTime=2020-07-01T09:00:00Z"
-```
-
-In this case, the response contains metrics from 05:00:00 to 09:00:00 on the 1st of July 2020.
-
-#### Aggregations
-
-Using only `names` and time window parameters will give you the raw data points of metrics values.
-
-To get a more organized response, you can provide an aggregate function for each queried metric: `AVG`, `SUM`, `COUNT`, `MAX`, `MIN`, or `RATE`.
-
-{{< call-out "note" >}}
-In the following definitions, `time period` refers to the `resolution` (if provided) or the difference between the `endTime` and `startTime` (when `resolution` is not provided).
-{{< /call-out >}}
-
-- `AVG` - calculates the average value of the metric data samples over the period
-- `SUM` - calculates the total value of the metric data samples over the period
-- `COUNT` - returns the number of collected data samples of the metric over the period
-- `MIN`/`MAX` - returns the minimal/maximal data sample of the metric from the given period
-- `RATE` - returns an average value of the metric calculated per second (always *per second*, regardless of the provided `resolution`), based on the data available in the given period
-
-{{< call-out "note" >}}
-You must define a `startTime` when using aggregate functions.
-{{< /call-out >}}
-
-{{< call-out "note" >}}
-The list of supported aggregate functions for any particular metric is available in the [Metrics Catalog]({{< ref "/controller/analytics/catalogs/metrics.md" >}})).
-{{< /call-out>}}
-
-For example, the following query returns a single value (per dimension set), which is the sum of the metric values for the last three hours. To get proper values, ensure that the `endTime` is greater than the `startTime`.
-
-```curl
-curl -X GET --cookie "session=" --url "{controller-IP}/api/v1/analytics/metrics?names=SUM(http.request.count)&startTime=now-3h"
-```
-
-It is possible to use aggregated and non-aggregated metrics in a single query. For this query, the [Metrics API]({{< ref "/controller/api/_index.md" >}}) returns a single value per dimension set. That value is the sum of all of the metric's values for the last three hours.
-
-For example:
-
-```curl
-curl -X GET --cookie "session=" --url "{controller-IP}/api/v1/analytics/metrics?names=SUM(http.request.count),http.request.bytes_rcvd&startTime=now-3h"
-```
-
-{{< call-out "important" >}}
-Using AVG aggregation with traffic metrics with the `.total` suffix may cause confusion because traffic metrics are already aggregated. To learn more, refer to the [Overview: Traffic Metrics]({{< ref "/controller/analytics/metrics/overview-traffic-metrics.md" >}})) topics.
-{{< /call-out >}}
-
-#### Resolution
-
-If you want to change the returned data's granularity, you can use `resolution` parameter. This parameter must be used in conjunction with an aggregation function and a time window (at least `startTime` must be provided).
-
-The `resolution` parameter must be a valid duration. The duration is a string that starts with a number, followed by a unit of time: `y`, `M`, `w`, `d`, `h`, `m`, or `s`.
-
-The following example query returns three aggregated metric values. Here, we're asking for the data from last three hours with one-hour granularity:
-
-```curl
-curl -X GET --cookie "session=" --url "{controller-IP}/api/v1/analytics/metrics?names=SUM(http.request.count),&startTime=now-3h&resolution=1h"
-```
-
-There may be situations when the returned resolution is lower than that requested in the query. This has to do with metrics retention periods—the older the metric, the lower the resolution.
-
-If the time window contains metrics with a lower resolution than was queried for, the API downsizes the granularity to the lowest possible value. You will see a warning in the `responseMetadata`:
-
-```json
-"responseMetadata": {
- "warning": "Time window is above 8 days, Resolution is downsized to 300 seconds"
-}
-```
-
-If no `resolution` is provided, the maximum available resolution is returned. This is calculated as `endTime` - `startTime`.
-
-#### Filter
-
-This parameter, as the name indicates, filters results based on the value of dimensions. Filtering by dimension value can help to refine the data that's returned into a more specific set.
-
-The `filter` query consists of one or more predicates in the form of ``, where:
-
-- `` is the name of the dimension;
-- `` is one of the supported operators (`=`, `!=`, `<`, `<=`, `>=` `>`, `in` or `not`);
-- `` is value of the dimension(s) that you want to filter on.
-
-For example, the following query includes a simple filter on the app name. The query returns data for the application named `app1` for the last three hours.
-
-```curl
-curl -X GET --cookie "session=" --url "{controller-IP}/api/v1/analytics/metrics?names=http.request.count&filter=app='app1'&startTime=now-3h"
-```
-
-{{< call-out "tip" >}}
-
-- Predicates can be combined into logical expressions using `OR`, `AND`, and `(` `)`.
-- For matching values, wildcard (`*`) use is supported.
-- We recommend wrapping predicates in single quotes to ensure that the full query string is processed correctly.
-
-{{< /call-out >}}
-
-The following example request uses `filter` with logical expressions:
-
-```curl
-curl -X GET --cookie "session=" --url "{controller-IP}/api/v1/analytics/metrics?names=http.request.count&filter=app='ap*' and environment='prod'&startTime=now-3h"
-```
-
-#### GroupBy
-
-Using filters and aggregation functions may not be enough to allow you to get comprehensive information about a specific application or environment.
-
-The `groupBy` parameter helps to gather results according to the specified dimension(s). You can provide multiple dimension names as a comma-separated list.
-
-{{< call-out "note" >}}
-
-- When using `groupBy`, you must use an aggregate function and a time window (`startTime` must be defined; `endTime` is optional).
-- If a request contains aggregated and non-aggregated metrics, the `groupBy` parameter will apply only to the aggregated metrics.
-
-{{< /call-out >}}
-
-For example, the following query returns data for any application with a name that starts with `ap` in the `prod` environment for the last three hours.
-
-```curl
-curl -X GET --cookie "session=" --url "{controller-IP}/api/v1/analytics/metrics?names=SUM(http.request.count)&groupBy=app,alias&startTime=now-3h"
-```
-
-The API response for the query looks similar to the following:
-
-```json
-{
- "metrics":[
- {
- "aggr": "SUM",
- "name":"http.request.count",
- "series":[
- {
- "dimensions":{
- "app":"app-name",
- "alias": "alias1"
- },
- "timestamps":[
- "2020-07-01T12:00:00Z"
- ],
- "values":[
- 1000
- ]
- },
- {
- "dimensions":{
- "app":"app-name-2",
- "component":"alias1"
- },
- "timestamps":[
- "2020-07-01T12:00:00Z"
- ],
- "values":[
- 2000
- ]
- }
- ]
- }
- ],
- "queryMetadata":{
- "endTime":"2020-07-01T12:00:00.970106672Z"
- }
-}
-```
-
-The API returns the data for the last three hours grouped by `app` and `alias` dimensions. Unlike other queries, the API only returns those dimensions that have been selected in `groupBy`. However, the series of different dimension values are still distinguished.
-
-#### SeriesLimit and OrderSeriesBy
-
-There are cases when you might want to view only a specific data series (for example, "Top-5"). To query the API for a particular series of data, you can define the `seriesLimit` and `orderSeriesBy` query parameters.
-
-- `seriesLimit` sets an upper limit on the number of series returned.
-- `orderSeriesBy` sorts the series values according to the order specified:
-
- - Must consist of two tokens -- an aggregate function and a sort order. For example, `SUM DESC`, `MIN ASC`, and so on.
- - Can be used only in combination with `seriesLimit`.
-
-When you specify a `seriesLimit`, the response always includes one other series with an `all` metric. This series aggregates the metric values of all the series that are not included in the result. If the total number of series returned is greater than the limit specified in the query parameter, an additional series named `other` is returned. This series aggregates the metrics values of the series outside of the specified limit.
-
-{{< call-out "note" >}}
-When using `seriesLimit`, you can only specify one metric name in the `names` parameter and one `groupBy` parameter.
-{{< /call-out >}}
-
-**Example 1**
-The following example request uses `seriesLimit` to restrict the data returned to five series:
-
-```curl
-curl -X GET --cookie "session=" --url "{controller-IP}/api/v1/analytics/metrics?names=SUM(http.request.count)&groupBy=app&seriesLimit=5&startTime=now-3h&resolution=5m
-```
-
-The response contains data for the last three hours, grouped by the `app` and `alias` dimensions. Unlike the other example queries, in this example, the API returns just those dimensions that have been selected in `groupBy`. Each dimension and its corresponding values are provided as distinct items in a series.
-
-**Example 2**
-The following example query uses both `seriesLimit` and `orderSeriesBy`:
-
-```curl
-curl -X GET --cookie "session=" --url "{controller-IP}/api/v1/analytics/metrics?names=SUM(some.metric.name)&groupBy=someDimension&seriesLimit=5&orderSeriesBy=MAX DESC&startTime=now-1d&endTime=now&resolution=5m
-```
-
-**Example 3**
-Building on the previous examples, here we use `seriesLimit` and `orderSeriesBy` to get the top-5 URIs with the highest number of bytes received for a specific App and Environment:
-
-```curl
-curl -X GET --cookie "session=" --url "{controller-IP}/api/v1/analytics/metrics?names=SUM(http.request.bytes_rcvd)&startTime=now-1h&filter=app='app1' AND environment='qa'&groupBy=http.uri&seriesLimit=5&orderSeriesBy=MAX DESC
-```
-
-In this case, the API returns five data series for the last hour ordered by MAX value in descending order for bytes received per URL, where the data is related to the application `app1` deployed on the environment `prod`.
-
-Together, these parameters are particularly useful for refining data. The `seriesLimit` says how many series should be returned, `orderSeriesBy` parameter defines the criteria for ordering series.
-
-#### Dimensions
-
-You can use the `dimensions` query parameter to specify which dimension(s) should be included in each metric series' response.
-
-Dimensions not specified in the query parameter will not be included in the response. This may result in some series having the same dimension set but being returned as separate list items.
-
-The following example returns results for the specified metric, where `dimensions=environment`:
-
-```curl
-curl -X GET --cookie "session=" --url "{controller-IP}/api/v1/analytics/metrics?names=SUM(http.request.count)&dimensions=environment&startTime=now-3h
-```
-
-If you have multiple Apps, the response looks similar to the following example:
-
-```json
-{
- "metrics":[
- {
- "aggr": "SUM",
- "name":"http.request.count",
- "series":[
- {
- "dimensions":{
- "environment":"prod"
- },
- "timestamps":[
- "2020-07-01T12:00:00Z"
- ],
- "values":[
- 1000
- ]
- },
- {
- "dimensions":{
- "environment":"prod"
- },
- "timestamps":[
- "2020-07-01T12:00:00Z"
- ],
- "values":[
- 2000
- ]
- }
- ]
- }
- ],
- "queryMetadata":{
- "endTime":"2020-07-01T12:00:00.970106672Z"
- }
-}
-```
-
-If `dimensions` and `groupBy` parameters are both used, the list of provided `dimensions` must be a subset of the list provided in `groupBy`.
-
-The following example uses `dimensions` with `groupBy`:
-
-```curl
-curl -X GET --cookie "session=" --url "{controller-IP}/api/v1/analytics/metrics?names=SUM(http.request.count)&groupBy=app,location&dimensions=app&startTime=now-3h&resolution=5m
-```
-
-The `dimensions` parameter also lets you omit the dimensions from the response altogether. To do so, define `dimensions` as an empty list (`dimensions=`).
-
-This results in several data series for the `http.request.count` metric without any dimensions being visible. That is not useful on its own; however, if you combine the empty `dimensions` parameter with metric aggregation, you will receive a single series with aggregated values.
-
-For example, the following example query sums all the values in all of the series of the `http.request.count` metric for the past three hours using the default `resolution`.
-
-```curl
-curl -X GET --cookie "session=" --url "{controller-IP}/api/v1/analytics/metrics?names=SUM(http.request.count)&startTime=now-3h&dimensions=
-```
-
-The response looks similar to the following example:
-
-```json
-{
- "metrics":[
- {
- "aggr": "SUM",
- "name":"http.request.count",
- "series":[
- {
- "dimensions":{},
- "timestamps":[
- "2020-07-01T12:00:00Z",
- "2020-07-01T12:00:30Z",
- "2020-07-01T12:01:00Z",
- "2020-07-01T12:01:30Z",
- ...
- ],
- "values":[
- 3000,
- 2500,
- 2800,
- 1900,
- ...
- ]
- }
- ]
- }
- ],
- "queryMetadata":{
- "endTime":"2020-07-01T15:00:00Z"
- }
-}
-```
-
-{{< call-out "important" >}}
-You cannot use `dimensions` with the `seriesLimit` parameter.
-{{< /call-out >}}
-
-## What's Next
-
-- [Metrics Reference]({{< ref "/controller/analytics/catalogs/metrics.md" >}}))
-- [Dimensions Reference]({{< ref "/controller/analytics/catalogs/dimensions.md" >}}))
-- [Create Custom Dashboards]({{< ref "/controller/analytics/dashboards/custom-dashboards.md" >}}))
-
-{{< versions "3.0" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/metrics/overview-metrics-metadata.md b/content/controller/analytics/metrics/overview-metrics-metadata.md
deleted file mode 100644
index 5f22c4722..000000000
--- a/content/controller/analytics/metrics/overview-metrics-metadata.md
+++ /dev/null
@@ -1,79 +0,0 @@
----
-description: Understanding how the F5 NGINX Controller Agent collects and reports
- metrics and metadata.
-nd-docs: DOCS-536
-title: 'Overview: Metrics and Metadata'
-toc: true
-weight: 20
-type:
-- reference
----
-
-## Overview
-
-The data that F5 NGINX Controller collects can be divided into two categories:
-
-- **System metrics**: Data collected from the NGINX Plus API, the NGINX log files, and NGINX process state.
-- **Traffic metrics**: Data related to processed traffic, with the ability to distinguish the Application, API endpoint, or Environment that traffic is directed through.
-
-{{< call-out "note" >}}
-The key difference between system and traffic metrics is that traffic metrics are pre-aggregated for each time period.
-{{< /call-out >}}
-
-Metrics are published at a regular interval of 60 or 30 seconds for system and traffic metrics, respectively.
-
-This topic gives an overview of the traffic metrics. Also known as "app-centric" metrics, traffic metrics contain information that lets you easily identify the App to which the data applies.
-
-{{< call-out "note" >}}
-Refer to [View traffic metrics]({{< ref "/controller/analytics/metrics/view-traffic-metrics.md" >}}) for instructions on how to view traffic metrics using the [NGINX Controller REST API]({{< ref "/controller/api/_index.md" >}}).
-{{< /call-out>}}
-## Metadata and Metrics That Are Reported
-
-The NGINX Controller Agent collects the following types of data:
-
-- **NGINX metrics.** The Agent collects NGINX-related metrics using the NGINX Plus API, and by monitoring the NGINX log files and NGINX process state.
-- **AVRD metrics.** AVRD sends app-centric data, so each metric has assigned dimensions like "application name" or "gateway". These metrics are related to processed traffic (for example, the number of bytes sent to a particular URL/endpoint).
-- **NGINX configuration.** After the initial installation, the NGINX configuration is uploaded to the NGINX Controller server. Configuration updates are also uploaded to the NGINX Controller server.
-- **System metrics.** These are key metrics describing the system. For example: CPU usage, memory usage, network traffic, etc.
-- **NGINX metadata.** These describe your NGINX instances, and include package data, build information, the path to the binary, build configuration options, and so on. NGINX metadata also includes the NGINX configuration elements.
-- **System metadata.** These are the basic information about the OS environment where the Agent runs. For example, the hostname, uptime, OS flavor, and other data.
-
-For the full list of metrics, see the [Metrics Catalog Reference]({{< ref "/controller/analytics/catalogs/metrics.md" >}})
-
-## Metrics Collection and Reporting Process
-
-The Agent mostly uses Golang's [gopsutil](https://github.com/shirou/gopsutil) to collect OS metrics.
-
-While the Agent is running on the host, it collects metrics at regular 20-second intervals. Metrics then are downsampled and sent to the Controller server once per minute. The Agent reports metadata to the NGINX Controller server every minute. Changes to the metadata can be examined using the Controller user interface.
-
-NGINX Controller stores historical metrics data in an analytics database. Metrics are aggregated and rolled-up as follows:
-
-- Data not older than 8 days are stored with best possible resolution (usually 1 min).
-- Data older than 8 days but not older than 30 days are stored with 5 min resolution.
-- Data older than 30 days but not older than 15 months are stored with 1 hour resolution.
-- Data older than 15 months are stored with 1 day resolution.
-
-### Parsing and Analyzing NGINX Configuration Files
-
-NGINX configuration updates are reported only when a configuration change is detected.
-
-The Agent checks the Controller server every 30 seconds for pending NGINX configuration changes. When changes are pending, the changes are applied and the NGINX is reloaded. Because the configuration is managed in the Controller server, the entire configuration is written to a single `nginx.conf` file.
-
-If the Agent cannot reach the Controller server to send the accumulated metrics, it continues to collect metrics and sends them to the Controller server as soon as connectivity is re-established. The maximum amount of data that can be buffered by the Agent is about 2 hour's worth of data.
-
-The Agent is able to automatically find all relevant NGINX configuration files, parse them, extract their logical structure, and send the associated JSON data to the Controller Server for further analysis and reporting.
-
-To parse SSL certificate metadata, the NGINX Controller Agent uses standard `openssl`(1) functions. SSL certificates are parsed and analyzed only when the corresponding [Agent settings]({{< ref "/controller/admin-guides/config-agent/configure-the-agent.md#default-agent-settings" >}}) are turned on. SSL certificate analysis is `off` by default.
-
-## Troubleshooting
-
-Most metrics are collected by the Agent without requiring the user to perform any additional setup. For troubleshooting instructions, see [Troubleshooting NGINX Controller Metrics]({{< ref "/controller/support/troubleshooting-controller.md" >}}).
-
-## What's Next
-
-- [Set up Metrics Collection]({{< ref "/controller/admin-guides/config-agent/configure-metrics-collection.md" >}})
-- [Metrics Reference]({{< ref "/controller/analytics/catalogs/metrics.md" >}})
-
-{{< versions "3.0" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/metrics/overview-traffic-metrics.md b/content/controller/analytics/metrics/overview-traffic-metrics.md
deleted file mode 100644
index 4a6aad116..000000000
--- a/content/controller/analytics/metrics/overview-traffic-metrics.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-description: Understanding how traffic metrics are collected, aggregated, and reported.
-nd-docs: DOCS-537
-title: 'Overview: Traffic Metrics'
-toc: true
-weight: 100
-type:
-- concept
-- reference
----
-
-## Overview
-
-The data that F5 NGINX Controller collects can be divided into two categories:
-
-- **System metrics**: Data collected from the NGINX Plus API, the NGINX log files, and NGINX process state.
-- **Traffic metrics**: Data related to processed traffic, with the ability to distinguish the Application, API endpoint, or Environment that traffic is directed through.
-
-{{< call-out "note" >}}
-The key difference between system and traffic metrics is that traffic metrics are pre-aggregated for each time period.
-{{< /call-out >}}
-
-Metrics are published at a regular interval of 60 or 30 seconds for system and traffic metrics, respectively.
-
-This topic gives an overview of the traffic metrics. Also known as "app-centric" metrics, traffic metrics contain information that lets you easily identify the App to which the data applies.
-
-{{< call-out "note" >}}
-Refer to [View traffic metrics]({{< ref "/controller/analytics/metrics/view-traffic-metrics.md" >}}) for instructions on how to view traffic metrics using the [NGINX Controller REST API]({{< ref "/controller/api/_index.md" >}}).
-{{< /call-out>}}
-
-## Available traffic metrics
-
-- `client.latency.{total | max | min | count}`
-- `client.network.latency.{total | max | min | count}`
-- `client.request.latency.{total | max | min | count}`
-- `client.ttfb.latency.{total | max | min | count}`
-- `client.response.latency.{total | max | min | count}`
-- `upstream.network.latency.{total | max | min | count}`
-- `upstream.header.latency.{total | max | min | count}`
-- `upstream.response.latency.{total | max | min | count}`
-- `http.request.bytes_rcvd`
-- `http.request.bytes_sent`
-- `http.request.count`
-
-{{< call-out "note" >}}
-Refer to the [NGINX Controller Metrics Catalog]({{< ref "/controller/analytics/catalogs/metrics.md" >}}) for details about these and the other metrics that NGINX Controller reports.
-{{< /call-out>}}
-
-## Calculating traffic metrics
-
-As traffic flows through a configured application, NGINX Controller collects the traffic-related data. With heavy traffic, the number of single, distinguishable metrics can be challenging to discern. For this reason, the metric values are aggregated.
-
-The aggregation happens every publish period -- this period is stored in the `aggregation_duration` dimension, and is usually 30 seconds -- and is based on metric dimensions.
-
-Metrics are aggregated using four aggregation functions:
-
-- **SUM** for `http.request.bytes_rcvd`, `http.request.bytes_sent` and all metrics with `.total` suffix.
-- **MAX** for metrics with `.max` suffix.
-- **MIN** for metrics with `.min` suffix.
-- **COUNT** for metrics with `.count` suffix.
-
-### Example
-
-To better understand how metrics are aggregated, consider the following example:
-
-Imagine you have one application configured with one URI (recorded in the `http.uri` dimension of each traffic-related metric). In the last 30 seconds, a user queried that URI five times. The `client.request.latency` values for the requests were: 1 ms, 2 ms, 3 ms, 4 ms, and 5 ms.
-
-The final metric values returned by the Metrics API will be:
-
-- `http.request.count` = 5
-- `client.request.latency.total` = 15 ms
-- `client.request.latency.max` = 5 ms
-- `client.request.latency.min` = 1 ms
-- `client.request.latency.count` = 5
-
-{{< versions "3.0" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/metrics/view-traffic-metrics.md b/content/controller/analytics/metrics/view-traffic-metrics.md
deleted file mode 100644
index d7f0acbe2..000000000
--- a/content/controller/analytics/metrics/view-traffic-metrics.md
+++ /dev/null
@@ -1,104 +0,0 @@
----
-description: How to view the traffic metrics gathered by NGINX Controller Analytics.
-nd-docs: DOCS-538
-title: View Traffic Metrics
-toc: true
-weight: 150
-type:
-- how-to
-- tutorial
----
-
-## Overview
-
-This topic explains how to use the [NGINX Controller REST API]({{< ref "/controller/api/_index.md" >}})
- to view traffic metrics.
-
-{{< call-out "note" >}}
-Refer to [Overview: Traffic Metrics]({{< ref "/controller/analytics/metrics/overview-traffic-metrics.md" >}}) to learn how NGINX Controller collects, aggregates, and reports traffic metrics.
-{{< /call-out>}}
-
-## Before You Begin
-
-To view traffic metrics, first confirm that you've correctly configured NGINX Controller.
-
-The following resources should have the status `Configured`:
-
-- [Environment]({{< ref "/controller/services/manage-environments.md" >}})
-- [Gateway]({{< ref "/controller/services/manage-gateways.md" >}})
-- [App and Component]({{< ref "/controller/app-delivery/manage-apps.md" >}})
-
-Initially, the graphs will display `No data yet`, and querying the Metrics API for traffic metrics will result in an empty response. As soon as the Component starts to receive traffic, the traffic-related data will be displayed in the graphs and the [Dashboards]({{< ref "/controller/analytics/dashboards/overview-dashboard.md" >}}) in the NGINX Controller user interface and will be returned in API responses.
-
-{{< call-out "note" >}}
-If traffic stops flowing to a resource (for example, an Application or Component), then no traffic metrics will be available for the resource.
-{{< /call-out >}}
-
-## View Traffic Metrics Using the REST API
-
-- To view the full list of metrics and dimensions, send a GET request to the `/analytics/catalogs/metrics` endpoint:
-
- ```curl
- curl -X GET --cookie "session=" --url "{Controller-FQDN}/api/v1/analytics/catalogs/metrics"
- ```
-
-- To view a detailed description for a metric, send a GET request to the `/analytics/catalogs/metrics/{metricName}` endpoint:
-
- ```curl
- curl -X GET --cookie "session=" --url "{Controller-FQDN}/api/v1/analytics/catalogs/metrics/client.latency.total"
- ```
-
-- Likewise, to view the full list of available dimensions, send a GET request to the `/analytics/catalogs/dimensions` endpoint:
-
- ```curl
- curl -X GET --cookie "session=" --url "{Controller-FQDN}/api/v1/analytics/catalogs/dimensions"
- ```
-
-{{< call-out "note" >}}
-Refer to the [Catalogs Reference]({{< ref "/controller/analytics/catalogs/_index.md" >}}) for information about all of the dimensions and metrics collected by NGINX Controller.
-{{< /call-out>}}
-
-## Example REST API Queries for Traffic Metrics
-
-Because traffic metrics are already aggregated, you should be careful about using the Metrics API for aggregations.
-
-### Example 1
-
-Goal: Retrieve the total number of requests for the last 3 hours:
-
-```curl
-curl -X GET --cookie "session=" --url "{Controller-FQDN}/api/v1/analytics/metrics?names=SUM(http.request.count)&startTime=now-3h"
-```
-
-The Metrics API returns a single value per dimension set. That value is the sum of the aggregated values (in 30s intervals) for the last 3 hours.
-
-### Example 2
-
-Goal: Retrieve an average value of max client latencies for my app -- let's call it `app1` -- for the last day:
-
-```curl
-curl -X GET --cookie "session=" --url "{Controller-FQDN}/api/v1/analytics/metrics?names=AVG(client.latency.max)&startTime=now-24h&filter=app='app1'"
-```
-
-### Example 3
-
-{{< call-out "important" >}}
-Because traffic metrics are pre-aggregated, using AVG aggregation with these metrics isn't recommended.
-{{< /call-out >}}
-
-Imagine you have one application configured with one URI (recorded in the `http.uri` dimension of each traffic-related metric). In the last 30 seconds, a user queried that URI 5 times. The `client.request.latency` values for each request were: 1 ms, 2 ms, 3 ms, 4 ms, 5 ms.
-
-The final metric values returned by the Metrics API will be:
-
-- `client.request.latency.total` = 15 ms
-- `client.request.latency.count` = 5
-
-The following query returns the average `client.request.latency.total = 15`, as you have one aggregated sample with value 15.
-
-```curl
-curl -X GET --cookie "session=" --url "{Controller-FQDN}/api/v1/analytics/metrics?names=AVG(client.request.latency.total)&startTime=now-24h"
-```
-
-{{< versions "3.0" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/analytics/view-app-security-analytics.md b/content/controller/analytics/view-app-security-analytics.md
deleted file mode 100644
index ee33ecfaa..000000000
--- a/content/controller/analytics/view-app-security-analytics.md
+++ /dev/null
@@ -1,272 +0,0 @@
----
-description: How to view App Security Analytics.
-nd-docs: DOCS-539
-title: View App Security Analytics
-toc: true
-weight: 500
-type:
-- concept
-- reference
----
-
-## Overview
-
-When App Security flags or blocks a request made to an App Component as a security violation, it generates an App Security event.
-You can use the F5 NGINX Controller web interface or the REST API to view these events or their related statistics (measures). Metrics reflect the number of requests and bytes flagged or blocked. You can use the Security Violation Dimensions to help understand and interpret the analytics data.
-
-For descriptions of Security Metrics and Events Dimensions, refer to [About App Security]({{< ref "/controller/app-delivery/security/concepts/what-is-waf.md" >}}) page.
-
-## View App Security Analytics
-
-You can use the NGINX Controller user interface or the REST API to view App Security Analytics. You can use this data to get a quick, high-level understanding of how the App Security module processes requests to an App.
-
-1. Open the NGINX Controller user interface and log in.
-2. On the Navigation Bar, select **Services**.
-3. On the Services Menu, select **Apps**.
-4. On the Apps Overview page, select the App name link.
-5. Select **Security Analytics** under the Analytics sub-menu.
-
-## View Security Analytics for Components
-
-To view Security Analytics for individual Components, take the steps below.
-
-1. Open the NGINX Controller user interface and log in.
-2. On the Navigation Bar, select **Services**.
-3. On the Services Menu, select **Apps**.
-4. On the Apps Overview page, select the App name link.
-5. Select **Components** from the menu. Select the Component name link.
-6. Select **Security Analytics** under the Analytics sub-menu.
-
-### View App Security Events
-
-To view app security events:
-
-1. Open the NGINX Controller user interface and log in.
-2. On the Navigation Bar, select **Services**.
-3. On the Services Menu, select **Apps**.
-4. On the Apps Overview page, select the App name link.
-5. Select **Security Events** under the Analytics sub-menu.
-
-### View Security Events for Components
-
-To view the security events for components, take the following steps:
-
-1. Open the NGINX Controller user interface and log in.
-2. On the Navigation Bar, select **Services**.
-3. On the Services Menu, select **Apps**.
-4. On the Apps Overview page, select the App name link.
-5. Select **Components** from the sub-menu. Select the Component name link.
-6. Select **Security Events** under the Analytics sub-menu.
-
-## Example REST API Queries for App Security Metrics
-
-Requests which App Security has rejected or allowed:
-
-```curl
-https://{{host}}/api/v1/analytics/metrics?
- startTime=0&
- endTime=now&
- names=sum(http.request.count)&
- groupBy=request_outcome&
- resolution=30m
-```
-
-Possible request outcomes are:
-
-- Passed: WAF allowed the request
-- Rejected: WAF blocked the request
-
-To get request counts based on how App Security processed the traffic:
-
-```curl
-https://{{host}}/api/v1/analytics/metrics?
- startTime=0&
- endTime=now&
- resolution=5m&
- names=sum(http.request.count)&
- groupBy=request_outcome_reason&
- filter=(
- app='shopping' and
- environment='prod' and
- component='app-component')
-```
-
-| **request_outcome_reason values** | **Description** |
-|--------------------------------|-----------------|
-| \ | App Security did not process the traffic (in other words, App Security is not enabled). All events with this request_outcome_reason value should have a request_outcome `PASSED`.|
-| SECURITY_WAF_OK | App Security processed the traffic and no violations are found. All events with this request_outcome_reason value should have a request_outcome of `PASSED`.|
-| SECURITY_WAF_FLAGGED | App Security allowed the request, but it was flagged for review. All events with this request_outcome_reason value should have a request_outcome of `PASSED`.|
-| SECURITY_WAF_VIOLATION | App Security identified one or more violations and rejected the request. All events with this request_outcome_reason value should have a request_outcome of `REJECTED`.|
-
-If you feel App Security is blocking too many requests, you can turn on monitor-only mode.
-
-### Security Violation Events
-
-You can use Security Violation Events to investigate violations identified by App Security for requests made to an App Component. Follow the steps below to view the Security Events:
-
-1. Open the NGINX Controller user interface and log in.
-2. Select the NGINX Controller menu icon, then select **Analytics**.
-3. On the **Analytics Menu**, select **Component**.
-
-You can use the following example Events requests to collect App Security Analytics data by using the NGINX Controller REST API:
-
-- To view ‘security violation’ Events:
-
- ```curl
- GET https://{{host}}/api/v1/analytics/events?
- startTime=0&
- endTime=now&
- filter=(
- category='security violation')
- ```
-
-- To get security violation details based on the Support ID seen on the request blocking page:
-
- ```curl
- GET https://{{host}}/api/v1/analytics/events?
- startTime=0&
- endTime=now&
- filter=(
- category='security violation' and
- waf.support_id='1880765231147185611')
- ```
-
-- To get all events where WAF rejected to investigate:
-
- ```curl
- GET https://{{host}}/api/v1/analytics/events?
- startTime=0&
- endTime=now&
- filter=(
- category='security violation' and
- request_outcome='REJECTED')
- ```
-
-- To get all events where WAF flagged to investigate:
-
- ```curl
- GET https://{{host}}/api/v1/analytics/events?
- startTime=0&
- endTime=now&
- filter=(
- category='security violation' and
- request_outcome_reason='SECURITY_WAF_FLAGGED')
- ```
-
-- To get all events where WAF has rejected or flagged to review:
-
- ```curl
- GET https://{{host}}/api/v1/analytics/events?
- startTime=0&
- endTime=now&
- filter=(
- category='security violation' and
- request_outcome_reason in ('SECURITY_WAF_VIOLATION','SECURITY_WAF_FLAGGED'))
- ```
-
-- To get all events where WAF has rejected or flagged for a specific App Component:
-
- ```curl
- GET https://{{host}}/api/v1/analytics/events?
- startTime=0&
- endTime=now&
- filter=(
- category='security violation' and
- request_outcome_reason in ('SECURITY_WAF_VIOLATION','SECURITY_WAF_FLAGGED') and
- app='shopping' and
- environment='prod' and
- component='app-component')
- ```
-
- {{< call-out "tip" >}}
-To get all Events, remove the Environment, App, and Component filters from the request call.
- {{< /call-out >}}
-
-- To find requests flagged by App Security’s violation rating algorithm as a possible or likely threat:
-
- ```curl
- GET https://{{host}}/api/v1/analytics/events?
- startTime=0&
- endTime=now&
- filter=(
- category='security violation' and
- request_outcome_reason = 'SECURITY_WAF_FLAGGED' and
- waf.violation_rating in ('POSSIBLE_ATTACK','MOST_LIKELY_ATTACK') and
- app='shopping' and
- environment='prod' and
- component='app-component')
- ```
-
- {{< call-out "important" >}}
-This is important if you are using App Security WAF monitoring only mode. You can use it to understand the type of threats WAF believes should be blocked.
- {{< /call-out >}}
-
-- To get Events that have triggered a specific signature-based violation by signature id:
-
- ```curl
- GET https://{{host}}/api/v1/analytics/events?
- startTime=0&
- endTime=now&
- filter=(
- category='security violation' and
- waf.signature_ids ='*200000098*' and
- app='shopping' and
- environment='prod' and
- component='app-component')
- ```
-
- The substring search using wildcards or ‘IN’ operand should be used because each signature might be part of various combinations of signatures triggered by App Security per request.
-
-- To get Events that have triggered a specific a signature-based violation by signature id:
-
- ```curl
- GET https://{{host}}/api/v1/analytics/events?
- startTime=0&
- endTime=now&
- filter=(
- category='security violation' and
- waf.signature_names IN ('DIRECTORY_TRAVERSAL') and
- app='shopping' and
- environment='prod' and
- component='app-component')
- ```
-
- The substring search using wildcards or ‘IN’ operand should be used because each signature might be part of various combinations of signatures triggered by App Security per request.
-
-- To get Events that triggered a particular attack type:
-
- ```curl
- GET https://{{host}}/api/v1/analytics/events?
- startTime=0&
- endTime=now&
- filter=(
- category='security violation' and
- waf.attack_types='*Non-browser Client, Abuse of Functionality*' and
- app='shopping' and
- environment='prod' and
- component='app-component')
- ```
-
- The substring search using wildcards or ‘IN’ operand should be used because each signature might be part of various combinations of attack types triggered by App Security per request.
-
-- To get Events from a remote address (client IP)
-
- ```curl
- GET https://{{host}}/api/v1/analytics/events?
- startTime=0&
- endTime=now&
- filter=(
- category='security violation' and
- http.remote_addr='172.18.71.147' and
- app='shopping' and
- environment='prod' and
- component='app-component')
- ```
-
-## Related Pages
-
-- [About App Security]({{< ref "/controller/app-delivery/security/concepts/what-is-waf.md" >}})
-
-{{< versions "3.11" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/api-management/_index.md b/content/controller/api-management/_index.md
deleted file mode 100644
index 91312bebd..000000000
--- a/content/controller/api-management/_index.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-description: Tasks for deploying and managing your APIs.
-title: API Management
-weight: 155
-url: /nginx-controller/api-management/
----
-
diff --git a/content/controller/api-management/manage-apis.md b/content/controller/api-management/manage-apis.md
deleted file mode 100644
index 5c7a389aa..000000000
--- a/content/controller/api-management/manage-apis.md
+++ /dev/null
@@ -1,505 +0,0 @@
----
-description: Use the F5 NGINX Controller API Manager to add APIs and control how your
- APIs are exposed and consumed.
-nd-docs: DOCS-569
-title: Manage Your APIs
-toc: true
-weight: 110
-type:
-- tutorial
----
-
-## Overview
-
-The F5 NGINX Controller API Management module provides full life cycle management for your APIs. This document provides a walkthrough of the steps needed to create, version, and publish your API using the NGINX Controller API Management module. When you have completed this guide, you should have the following resources:
-
-- An **API Definition**, which stores a collection of related API resources. It can be thought of as a folder.
-- An **API Version**, which describes a particular API and serves as the data contract. It describes available endpoints and operations on each endpoint and can also include API documentation.
-- A **Published API**, which represents an API Version that has been deployed to an NGINX Plus instance serving as an API Gateway.
-- (Optional) API documentation available via the Developer Portal.
-
-{{< call-out "note" >}}
-
-- You must have an API Management module license installed to complete the steps in this guide.
-- The API Management module is available to users with the predefined [Admin or User Roles]({{< ref "/controller/platform/access-management/manage-roles.md#predefined-roles-and-role-groups" >}}).
-
-{{< /call-out >}}
-
-## Create an API Definition
-
-An API Definition functions as a collection of related API resources.
-
-1. Open the NGINX Controller user interface and log in.
-
-2. Select the NGINX Controller menu icon, then select **Services**.
-
-3. On the **Services** menu, select **APIs**.
-
-4. On the **All APIs** page, select **Create** and choose **API Definition**. Alternatively, you can also select **Create API Definition** from the Quick Actions list.
-
-## Create an API Version
-
-An API Version describes a particular API. It can be thought of as an API specification.
-
-1. Open the NGINX Controller user interface and log in.
-
-2. Select the NGINX Controller menu icon, then select **Services**.
-
-3. On the **Services** menu, select **APIs**.
-
-4. On the **All APIs** page, select **Create** and choose **API Version**. Alternatively, you can also select **Create API Version** from the Quick Actions list.
-
-5. Select an existing **API Definition** under which to group the API Version or select **Create New** to add a new **API Definition**.
-
-6. Choose how you would like to describe the API:
-
- 1. [OpenAPI specification](#import-an-openapi-specification)
-
- 2. [Configure manually](#define-api-resources-manually)
-
- 3. [WSDL file](#import-a-web-services-description-language-wsdl-file) (Currently only supports unauthenticated, unencrypted traffic)
-
-7. Provide a version. If a version isn't provided, the default version `unspecified` is used.
-
-8. (Optional) Provide a display name.
-
-9. (Optional) Provide a description.
-
- {{< call-out "note" >}}
-
- If your API specification includes a description, that text populates this field automatically when you [add your OpenAPI spec](#import-an-openapi-specification).
-
- {{< /call-out >}}
-
-10. (Optional) Add tags.
-
-### Import an OpenAPI Specification
-
-The APIM module supports import of a valid OpenAPI v3 specification formatted as valid JSON or YAML.
-
-{{< call-out "note" >}}
-
-If your API spec includes documentation elements, the "Enable documentation" option is selected automatically. You do not need to take any additional steps to document your API.
-
-{{< /call-out >}}
-
-**To import your spec by uploading a file:**
-
-1. Select **OpenAPI Specification**.
-
-2. Select **Import file**.
-
-3. Drag and drop your file into the upload box, or select **Browse** to find and upload a file.
-
-**To import your spec by copying and pasting:**
-
-1. Select **OpenAPI Specification**.
-
-2. Select **Copy and paste specification text**.
-
-3. Paste or type your API in the space provided.
-
-Once you have imported your API spec, select **Next** to continue to the **Resources** page.
-
-### Define API Resources Manually
-
-Take the steps below to manually add your API resources.
-
-1. Select **Configure Manually**.
-
-2. Select **Next** to continue to the **Resources** page.
-
-3. Select **Add API Resource**.
-
-4. Select the **Match Type** to use for the API resource path.
-
-5. Specify the **Path** for the API resource.
-**Tip**: Path should start with `/`, for example, `/userlookup/{userid}/attributes/{surname}`.
-
-6. Select the HTTP method(s).
-
-7. (Optional) [Document Your API](#document-your-api).
-
-8. Review the API spec that will be submitted to create the **API Version**.
-
-9. Select **Submit** to save the **API Version**.
-
-### Document Your API
-
-Follow the steps below to document your API.
-
-{{< call-out "note" >}}
-
-API documentation must follow the OpenAPI 2.0/3.0 Specification.
-
-If you uploaded an API spec that contains documentation, you don't need take any further steps to document your API.
-
-{{< /call-out >}}
-
-{{< call-out "tip" >}}
-
-Skip to step 6 if you're continuing from the [Define API Resources Manually](#define-api-resources-manually) section.
-
-{{< /call-out >}}
-
-1. Open the NGINX Controller user interface and log in.
-
-2. Select the NGINX Controller menu icon, then select **Services**.
-
-3. On the **Services** menu, select **APIs**.
-
-4. On the **All APIs** page, select the **API Version** for which you want to create documentation. Click the pencil (edit) button to edit the API Version.
-
-5. Select **Resources**.
-
-6. Select the pencil (edit) icon next to the method or methods that you want to document.
-
-7. Select **Enable Documentation**.
-
-8. Add a summary.
-
-9. (Optional) Add a description.
-
-10. (Optional) Add a request body description.
-
-11. (Optional) Add a sample request.
-
-12. Specify whether the request body is required.
-
-13. To add a parameter, select **Add Parameter**.
-
-14. Provide the parameter name.
-
-15. (Optional) Provide a parameter description.
-
-16. Select the parameter type.
-
-17. Select the parameter value.
-
-18. (Optional) Specify whether the parameter is required.
-
-19. To add a response, select **Add Response**.
-
-20. Provide the HTTP Response status code.
-
-21. Provide a description.
-
-22. (Optional) Provide a sample response in JSON format.
-
-23. Select **Next** to review the API spec that will be submitted to update the **API Version**.
-
-24. Select **Submit** to save the **API Version**.
-
-### Import a Web Services Description Language (WSDL) file
-
- {{< call-out "caution" >}}
-
-Currently, only HTTP is supported for SOAP-REST proxy traffic. Traffic will be unauthenticated and unencrypted, and as a result will be vulnerable to several security risks. It should be treated as a beta/preview feature.
-
- {{< /call-out >}}
-
-The APIM module supports importing a WSDL file that describes a SOAP service.
-
-**To import your spec by uploading a file:**
-
-1. Select **WSDL File**.
-
-2. Select **Import file**.
-
-3. Drag and drop your file into the upload box, or select **Browse** to find and upload a file.
-
-**To import your spec by copying and pasting:**
-
-1. Select **WSDL file**.
-
-2. Select **Copy and paste WSDL text**.
-
-3. Paste or type your API in the space provided.
-
-Once you've imported your API spec, select **Next** to continue to the **Resources** page. Note that you need to submit the API spec before you can modify the **Resources** and **Schema**. Select **Submit** to save the **API Version.**
-
-### Modify Schema and Resources for an API Version created from a WSDL file
-
-Take the following steps to **Edit** add your API Version:
-
-1. On the **All APIs** page, select the **API Version** that was created from a WSDL
-
-2. Select **Next** to continue to the **Resources** page.
-
-3. For each **SOAP operation**, choose the appropriate equivalent **REST Method**.
-
-4. (optional) Modify the **Path** for the API resource as desired.
-
- {{< call-out "tip" >}}
-
- Path should start with `/`, for example, `/userlookup/{userid}/attributes/{surname}`.
-
- {{< /call-out >}}
-
-5. Select **Next** to continue to the **Schema** page
-
-6. (Optional) For each JSON schema, modify the **Property** as desired
-
-7. Review the API spec that will be submitted to create the **API Version**.
-
-8. Select **Submit** to save the **API Version**.
-
-## Publish an API
-
-You need at least one of each of the resources listed below to complete this section. If you haven't already created the required resources, you can do so while configuring the Published API.
-
-- [Environment]({{< ref "/controller/services/manage-environments.md" >}})
-
-- [Gateway]({{< ref "/controller/services/manage-gateways.md" >}})
-
-- [App]({{< ref "/controller/app-delivery/manage-apps.md" >}})
-
-- [Identity Provider]({{< ref "/controller/services/manage-identity-providers.md" >}})
-
- (required to add Authentication to the Published API Component).
-
-{{< call-out "tip" >}}
-You can connect one or more [Developer Portals]({{< ref "/controller/api-management/manage-dev-portals.md" >}}) to your Published API to host your API documentation. This can be done either when creating or editing your Published API, or independently via the API Quick Actions menu.
-{{< /call-out >}}
-
-### Add a Published API
-
-1. Open the NGINX Controller user interface and log in.
-
-2. Select the NGINX Controller menu icon, then select **Services**.
-
-3. On the **Services** menu, select **APIs**.
-
-4. On the **All APIs** page, select the **API Version** that you want to publish.
-
-5. Select **Add Published API**.
-
-#### Configure the Published API
-
-On the **Create Published API** *Configuration* page:
-
-1. Select the **API Definition Version** that you want to publish.
-
-2. (Optional) Provide a **Base Path** for the Published API.
-
-3. Specify whether the **Strip Base Path** parameter is required.
-
- {{< call-out "note" >}}
-
- The `Strip Base Path` option modifies the path that is passed from the Gateway to the upstream host. When the option is selected, the base path will be removed from the original request when the request is passed to the upstream host. If the option is not selected, the original request -- including the base path -- is passed from the Gateway to the upstream host.
-
- {{< /call-out >}}
-
-4. Provide a Name and/or Display Name for the Published API.
-
-5. (Optional) Provide a description for the Published API.
-
-6. (Optional) Add tags.
-
-7. Select **Next**.
-
-#### Define the Published API Deployment
-
-For each of the steps below, you can create a new resource for the Published API by selecting the **Create New** link.
-
-On the **Create Published API** *Deployment* page:
-
-1. Select the **Environment** that the Published API belongs to.
-
-2. Select the **App** that the Published API represents.
-
-3. Select the **Gateway(s)** that will expose the Published API.
-
-4. Select the **Dev Portal(s)** that will host documentation for the Published API.
-
-5. Select **Next**.
-
-#### Define the Routing Rules
-
-On the **Create Published API** *Routing* page:
-
-1. Select the **Add New** link to create a new App Component resource for the Published API. The **Create App Component** page has multiple sections.
-
-2. On the **Create App Component** *Configuration* page:
-
- 1. Provide the name for your Component.
-
- 2. (Optional) Provide a Display Name.
-
- 3. (Optional) Provide a Description.
-
- 4. (Optional) Add any desired tags.
-
- 5. (Optional) Select the error response format.
-
- 6. Select **Next**.
-
-3. On the **Create App Component** *Workload Groups* page:
-
- 1. Provide a Workload Group Name.
-
- 2. (Optional) Select a Location. The default Location is 'Unspecified'. This value is applied automatically to "bring your own" (BYO) NGINX Plus instances that were not deployed by NGINX Controller.
-
- 3. Define the backend workload URIs.
-
- 4. (Optional) Define the DNS Server.
-
- 5. (Optional) Select the Load Balancing Method. The default value is `Round Robin`.
-
- 6. (Optional) Select the Session Persistence Type (applicable only to Web Components).
-
- 7. (Optional) Select the Desired Proxy Settings (applicable only to Web Components).
-
- 8. Select **Next**.
- {{< call-out "note" >}}
-
- - Refer to the [Manage Locations]({{< ref "/controller/infrastructure/locations/manage-locations.md" >}}) topic for more information.
-
- - Refer to the [NGINX Plus Admin Guide](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/) for more information about the available options.
-
- {{< /call-out>}}
- {{< call-out "tip" >}}
- Hover your pointer over the info icon for each setting to learn about the expected values and requirements.
- {{< /call-out >}}
-
-
-4. On the **Create App Component** *Rate Limiting* page:
-
- 1. Enable Rate Limiting and select a **Key**.
-
- 2. Select options for Rate and Units.
-
- 3. (Optional) Select options for Excess Request Processing and Ignore Initial N Requests.
-
- 4. Select options for Reject Status Code.
-
- 5. Select **Next**.
-
-5. On the **Create App Component** *Authentication* page:
-
- 1. Select **Add Authentication**.
-
- 2. Select an [**Identity Provider**]({{< ref "/controller/services/manage-identity-providers.md" >}}).
-
- 3. Select a **Credential Location**.
-
- 1. (Optional) Enable [**Conditional Access**]({{< ref "/controller/services/available-policies.md#conditional-access" >}}).
-
- 4. Select **Next**.
-
-{{< call-out "important" >}}
-
-The **Advanced Security** features require an *NGINX Controller API Management Advanced Security* license.
-
-{{< /call-out >}}
-
-6. On the **Create App Components** *Advanced Security* page:
-
- 1. (Optional) Select **Enable Web Application Firewall (WAF)** to monitor and block suspicious requests or attacks.
-
- 2. (Optional) Select **Monitor Only** to allow traffic to pass without being rejected. Security events are still generated and metrics are still collected. Refer to [About App Security Analytics]({{< ref "/controller/analytics/view-app-security-analytics.md" >}}) for more information.
-
- 3. (Optional) Add the signature(s) that you want WAF to ignore. You can specify multiple signatures as a comma-separated list.
-
- 4. Select **Next**
-
- {{< call-out "note" >}} Refer to the [Default WAF Policy]({{< ref "/controller/app-delivery/security/concepts/app-sec-default-policy-original.md" >}}) topics to learn more about the default protection provided by NGINX App Protect. {{< /call-out>}}
-
-
-7. On the **Create App Component** *Ingress* page:
-
- 1. (Optional) Set the desired **Client Max Body Size**.
- 2. Select **Next**.
-
- {{< call-out "note" >}}
-
- Refer to the [NGINX module docs](http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size) for more information about this option.
-
- {{< /call-out>}}
-
-
-8. On the **Create App Component** *Monitoring* page:
-
- 1. (Optional) Enable **Health Monitoring** and define the desired Monitoring Request and Response. Health Monitoring is disabled by default.
-
- 2. (Optional) Specify the URI to use in health check requests (applicable only to Web Components). The default is `/`. For TCP/UDP Components, specify the Send string.
-
- 3. (Optional) Specify the port to use when connecting to a server to perform a health check. The server port is used by default.
-
- 4. (Optional) Set the interval to wait between two consecutive health checks. The default is 5 seconds.
-
- 5. (Optional) Specify the number of consecutive passed health checks that must occur for a server to be considered healthy. The default is `1`.
-
- 6. (Optional) Specify the number of consecutive failed health checks that must occur for a server to be considered unhealthy. The default is `1`.
-
- 7. (Optional) Specify the default state for the server. The default state is `HEALTHY`.
-
- 8. (Optional) Specify the starting HTTP status code to match against (applicable only to Web components).
-
- 9. (Optional) Specify the ending HTTP status code to match against (applicable only to Web components).
-
- 10. (Optional) Select whether a response should pass in order for the health check to pass (applicable only to Web components). By default, the response should have status code `2xx` or `3xx`.
-
- 11. Select **Next**.
-
- {{< call-out "note" >}}
-
- Refer to the [NGINX module docs](http://nginx.org/en/docs/http/ngx_http_upstream_hc_module.html#health_check) for more information about these options.
-
- {{< /call-out>}}
-
-9. On the **Create App Component** *Logs* page:
-
- 1. (Optional) Select the logs to enable:
-
- § Error Log
-
- § Access Log
-
- 2. (Optional) Specify the log format to use.
-
- 3. Select **Next**.
-
- {{< call-out "note" >}}
-
- Refer to the [NGINX docs](http://nginx.org/en/docs/http/ngx_http_log_module.html) for more information about these options.
-
- {{< /call-out>}}
-
-9. On the **Create App Component** *Programmability* page:
-
- The following settings are applicable **only to Web components**.
-
- 1. (Optional) Select **Add URI Redirects** and define the desired redirect condition(s).
-
- 2. (Optional) Select **Add URI Rewrite** and define the desired rewrite pattern(s).
-
- 3. (Optional) Select **Add Request Header Modification** and define how to modify the request header.
-
- 4. (Optional) Select **Add Response Header Modification** and define how to modify the response header.
-
- 5. Select **Next**.
-
- {{< call-out "note" >}}
-
- Refer to the [NGINX module docs](http://nginx.org/en/docs/http/ngx_http_rewrite_module.html) for more information about these options.
-
- {{< /call-out>}}
-
- 6. Select **Next** to review the API spec that will be sent to create the App Component.
-
- 7. Drag and drop resources one at a time, or move multiple resources by selecting the checkboxes next to the desired resources, from the **Unrouted** column to the desired Component in the **Components** list. You can use the search bar to narrow down the list.
- **Note:** Resources can be dragged between **Components** and back to the **Unrouted** section either one at a time or by multi-select.
-
- 8. Select **Next** to review the API spec that will be sent to create the Published API.
-
- 9. Select **Submit** to create the Published API.
-
-## Create a Developer Portal
-
-Once you have created an API Definition and a Published API, you can host your API in a Developer Portal.
-
-From the **API Definitions** page, select **Create Dev Portal** from the Quick Actions menu. Then, follow the steps in [Create a Developer Portal]({{< ref "/controller/api-management/manage-dev-portals.md" >}}) to create, customize, and publish your Dev Portal.
-
-{{< versions "3.0" "3.18" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
diff --git a/content/controller/api-management/manage-dev-portals.md b/content/controller/api-management/manage-dev-portals.md
deleted file mode 100644
index 3f3f1aa5d..000000000
--- a/content/controller/api-management/manage-dev-portals.md
+++ /dev/null
@@ -1,138 +0,0 @@
----
-description: Learn how to create and manage Developer Portals for your API documentation.
-nd-docs: DOCS-570
-title: Manage Developer Portals
-toc: true
-weight: 120
-type:
-- tutorial
----
-
-## Overview
-
-You can use F5 NGINX Controller Developer Portals (also called 'Dev Portals') to create and manage beautiful, easy-to-use API reference documentation to support your [Published APIs]({{< ref "/controller/api-management/manage-apis.md#publish-an-api" >}}).
-
-## About Developer Portals
-
-In NGINX Controller, each Dev Portal sits within an Environment. An Environment can contain multiple Dev Portals. You can use the same Dev Portal names across different Environments, which means you can create "test", "dev", and "production" versions of your Dev Portal across the corresponding Environments.
-
-Each Dev Portal is associated with a Gateway, which defines the URI at which users can access the Dev Portal -- for example, `developer.acme.com`. A Gateway for a Developer Portal can be placed on a dedicated Instance, or share an Instance with other Gateway resources.
-
-## Before You Begin
-
-You must complete the steps below before you can create a Developer Portal.
-
-1. [Create an Environment]({{< ref "/controller/services/manage-environments.md" >}}).
-1. [Create a Gateway]({{< ref "/controller/services/manage-gateways.md" >}}) for the Dev Portal.
-
- {{< call-out "tip" >}}
-You can create multiple Dev Portal Gateways on the same Instance. If you do so, be sure to use a unique hostname and port for each. For example:
-
-- Gateway 1's ingress URI is `https://dev-developer.acme.com`.
-- Gateway 2's ingress URI is `https://test-developer.acme.com`. These resources might both have IP addresses and ports that are accessible only from within your private network.
-- Gateway 3's ingress URI is `https://developer.acme.com`. This resource would have a public IP address and be accessible via the internet.
-
-If you create multiple Dev Portal Gateways on the same Instance using the same hostname and port, the Dev Portal configuration will fail.
- {{< /call-out >}}
-
-1. [Create an API Definition]({{< ref "/controller/api-management/manage-apis.md#create-an-api-definition" >}}).
-
- {{< call-out "tip" >}}
-If you choose to [define your API manually]({{< ref "/controller/api-management/manage-apis.md#define-resources-manually" >}}), be sure to [document your API]({{< ref "/controller/api-management/manage-apis.md#document-your-api" >}}).
- {{< /call-out >}}
-
-1. [Create a Published API]({{< ref "/controller/api-management/manage-apis.md#publish-an-api" >}}).
-
- {{< call-out "important" >}}
-You must create an App Component when creating a Published API. You'll [assign routes]({{< ref "/controller/api-management/manage-apis.md#define-the-routing-rules" >}}) from the API Definition to this Component.
-
-Both the Published API and the associated App Component must be successfully created before you can create a Dev Portal.
-
-See [Manage Your APIs]({{< ref "/controller/api-management/manage-apis.md" >}}) and the [troubleshooting](#troubleshoot-dev-portal-publication) section below for more information.
-
-You also have the option to associate Dev Portal(s) in the *Deployment* page when you [Add a Published API]({{< ref "/controller/api-management/manage-apis.md#add-a-published-api" >}}). If you already have a Published API and you want to create a new Dev Portal to host it, complete the tasks described in this guide.
-
- {{< /call-out >}}
-
-## Create a Developer Portal
-
-To create a Dev Portal, take the steps below:
-
-1. Open the NGINX Controller user interface and log in.
-2. Select the NGINX Controller menu icon, then select Services.
-3. On the **Services** menu, select APIs.
-4. On the APIs page, select **Create Dev Portal** from the Quick Actions menu.
-
- {{< call-out "tip" >}}
-If you want to connect one or more Dev Portals to an existing Published API, you should select the **Edit Published API** option. The API Documentation will be published to the selected Dev Portal(s). Refer to the [Define the Published API Deployment]({{< ref "/controller/api-management/manage-apis.md#define-the-published-api-deployment" >}}) section for more information and instructions.
- {{< /call-out >}}
-
-### Configure the Developer Portal
-
-On the **Create Dev Portal** *Configuration* page:
-
-1. Provide a resource name for the Dev Portal.
-2. (Optional) Provide a display name, description, and tags.
-3. Select the desired Environment, or select Create to create a new resource.
-4. Select a Gateway, or select Create to create a new resource.
-5. Select the Published API(s) that you want to host in the Dev Portal.
-6. Select **Next** to move to the **Themes** page.
-
-### Define the Dev Portal Theme
-
-On the **Create Dev Portal** *Themes* page:
-
-1. Select **Brand** to define the following elements:
-
- - **Brand Name**,
- - **Logo**, and
- - **Favicon**
-
-2. Select **Next**.
-3. Set the **Colors** for theme elements. Then, select **Next**.
-4. Set the **Fonts** for the theme. Then, select **Next**.
-5. Review the **API Spec**, then select **Submit**.
-
-> You should now be able to access the Dev Portal via the hostname and port that you assigned to the Dev Portal Gateway.
-
-## View, Edit, or Delete a Developer Portal
-
-To view, edit, or delete a Dev Portal, take the steps below:
-
-1. Open the NGINX Controller user interface and log in.
-2. Select the NGINX Controller menu icon, then select Services.
-3. On the **Services** menu, select APIs.
-4. On the APIs menu, select **Dev Portals**.
-
-To **edit** a Dev Portal:
-
-1. Select the **Edit** icon for the Dev Portal.
-2. Edit the Dev Portal as desired.
-
- - Select **Configure** to update the Dev Portal configurations, including the Environment, Gateway, and Published API.
- - Select **Brand** to customize the **Brand Name** and to upload a **Logo** and **Favicon**.
- - Select **Color** to customize the Dev Portal theme colors.
- - Select **Fonts** to customize the Dev Portal theme fonts.
-
-3. Select **Submit** to save your changes.
-
-To **delete** a Dev Portal, select the **Delete** icon. Then, select **Delete** in the confirmation prompt window.
-
-## Troubleshoot Dev Portal Publication
-
-If the Gateway that the Dev Portal is associated with is in an error state, publishing your Dev Portal will fail. You won't necessarily see an error in the Dev Portals section of the user interface when this happens, but configuration errors in these resources will impact Dev Portal functionality.
-
-- App Component configuration errors are displayed only in the App Component section of the user interface.
-- Published API configuration errors are displayed in the Published APIs section of the user interface, as well as in the Dev Portal.
-- Dev Portal configuration errors are not displayed in the NGINX Controller user interface.
-
-If your Dev Portal failed to publish, check the status of the Gateway first; resolve any issues with the Gateway, then try publishing the Dev Portal again.
-If the issue persists, check the other resources for configuration errors.
-
-## What's Next
-
-- [Learn about Policies]({{< ref "/controller/services/available-policies.md" >}})
-- [Manage Your APIs]({{< relref "./manage-apis.md" >}})
-
-{{< versions "3.7" "3.18" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
diff --git a/content/controller/api/_index.md b/content/controller/api/_index.md
deleted file mode 100644
index 100d0ce46..000000000
--- a/content/controller/api/_index.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-description: Learn how to use the F5 NGINX Controller REST API.
-title: API Reference
-weight: 210
-url: /nginx-controller/api/reference/
----
-
diff --git a/content/controller/api/overview.md b/content/controller/api/overview.md
deleted file mode 100644
index d37acb406..000000000
--- a/content/controller/api/overview.md
+++ /dev/null
@@ -1,122 +0,0 @@
----
-description: Provides information about the F5 NGINX Controller API.
-nd-docs: DOCS-343
-layout: docs
-title: API Overview
-toc: true
-weight: 10
-type:
-- concept
----
-
-## Introduction
-
-The F5 NGINX Controller API is a [REST](https://en.wikipedia.org/wiki/Representational_state_transfer) API that allows you to programmatically manage your NGINX Plus data planes.
-
-NGINX Controller follows an "API-first" approach, which means that all NGINX Controller functionality is exclusively exposed through declarative and resource-oriented APIs. Even the user interface (user interface) uses our REST API! You'll find examples of REST request bodies in the user interface. You can rest assured that the example you see is correct, because that is the call that the user interface is going to make to apply your requested configuration.
-
-## Encoding
-
-All NGINX Controller API endpoints expect and return JSON-formatted data by default.
-When appropriate, the API accepts and returns other media types, such as file uploads or downloads.
-
-All JSON-formatted data is expected to be encoded using UTF-8 as described by the [IETF JSON Spec](https://tools.ietf.org/html/rfc8259).
-If you do not specify a specific media type in an API call, then the API defaults to `"application/json"`. If you specify multiple acceptable media types, the first type that the API supports is chosen for the response. In the event of a request for a media type that the API doesn't support, it returns a "415 Unsupported Media Type" response.
-
-## Object Model
-
-The NGINX Controller API -- as well as the user interface and the product documentation -- is organized into four top-level areas:
-
-- **Analytics**: Enables data visualization for NGINX Controller.
-- **Infrastructure**: Lets you manage your NGINX Plus instances and certain aspects of the host machines on which NGINX Controller and NGINX Plus instances run.
-- **Platform**: Lets you manage NGINX Controller options and configurations, including Users, Roles, Licenses, and Global Settings.
-- **Services**: Lets you manage your applications and APIs.
-
-The diagrams below demonstrate how the different objects at the Service level relate to each other:
-
-1. All Service objects are part of an Environment.
-1. Gateways and Certs can be defined at the Environment level --or-- at the Component Level. The diagram below shows an example of how traffic flows through a Gateway to an App.
-1. Components are child objects that represent the back-end server(s) that host your App or API.
- {{< call-out "note" >}}A Component can represent an application **or** an API. The same Component cannot be used for both App Delivery and API Management.{{< /call-out >}}
-1. Certs can be added to a Gateway or to an individual Component.
-
-{{< img src="/ctlr/img/services-object-model-example.png" alt="Diagram showing the relationship of objects in an Environment within the Services area." >}}
-{{< img src="/ctlr/img/traffic-flow-example-1.png" alt="Example traffic flow through a gateway to app components that represent a back-end application. Certs can be configured at the gateway or at the app component level." >}}
-
-### Permissions
-
-Access to each of these areas is determined by your User Role. Roles grant Users access to specific Environments; Role permission levels define what content you can see ("Read" access) and interact with ("Write" access). Users with Roles that contain "Full" access can interact with all areas.
-
-The diagram below shows a sample System Administrator (or, "SysAdmin") workflow. The SysAdmin user has full administrator permissions, which allows creation of objects in all areas. In this workflow, the SysAdmin user creates an Environment; then creates a Role that has permission to interact with objects in that Environment; and, finally, creates a User. The Role grants the User access to objects in the Environment.
-
-{{< img src="/ctlr/img/netops-workflow.png" alt="Example System Admin workflow" >}}
-
-The diagram below shows a sample deployment workflow. In this workflow, the user - a Deployment Manager - has read and write access to objects in one specific Environment, but no access to other Environments. Within the allowed Environment, the user can create objects or select from objects that were added by a system administrator. In this workflow, the Deployment Manager creates an App and an App Component. Associated objects like Certs and Gateways can be added -- or selected from a list -- when adding the App Component. The configs for load balancing, monitoring, and URI redirects are defined as part of the App Component as well.
-
-{{< img src="/ctlr/img/devops-workflow-simple.png" alt="Example deployment workflow" >}}
-
-{{< call-out "note" >}}
-
-- [Managing Roles & Users]({{< ref "/controller/platform/access-management/manage-users.md" >}})
-
-{{< /call-out>}}
-
-## Authentication
-
-The NGINX Controller API uses session cookies to authenticate requests. The session cookie is returned in response to a `GET /api/v1/platform/login` request. See the Login endpoint in the [NGINX Controller API Reference]({{< ref "/controller/api/_index.md" >}}) documentation for information about session cookie timeouts and invalidation.
-
-{{< call-out "tip" >}}
-You can send a GET request to the login endpoint to find the status of the session token.
-{{< /call-out >}}
-
-For example:
-
-- Login and capture the session cookie:
-
- ```curl
- curl -c cookie.txt -X POST --url 'https://198.51.100.10/api/v1/platform/login' --header 'Content-Type: application/json' --data '{"credentials": {"type": "BASIC","username": "arthur@example.net","password": ""}}'
- ```
-
-- Use the session cookie to authenticate and get the session status:
-
- ```curl
- curl -b cookie.txt -c cookie.txt -X GET --url 'https://198.51.100.10/api/v1/platform/login'
- ```
-
-
-## Resource Types
-
-The NGINX Controller API contains two types of resources: immediately consistent and eventually consistent.
-
-Immediately consistent resources are synchronous. For these resources, any changes you make will be applied at the time the request is received. Requests to modify state using an API write operation (POST, PUT, PATCH or DELETE) result in the transmitted data being stored by the server as state. There is no need to check for progress, success, or failure using an API read operation (GET) for these resources. The original response should communicate if the request was successful.
-
-Eventually consistent resources are asynchronous. For these resources, any changes you request will be applied over time. Requests to modify state using an API write operation (POST, PUT, PATCH or DELETE) result in the transmitted data being stored by the server and messages or events being generated to eventually apply this state. You may check for progress, success, or failure using an API read operation (GET). The original response communicates that the data resulting in instructions was understood by the system.
-
-## Resource Properties
-
-All NGINX Controller API resources contain the following properties:
-
-```json
-{
- "metadata": {
- },
- "desiredState": {
- },
- "currentStatus": {
- }
-}
-```
-
-The `desiredState` property is a representation of the state that you want to apply to the system. The properties within `desiredState` are the API representation of data. While changes to `desiredState` may trigger eventually consistent operations, the object itself is "immediately consistent". Consumers of the API can "read their own writes" and should always be able to retrieve the current desired state, no matter where the system is in the process of applying the state change.
-
-The `currentStatus` property represents the current state of the system. Its purpose is to communicate the progress of achieving eventual consistency to the API consumer. As such, `currentStatus` is a read-only property.
-
-## Versioning
-
-The introduction of backwards-incompatible changes to the NGINX Controller API constitutes a major version change. This will be represented in the NGINX Controller API version string. For example, to use a `v2` API, you would use `https:///api/v2`.
-
-When any NGINX Controller component requires a version change, we will release a new version of the entire API. In other words, you won't see a mix of `v1` and `v2` objects in the same API.
-
-{{< versions "3.0" "latest" "ctrlvers" >}}
-{{< versions "3.18" "latest" "apimvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/api/reference/ctlr-adc-api.md b/content/controller/api/reference/ctlr-adc-api.md
deleted file mode 100644
index 04ead674a..000000000
--- a/content/controller/api/reference/ctlr-adc-api.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-description: Represents the state of the F5 NGINX Controller Application Delivery
- REST API.
-nd-docs: DOCS-1280
-type:
-- reference
-doctypes:
- - reference
-type: redoc
-tags:
- - api
-title: ADC API
-toc: false
-weight: 300
-nd-api-reference: "./nginx-controller/api/reference/ctlr-adc-openapi.json"
----
diff --git a/content/controller/api/reference/ctlr-analytics-api.md b/content/controller/api/reference/ctlr-analytics-api.md
deleted file mode 100644
index 70e1214f6..000000000
--- a/content/controller/api/reference/ctlr-analytics-api.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-description: Represents the state of the F5 NGINX Controller Analytics REST API.
-nd-docs: DOCS-1279
-type:
-- reference
-doctypes:
- - reference
-type: redoc
-tags:
- - api
-title: Analytics API
-toc: false
-weight: 200
-nd-api-reference: "./nginx-controller/api/reference/ctlr-analytics-openapi.json"
----
diff --git a/content/controller/api/reference/ctlr-apim-api.md b/content/controller/api/reference/ctlr-apim-api.md
deleted file mode 100644
index 5add27db2..000000000
--- a/content/controller/api/reference/ctlr-apim-api.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-description: Represents the state of the F5 NGINX Controller API Management REST API.
-nd-docs: DOCS-1281
-type:
-- reference
-doctypes:
- - reference
-type: redoc
-tags:
- - api
-title: APIM API
-toc: false
-weight: 400
-nd-api-reference: "./nginx-controller/api/reference/ctlr-apim-openapi.json"
----
diff --git a/content/controller/api/reference/ctlr-platform-api.md b/content/controller/api/reference/ctlr-platform-api.md
deleted file mode 100644
index 562a3db72..000000000
--- a/content/controller/api/reference/ctlr-platform-api.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-description: Represents the state of the F5 NGINX Controller Platform REST API.
-nd-docs: DOCS-1278
-doctypes:
- - reference
-type: redoc
-tags:
- - api
-title: Platform API
-toc: false
-nd-api-reference: "./nginx-controller/api/reference/ctlr-platform-openapi.json"
----
diff --git a/content/controller/app-delivery/_index.md b/content/controller/app-delivery/_index.md
deleted file mode 100644
index 021e9ba97..000000000
--- a/content/controller/app-delivery/_index.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-description: Tasks for deploying and managing your applications.
-title: Application Delivery
-weight: 152
-url: /nginx-controller/app-delivery/
----
-
diff --git a/content/controller/app-delivery/about-app-delivery.md b/content/controller/app-delivery/about-app-delivery.md
deleted file mode 100644
index 544e54607..000000000
--- a/content/controller/app-delivery/about-app-delivery.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-description: Learn about F5 NGINX Controller Application Delivery concepts.
-nd-docs: DOCS-474
-title: About Application Delivery
-toc: true
-weight: 100
----
-
-## Apps
-
-In F5 NGINX Controller, an App serves as a container for one or more Components. Components represent the backend services that comprise your application. Together, an App and its Components represent the logical partitioning of your application into its composite parts. For example, a Component might correspond to a particular microservice within your application. Each Component you add to an App represents one or more paths via which traffic can reach that microservice.
-
-All Apps and Components live within an [Environment]({{< ref "/controller/services/manage-environments.md" >}}). This means that in order to have access to a particular App, a User needs to have permission to access its Environment. If you need access to an Environment or App, contact your administrator.
-
-## Components
-
-A Component is a child object of an App. Components let you partition an App into smaller, self-contained pieces that are each responsible for a particular function of the overall application. For example, a Component could correspond to a microservice that, together with several other microservices, comprises a complete application.
-
-Each Component contains an ingress definition that includes the fully-qualified domain names (FQDNs) and URIs from clients. These ingress definitions associate incoming requests with a particular path; the certificates that are used for decryption/encryption of HTTPS requests and responses that traverse that path; the backend servers that host the App to which the path delivers the requests; and the rewrites, redirects, and modifications on the requests/responses that occur along the path.
-
-Components can be instantiated on multiple paths corresponding to the placements associated with the Component; these placements are defined within the [Gateway(s)]({{< ref "/controller/services/manage-gateways.md" >}}) referenced in the Component.
-
-## Inherited or Independent Resources
-
-When you configure a Component, you can choose to:
-
-- inherit resources and configurations from the Gateway;
-- create and define new resources and configurations specific to the Component; or
-- use a combination of inherited and Component-specific configurations.
-
-For example, a Gateway's ingress definition might include the URIs for a Service's FQDN(s) and the associated TLS [certificates]({{< ref "/controller/services/manage-certs.md" >}}), while the Component's ingress definition would contain relative URIs for the FQDN defined in the Gateway:
-
-- Gateway Ingress URIs: `www.example.com`
-- Component Ingress URIs: `/about/`, `/docs/`, `/contact/`
-
-Together, the Component's relative paths and the Gateway's FQDN results form the absolute URI for each path (`www.example.com/about/`, `www.example.com/docs/`, and `www.example.com/contact/`).
-
-Likewise, you can configure a Component with its own FQDN and paths, but inherit the TLS certificates from the Gateway. Or, you can configure a Component that doesn't inherit any resources or configurations from the Gateway and uses its own set of definitions.
-
-{{< call-out "note" >}}The ability to add resources, like Certificates, is determined by your account permissions. If you don't have the ability to add new Certs, contact your administrator. {{< /call-out >}}
-
-{{< versions "3.0" "latest" "ctrlvers" >}}
-{{< versions "3.20" "latest" "adcvers" >}}
diff --git a/content/controller/app-delivery/about-caching.md b/content/controller/app-delivery/about-caching.md
deleted file mode 100644
index 6e5f9c005..000000000
--- a/content/controller/app-delivery/about-caching.md
+++ /dev/null
@@ -1,387 +0,0 @@
----
-description: Learn how F5 NGINX Controller handles caching configurations and what
- NGINX cache directives are supported.
-nd-docs: DOCS-339
-title: About Caching
-toc: true
-weight: 200
-type:
-- concept
----
-
-## Overview
-
-The F5 NGINX Controller Application Delivery (AD) module lets you configure content caching by using either the user interface (UI) or the [Components REST API](https://docs.nginx.com/nginx-controller/api/ctlr-adc-api/#tag/Components).
-
-## Basic Caching
-
-NGINX Controller Caching supports [basic caching](https://www.nginx.com/blog/nginx-caching-guide/#How-to-Set-Up-and-Configure-Basic-Caching) via the *disk store* resource.
-
-When you add a disk store to a component, you define the location of the cache on the hard disk. The path you specify for the disk store is the base path under which you want to store the cache files for the component.
-
-{{< call-out "important" >}}
-The directory that you want to use as the cache must already exist and the NGINX process must have read and write permissions to it. Otherwise, NGINX Controller can't create the cached folders and files.
-
-If NGINX Controller can't create the desired cache directory and/or write files to it, the user interface will display an error for the component.
-{{< /call-out >}}
-
-When you use the UI or the REST API to create a single disk store, NGINX Controller adds the following directives to the auto-generated `nginx.conf` file:
-
-- [`proxy_cache_path`](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_path), in the top-level `http` context;
-- [`proxy_cache`](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache), added to the component's `location` block.
-
-You can include NGINX Controller Caching data when creating [custom dashboards]({{< ref "/controller/analytics/dashboards/custom-dashboards" >}}) and [alerts]({{< ref "/controller/analytics/alerts/manage-alerts" >}}) for your applications.
-
-## Cache Splitting
-
-NGINX Controller Caching also supports splitting the cache across multiple directories, which can reside on different hard drives. To split the cache, you need to create a disk store for each desired cache location. The Caching *split config* settings let you determine how NGINX Controller should split the data between the disk stores -- either by percentage or by pattern matching.
-
-The percentage option lets you set the percentage of the cache to store in each location. Pattern matching lets you define where to store cache contents -- like certain file types -- and which cache location should send a response based on the request.
-
-{{< call-out "note" >}}
-Read the [NGINX Caching Guide](https://www.nginx.com/blog/nginx-caching-guide/#Splitting-the-Cache-Across-Multiple-Hard-Drives) to learn more about splitting the cache across multiple hard drives.
-{{< /call-out>}}
-
-When you define a split cache, NGINX Controller adds a `split_clients` configuration block with percentage split or a `map` configuration block with string split to the `http` context of the generated `nginx.conf` file.
-
-## Advanced Caching
-
-As noted earlier in this topic, you can use Caching to manage basic caching use cases.
-To add any of the [`ngx_http_proxy_module`](http://nginx.org/en/docs/http/ngx_http_proxy_module.html) cache directives listed below, use NGINX Controller **Snippets**.
-
-- [`proxy_cache_background_update`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_background_update)
-- [`proxy_cache_bypass`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_bypass)
-- [`proxy_cache_convert_head`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_convert_head)
-- [`proxy_cache_key`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_key)
-- [`proxy_cache_lock`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_lock)
-- [`proxy_cache_lock_age`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_lock_age)
-- [`proxy_cache_lock_timeout`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_lock_timeout)
-- [`proxy_cache_max_range_offset`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_max_range_offset)
-- [`proxy_cache_methods`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_methods)
-- [`proxy_cache_min_uses`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_min_uses)
-- [`proxy_cache_purge`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_purge)
-- [`proxy_cache_revalidate`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_revalidate)
-- [`proxy_cache_use_stale`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_use_stale)
-- [`proxy_cache_valid`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_valid)
-- [`proxy_no_cache`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_no_cache)
-- [`proxy_temp_path`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_temp_path)
-
-In order to enable the collection of app centric caching metrics, NGINX Controller has added a minimal set of APIs to enable and control caching. For more advanced caching features, you can make use of `configSnippets` to configure the directives above.
-
-{{< call-out "note" >}}
-When you enable the temporary path for disk store with `tempPath:ENABLED`, you need to set the temporary path `proxy_temp_path` using the snippets API.
-{{< /call-out >}}
-
-
-{{< call-out "note" >}}
-NGINX Controller does not collect or report metrics for directives configured using Snippets.
-{{< /call-out >}}
-
-## Usage Examples
-
-Each of the examples provided here shows a sample API request and the resulting NGINX config file. These examples are for learning purposes only and are not intended for use in production settings.
-
-### Basic Caching {#basic-caching-example}
-
-The example below shows an excerpt of a REST API request that sets up basic caching. This example defines one server as the cache location.
-
-```json
-"desiredState": {
- "caching": {
- "diskStores": [
- {
- "path": "/tmp/cache-1",
- "maxSize": "5G",
- "minFree": "10k",
- "inMemoryStoreSize": "500M",
- "inactiveTime": "2s"
- }
- ]
- }
-}
-```
-
-The above request modifies the NGINX Controller-generated `nginx.conf` file as follows:
-
-- Adds a `proxy_cache_path` directive for the disk store to the `http` context;
-- Adds a new `proxy_cache` directive to the `location` block for the component.
-
-```Nginx configuration file {hl_lines=[1,14]}
-proxy_cache_path /tmp/cache-1/app_centric_example-env|example-app-1|example-app-component| max_size=5G min_free=10k keys_zone=app_centric_example-env|example-app-1|example-app-component|/tmp/cache-1:500M purger=off;
-
-server {
- server_name test.example.com;
- listen 80;
- status_zone server_5ae404e8-005d-38e8-b355-6d54cb219730;
- set $f5_gateway example-gw;
- f5_metrics_marker gateway $f5_gateway;
- set $f5_environment example-env;
- f5_metrics_marker environment $f5_environment;
- location / {
- error_log /dev/null;
- access_log off;
- proxy_cache app_centric_example-env|example-app-1|example-app-component|/tmp/cache-1;
- set $f5_app example-app-1;
- f5_metrics_marker app $f5_app;
- set $f5_component example-app-component;
- f5_metrics_marker component $f5_component;
- proxy_set_header X-Forwarded-For $remote_addr;
- proxy_set_header Host $host;
- proxy_set_header Connection '';
- proxy_http_version 1.1;
- proxy_pass http://wg-example_http_b4859463-b3bd-4ccb-8442-e21253a50da7;
- }
-}
-```
-
-### Cache Splitting using Percentage and Snippets {#split-percentage-example}
-
-You can set up cache splitting using the Percentage criteria to define the percent of the cache to store in each location.
-
-The example request excerpt below does the following:
-
-- splits the cache across three different storage paths;
-- sets one of the stores -- `/tmp/default` -- as the default;
-- uses the Component `configSnippets.uriSnippets` API to configure the [`add_header`](https://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header) directive, to include `Cache` header with "HIT/MISS/EXPIRED/BYPASS" in the response;
-- uses the Component `configSnippets.uriSnippets` API to set a cache duration time of 1m for all requests using [`proxy_cache_valid`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_valid).
-
-```json
-{
- "desiredState": {
- "configSnippets": {
- "uriSnippets": [
- {
- "directives": [
- {
- "directive": "proxy_cache_valid",
- "args": [
- "any",
- "1m"
- ]
- }
- ]
- }
- ]
- },
- "programmability": {
- "responseHeaderModifications": [
- {
- "action": "ADD",
- "headerName": "X-Cache-Status",
- "headerValue": "$upstream_cache_status"
- }
- ]
- },
- "caching": {
- "splitConfig": {
- "criteriaType": "PERCENTAGE",
- "key": "$request_uri"
- },
- "diskStores": [
- {
- "inMemoryStoreSize": "100m",
- "inactiveTime": "1m",
- "isDefault": false,
- "maxSize": "5G",
- "minFree": "10k",
- "path": "/tmp/hdd1",
- "percentCriteria": "20%"
- },
- {
- "inMemoryStoreSize": "100m",
- "inactiveTime": "10s",
- "isDefault": false,
- "maxSize": "5g",
- "minFree": "10k",
- "path": "/tmp/hdd2",
- "percentCriteria": "50%"
- },
- {
- "inMemoryStoreSize": "100m",
- "inactiveTime": "15s",
- "isDefault": true,
- "maxSize": "2g",
- "minFree": "10k",
- "path": "/tmp/default"
- }
- ]
- }
- }
-}
-```
-
-The above request modifies the `nginx.conf` file as follows:
-
-- Adds the `split_clients` directive to the `http` context, reflecting the criteria defined for `diskStores`;
-- Adds a `proxy_cache_path` directive for each disk store to the `http` context;
-- Adds a new `proxy_cache` variable -- `$cache_` -- to the `location` block for the component;
-- Adds the `proxy_cache_valid` and `add_header` directives to the `location` block for the component.
-
-```Nginx configuration file {hl_lines=["1-8",27,36,37]}
-split_clients $request_uri $cache_bdfa5d91f97d37dbb97a42dde6a5f4ff {
- 20% app_centric_env|app|split_cache_percentage|/tmp/hdd1;
- 50% app_centric_env|app|split_cache_percentage|/tmp/hdd2;
- * app_centric_env|app|split_cache_percentage|/tmp/default;
-}
-proxy_cache_path /tmp/hdd1/app_centric_env|app|split_cache_percentage| max_size=5G min_free=10k keys_zone=app_centric_env|app|split_cache_percentage|/tmp/hdd1: 100m purger=off inactive=1m;
-proxy_cache_path /tmp/hdd2/app_centric_env|app|split_cache_percentage| max_size=5g min_free=10k keys_zone=app_centric_env|app|split_cache_percentage|/tmp/hdd2: 100m purger=off inactive=10s;
-proxy_cache_path /tmp/default/app_centric_env|app|split_cache_percentage| max_size=2g min_free=10k keys_zone=app_centric_env|app|split_cache_percentage|/tmp/default: 100m purger=off inactive=15s;
-upstream split_p_http_7ec84d9e-373e-4d90-bcaa-0e33dcc4b906 {
- zone split_p_http_7ec84d9e-373e-4d90-bcaa-0e33dcc4b906 160k;
- server 10.146.187.154: 80;
- keepalive 64;
- keepalive_requests 100;
- keepalive_timeout 60s;
-}
-server {
- server_name test.example.com;
- listen 80 reuseport;
- status_zone server_4d1ee345-cf08-354e-93dc-1c3a844a04e3;
- set $f5_gateway gw;
- f5_metrics_marker gateway $f5_gateway;
- set $f5_environment env;
- f5_metrics_marker environment $f5_environment;
- location /aaa {
- error_log /dev/null;
- access_log off;
- proxy_cache $cache_bdfa5d91f97d37dbb97a42dde6a5f4ff;
- set $f5_app app;
- f5_metrics_marker app $f5_app;
- set $f5_component split_cache_percentage;
- f5_metrics_marker component $f5_component;
- proxy_set_header X-Forwarded-For $remote_addr;
- proxy_set_header Host $host;
- proxy_set_header Connection '';
- proxy_http_version 1.1;
- add_header Cache $upstream_cache_status;
- proxy_cache_valid any 1m;
- proxy_pass http: //split_p_http_7ec84d9e-373e-4d90-bcaa-0e33dcc4b906;
-}
-```
-
-### Cache Splitting using Pattern Matching and Snippets {#split-string-example}
-
-You can also use pattern matching to cache based on a certain string (`stringCriteria`) for each store. For example, you can define the string criteria as a list of file formats, as shown in the request excerpt below. As in the [percentage example](#split-percentage-example), we're also using the Components `configSnippets` API here to set the `add_header` and `proxy_cache_valid` directives.
-
-The request below splits the cache into three different stores.
-
-- One store is the default location and has no string criteria defined.
-- One store is the location for all `.html`files.
-- Ones store is the location for all `.mp4` files.
-
-```json
-"desiredState": {
- "configSnippets": {
- "uriSnippets": [
- {
- "directives": [
- {
- "directive": "proxy_cache_valid",
- "args": [
- "any",
- "1m"
- ]
- }
- ]
- }
- ]
- },
- "programmability": {
- "responseHeaderModifications": [
- {
- "action": "ADD",
- "headerName": "X-Cache-Status",
- "headerValue": "$upstream_cache_status"
- }
- ]
- },
- "caching": {
- "splitConfig": {
- "criteriaType": "STRING",
- "key": "$request_uri"
- },
- "diskStores": [
- {
- "inMemoryStoreSize": "10m",
- "inactiveTime": "1m",
- "isDefault": false,
- "maxSize": "2G",
- "minFree": "1m",
- "path": "/tmp/hdd1",
- "stringCriteria": ["~.html$"]
- },
- {
- "inMemoryStoreSize": "50m",
- "inactiveTime": "1m",
- "isDefault": false,
- "maxSize": "1g",
- "minFree": "10k",
- "path": "/tmp/hdd2",
- "stringCriteria": ["~.mp4$"]
- },
- {
- "inMemoryStoreSize": "30m",
- "inactiveTime": "1m",
- "isDefault": true,
- "maxSize": "2g",
- "minFree": "10k",
- "path": "/tmp/default"
- }
- ]
- }
-}
-```
-
-The above request modifies the `nginx.conf` file as follows:
-
-- Adds a `map` directive to the `http` context, reflecting the string criteria defined for the disk stores.
-- Adds a `proxy_cache_path` directive to the `http` context for each disk store.
-- Adds a new variable `$cache_` to the `location` block for the component.
-
-```Nginx configuration file {hl_lines=["1-8",30,39,40]}
-map $request_uri $cache_8de5273e13f731e283acbc999760c3e3 {
- ~.html$ app_centric_env|app|split_string|/tmp/hdd1;
- ~.mp4$ app_centric_env|app|split_string|/tmp/hdd2;
- default app_centric_env|app|split_string|/tmp/default;
-}
-proxy_cache_path /tmp/hdd1/app_centric_env|app|split_string| max_size=2G min_free=1m keys_zone=app_centric_env|app|split_string|/tmp/hdd1:10m purger=off inactive=1m;
-proxy_cache_path /tmp/hdd2/app_centric_env|app|split_string| max_size=1g min_free=10k keys_zone=app_centric_env|app|split_string|/tmp/hdd2:50m purger=off inactive=1m;
-proxy_cache_path /tmp/default/app_centric_env|app|split_string| max_size=2g min_free=10k keys_zone=app_centric_env|app|split_string|/tmp/default:30m purger=off inactive=1m;
-upstream wg_http_0ace772a-0c68-4d01-a443-6e377d4f6133 {
- zone wg_http_0ace772a-0c68-4d01-a443-6e377d4f6133 160k;
- server 10.146.187.154:80;
- keepalive 64;
- keepalive_requests 100;
- keepalive_timeout 60s;
-}
-map $host $f5_published_api {
- default -;
-}
-server {
- server_name test.example.com;
- listen 80 reuseport;
- status_zone server_4d1ee345-cf08-354e-93dc-1c3a844a04e3;
- set $f5_gateway gw;
- f5_metrics_marker gateway $f5_gateway;
- set $f5_environment env;
- f5_metrics_marker environment $f5_environment;
- location / {
- error_log /dev/null;
- access_log off;
- proxy_cache $cache_8de5273e13f731e283acbc999760c3e3;
- set $f5_app app;
- f5_metrics_marker app $f5_app;
- set $f5_component split_string;
- f5_metrics_marker component $f5_component;
- proxy_set_header X-Forwarded-For $remote_addr;
- proxy_set_header Host $host;
- proxy_set_header Connection '';
- proxy_http_version 1.1;
- add_header Cache $upstream_cache_status;
- proxy_cache_valid any 1m;
- proxy_pass
- }
-}
-```
-
-{{< versions "3.22" "latest" "adcvers" >}}
diff --git a/content/controller/app-delivery/about-snippets.md b/content/controller/app-delivery/about-snippets.md
deleted file mode 100644
index 83c3c063f..000000000
--- a/content/controller/app-delivery/about-snippets.md
+++ /dev/null
@@ -1,564 +0,0 @@
----
-nd-docs: DOCS-340
-title: About Snippets
-toc: true
-weight: 300
-type:
-- concept
----
-
-## Overview
-
-The F5 NGINX Controller Application Delivery (AD) module lets you configure NGINX directives that aren't represented in the NGINX Controller API via "config snippets", or "Snippets". You can do so by using either the user interface (UI) or the [Application Delivery REST API](https://docs.nginx.com/nginx-controller/api/ctlr-adc-api/).
-
-{{< call-out "caution" >}}
-When you use Snippets to customize your NGINX configuration, your changes are applied to the `nginx.conf` file *as is*. NGINX Controller does not verify that your configuration is valid before applying the snippet.
-
-We strongly recommend verifying Snippets in a lab environment before making any changes in production.
-{{< /call-out >}}
-
-## Types of Snippets
-
-There are five types of Snippets, which you can configure for gateways or components. This lets you add custom directives into the corresponding NGINX configuration blocks generated by the gateways and components for the associated URIs.
-
-{{< call-out "note" >}}The `uriSnippets` can't be used for TCP/UDP components.{{< /call-out >}}
-
-{{}}
-
-| Snippet | Description | Corresponding API Endpoint |
-| ----------------------- | ------------------------------------------------------------------ | -------------------------- |
-| `httpSnippet` | Adds directives to the `http` block. | Gateway |
-| `mainSnippet` | Adds directives to the `main` block. | Gateway |
-| `streamSnippet` | Adds directives to the `stream` block. | Gateway |
-| `uriSnippets` | Adds directives to the component's `server` and `location` blocks. | Component |
-| `uriSnippets` | Adds directives to the gateway's `server` blocks. | Gateway |
-| `workloadGroupSnippets` | Adds directives to the `upstream` blocks. | Component |
-
-{{}}
-
-## Best Practices
-
-### Gateway Partitions
-
-It's important to avoid adding conflicting snippets to the same [context](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/#contexts) in your NGINX configuration file. We recommend that you create one stand-alone Gateway to hold the `main`, `http`, and `stream` snippets. Doing so lets you share the configuration for these contexts across Gateways that define the URIs (`server` blocks) for particular instances while reducing the risk of duplicate or conflicting settings.
-
-### NGINX Variables
-
-NGINX configurations commonly use [NGINX variables](https://nginx.org/en/docs/varindex.html) or custom variables. If you prefer to configure NGINX Controller by using the REST API, you may run into problems with variable expansion when sending JSON as part of a `curl` request using th `-d` flag. The recommended best practice for this is to reference the JSON in a data file instead of sending the string as part of the request. An alternative is to redefine the variable to itself, which allows the variable to pass through to the NGINX configuration. If you're using the NGINX `$host` variable in your JSON data -- represented by the `` placeholder in the example below -- you would define the variable before the curl request as follows:
-
-```none
-host='$host' curl -s -k -H "Content-Type: application/json" -X PUT -d "