Health Checks

Availability Zone fault

Avantra for AWS is designed to automatically recover from Availability Zone faults.

Application and Network Load Balancers are set up in three Availability Zones, and the Amazon RDS for PostgreSQL is using a Multi-AZ setup. The Amazon EFS is deployed using mount targets in all three Availability Zones. Finally, the EC2 instance hosting the Avantra Server is controlled by an Auto-Scaling Group which also spans all three Availability Zones.

Most likely you will receive the following Amazon CloudWatch Alarms:

  • ${NamePrefix}-alb-unhealthy-host-count-cw-alarm

  • ${NamePrefix}-nlb-unhealthy-host-count-cw-alarm

Instance fault

Avantra for AWS is designed to automatically recover from instance faults.

In case of an instance fault, the Load Balancers will no longer be able to connect to the Avantra application. This will trigger the Auto-Scaling Group to terminate the faulty instance and launch a new one.

Most likely you will receive the following Amazon CloudWatch Alarms:

  • ${NamePrefix}-alb-unhealthy-host-count-cw-alarm

  • ${NamePrefix}-nlb-unhealthy-host-count-cw-alarm

If you receive ${NamePrefix}-ec2-cpu-utilization-too-high-cw-alarm Amazon CloudWatch Alarms, it may give you an indication your instance type might be to small.

Similarly, * ${NamePrefix}-rds-freeable-memory-cw-alarm: may indicate your RDS instance type is too small.

Application fault

Avantra for AWS is designed to automatically recover from severe application faults.

In case of a severe application fault where either the Avantra UI or the Avantra Master become inaccessible, the Load Balancers will no longer be able to connect to the Avantra application. This will trigger the Auto-Scaling Group to terminate the faulty instance and launch a new one.

There are some more Amazon CloudWatch Alarms defined:

  • ${NamePrefix}-error-count-too-high-cw-alarm: If they occur frequently you should check the Amazon CloudWatch Logs in the group `/avantra/ec2'

The following may occur from time to time and should be followed up if they happen cumulative, frequently, or in conjunction with other incidents:

  • ${NamePrefix}-http-code-elb-5xx-too-high-cw-alarm

  • ${NamePrefix}-http-code-target-5xx-too-high-cw-alarm

  • ${NamePrefix}-rejected-connection-count-too-high-cw-alarm

  • ${NamePrefix}-target-connection-error-count-too-high-cw-alarm

In case of multiple ${NamePrefix}-rds-deadlocks-cw-alarm, please turn to the Support.

Storage Capacity

EC2, EBS and EFS

THe EC2 instance running the Avantra Server comes with 30GB of EBS storage, which is plenty, and there is no option to change it. The vast majority of application data is stored in Amazon RDS for PostgreSQL, and log files written to the local volume are rotated and cleared automatically.

Smaller portions of application data are stored in the directory /opt/avantra/.xandria which is mapped to Amazon EFS storage. Also, only this storage is persistent. All EBS storage (i.e. all local volume data) will be gone whenever the Auto-Scaling group creates a new EC2 instance, for instance in case of AZ, instance, or application faults, or during upgrades.

In case you want to persistently store data, use /opt/avantra/.xandria.

EFS storage capacity is not limited.

Avantra performs monitoring of storage attached to the EC2 instance (both EBS and EFS) by means of the Avantra Agent installed with Avantra for AWS. See the description of the FILESYSTEMS check.

In case you want to monitor the usage of the EFS storage to keep an eye on costs, please proceed as follows:

  1. Open the Avantra UI and choose Systems  Server.

  2. Choose the Server with the name ${NamePrefix}-ec2 and select More  Create  Custom Check.

  3. Select FILESYSTEMS from the drop-down list.

  4. Change the Custom Check Name to e.g. Avantra Server EFS.

  5. In section File Systems fill in the value /mnt/efs into the field File System and choose values for Warning and Critical Usage, e.g. 2GB and 3GB.

  6. Push the Apply button followed by the Activate button.

ui create fs cc

You will find the newly created check for instance in Monitoring  RTM Check List, and it will turn to warning if the usage of /mnt/efs (mapped to /opt/avantra/.xandria) exceeds 2GB, and critical if it exceeds 3GB. It is probably time to do some cleanup then.

RDS

We recommend you setup Storage Autoscaling for the Amazon RDS for PostgreSQL. As time of developing Avantra for AWS, Storage Autoscaling could not be provisioned using AWS Cloud​Formation. So you have to follow the steps in section Changing the Storage Autoscaling Settings for a DB Instance of Managing Capacity Automatically with Amazon RDS Storage Autoscaling.

There is also a storage related Amazon CloudWatch Alarms:

  • ${NamePrefix}-rds-free-storage-space-cw-alarm

Security certificate expiration

As Avantra for AWS uses the AWS Certificate Manager to manage the certificate of the Application Load Balancer, the certificate will automatically be renewed and you do not have to care about certificate expiration. See also Managed Renewal for ACM’s Amazon-Issued Certificates.