Add mdox link checking and formatting

Signed-off-by: Saswata Mukherjee <[email protected]>

Author: saswatamcode

ADOPTERS.md

@@ -1,7 +1,7 @@
 ---
-title: "Adopters"
-date: 2021-03-08T23:50:39+01:00
+title: Adopters
 draft: false
+date: "2021-03-08T23:50:39+01:00"
 ---
 
 <!--
@@ -27,7 +27,7 @@ This document tracks people and use cases for the Prometheus Operator in product
 
 Go ahead and [add your organization](https://github.com/prometheus-operator/prometheus-operator/edit/master/ADOPTERS.md) to the list.
 
-## Clyso 
+## Clyso
 
 [clyso.com](https://www.clyso.com/en)
 
@@ -83,7 +83,7 @@ Details:
 - 20000 samples/s
 - 1M active series
 
-## Innovaccer ##
+## Innovaccer
 
 https://innovaccer.com/
 

CHANGELOG.md

@@ -2,7 +2,7 @@
 
 No change since v0.51.0.
 
-_The CI automation failed to build the v0.51.0 images so we had to create a new patch release._
+*The CI automation failed to build the v0.51.0 images so we had to create a new patch release.*
 
 ## 0.51.0 / 2021-09-24
 
@@ -181,11 +181,12 @@ future.
 
 ## 0.42.1 / 2020-09-21
 
-* [BUGFIX] Bump client-go to fix watch bug 
+* [BUGFIX] Bump client-go to fix watch bug
 
 ## 0.42.0 / 2020-09-09
 
-The Prometheus Operator now lives in its own independent GitHub organization.  
+The Prometheus Operator now lives in its own independent GitHub organization.
+
 We have also added a governance (#3398).
 
 * [FEATURE] Move API types out into their own module (#3395)
@@ -230,12 +231,12 @@ We have also added a governance (#3398).
 
 * [CHANGE] Update dependencies to prometheus 2.18 (#3231)
 * [CHANGE] Add support for new prometheus versions (v2.18 & v2.19) (#3284)
-* [CHANGE] bump Alertmanager default version to v0.21.0 (#3286) 
+* [CHANGE] bump Alertmanager default version to v0.21.0 (#3286)
 * [FEATURE] Automatically disable high availability mode for 1 replica alertmanager (#3233)
 * [FEATURE] thanos-sidecar: Add minTime arg (#3253)
-* [FEATURE] Add scrapeTimeout as global configurable parameter (#3250) 
-* [FEATURE] Add EnforcedSampleLimit which enforces a global sample limit (#3276) 
-* [FEATURE] add ability to exclude rules from namespace label enforcement (#3207) 
+* [FEATURE] Add scrapeTimeout as global configurable parameter (#3250)
+* [FEATURE] Add EnforcedSampleLimit which enforces a global sample limit (#3276)
+* [FEATURE] add ability to exclude rules from namespace label enforcement (#3207)
 * [BUGFIX] thanos sidecar: log flags double definition (#3242)
 * [BUGFIX] Mutate rule labels, annotations to strings (#3230)
 
@@ -513,7 +514,7 @@ and accepts and comma-separated list of namespaces as a string.
 ## 0.22.0 / 2018-07-09
 
 * [FEATURE] Allow setting volume name via volumetemplateclaimtemplate in prom and alertmanager (#1538)
-* [FEATURE] Allow setting custom tags of container images (#1584) 
+* [FEATURE] Allow setting custom tags of container images (#1584)
 * [ENHANCEMENT] Update default Thanos to v0.1.0-rc.2 (#1585)
 * [ENHANCEMENT] Split rule config map mounted into Prometheus if it exceeds Kubernetes config map limit (#1562)
 * [BUGFIX] Mount Prometheus data volume into Thanos sidecar & pass correct path to Thanos sidecar (#1583)

CONTRIBUTING.md

@@ -1,20 +1,20 @@
 ---
-title: "Contributing"
-description: "How can I contribute to the Prometheus Operator and kube-prometheus?"
-lead: ""
-date: 2021-03-08T08:48:57+00:00
-lastmod: 2021-03-08T08:48:57+00:00
-draft: false
-images: []
-menu:
-  docs:
-    parent: "prologue"
 weight: 200
 toc: true
+title: Contributing
+menu:
+    docs:
+        parent: prologue
+lead: ""
+lastmod: "2021-03-08T08:48:57+00:00"
+images: []
+draft: false
+description: How can I contribute to the Prometheus Operator and kube-prometheus?
+date: "2021-03-08T08:48:57+00:00"
 ---
 
 This project is licensed under the [Apache 2.0 license](LICENSE) and accept
-contributions via GitHub pull requests.  This document outlines some of the
+contributions via GitHub pull requests. This document outlines some of the
 conventions on development workflow, commit message formatting, contact points
 and other resources to make it easier to get your contribution accepted.
 

Documentation/additional-scrape-config.md

@@ -5,8 +5,7 @@ additional Prometheus scrape configurations. Scrape configurations specified
 are appended to the configurations generated by the Prometheus Operator.
 
 Job configurations specified must have the form as specified in the official
-[Prometheus documentation](
-https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config).
+[Prometheus documentation](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config).
 As scrape configs are appended, the user is responsible to make sure it is
 valid. *Note* that using this feature may expose the possibility to break
 upgrades of Prometheus.
@@ -17,7 +16,7 @@ scrape configs are going to break Prometheus after the upgrade.
 ## Creating an additional configuration
 
 First, you will need to create the additional configuration.
-Below we are making a simple "prometheus" config.  Name this
+Below we are making a simple "prometheus" config. Name this
 `prometheus-additional.yaml` or something similar.
 
 ```yaml
@@ -62,5 +61,5 @@ NOTE: Use only one secret for ALL additional scrape configurations.
 
 ## Additional References
 
- * [Prometheus Spec](api.md#prometheusspec)
- * [Additional Scrape Configs](../example/additional-scrape-configs)
+* [Prometheus Spec](api.md#prometheusspec)
+* [Additional Scrape Configs](../example/additional-scrape-configs)

Documentation/custom-configuration.md

@@ -3,9 +3,7 @@
     <i class="fa fa-exclamation-triangle"></i><b> Note:</b> Starting with v0.39.0, Prometheus Operator requires use of Kubernetes v1.16.x and up.
 </div>
 
-
-**Deprecation Warning:** The _custom configuration_ option of the Prometheus Operator will be deprecated in favor of the [_additional scrape config_](additional-scrape-config.md) option.
-
+**Deprecation Warning:** The *custom configuration* option of the Prometheus Operator will be deprecated in favor of the [*additional scrape config*](additional-scrape-config.md) option.
 
 # Custom Configuration
 

Documentation/design.md

@@ -1,15 +1,15 @@
 ---
-title: "Design"
-description: "This document describes the design and interaction between the custom resource definitions that the Prometheus Operator introduces."
-lead: ""
-date: 2021-03-08T08:49:31+00:00
-draft: false
-images: []
-menu:
-  docs:
-    parent: "operator"
 weight: 100
 toc: true
+title: Design
+menu:
+    docs:
+        parent: operator
+lead: ""
+images: []
+draft: false
+description: This document describes the design and interaction between the custom resource definitions that the Prometheus Operator introduces.
+date: "2021-03-08T08:49:31+00:00"
 ---
 
 This document describes the design and interaction between the custom resource definitions that the Prometheus Operator introduces.
@@ -35,7 +35,6 @@ The CRD specifies which `ServiceMonitor`s should be covered by the deployed Prom
 
 If no selection of `ServiceMonitor`s is provided, the Operator leaves management of the `Secret` to the user, which allows to provide custom configurations while still benefiting from the Operator's capabilities of managing Prometheus setups.
 
-
 ## Alertmanager
 
 The `Alertmanager` custom resource definition (CRD) declaratively defines a desired Alertmanager setup to run in a Kubernetes cluster. It provides options to configure replication and persistent storage.
@@ -44,15 +43,13 @@ For each `Alertmanager` resource, the Operator deploys a properly configured `St
 
 When there are two or more configured replicas the operator runs the Alertmanager instances in high availability mode.
 
-
 ## ThanosRuler
 
 The `ThanosRuler` custom resource definition (CRD) declaratively defines a desired [Thanos Ruler](https://github.com/thanos-io/thanos/blob/master/docs/components/rule.md) setup to run in a Kubernetes cluster. With Thanos Ruler recording and alerting rules can be processed across multiple Prometheus instances.
 
-A `ThanosRuler` instance requires at least one `queryEndpoint` which points to the location of Thanos Queriers or Prometheus instances.  The `queryEndpoints` are used to configure the `--query` arguments(s) of the Thanos runtime.
+A `ThanosRuler` instance requires at least one `queryEndpoint` which points to the location of Thanos Queriers or Prometheus instances. The `queryEndpoints` are used to configure the `--query` arguments(s) of the Thanos runtime.
 Further information can also be found in the [Thanos doc](thanos.md).
 
-
 ## ServiceMonitor
 
 The `ServiceMonitor` custom resource definition (CRD) allows to declaratively define how a dynamic set of services should be monitored. Which services are selected to be monitored with the desired configuration is defined using label selections. This allows an organization to introduce conventions around how metrics are exposed, and then following these conventions new services are automatically discovered, without the need to reconfigure the system.
@@ -69,13 +66,13 @@ The `endpoints` section of the `ServiceMonitorSpec`, is used to configure which
 
 Both `ServiceMonitors` as well as discovered targets may come from any namespace. This is important to allow cross-namespace monitoring use cases, e.g. for meta-monitoring. Using the `ServiceMonitorNamespaceSelector` of the `PrometheusSpec`, one can restrict the namespaces `ServiceMonitor`s are selected from by the respective Prometheus server. Using the `namespaceSelector` of the `ServiceMonitorSpec`, one can restrict the namespaces the `Endpoints` objects are allowed to be discovered from.
 To discover targets in all namespaces the `namespaceSelector` has to be empty:
+
 ```yaml
 spec:
   namespaceSelector:
     any: true
 ```
 
-
 ## PodMonitor
 
 The `PodMonitor` custom resource definition (CRD) allows to declaratively define how a dynamic set of pods should be monitored.
@@ -91,26 +88,23 @@ The `PodMetricsEndpoints` section of the `PodMonitorSpec`, is used to configure
 Both `PodMonitors` as well as discovered targets may come from any namespace. This is important to allow cross-namespace monitoring use cases, e.g. for meta-monitoring.
 Using the `namespaceSelector` of the `PodMonitorSpec`, one can restrict the namespaces the `Pods` are allowed to be discovered from.
 To discover targets in all namespaces the `namespaceSelector` has to be empty:
+
 ```yaml
 spec:
   namespaceSelector:
     any: true
 ```
 
-
 ## Probe
 
 The `Probe` custom resource definition (CRD) allows to declarative define how groups of ingresses and static targets should be monitored. Besides the target, the `Probe` object requires a `prober` which is the service that monitors the target and provides metrics for Prometheus to scrape. This could be for example achieved using the [blackbox exporter](https://github.com/prometheus/blackbox_exporter/).
 
-
 ## PrometheusRule
 
 The `PrometheusRule` custom resource definition (CRD) declaratively defines a desired Prometheus rule to be consumed by one or more Prometheus instances.
 
 Alerts and recording rules can be saved and applied as YAML files, and dynamically loaded without requiring any restart.
 
-
 ## AlertmanagerConfig
 
 The `AlertmanagerConfig` custom resource definition (CRD) declaratively specifies subsections of the Alertmanager configuration, allowing routing of alerts to custom receivers, and setting inhibit rules. The `AlertmanagerConfig` can be defined on a namespace level providing an aggregated config to Alertmanager. An example on how to use it is provided [here](../example/user-guides/alerting/alertmanager-config-example.yaml). Please be aware that this CRD is not stable yet.
-

Documentation/exposing-metrics.md

@@ -13,7 +13,7 @@ Not all software is natively instrumented with Prometheus metrics, but still rec
 
 Exporters can generally be divided into two categories:
 
-* Instance exporters: These expose metrics about a single instance of an application. For example the HTTP requests that a single HTTP server has exporters served. These exporters are deployed as a [side-car](http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html) container in the same pod as the actual instance of the respective application.  A real life example is the [`dnsmasq` metrics sidecar](https://github.com/kubernetes/dns/blob/master/docs/sidecar/README.md), which converts the proprietary metrics format communicated over the DNS protocol by `dnsmasq` to the Prometheus exposition format and exposes it on an HTTP server.
+* Instance exporters: These expose metrics about a single instance of an application. For example the HTTP requests that a single HTTP server has exporters served. These exporters are deployed as a [side-car](http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html) container in the same pod as the actual instance of the respective application. A real life example is the [`dnsmasq` metrics sidecar](https://github.com/kubernetes/dns/blob/master/docs/sidecar/README.md), which converts the proprietary metrics format communicated over the DNS protocol by `dnsmasq` to the Prometheus exposition format and exposes it on an HTTP server.
 
 * Cluster-state exporters: These expose metrics about an entire system. For example these could be the number of 3D objects in a game, or metrics about a Kubernetes deployment. These exporters are typically deployed as a normal Kubernetes deployment, but can vary depending on the nature of the particular exporter. A real life example of this is the [`kube-state-metrics`](https://github.com/kubernetes/kube-state-metrics) exporter, which exposes metrics about the cluster state of a Kubernetes cluster.
 

Documentation/high-availability.md

@@ -1,15 +1,15 @@
 ---
-title: "High Availability"
-description: "High Availability is a must for the monitoring infrastructure."
-lead: ""
-date: 2021-03-08T08:49:31+00:00
-draft: false
-images: []
-menu:
-  docs:
-    parent: "operator"
 weight: 300
 toc: true
+title: High Availability
+menu:
+    docs:
+        parent: operator
+lead: ""
+images: []
+draft: false
+description: High Availability is a must for the monitoring infrastructure.
+date: "2021-03-08T08:49:31+00:00"
 ---
 
 High availability is not only important for customer facing software, but if the monitoring infrastructure is not highly available, then there is a risk that operations people are not notified for alerts of the customer facing software. Therefore high availability must be just as thought through for the monitoring stack, as for anything else.
@@ -26,7 +26,7 @@ One of the goals with the Prometheus Operator is that we want to completely auto
 
 The final step of the high availability scheme between Prometheus and Alertmanager is that Prometheus, when an alert triggers, actually fires alerts against *all* instances of an Alertmanager cluster. Prometheus can discover all Alertmanagers through the Kubernetes API.
 
-The Alertmanager, starting with the `v0.5.0` release, ships with a high availability mode. It implements a gossip protocol to synchronize instances of an Alertmanager cluster regarding notifications that have been sent out, to prevent duplicate notifications. It is an AP (available and partition tolerant) system. Being an AP system, means that notifications are guaranteed to be sent at least once. 
+The Alertmanager, starting with the `v0.5.0` release, ships with a high availability mode. It implements a gossip protocol to synchronize instances of an Alertmanager cluster regarding notifications that have been sent out, to prevent duplicate notifications. It is an AP (available and partition tolerant) system. Being an AP system, means that notifications are guaranteed to be sent at least once.
 
 The Prometheus Operator ensures that Alertmanager clusters are properly configured to run highly available on Kubernetes, and allows easy configuration of Alertmanagers discovery for Prometheus.
 

Documentation/network-policies.md

@@ -16,6 +16,7 @@ This example will close all inbound communication on the namespace monitoring, a
 First, follow the instructions to [add Calico to an existing Kubernetes cluster](http://docs.projectcalico.org/v1.5/getting-started/kubernetes/installation/).
 
 Next, use the following configuration to deny all the ingress (inbound) traffic.
+
 ```yaml
  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
@@ -26,6 +27,7 @@ Next, use the following configuration to deny all the ingress (inbound) traffic.
    podSelector:
      matchLabels:
 ```
+
 Save the config file as default-deny-all.yaml and apply the configuration to the cluster using
 
 ```sh

Documentation/rbac-crd.md

@@ -1,15 +1,15 @@
 ---
-title: "RBAC for CRDs"
-description: "Aggregate permissions on the Prometheus Operator CustomResourceDefinitions."
+weight: 420
+toc: true
+title: RBAC for CRDs
+menu:
+    docs:
+        parent: operator
 lead: ""
-date: 2021-03-08T08:49:31+00:00
-draft: false
 images: []
-menu:
-  docs:
-    parent: "operator"
-weight: 420 # nice
-toc: true
+draft: false
+description: Aggregate permissions on the Prometheus Operator CustomResourceDefinitions.
+date: "2021-03-08T08:49:31+00:00"
 ---
 
 ## Aggregated ClusterRoles
@@ -18,11 +18,11 @@ It can be useful to aggregate permissions on the Prometheus Operator CustomResou
 
 This can be achieved using ClusterRole aggregation. This lets admins include rules for custom resources, such as those served by CustomResourceDefinitions or Aggregated API servers, on the default roles.
 
-> Note: ClusterRole aggregation is available starting Kubernetes 1.9. 
+> Note: ClusterRole aggregation is available starting Kubernetes 1.9.
 
 ## Example
 
-In order to aggregate _read_ (resp. _edit_) permissions for the Prometheus Operator CustomResourceDefinitions to the `view` (resp. `edit` / `admin`) role(s), a cluster admin can create the `ClusterRole`s below.
+In order to aggregate *read* (resp. *edit*) permissions for the Prometheus Operator CustomResourceDefinitions to the `view` (resp. `edit` / `admin`) role(s), a cluster admin can create the `ClusterRole`s below.
 
 This grants:
 - Users with `view` role permissions to view the Prometheus Operator CRDs within their namespaces,