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 Elements (MEs) are all of the components in the network infrastructure that generate and emit events:


Environment CPU File System
  • 1000 to 5000 Managed Elements (MEs)
  • 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 MEs
  • 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 MEs
  • 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 required for the database using the following:

(Aggregate event rate / the number of seconds per day x desired retention x average event size) / 1,000,000

    • Where the aggregate event rate is across all LAMs
    • Desired retention is in days
    • Average event size is in Kb
    • Result is in Gb.
    • Some event sources have larger than average events (e.g SCOM) but generally a 2kb event size is a reasonable assumption. This 2kb base takes account of the other event/alert based storage (e.g an alerts situation membership, typical custom_info, situation room thread sizes etc.)
    • So for an event rate of 10/s per LAM with 5 lams and a 400 day (13 month) retention we would have

50 x 60 x 60 x 24 x 400 x 2 / 1,000,000 = 3,456GN (3.5TB)