When you have a simple schedule, the basic ignore properties are a good option. These are intended for somewhat rigid schedules, such as every weekend or nightly after 11:00 PM (22:00). But they are not the best fit for schedules that are ad hoc. Since the schedule is part of the sensor definition, if you want to change it on the fly, it requires editing and saving many sensors. It is easy to miss one or make a mistake. You may need to undo your changes once complete, and so on. Additionally, changing the underlying source of a policy triggers it to reload and re-evaluate all sensors which can cause trigger duplicate alerts and other side effects.
Introduction
The solution to these is a schedule policy. The concept is very simple. If the schedule policy returns a success state than any sensors that reference it are treated normally. For any other state, referenced sensors go into ignore. The power of a schedule policy comes from what determines its state. A key factor is that the schedule policy is external to the sensors and yet controls their behavior.
Day of Week Example
Let's take a very simple example. The following schedule policy is simple. A single sensor returns SUCCESS if it is Monday through Friday and WARNING on the weekend. In the examples below, weekday is on the left and weekend on the right.
Using another simple sensor that is just tracking whether a system is up or down, we can now set it to ignored on the weekend, simply by referencing this policy. See example below
The sensor below is being controlled by the schedule policy shown above. It will be active during the week on the left and ignored on the weekend.
This example is simple but the possibilities of a schedule policy are endless, they can be triggered by any data elements. Since the schedule is just an evaluation of data being collected within your environment, you can use anything that you can collect.
External Control via other Experts
One scenario that is often used is a database with a holiday schedule in it. You can use the SQL Query expert to check that database to determine if today is a holiday. You can then trigger the schedule using that. Using this technique in the example below, while it not the weekend, it is a holiday, so the schedule is in a warning state and related sensors are going to be ignore. A significant advantage of this is that the calendar is being maintained externally and no manual intervention is required.
Suppose you wanted a way to manually trigger an ignore period from a script or some other scheduling system. That can also be done. The Process Wrapper expert accepts facts from external systems. By entering a command or running a script, you could set an indicator to initiate an ignore window and to turn if off when complete.
apfact -fact ignore_active=true
It is during the week, it is not a holiday but a manual override is in effect so the related sensors are in ignore state.
Linking Schedule Policies
One final example is that a schedule policy can include a link to another schedule. The examples above are generic and could be applied to multiple applications. Rather than create this logic over and over, you can just link within a specific application schedule.
In this case, the payroll application has its own triggers and includes the common schedule.
Testing
One benefit of a schedule policy can be demonstrated with this simple example. When using the basic ignore options, to test them, you would need to modify the sensors for different time periods and such, but this can lead to errors and is not really a good testing method, To test the behavior with schedule policies, you can simply change the schedule policy. With this example, you could use the manual override or change the logic to say that Wednesday is a weekend day.
Summary
There are many other potential use cases for schedule policies and hopefully this short article has created an interest to explore them further.