Dynatrace Buckets
Dynatrace buckets are storage containers that hold logs, metrics, and events with custom retention rules. You set them up by defining storage pools and routing incoming records by source or sensitivity. Teams often group all app logs into one big default pool at first. That choice makes setup fast, but it gives every reader broad rights over sensitive records. When roles stay too wide, any user can read private data across every service. How dynatrace buckets work in your stack The platform u
Buckets: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Dynatrace buckets are storage containers that hold logs, metrics, and events with custom retention rules. You set them up by defining storage pools and routing incoming records by source or sensitivity. Teams often group all app logs into one big default pool at first. That choice makes setup fast, but it gives every reader broad rights over sensitive records. When roles stay too wide, any user can read private data across every service.
How dynatrace buckets work in your stack
The platform uses a central storage engine to keep your incoming telemetry data. When your apps send logs or events, an ingest pipeline checks each record. The pipeline matches fields on the record against routing rules that your team wrote. Once a rule matches, the engine writes the record into the chosen storage container.
Each container has its own retention time so you control storage costs and data rules. You can keep payment audit logs for years while dropping noisy debug logs after days. Access control relies on role policies attached to user groups in your account. You bind a policy to a group and name which containers that group can query. You can also add field filters to limit which rows return during a search.
Planning your bucket layout and roles
A clean layout starts by splitting data by team ownership and sensitivity level. Do not make hundreds of tiny containers for every single microservice in your stack. Having too many containers slows down cross-service searches and makes role management very hard. Instead, group records into a few clear tiers like production, staging, security, and payments.
Next, map your identity provider groups to specific read roles for each container tier. Product engineers might get read rights to general app logs in staging and production. Security teams get read rights to audit containers that hold login and network events. Review your ingest routing rules often so new services do not land in default pools. When a new app goes live, make sure its logs route to the right container.
Buckets: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native bucket rules solve and what they miss
Splitting logs into separate containers solves two big problems for growing engineering teams. First, it stops high-volume debug logs from driving up storage bills for long-term data. Second, it keeps general users from browsing top-tier security or finance logs by mistake. Native role bindings check who logs in and which storage containers they can query.
Still, storage boundaries alone do not inspect what happens inside the underlying systems during triage. When an engineer reads an error in a log, they must connect to databases or hosts to fix it. Native log roles cannot control the live commands or queries run during that session. Also, apps often leak emails, phone numbers, or card numbers into standard app logs. Any user with read rights to that container will pull those fields in query results. Data masking rewrites matched fields like card numbers or national IDs in query results.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
When should a team create a new bucket?
Create a new container when data needs a different retention time or stricter read rules. Do not make new containers just to copy your team chart or folder names.
Can you move old logs from one bucket to another?
No, routing rules only apply when records first arrive in the ingest pipeline. Once the engine writes a record to a container, it stays there until it expires.
How do you stop sensitive data from leaking in shared buckets?
Strip sensitive fields like emails or phone numbers before your apps send the logs out. You can also route sensitive services to locked containers with strict role policies.