Compound Check
- Caleb Miller
The Compound Check is a virtual, aggregated check, meaning that there are multiple individual checks, in a specified monitor subgroup, whose statuses/results make up the results of this Compound Check.
Use Case
If you have multiple checks that need to be collectively assessed before creating an event/alert, this is the check type that allows the logic that says, “Whenever X checks are over a certain count/threshold set an aggregate result to all of them.”
Example 1 Global API Application Response: If you have 4 global checks, measuring your API response from 4 different locations, US, EU, APAC, and China but you know that China has a firewall that has caused checks to be periodically down (fatal) for known periods, the Compound Check can create logic that states that 3 of the 4 checks must be in a fatal condition for at least X number of times (or X percentage of the results) before you can declare the API application to be in a Fatal condition.
Example 2 North America Regional Performance over Time: If you have 6 North America checks, measuring your Check-out Cart response times from 6 different locations, 4 US (Northeast, Northwest, Southeast, and Southwest), 2 Canadian (East and West Coasts), the Compound Check can create logic that states that 4 of the 6 checks must be in a slow response/Warning condition least 25% of the results in the last hour before you can send an alert to your operations team to check if your e-commerce application servers might be overloaded.
This will give you the ability to lower your false-positive rates when you set realistic thresholds and have other checks be validators of what may turn out to be a historically unreliable region or network.
Step | Screenshot |
|---|---|
|
 |
|  |
3. Select from a pre-defined Monitor Subgroup from the dropdown box. This will focus the aggregation of the checks to a specific group of checks. If you don’t have that Subgroup pre-defined, you will need to do this first for it to show up in this dropdown. | The monitor subgroup containing the checks to aggregate. Status information from all checks in the selected subgroup will be included. E.g. for the selection “Basic Checks \ URL Checks”, all URL Checks under the Basic Checks Group will be aggregated. |
Monitoring Group Aggregations Across Checks in the Group | |
Return Value | Which type of aggregation information to be returned on the selected checks. Choices are:
The screenshot shows a Return Value of Percent. |
Latest Run - Severity Status Match List | A string containing the severity statuses to include in aggregation. Possible values are I (Info), W (Warning), E (Error), and F (Fatal). Example: WEF (this string will aggregate all selected checks with a severity status of Warning, Error, or Fatal). In the screenshot, the string is set to EF. So, in the count/percent Return Value, only the checks that return an E (Error) or F (Fatal) are calculated in the count/percentage. |
Latest Run - Checks Threshold | This is the threshold for the “Latest Run - Result Severity“ to be applied. So, if the Return Value (Count/Percent of checks matching the Latest Run - Severity Status Match List) exceeds this setting, then the severity status of this Compound Check will be set to the Latest Run - Result Severity, chosen below. In the screenshot, the threshold is set to 50 + Percent |
Latest Run - Result Severity | The severity status to set for this Compound Check if the number of checks matches the criteria in the previous two fields. NOTE: If both the Latest Run and Consecutive Runs criteria are triggered at the same time, then the worst of two severities will be applied. In the screenshot, the Result Severity is set to F meaning (in this screenshot) that if 50% of the checks in the Basic Checks\URL Checks result in Error or Fatal, the result severity will be Fatal. |
Consecutive Runs; Checks Results Over Time | |
Consecutive Runs - Count | This Compound Check’s status will be set to the chosen Consecutive Runs -Result Severity (see that table row below) whenever the number of runs matching the Consecutive Runs-Severity Status for any single check in the selected monitor subgroup exceeds the number set here. To disable tracking of individual checks, set this value to -1. Tracking times start with the most current result and looks backwards. In the screenshot, the Consecutive Runs Count is set to 5; 5 consecutive runs of this check over time. |
Consecutive Runs - Severity Status | For any single check in the selected monitor subgroup, the severity status to use when counting matching consecutive runs. Possible values are I (Info), W (Warning), E (Error), and F (Fatal). Example: WEF (this string will count the total consecutive runs every single check has matched a severity status of Warning, Error, or Fatal). In the screenshot, the Severity Status is set to EF, so for every check in the Basic Checks\URL Checks that has matched a severity status of Error or Fatal will be counted. |
Consecutive Runs - Result Severity | The severity status to set for this Compound Check if the consecutive runs of a single check match the criteria in the previous two fields. Possible values are I (Info), W (Warning), E (Error), and F (Fatal). In the screenshot, the severity will be set to E meaning (in this screenshot) that if 5 consecutive checks in the Basic Checks\URL Checks result in Error or Fatal, the result severity will be Error. |
Can't find what you're looking for? Send an E-mail to support@apica.io