updated: docs and rearranged the weights

Signed-off-by: Yashvardhan Kukreja <yash.kukreja.98@gmail.com>

content/en/docs/Monitoring Kyverno With Prometheus Metrics/_index.md

@@ -1,7 +1,7 @@
 ---
 title: Monitoring Kyverno
-description: Monitor the activities associated with the Kyverno policies applied over your cluster with a good set of Prometheus-compliant metrics
-weight: 45
+description: Monitor the activities associated with the Kyverno policies applied over your cluster with Prometheus-compliant metrics.
+weight: 65
 ---
 
 ## Introduction
@@ -12,21 +12,19 @@ Alongside this, providing a non-rigid granularity of monitoring the above target
 
 ## Installation and Setup
 
-Whenever you install Kyverno via helm, a service called `kyverno-svc` gets created as well inside the `kyverno` namespace and this service ends up exposing the metrics at its port no. 8000.
+Whenever you install Kyverno via helm, a service called `kyverno-svc-metrics` gets created inside the `kyverno` namespace and this service ends up exposing the metrics at its port number 8000.
 
 ```sh
 $ values.yaml
 
 ...
-service:
-  port: 443
+metricsService:
+  create: true
   type: ClusterIP
-  # Only used if service.type is NodePort
-  nodePort:
   ## Kyverno's metrics server will be exposed at this port
-  metricsPort: 8000
+  port: 8000
   ## The Node's port which will allow access Kyverno's metrics at the host level. Only used if service.type is NodePort.
-  metricsNodePort: 8000
+  nodePort:
   ## Provide any additional annotations which may be required. This can be used to
   ## set the LoadBalancer service type to internal only.
   ## ref: https://kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer
@@ -36,20 +34,41 @@ service:
 ```
 
 By default, the service type is going to be `ClusterIP` meaning that the metrics would be only capable of being scraped by a Prometheus server sitting inside the cluster. <br>
-But speculatively, in majority of the cases, the Prometheus server would be kept outside the cluster as an isolated component. In those kinds of scenarios, you would want the `kyverno-svc` service to be publicly exposed so as to expose the metrics (available at port 8000) to your Prometheus server sitting outside the cluster.<br>
-
-To do so, either you can expose the `kyverno-svc` service as NodePort or LoadBalancer.
-That can be done via the `values.yaml` file itself which is provided at the time of helm installation.
+But speculatively, in majority of the cases, the Prometheus server would be kept outside the cluster as an isolated component. In those kinds of scenarios, you would want the `kyverno-svc-metrics` service to be publicly exposed so as to expose the metrics (available at port 8000) to your Prometheus server sitting outside the cluster.<br>
 
+Hence, to expose your `kyverno-svc-metrics` service publicly as `NodePort` at host's/node's port number 8000, you can configure your values.yaml before helm installation as described below:
 ```sh
 ...
-service:
+metricsService:
+  create: true
   type: NodePort
-  metricsPort: 8000
-  metricsNodePort: 8000
+  ## Kyverno's metrics server will be exposed at this port
+  port: 8000
+  ## The Node's port which will allow access Kyverno's metrics at the host level. Only used if service.type is NodePort.
+  nodePort: 8000
+  ## Provide any additional annotations which may be required. This can be used to
+  ## set the LoadBalancer service type to internal only.
+  ## ref: https://kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer
+  ##
+  annotations: {}
+...
+```
+Or, if you want to expose your `kyverno-svc-metrics` service publicly as `LoadBalancer`, you can configure your values.yaml before helm installation as described below:
+```sh
+...
+metricsService:
+  create: true
+  type: LoadBalancer
+  ## Kyverno's metrics server will be exposed at this port
+  port: 8000
+  ## The Node's port which will allow access Kyverno's metrics at the host level. Only used if service.type is NodePort.
+  nodePort: 
+  ## Provide any additional annotations which may be required. This can be used to
+  ## set the LoadBalancer service type to internal only.
+  ## ref: https://kubernetes.io/docs/concepts/services-networking/service/#internal-load-balancer
+  ##
+  annotations: {}
 ...
 ```
-
-The above configuration will allow Kyverno's metrics to be exposed at port 8000 of any host/node of the cluster.
 
 ## Metrics and a ready-to-use Grafana Dashboard

content/en/docs/Monitoring Kyverno With Prometheus Metrics/admission-review-latency.md

@@ -1,9 +1,13 @@
 ---
-title: kyverno_admission_review_latency_milliseconds
+title: Admission Review Latency
 description: This metric can be used to track the end-to-end latencies associated with the entire individual admission review, corresponding to the incoming resource request triggering a bunch of policies and rules.
-weight: 2
+weight: 40
 ---
 
+**Metric Name**
+
+kyverno_admission_review_latency_milliseconds
+
 **Metric Value**
 
 A float value representing the latency of the admission review in milliseconds.

content/en/docs/Monitoring Kyverno With Prometheus Metrics/bonus-grafana-dashboard.md

@@ -1,7 +1,7 @@
 ---
 title: "Grafana Dashboard" 
 description: A ready-to-use dashboard depicting insights from Kyverno metrics.
-weight: 2
+weight: 60
 ---
 
 ## Setup

content/en/docs/Monitoring Kyverno With Prometheus Metrics/policy-changes-info.md

@@ -1,9 +1,13 @@
 ---
-title: kyverno_policy_changes_info
+title: Information around Policy-level changes
 description: This metric can be used to track the history of all the Kyverno policies-related changes such as policy creations, updations and deletions.
-weight: 2
+weight: 50
 ---
 
+**Metric Name**
+
+kyverno_policy_changes_info
+
 **Metric Value**
 
 1 - Constant value serving no purpose

content/en/docs/Monitoring Kyverno With Prometheus Metrics/policy-rule-execution-latency.md

@@ -1,9 +1,13 @@
 ---
-title: kyverno_policy_rule_execution_latency_milliseconds
+title: Rule execution latency
 description: This metric can be used to track the latencies associated with the execution/processing of the individual rules whenever they evaluate incoming resource requests or execute background scans.
-weight: 2
+weight: 30
 ---
 
+**Metric Name**
+
+kyverno_policy_rule_execution_latency_milliseconds
+
 **Metric Value**
 
 A float value representing the latency of the rule's execution in milliseconds.

content/en/docs/Monitoring Kyverno With Prometheus Metrics/policy-rule-info-total.md

@@ -1,9 +1,13 @@
 ---
-title: kyverno_policy_rule_info_total
+title: Information around Policies and Rules
 description: This metric can be used to track the number of policies as well as rules present in the cluster which are currently active and even the ones which are not currently active but were created in the past.
-weight: 2
+weight: 10
 ---
 
+**Metric Name**
+
+kyverno_policy_rule_info_total
+
 **Metric Value**
 
 * 0 - if the rule is not anymore present in the cluster (although it was created in the past).

content/en/docs/Monitoring Kyverno With Prometheus Metrics/policy-rule-results-info.md

@@ -1,9 +1,13 @@
 ---
-title: kyverno_policy_rule_results_info
+title: Information around results of Rule/Policy executions
 description: This metric can be used to track the results associated with the rule executing as a part of incoming resource requests and even background scans.
-weight: 2
+weight: 20
 ---
 
+**Metric Name**
+
+kyverno_policy_rule_results_info
+
 **Metric Value**
 
 1 - Constant value serving no purpose