Filter metrics by management zone
You can filter metric data by management zone in two ways.
The following sections discuss each method and any security considerations of filtering metric data by management zone.
Entity-based rules to filter metric data
You can define UI-based or text-based rules to provide access to entities within a management zone. Management-zone users automatically get access to the metrics whose entity type matches the entities scoped within the management zone. Note that the entity type of a metric is the primary entity associated with that metric. While a metric can have several entity-based dimensions, these are not the same thing as the entity type.
Metric entity type
You can check the entity type of a metric using:
Alternatively, you can explicitly configure the entity type for ingested custom metrics by setting the Source entity type on the Metric metadata page.
There are two limitations of filtering metric data in management zones via entity-based rules.
Filtering metrics by entity-based rules only works for the entity type of a metric. A metric can have multiple entity-based dimensions like
dt.entity.disk, but most metrics have only one entity type. Suppose an entity-based rule of a management zone refers to an entity that's not the entity type of a metric. In that case, the metric series won't be visible when the management zone is applied, even if an entity-based dimension of the metric does match the rule.
For example, if your management-zone rule matches
QUEUEentities starting with a given string, the metric
builtin:queue.incoming_requestswon't be visible in the management zone. This is because even though the metric has the
dt.entity.queueentity-based dimensions, its entity type is
SERVICE, which doesn't match the rule referring to
If a metric has multiple entity types, management-zone filtering isn't applied. This limitation impacts metrics with the dimensions
Dimensional rules for metric data
If a metric's entity type doesn't match the entity-based rule in a management zone, you can define a dimensional rule to match the metric's entity-based dimension. For example, for the
builtin:queue.incoming_requests metric, you need to define a dimensional rule for the
dt.entity.queue dimension. Note that the value of the dimension condition must be the entity ID (for example,
'dt.entity.queue' equals 'QUEUE-43717C10AF1BD1E0') and not the entity name (see the image below).
The following are the security considerations of metric data display and measures to mitigate the impact.
Metric series visible in all management zones
Management-zone filtering doesn't work for metrics with multiple entity types. The following metrics are affected by this limitation.
builtin:apps.other.metrics with the dimension
Due to this limitation, users who shouldn't have access to these metric series can still access them regardless of management zone.
The metric-selector transformations
names add information to metric data queries, which can expose the ID of the parent monitored entity (such as the ID of a host that is parent to a process) or the display name of the entity in the case of the
While these caveats are noteworthy, the practical security impact is limited. The data from the metrics with multiple entity types is typically not sensitive. For security-sensitive environments, we recommend taking the caveats regarding metric-selector transformations (for example, entity IDs such as
HOST-27A71FA663E7F352 and the display of hostnames) into account when granting a user permission to read any metric data.
We recommend special care in deciding which dimensions are sent as part of the data for security-sensitive custom metrics to ensure that the desired read-access restrictions are effective.