I'm trying to understand what's the source for the data in the problem feed. Let's say that we have 2 alerting profiles: "Default" and "Critical". Default of course has the default settings. Critical has quite a few filters in place (which we can mostly emulate by filtering based on tags at the API call), but most of all it has definitions such as raising Error alerts only when the problem has been active for 15 minutes, etc.
So these 2 profiles generate alerts with different rulesets, and you can see that at the Dynatrace UI by filtering based on the alerting profile - for example using "Critical" would remove several problems from the list.
So I'm kind of thinking out loud, but I guess my question here is not only about the Problem API, but also the ruleset behind problem creation at the Dynatrace UI, right? So the Problem feed is just collecting all the problems at the UI, regardless of any alerting profile filters. If that is the case, what are the rules used? For example the Default alerting profile raises Slowdown problems after they've been open for 30 minutes. Does it mean that from the Problem Feed's perspective, it would still display a Slowdown problem that was only active for 1 minute? So could we say the the ruleset behind the problem creation at the Dynatrace UI is essentially using "Immediate" for all entities?
Solved! Go to Solution.
Alerting Profiles is only a filter on the overall list of detected problems. So the total number of problems always stays the same number but the alerting profile applies a filter to the total number of problems for the purpose of sending only a subset as alerts to a selected channel, e.g.: ServiceNow.
Alerting profiles do offer multiple filters, such as problem duration, severity level and even event types within a problem.
In the future we do plan to offer all the filters that you have in the problem feed also as alerting profile.
I hope that helps?
Thanks Wolfgang! I suppose this comment "In the future we do plan to offer all the filters that you have in the problem feed also as alerting profile." actually refers to having them in the Problem API? Because you can already filter the problem feed based on alerting profile, but doing the same for the Problem API would be a new feature actually. Currently the only filter available are tags.