VM configuration for automation

VM monitoring and metrics

The platform may automatically enable metrics for all VMs. If you have the privilege to Manage virtual machine monitoring and it is configured in your virtual datacenter, you can enable the option to fetch built-in metrics from the hypervisor or public cloud region, as well as any custom metrics defined for your VM.

Enable VM monitoring and metrics

To enable VM monitoring and metrics:

Go to myCloud Virtual datacenters and edit a VM
Go to Monitoring
Select the Fetch metrics data checkbox. This will retrieve all metrics while the VM is deployed
Select from the available options, for example, for AWS offers Detailed or Basic monitoring.
Select the individual metrics you would like to display for your VM. The functionality and list of available metrics depend on the underlying virtualization technology and the platform configuration.

The platform will always retrieve all metrics, so you can change the metrics to display at any time. And you can use any metric for alarms and alerts, even if you do not display it. You may need to wait a short time for the first metrics to load.

Display metrics for a VM

To display and filter metrics for a VM:

Go to Virtual datacenters → Virtual appliance
On the VM icon → click the graph metrics symbol
The metrics panel will open and you can dynamically filter and select which metrics to display.

To update the display of a metric, click the round-arrow refresh button.

To configure the display of the metric:

Select the funnel filter button
Set the following as required
1. Granularity, which is how often the metric is sampled
2. Statistic, which determines how the raw values will be processed over time
3. "Last" period, which is how long the display will look behind at the processed data
4. Metric dimensions: for metrics with more than one possible element being monitored, for example, multiple hard disks, you can display metric dimensions, which are metrics for separate elements.
  1. To view metric dimensions, click Get dimensions. Select a dimension.
  2. If no dimension is selected, the default value is the average of all dimensions
Click Accept to save the values.

To view the exact metric values in a call-out box, mouse over the metric graph line.

To create a highlight point, click on the metric graph line.

To simultaneously view the data for more than one VM, use the virtual appliance Monitoring view.

Automate VM first boot with a configuration or script

Before you begin:

Create your VM with a template that is compatible with cloud-init version 0.7.9 or above, or cloudbase-init, or a similar system
In private cloud, the platform will create an ISO disk for Configuration drive

To add a VM bootstrap configuration or script in private or public cloud:

Go to create or edit VM → Bootstrap script
Paste your configuration or script in the Bootstrap script text box
Continue to configure the VM or click Save to finish

Notes about bootstrap in private cloud

If the user does not enter the FQDN on the General tab when editing the VM, the platform will try to set the FQDN using the name or ID attribute of the VM, and the domain of the VM's networks, or the localhost domain
If DHCP is not used in your datacenter, the network configuration of the VM can be read from cloud-init, so you do not need to configure the network or allow access to the VM
Abiquo uses the ConfigDrive DataSource for cloud-init. Reference: http://cloudinit.readthedocs.io/en/latest/topics/datasources/configdrive.html

Notes about startup scripts in AWS

In Amazon Web Services you must always select a guest setup option
In AWS, for Windows, depending on the template and its guest setup option, the script format is:
1. cloudbase_init: cloud-init or shellscript
2. ec2launch and ec2config: you must have the following tags at the start and end of your script
  1. batch script, use <script></script>
  2. powershell script, use <powershell></powershell>
3. ec2launch v2: yaml format. See https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-windows-user-data.html#user-data-yaml-scripts.
  If your script format is invalid, AWS will try ec2launch and ec2config format. See: https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-windows-user-data.html

Notes about startup scripts in OCI

The Windows templates provided by Oracle Cloud Infrastructure include cloudbase-init.
See https://docs.oracle.com/en-us/iaas/releasenotes/changes/595afbb7-de0c-4934-8074-5b1ed6be1b56/

Related pages

Main VM configuration page Configure virtual machines
Guest setup
To add a bootstrap script with the API, use VM metadata. See Manage virtual machine metadata via API

Add variables for the configuration of your VM

Add VM variables

Before you deploy a VM, you can set guest variables to pass user data to your VM. This functionality uses cloud-init and requires appropriate templates. In private cloud, the templates must have the guest setup flag set to cloud init. The administrator can add default variables for the VM template.

This functionality is available through the API. The platform stores variables in the VirtualMachine "variables" attribute, which is a dictionary of keys and values. See Update a virtual machine in VirtualMachinesResource

You can modify VM variables before you deploy the VM

To add VM variables:

