8 Monitoring

General Alerts

General Alerts for all Web Applications should be set up. The following are recommendations for monitoring EnterWorks’s hardware infrastructure. These should not serve as replacements for an organization’s current best-practices. If an organization already has a monitoring standard, this section can be ignored. Additionally, all recommendations are based on virtual servers.

Monitoring CPU Usage

All distinct servers, whether two-tier or three-tier, need to have CPU utilization monitored over periods of time. Alerts should be placed based on the following conditions.

  • Greater than 85% for one minute.
  • Greater than 80% utilization over 1 hour.
  • Average daily utilization is greater than 60%.

If there is compute resource contention, determine if the issue is historically a rare occurrence or if it happens at regular intervals but returns below the threshold most of the time. If either case is true it's very likely this is not a problem, so no action is required. However, if the resource contention is a chronic problem or directly impacts overall sight performance for a prolonged amount of time, consider upgrading to the next larger instance. Some examples include going from m5.large to m5.xlarge, or going from Gen 5 4 vCore to Gen 5 8 vCore.

If average daily utilization is greater than 60% over the course of 2 weeks, the corresponding server should be stepped up by 2 CPUs.

Monitoring Memory Usage

Memory utilization must be monitored across servers with a different set of alerts. Each server has different recommendations based on consistent alert faults. Alerts should be placed based on the following conditions:

  • All Servers – greater than 95% for one minute.
  • EnterWorks Web – greater than 75% memory utilization over 2 hours.
  • EnterWorks App – greater than 75% memory utilization over 2 hours.
  • Database – greater than 90% memory utilization over 1 hour.

If these alerts are triggered consistently, the following are recommendations for stepping up the corresponding server:

  • EnterWorks Web – Add memory in increments of 2GB.
  • EnterWorks App – Add memory in increments of 2GB*.
  • Database – Add memory in increments of 4GB**.

EnterWorks will need to be re-configured to use newly available memory. See the your EnterWorks solution architecture design documents and the appropriate EnterWorks 10 Installation Guide.

Monitoring Storage Capacity

General recommendations for storage are described below. (See Maintenance for information regarding clean-up of physical files.) The assumptions are:

  • There is a separate partition is used for the installation of EnterWorks.
  • There are standard monitors for other partitions.
  • All maintenance detailed in this document is performed.

Issue indicator:

  • Less than 10% of total hard drive space is available.
  • For EC2 instance or Azure VM:
    • Greater than 90% for one minute.
    • Less than ten gigabytes free

Once available free space is less than 10% of the total drive space, the following step-up requirements are recommended for each classification of EnterWorks components:

  • Web/Application (JBoss) – 20% of total drive space increments (i.e. 1TB = 200GB increment).
  • Database – 35% of total drive space increments to data drive (i.e. 1TB = 350GB increment).

If there is storage capacity contention:

  • EC2 instance: increase storage capacity of EBS volume by 50%.
  • Azure VM: upgrade to next disk size (e.g., from P15 to P20).
  • Amazon RDS: increase allocated storage capacity by 50%.
  • Azure Database for PostgreSQL: increase allocated storage capacity by 50%.