Moogsoft Docs

Sizing Recommendations

The sizing recommendations below are guidelines for small, medium and large Moogsoft AIOps systems based on input data rate and volume.

In the context of this guide, Managed Devices (MDs) are all of the components in the network infrastructure that generate and emit events:


Environment CPU File System
  • 1000 to 5000 Managed Devices (MDs)
  • Less than 20 users
  • Up to 5 integrations
  • Less than 20 Alerts per second
  • 8 Cores
  • 32GB RAM
  • 2 x 1GB Ethernet
  • Physical or Virtual Server
  • 1 TB Local or SAN

See retention policy .


Environment CPU File System
  • 5000 to 20,000 MDs
  • Between 20 and 40 users
  • Between 6 and 10 integrations
  • Between 20 and 100 Alerts per second
  • 16 Cores
  • 64GB RAM
  • 2 x 1GB Ethernet
  • Physical or Virtual Server
  • 1 TB Local or SAN

See retention policy .


Environment CPU File System
  • More than 20,000 MDs
  • More than 40 users
  • More than 10 integrations
  • More than100 Alerts per second
  • 24+ Cores
  • 128GB RAM
  • 2 x 1GB Ethernet
  • Physical or Virtual Server
  • 1 TB Local or SAN

See retention policy .

Virtualization Restrictions

Consider the following restrictions for virtual environments:

  • Ideally all Moog servers (guests) should be on the same compute node (host) sharing a hypervisor or virtual machine monitor. This minimizes latency between Moog guests.
  • If servers are liable to automated resource balancing (e.g. vMotion) and liable to move compute nodes, then all Moog servers should be moved at the same time. If this is not possible, then Moog servers should be constrained to movements that minimize the resulting network distance.
  • If Moog servers are distributed amongst compute nodes then the network “distance” (logical hops) between the nodes should be minimized.
  • Network latency between components may affect Event processing throughput. This is especially true of the core to db servers.

Shared Storage

On any shared compute platform Moogsoft makes the following recommendations:

  • The minimum resource requirements are multiplied by at least 33% to account for shared resource usage and allocation.
  • Storage latency will reduce effective throughput at the core processing layer and should be minimised within the available constraints of a SAN.
  • Moog should be treated as a highly transactional system and not placed on the same compute node as other highly transactional applications that may cause SAN resource contention.
  • SAN port and array port contention should be minimized
  • Storage medium should be as fast as possible to minimize the transaction times to the database.

Retention Policy

You can calculate the amount of disk space in GB required for the database server using the following calculation:

(es x eps x d x 86,400 ) x 1.2 / 1,000,000

For this calculation: es = average event size in KB, eps = average events per second, d = number of days of retention and 86,400 represents the number of seconds per day.

For the majority of event sources, you can reasonably estimate a 2KB event size. However, some sources have larger than average events. For example, Microsoft SCOM . A 2KB base takes account of the other event and alert based storage such as an alert's Situation membership and Situation room thread sizes.

The average event rate is across all LAMs and integrations.


If you do not enable the Archiver tool, the historic database will grow indefinitely. See Archive Situations and Alerts for more information.

For example, the following calculation represents a 400 day retention period with an average event size of 2KB at 300 events per second:

(2 x 300 x 400 x 86,400) x 1.2 / 1,000,000 = 24,883.2 GB .