Merge branch 'main' into fix-n1c-metric-details

Author: ADubhlaoich

content/nap-dos/deployment-guide/installing-nginx-plus-with-dos-and-waf-on-amazon-web-services.md

@@ -21,7 +21,7 @@ The AMIs contain combination of the following components:
 - Latest version of [NGINX App Protect WAF](https://docs.nginx.com/nginx-app-protect-waf/), optimized for use on Amazon EC2
 - Pre-packaged software for building highly available (HA) NGINX Plus configurations
 
-## Installing the NGINX Plus NGINX App Protect WAF + DoS
+## Install NGINX Plus NGINX App Protect WAF + DoS
 
 To quickly set up an environment with NGINX Plus, NGINX App Protect WAF and NGINX App Protect DoS on AWS:
 

content/nap-dos/monitoring/live-activity-monitoring.md

@@ -113,8 +113,8 @@ To activate the API:
   }
   ```
 
-## Using the Dashboard
-### Accessing the Dashboard
+## Use the Dashboard
+### Access the Dashboard
 To view the Dashboard, enter the corresponding address in your browser's address bar.<br>
 For example, "http://192.168.1.23/dashboard-dos.html" will show the Dashboard page located in /usr/share/nginx/html as indicated in the root directive.
 
@@ -158,12 +158,12 @@ The displayed graph is a stacked composition, encompassing two specific metrics:
 - **Yellow**: Indicates the presence of either an active attack or diminished server health.
 - **Red**: Indicates a severe scenario, where the object is experiencing an attack combined with poor health.
 
-### Configuring Dashboard Options
+### Configure Dashboard Options
 You can configure the dashboard by clicking the Gear button in the Tabs menu.<br>
 **Update every N sec** - updates the Dashboard data after the specified number of seconds, default is 1 second.<br>
 <br>
 
-## Using the REST API
+## Use the REST API
 Statistics of your server infrastructure can be managed with the REST API interface. The API is based on standard HTTP requests: statistics can be obtained with `GET` requests.
 
 The requests are sent in the JSON format that allows you to connect the stats to monitoring tools or dashboards that support JSON.

content/nginx/admin-guide/basic-functionality/runtime-control.md

@@ -2,7 +2,7 @@
 description: Understand the NGINX processes that handle traffic, and how to control
   them at runtime.
 docs: DOCS-379
-title: Controlling NGINX Processes at Runtime
+title: Control NGINX Processes at Runtime
 toc: true
 weight: 100
 type:
@@ -19,7 +19,7 @@ The main purpose of the master process is to read and evaluate configuration fil
 
 The worker processes do the actual processing of requests. NGINX relies on <span style="white-space: nowrap;">OS-dependent</span> mechanisms to efficiently distribute requests among worker processes. The number of worker processes is defined by the [worker_processes](https://nginx.org/en/docs/ngx_core_module.html#worker_processes) directive in the **nginx.conf** configuration file and can either be set to a fixed number or configured to adjust automatically to the number of available CPU cores.
 
-## Controlling NGINX
+## Control NGINX
 
 To reload your configuration, you can stop or restart NGINX, or send signals to the master process. A signal can be sent by running the `nginx` command (invoking the NGINX executable) with the `-s` argument.
 
@@ -36,4 +36,4 @@ where `<SIGNAL>` can be one of the following:
 
 The `kill` utility can also be used to send a signal directly to the master process. The process ID of the master process is written, by default, to the **nginx.pid** file, which is located in the **/usr/local/nginx/logs** or **/var/run** directory.
 
-For more information about advanced signals (for performing live binary upgrades, for example), see [Controlling nginx](https://nginx.org/en/docs/control.html) at **nginx.org**.
+For more information about advanced signals (for performing live binary upgrades, for example), see [Control nginx](https://nginx.org/en/docs/control.html) at **nginx.org**.