11/12/2020 | Press release | Distributed by Public on 11/12/2020 11:55
Dynatrace is unique amongst its competitors in that it keeps the largest of large-scale enterprise landscapes foremost in mind. Within such large environments, you want to control who sees what information. This is important both for maintaining team focus but also for security and regulatory concerns. This is why we introduced management zones some time ago. Management zones provide a unique mechanism for defining access permissions based on cloud-native components and their dependencies. Management zones simultaneously promote collaboration and the sharing of relevant team-specific data while ensuring secure access controls.
Recently, we simplified StatsD, Telegraf, and Prometheus observability by allowing you to capture and analyze all your custom metrics. No matter if your metrics are directly related to application and service performance, or if you just want to support other data analytics use cases within your company, you can now use Dynatrace to collect and analyze every metric that's important to the various departments of your enterprise.
However, in large enterprise landscapes where many teams must work together and share data within complex web-scale monitoring environments, you need to focus each team's attention on the data that they're responsible for, rather than dumping all available data on them.
Compared to other flat metric solutions, Dynatrace comes with an enterprise-ready solution for fine-grained access control over all your Prometheus, StatsD, and Telegraf metrics.
Having a highly sophisticated way of organizing data visibility between monitoring teams makes a huge difference in efficiency when building charts, analyzing incidents, and reacting to problems because teams aren't drowning in unnecessary information. In such cases, Dynatrace ensures productive and effective collaboration while still enforcing rigid access restrictions where it matters.
Let's take a deeper dive into the two use cases mentioned above.
Management zones are used to distribute and organize access and visibility rights across your entire company. In regards to the first use case outlined above, let's explore how to grant access to a selected metric within a Dynatrace management zone.
Let's assume that your security department asks you to collect some important security-related metrics (for example, firewall metrics) within your monitoring environment. Within other simple metric-monitoring solutions, you would have no choice other than to expose this metric to all other users who have access to the monitoring environment. This is not the case with Dynatrace! As you don't want to share this type of information with all users of your monitoring environment, you can restrict a selected metric to just the management zone that your security team can access.
For simplicity reasons, let's assume that all security-related metric identifiers in this example start with the prefix security. (for example, security.firewall and security.logins).
We'll configure a security-related management zone that includes these metrics. The first step is to navigate to Settings > Preferences > Management zones and select Add new management zone.
Once on the Create management zone page (shown below), select Add new rule to configure a rule that includes all metric identifiers that begin with the prefix security.
This single rule allows the Security management zone to access all metric measurements that have the identifier prefix security.
As this management zone doesn't grant any entity access, users who can only access the Security management zone are restricted to charting and analyzing just those security metrics that begin with the prefix security. Of course, you can add additional metric access rules to the Security management zone, along with the necessary topological access.
The example above shows how to restrict one or more metrics to a management zone, which is a great option for organizing access at the metric level. But what about use cases where more fine-grained access to metric measurements is necessary?
One use case where more fine-grained access is necessary at the metric measurement level is the collection of company-wide business data.
Let's assume that your company operates hundreds of individual retail shops across the United States and you want those shops to report a selected set of business KPIs into your monitoring environment. For simplicity, we'll assume that each shop reports a revenue number every minute along with the shop identifier, the region, the city, and whatever information your business intelligence needs for further analysis.
Below are some example measurements (Github) for this business metric, streaming in each minute:
business.revenue,shop=shop23,city='New York',region='useast',country='US' 2000
business.revenue,shop=shop17,city='San Diego',region='uswest',country='US' 1000
The screenshot below shows the resulting chart of the total revenue across all shops and regions.
A split along the region dimension reveals the total revenue per region, as shown below.
Now, one might argue that visibility into total revenue across hundreds of shops is fine for global company management, but the individual regions should only see their own regional revenue stream. This can easily be configured by defining a dimensional metric rule within a management zone that is dedicated to the individual region, as shown below.
Now members of the management zone Region-US-East only see revenue for the corresponding region, as shown below.
Now that you can distribute access rights for individual metric measurements across multiple management zones, you have all the flexibility you need to shape your enterprise's access to monitoring and data.
According to your own access strategy, you can create management zones to grant data access for each of your individual shops or for higher-level aggregates, such as regions or global access.
In all cases where a custom metric is ingested via one of your own OneAgent-monitored hosts (assuming that your team is granted access to that host), your team also has access to these custom metric measurements.
Please note that this doesn't automatically include all measurements of that custom metric but only those measurements that were sent in for your host. All other measurements of other teams' hosts won't be automatically granted in your management zone.
The newly introduced flexibility in collecting Prometheus, StatsD, and Telegraf metrics comes with new challenges related to company-wide access to your organization's business-critical metrics. By extending Dynatrace management zones to include rules for filtering metrics based on their dimensional information, monitoring administrators are now empowered to shape fine-grained access scopes for custom metrics at the team level.