Datadog’s "rehydration" isn’t about bringing logs back from the dead, it’s about paying a premium to access logs that have been moved to cheaper, slower storage.
Let’s see it in action. Imagine you’ve got a security incident and need to check logs from 3 months ago. Your standard Datadog interface might show "No data" for that period. This isn’t because the logs vanished, but because Datadog, by default, moves older logs from its hot, performant storage to "warm" or "cold" archival storage to save you money. To see them again, you need to initiate a rehydration request.
Here’s how it typically works:
- Identify the Timeframe: You’ll need the exact start and end timestamps for the logs you want to access. This is crucial for Datadog to know what to retrieve.
- Initiate Rehydration: This is usually done via the Datadog API or sometimes through a specific UI option if available for your account tier. You’ll specify the logs’ source (e.g.,
source:kubernetes,service:my-app), the time range, and the desired retention period for the rehydrated logs (how long they’ll stay in hot storage before archiving again). - Datadog Processes the Request: Datadog’s backend team receives your request, locates the archived logs on their slower storage, and copies them back to your active, searchable log streams.
- Access Rehydrated Logs: Once the rehydration is complete (which can take anywhere from a few minutes to several hours, depending on the volume and your Datadog plan), you can query them as if they were still in hot storage.
The problem this solves is the economic reality of storing vast amounts of log data indefinitely. Storing everything in high-speed, readily accessible storage would be prohibitively expensive for most organizations. Datadog’s archival tiers allow you to retain logs for compliance or historical analysis at a fraction of the cost, with the understanding that immediate access comes with a delay and an extra charge.
The exact levers you control are primarily:
- Archival Policy: You configure how long logs stay in hot storage before being moved to warm/cold. This is a trade-off between immediate availability and cost.
- Rehydration Scope: When you request rehydration, you specify the exact logs (by attributes like service, source, and tags) and the time window. This ensures you only pay to bring back what you actually need.
- Rehydrated Retention: You can often specify how long the rehydrated logs should remain in hot storage before being archived again. This is useful if you know you’ll need to query them repeatedly over a short period.
The surprising thing many users don’t realize is that rehydrated logs aren’t just made instantly available. They are copied back. This means that if you have a very long rehydration period set, and then initiate another rehydration for the exact same logs and time range but with a different retention, you might end up with duplicate log sets in your hot storage, each with its own rehydration timestamp and eventual archive schedule. This is a subtle point that can lead to confusion if you’re not tracking your rehydration requests carefully.
After successfully rehydrating logs, the next challenge often becomes correlating them with other observability data like traces or metrics from the same period, which might also have been archived or are not immediately obvious to link.