Go to Virtual datacenters → edit a VM that is not deployed
Go to Variables
Enter a Key and Value
1. The length of these can be up to 255 characters each
Click Add
Add more variables as required
To delete a variable click the trash can symbol beside the Key. To edit the Value of a variable, click the pencil edit button beside the Value
To apply changes to variables, and other changes to the VM, click Save

Read guest variables

The variable location will depend on the method of guest setup that you are using for your VM. Here are some general guidelines.

Cloud	Method	Variable location
Private	Cloud-init	The variables are stored on the cloud-init ISO, which has the label "config-2". The variables file is "openstack/latest/vm-variables.rc"
Private	Hypervisor tools	On ESXi, run the following command in the guest to get the value of a variable: vmtoolsd --cmd "info-get guestinfo.abiquo.<variable-name>"
Private	Hypervisor tools	For vCloud Director, hypervisor tools does not support variables
Public	Cloud-init	The variables are stored in the /opt/abiquo-env.rc file
Amazon	Cloudbase-init ec2launchv2 ec2lanch ec2config	On Windows, the variables are stored in the C:\ProgramData\Abiquo\abiquo-env.rc file
Azure	Cloud-init	On Windows, according to the Azure documentation on custom data Custom data is placed in %SYSTEMDRIVE%\AzureData\CustomData.bin as a binary file, but it is not processed. If you wish to process this file, you will need to build a custom image, and write code to process the CustomData.bin.. On Linux, you can use cloud-init to read the variables from custom data.

Use collectd plugin for custom metrics

Abiquo supports collectd with an integration in the multi-cloud platform to enable you to easily work with custom VM monitoring and metrics in public cloud providers, including Amazon, Azure, and Google Cloud, as well as VMware vCenter.

In the Abiquo multi-cloud platform you can create alerts and automation based on your custom metrics.
For example, you can automatically scale out your VMs based on your application metrics.

After you configure collectd and the Abiquo collectd plugin, the plugin will automatically push the values from collectd to the Abiquo API using the Abiquo API endpoints for collectd.
For example, for a VM, or a group of VMs in a VApp, or for a scaling group.
The Abiquo API then pushes the collectd metrics to the Abiquo Monitoring Server. Users can then display metrics through the UI or use them for automation.

How to install and configure collected for VMs in Abiquo

The following steps are a general guide:

In Abiquo, create an OAuth application in Abiquo for collectd. See Add an application for OAuth
1. Assign the privilege to “Allow user to push own metrics”
Install collectd on your VM
Install the Abiquo collectd plugin (from source or using the Abiquo Chef cookbook).
1. Configure the Abiquo API path to push the metrics to the VM in Abiquo. Check the correct format of the API path in the API documentation
Configure your metrics in collectd

The Abiquo collectd plugin will automatically push all collectd metrics to the Abiquo API in PUTVAL JSON format.

To display the VM metrics in Abiquo:

Edit your VM and go to Monitoring
Select Fetch metrics data.
Optionally select the monitoring level on providers that support it, e.g. AWS
Select the metrics to display from the custom metrics and the built-in metrics of the cloud provider or hypervisor
Save your changes to the VM. Optionally define a scaling group to increase the number of VMs running your application automatic scaling actions. See Define a scaling group
If your VM is not running, deploy to launch the VM. Wait several minutes for the server to return metrics
On the VM icon near the top right corner, click the metrics symbol. Or in the Virtual appliance, go to Monitoring → Virtual machines
Configure the metrics to display the required statistic, frequency, dimensions, and so on.
Create alarms to set metric thresholds and alerts on groups of alarms, to notify or respond to changing application conditions with automation using action plans. See Cloud VM automation guide

Automate the install of collectd using Chef

This is an example use case with Chef using the Abiquo Chef cookbook.

In Abiquo, the administrator creates an OAuth application in Abiquo for collectd. See Add an application for OAuth
1. Assign the privilege to “Allow user to push own metrics”
On the Chef server, the administrator creates a role with the following:
1. The monitoring recipes to install the Abiquo collectd plugin
2. The OAuth tokens for the application configured
In Abiquo, users edit the VM and go to Chef, then select the appropriate collectd role.

Abiquo recommends this kind of automation because the OAuth application belongs to the tenant administrator. This means that the administrator prepares the configuration for users, it is easy to apply it automatically on a large scale, and the administrator can protect the configuration from accidental changes when users load their own Chef recipes, etc.

Example collectd data object

Here is an example of a data entity to update a virtual machine with the collectd metrics specification.

Click here to expand...

