Background
Currently, ContainerUtilizationMetricService mixes multiple concerns:
- Direct aiohttp HTTP calls (no connection pooling)
- PromQL query string generation
- Metric type detection (gauge/rate)
- Business logic coordination
This tight coupling makes it difficult to:
- Extend to other metric types (agent, node metrics)
- Test query building logic in isolation
- Reuse Prometheus access from other services
Proposed Solution
- Extract PrometheusClient
- Create clients/prometheus/ package with dedicated client
- Use ClientPool for connection reuse
- Add proper error handling (PrometheusQueryError, PrometheusTimeoutError)
- Introduce Querier Interface Hierarchy
PrometheusMetricQuerier (base: name, labels)
└── AggregatingMetricQuerier (adds: group_by_labels)
└── UtilizationMetricQuerier (adds: query_strategy)
- Business-Oriented Client API
- query_utilization(querier, time_range) - accepts abstract querier type
- fetch_available_container_metrics() - metadata retrieval
- Query building logic moved to client as private methods
Acceptance Criteria
- PrometheusClient extracted with ClientPool integration
- Querier interface hierarchy defined (PrometheusMetricQuerier → AggregatingMetricQuerier → UtilizationMetricQuerier)
- ContainerMetricQuerier implements query_strategy() for automatic gauge/rate selection
- ContainerUtilizationMetricService simplified to thin coordination layer
- All existing tests pass with updated mocks
- New tests for query_strategy() method
JIRA Issue: BA-4229
Background
Currently, ContainerUtilizationMetricService mixes multiple concerns:
This tight coupling makes it difficult to:
Proposed Solution
PrometheusMetricQuerier (base: name, labels)
└── AggregatingMetricQuerier (adds: group_by_labels)
└── UtilizationMetricQuerier (adds: query_strategy)
Acceptance Criteria
JIRA Issue: BA-4229