Events powered by Grail

• Concept
• 15min
• Updated on Jun 17, 2025

While there are no additional costs or licensing involved in the default monitoring and reporting of built-in event types via OneAgent or cloud integrations, you have the option to configure custom events and/or event-ingestion channels. Such event-related customizations generate additional consumption because they require significantly more processing and analytical power than built-in event ingestion via OneAgent or cloud integrations.

The unit of measure for consumed events is the data volume of ingested events in gibibytes (GiB).

The overall consumption model for Events powered by Grail is based on three dimensions of data usage. These correspond to the respective capabilities on your rate card.

Custom created/ingested or subscribed events that might be configured for an environment include:

Usage of different kinds of events affects your consumption differently, as outlined in the table below.

Event kind

Ingest & Process

Retain

Query

Business events

Billable

Billable

Billable

Software development lifecycle (SDLC) events

Billable

Billable

Billable

Custom Davis AI and
Kubernetes events

Billable

Billable

Billable

Davis AI problems
and events

Included
(non-billable)

Limited included
(up to 15 months) ¹

Included (non-billable)

Kubernetes warning events

Limited included ²

Limited included ²

Non-billable
for usage generated in Kubernetes.

Security events ³

Billable

Billable

Billable

Synthetic events ⁴

Included

Limited included

Included (non-billable)

Custom generic events

Billable

Billable

Billable

Usage recorded for business events, custom Davis AI and Kubernetes events, Security events, and other custom generic events (in particular event data stored in custom buckets using the Storage Management app) results in consumption for Ingest & Process, Retain, and Query. The following specifics apply for:

Ingest & Process

Here's what's included with the Ingest & Process data-usage dimension:

Apply the following calculation to determine your consumption for the Ingest & Process data-usage dimension:
(number of gibibytes ingested) × (gibibyte price as per your rate card) = consumption in your local currency

Be aware that data enrichment and processing can increase your data volume typically by 0.5-1.0 kB per event. Depending on the source of the data, and the attributes and metadata added during processing, the total data volume after processing can increase by a factor of 1.5 or more. Processing can also be used to drop unwanted event attributes to reduce retained data volume.

Retain

Here's what's included with the Retain data-usage dimension:

Apply the following calculation to determine your consumption for the Retain data-usage dimension:
(number of GiB of processed data ingested per day) × (retention period in days) × (GiB-day price as per your rate card) × (number of days that data is stored) = consumption in your local currency

Query

Query data usage occurs when:

Here's what's included with the Query data-usage dimension:

Apply the following calculation to determine your consumption for the Query data-usage dimension:
(number of GiB of uncompressed data read during query execution) × (GiB scanned price as per your rate card) = consumption in your local currency

Consumption examples

The following example calculations show how each data-usage dimension contributes to overall usage and consumption.

Step 1 – Ingest & Process

Let's assume that you ingest 5 GiB of event data per day into Dynatrace. The yearly consumption for Ingest & Process is calculated as follows:

Step 2 – Retain

If you retain the ingested 5 GiB of event data, a total of 9 GiB of enriched data is added to storage (5 GiB times an enrichment factor of 1.8).

If you ingest an additional 5 GiB of data per day (i.e., 9 GiB after enrichment), for a total of 35 days, consumption for Retain (after the 35th day) is calculated as follows:

Step 3 – Query

Let's assume that to resolve incidents and analyze performance issues your team executes DQL queries with a total of 60 GiB of data read per day. The yearly consumption for Query is calculated as follows:

Step 4 – Total consumption

The total annual consumption for this example scenario is the sum of the yearly consumption for Ingest & Process, Retain, and Query:

Consumption details

Your organization's consumption of each Dynatrace capability accrues costs towards your annual commitment as defined in your rate card. Your Dynatrace Platform Subscription provides daily updates about accrued usage and related costs. You can access these details anytime via Account Management (Subscription > Overview > Cost and usage details > Events – Ingest & Process or Retain or Query > Actions > View details) or the Dynatrace Platform Subscription API.

On the Capability cost and usage analysis page, select a specific environment to analyze that environment’s cost and usage for a specific capability. On the environment level, Dynatrace provides pre-made Notebooks for each capability you can use for detailed analysis (Actions > View details).

Ingest & Process

The following DQL query provides an overview of total Events – Ingest & Process usage in gibibytes:

fetch dt.system.events
| filter event.kind == "BILLING_USAGE_EVENT" and event.type == "Events - Ingest & Process"
| dedup event.id
| summarize {`Total GiB` = sum(billed_bytes)}

The example below shows the total usage visualized as a single-value chart.

The following DQL query provides an overview of Ingest & Process usage by bucket.

