../_images/preview.png

Event Descriptions

Events are automatically fired by Scalr over the lifecycle of your Farms and Servers (Instances). For Servers these events can be used to trigger Scope level, Role and Farm Role orchestration rules. For Farms events can be linked to Webhooks and Endpoints to trigger integration actions with external systems.

You will find the list of events built in to Scalr below along with details of how each event occurs and their uses. Scalr also supports Custom Events.

Farm Life Cycle Events

Farm Events can only currently be used with Webhooks and Endpoints and Approvals.

BeforeFarmLaunch

  • Farm launch has been requested. In this stage a Farm is in the “Pending launch” state and waiting for “approval” (if one is required).
  • Any Farm’s cloud resources cannot be launched in this state considering that previous state was Terminated.
  • Event is triggered as soon as Farm is launched.

FarmLaunched

  • Farm has successfully been launched. Farm status is Running.
  • When “approval” is not required this event is triggered immediately after BeforeFarmLaunch event independently from the statuses of the Farm’s Servers. If approval is required the event is triggered as soon the “approval” is received.

FarmSuspended

  • Farm has been suspended.
  • Triggered as soon as Farm is suspended by the initiator (User, Lease manager / lights out functionality)

FarmResumed

  • Farm has been resumed.
  • Triggered as soon as Farm has resumed by the initiator (User, Lease manager / lights out functionality)

BeforeFarmTerminate

  • Termination of Farm has been requested. The Farm will be in “Pending terminate” state and waiting for the “approval” if required.
  • All cloud resources remain in their current state.

FarmTerminated

  • Farm has been terminated.
  • All Farm’s servers are put in the Pending terminate state at this point.
  • Triggered immediately after BeforeFarmTerminate event if the “approval” is not required, or as soon as it is received otherwise.

Server Life Cycle Events

Note

The ONLY guaranteed sequence for events occurs when a server is booting up and the events are being processed on the triggering server.
This sequence is HostInit -> BeforeHostUp -> HostUp.

Warning

The sequence/order that events are received when the target is NOT the triggering server or the target is a Webhook ARE NOT guaranteed and may vary from case to case due to the multithreaded processing of events in Scalr.


BeforeInstanceLaunch Event

Firing Sequence


  • When Scalr provisions a new Server for a given Farm Role and the Server state from Pending Launch state to Pending State.
  • Scalr fires the BeforeInstanceLaunch Event after making an API Call to your Cloud Platform.
  • Event will not fire if the API Call fails.
Scalr Event Actions None
When to Use You may use this event to execute setup Orchestration Actions on other Servers (Instances).
Global Variables













Server-Scope Global Variables will already include the Server’s Cloud ID.

Event Scope Global Variables
SCALR_LAUNCH_REASON : This is a string that indicates why this instance is being launched.
(Scalr makes no guarantees as to the stability of this output. For integrations, ensure you use the below code.)
SCALR_LAUNCH_REASON_CODE : This is an integer code that corresponds to the launch reason.

Launch Reason Codes
  1. This Server is being launched as a replacement due to a rolling replaced triggered Create an Image with Server Snapshot
  2. The Farm Role this Server belongs to is scaling up due to Autoscaling, and this Server is being launched
  3. The Farm this Server is associated with is being launched
  4. The Server was launched manually through the API
  5. The Server was launched manually through the UI

HostInit Event

Warning

The HostInit Event does not fire on reboots! To fire Orchestration Rules on reboot, use the RebootComplete Event.


HostInitFailed Event


BeforeHostUp Event

Warning

The BeforeHostUp Event does not fire on reboots! To fire Orchestration Rules on reboot, use the RebootComplete Event.

Firing Sequence

  • When a Server is booting up but just before firing the HostUp Event.
  • Scalr guarantees that Blocking Scripts configured to execute on BeforeHostUp will terminate before HostUp fires (See: Execution Mode in Scripts).
Scalr Event Actions
None
When to Use


  • For bootstrapping and setup actions, such as installing software, or configuring applications.
  • In most cases, use Blocking Orchestration Rules with BeforeHostUp.
  • As a general rule, non-blocking Scripts should probably use the HostUp Event instead.
Global Variables No Event Scope Global Variables
Flagging Servers as Failed




Scalr gives you the option to place Servers in Failed State when an Blocking Orchestration Rule triggered by the BeforeHostUp Event fails (i.e. the Script exits with a non-zero exit code).
This allows you to ensure that Servers that failed to initialize properly are placed in Failed State and not in Running State.
When a blocking script failes a HostInitFailed Event is raised and the HostUp Event is not raised.
This option is controlled in the Advanced Options tab of Farm Roles.

HostUp Event

Warning

The HostUp Event does not fire on reboots! To fire Orchestration Rules on reboot, use the RebootComplete Event.

Firing Sequence


  • When a Server has finished initialization steps.
  • Scalr expects Servers to be ready to perform their desired function when they fire HostUp. Thus all internal services and applications should be configured and running before this event fires.
Scalr Event Actions


  • Scalr’s built-in Roles use the HostUp Event to register Servers with built-in load balancing Roles, such as Nginx and HAProxy.
  • Scalr’s built-in DNS also uses the HostUp event to create DNS records and add Servers to them.
  • Scalr sets it’s internal status as shown in the UI and API to RUNNING
When to Use


  • To notify other Servers that a Server is ready to perform it’s desired function.
  • For low-priority initialization actions, which do not affect the functinality of the Server, such as registering it with a monitoring solution.
Global Variables No Event Scope Global Variables

IPAddressChanged Event

Firing Sequence
  • When a Servers IP Address changes after it has finished booting, i.e. if an IP address changes after the HostInit Event.
Scalr Event Actions
None
When to Use
  • To reconfigure services that would depend on the IP Address of a Server (such as DNS service).
