As you scale log ingestion, allowing all logs to flow into the default_logs bucket makes it progressively harder to configure access control, optimize queries, and manage costs. A planned logs bucket strategy makes each of these tasks easier and provides a better query experience for all teams. These best practices help you design that strategy before log volume forces reactive decisions.
Split log buckets by line of business rather than by individual application. Splitting by application too granularly can exhaust the 80-bucket limit per environment before you have enough buckets to serve business-level groupings.
Examples of line-of-business bucket groupings:
This approach keeps your bucket count manageable, reduces operational overhead, and provides meaningful partitioning for access control and cost allocation. If a specific application within a line of business requires separate treatment—for example, due to compliance retention requirements or unusually high volume—create a dedicated bucket for it as an exception rather than the rule.
Teams migrating from Splunk often try to replicate an index-per-application approach with Grail buckets. Splunk indexes and Grail buckets serve a similar purpose, but a direct mapping is not always the right design. Start with line-of-business groupings and add application-level buckets only where volume or compliance requirements justify it.
Design your bucket strategy so that each bucket receives between 1 TB and 3 TB of log data per day. This range provides a good balance between query performance and cost.
Dynatrace applies default query limits that affect how much data a query can scan:
At 1–3 TB/day ingest per bucket, a query scanning 500 GB covers approximately 4–12 hours of logs. This is a useful time range for most operational queries. At 100 TB/day in a single bucket, the same 500 GB scan covers only a few minutes of logs, making historical queries impractical without increasing scan limits.
Increasing scan limits is possible, but it raises both query runtime and DPS cost. Design your bucket strategy to make the default limits sufficient for the most common query patterns.
Put log data into the same bucket when it meets all of the following conditions:
Separating data that must be queried together into different buckets requires users to join across buckets or run multiple queries, which increases complexity and cost.
default_logs as a catch-all or keep it empty The default_logs bucket should serve one of two roles:
default_logs empty. This approach gives you the most control over where data lands and makes access control simpler.Avoid letting default_logs accumulate a large, growing volume of mixed log data. Once the bucket fills with heterogeneous logs from many sources, configuring access control and optimizing queries becomes significantly harder.
The 80-bucket limit per environment can be increased based on ingest volume by contacting your Dynatrace account team. Request an increase only after demonstrating through the volume assessment that the current limit is genuinely insufficient for your bucket strategy, not as a precaution.
Explore the other best practice for this stage, or return to Partition your Grail data to continue your upgrade.