[
  {
    "datasourceNames": [
      "933cc3bb-ce9b-4529-8854-c2e0b3db8f15", 
      "e62ded09-cb81-4f84-b952-0e1670caafb4"
    ], 
    "datasourcetypes": [
      "ABSOLUTE", 
      "GAUGE"
    ], 
    "dsnames": [
      "933cc3bb-ce9b-4529-8854-c2e0b3db8f15", 
      "e62ded09-cb81-4f84-b952-0e1670caafb4"
    ], 
    "host": "0d5be059-3489-40b2-8ca9-2eb06ac380ee", 
    "long_time": 1479997080, 
    "plugin_instance": "4877672f-1e7d-4aba-9fea-e27f04edb0ba", 
    "pluginInstance": "4877672f-1e7d-4aba-9fea-e27f04edb0ba", 
    "dstypes": [
      "ABSOLUTE", 
      "GAUGE"
    ], 
    "plugin": "454dbbf3-1b8d-48e6-873b-013186aab177", 
    "interval": 10, 
    "typeInstance": "e105b17d-c6ba-4ba3-a767-79fc7de1abc9", 
    "length": 2, 
    "long_interval": 10, 
    "values": [
      "10373115", 
      "12863138"
    ], 
    "time": 1479997080, 
    "type_instance": "e105b17d-c6ba-4ba3-a767-79fc7de1abc9", 
    "type": "5c707508-a1f2-4318-aa35-3f91b74378c3"
  }, 
  {
    "datasourceNames": [
      "71d83476-7906-47d9-a053-f7cf2080f809"
    ], 
    "datasourcetypes": [
      "ABSOLUTE"
    ], 
    "dsnames": [
      "71d83476-7906-47d9-a053-f7cf2080f809"
    ], 
    "host": "78c620c2-8b48-405c-b2b0-39d22527b9ef", 
    "long_time": 1479997080, 
    "plugin_instance": "c8d66a06-bf36-4f8d-ae4d-3c1dc9868662", 
    "pluginInstance": "c8d66a06-bf36-4f8d-ae4d-3c1dc9868662", 
    "dstypes": [
      "ABSOLUTE"
    ], 
    "plugin": "e4d3ba5b-e322-4e18-8856-29f3db6240f5", 
    "interval": 10, 
    "typeInstance": "6d90f553-100a-4137-816b-695663cbc621", 
    "length": 1, 
    "long_interval": 10, 
    "values": [
      "1857444"
    ], 
    "time": 1479997080, 
    "type_instance": "6d90f553-100a-4137-816b-695663cbc621", 
    "type": "e9553cea-9930-40aa-a89d-96d937ea50e0"
  }, 
  {
    "datasourceNames": [
      "d1d67266-b3e8-489b-bd8d-9cfc2bc22322"
    ], 
    "datasourcetypes": [
      "ABSOLUTE"
    ], 
    "dsnames": [
      "d1d67266-b3e8-489b-bd8d-9cfc2bc22322"
    ], 
    "host": "dafdcd40-1ad9-4fa1-ab89-6821ec3dc7b5", 
    "long_time": 1479997080, 
    "plugin_instance": "9c63a050-c6f2-461f-8380-a6ec96c476b7", 
    "pluginInstance": "9c63a050-c6f2-461f-8380-a6ec96c476b7", 
    "dstypes": [
      "ABSOLUTE"
    ], 
    "plugin": "946f66fb-c230-4ded-a2ac-4f130520d5c8", 
    "interval": 10, 
    "typeInstance": "befc79ea-49ba-4bf1-bff5-fe7f04bacb65", 
    "length": 1, 
    "long_interval": 10, 
    "values": [
      "5177812"
    ], 
    "time": 1479997080, 
    "type_instance": "befc79ea-49ba-4bf1-bff5-fe7f04bacb65", 
    "type": "9ad979ed-3cc1-4339-8e76-59f6c1adf073"
  }, 
  {
    "datasourceNames": [
      "f28d1829-d3de-4f50-b604-33b79422645c"
    ], 
    "datasourcetypes": [
      "COUNTER"
    ], 
    "dsnames": [
      "f28d1829-d3de-4f50-b604-33b79422645c"
    ], 
    "host": "0d835519-bdc6-4b52-8ccd-0970f2ac252b", 
    "long_time": 1479997080, 
    "plugin_instance": "0b84221f-f282-4662-9f3c-198d9facbb51", 
    "pluginInstance": "0b84221f-f282-4662-9f3c-198d9facbb51", 
    "dstypes": [
      "COUNTER"
    ], 
    "plugin": "bcd3327c-2c00-4651-9ad7-51caccadd6f7", 
    "interval": 10, 
    "typeInstance": "1882cdaf-d99d-4494-b7a4-527d0e6e3c98", 
    "length": 1, 
    "long_interval": 10, 
    "values": [
      "3023252"
    ], 
    "time": 1479997080, 
    "type_instance": "1882cdaf-d99d-4494-b7a4-527d0e6e3c98", 
    "type": "5f25fa66-8484-4e98-8169-edf2d6cf22f9"
  }, 
  {
    "datasourceNames": [
      "e786a610-7c90-451a-9955-078e90071969"
    ], 
    "datasourcetypes": [
      "DERIVE"
    ], 
    "dsnames": [
      "e786a610-7c90-451a-9955-078e90071969"
    ], 
    "host": "7af8662b-33a3-4cb0-afed-f68340d43b62", 
    "long_time": 1479997080, 
    "plugin_instance": "4b3e9685-7e7d-4f6f-8256-6a22f8e3308c", 
    "pluginInstance": "4b3e9685-7e7d-4f6f-8256-6a22f8e3308c", 
    "dstypes": [
      "DERIVE"
    ], 
    "plugin": "1023cd92-7f4b-4462-ad8a-305312aa9e94", 
    "interval": 10, 
    "typeInstance": "803f1271-7cac-426f-9951-33379c49bba8", 
    "length": 1, 
    "long_interval": 10, 
    "values": [
      "9775473"
    ], 
    "time": 1479997080, 
    "type_instance": "803f1271-7cac-426f-9951-33379c49bba8", 
    "type": "30529502-f812-4386-8d7b-9076ccf72d5b"
  }
]

Custom metrics entities

Abiquo enables you to easily manage custom metrics for many platform resources, including:

Public cloud region (from cloud/locations and admin/publiccloudregions)
Datacenter (from cloud/locations and admin/datacenters)
Machine
Rack
Virtual appliance
Scaling group
- Virtual machines
Virtual machine

Custom metrics display in the UI

The Abiquo UI enables users to display custom metrics for the following entities:

Virtual appliance
Scaling group
Virtual machine

Display custom VApp metrics

Abiquo can display custom metrics for your virtual appliance and metrics for the group of VMs in the virtual appliance.

To display custom metrics for the virtual appliance:

On a Virtual appliance card, click the Monitoring button OR
Open a Virtual appliance and go to Monitoring tab → Virtual appliance metrics page.

To configure the display of metrics:

For the refresh interval, select the Refresh data every checkbox and enter a number of minutes.
To filter metric statistics, click on the Filter button and select the granularity, statistic, time frame, and dimension, as required.

Scaling groups

Introduction to autoscaling

To configure an automatic response to changing demands for resources, you can scale out VMs or scale them in, which is also called horizontal autoscaling. To scale out, the platform clones the base VM and deploys the clones. To scale in, the platform will delete clone VMs and undeploy the base VM. Scaling operations are subject to all standard platform constraints, such as privileges and allocation limits.

Screenshot: A scaling group with VMs deployed automatically.

Limitations:
- Autoscaling does not clone captured VMs, so to use scaling groups with a captured VM, create an instance and recreate the VM. Create instances to save VM disks to templates
- VApp specs do not support scaling groups. See What do virtual appliance specs save and create
- Scaling groups have aggregate alarms that are associated with the base VM. This means that you can push custom metrics for clone VMs but you cannot create alarms for cloned VMs that are part of a scaling group.
State of base VM: A scaling group with a deployed base VM would be destroyed if the base VM were deleted directly on the hypervisor. In contrast, a scaling group with an undeployed base VM is not vulnerable to interference at the hypervisor level

To stop autoscaling, put the scaling group into maintenance mode.

Automatically scale VMs

The platform enables you to automatically scale out (add more VMs) or scale up (add more resources to existing VMs).

Privileges: Manage scaling groups, Manage workflow for scaling groups

To use autoscaling do these steps:

Create a base VM, which can be deployed or undeployed
Configure the VM and enable metrics
Define a scaling group with rules for scaling the VM.
The checkbox to automatically create a scaling action, will create the following automatically:
1. Standard alarms and alerts for the selected metrics
2. Action plans with scaling actions for the VM and triggers for the action plans, which are monitoring alerts
You can customize the elements the platform creates, or you can create your own configuration.

Virtual machines in Virtual datacenter - virtual appliance view

Related pages:

Manage Scaling Groups

Define a scaling group

Before you begin:

Configure the base VM that will be scaled
Ensure that you have enough resources in your virtual datacenter to deploy up to the maximum number of cloned VMs, especially IP addresses

