Merge pull request #19 from marioferh/fix_markdown

fix markdown

Author: marioferh

docs/index.md

@@ -64,8 +64,7 @@ Thank you for visiting the official documentation. Here you'll find all the info
 - [Additional Configuration](prometheus-operator/additional-scrape-config.md)
 - [Platform Specific Guides](prometheus-operator/platform/)
 - [Developer Documentation](prometheus-operator/developer/)
-
----
+## 
 
 ## Introduction
 
@@ -76,7 +75,6 @@ Key features:
 - Service discovery and monitoring
 - Custom resource definitions for monitoring configuration
 - Integration with various platforms and environments
-
----
+## 
 
 If you have any questions or suggestions, feel free to contact us.

docs/introduction.md

@@ -10,18 +10,17 @@ lastmod: "2020-10-06T08:48:57+00:00"
 images: []
 draft: false
 description: The Prometheus Operator provides Kubernetes native deployment and management of Prometheus and related monitoring components
-date: "2020-10-06T08:48:57+00:00"
----
+## date: "2020-10-06T08:48:57+00:00"
 
 Prometheus Operator is a [Kubernetes Operator](https://github.com/cncf/tag-app-delivery/blob/main/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md#foundation) that provides Kubernetes native deployment and management of [Prometheus](https://prometheus.io/) and related monitoring components.
 
 The Prometheus operator includes, but is not limited to, the following features:
 
-- **Kubernetes Custom Resources**: Use Kubernetes custom resources to deploy and manage Prometheus, Alertmanager, and related components.
+- __Kubernetes Custom Resources__: Use Kubernetes custom resources to deploy and manage Prometheus, Alertmanager, and related components.
 
-- **Simplified Deployment Configuration**: Configure the fundamentals of Prometheus like versions, persistence, retention policies, and replicas from a native Kubernetes resource.
+- __Simplified Deployment Configuration__: Configure the fundamentals of Prometheus like versions, persistence, retention policies, and replicas from a native Kubernetes resource.
 
-- **Prometheus Target Configuration**: Automatically generate monitoring target configurations based on familiar Kubernetes label queries; no need to learn a Prometheus specific configuration language.
+- __Prometheus Target Configuration__: Automatically generate monitoring target configurations based on familiar Kubernetes label queries; no need to learn a Prometheus specific configuration language.
 
 Prometheus Operator provides a set of Custom Resource Definitions(CRDs) that allows you to configure your Prometheus and related instances. Currently, the CRDs provided by Prometheus Operator are:
 
@@ -42,11 +41,11 @@ Prometheus Operator provides a set of Custom Resource Definitions(CRDs) that all
 
 - To significantly reduce the effort required to configure, implement and manage all components of Prometheus based monitoring stack.
 
-- **Automation** - Automate the management of Prometheus monitoring targets, ultimately increasing efficiency. This automation is performed by the use of Kubernetes [Custom Resource Definition](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). The Operator introduces custom resources like `Prometheus`, `Alertmanager`, `ThanosRuler`, and others, which help automate the deployment and configuration of these resources.
+- __Automation__ - Automate the management of Prometheus monitoring targets, ultimately increasing efficiency. This automation is performed by the use of Kubernetes [Custom Resource Definition](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). The Operator introduces custom resources like `Prometheus`, `Alertmanager`, `ThanosRuler`, and others, which help automate the deployment and configuration of these resources.
 
-- **Configuration Abstraction and Validation** - Instead of learning and manually writing Prometheus Relabeling rules (which can be time consuming), you can simply use Kubernetes [Label Selectors](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors). `ServiceMonitor`, `PodMonitor` and `Probe` custom resources provide this abstraction. The Operator also removes the complexity of validating the configuration of `AlertmanagerConfig` and `PrometheusRule` objects.
+- __Configuration Abstraction and Validation__ - Instead of learning and manually writing Prometheus Relabeling rules (which can be time consuming), you can simply use Kubernetes [Label Selectors](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors). `ServiceMonitor`, `PodMonitor` and `Probe` custom resources provide this abstraction. The Operator also removes the complexity of validating the configuration of `AlertmanagerConfig` and `PrometheusRule` objects.
 
-- **Scaling** - There are many scaling-related features provided by the Operator like [ThanosRuler](https://prometheus-operator.dev/docs/platform/thanos/#thanos-ruler) custom resource for rule evaluation, workload distribution across multiple Prometheus instances using scrape target sharding, and running [Thanos sidecar](https://thanos.io/v0.4/components/sidecar/) in Prometheus instance for long-term storage.
+- __Scaling__ - There are many scaling-related features provided by the Operator like [ThanosRuler](https://prometheus-operator.dev/docs/platform/thanos/#thanos-ruler) custom resource for rule evaluation, workload distribution across multiple Prometheus instances using scrape target sharding, and running [Thanos sidecar](https://thanos.io/v0.4/components/sidecar/) in Prometheus instance for long-term storage.
 
 ### Next Steps
 

docs/openshift/monitoring-about-accessing-monitoring-web-service-apis.md

@@ -9,10 +9,8 @@ You can directly access web service API endpoints from the command line for the
 * Thanos Ruler
 * Thanos Querier
 
-[IMPORTANT]
-====
-To access Thanos Ruler and Thanos Querier service APIs, the requesting account must have `get` permission on the namespaces resource, which can be granted by binding the `cluster-monitoring-view` cluster role to the account.
-====
+# [IMPORTANT]
+# To access Thanos Ruler and Thanos Querier service APIs, the requesting account must have `get` permission on the namespaces resource, which can be granted by binding the `cluster-monitoring-view` cluster role to the account.
 
 When you access web service API endpoints for monitoring components, be aware of the following limitations:
 

docs/openshift/monitoring-about-cluster-monitoring.md

@@ -3,8 +3,6 @@
 ifeval::["{context}" == "understanding-the-monitoring-stack"]
 :ocp-monitoring:
 
-
-
 # About OpenShift monitoring
 
 :ocp-monitoring!:
@@ -13,12 +11,9 @@ OpenShift includes a preconfigured, preinstalled, and self-updating monitoring s
 
 After installing OpenShift , cluster administrators can optionally enable *monitoring for user-defined projects*. By using this feature, cluster administrators, developers, and other users can specify how services and pods are monitored in their own projects. You can then query metrics, review dashboards, and manage alerting rules and silences for your own projects in the OpenShift web console.
 
-[NOTE]
-====
-Cluster administrators can grant developers and other users permission to monitor their own projects. Privileges are granted by assigning one of the predefined monitoring roles.
-====
+# [NOTE]
+# Cluster administrators can grant developers and other users permission to monitor their own projects. Privileges are granted by assigning one of the predefined monitoring roles.
 
 [id="about-openshift-monitoring_{context}"]
 ifeval::["{context}" == "understanding-the-monitoring-stack"]
 :!ocp-monitoring:
-

docs/openshift/monitoring-about-creating-alerting-rules-for-user-defined-projects.md

@@ -17,11 +17,6 @@ However, the rule cannot include metrics from a different `ns2` user-defined pro
 * To reduce latency and to minimize the load on core platform monitoring components, you can add the `openshift.io/prometheus-rule-evaluation-scope: leaf-prometheus` label to a rule.
 This label forces only the Prometheus instance deployed in the `openshift-user-workload-monitoring` project to evaluate the alerting rule and prevents the Thanos Ruler instance from doing so.
 +
-[IMPORTANT]
-====
+# [IMPORTANT]
 If an alerting rule has this label, your alerting rule can use only those metrics exposed by your user-defined project.
-Alerting rules you create based on default platform metrics might not trigger alerts.
-====
-
-
-
+# Alerting rules you create based on default platform metrics might not trigger alerts.

docs/openshift/monitoring-about-managing-alerts.md

@@ -8,7 +8,5 @@ In the OpenShift, the Alerting UI enables you to manage alerts, silences, and al
 * *Alerts*. An alert is fired when the conditions defined in an alerting rule are true. Alerts provide a notification that a set of circumstances are apparent within an OpenShift cluster.
 * *Silences*. A silence can be applied to an alert to prevent notifications from being sent when the conditions for an alert are true. You can mute an alert after the initial notification, while you work on resolving the issue.
 
-[NOTE]
-====
-The alerts, silences, and alerting rules that are available in the Alerting UI relate to the projects that you have access to. For example, if you are logged in as a user with the `cluster-admin` role, you can access all alerts, silences, and alerting rules.
-====
+# [NOTE]
+# The alerts, silences, and alerting rules that are available in the Alerting UI relate to the projects that you have access to. For example, if you are logged in as a user with the `cluster-admin` role, you can access all alerts, silences, and alerting rules.

docs/openshift/monitoring-about-monitoring-dashboards.md

@@ -21,4 +21,4 @@ image::monitoring-dashboard-administrator.png[]
 In the *Developer* perspective, you can access only the Kubernetes compute resources dashboards:
 
 .Example dashboard in the Developer perspective
-image::observe-dashboard-developer.png[]
+image::observe-dashboard-developer.png[]

docs/openshift/monitoring-about-specifying-limits-and-requests-for-monitoring-components.md

@@ -23,4 +23,4 @@ You can configure resource limits and requests for the following components that
 
 By defining the resource limits, you limit a container's resource usage, which prevents the container from exceeding the specified maximum values for CPU and memory resources.
 
-By defining the resource requests, you specify that a container can be scheduled only on a node that has enough CPU and memory resources available to match the requested resources.
+By defining the resource requests, you specify that a container can be scheduled only on a node that has enough CPU and memory resources available to match the requested resources.

docs/openshift/monitoring-accessing-alerting-rules-for-your-project.md

@@ -14,12 +14,16 @@ To list alerting rules for a user-defined project, you must have been assigned t
 
 . To list alerting rules in `<project>`:
 +
+
 ```terminal
 $ oc -n <project> get prometheusrule
+
 ```
 
 . To list the configuration of an alerting rule, run the following:
 +
+
 ```terminal
 $ oc -n <project> get prometheusrule <rule> -o yaml
+
 ```

docs/openshift/monitoring-accessing-the-alerting-ui.md

@@ -1,44 +1,25 @@
 :_mod-docs-content-type: PROCEDURE
 
-
-
-
 [id="monitoring-accessing-the-alerting-ui-adm_{context}"]
 # Accessing the Alerting UI from the Administrator perspective
 
-
-
 [id="monitoring-accessing-the-alerting-ui-dev_{context}"]
 # Accessing the Alerting UI from the Developer perspective
 
-
-
-
-
 :perspective: Administrator
 
-
-
 :perspective: Developer
 
-
 The Alerting UI is accessible through the *{perspective}* perspective of the OpenShift web console.
 
-
 * From the *Administrator* perspective, go to *Observe* -> *Alerting*. The three main pages in the Alerting UI in this perspective are the *Alerts*, *Silences*, and *Alerting rules* pages.
 
-
-
 * From the *Developer* perspective, go to *Observe* and go to the *Alerts* tab.
 * Select the project that you want to manage alerts for from the *Project:* list. 
 
 In this perspective, alerts, silences, and alerting rules are all managed from the *Alerts* tab. The results shown in the *Alerts* tab are specific to the selected project.
 
-[NOTE]
-====
-In the *Developer* perspective, you can select from core OpenShift and user-defined projects that you have access to in the *Project: <project_name>* list. However, alerts, silences, and alerting rules relating to core OpenShift projects are not displayed if you are not logged in as a cluster administrator.
-====
-
-
+# [NOTE]
+# In the *Developer* perspective, you can select from core OpenShift and user-defined projects that you have access to in the *Project: <project_name>* list. However, alerts, silences, and alerting rules relating to core OpenShift projects are not displayed if you are not logged in as a cluster administrator.
 
 :!perspective: