Sy/keda readme (#19510)

* readme

* csv WIP

* metadata entries

* metadata

* metadata units

* Update keda/README.md

Co-authored-by: Janine Chan <64388808+janine-c@users.noreply.github.com>

* Update keda/README.md

Co-authored-by: Janine Chan <64388808+janine-c@users.noreply.github.com>

---------

Co-authored-by: Janine Chan <64388808+janine-c@users.noreply.github.com>

Author: steveny91

keda/README.md

@@ -2,27 +2,107 @@
 
 ## Overview
 
-This check monitors [Keda][1] through the Datadog Agent. 
-
-Include a high level overview of what this integration does:
-- What does your product do (in 1-2 sentences)?
-- What value will customers get from this integration, and why is it valuable to them?
-- What specific data will your integration monitor, and what's the value of that data?
+This check monitors [Keda][1] through the Datadog Agent. For more information, see [Keda monitoring][10].
 
 ## Setup
 
 Follow the instructions below to install and configure this check for an Agent running on a host. For containerized environments, see the [Autodiscovery Integration Templates][3] for guidance on applying these instructions.
 
 ### Installation
 
-The Keda check is included in the [Datadog Agent][2] package.
-No additional installation is needed on your server.
+Starting from Agent release 7.62.0, the Keda check is included in the [Datadog Agent][2] package. No additional installation is needed in your environment.
 
 ### Configuration
 
-1. Edit the `keda.d/conf.yaml` file, in the `conf.d/` folder at the root of your Agent's configuration directory to start collecting your keda performance data. See the [sample keda.d/conf.yaml][4] for all available configuration options.
-
-2. [Restart the Agent][5].
+Keda consists of multiple components, including the Admissions Controller, Metrics API Server, and the Operator. Each of these components can be scraped for metrics. Prometheus-formatted metrics are available at /metrics on port 8080 for each component.
+
+To expose these metrics, ensure that Prometheus scraping is enabled for each component. For example, in Helm, you need to enable the following Helm configuration options:
+- prometheus.metricServer.enabled
+- prometheus.operator.enabled
+- prometheus.webhooks.enabled
+
+Alternatively, you can achieve this by providing the following configuration in a values.yaml file used during the Helm installation of Keda:
+
+```yaml
+prometheus:
+  metricServer:
+    enabled: true
+  operator:
+    enabled: true
+  webhooks:
+    enabled: true
+```
+
+For the Agent to start collecting metrics, the Keda controller pods need to be annotated. For more information about annotations, refer to the [Autodiscovery Integration Templates][3] for guidance. You can find additional configuration options by reviewing the [sample keda.d/conf.yaml][4]. 
+
+**Note**: The listed metrics can only be collected if they are available. Some metrics are generated only when certain actions are performed. For example, the `keda.scaler.detail_errors.count` metric is exposed only after a scaler encountered an error.
+
+The only parameter required for configuring the Keda check is:
+- `openmetrics_endpoint`: This parameter should be set to the location where the Prometheus-formatted metrics are exposed. The default port is `8080`. In containerized environments, `%%host%%` should be used for [host autodetection][3]. 
+
+```yaml
+apiVersion: v1
+kind: Pod
+# (...)
+metadata:
+  name: '<POD_NAME>'
+  annotations:
+    ad.datadoghq.com/<CONTAINER_NAME>.checks: | # <CONTAINER_NAME> Needs to match the container name at the bottom. 'keda-operator-metrics-apiserver' in this example.
+      {
+        "keda": {
+          "init_config": {},
+          "instances": [
+            {
+              "openmetrics_endpoint": "http://%%host%%:8080/metrics"
+            }
+          ]
+        }
+      }
+    # (...)
+spec:
+  containers:
+    - name: <CONTAINER_NAME> # e.g. 'keda-operator-metrics-apiserver' in the Metrics API Server
+# (...)
+```
+
+To collect metrics from each Keda component, the above pod annotations need to be applied to each Keda component pod. Example pod annotations for the Operator pod:
+
+```yaml
+# Pod manifest from a basic Helm chart deployment
+apiVersion: v1
+kind: Pod
+# (...)
+metadata:
+  name: 'keda-operator'
+  annotations:
+    ad.datadoghq.com/<CONTAINER_NAME>.checks: |
+      {
+        "keda": {
+          "init_config": {},
+          "instances": [
+            {
+              "openmetrics_endpoint": "http://%%host%%:8000/metrics"
+            }
+          ]
+        }
+      }
+    # (...)
+spec:
+  containers:
+    - name: keda-operator
+# (...)
+```
+#### Log collection
+
+_Available for Agent versions >6.0_
+
+Kyverno logs can be collected from the different Keda pods through Kubernetes. Collecting logs is disabled by default in the Datadog Agent. To enable it, see [Kubernetes Log Collection][10].
+
+See the [Autodiscovery Integration Templates][3] for guidance on applying the parameters below.
+
+| Parameter      | Value                                                   |
+| -------------- | ------------------------------------------------------- |
+| `<LOG_CONFIG>` | `{"source": "keda", "service": "<SERVICE_NAME>"}`  |
 
 ### Validation
 
@@ -49,7 +129,7 @@ See [service_checks.json][8] for a list of service checks provided by this integ
 Need help? Contact [Datadog support][9].
 
 
-[1]: **LINK_TO_INTEGRATION_SITE**
+[1]: https://keda.sh/
 [2]: https://app.datadoghq.com/account/settings/agent/latest
 [3]: https://docs.datadoghq.com/agent/kubernetes/integrations/
 [4]: https://github.com/DataDog/integrations-core/blob/master/keda/datadog_checks/keda/data/conf.yaml.example
@@ -58,3 +138,5 @@ Need help? Contact [Datadog support][9].
 [7]: https://github.com/DataDog/integrations-core/blob/master/keda/metadata.csv
 [8]: https://github.com/DataDog/integrations-core/blob/master/keda/assets/service_checks.json
 [9]: https://docs.datadoghq.com/help/
+[10]: https://keda.sh/docs/2.16/integrations/prometheus/
+[11]: https://github.com/kedacore/charts/blob/main/keda/README.md#operations