To create a scaling group:

Go to Virtual datacenters → Virtual appliances
On the VM icon, from the options menu, select Define scaling group
Enter the scaling parameters
1. For the Default cooldown, enter the period of time to wait from the start of one scaling operation before allowing another scaling operation
2. For the Minimum running virtual machines that Abiquo must maintain in the scaling group, the value must be greater than or equal to zero, where zero means that the base machine is not deployed
3. The option to Keep virtual machines in the same layer can maintain VM anti-affinity layers when autoscaling
4. Administrators with the privilege to Manage workflow for scaling groups can Disable workflow or enable it as required
5. Optionally, select Create in maintenance mode to delay the start of autoscaling, and the automatic deployment of VMs to meet the minimum size
6. Select the option to Create autoscaling action to create basic operations to scale in and scale out, with triggers based on metrics and alarm conditions.
Create scaling rules
1. For Scale out rules, enter the number of VMs to Add. This is the number of times to clone the base VM and deploy each clone for each scaling step
2. For Scale in rules, enter the number of VMs to Remove. Abiquo will delete clone machines and undeploy the base machine
3. If there is no time range, then this is a default scaling rule. A time range must be unique and cannot overlap with other rules with the same scaling direction.
Click Save

When you save the scaling group, Abiquo will mark the VM icon with the scaling group symbol and display the scaling group name.

When the scaling group leaves maintenance mode, Abiquo will create clones of the base VM and deploy them to reach the minimum size.
The number in the bottom right-hand corner of the icon is the number of running VMs in the scaling group, including the base VM.

To open the scaling group and check its parameters, click the scaling group symbol at the top of the VM icon.

Configure automatic scaling actions

To configure automatic scaling actions:

When you define a scaling group, select Create autoscaling action and Save the scaling group
In the dialog, select a Metric to control an autoscaling action
To configure more options, including the thresholds for scaling in and scaling out, click Show more
To add this action, click Add
Add more actions as required

The platform will automatically create the alarms, alerts, and action plan to automatically scale in or out according to your thresholds.

Trigger autoscaling

Before you begin:

Create a VM and a scaling group for the VM. See Define a scaling group
1. If you create an automatic scaling action, then the VM metrics will trigger autoscaling when they cross the thresholds set for the actions

To enable autoscaling operations to run:

Create an action plan with a scaling action for the VM with the scaling group. See Create an action plan to automate VM actions
Create triggers to run the action plan. See Create a trigger for an action plan

When scaling, the platform will search for a scaling rule that is valid for the specific time range, or for a default rule. It will create or delete/undeploy the number of VMs in the rule, then wait for the cooldown period before accepting another scaling request.

Autoscaling will not run if the scaling group is in maintenance mode.

How the platform scales VMs

To scale out, the platform does not deploy VMs that are undeployed in the scaling group. To clone the base VM, the platform will do the following:

Create disks using the following:
1. Copies of content of disks from the VM template
2. Empty disks or volumes for each additional disk used in the VM
3. Disk controllers used in the VM
Apply ALL configuration used in the VM, for example:
1. CPU and RAM
2. Network connections of the same type (e.g. private network)
3. Assignment of firewall policies and attachment to load balancers
4. Backups, startup script, cloud-init, variables, and so on
5. Metrics. The group of metrics from clone VMs and the base VM (if it is deployed) can activate alarms in the base VM, even if it is not deployed
6. Exception – Alarms: the scaling group has only one set of alarms in the base VM

To scale in, Abiquo currently selects the VMs to delete or undeploy using first in, first out (FIFO). The platform deletes and undeploys VMs without requesting user confirmation when there are disks that are not stored in the Apps library (ISO configuration drive or additional hard disk).

Perform maintenance on a scaling group

To make changes to your VMs in a scaling group (manually deploy, undeploy, delete, etc.) and edit the scaling group, put it into maintenance mode, which will disable autoscaling.

When you leave maintenance mode, the platform will apply your modifications to the scaling group, e.g. adding new rules. Then the platform will adjust the number of VMs in the group to within the minimum and maximum size range.

To put the scaling group in maintenance mode:

Go to Virtual datacenters → Virtual appliances → select VM
At the bottom of the VM icon, click the cog maintenance symbol at the bottom of the VM icon
OR if the scaling group is open, click the spanner maintenance symbol in the top right corner

To leave maintenance mode

Click a maintenance button

To automatically manage maintenance mode

Trigger action plans with the action "Scaling group: start maintenance mode" or "Scaling group: end maintenance mode".

To delete the base VM, you must delete the scaling group first.

