Fix tables of contents, headers and formatting

2026-09-26 04:58:07 +00:00 · 2022-09-10 00:26:51 -07:00
parent 11ebb7d341
commit 5fdfa52386
336 changed files with 1249 additions and 3710 deletions
@@ -14,11 +14,6 @@ When a cluster scan is run, you need to select a Profile which points to a speci

 Follow all the steps below to add a custom Benchmark Version and run a scan using it.

-1. [Prepare the Custom Benchmark Version ConfigMap](#1-prepare-the-custom-benchmark-version-configmap)
-2. [Add a Custom Benchmark Version to a Cluster](#2-add-a-custom-benchmark-version-to-a-cluster)
-3. [Create a New Profile for the Custom Benchmark Version](#3-create-a-new-profile-for-the-custom-benchmark-version)
-4. [Run a Scan Using the Custom Benchmark Version](#4-run-a-scan-using-the-custom-benchmark-version)
-
 ### 1. Prepare the Custom Benchmark Version ConfigMap

 To create a custom benchmark version, first you need to create a ConfigMap containing the benchmark version's config files and upload it to your Kubernetes cluster where you want to run the scan.
@@ -19,7 +19,7 @@ Note: If you were using the `cis-edit` role added in Rancher v2.5 setup, it has
 Rancher v2.5.2 because it essentially is same as `cis-admin`. If you happen to create any clusterrolebindings
 for `cis-edit`, please update them to use `cis-admin` ClusterRole instead.

-# Cluster-Admin Access
+## Cluster-Admin Access

 Rancher CIS Scans is a cluster-admin only feature by default.
 This means only the Rancher global admins, and the cluster’s cluster-owner can:
@@ -32,7 +32,7 @@ This means only the Rancher global admins, and the cluster’s cluster-owner can
 - View and Download the ClusterScanReport created after the ClusterScan is complete


-# Summary of Default Permissions for Kubernetes Default Roles
+## Summary of Default Permissions for Kubernetes Default Roles

 The rancher-cis-benchmark creates three `ClusterRoles` and adds the CIS Benchmark CRD access to the following default K8s `ClusterRoles`:

@@ -7,7 +7,7 @@ This section lists the tests that are skipped in the permissive test profile for

 > All the tests that are skipped and not applicable on this page will be counted as Not Applicable in the v2.5 generated report. The skipped test count will only mention the user-defined skipped tests. This allows user-skipped tests to be distinguished from the tests that are skipped by default in the RKE permissive test profile.

-# CIS Benchmark v1.5
+## CIS Benchmark v1.5

 ### CIS Benchmark v1.5 Skipped Tests

@@ -25,7 +25,7 @@ When adding Fleet agent environment variables for the proxy, replace <PROXY_IP>
 | `HTTPS_PROXY` | http://<PROXY_IP>:8888
 | `NO_PROXY`     | 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local |

-# Setting Environment Variables in the Rancher UI
+## Setting Environment Variables in the Rancher UI

 To add the environment variable to an existing cluster,

@@ -38,7 +38,7 @@ To add the environment variable to an existing cluster,

 **Result:** The Fleet agent works behind a proxy.

-# Setting Environment Variables on Private Nodes
+## Setting Environment Variables on Private Nodes

 For private nodes and private clusters, the proxy environment variables need to be set on the nodes themselves, as well as configured from the Rancher UI.

@@ -9,10 +9,6 @@ This ensures you can view traffic, metrics and graphs for resources deployed in

 If you would like to limit Prometheus to specific namespaces, set `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`. Once you do this, you will need to add additional configuration to continue to monitor your resources.

- [Limiting Monitoring to Specific Namespaces by Setting ignoreNamespaceSelectors to True](#limiting-monitoring-to-specific-namespaces-by-setting-ignorenamespaceselectors-to-true)
- [Enabling Prometheus to Detect Resources in Other Namespaces](#enabling-prometheus-to-detect-resources-in-other-namespaces)
- [Monitoring Specific Namespaces: Create a Service Monitor or Pod Monitor](#monitoring-specific-namespaces-create-a-service-monitor-or-pod-monitor)
- [Monitoring Across Namespaces: Set ignoreNamespaceSelectors to False](#monitoring-across-namespaces-set-ignorenamespaceselectors-to-false)

 ### Limiting Monitoring to Specific Namespaces by Setting ignoreNamespaceSelectors to True

@@ -27,7 +27,7 @@ In Kubernetes, the resource request indicates that the workload will not deploye
 | proxy          |  10m         | 10mi            | 2000m        | 1024mi   |
 | **Totals:** | **710m** | **2314Mi** | **6000m** | **3072Mi** |

-# Configuring Resource Allocations
+## Configuring Resource Allocations

 You can individually configure the resource allocation for each type of Istio component. This section includes the default resource allocations for each component.

@@ -5,7 +5,7 @@ weight: 4

 This section describes how to uninstall Istio in a cluster or disable a namespace, or workload.

-# Uninstall Istio in a Cluster
+## Uninstall Istio in a Cluster

 To uninstall Istio,

@@ -29,7 +29,7 @@ You can no longer disable and re-enable your Istio installation. If you would li

 This could mean a few things. You either selected all the apps in the `istio-system` namespace and deleted them at the same time, or you deleted `rancher-istio` chart dependencies prior to deleting the `rancher-istio` chart. Since the uninstall did not complete properly, you will have resources remaining in the `istio-system` namespace that you will need to manually clean up. Another option to avoid manual clean up is to install `rancher-istio` again, then uninstall it in the correct order.

-# Disable Istio in a Namespace
+## Disable Istio in a Namespace

 1. Click **☰ > Cluster Management**.
 1. Go to the cluster that you created and click **Explore**.
@@ -38,6 +38,6 @@ This could mean a few things. You either selected all the apps in the `istio-sys

 **Result:** When workloads are deployed in this namespace, they will not have the Istio sidecar.

-# Remove the Istio Sidecar from a Workload
+## Remove the Istio Sidecar from a Workload

 Disable Istio in the namespace, then redeploy the workloads with in it. They will be deployed without the Istio sidecar.
@@ -5,18 +5,8 @@ weight: 1

 For the full details on configuring `Flows` and `ClusterFlows`, see the [Banzai Cloud Logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/flow/)

- [Configuration](#configuration)
- [YAML Example](#yaml-example)

-# Configuration
-
- [Flows](#flows)
-  - [Matches](#matches)
-  - [Filters](#filters)
-  - [Outputs](#outputs)
- [ClusterFlows](#clusterflows)
-
-# Flows
+## Flows

 A `Flow` defines which logs to collect and filter and which output to send the logs to.

@@ -50,7 +40,7 @@ This `Output` will receive logs from the `Flow`. Because the `Flow` is a namespa

 `Outputs` can be referenced when filling out the `Flow` or `ClusterFlow` forms in the Rancher UI.

-# ClusterFlows
+## ClusterFlows

 Matches, filters and `Outputs` are configured for `ClusterFlows` in the same way that they are configured for `Flows`. The key difference is that the `ClusterFlow` is scoped at the cluster level and can configure log collection across all namespaces.

@@ -58,7 +48,7 @@ Matches, filters and `Outputs` are configured for `ClusterFlows` in the same way

 After `ClusterFlow` selects logs from all namespaces in the cluster, logs from the cluster will be collected and logged to the selected `ClusterOutput`.

-# YAML Example
+## YAML Example

 The following example `Flow` transforms the log messages from the default namespace and sends them to an S3 `Output`:

@@ -5,19 +5,7 @@ weight: 2

 For the full details on configuring `Outputs` and `ClusterOutputs`, see the [Banzai Cloud Logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/output/)

- [Configuration](#configuration)
- [YAML Examples](#yaml-examples)
-  - [Cluster Output to ElasticSearch](#cluster-output-to-elasticsearch)
-  - [Output to Splunk](#output-to-splunk)
-  - [Output to Syslog](#output-to-syslog)
-  - [Unsupported Outputs](#unsupported-outputs)
-
-# Configuration
-
- [Outputs](#outputs)
- [ClusterOutputs](#clusteroutputs)
-
-# Outputs
+## Outputs

 The `Output` resource defines where your `Flows` can send the log messages. `Outputs` are the final stage for a logging `Flow`.

@@ -53,7 +41,7 @@ The Rancher UI provides forms for configuring the `Output` type, target, and acc

 For example configuration for each logging plugin supported by the logging operator, see the [logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/outputs/)

-# ClusterOutputs
+## ClusterOutputs

 `ClusterOutput` defines an `Output` without namespace restrictions. It is only effective when deployed in the same namespace as the logging operator.

@@ -61,7 +49,7 @@ For example configuration for each logging plugin supported by the logging opera

 For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/clusteroutput_types/)

-# YAML Examples
+## YAML Examples

 Once logging is installed, you can use these examples to help craft your own logging pipeline.

@@ -4,12 +4,6 @@ shortTitle: Helm Chart Options
 weight: 4
 ---

- [Enable/Disable Windows Node Logging](#enable-disable-windows-node-logging)
- [Working with a Custom Docker Root Directory](#working-with-a-custom-docker-root-directory)
- [Adding NodeSelector Settings and Tolerations for Custom Taints](#adding-nodeselector-settings-and-tolerations-for-custom-taints)
- [Enabling the Logging Application to Work with SELinux](#enabling-the-logging-application-to-work-with-selinux)
- [Additional Logging Sources](#additional-logging-sources)
- [Systemd Configuration](#systemd-configuration)

 ### Enable/Disable Windows Node Logging

@@ -6,20 +6,7 @@ Starting in v2.5, the logging feature available within Rancher has been complete

 Among the many features and changes in the new logging functionality is the removal of project-specific logging configurations. Instead, one now configures logging at the namespace level. Cluster-level logging remains available, but configuration options differ. 

- [Installation](#installation)
-  - [Terminology](#terminology)
- [Cluster Logging](#cluster-logging)
- [Project Logging](#project-logging)
- [Output Configuration](#output-configuration)
-  - [Elasticsearch](#elasticsearch)
-  - [Splunk](#splunk)
-  - [Kafka](#kafka)
-  - [Fluentd](#fluentd)
-  - [Syslog](#syslog)
- [Custom Log Fields](#custom-log-fields)
- [System Logging](#system-logging)
-
-# Installation
+## Installation

 To install logging in Rancher v2.5+, refer to the [installation instructions](../../../pages-for-subheaders/logging.md#enabling-logging).

@@ -51,7 +38,7 @@ There are four key concepts to understand for v2.5+ logging:

    `ClusterFlows` serve the same function as `Flows`, but at the cluster level. They are used to configure log collection for an entire cluster, instead of on a per-namespace level. `ClusterFlows` are also where mutations and filters are defined, same as `Flows` (in functionality).

-# Cluster Logging
+## Cluster Logging

 To configure cluster-wide logging for v2.5+ logging, one needs to set up a `ClusterFlow`. This object defines the source of logs, any transformations or filters to be applied, and finally the `Output` (or `Outputs`) for the logs. 

@@ -71,7 +58,7 @@ In legacy logging, in order to collect logs from across the entire cluster, one

 This will result in logs from all sources in the cluster (all pods, and all system components) being collected and sent to the `Output` or `Outputs` you defined in the `ClusterFlow`. 

-# Project Logging
+## Project Logging

 Logging in v2.5+ is not project-aware. This means that in order to collect logs from pods running in project namespaces, you will need to define `Flows` for those namespaces. 

@@ -91,7 +78,7 @@ To collect logs from a project, repeat the above steps for every namespace withi

 :::

-# Output Configuration
+## Output Configuration
 In legacy logging, there are five logging destinations to choose from: Elasticsearch, Splunk, Kafka, Fluentd, and Syslog. With the exception of Syslog, all of these destinations are available in logging v2.5+. 


@@ -110,7 +97,7 @@ In legacy logging, there are five logging destinations to choose from: Elasticse

 In legacy logging, indices were automatically created according to the format in the "Index Patterns" section. In v2.5 logging, default behavior has been changed to logging to a single index. You can still configure index pattern functionality on the `Output` object by editing as YAML and inputting the following values:

-```
+```yaml
 ...
 spec:
  elasticsearch:
@@ -179,11 +166,11 @@ _(1) These values are to be specified as paths to files. Those files must be mou

 As of v2.5.2, syslog is not currently supported for `Outputs` using v2.5+ logging. 

-# Custom Log Fields
+## Custom Log Fields

 In order to add custom log fields, you will need to add the following YAML to your `Flow` configuration:

-```
+```yaml
 ...
 spec:
  filters:
@@ -194,7 +181,7 @@ spec:

 (replace `foo: "bar"` with custom log fields you wish to add)

-# System Logging
+## System Logging

 In legacy logging, collecting logs from system components was accomplished by checking a box labeled "Include System Log" when setting up cluster logging. In v2.5+ logging, system logs are gathered in one of two ways:

@@ -20,6 +20,7 @@ With Longhorn, you can:
 - Upgrade Longhorn without disrupting persistent volumes

 <figcaption>Longhorn Dashboard</figcaption>
+
 ![Longhorn Dashboard](/img/longhorn-screenshot.png)

 ### Installing Longhorn with Rancher
@@ -3,11 +3,8 @@ title: Built-in Dashboards
 weight: 3
 ---

- [Grafana UI](#grafana-ui)
- [Alertmanager UI](#alertmanager-ui)
- [Prometheus UI](#prometheus-ui)

-# Grafana UI
+## Grafana UI

 [Grafana](https://grafana.com/grafana/) allows you to query, visualize, alert on and understand your metrics no matter where they are stored. Create, explore, and share dashboards with your team and foster a data driven culture.

@@ -26,7 +23,7 @@ To create a persistent Grafana dashboard, see [this page.](../../../how-to-guide
 For information about role-based access control for Grafana, see [this section.](rbac-for-monitoring.md#role-based-access-control-for-grafana)


-# Alertmanager UI
+## Alertmanager UI

 When `rancher-monitoring` is installed, the Prometheus Alertmanager UI is deployed, allowing you to view your alerts and the current Alertmanager configuration.

@@ -66,7 +63,7 @@ For more information on configuring Alertmanager in Rancher, see [this page.](..
 To see alerts that are fired by default, go to the Alertmanager UI and click **Expand all groups**.


-# Prometheus UI
+## Prometheus UI

 By default, the [kube-state-metrics service](https://github.com/kubernetes/kube-state-metrics) provides a wealth of information about CPU and memory utilization to the monitoring application. These metrics cover Kubernetes resources across namespaces. This means that in order to see resource metrics for a service, you don't need to create a new ServiceMonitor for it. Because the data is already in the time series database, you can go to the Prometheus UI and run a PromQL query to get the information. The same query can be used to configure a Grafana dashboard to show a graph of those metrics over time.

@@ -78,6 +75,7 @@ To see the Prometheus UI, install `rancher-monitoring`. Then:
 1. Click **Prometheus Graph**.

 <figcaption>Prometheus Graph UI</figcaption>
+
 ![Prometheus Graph UI](/img/prometheus-graph-ui.png)

 ### Viewing the Prometheus Targets
@@ -3,13 +3,8 @@ title: How Monitoring Works
 weight: 1
 ---

-1. [Architecture Overview](#1-architecture-overview)
-2. [How Prometheus Works](#2-how-prometheus-works)
-3. [How Alertmanager Works](#3-how-alertmanager-works)
-4. [Monitoring V2 Specific Components](#4-monitoring-v2-specific-components)
-5. [Scraping and Exposing Metrics](#5-scraping-and-exposing-metrics)

-# 1. Architecture Overview
+## 1. Architecture Overview

 _**The following sections describe how data flows through the Monitoring V2 application:**_

@@ -67,7 +62,7 @@ Once Prometheus determines that an alert needs to be fired, alerts are forwarded
 <figcaption>How data flows through the monitoring application:</figcaption>


-# 2. How Prometheus Works
+## 2. How Prometheus Works

 ### Storing Time Series Data

@@ -111,7 +106,7 @@ The Rule file adds labels and annotations to alerts before firing them, dependin

 - Annotations denote information that doesn't affect where an alert is routed, for example, a runbook or an error message.

-# 3. How Alertmanager Works
+## 3. How Alertmanager Works

 The Alertmanager handles alerts sent by client applications such as the Prometheus server. It takes care of the following tasks:

@@ -139,7 +134,7 @@ By editing the forms in the Rancher UI, you can set up a Receiver resource with

 By editing custom YAML in the Alertmanager or Receiver configuration, you can also send alerts to multiple notification systems. For more information, see the section on configuring [Receivers.](../../../reference-guides/monitoring-v2-configuration/receivers.md#configuring-multiple-receivers)

-# 4. Monitoring V2 Specific Components
+## 4. Monitoring V2 Specific Components

 Prometheus Operator introduces a set of [Custom Resource Definitions](https://github.com/prometheus-operator/prometheus-operator#customresourcedefinitions) that allow users to deploy and manage Prometheus and Alertmanager instances by creating and modifying those custom resources on a cluster.

@@ -185,7 +180,7 @@ Since the metrics for Kubernetes components are generally exposed on the host ne

 Refer to [Scraping Metrics with PushProx](#scraping-metrics-with-pushprox) for more.

-# 5. Scraping and Exposing Metrics
+## 5. Scraping and Exposing Metrics

 ### Defining what Metrics are Scraped

@@ -7,70 +7,8 @@ The PromQL expressions in this doc can be used to configure alerts.

 For more information about querying the Prometheus time series database, refer to the official [Prometheus documentation.](https://prometheus.io/docs/prometheus/latest/querying/basics/)

-<!-- TOC -->

- [Cluster Metrics](#cluster-metrics)
-  - [Cluster CPU Utilization](#cluster-cpu-utilization)
-  - [Cluster Load Average](#cluster-load-average)
-  - [Cluster Memory Utilization](#cluster-memory-utilization)
-  - [Cluster Disk Utilization](#cluster-disk-utilization)
-  - [Cluster Disk I/O](#cluster-disk-i-o)
-  - [Cluster Network Packets](#cluster-network-packets)
-  - [Cluster Network I/O](#cluster-network-i-o)
- [Node Metrics](#node-metrics)
-  - [Node CPU Utilization](#node-cpu-utilization)
-  - [Node Load Average](#node-load-average)
-  - [Node Memory Utilization](#node-memory-utilization)
-  - [Node Disk Utilization](#node-disk-utilization)
-  - [Node Disk I/O](#node-disk-i-o)
-  - [Node Network Packets](#node-network-packets)
-  - [Node Network I/O](#node-network-i-o)
- [Etcd Metrics](#etcd-metrics)
-  - [Etcd Has a Leader](#etcd-has-a-leader)
-  - [Number of Times the Leader Changes](#number-of-times-the-leader-changes)
-  - [Number of Failed Proposals](#number-of-failed-proposals)
-  - [GRPC Client Traffic](#grpc-client-traffic)
-  - [Peer Traffic](#peer-traffic)
-  - [DB Size](#db-size)
-  - [Active Streams](#active-streams)
-  - [Raft Proposals](#raft-proposals)
-  - [RPC Rate](#rpc-rate)
-  - [Disk Operations](#disk-operations)
-  - [Disk Sync Duration](#disk-sync-duration)
- [Kubernetes Components Metrics](#kubernetes-components-metrics)
-  - [API Server Request Latency](#api-server-request-latency)
-  - [API Server Request Rate](#api-server-request-rate)
-  - [Scheduling Failed Pods](#scheduling-failed-pods)
-  - [Controller Manager Queue Depth](#controller-manager-queue-depth)
-  - [Scheduler E2E Scheduling Latency](#scheduler-e2e-scheduling-latency)
-  - [Scheduler Preemption Attempts](#scheduler-preemption-attempts)
-  - [Ingress Controller Connections](#ingress-controller-connections)
-  - [Ingress Controller Request Process Time](#ingress-controller-request-process-time)
- [Rancher Logging Metrics](#rancher-logging-metrics)
-  - [Fluentd Buffer Queue Rate](#fluentd-buffer-queue-rate)
-  - [Fluentd Input Rate](#fluentd-input-rate)
-  - [Fluentd Output Errors Rate](#fluentd-output-errors-rate)
-  - [Fluentd Output Rate](#fluentd-output-rate)
- [Workload Metrics](#workload-metrics)
-  - [Workload CPU Utilization](#workload-cpu-utilization)
-  - [Workload Memory Utilization](#workload-memory-utilization)
-  - [Workload Network Packets](#workload-network-packets)
-  - [Workload Network I/O](#workload-network-i-o)
-  - [Workload Disk I/O](#workload-disk-i-o)
- [Pod Metrics](#pod-metrics)
-  - [Pod CPU Utilization](#pod-cpu-utilization)
-  - [Pod Memory Utilization](#pod-memory-utilization)
-  - [Pod Network Packets](#pod-network-packets)
-  - [Pod Network I/O](#pod-network-i-o)
-  - [Pod Disk I/O](#pod-disk-i-o)
- [Container Metrics](#container-metrics)
-  - [Container CPU Utilization](#container-cpu-utilization)
-  - [Container Memory Utilization](#container-memory-utilization)
-  - [Container Disk I/O](#container-disk-i-o)
-
-<!-- /TOC -->
-
-# Cluster Metrics
+## Cluster Metrics

 ### Cluster CPU Utilization

@@ -121,7 +59,7 @@ For more information about querying the Prometheus time series database, refer t
 | Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m])) by (instance)</code></td></tr></table> |
 | Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;"}[5m]))</code></td></tr></table> |

-# Node Metrics
+## Node Metrics

 ### Node CPU Utilization

@@ -172,7 +110,7 @@ For more information about querying the Prometheus time series database, refer t
 | Detail | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m])) by (device)</code></td></tr></table> |
 | Summary | <table><tr><td>receive</td><td><code>sum(rate(node_network_receive_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr><tr><td>transmit</td><td><code>sum(rate(node_network_transmit_bytes_total{device!~"lo &#124; veth.&ast; &#124; docker.&ast; &#124; flannel.&ast; &#124; cali.&ast; &#124; cbr.&ast;",instance=~"$instance"}[5m]))</code></td></tr></table> |

-# Etcd Metrics
+## Etcd Metrics

 ### Etcd Has a Leader

@@ -242,7 +180,7 @@ For more information about querying the Prometheus time series database, refer t
 | Detail | <table><tr><td>wal</td><td>`histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) by (instance, le))`</td></tr><tr><td>db</td><td>`histogram_quantile(0.99, sum(rate(etcd_disk_backend_commit_duration_seconds_bucket[5m])) by (instance, le))`</td></tr></table> |
 | Summary | <table><tr><td>wal</td><td>`sum(histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) by (instance, le)))`</td></tr><tr><td>db</td><td>`sum(histogram_quantile(0.99, sum(rate(etcd_disk_backend_commit_duration_seconds_bucket[5m])) by (instance, le)))`</td></tr></table> |

-# Kubernetes Components Metrics
+## Kubernetes Components Metrics

 ### API Server Request Latency

@@ -300,7 +238,7 @@ For more information about querying the Prometheus time series database, refer t
 | Detail | `topk(10, histogram_quantile(0.95,sum by (le, host, path)(rate(nginx_ingress_controller_request_duration_seconds_bucket{host!="_"}[5m]))))` |
 | Summary | `topk(10, histogram_quantile(0.95,sum by (le, host)(rate(nginx_ingress_controller_request_duration_seconds_bucket{host!="_"}[5m]))))` |

-# Rancher Logging Metrics
+## Rancher Logging Metrics


 ### Fluentd Buffer Queue Rate
@@ -331,7 +269,7 @@ For more information about querying the Prometheus time series database, refer t
 | Detail | `sum(rate(fluentd_output_status_num_records_total[5m])) by (instance)` |
 | Summary | `sum(rate(fluentd_output_status_num_records_total[5m]))` |

-# Workload Metrics
+## Workload Metrics

 ### Workload CPU Utilization

@@ -368,7 +306,7 @@ For more information about querying the Prometheus time series database, refer t
 | Detail | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`</td></tr></table> |
 | Summary | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`</td></tr></table> |

-# Pod Metrics
+## Pod Metrics

 ### Pod CPU Utilization

@@ -405,7 +343,7 @@ For more information about querying the Prometheus time series database, refer t
 | Detail | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m])) by (container_name)`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m])) by (container_name)`</td></tr></table> |
 | Summary | <table><tr><td>read</td><td>`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr><tr><td>write</td><td>`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`</td></tr></table> |

-# Container Metrics
+## Container Metrics

 ### Container CPU Utilization

@@ -5,18 +5,8 @@ weight: 2
 ---
 This section describes the expectations for RBAC for Rancher Monitoring.

- [Cluster Admins](#cluster-admins)
- [Users with Kubernetes ClusterRole-based Permissions](#users-with-kubernetes-clusterrole-based-permissions)
-  - [Users with Kubernetes Admin/Edit Permissions](#users-with-kubernetes-admin-edit-permissions)
-  - [Users with Kubernetes View Permissions](#users-with-kubernetes-view-permissions)
-  - [Additional Monitoring Roles](#additional-monitoring-roles)
-  - [Additional Monitoring ClusterRoles](#additional-monitoring-clusterroles)
- [Users with Rancher Based Permissions](#users-with-rancher-based-permissions)
-  - [Differences in 2.5.x](#differences-in-2-5-x)
-  - [Assigning Additional Access](#assigning-additional-access)
- [Role-based Access Control for Grafana](#role-based-access-control-for-grafana)

-# Cluster Admins
+## Cluster Admins

 By default, only those with the cluster-admin `ClusterRole` should be able to:

@@ -27,7 +17,7 @@ By default, only those with the cluster-admin `ClusterRole` should be able to:
 - Persist new Grafana dashboards or datasources via creating ConfigMaps in the appropriate namespace
 - Expose certain Prometheus metrics to the k8s Custom Metrics API for HPA via a Secret in the `cattle-monitoring-system` namespace

-# Users with Kubernetes ClusterRole-based Permissions
+## Users with Kubernetes ClusterRole-based Permissions

 The `rancher-monitoring` chart installs the following three `ClusterRoles`. By default, they aggregate into the corresponding k8s `ClusterRoles`:

@@ -92,7 +82,7 @@ An alternative method to using Rancher to attach a `Role` or `ClusterRole` to a

 * **Roles**: Below is an example of a YAML file to help you configure `RoleBindings` in Kubernetes. You will need to fill in the name below, and name is case-sensitive. 

-```
+```yaml
 # monitoring-config-view-role-binding.yaml
 apiVersion: rbac.authorization.k8s.io/v1
 kind: RoleBinding
@@ -114,7 +104,7 @@ subjects:
  * **`kubectl apply -f monitoring-config-view-role-binding.yaml`
 

-# Users with Rancher Based Permissions
+## Users with Rancher Based Permissions

 The relationship between the default roles deployed by Rancher (i.e. cluster-owner, cluster-member, project-owner, project-member), the default Kubernetes roles, and the roles deployed by the rancher-monitoring chart are detailed in the table below:

@@ -161,7 +151,7 @@ If cluster-admins would like to provide additional admin/edit access to users ou



-# Role-based Access Control for Grafana
+## Role-based Access Control for Grafana

 Rancher allows any users who are authenticated by Kubernetes and have access the Grafana service deployed by the Rancher Monitoring chart to access Grafana via the Rancher Dashboard UI. By default, all users who are able to access Grafana are given the [Viewer](https://grafana.com/docs/grafana/latest/permissions/organization_roles/#viewer-role) role, which allows them to view any of the default dashboards deployed by Rancher.

@@ -8,17 +8,14 @@ _Available as of v2.5.8_

 Starting at Monitoring V2 14.5.100 (used by default in Rancher 2.5.8), Monitoring V2 can now be deployed on a Windows cluster and will scrape metrics from Windows nodes using [prometheus-community/windows_exporter](https://github.com/prometheus-community/windows_exporter) (previously named `wmi_exporter`).

- [Comparison to Monitoring V1](#comparison-to-monitoring-v1)
- [Cluster Requirements](#cluster-requirements)
-  - [Upgrading Existing Clusters to wins v0.1.0](#upgrading-existing-clusters-to-wins-v0-1-0)

-# Comparison to Monitoring V1
+## Comparison to Monitoring V1

 Unlike Monitoring V1 for Windows, metrics collected by `windows_exporter` will be labeled as `windows_` instead of `wmi_` in accordance to a naming change from upstream from `wmi_exporter` to `windows_exporter`.

 In addition, Monitoring V2 for Windows will no longer require users to keep port 9796 open on Windows hosts since the host metrics will published directly onto a port exposed on the windows-exporter Pod. This feature was powered by recent changes made by `wins` v0.1.0 to support publishing ports exposed on the hostNetwork on Pods that use wins to run a privileged Windows binary as a host process.

-# Cluster Requirements
+## Cluster Requirements

 Monitoring V2 for Windows can only scrape metrics from Windows hosts that have a minimum `wins` version of v0.1.0.  To be able to fully deploy Monitoring V2 for Windows, all of your hosts must meet this requirement.

@@ -16,13 +16,13 @@ OPA provides a high-level declarative language that lets you specify policy as c

 To read more about OPA, please refer to the [official documentation.](https://www.openpolicyagent.org/docs/latest/)

-# How the OPA Gatekeeper Integration Works
+## How the OPA Gatekeeper Integration Works

 Kubernetes provides the ability to extend API server functionality via admission controller webhooks, which are invoked whenever a resource is created, updated or deleted. Gatekeeper is installed as a validating webhook and enforces policies defined by Kubernetes custom resource definitions. In addition to the admission control usage, Gatekeeper provides the capability to audit existing resources in Kubernetes clusters and mark current violations of enabled policies.

 OPA Gatekeeper is made available via Rancher's Helm system chart, and it is installed in a namespace named `gatekeeper-system.`

-# Enabling OPA Gatekeeper in a Cluster
+## Enabling OPA Gatekeeper in a Cluster

 :::note

@@ -48,7 +48,7 @@ The OPA Gatekeeper Helm chart can be installed from **Apps & Marketplace**.

 **Result:** OPA Gatekeeper is deployed in your Kubernetes cluster.

-# Constraint Templates
+## Constraint Templates

 [Constraint templates](https://github.com/open-policy-agent/gatekeeper#constraint-templates) are Kubernetes custom resources that define the schema and Rego logic of the OPA policy to be applied by Gatekeeper. For more information on the Rego policy language, refer to the [official documentation.](https://www.openpolicyagent.org/docs/latest/policy-language/)

@@ -58,7 +58,7 @@ To list the constraint templates installed in the cluster, go to the left side m

 Rancher also provides the ability to create your own constraint templates by importing YAML definitions.
   
-# Creating and Configuring Constraints
+## Creating and Configuring Constraints

 [Constraints](https://github.com/open-policy-agent/gatekeeper#constraints) are Kubernetes custom resources that define the scope of objects to which a specific constraint template applies to. The complete policy is defined by constraint templates and constraints together.

@@ -84,7 +84,7 @@ To limit the scope of the constraint only to user namespaces, always specify the

 Also, the constraint may interfere with other Rancher functionality and deny system workloads from being deployed. To avoid this, exclude all Rancher-specific namespaces from your constraints.
   
-# Enforcing Constraints in your Cluster
+## Enforcing Constraints in your Cluster

 When the **Enforcement Action** is **Deny,** the constraint is immediately enabled and will deny any requests that violate the policy defined. By default, the enforcement value is **Deny**.

@@ -92,7 +92,7 @@ When the **Enforcement Action** is **Dryrun,** then any resources that violate t

 To enforce constraints, create a constraint using the form. In the **Enforcement Action** field, choose **Deny**. 

-# Audit and Violations in your Cluster
+## Audit and Violations in your Cluster

 OPA Gatekeeper runs a periodic audit to check if any existing resource violates any enforced constraint. The audit-interval (default 300s) can be configured while installing Gatekeeper.

@@ -102,7 +102,7 @@ Also under **Constraints,** the number of violations of the constraint can be fo

 The detail view of each constraint lists information about the resource that violated the constraint.

-# Disabling Gatekeeper
+## Disabling Gatekeeper

 1. Navigate to the cluster's Dashboard view
 1. On the left side menu, expand the cluster menu and click on **OPA Gatekeeper**.