Azure Managed Redis: Add server load guidance for small SKUs

[apoorvaMSFT]

Summary

Customers on small Azure Managed Redis SKUs (B0–B5, X3, M10) sometimes report unexpectedly high Server Load or CPU metrics without a corresponding increase in operations per second. This PR adds a new subsection to the public documentation to help customers correctly interpret these signals and avoid unnecessary concern or misdiagnosis.

What changed

File: articles/redis/best-practices-server-load.md

Added a new subsection "Interpreting Server Load on Small SKUs" under ## Monitor Server Load that:

• Explains why 2-vCPU SKUs are more susceptible to percentage-based metric inflation
• Clarifies that elevated metrics on these SKUs may not indicate actual workload saturation
• Recommends using percentProcessorTime split by instance ID with Average aggregation for a more accurate view over longer time windows

Customer impact

Reduces confusion for customers monitoring small SKUs who may otherwise scale up unnecessarily or open support tickets based on misleading metric readings.

Work item

AB#36768182

Test plan

• Verify rendered markdown on docs staging
• OPS build validation passes (no broken links or formatting issues)

[prmerger-automator]

@apoorvaMSFT : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change.

[learn-build-service-prod]

Learn Build status updates of commit c1f3efb:

✅ Validation status: passed

File	Status	Preview URL	Details
articles/redis/best-practices-server-load.md	✅Succeeded

For more details, please refer to the build report.

[v-regandowner]

@flang-msft

Can you review the proposed changes?

IMPORTANT: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

[Copilot]

Pull request overview

Adds documentation guidance for interpreting elevated Server Load/CPU metrics on small Azure Managed Redis SKUs to reduce false alarms and unnecessary scale-ups.

Changes:

• Adds a new “Interpreting Server Load on Small SKUs” subsection under “Monitor Server Load”.
• Explains why percentage-based metrics can look inflated on 2-vCPU SKUs.
• Recommends using percentProcessorTime with instance split and Average aggregation for longer time windows.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The new guidance recommends Average over Maximum, which can read as contradictory to the earlier guidance historically given for examining max spikes (especially for detecting brief events that cause timeouts/failovers). Consider adding a clarifying sentence that distinguishes the intent: e.g., use Maximum over short windows to catch spikes/events, but use Average over longer windows for trend analysis on small SKUs (especially when using percentProcessorTime).

Suggested change

	- Using **Average** aggregation instead of **Maximum**
	- Using **Average** aggregation instead of **Maximum** for these longer time ranges
	You can still use **Maximum** aggregation over short time windows to catch brief spikes or events (such as those that might cause timeouts or failovers), while relying on **Average** over longer windows for trend analysis on small SKUs, especially when using `percentProcessorTime`.

[learn-build-service-prod]

Learn Build status updates of commit 46d55e7:

✅ Validation status: passed

File	Status	Preview URL	Details
articles/redis/best-practices-server-load.md	✅Succeeded

For more details, please refer to the build report.

[learn-build-service-prod]

Learn Build status updates of commit 4f3d1d0:

✅ Validation status: passed

File	Status	Preview URL	Details
articles/redis/best-practices-server-load.md	✅Succeeded

For more details, please refer to the build report.