fix structure of the document

Author: salonichf5

site/content/how-to/monitoring/troubleshooting.md

@@ -85,13 +85,13 @@ Logs from the NGINX Gateway Fabric control plane and data plane can contain info
 To see logs for Control plane container:
 
 ```shell
-kubectl -n nginx-gateway  logs <ngf-pod-name> -c nginx-gateway
+kubectl -n nginx-gateway logs <ngf-pod-name> -c nginx-gateway
 ```
 
 To see logs for Data plane container:
 
 ```shell
-kubectl -n nginx-gateway  logs <ngf-pod-name> -c nginx
+kubectl -n nginx-gateway logs <ngf-pod-name> -c nginx
 ```
 
 ##### Error Logs
@@ -101,7 +101,7 @@ To see error logs for control plane and data plane containers:
 For _nginx-gateway_ container, you can `grep` for the word `error` or change the log level to `error` by following steps in [Modify log levels](#modify-log-levels). Once you have modified log levels, you can `grep` for the word `debug` to check debug logs for further investigation.
 
 ```shell
-kubectl -n nginx-gateway  logs <ngf-pod-name> -c nginx-gateway | grep error
+kubectl -n nginx-gateway logs <ngf-pod-name> -c nginx-gateway | grep error
 ```
 
 For example, an error message when telemetry is not enabled for NGINX Plus installations:
@@ -112,10 +112,10 @@ Defaulted container "nginx-gateway" out of: nginx-gateway, nginx
 {"level":"error","ts":"2024-06-13T18:22:16Z","logger":"usageReporter","msg":"Usage reporting must be enabled when using NGINX Plus; redeploy with usage reporting enabled","error":"usage reporting not enabled","stacktrace":"github.com/nginxinc/nginx-gateway-fabric/internal/mode/static.createUsageWarningJob.func1\n\tgithub.com/nginxinc/nginx-gateway-fabric/internal/mode/static/manager.go:616\nk8s.io/apimachinery/pkg/util/wait.JitterUntilWithContext.func1\n\tk8s.io/apimachinery@v0.30.1/pkg/util/wait/backoff.go:259\nk8s.io/apimachinery/pkg/util/wait.BackoffUntil.func1\n\tk8s.io/apimachinery@v0.30.1/pkg/util/wait/backoff.go:226\nk8s.io/apimachinery/pkg/util/wait.BackoffUntil\n\tk8s.io/apimachinery@v0.30.1/pkg/util/wait/backoff.go:227\nk8s.io/apimachinery/pkg/util/wait.JitterUntil\n\tk8s.io/apimachinery@v0.30.1/pkg/util/wait/backoff.go:204\nk8s.io/apimachinery/pkg/util/wait.JitterUntilWithContext\n\tk8s.io/apimachinery@v0.30.1/pkg/util/wait/backoff.go:259\ngithub.com/nginxinc/nginx-gateway-fabric/internal/framework/runnables.(*CronJob).Start\n\tgithub.com/nginxinc/nginx-gateway-fabric/internal/framework/runnables/cronjob.go:53\nsigs.k8s.io/controller-runtime/pkg/manager.(*runnableGroup).reconcile.func1\n\tsigs.k8s.io/controller-runtime@v0.18.4/pkg/manager/runnable_group.go:226"}
 ```
 
-For _nginx_ container you can `grep` for various [error](https://nginx.org/en/docs/ngx_core_module.html#error_log) log levels and they are all logged in brackets `[emerg]`:
+For _nginx_ container you can `grep` for various [error](https://nginx.org/en/docs/ngx_core_module.html#error_log) log levels. They are logged with the`[emerg]` tag:
 
 ```shell
-kubectl -n nginx-gateway  logs <ngf-pod-name> -c nginx | grep emerg
+kubectl -n nginx-gateway logs <ngf-pod-name> -c nginx | grep emerg
 ```
 
 For example, if a variable is too long, NGINX may display such an error message:
@@ -127,8 +127,8 @@ kubectl logs -n nginx-gateway ngf-nginx-gateway-fabric-bb8598998-jwk2m -c nginx
 
 ##### Access Logs
 
-NGINX access logs are files that record all requests processed by the NGINX server. These logs provide detailed information about each request, which can be useful for troubleshooting, and analyzing web traffic.
-To view the access logs, get shell access to your NGINX container using the [steps](#get-shell-access-to-nginx-container). The access logs are located in the file `/var/log/nginx/access.log` in the NGINX container and present in logs for _nginx_ container.
+NGINX access logs record all requests processed by the NGINX server. These logs provide detailed information about each request, which can be useful for troubleshooting and analyzing web traffic.
+Access logs can be viewed with the above method of using `kubectl logs`, or by viewing the access log file directly. To do that, get shell access to your NGINX container using these [steps](#get-shell-access-to-nginx-container). The access logs are located in the file `/var/log/nginx/access.log` in the NGINX container.
 
 You can see logs for a crashed or killed container by adding the `-p` flag to the above commands.
 
@@ -154,7 +154,7 @@ server {
 }
 ```
 
-Once HTTPRoute with path matches and rules are defined, the nginx.conf is updated accordingly to determine which location block will manage incoming requests. To demonstrate how `nginx.conf` is changed, let's create some resources:
+Once a HTTPRoute with path matches and rules are defined, the nginx.conf is updated accordingly to determine which location block will manage incoming requests. To demonstrate how `nginx.conf` is changed, let's create some resources:
 
 1. A Gateway with single listener on port 80. The hostname specified is `*.example.com`, so all incoming requests matching that wildcard is accepted by this Gateway.
 2. A simple `coffee` application with hostname `cafe.example.com` and referenced to the Gateway we created.
@@ -291,23 +291,23 @@ In such situations, it's advisable to review the logs of both NGINX and NGINX Ga
 #### Access the N+ Dashboard
 
 If you have NGINX Gateway Fabric installed with NGINX Plus, you can access the N+ dashboard at `http://localhost:8080/dashboard.html`.
-Note that, the port number i.e `8080` matches the port number you have port-forwarded your NGINX Gateway Fabric Pod. For further [details]({{< relref "dashboard.md" >}})
+Note that, the port number i.e `8080` matches the port number you have port-forwarded your NGINX Gateway Fabric Pod. For further details, see the [dashboard guide]({{< relref "dashboard.md" >}})
 
 ### Common Errors
 
 {{< bootstrap-table "table table-striped table-bordered" >}}
-| Problem Area                 | Symptom                                | Troubleshooting Method                                                                                              | Common Cause                                           |
-|------------------------------|----------------------------------------|---------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------|
-| Startup                      | NGINX Gateway Fabric fails to start.   | Check logs for _nginx_ and _nginx-gateway_ container.                                                               | Missing TLS key and cert for SSL servers.              |
-| Resources not configured     | Status missing on resources.           | Check referenced resources.                                                                                         | Referenced resources not belong to Gateway Fabric.     |
-| NGINX errors                 | Reload failures on NGINX               | Fix permissions for control plane.                                                                                  | Security context not configured.                       |
-| Usage reporting              | Errors logs related to usage reporting | Enable usage reporting. Refer to this [Usage Reporting]({{< relref "installation/usage-reporting.md" >}})           | Usage reporting disabled.                              |
+| Problem Area                 | Symptom                                | Troubleshooting Method                                                                                              | Common Cause                                              |
+|------------------------------|----------------------------------------|---------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------|
+| Startup                      | NGINX Gateway Fabric fails to start.   | Check logs for _nginx_ and _nginx-gateway_ container.                                                               | Missing TLS key and cert for SSL servers.                 |
+| Resources not configured     | Status missing on resources.           | Check referenced resources.                                                                                         | Referenced resources do not belong to NGINX Gateway Fabric.     |
+| NGINX errors                 | Reload failures on NGINX               | Fix permissions for control plane.                                                                                  | Security context not configured.                          |
+| Usage reporting              | Errors logs related to usage reporting | Enable usage reporting. Refer to this [Usage Reporting]({{< relref "installation/usage-reporting.md" >}})           | Usage reporting disabled.                                 |
 {{< /bootstrap-table >}}
 
 ##### NGINX fails to reload
 
 NGINX reload errors can occur for various reasons, including syntax errors in configuration files, permission issues, and more. To determine if NGINX has failed to reload, check logs for your _nginx-gateway_ and _nginx_ containers.
-You will see the following error in the _nginx-gateway_  logs `failed to reload NGINX:` followed by the reason for the failure. Similarly, error logs in _nginx_ container start with `emerg`. For example, `2024/06/12 14:25:11 [emerg] 12345#0: open() "/var/run/nginx.pid" failed (13: Permission denied)` shows a critical error, such as a permission problem preventing NGINX from accessing necessary files.
+You will see the following error in the _nginx-gateway_  logs: `failed to reload NGINX:`, followed by the reason for the failure. Similarly, error logs in _nginx_ container start with `emerg`. For example, `2024/06/12 14:25:11 [emerg] 12345#0: open() "/var/run/nginx.pid" failed (13: Permission denied)` shows a critical error, such as a permission problem preventing NGINX from accessing necessary files.
 
 To debug why your reload has failed, start with verifying the syntax of your configuration files by opening a shell in the NGINX container following these [steps](#get-shell-access-to-nginx-container) and running `nginx -T`. If there are errors in your configuration file, the reload will fail and specify the reason for it.