Delete a scaling group

When you delete a scaling group, the platform will place all the VMs in the virtual appliance as regular VMs and the scaling group constraints will no longer exist.

To delete a scaling group:

Go to Virtual datacenters → Virtual appliances
Open the scaling group
Click the wrench maintenance button to put the scaling group into maintenance mode
Click the trash can delete button

Alarms

Introduction to alarms

An alarm activates when a metric passes a certain threshold. If you imagine a dashboard for your metrics, alarms are like red lights that light up when conditions change, for example, when there is a problem.

If you would like the platform to notify you when an alarm activates, create an Alert for it in Control view.

Alerts are a group of one or more alarms. They are like a worker monitoring a group of alarms; when all the lights for the group are lit up, then the worker takes action and activates the alert. Alerts can also trigger action plans to perform automated actions when their alarms activate. After you create an alert, create an action plan in Control view with the alert as a trigger.

You can create alarms for built-in VM metrics or scaling group metrics, as well as custom metrics created using the API for VMs, scaling groups, virtual appliances, and virtual datacenters.

You cannot create alarms for cloned VMs that are part of a scaling group. This is because scaling groups have aggregate alarms that are associated with the base VM.

Display alarms in virtual datacenters

To display alarms in virtual datacenters:

Go to Virtual datacenters
Select a virtual datacenter or All virtual datacenters
Go to Alarms

Display alarms in virtual datacenters in Display alarms in virtual datacenter view

Create an alarm

Before you begin:

Configure the metrics you will use in the alarm. See VM monitoring and metrics and Custom metrics resources.

To create an alarm:

Privileges: Access alarms section, Manage alarms

Go to Virtual datacenter → Alarms
Select virtual datacenter, virtual appliance, scaling group, or VM
Click the + add button
Enter the alarm details
Enter the alarm metric details and for more information see the Alarm UI fields table below.
Click Save

Alarm UI fields table

Field	Description
Entity type	Select an entity with metrics from the list on the left.
Entity name	The name of the entity
Entity label	The label of the entity, which for VMs is shown in the list on the left
Entity icon	The icon that the platform displays in the UI for VMs and virtual appliances
Name	Name of the alarm with up to 128 characters. Alarm names must be unique for each metric
Description	Description of the alarm. Used together with the alarm name and VM name to identify the alarm, for example, when creating an alert
Metric	Select one of the metrics available for the VM
Metric unit	The unit of the metric. Read only
Metric description	The description of the metric. Read only
Dimension	When the metric has multiple dimensions, optionally select one or more dimensions. For example, if a VM has multiple hard disks, then the disk read bytes metric may have a dimension for each disk
Last datapoints in period	The number of datapoints that the platform will evaluate for the metric during the elapsed time. If you request the evaluation of an alarm more frequently than metric data is collected by the platform or sent by the provider, then the alarm will not activate. We recommend that you create alarms with longer evaluation periods, for example, an average of 10 points over the last hour, so the transmission and collection intervals will not affect the activation of the alarm.
Statistic	Statistic that the platform will use for evaluating the alarm, which can be: average, maximum, minimum, sum, count, dev
Formula	Operator that the platform will use for evaluation of the alarm, for example, greater than. Values can be: notequal, greaterthan, greaterthanorequalto, lessthan, lessthanorequalto, trendup, trenddown
Threshold	Value that the platform will evaluate the alarm against, if appropriate

The platform will create the alarm for the metric. If you would like the platform to notify you when an alarm is triggered, create an Alert.

Troubleshooting alarms that do not trigger

The minimum value of the time period to evaluate alarms is 1 minute, but the platform collects metrics data every 2 minutes by default. The administrator can also configure the time for each hypervisor or provider.
For the default configuration, to ensure that an alarm will activate, you should set the alarm to evaluate every 2 minutes as a minimum.
In addition, each provider sends metrics at different intervals, for example, with Amazon Basic monitoring, data is sent every 5 minutes, and with Advanced monitoring, every minute. In contrast, for vCloud, data is available on consultation.

For a scaling group, an alarm on a metric of the VM in the base workload will receive input from the metrics of all VMs in the scaling group. This means the base workload and/or the clone VMs. So an alarm for a scaling group can activate, even if the base workload is not deployed.

For API documentation about alarms on an entity, see the API documentation for the entity's resource. For example, for VMs, see VirtualMachinesResource.

Edit an alarm

When you edit an alarm, you cannot modify the metric or the entity.

When you edit an alarm, there is an extra field, "Active", that shows if the alarm is activated or not.

