What problem are you trying to solve?

Focus on the what and why of the need you have, not the how you'd like it solved.

High cache fill and dirty cache fill ratios can directly cause a node to stall out, but these metrics are not considered when deciding whether to auto-scale. Auto-scaling does not monitor Storage Engine metrics that could indicate a need to scale before CPU and Memory reach critical thresholds, and can help to improve scenarios where cache fill or dirty cache contributes to a cluster tipping over. IE: A cluster stalls out due to heavy WiredTiger dirty fill ratio causing aggressive eviction, but does not reach the thresholds for auto-scaling yet, this will cause the cluster to be in a degraded state at best while we wait for the downstream CPU and Memory metrics to reach the threshold. Without the storage metrics being considered, there are gaps like above which we believe should be addressed to prevent these scenarios.

What would you like to see happen?

Describe the desired outcome or enhancement.

Incorporate additional WiredTiger engine-level metrics as autoscaling signals, specifically:

1. Eviction pressure — sustained high eviction activity (application threads doing eviction, eviction worker saturation) indicates the current tier's cache is undersized for the workload, even when aggregate CPU/memory metrics appear healthy.

2. Ticket utilization — high read/write ticket consumption (approaching wiredTigerConcurrentTransactions limits) signals storage-layer contention that CPU/memory metrics alone do not capture.

3. Dirty cache fill ratio — already requested in CLOUDP-311067; including here for completeness as part of a broader WT-aware autoscaling signal set.

Why is this important to you or your team?

Explain how the request adds value or solves a business need.

These metrics would complement existing CPU/memory triggers by detecting engine-level resource pressure that precedes or occurs independently of host-level saturation. This is particularly valuable for workloads with high write amplification, large working sets, or bursty I/O patterns where WT pressure manifests before CPU/memory thresholds are breached. Enterprise customers running latency-sensitive workloads have observed scenarios where WT cache pressure (dirty pages, eviction stalls, ticket exhaustion) degraded performance significantly, but autoscaling did not trigger because CPU and memory remained below thresholds. Earlier, WT-aware scaling would prevent these degradation windows. This specific feedback was raised by our NTSE Stripe.

What steps, if any, are you taking today to manage this problem?

Currently we simply rely on Auto-scaling as it is, and memory as a whole, without these Storage Engine specific metrics being considered. But we could be catching these issues before CPU and Memory reach critical thresholds.