The following methodologies (in the same order specified below) are usually considered for the final score determination:
It facilitates the increase of the overall anomaly score if an anomaly is detected with another attribute of the same monitor.
Severity of the anomaly detected in a monitor can be increased if any of the monitors, which are dependent on it or monitor for which it is dependent has anomalies. For example, a URL monitor has a Server monitor as a dependent monitor. If URL monitor has 'Response time' anomaly and at the same time interval, a Server monitor also has 'CPU Usage anomaly', then the score and severity of anomaly will be increased. It can also be inferred that Response time spike is due to spike in CPU usage of underlying server.
These dependent monitors are associated during the additon of the monitor.
Dependency scoring can also be done using Parent/Child dependency. For example, if an underlying plugin monitor has any anomaly, it will also affect the health of the parent server monitor. So, whenever an anomaly occurs in a monitor, we will check if there exists any child monitor of it. If the child monitor also has anomaly, score will be increased and we can infer that the anomaly in parent might be caused due to child monitor's anomaly.
If any of the monitors in the monitor groups (to which current monitor with anomaly belongs to) have anomalies in last half an hour, then it'll increase the overall score. There are two types to add the score:
If monitors with same tags have anomaly, it increases the score for ingrastructure as well as non-infrastructure monitors.
Monitors having same domain name can also be grouped together for Anomaly scoring. In most of the cases, monitors with same domain are affected or have anomalies at the same period.
If none of the above cases are satisfied, scoring is handled based on anomalies detected in other monitors of the similar monitor type.