After you save the alarm, the platform will start to evaluate it again with new data when it receives the next set of metrics datapoints.

Delete an alarm

You can delete any alarm at any time, even if it is part of one or more alerts. The platform will not warn you that the alarm is used in an alert. However, you can check this in Control view. After you delete an alarm, you cannot recover it.

You can also remove an alarm from an alert.

Privileges: Access alarms section, Manage alarms, Manage alerts

To delete an alarm:

Go to Virtual datacenters or Infrastructure → Alarms
Select the alarm and delete it by clicking on the trash bin delete button

To remove an alarm from an alert:

Go to Control → Alerts → edit alert
Select the alarm, click the trash bin delete button, and confirm
The platform will remove it from this alert, but it will remain in all other alerts that it is associated with

If you delete a VM, the platform will delete any alarms associated with its metrics.

Alerts

Introduction to alerts

Alerts are a group of one or more alarms. An alert can notify the user when it activates and it can also trigger action plans. An alert activates when all its alarms are activated. An alarm activates when a metric passes a certain threshold.

If you imagine a dashboard for your metrics, alarms are like red lights that light up when conditions change, for example, when there is a problem. Alerts are like a worker monitoring a group of alarms; when all the lights for the group are lit up, then the worker takes action and activates the alert.

Display alerts

To display and manage alerts:

Go to Control → Alerts

Create alerts and alarms

An alert will trigger when all its alarms are activated. You can use the alert to notify users and trigger automation. See Manage action plans.

Privileges: Access alerts section, Manage alerts

Before you begin:

Retrieve VM built-in metrics, by editing VMs and enabling monitoring (see VM monitoring and metrics) or create custom metrics
Create one or more metric alarms (see Manage cloud alarms and Infrastructure alarms). You cannot save an alert without an alarm

To create an alert:

Go to Control → Alerts
Click the + add button
Enter the General information
1. To disable action when the alert activates, select the Muted checkbox
2. For the Email, enter a comma separated list of emails to notify when the alert activates
To assign alarms to the alert, click the + add button. To be able to save the alert, you must assign at least one alarm.
1. Select an existing alarm, or create a new alarm, and assign it to the alert. You can filter the Alarms list by Metric and also if the alarm is Active or not.
2. Repeat for the required alarms.
3. Click Confirm
Click Save

Remove alarms from alerts

You can delete any alarm at any time, even if it is part of one or more alerts. The platform will not warn you that the alarm is used in an alert. However, you can check this in Control view. After you delete an alarm, you cannot recover it.

You can also remove an alarm from an alert.

Privileges: Access alarms section, Manage alarms, Manage alerts

To delete an alarm:

Go to Virtual datacenters or Infrastructure → Alarms
Select the alarm and delete it by clicking on the trash bin delete button

To remove an alarm from an alert:

Go to Control → Alerts → edit alert
Select the alarm, click the trash bin delete button, and confirm
The platform will remove it from this alert, but it will remain in all other alerts that it is associated with

If you delete a VM, the platform will delete any alarms associated with its metrics.

Action plans

Introduction to action plans

To enable more control over cloud operations, users can create action plans that will automatically run tasks on VMs and scaling groups, and to run general tasks, such as sending an email or web hook.

Action plans are an important automation functionality of the platform. They can combine general tasks with tasks that run on VMs and scaling groups in different providers and have multiple triggers including alerts from custom metrics, built-in metrics, budget alerts, and schedules.

Users can select groups of VMs or scaling groups to run actions based on tags. And multiple action plans can apply to a VM or scaling group.

Display action plans

To display action plans:

Go to Control → Action plans

Create an action plan

Before you create an action plan, consider the elements that you wish to automate with the action plan. Create VMs or scaling groups, fetch metrics, and create alarms and alerts.

To create an action plan:

Go to Control → Action plans, and click the + add button
Enter the action plan details
Go to Actions to add actions:
1. Click the + add button
2. Select the action Type: general action, VM, scaling group, VMs by tags, scaling groups by tags
3. If you are selecting by tags, then enter the tag filter.
  See Search for resources by tag and filter search
4. Enter action details
  1. Decrease CPU/RAM: you cannot use this with hot-reconfigure and you must check that the OS is compatible
  2. Instance: Name for Instance (clone) template. The platform will append the date to the name supplied
  3. Webhook action - Expected HTTP status code: If this status code is returned, continue running the action plan. Default: 204 No Content
  4. Email action - To, CC: Enter email addresses as a comma separated list
    For more details, see Action plan actions table and Webhook actions table below.
