The Schedule Management screen displays the list of all Schedules and allows for adding, editing and removing them.
Once the schedule is defined, it can be used for executing Actions, Auto-scaling and disabling alerts during Maintenance periods.
The Schedule is active only if the definition was applied to some Action or Resource. A single Schedule can be applied to multiple Actions and Resources.
Schedules are a simple, yet very powerful idea. They save a lot of time and enable specialists to focus on more interesting tasks by automatically performing certain activities at provided times.
The schedule definitions are very flexible and can easily be configured to fit even untypical scenarios. The simplest schedule allows to perform a certain task daily at a specific hour. However, it’s just as easy to define a schedule that will perform the same task on the 3rd day of every month, or every second Saturday in January, March and May.
The ActionExecution schedule can be used to automatically perform Actions, such as shutting down or starting Virtual Machines and WebRoles, cleaning up servers, or generating reports by running a SQL script.
That feature is particularly useful in case of memory leaks. Restarting Virtual Machines regularly is easier than tracking down causes of subtle leaks, and in many cases is an acceptable solution.
The same schedule definition can be used multiple times for various tasks. For example, it’s possible to define a single schedule that will be used to restart a WebRole and run a script on a database in order to generate a weekly report.
The MaintenanceWindow schedule can be used to disable raising alerts during maintenance hours. Typically many alerts are triggered during maintenance, because resources are inaccessible and metrics values fall outside the typical ranges. On the other hand, that’s the expected behaviour which doesn’t require any action. Therefore alerts would only generate noise and most likely would be simply ignored.
During the duration of the MaintenanceWindow Schedule all the metrics are collected in a standard way, so no information is lost and t’s possible to access that data in case of unexpected failures.
The ScalingRange schedule can be used for auto-scaling Azure Web Apps and Azure Cloud Roles instances. It’s similar to Actions, however it’s used exclusively for managing the number of resources.
That feature is particularly useful for optimizing usage of resources in systems that have well-known access patterns which fluctuate regularly. For example, many websites are accessed mainly during the day, but the traffic tends to be low at night. Using ScalingRange schedule in combination with ScaleAdjustments CloudMonix can automatically spin up at least 10 instances of the Web App during peak hours, and reduce it to only 2 instances at other times.
Approximate Start Time
Some Schedules definitions specify the Approximate Start Time. In order to properly define the start time, it's important to understand how CloudMonix works.
CloudMonix performs work in cycles (called monitoring cycles). By default the cycle is 10 mins. long in the Free Plan, and 1 min. long in the Professional and Ultimate Plans. Apart from capturing values of various metrics, in each monitoring cycle CloudMonix checks if any activities needs to be performed based on the active Schedules.
Therefore, it’s possible that the start time will be slightly later than specified in the CloudMonix definition. The possible delay depends on the monitoring frequency and the delay in receiving data from Azure.
For example, if a schedule is defined to start at approximately 10 am, but the monitoring cycle starts at 9:59:50 am and the monitoring frequency is 1 min., then the actual start time for the action could be 9:01:50 or slightly later. If the monitoring frequency is 10 min., then the actual start time for the action could be 9:09:50 or slightly later.
When defining Schedules keep in mind the possible delays and whenever necessary adjust the definition to account for them.
The schedule definitions are very flexible and can easily be configured even for untypical scenarios.
If the schedule frequency is set to daily, it is necessary to specify the Approximate Start Time of the activity (in UTC).
If the schedule frequency is set to weekly, it is necessary to specify the Approximate Start Timee of the activity (in UTC) and on what days it should be executed. The approximate start time will be the same for all selected days in that schedule.
If the schedule frequency is set to monthly, it is necessary to specify the Approximate Start Time of the activity (in UTC) and on what days it should be executed. In the monthly schedule the days to run can be defined as days of the week in specified weeks of the month.
For example, the maintenance might be planned for every second Saturday in January, February and March:
Or for example, some report might need to be generated on the 6th day of every month:
Testing Schedules Definitions
The MaintenanceWindow and ScalingRange definitions often are complex, therefore they can be tested using a tool built into the schedule definition form: