Try it free

Application snapshots OpenPipeline use cases

  • Latest Dynatrace
  • Tutorial
  • 5-min read
  • Published Sep 04, 2026

Application snapshots captured by Live Debugger are routed through OpenPipeline as the application.snapshots data type—the same processing infrastructure used for logs, spans, and events. This page covers two common use cases: enriching snapshots with custom attributes in a processing pipeline, and restricting access to snapshots using dt.security_context together with an IAM policy.

Who is this for?

This tutorial is for platform and security administrators who manage OpenPipeline configurations. You don't need to change how developers use Live Debugger; the enrichment and access control happen at the pipeline level, with no changes required to how developers use Live Debugger.

What will you learn?

By the end of this tutorial, you'll have an OpenPipeline configuration that processes application snapshots before they're stored in Grail, either by enriching them with custom metadata, restricting access by team, or both.

In this tutorial, you'll learn how to:

  • Add custom attributes to snapshots at ingest time using the Add fields processor, so snapshots are tagged with team ownership or environment metadata before they're stored in Grail.
  • Set dt.security_context on snapshots using the Set security context processor, and enforce team-level read access by creating a matching IAM policy statement.

Enrich snapshots with custom attributes

You can use OpenPipeline to add or transform attributes on snapshots before they are stored in Grail. This is useful for tagging snapshots with organizational metadata—such as team ownership, environment, or cost center—so they can be filtered, queried, and governed consistently.

Steps

  1. Go to Settings Settings > Process and contextualize > OpenPipeline > Application snapshots > Pipelines.

  2. Find an existing pipeline or select Pipeline to create a new one.

  3. Enter a name for the pipeline, for example, Tag snapshots by team.

  4. Expand the Processing tab and select Processor > Add fields.

  5. Configure the processor as follows.

    FieldValue

    Name

    Add team ownership

    Matching condition

    matchesValue(k8s.namespace.name, "payments")

  6. Add the fields you want to attach to matching snapshots, for example:

    NameValue

    dt.owner

    payments-team

    deployment.environment

    production

  7. Select Run sample data to validate the processor against a sample snapshot record.

  8. Select Save.

Conclusion

Snapshots from the payments namespace are now tagged with dt.owner = "payments-team" and deployment.environment = "production" at ingest time. You can filter by these attributes in Notebooks Notebooks, Dashboards Dashboards, and DQL queries:

fetch application.snapshots
| filter matchesValue(dt.owner, "payments-team")

Restrict snapshot access by team

dt.security_context is a special attribute that OpenPipeline writes to records at ingest time to enable fine-grained, record-level access control in Grail. By setting this attribute on snapshots and then creating a matching IAM policy statement, you can ensure that each team can only read snapshots belonging to their own services, without any change to how developers use Live Debugger.

Set the security context in OpenPipeline

  1. Go to Settings Settings > Process and contextualize > OpenPipeline > Application snapshots.

  2. Find an existing pipeline or select Pipeline to create a new one.

  3. Enter a name for the pipeline, for example, Snapshot access control.

  4. On the Permission tab, select Processor > Set security context.

  5. Configure the processor as follows.

    FieldValue

    Name

    Team context from namespace

    Matching condition

    true

    Security context value

    Choose Field name and set the source field to k8s.namespace.name

    Using a field name rather than a static string means the dt.security_context automatically reflects each snapshot's actual namespace. You can also use a static string (for example, payments-team) if a single pipeline covers a known set of namespaces.

  6. Select Save.

Once new snapshots arrive, each record stored in Grail has a dt.security_context value that matches its Kubernetes namespace. Verify this in a notebook:

fetch application.snapshots
| fields dt.security_context, k8s.namespace.name

Create the IAM policy statement

Now create an IAM policy that grants read access to snapshots only when the dt.security_context matches the team's own namespace.

  1. Go to Account Management > Identity & access management > Policy management.

  2. Select Create policy or edit an existing policy by selecting > Edit policy.

  3. Add a policy statement that allows reading snapshots scoped to the team's context.

    Example

    Grant the payments-team group read access to snapshots from the payments namespace only:

    ALLOW storage:application.snapshots:read
    WHERE storage:dt.security_context = "payments";

    You can combine multiple conditions. For example, to additionally restrict by cluster:

    ALLOW storage:application.snapshots:read
    WHERE storage:dt.security_context = "payments"
    AND storage:k8s.cluster.name = "prod-cluster-eu";

    Members of payments-team can now read only those snapshots where dt.security_context = "payments" and, if you add the cluster restriction, where storage:k8s.cluster.name = "prod-cluster-eu". Snapshots from other namespaces return empty results rather than an error, which preserves the security of sensitive debugging data without revealing the existence of other teams' snapshots.

    For details on enforcing access with policy statements, see Configure advanced permissions with security context.

  4. Select Save and assign the policy to the relevant user group.

Congratulations!

You've configured OpenPipeline to process application.snapshots records before they reach Grail. Specifically, you learned how to:

  • Tag snapshots with custom attributes so they can be filtered and queried by team, environment, or any other dimension that matters to your organization.
  • Use dt.security_context and IAM policy statements to enforce team-level access boundaries—without changing anything in Live Debugger or the applications being debugged.

As a next step, verify your configuration by querying snapshots in a notebook:

fetch application.snapshots
| fields dt.owner, dt.security_context, k8s.namespace.name

Related topics

  • Set up Grail permissions for Snapshots
  • OpenPipeline processing examples
  • Configure advanced permissions with security context
  • Set up Grail permissions for logs
Related tags
Application ObservabilityLive DebuggerLive Debugger