Fix tables of contents, headers and formatting

docs/reference-guides/best-practices/rancher-managed-clusters/logging-best-practices.md

@@ -14,7 +14,7 @@ Rancher provides a flexible experience for log aggregation. With the logging fea
 
 "Under the hood", Rancher logging uses the Banzai Cloud logging operator. We provide manageability of this operator (and its resources), and tie that experience in with managing your Rancher clusters. 
 
-# Cluster-level Logging
+## Cluster-level Logging
 
 ### Cluster-wide Scraping
 
@@ -32,7 +32,7 @@ Currently the logs from RKE containers are collected, but are not able to easily
 
 A future release of Rancher will include the source container name which will enable filtering of these component logs. Once that change is made, you will be able to customize a _ClusterFlow_ to retrieve **only** the Kubernetes component logs, and direct them to an appropriate output.
 
-# Application Logging
+## Application Logging
 
 Best practice not only in Kubernetes but in all container-based applications is to direct application logs to `stdout`/`stderr`. The container runtime will then trap these logs and do **something** with them - typically writing them to a file. Depending on the container runtime (and its configuration), these logs can end up in any number of locations.
 
@@ -48,7 +48,7 @@ The goal of setting up a streaming sidecar is to take log files that are written
 
 To set this up, edit your workload resource (e.g. Deployment) and add the following sidecar definition:
 
-```
+```yaml
 ...
 containers:
 - args:
@@ -68,7 +68,7 @@ This will add a container to your workload definition that will now stream the c
 
 This log stream is then automatically collected according to any _Flows_ or _ClusterFlows_ you have setup. You may also wish to consider creating a _Flow_ specifically for this log file by targeting the name of the container. See example:
 
-```
+```yaml
 ...
 spec:
   match:
@@ -79,7 +79,7 @@ spec:
 ```
 
 
-# General Best Practices
+## General Best Practices
 
 - Where possible, output structured log entries (e.g. `syslog`, JSON). This makes handling of the log entry easier as there are already parsers written for these formats. 
 - Try to provide the name of the application that is creating the log entry, in the entry itself. This can make troubleshooting easier as Kubernetes objects do not always carry the name of the application as the object name. For instance, a pod ID may be something like `myapp-098kjhsdf098sdf98` which does not provide much information about the application running inside the container.