-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Add an Agent Observability data retention page and link pricing #39676
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
e3c17ca
d69e761
d9d5464
88657a7
da3f308
3f046eb
7151ee3
a656962
bf84424
21656ae
7c5ad80
a661ef8
67278f1
dad9e81
8d0a917
fa7a12b
210e2d5
24b5560
988f1f3
d7210b6
046226a
fe0d524
5bf8d1d
8bb87fa
bdfd6cc
99201fa
0c0d62d
9e875e1
c1a0b2b
68ff510
b308b53
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,145 @@ | ||
| --- | ||
| title: Data Privacy, Security, and Retention | ||
| aliases: | ||
| - /llm_observability/data_privacy_security_and_rbac/ | ||
| - /llm_observability/data_security_and_rbac/ | ||
| description: Control access to sensitive Agent Observability data with data access controls and RBAC, redact data with span processors, and learn how long Agent Observability retains each type of data. | ||
| further_reading: | ||
| - link: "/account_management/rbac/data_access" | ||
| tag: "Documentation" | ||
| text: "Learn more about data access controls" | ||
| - link: "/llm_observability/improve/datasets/" | ||
| tag: "Documentation" | ||
| text: "Work with datasets and dataset versions" | ||
| - link: "/data_security/data_retention_periods/" | ||
| tag: "Documentation" | ||
| text: "See default data retention periods across Datadog products" | ||
| - link: "https://www.datadoghq.com/pricing/?product=llm-observability#products" | ||
| tag: "Pricing" | ||
| text: "Agent Observability pricing" | ||
| --- | ||
| {{< whatsnext desc=" ">}} | ||
| {{< nextlink href="https://datadoghq.com/legal/hipaa-eligible-services">}}<u>HIPAA-Eligible Services</u>: Datadog Legal's list of HIPAA-eligible services{{< /nextlink >}} | ||
| {{< /whatsnext >}} | ||
|
|
||
| ## Data Access Control | ||
|
|
||
| Agent Observability allows you to restrict access to potentially sensitive data associated with your ML applications to only certain teams and roles in your organization. This is particularly important when your LLM applications process sensitive information such as personal data, proprietary business information, or confidential user interactions. | ||
|
|
||
| Access controls in Agent Observability are built on Datadog's [Data Access Control][11] feature, which enables you to regulate access to data deemed sensitive. You can use the `ml_app` tag to identify and restrict access to specific LLM applications within your organization. | ||
|
|
||
| ## Redacting data with span processors | ||
|
|
||
| You can redact or modify sensitive data at the application level before it is sent to Datadog. Use span processors in the Agent Observability SDK to conditionally modify input and output data on spans, or prevent spans from being emitted entirely. | ||
|
|
||
| This is useful for: | ||
| - Removing sensitive information from prompts or responses | ||
| - Filtering out internal workflows or test data | ||
| - Conditionally redacting data based on tags or other criteria | ||
|
|
||
| For detailed implementation examples and usage patterns, see the [Span Processing section in the SDK Reference][12]. | ||
|
|
||
| ## Sensitive Data Scanner integration | ||
|
|
||
| Agent Observability integrates with [Sensitive Data Scanner][13], which helps prevent data leakage by identifying and redacting any sensitive information (such as personal data, financial details, or proprietary information) that may be present in any step of your LLM application. | ||
|
|
||
| By proactively scanning for sensitive data, Agent Observability ensures that conversations remain secure and compliant with data protection regulations. This additional layer of security reinforces Datadog's commitment to maintaining the confidentiality and integration of user interactions with LLMs. | ||
|
|
||
| ## Data retention | ||
|
|
||
| Retention periods in Agent Observability depend on the type of data and on your plan. Traces from your instrumented applications follow the span retention period in your plan, while experiment definitions, datasets, and prompts have their own periods. | ||
|
|
||
| | Data | Retention period | | ||
| | -------------------------------------------- | ----------------------------------------------------------------------------------------- | | ||
| | Traces and spans | 15 days; 30, 60, or 90 days with a retention add-on | | ||
| | Experiment traces | On-demand plans: 15 days. Committed plans: 90 days. With a retention add-on: 6, 9, or 12 months | | ||
| | Experiment definitions and aggregate results | 90 days from creation | | ||
| | Annotated traces, spans, and sessions | 90 days from the time of annotation, or your span retention period if that is longer | | ||
| | Annotation labels | 90 days, matching the object they annotate | | ||
| | Dataset records | 3 years, regardless of your span retention period | | ||
| | Prompts in the prompt registry | 3 years, extended each time the prompt is pulled | | ||
| | `ml_obs.*` metrics | 15 months | | ||
|
|
||
| ### Traces and spans | ||
|
|
||
| Traces and spans from your instrumented applications are retained for **15 days** on all plans by default. This applies to everything stored on the span, including per-span operational data such as cost, token counts, latency, and errors, as well as evaluation scores attached to spans. | ||
|
|
||
| A retention add-on extends this to **30, 60, or 90 days**. See [Changing your retention period](#changing-your-retention-period). | ||
|
|
||
| Retention applies to the raw spans you query in the Trace Explorer. Metrics derived from those spans are retained separately, for longer. See [Metrics](#metrics). | ||
|
|
||
| ### Experiment traces | ||
|
|
||
| On committed plans, the traces produced by [experiment][3] runs are retained longer than production traces. | ||
|
|
||
| | Plan | Experiment trace retention | | ||
| | ----------------------------------- | -------------------------- | | ||
| | On-demand | 15 days | | ||
| | Committed (monthly or annual) | 90 days | | ||
|
Comment on lines
+77
to
+78
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Which experiment trace retention period applies to Free-tier organizations? If they are included in one of these rows, could we clarify that briefly so readers can identify their retention period? |
||
| | 30-day retention add-on | 6 months | | ||
| | 60-day retention add-on | 9 months | | ||
| | 90-day retention add-on | 12 months | | ||
|
|
||
| If your organization has a custom contract, your retention periods may not match this table. Contact your Datadog account representative to confirm your periods. | ||
|
|
||
| ### Experiment definitions | ||
|
|
||
| The experiment itself — its name, configuration, and aggregate results — is retained for **90 days** from the time it is created. Unlike experiment traces, this period is the same on every plan and does not extend with a retention add-on. Export any experiment results you need to keep beyond 90 days. | ||
|
|
||
| ### Changing your retention period | ||
|
|
||
| Retention length affects what you are billed, because a longer period means Datadog stores more of your data. For rates, see the [Agent Observability pricing page][10]. | ||
|
|
||
| Retention add-ons are arranged through your account team rather than enabled from the Datadog UI. To request a longer retention period, contact your Datadog account representative or [Datadog support][1]. | ||
|
|
||
| When you add or extend a retention add-on, the longer period applies **retroactively to every span that has not already expired**. Spans that expired under your previous period are not recoverable. | ||
|
|
||
| For example, if you are on the default 15-day retention and add a 60-day add-on today, the spans from the last 15 days pick up the 60-day period, but anything older is already gone. | ||
|
|
||
| When you move to a shorter retention period, spans older than the new period are no longer available. | ||
|
|
||
| ### Annotated objects | ||
|
|
||
| Annotating an object extends its retention. When you apply an annotation label or note to a trace, span, or session — whether directly or through an [annotation queue][2] — Datadog retains the annotated object for **90 days** from the time of annotation, even if your span retention period is shorter. Annotating a span retains its whole parent trace, and annotating a trace that belongs to a session retains the whole session. | ||
|
|
||
| If your organization's span retention period is longer than 90 days, annotated objects are retained for that longer period instead. | ||
|
|
||
| Annotation labels are retained for the same 90 days as the object they annotate, and are no longer viewable after that object expires. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do annotation labels follow the annotated object’s retention period, including when it exceeds 90 days, or do labels expire separately at 90 days? The preceding paragraph allows longer object retention, so “the same 90 days” leaves that case unclear. If labels follow the object, could we say “Annotation labels are retained for as long as the object they annotate” and update the label rows in both retention tables accordingly? Also, could the final sentence in this section distinguish notes by whether they are attached, rather than calling them “free-form”? The annotation-queue docs also use “free-form notes” for trace-review observations. Suggested wording: “Adding a note that is not attached to a trace, span, or session does not extend any object’s retention.” |
||
|
|
||
| Extending retention by annotating an object does not incur an additional charge. | ||
|
|
||
| A free-form note is not attached to a trace, span, or session, so adding one does not extend any object's retention. | ||
|
|
||
| ### Dataset records | ||
|
|
||
| Records in a [dataset][4] are retained for **3 years**, regardless of your span retention period. | ||
|
|
||
| Records in previous versions of a dataset are retained for **90 days**. This period is extended each time a previous version is used — for example, when an experiment reads that version. After 90 consecutive days without use, a previous version becomes eligible for permanent deletion. For details on how versions are created, see [Dataset versioning][5]. | ||
|
|
||
| ### Prompts | ||
|
|
||
| Prompts in the [prompt registry][9] are retained for **3 years**. This period is extended each time the prompt is pulled by your application, so a prompt in active use stays available. A prompt that is not pulled for 3 years becomes eligible for permanent deletion. | ||
|
|
||
| ### Metrics | ||
|
|
||
| The `ml_obs.*` metrics generated from your spans are standard [Datadog metrics][6] and follow [standard Datadog metric retention][7]: 15 months at full granularity. They are retained on this schedule regardless of your span retention period, so you can build long-term dashboards and monitors on span counts, token usage, cost, latency, and error rates even after the underlying spans expire. | ||
|
|
||
| For the full list of available metrics, see [Agent Observability metrics][8]. | ||
|
|
||
| ## Further reading | ||
|
|
||
| {{< partial name="whats-next/whats-next.html" >}} | ||
|
|
||
| [1]: /help/ | ||
| [2]: /llm_observability/investigate/annotation_queues/ | ||
| [3]: /llm_observability/improve/experiments/ | ||
| [4]: /llm_observability/improve/datasets/ | ||
| [5]: /llm_observability/improve/datasets/#dataset-versioning | ||
| [6]: /metrics/ | ||
| [7]: /data_security/data_retention_periods/ | ||
| [8]: /llm_observability/investigate/metrics/ | ||
| [9]: /llm_observability/configure/prompt_management/ | ||
| [10]: https://www.datadoghq.com/pricing/?product=llm-observability#products | ||
| [11]: /account_management/rbac/data_access | ||
| [12]: /llm_observability/instrument/sdk/#span-processing | ||
| [13]: /security/sensitive_data_scanner/ | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we distinguish current and previous dataset versions in this row? The three-year statement reads as applying to all records, but the Dataset records section below and the linked Dataset versioning docs give previous versions a 90-day window that resets when used.
Suggested wording: “Current version: 3 years. Previous versions: 90 days, reset when used.”
Please also qualify the opening sentence under “Dataset records” as “Records in the current version of a dataset…” so the two summaries agree.