fetch dt.system.events
| filter event.kind == "BILLING_USAGE_EVENT" and (event.type == "Events - Ingest & Process" )
| join [fetch dt.system.buckets], kind:leftOuter, on: { left[usage.event_bucket] == right[name] }
| dedup event.id
| summarize {billed_bytes = sum(billed_bytes)}, by:{timestamp, event.id, right.display_name, event.type}
| makeTimeseries `Total GiB`=sum(billed_bytes), by:{right.display_name, event.type}, time: timestamp

The example below shows the daily usage visualized as a line chart.

The following DQL query provides the hourly Ingest & Process usage

fetch dt.system.events
| filter event.kind == "BILLING_USAGE_EVENT" and event.type == "Events - Ingest & Process"
| dedup event.id
| summarize {`bucket billed_bytes`=sum(billed_bytes)}, by:{billing_period = bin(timestamp, 1h), usage.event_bucket}
| summarize {`Total GiB`=sum(`bucket billed_bytes`), `Total billed buckets`=collectDistinct(record(`Bucket` = usage.event_bucket, `Bucket GiB` = `bucket billed_bytes`))}, by:{`Billing period`=billing_period}

The example below shows the hourly usage by bucket visualized in a nested table view.

Retain

The following DQL query provides the hourly Retain usage by bucket

fetch dt.system.events
| filter event.kind == "BILLING_USAGE_EVENT" and event.type == "Events - Retain"
| summarize {usage.event_bucket = takeLast(usage.event_bucket), billed_bytes = takeLast(billed_bytes)}, by:{billing_period = bin(timestamp, 1h), event.id}
| fieldsAdd bytes_and_bucket = record(bucket = usage.event_bucket, billed_bytes = billed_bytes)
| summarize {`total billed_bytes` = sum(billed_bytes), `billed_bytes by bucket` = collectDistinct(bytes_and_bucket)}, by:{billing_period}
| fields billing_period, `total billed_bytes`, `billed_bytes by bucket`

The example below shows the hourly usage by bucket visualized in a nested table view

Query

The following DQL query provides an overview of total Query usage in gibibytes scanned:

fetch dt.system.events
| filter event.kind == "BILLING_USAGE_EVENT"
| filter event.type == "Events - Query" or event.type == "Events - Query - SaaS"
| dedup event.id
| summarize {
data_read_bytes = sum(billed_bytes)
}, by: {
startHour = bin(timestamp, 1d)
}

The example below shows the daily usage by bucket visualized in a line chart

The following DQL query provides an overview of the Query usage by application:

fetch dt.system.events
| filter event.kind == "BILLING_USAGE_EVENT"
| filter event.type == "Events - Query" or event.type == "Events - Query - SaaS"
| fieldsAdd query_id = if(event.version == "1.0", event.id, else: query_id)
| dedup event.id
| summarize {
data_read_bytes = sum(billed_bytes),
Query_count = countDistinctExact(query_id)
}, by: {
App_context = client.application_context, application_detail = client.source, User = user.email
}
| fieldsAdd split_by_user = record(data_read_bytes, App_context, application_detail, User, Query_count)
| summarize {
split_by_user = arraySort(collectArray(split_by_user), direction: "descending"),
data_read_bytes = sum(data_read_bytes),
Query_count = sum(Query_count)
}, by:{
App_context, application_detail
}
| fieldsAdd split_by_user = record(App_context = split_by_user[][App_context], application_detail = split_by_user[][application_detail], User = split_by_user[][User], data_read_bytes = split_by_user[][data_read_bytes], data_read_pct = (split_by_user[][data_read_bytes] / data_read_bytes * 100), Query_count = split_by_user[][Query_count])
| fieldsAdd split_by_user = if(arraySize(split_by_user) == 1, arrayFirst(split_by_user)[User], else: split_by_user)
| fieldsAdd application_details = record(data_read_bytes, App_context, application_detail, split_by_user, Query_count)
| summarize {
application_details = arraySort(collectArray(application_details), direction: "descending"),
data_read_bytes = sum(data_read_bytes),
Query_count = toLong(sum(Query_count))
}, by:{
App_context
}
| fieldsAdd application_details = record(App_context = application_details[][App_context], application_detail = application_details[][application_detail], split_by_user = application_details[][split_by_user], data_read_bytes = application_details[][data_read_bytes], data_read_pct = application_details[][data_read_bytes] / data_read_bytes * 100, Query_count = application_details[][Query_count])
| fieldsAdd key = 1
| fieldsAdd total = lookup([
fetch dt.system.events
| filter event.kind == "BILLING_USAGE_EVENT" and (event.type == "Events - Query" or event.type == "Events - Query - SaaS")
| dedup event.id
| summarize total = sum(billed_bytes),
| fieldsAdd key = 1
], sourceField: key, lookupField:key)[total]
| fields App_context, application_details, data_read_bytes, data_read_pct = data_read_bytes / total * 100, Query_count
| sort data_read_bytes desc

The example below shows the usage by application visualized in a nested table view