Skip to content

Slice & Dice

🎯 Lab Goals#

By the end of this lab, you will:

  • Understand the customer’s requirements, dimensions, and technologies for 3rd-Gen Data Access & Partitioning.
  • Perform a pre-investigation for an existing customer scenario.
  • Identify key dimensions and technologies to enable: Granular data access using dt.security_context, Cost allocation with dt.cost.costcenter and dt.cost.product
  • Validate findings against customer requirements to guide the next stage: metadata enrichment at source.

🧪 Exercises#

To execute a solid 3rd-Gen Data Access & Partitioning design, we need a clear understanding of the customer’s:

  • 📋 Requirements
  • 📐 Dimensions
  • 🖥️ Technologies

Existing or New Customer?#

New Customer: Gather requirements directly from them. D1 CoE provides guidance on key questions to ask during these conversations here.

Existing Customer: They already have an approach in place. Historically, customers relied on Management Zones for Data Access and Segmentation. For these cases, conduct a pre-investigation (if possible) to collect relevant information beforehand.

For this lab, as presented earlier, we’re working with an existing customer, so we’ll proceed with a pre-investigation.

Existing Customer Pre-investigation#

Data Access#

Dynatrace Classic Data Access was role-based (RBAC), and permissions looked like this:

For this exercise, we’ll provide screenshots of Easytrade’s Access Control since RBAC cannot be created in Dynatrace sprint today. During a real customer engagement, you should also review:

In Classic, customers often created groups for individual Management Zones (MZ). Users were linked to these groups, granting visibility into everything within that zone.

Tip

This approach was simple but not ideal. In a shared infrastructure, how would you give each team access to their own logs if permissions were tied to the entity itself?

With Dynatrace 3rd-Generation Platform, every datapoint (entities, logs, spans) is treated independently, allowing granular access for each team.

Back to the exercise: during pre-investigation, we found the following for our customer scenario:

Success

  • Teams should only access their own apps
  • Customer uses Management Zones in Dynatrace Classic

Following the investigation with a customer validation.

Dimensions#

What do we mean by Dimensions?#

In our customer scenario, app is a dimension, and Easytrade is its value.

Dimensions are key–value pairs that provide context for metrics, logs, or traces. They transform raw data into actionable insights by enabling slicing, filtering, and aggregation.

Historically, customers stored dimensions in HOST_GROUP (from the source) or defined them as tags and/or Management Zones.

  1. Explore the dimensions within your customer environment. You can use this Notebook

    Tip

    Dimensions give us a clear way to slice and dice a customer’s environment:

    • Metadata Enrichment at Source: Identify which attributes should be added as metadata during ingestion. Ensure these enrichments align with tagging standards for cloud-native environments.
    • Security Context: Determine which dimensions can be leveraged as dt.security_context
    • Bucket Strategy: Avoid excessive bucket creation (e.g., 18k apps across 30 BUs should not result in 36k buckets). Use a multi-dimensional approach, group lighter apps by Business Unit (BU). Assign dedicated buckets to high-volume apps (those with higher TB/day traffic).

Technologies#

  1. Explore the technologies within your customer environment. You can use this notebook

    Tip

    Previously, customers relied heavily on auto-tags, which often led to performance issues due to excessive processing and complexity. With Dynatrace 3rd-Gen, the recommended approach is to enrich metadata at the source, ensuring better scalability and efficiency.

    The enrichment strategy should adapt to the underlying technology. Different platforms (e.g., Kubernetes, AWS, Azure, OpenShift) offer distinct tagging and annotation mechanisms, so best practices must be tailored accordingly.

🌱 Closing Up#

Requirements#

With our findings on RBAC, Dimensions, and Technologies, and leveraging the Slice & Dice, we are prepared to:

  • Validate customer requirements
  • Map critical fields for the next stage, including: dt.security_context, dt.cost.costcenter, dt.cost.product

Resulting in the following:

Area Requirement Dimension
Data Access
  • Teams should only access their own apps
  • The customer uses Management Zones in Dynatrace Classic
 dt.security_context = <app> (easytrade)
Partitioning
  • They didn't have such thing in Classic, we'll implement a bucket strategy to meet their requirements and improve performance & costs
 App, we could use dt.security_context
Segmentation
  • Customers needs to be able to easily navigate through Dynatrace interface and see their respective apps as well as app signals.
  • Using also Management Zones, as other dimensions. We may have to find out!
 All Dimensions as a Segment, set missing dimensions as Primary Grail Tags
Cost Allocation
  • They want to track the spending for each app
 dt.cost.costcenter = <app> and dt.cost.product = <app> (easytrade)

Technologies#

K8s running on GCP, important to understand the most convenient enrichment mechanims for the customer

Note

This table will be quite useful for the next steps. Keep it in a separate tab to help yourself set things up accordingly

Resources#

To save in your bookmarks!

D1 CoE: - D1 CoE | 3rd-Gen setup helper - Notebook to execute pre-investigation - D1 CoE | How to gather requirements from customer - D1 CoE | Why Not Management Zones, drive better conversations about enrichment at source, motivate your customer to scalable and cluster-friendly approaches.

Collab

We’d love to hear from you! If you have best practices, ideas, or suggestions to improve existing content—whether in Notebooks or CoE pages, please share them with us. Your input helps us make this material more valuable and actionable for everyone.