Area(s)

area:k8s

What's missing?

Introduce new metrics and attributes to provide further insight into k8s HPA's configuration. These metrics will be used to monitor the target values of the metrics specified in the HPA's spec.metrics[] field. HPA spec can be seen here.

The metrics and attributes should convey the following information:

1. Track which metrics the HPA is configured to monitor.
2. Report the configured target values for these metrics, including relevant attributes to provide insight into the type.

Example of an HPA spec

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Object
    object:
      metric:
        name: requests-per-second
      describedObject:
        apiVersion: networking.k8s.io/v1
        kind: Ingress
        name: main-route
      target:
        type: Value
        value: 10k
  - type: ContainerResource
    resource:
      name: memory
      container: my-sidecar
      target:
        type: Value
        averageUtilization: 2Gi

Describe the solution you'd like

Proposed new metrics -

1. Metric: k8s.hpa.metrics.target.value

• Description: Represents the target value of the metric being monitored by the HPA.
• Instrument: Gauge
• Unit: Varies by the metric type
• Attributes:
  • k8s.hpa.metrics.target.type: The type of metric source - possible values are Resource, External, Object, Pods, ContainerResource.
  • k8s.hpa.metrics.target.name: The name of the metric being tracked (e.g., cpu, http_requests_per_second, queue_length).
  • k8s.hpa.metrics.target.value.type: Specifies the type of value - possible values are average_value, average_utilization, value.
  • k8s.hpa.metrics.target.container (optional): The name of the container (if type=ContainerResource).
  • k8s.hpa.metrics.target.object.kind (optional): The kind of the object (if type=Object).
  • k8s.hpa.metrics.target.object.name (optional): The name of the object (if type=Object).
  • k8s.hpa.metrics.target.object.apiversion (optional): The name of the object (if type=Object).

OR

Break above metric into to 3 different metrics with the value of k8s.hpa.metrics.target.value.type attribute now being reflected in the metric name which I think is more inline with the semantic-conventions guidance -

1. Metric: k8s.hpa.metrics.target.value

• Description: Tracks the configured target value for the HPA metric.
• Attributes:
  • k8s.hpa.metrics.target.type: The type of metric source - possible values are Resource, External, Object, Pods, ContainerResource.
  • k8s.hpa.metrics.target.name: The name of the metric being tracked (e.g., cpu, http_requests_per_second, queue_length).
  • k8s.hpa.metrics.target.container (optional): The name of the container (if type=ContainerResource).
  • k8s.hpa.metrics.target.object.kind (optional): The kind of the object (if type=Object).
  • k8s.hpa.metrics.target.object.name (optional): The name of the object (if type=Object).
  • k8s.hpa.metrics.target.object.apiversion (optional): The name of the object (if type=Object).

2. Metric: k8s.hpa.metrics.target.average_value

• Description: Tracks the configured average target value for the HPA metric.
• Attributes:
  • Same as k8s.hpa.metrics.target.value.

3. Metric: k8s.hpa.metrics.target.average_utilization

• Description: Tracks the configured average utilization target for the HPA metric (as a percentage).
• Attributes:
  • Same as k8s.hpa.metrics.target.value.

Given the variety of resources that HPAs can scale on (CPU, memory, external metrics, object metrics, etc.), the units for k8s.hpa.metrics.target.value and k8s.hpa.metrics.target.average_value could vary significantly. For example, 500m for CPU, 2Gi for memory, or 1000 req/s for HTTP requests, etc. I think defining each possible combination (if even feasible) would introduce significant overhead. I am looking for suggestions on how best to represent the metrics' units in this situation.