Global Variables



  • SCALR_OLD_PUBLIC_IP: Public IP Address for this Server before the IP Address changed.
  • SCALR_OLD_PRIVATE_IP: Private IP Address for this Server before the IP Address changed.
  • SCALR_NEW_PUBLIC_IP: Public IP Address for this Server as a result of the change.
  • SCALR_NEW_PRIVATE_IP: Private IP Address for this Server as a result of the change.

Note

IPAddressChanged event fires when a Server is Resumed. The *OLD* variables will show the old IP Address as “N/A”


EBSVolumeAttached Event

Warning

  • This event fires for block devices on all clouds, not just EBS block devices.
  • This event does not fire on Windows Servers.
Firing Sequence
  • When a block device is attached to a Server.
Scalr Event Actions
None
When to Use


  • To format or perform any other actions on the newly attached volume.
  • If you requested that Scalr automatically mount block devices when they are attached (see Storage Tab), you should not use this Event, and should use the EBSVolumeMounted Event instead.
Global Variables

  • SCALR_DEVICE_NAME: this is the device name for the block device (e.g. /dev/sda)
  • SCALR_VOLUME_ID: this is the cloud ID for the block device (e.g. vol-c7541db1)

EBSVolumeMounted Event

Warning

  • This event fires for block devices on all clouds, not just EBS block devices.
Firing Sequence


  • When a block device is mounted on a Server.
  • Note that this Event only fires when a volume was Mounted by Scalr. If you mounted a volume using mount or a similar command (either manually or using an Orchestration Action), Scalr will not know about it, and the EBSVolumeMounted Event will not fire.
Scalr Event Actions
None
When to Use

  • To take action once a block device you required is mounted to your Server’s filesystem, such as creating a standard directory structure.
Global Variables

  • SCALR_DEVICE: this is the device name for the block device (e.g. /dev/sda)
  • SCALR_MOUNTPOINT: this is the filesystem location where the block device was mounted (e.g. /mnt)

BeforeHostTerminate Event

Firing Sequence
  • When Scalr schedules a server for termination or suspension but before it is actually terminated or suspended.
Scalr Event Actions
None
When to Use

  • To perform cleanup actions such as de-registering a Server from your load balancer or monitoring solution, or removing it from your DNS Zone.
Global Variables




  • SCALR_TERMINATION_REASON: This is a string that indicates why this instance is being terminated. * Scalr makes no guarantees as to the stability of this output. For integrations, ensure you use the below code.
  • SCALR_TERMINATION_REASON_CODE: This is an integer code that corresponds to the termination reason.
  • SCALR_IS_SUSPEND: This is an integer code that corresponds to the termination reason. This is set to 0 if the host is being terminated, and to 1 if it is being suspended.

Note

By default Scalr will make the API call to the Cloud service to terminate the server 3 minutes after the termination request is made in Scalr. However Scalr can be configured to wait until all orchestration scripts run by the BeforeHostTerminate Event have completed before terminating the server. The config parameter scalr.system.server_terminate_timeout can be set to auto to enable this. When set to auto if there are no orchestration scripts on BeforeHostTerminate, Scalr will terminate the server immediately. However, if there are scripts on BeforeHostTerminate, Scalr will terminate the server only when Scalr receives confirmation that the scripts have completed.


HostDown Event

Firing Sequence
  • After it has been suspended or terminated
Scalr Event Actions
None
When to Use
  • For non time-sensitive cleanup actions, such as de-registering a Server from your monitoring solution.
Global Variables






















  • SCALR_TERMINATION_REASON: This is a string that indicates why this instance is being terminated.
  • SCALR_TERMINATION_REASON_CODE: This is an integer code that corresponds to the termination reason.
  • SCALR_IS_SUSPEND: This is set to 0 is the host is being terminated, and to 1 if it is being suspended.

Termination Reason Codes

  1. MongoDB-Only: Shutting Down Cluster
  2. MongoDB-Only: Removing Replica Set from Cluster
  3. Reserved for future use.
  4. The Farm Role this Server belongs to was removed from the Farm
  5. The Server (Instance) timed-out when launching (view Advanced Tab - Timeouts)
  6. Reserved for future use.
  7. The Server was a temporary Server created Create an Image with the Image Builder, and it is no longer needed
  8. The Farm Role this Server belongs to is scaling down due to Autoscaling, and this Server is being decommissioned
  9. This Server was a Replacement Server launched after Create an Image with Server Snapshot with Server Replacement, but the Replacement process was cancelled and this Server is being rolled-back to the original Role
  10. The Server was terminated manually through the UI
  11. The Server was terminated manually through the API
  12. Reserved for future use.
  13. The Farm this Server is associated with is being terminated.
  14. This Server is being replaced due to a rolling replaced triggered Create an Image with Server Snapshot
  15. The Server was a temporary Server created Create an Image with the Image Builder, but the role-building process was aborted
  16. The Server crashed (e.g. it was terminated in your Cloud Platform)

Warning

  • Scalr makes no guarantees as to how long it will take for HostDown to fire after a Server has been terminated.
  • In some cases, the HostDown Event may fire multiple times for a server going offline. Your Orchestration Rules should be ready to handle this condition.

RebootComplete Event

Firing Sequence

Scalr Event Actions
None
When to Use
  • To perform post-boot actions without having to hardcode them into your cloud image’s init.d, such as remounting some network storage to the filesystem.
Global Variables
None

ResumeComplete Event

Firing Sequence
  • When a Server finishes booting after resuming from a stop, such as Resuming from a Suspended State.
Scalr Event Actions
None
When to Use
  • To perform post-boot actions without having to hardcode them into your cloud image’s init.d, such as remounting some network storage to the filesystem.
Global Variables
None