Calculate your consumption of Metrics powered by Grail - Query (DPS)

  • Latest Dynatrace
  • Explanation
  • 6-min read
Metrics - Query feature overview

This page describes the Metrics powered by Grail - Query DPS capability. For an overview of the capability, including its main features, see Metrics powered by Grail - Query.

Querying metrics using the timeseries command (timeseries avg(dt.host.cpu.usage) is always included in your DPS subscription and never results in costs.

Queries involving other data types generally incur usage at each query, even when they output timeseries format. For example, the following query that uses the maketimeseries command results in consumption based on the GiB volume of data read during the DQL query execution: fetch logs | maketimeseries count().

Create log metrics to reduce your consumption

If you frequently use predefined maketimeseries or summarize commands, it might be more cost-effective for you to create a log metric. Log metrics are regular metrics that are billed for Ingest & Process (and Retain above 15 months), but not for Query.

The above example could be turned into a log metric log.all_logs_count, consuming 525,600 metric data points per year (assuming at least one log record per minute), and the query would then become timeseries sum(log.all_logs_count).

Assuming the equivalent query using logs (fetch logs | maketimeseries count()):

  • scans 40 GiB over the last 2 hours,
  • is triggered 10 times per day each day.

The query usage over the logs version would be 40 GiB * 10 * 365 = 146,000 GiB per year. When multiplied by the Log Management & Analytics – Query price on your rate card, the Metrics powered by Grail – Ingest & Process cost of the log metric is two orders of magnitude less than the Logs Management & Analytics - Query cost of the command using the logs, and even more so if the amount of logs scanned increases (due to longer timeframes, for example).

Related tags
Dynatrace Platform