Part of #336. Blocks #337, #338, #339.
Proposal. Pod telemetry (cadvisor, DCGM) stops at the pod; nothing generic joins it to the workload a pod belongs to, and for custom types there is no workload-level view at all. A Karta description already knows which pods form a workload, a component, and a component instance. This proposes an exporter that publishes that knowledge as Prometheus-style metrics (the assumed default; the design should note alternatives), so consumers (dashboards, autoscalers, policy engines, alerting) can read existing pod telemetry at workload and component level for any described type, without per-type code.
Scope of this ticket. The infrastructure for emitting workload-, component- and component-instance-level fact series from Karta descriptions. Not the aggregate series (per-workload GPU utilization and the like); those are out of scope here and land as a default recording-rules file under #336.
Properties the design should address (open for discussion, not final):
- Attribution: a pod maps to exactly one workload / component / component instance, with nested described types rolling up to the top-level workload, so sums across workloads stay correct.
- Phase: a workload's Karta generic status (phase) is observable over time (duration in phase, transition time) with one generic query for all types.
- Freshness: consumers can tell how current the attribution is; target is cluster state reflected within ~30s.
- Interface stability: metric and label names are a versioned contract consumers can build on.
- Facts, not judgments: the exporter emits attribution and state, no measurements and no aggregation; thresholds, statistics and idleness decisions belong to the consumer.
Numbers and rules in #337, #338 and #339 are starting points; the design may revise them.
Deliverables
Rough estimate: a few days for the design doc.
Part of #336. Blocks #337, #338, #339.
Proposal. Pod telemetry (cadvisor, DCGM) stops at the pod; nothing generic joins it to the workload a pod belongs to, and for custom types there is no workload-level view at all. A Karta description already knows which pods form a workload, a component, and a component instance. This proposes an exporter that publishes that knowledge as Prometheus-style metrics (the assumed default; the design should note alternatives), so consumers (dashboards, autoscalers, policy engines, alerting) can read existing pod telemetry at workload and component level for any described type, without per-type code.
Scope of this ticket. The infrastructure for emitting workload-, component- and component-instance-level fact series from Karta descriptions. Not the aggregate series (per-workload GPU utilization and the like); those are out of scope here and land as a default recording-rules file under #336.
Properties the design should address (open for discussion, not final):
Numbers and rules in #337, #338 and #339 are starting points; the design may revise them.
Deliverables
docs/design/metrics-exporter/high-level-design.md: architecture, metric and label naming, deployment model, alternatives considered.Rough estimate: a few days for the design doc.