cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

Alerts not sent to recipients, after CAS 12.3.9 upgrade from 12.3.6

fstekelenburg
DynaMight Pro
DynaMight Pro

Hi,

We noticed several alerts where not being sent anymore, after upgrading CAS from 12.3.6 to 12.3.9.

In RUM console the recipients have a warning sign (exclamation mark)
with message details: "E-mail notifications will not be sent to user
<user> due to access restrictions on dimension Application for
devices: CAS(<ip address>)

Available application: None"

(Sometimes the message/exclamation mark would dis- and reappear?)

When checkin the users and groups rights, they all have unrestricted data access rights.

(It is not set per Application); Local group.

This also happens for a collegue who has admin (group) level rights. (LDAP group)

When I verify the Data Access Permission - Global Configuration, it
is ON and Filtering Dimension is Application. When I turn DAP off, it
appears the warnings disappear. But is this really a solution?
What was the setting in 12.3.6? Was it OFF, or was the Filtering Dimension on another value, Reporting Group perhaps?

Since all users (groups) have data access unrestricted, I wonder why this limitation is appearing (now).

This story is somewhat similar to

https://answers.dynatrace.com/questions/163425/alerts-issue-data-access-restrictions.html

2 REPLIES 2

maciej_walezak
Inactive

Please check the following description of alert notification filtering rules. Hopefully it will help you diagnose your issue.

CAS will verify if given recipient has rights to receive given alert notification. If not then notification will not be sent.

Rules


  1. The filtering is in effect only if multitenancy (data access) is enabled.
  2. Only e-mail recipients for which multitenancy (data access) has been configured are subject to notification filtering.
  3. Only the following metric alarm types are subject to filtering:

    • Metric (probe)
    • Trans
    • Gomez
    • Citrix
    • P2p
    • Tier
  4. Alert
    notification will be filtered out (blocked) if its definition does not
    meet the restrictions defined by multitenancy settings, that is:

    • Alert
      type does not contain multitenancy dimension. For example, if the
      multitenancy level is "Software service" then all notifications for Tier
      alarms will be blocked as Tier alarms do not contain "Software Service"
      dimension.
    • Multitenancy dimension is not selected as monitored dimension (aggregation type is AGGR).
  5. Moreover,
    alert notification will be filtered out if for given alert instance the
    value of multitenancy dimension is not included on recipient's list of
    permitted values.

Example

Consider the following scenario.

Data access permission configuration:

Control data access enabled
Filtering dimension Application
User data access configuration:
User data access status constraints
superuser
chm controlled

SSL
SSLD
SSLD_APPLICATION
SSLD_B_APPLICATION
XML_BA

Alert definition:

TypeReal user performance (probe)
MetricClient bytes (BCLI)
Monitored dimensions (Break by)Application, Software service
FiltersTraffic type: (Real)
Threshold>10
Weight metric
Auxiliary threshold
Alarm triggering modeSINGLE
Alert instances produced from a sample:

[*, SSLD_APPLICATION, *, *, SSLD, *, *, *, *, *, *, *, *, *, *, *, 1760, B, >10, N/A, -, SINGLE]
[*, XML_APPLICATION, *, *, XML, *, *, *, *, *, *, *, *, *, *, *, 26616, B, >10, N/A, -, SINGLE]
[*, XML_SSLD_BA, *, *, XML, *, *, *, *, *, *, *, *, *, *, *, 26616, B, >10, N/A, -, SINGLE]
[*, XML_BA, *, *, XML, *, *, *, *, *, *, *, *, *, *, *, 26616, B, >10, N/A, -, SINGLE]

Notifications received:

superuser

[*, SSLD_APPLICATION, *, *, SSLD, *, *, *, *, *, *, *, *, *, *, *, 1760, B, >10, N/A, -, SINGLE]
[*, XML_APPLICATION, *, *, XML, *, *, *, *, *, *, *, *, *, *, *, 26616, B, >10, N/A, -, SINGLE]
[*, XML_SSLD_BA, *, *, XML, *, *, *, *, *, *, *, *, *, *, *, 26616, B, >10, N/A, -, SINGLE]
[*, XML_BA, *, *, XML, *, *, *, *, *, *, *, *, *, *, *, 26616, B, >10, N/A, -, SINGLE]

chm [*, SSLD_APPLICATION, *, *, SSLD, *, *, *, *, *, *, *, *, *, *, *, 1760, B, >10, N/A, -, SINGLE]
[*, XML_BA, *, *, XML, *, *, *, *, *, *, *, *, *, *, *, 26616, B, >10, N/A, -, SINGLE]

Thank you Maciej for this elaborate information, I will have a look at it to verify the setup.
Still puzzling why something in the behaviour would change by only applying 12.3.9.