fix invalid code blocks (#20401)

* fix invalid code blocks

* fix invalid tag blocks

* Fix tabs

---------

Co-authored-by: hestonhoffman <hestonhoffman@gmail.com>

Author: bgoldberg122

ibm_mq/README.md

@@ -141,10 +141,10 @@ There are many ways to set up permissions in IBM MQ. Depending on how your setup
 
 The example below sets the required permissions on the queue manager `QM1` for the `mqclient` group, the group the `datadog` user is using to execute commands. You can use wildcards to grant permissions to many queues at once.
 
-{{< code-block lang="shell" >}}
+```shell
 setmqaut -m QM1 -n SYSTEM.ADMIN.COMMAND.QUEUE -t queue -g mqclient +dsp +inq +get +put
 setmqaut -m QM1 -n SYSTEM.MQEXPLORER.REPLY.MODEL -t queue -g mqclient +dsp +inq +get +put
-{{< /code-block >}}
+```
 
 **Note**: "Queue Monitoring" must be enabled on the MQ server and set to at least "Medium". This can be done using the MQ UI or with an `mqsc` command in the server's host:
 
@@ -184,15 +184,15 @@ To configure this check for an Agent running on a host:
    - `port`: The port that IBM MQ has exposed
    - `convert_endianness`: You need to enable this if your MQ server is running on AIX or IBM i
 
-    If you are using a username and password setup, you can set the `username` and `password`. If no username is set, the Agent process owner (`dd-agent`) is used.
+   If you are using a username and password setup, you can set the `username` and `password`. If no username is set, the Agent process owner (`dd-agent`) is used.
 
-    **Note**: The check only monitors the queues you have set with the `queues` parameter
+   **Note**: The check only monitors the queues you have set with the `queues` parameter
 
-    ```yaml
-    queues:
-      - APP.QUEUE.1
-      - ADMIN.QUEUE.1
-    ```
+   ```yaml
+   queues:
+     - APP.QUEUE.1
+     - ADMIN.QUEUE.1
+   ```
 
 2. [Restart the Agent][6].
 
@@ -271,40 +271,43 @@ See [service_checks.json][11] for a list of service checks provided by this inte
 ## Troubleshooting
 
 ### Reset queue statistics MQRC_NOT_AUTHORIZED permission warning
+
 If you are getting the following warning:
 
 ```
 Warning: Error getting pcf queue reset metrics for SAMPLE.QUEUE.1: MQI Error. Comp: 2, Reason 2035: FAILED: MQRC_NOT_AUTHORIZED
 ```
 
 This is due to the `datadog` user not having the `+chg` permission to collect reset queue metrics. To fix this, you can either give `+chg` permissions to the `datadog` user [using `setmqaut`][15] and collect queue reset metrics, or you can disable the `collect_reset_queue_metrics`:
+
 ```yaml
-    collect_reset_queue_metrics: false
+collect_reset_queue_metrics: false
 ```
 
 ### High resource utilization
+
 The IBM MQ check performs queries on the server, sometimes these queries can be expensive and cause a degradation on the check.
 
 If you observe that the check is taking a long time to execute or that is consuming many resources on your host,
 you can potentially reduce the scope of the check by trying the following:
 
-* If you are using `auto_discover_queues`, try using `queue_patterns` or `queue_regex` instead to only discover certain queues. This is particularly relevant if your system creates dynamic queues.
-* If you are autodiscovering queues with `queue_patterns` or `queue_regex`, try tightening the pattern or regex so it matches _less_ queues.
-* Disable `auto_discover_channels` if you have too many channels.
-* Disable `collect_statistics_metrics`.
+- If you are using `auto_discover_queues`, try using `queue_patterns` or `queue_regex` instead to only discover certain queues. This is particularly relevant if your system creates dynamic queues.
+- If you are autodiscovering queues with `queue_patterns` or `queue_regex`, try tightening the pattern or regex so it matches _less_ queues.
+- Disable `auto_discover_channels` if you have too many channels.
+- Disable `collect_statistics_metrics`.
 
 ### Errors in the logs
-* `Unpack for type ((67108864,)) not implemented`: If you're seeing errors like this, and your MQ server is running on a IBM OS, enable `convert_endianness` and restart your Agent.
+
+- `Unpack for type ((67108864,)) not implemented`: If you're seeing errors like this, and your MQ server is running on a IBM OS, enable `convert_endianness` and restart your Agent.
 
 ### Warnings in the logs
-* `Error getting [...]: MQI Error. Comp: 2, Reason 2085: FAILED: MQRC_UNKNOWN_OBJECT_NAME`: If you're seeing messages like this, it is because the integration is trying to collect metrics from a queue that doesn't exist. This can be either due to misconfiguration or, if you're using `auto_discover_queues`,  the integration can discover a [dynamic queue][16] and then, when it tries to gather its metrics, the queue no longer exists. In this case you can mitigate the issue by providing a stricter `queue_patterns` or `queue_regex`, or just ignore the warning.  
 
+- `Error getting [...]: MQI Error. Comp: 2, Reason 2085: FAILED: MQRC_UNKNOWN_OBJECT_NAME`: If you're seeing messages like this, it is because the integration is trying to collect metrics from a queue that doesn't exist. This can be either due to misconfiguration or, if you're using `auto_discover_queues`, the integration can discover a [dynamic queue][16] and then, when it tries to gather its metrics, the queue no longer exists. In this case you can mitigate the issue by providing a stricter `queue_patterns` or `queue_regex`, or just ignore the warning.
 
 ### Other
 
 Need help? Contact [Datadog support][12].
 
-
 ## Further Reading
 
 Additional helpful documentation, links, and articles:

kube_apiserver_metrics/README.md

@@ -36,8 +36,8 @@ You can review all available configuration options in the [kube_apiserver_metric
 
 You can annotate the kubernetes service in your `default` namespace with the following:
 
-{{< tabs >}}
-{{% tab "Annotations v2 (for Datadog Agent v7.36+)" %}}
+<!-- xxx tabs xxx -->
+<!-- xxx tab "Annotations v2 (for Datadog Agent v7.36)" xxx -->
 
 ```yaml
 ad.datadoghq.com/endpoints.checks: |
@@ -49,11 +49,12 @@ ad.datadoghq.com/endpoints.checks: |
         }
       ]
     }
-  } 
-
+  }
 ```
-{{% /tab %}}
-{{% tab "Annotations v1 (for Datadog Agent < v7.36)" %}}
+
+<!-- xxz tab xxx -->
+
+<!-- xxx tab "Annotations v1 (for Datadog Agent < v7.36)" xxx -->
 
 ```yaml
 annotations:
@@ -62,8 +63,9 @@ annotations:
   ad.datadoghq.com/endpoints.instances:
     '[{ "prometheus_url": "https://%%host%%:%%port%%/metrics"}]'
 ```
-{{% /tab %}}
-{{< /tabs >}}
+
+<!-- xxz tab xxx -->
+<!-- xxz tabs xxx -->
 
 Then the Datadog Cluster Agent schedules the check(s) for each endpoint onto Datadog Agent(s). 
 
@@ -75,8 +77,10 @@ You can also run the check by configuring the endpoints directly in the `kube_ap
 
 Provide a [configuration][13] to your Cluster Agent to setup a Cluster Check:
 
-{{< tabs >}} 
-{{% tab "Helm" %}}
+<!-- xxx tabs xxx -->
+
+<!-- xxx tab "Helm" xxx -->
+
 ```yaml
 clusterAgent:
   confd:
@@ -90,9 +94,10 @@ clusterAgent:
       instances:
         - prometheus_url: "https://%%host%%:%%port%%/metrics"
 ```
-{{% /tab %}}
 
-{{% tab "Operator" %}}
+<!-- xxz tab xxx -->
+
+<!-- xxx tab "Operator" xxx -->
 
 ```yaml
 spec:
@@ -111,8 +116,10 @@ spec:
             instances:
               - prometheus_url: "https://%%host%%:%%port%%/metrics"
 ```
-{{% /tab %}}
-{{< /tabs >}}
+
+<!-- xxz tab xxx -->
+
+<!-- xxz tabs xxx -->
 
 These configurations trigger the Agent to make a request to the `kubernetes` service in the `default` namespace at its defined Endpoint IP Addresses and defined port.