Capacity Planning for SAN, vCPU, RAM etc. in ServiceNow

[rajumunta]

Have any of you implemented Capacity Planning for SAN, vCPU, RAM etc. in ServiceNow? To add more details on to this - more similar to physical assets like Laptops or Desktops where we have Stock rooms and Stock rules that govern inventory of the assets and are assigned/consumed over period of time....I was looking to implement the same analogy on Enterprise Capacity Planning for future and integrate with new requests for SAN/vCPU/RAM. One of many use cases to start with.

[Bill Martin · Accepted solution]

Great question @rajumunta, 

this comes up a lot and there's an important distinction to make upfront: there's no out-of-the-box "capacity planning for SAN/vCPU/RAM" module in ServiceNow that works like Stock Rooms and Stock Rules in EAM/ITAM (which are designed for physical assets like laptops and desktops).

However, the stronger and more scalable pattern is to use ITOM + Metric Intelligence, and here's how we've approached it in practice:

Metric Intelligence as the Core Metrics & Anomaly Layer

ServiceNow's Metric Intelligence (formerly Operational Intelligence) is the right foundation here. It ingests time-series metrics, CPU, memory, disk, IOPS, etc.  from your existing monitoring and observability tools, learns normal behavior per CI, and applies ML-based dynamic thresholds to detect anomalies early.

This gives you real-time and historical utilization trends on hosts, VMs, and storage pools directly in the Metric Intelligence dashboards and Service Operations Workspace, which is far more actionable for infrastructure capacity decisions than trying to replicate stock-room logic for compute resources.

Build Capacity Views on the Metrics Dashboard

Once metrics are flowing in, we layer Performance Analytics indicators and reports on top, for example: "hosts above 80% CPU sustained for 7 of the last 10 days" or "storage pools projected to hit 90% within 90 days." This effectively becomes your infrastructure capacity planning view, and you can use those insights to raise demands or changes for capacity procurement.

Dedicated MID Server for Metric Intelligence: Architecture Recommendation

This is an important architecture point that's often overlooked: Metric Intelligence and Agent Client Collector traffic can be very high-volume, especially in large environments. From our implementation experience, I strongly recommend deploying a dedicated MID Server (or MID cluster) exclusively for metrics and AIOps workloads, separate from your existing MID Servers that handle Discovery and integrations.

We've done this in previous architectures and it pays off: your existing MIDs were likely sized only for Discovery and integration traffic, and mixing high-frequency metric polling on the same MID introduces contention and can impact your current integrations. A separate MID tier for Metric Intelligence keeps collection isolated, easier to scale independently, and much simpler to troubleshoot.

If you want the "asset/stock-room" metaphor for physical infrastructure hardware (e.g., tracking spare SAN arrays or RAM modules as inventory), you can model those in EAM/ITAM and link them to CMDB CIs. But for actual SAN/vCPU/RAM capacity utilization and forecasting, Metric Intelligence + metrics dashboards + PA reporting is the recommended path.

Hope this helps point you in the right direction!

Please mark as helpful and accept as solution if you find the post lucrative

[rajumunta]

Thanks for the insight and direction.