-
Notifications
You must be signed in to change notification settings - Fork 37
Open
Description
Background
Currently, the Poller always prepends every metric query with the following base filter (implementation):
resource.type="spanner_instance" AND
resource.labels.instance_id="<INSTANCE_ID>" AND
project="<PROJECT_ID>" AND …
However, custom metrics can’t be written under the spanner_instance resource type (docs). As a result, any predictive business- or application-level KPIs that signal upcoming high load emitted under other resource types cannot be picked up by the autoscaler.
Use Case: Predictive Pre-Scaling
- Future-Load Indicator
- A separate service publishes a Cloud Monitoring gauge metric that implies future Spanner load(e.g. estimated QPS or queue length).
- Pre-warm Nodes
- When that predictive metric crosses a given threshold, we want to proactively add nodes before the actual load hits Spanner.
- Stable Scaling Decision
- Because this external metric won’t drop simply by adding Spanner nodes, we need to calculate desired node count based on both the metric value and the current node count.
Proposal
-
Introduce an
externalMetric
flag- Type:
boolean
- Purpose: When set to
true
, disable the built-in Spanner resource filter so that any Cloud Monitoring query can be used. - Default:
false
(existing behavior)
- Type:
-
Support a per-node threshold (
thresholdByNode
)-
Type:
number
-
Purpose: Compute the desired node count as
desiredNodes = ceil(metricValue / thresholdByNode)
This prevents unbounded scale-outs for external metrics that is not not affected by spanner nodes.
-
Default:
undefined
-
Benefits
- Proactive scaling based on true business-level KPIs, not just realtime CPU or storage.
- Backward compatibility: existing users see no change unless they opt in.
Thank you for considering this enhancement! We’d be happy to help prototype, test, or refine the design.
rluisr, taba2424, nishikawa-tadashi, tani-yu and omoterikuto
Metadata
Metadata
Assignees
Labels
No labels