Put the actions in run order using the arrow buttons

To run the action plan automatically, go to the Triggers tab and create an alert or schedule trigger.

When you create actions on VMs also consider the following constraints.

User constraints: e.g. allocation limits
Platform constraints: e.g. to create an instance, the VM must be deployed and powered off
Hypervisor constraints: e.g. with hot reconfigure on ESXi, you cannot reduce CPU or RAM

For the API you can request the JSON schema for each action plan entry type from the API.
See: https://wiki.abiquo.com/api/latest/ActionPlansResource.html#list-action-plan-entry-templates

Action plan actions table

Action	Notes and Parameters
Virtual machine
Increase CPU	vCPUs
Decrease CPU	vCPUs. Not supported by hot-reconfigure. Check OS compatibility
Increase RAM	RAM RAM unit of GB or MB
Decrease RAM	RAM. Not supported by hot-reconfigure. Check OS compatibility RAM unit of GB or MB
Increase hardware profile	Use the same family and type
Decrease hardware profile	Use the same family and type
Resize disk	Amount Disk unit of GB or MB Selected disk
Instance	Name for Instance (clone) template. The platform will append the date to the name supplied All disks or selected disks
Set hardware profile	Select from the available hardware profiles
General
Send email	Subject Body To (email addresses) Cc (copy to these addresses) Enter email addresses as a comma separated list
Send webhook	See webhook attributes table
Scaling group
Start maintenance
End maintenance
Scale in
Scale out

Webhook action attributes table

Attribute	Description	Required	Default value
Endpoint	Where to submit the request	true
HTTP Method	The type of request can be GET, POST, or PUT	false	GET
Expected HTTP status code	If this status code is returned, continue running the action plan	false	204 No Content
Request headers	Headers such as, secret, authentication, and content-type	false
Request content	Request body	false

Run an action plan now

To run an action plan immediately to test it, do these steps:

Go to Control → Action plans
Select the action plan
On the Actions pane, click the Run action plan button

Abiquo recommends that you run an action plan manually to test it before you create a trigger to run it automatically.

Create a trigger for an action plan

The platform supports two types of triggers to run action plans: Alerts and Schedules.

To run your action plan based on metrics, select an existing alert with these steps:

Go to Control → Action plans
Select an action plan
Below the Alerts panel, click the + add button
Select an alert. For details about creating an alert, see Manage alerts.

To run your action plan automatically at selected dates and times, cre

ate a schedule trigger with these steps:

Go to Control → Action plans
Select an action plan
Below the Schedules panel, click the + add button
Enter the details of the schedule using the calendar or time and repeat interval as described below

To run the action plan at intervals of a fixed number of seconds within a set timeframe:

Select an Interval schedule
Enter the following parameters
1. Interval seconds: the number of seconds from when the action plan execution starts to when it will start again
2. Repeat count: the number of times to run the action plan. A value of 0 means repeat forever
3. Start time: date and time
4. End time: date and time

After you create an interval schedule, the platform will display the execution count of how many times the action plan has run. If the repeat count is 0, the execution count is null

To run the action plan using a Cron-type schedule:

Select an Advanced schedule
Use the calendar selector.

Delete an action plan

If you delete an action plan, Abiquo will also delete the schedule associated with that action plan.

Cloud VM automation guide

VM configuration for automation

VM monitoring and metrics

Enable VM monitoring and metrics

Display metrics for a VM

Automate VM first boot with a configuration or script

Add variables for the configuration of your VM

Add VM variables

Read guest variables

Use collectd plugin for custom metrics

How to install and configure collected for VMs in Abiquo

Automate the install of collectd using Chef

Related links

Example collectd data object

Custom metrics entities

Custom metrics display in the UI

Display custom VApp metrics

Scaling groups

Introduction to autoscaling

Automatically scale VMs

Define a scaling group

Configure automatic scaling actions

Trigger autoscaling

How the platform scales VMs

Perform maintenance on a scaling group

Delete a scaling group

Alarms

[data-colorid=u0s1q37h0k]{color:#030303} html[data-color-mode=dark] [data-colorid=u0s1q37h0k]{color:#fcfcfc}Introduction to alarms

Display alarms in virtual datacenters

Create an alarm

Troubleshooting alarms that do not trigger

Edit an alarm

Delete an alarm

Alerts

Introduction to alerts

Display alerts

Create alerts and alarms

Remove alarms from alerts

Action plans

Introduction to action plans

Display action plans

Create an action plan

Run an action plan now

Create a trigger for an action plan

Delete an action plan

Introduction to alarms