Monitoring

Kedify and KEDA expose Prometheus metrics for collection by your monitoring stack. Monitor component health, scaling results and application latency together.

Metrics endpoints

The default metrics endpoints are listed below. Use the installation namespace and verify Service names in your cluster.

Component	Service or pod	Port / path
Kedify Agent	kedify-agent-metrics	8080/metrics
KEDA operator	keda-operator	8080/metrics
KEDA metrics server	keda-operator-metrics-apiserver	8080/metrics
KEDA admission webhooks	keda-admission-webhooks	8080/metrics
HTTP interceptor	keda-add-ons-http-interceptor-metrics	2223/
OTel Scaler	kedify-otel-scaler	8080/metrics
Kedify Predictor	kedify-predictor	8080/metrics
Kedify Pod Autoscaler	<chart-fullname>-metrics (e.g. kpa-metrics)	8080/metrics
Kedify Proxy	kedify-proxy-admin in each proxy namespace	9901/stats/prometheus
Autoscaling Checks	Each runner pod / Service	8080/metrics

Scrape only installed components. The OTel Scaler Service defaults to kedify-otel-scaler when installed through the Agent; standalone installations use the Helm release name unless overridden. The kubectl kedify plugin listed on the Versions page is a CLI, not a metrics scrape target.

Discover individual pod or Service endpoints so each replica is scraped. Allow the collector to reach the metrics ports, add cluster and namespace labels, and collect only the metrics you need. A Service alone does not configure collection.

For a quick component status check:

kubectl get kedify kedify -n keda -o wide

Start with kedify_agent_component_up (1 healthy, 0 unhealthy; component name and version labels), KEDA scaler errors and metric latency, and desired versus ready workload replicas. Alert separately on unavailable scrape targets or missing data. For HTTP workloads, compare request rate/concurrency, pending requests, errors and latency with replica changes; see HTTP metrics and proxy tuning.

Autoscaling Checks

Install Autoscaling Checks to exercise signal generation, metric delivery, scale-out and scale-in. The Agent discovers runner Services for the Kedify Dashboard; external monitoring must scrape them separately.

• Track kedify_autoscaling_check_duration_seconds and its result label. A failed check can finish quickly, so a duration alert alone is insufficient.
• Track kedify_autoscaling_check_last_run_timestamp_seconds. Allow the configured interval, maximum run time and scrape delay before alerting on stale results; also detect missing runners.
• Run checks before and after upgrades. Validate application throughput, errors and cold-start latency with representative traffic as well.

Metric types, labels and alert examples are in the metrics reference.

Integrations

Datadog

Use the KEDA integration, included in Datadog Agent 7.62.0+, for KEDA components. Use OpenMetrics Autodiscovery for Kedify metrics. For the Kedify Agent, add these Helm values:

agent:
  podAnnotations:
    ad.datadoghq.com/manager.checks: |
      {
        "openmetrics": {
          "init_config": {},
          "instances": [{
            "openmetrics_endpoint": "http://%%host%%:8080/metrics",
            "namespace": "kedify",
            "metrics": [{"kedify_agent_component_up": "component.up"}]
          }]
        }
      }

This collects kedify.component.up. Configure a separate check for each Autoscaling Checks runner container, selecting the duration and last-run metrics above. Use the proxy’s /stats/prometheus path for HTTP metrics. Verify collection in Datadog Agent status and filter dashboards by cluster. Avoid collecting the same KEDA series through both the native integration and a generic check.

Prometheus

With Prometheus Operator installed, create a ServiceMonitor for the Agent:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: kedify-agent
  namespace: keda
spec:
  namespaceSelector:
    matchNames: [keda]
  selector:
    matchLabels:
      control-plane: kedify-agent
  endpoints:
    - port: metrics
      path: /metrics

Ensure your Prometheus selects this ServiceMonitor’s namespace and labels. In the KEDA chart values, enable prometheus.operator.serviceMonitor.enabled, prometheus.metricServer.serviceMonitor.enabled and prometheus.webhooks.serviceMonitor.enabled; prefix them with keda. when using the Agent chart. In the Autoscaling Checks chart, enable monitoring.serviceMonitor.enabled. For the proxy, use the HTTP ServiceMonitor example. Verify targets are up and samples are fresh.

Without Prometheus Operator, configure Kubernetes service discovery for the same endpoints in your Prometheus scrape configuration.

For Kedify Pod Autoscaler, enable serviceMonitor.enabled in its chart; prometheusRule.enabled installs the supplied alerts. Scrape OTel Scaler and Predictor Services using the endpoints above.

Grafana and Grafana Cloud

For Grafana, query the Prometheus data source collecting these metrics. For Grafana Cloud, use Grafana Alloy or Prometheus remote write.

The public kedify-observability reference stack includes Prometheus, Grafana dashboards, custom-resource kube-state-metrics mappings, Loki and an OTel log collector. Adapt collection targets, authentication and storage to your environment; its defaults include anonymous Grafana Admin access and disabled Grafana persistence.

New Relic

Use the Prometheus agent with scrape jobs selecting the Kedify endpoints, or forward an existing Prometheus collector through remote write. Include Kedify metrics in the agent’s collection filters.

OpenTelemetry

Use the Collector’s Prometheus receiver to scrape these endpoints and export the metrics to your backend. For request timing, enable proxy and interceptor tracing.