[error-tracking] Apply general doc update (#28724)

Co-authored-by: iadjivon <[email protected]>

Author: 2 people

content/en/error_tracking/dynamic_sampling.md

@@ -41,7 +41,7 @@ A `Dynamic Sampling activated` event is generated when Dynamic Sampling is appli
 When Dynamic Sampling is applied, the following steps are recommended:
 
 - Check which issue is consuming your quota. The issue to which Dynamic Sampling is applied is linked in the event generated in Event Management.
-- If you'd like collect additional samples for this issue, raise your daily quota on the [Error Tracking Rate Limits page][2].
+- If you'd like to collect additional samples for this issue, raise your daily quota on the [Error Tracking Rate Limits page][2].
 - If you'd like to avoid collecting samples for this issue in the future, consider creating an [exclusion filter][3] to prevent additional events from being ingested into Error Tracking.
 
 ## Further Reading

content/en/error_tracking/error_grouping.md

@@ -21,9 +21,13 @@ Error Tracking intelligently groups similar errors into issues. This grouping is
 
 The error stack trace is the code path followed by an error between being thrown and being captured by Datadog instrumentation. Error Tracking evaluates the topmost stack frame (the **location** of the error) and uses it to group the error.
 
-If any stack-frame properties differ for two given errors, the two errors are grouped under different issues. For example, Error Tracking does not group issues across services or error types. Error Tracking also ignores numbers, punctuation, and anything that is between quotes or parentheses: only word-like tokens are used.
+If any stack frame properties differ for two given errors, the two errors are grouped under different issues. For example, Error Tracking does not group issues across services or error types. Error Tracking also ignores numbers, punctuation, and anything that is between quotes or parentheses: only word-like tokens are used.
 
-**Note**: To improve grouping accuracy, Error Tracking removes variable stack-frame properties such as versions, ids, dates, and so on.
+<div class="alert alert-info">
+<strong>Tip:</strong> To ensure optimal grouping, enclose variables in your error messages in quotes or parentheses.
+</div>
+
+**Note**: To improve grouping accuracy, Error Tracking removes variable stack frame properties such as versions, ids, dates, and so on.
 
 
 ## Custom Grouping
@@ -36,7 +40,7 @@ If `error.fingerprint` is provided, the grouping behavior follows these rules:
 
 * Custom grouping takes precedence over the default strategy.
 * Custom grouping can be applied only to a subset of your errors and can coexist with the default strategy.
-* The content of `error.fingerprint` is used as-is without any modification.
+* The content of `error.fingerprint` is used as-is without any modification (although it is converted to a standardized fingerprint format).
 * Errors from the same service and with the same `error.fingerprint` attribute are grouped into the same issue.
 * Errors with different `service` attributes are grouped into different issues.
 

content/en/error_tracking/explorer.md

@@ -24,6 +24,12 @@ Each item listed in the Error Tracking Explorer is an issue that contains high-l
     -   Graph of occurrences over time
     -   Number of occurrences in the selected time period
 
+Issue are also tagged as:
+- `New` if the issue was first seen less than two days ago and is in state **FOR REVIEW** (see [Issue States][5])
+- `Regression` if the issue was **RESOLVED** and occurred again in a newer version (see [Regression Detection][6])
+- `Crash` if the application crashed
+- Having a [Suspected Cause][3]
+
 ### Time range
 
 {{< img src="real_user_monitoring/error_tracking/time_range.png" alt="Error Tracking Time Range" style="width:80%;" >}}
@@ -48,6 +54,36 @@ Click the Edit icon to see the list of available facets that you can show or hid
 
 {{< img src="/error_tracking/error-tracking-facets.png" alt="Click the pencil icon to hide or show available Error Tracking facets from view." style="width:100%;" >}}
 
+### Issue level filters
+
+In addition to error events, Error Tracking offers issue level filters to refine the list of displayed issues.
+
+{{< img src="error_tracking/issue-level-filters.png" alt="Issue level filters in Error Tracking" style="width:100%;" >}}
+
+#### Sources
+
+Error Tracking consolidates errors from multiple Datadog products (Rum, Logs, APM) into a unified view, allowing you to watch and troubleshoot errors across your entire stack. You can choose to display **All**, **Browser**, **Mobile**, or **Backend** issues in the explorer.
+
+For more granular filtering, you can narrow down issues by specific log sources or by SDK and scope to a programming language.
+
+#### Fix available
+
+Display only issues that have an AI generated fix available to quickly remediate problems.
+
+#### Teams filters
+
+Issue Team Ownership helps you quickly identify issues and focus on relevant errors by using Git `CODEOWNERS`. Datadog will automatically filter your issues so your team can cut through noise and prioritize what matters.
+
+Issue ownership is derived from the `CODEOWNERS` files of your repositories. To use this feature, you need to link your Datadog teams to their GitHub counterparts. All errors coming from RUM and APM are eligible for Team Ownership.
+
+#### Assigned to
+
+Track and assign issues to yourself or the most knowledgeable team members, and easily refine the issue list by assignee.
+
+#### Suspected Cause
+
+[Suspected Cause][3] enables quicker filtering and prioritization of errors, empowering teams to address potential root causes more effectively.
+
 ## Inspect an issue
 
 Click on any issue to open the issue panel and see more information about it.
@@ -64,21 +100,19 @@ The lower part of the issue panel gives you the ability to navigate error sample
 
 ## Get alerted on new errors
 
-Seeing a new issue as soon as it happens gives you the chance to proactively identify and fix it before it becomes critical. Error Tracking generates a [Datadog event][1] whenever an issue is first seen in a given service and environment and, as a result, gives you the ability to be alerted in such cases by configuring [Event Monitors][2].
+Seeing a new issue as soon as it happens gives you the chance to proactively identify and fix it before it becomes critical. Error Tracking monitors allow you to track any new issue or issues that have a high impact in your systems or on your users (see [Error Tracking Monitors][7])
 
-Each event generated is tagged with the version, the service, and the environment so that you have a fine-grained control over issues you want to be alerted for. You can directly export your search query from the explorer to create an event monitor on the related scope:
+You can directly export your search query from the explorer to create an Error Tracking Monitor on the related scope:
 
 {{< img src="/error_tracking/create-monitor.mp4" alt="Export your search query to an Error Tracking monitor" video=true >}}
 
-## Suspected Cause
-
-[Suspected Cause][3] enables quicker filtering and prioritization of errors, empowering teams to address potential root causes more effectively.
-
 ## Further Reading
 
 {{< partial name="whats-next/whats-next.html" >}}
 
 [1]: /events
-[2]: /monitors/types/event/
 [3]: /error_tracking/suspected_causes
-[4]: /real_user_monitoring/explorer/search/#event-types
+[4]: /real_user_monitoring/explorer/search/#event-types
+[5]: /error_tracking/issue_states
+[6]: /error_tracking/regression_detection
+[7]: /monitors/types/error_tracking

content/en/error_tracking/issue_states.md

@@ -11,7 +11,7 @@ further_reading:
 All issues in Error Tracking have a status to help you triage and prioritize issues or dismiss noise. There are four statuses:
 
 - **FOR REVIEW**: Ongoing and in need of attention because the issue is new or it's a regression.
-- **REVIEWED**: Triaged and needs to be fixed, either now or later. 
+- **REVIEWED**: Triaged and needs to be fixed, either now or later.
 - **IGNORED**: Requiring no additional investigation or action.
 - **RESOLVED**: Fixed and no longer occurring.
 
@@ -27,13 +27,13 @@ Error Tracking automatically marks issues as **REVIEWED** if one of the followin
 - The issue has been assigned
 - A case has been created from the issue
 
-{{< img src="error_tracking/auto-review-actions.png" alt="Error Tracking automatic review actions" style="width:75%;" >}}
+{{< img src="error_tracking/auto-review-actions-2.png" alt="Error Tracking automatic review actions" style="width:75%;" >}}
 
 ## Automatic resolution
 
 Error Tracking automatically marks issues as **RESOLVED** that appear to be inactive or resolved due to a lack of recent error occurrences:
 
-- If the issue was last reported in a version that is more than 14 days old, and a newer version has been released but does not report the same error, Error Tracking automatically resolves the issue. Configure your services with version tags (see instructions for [APM][1], [RUM][2], and [Logs][3]) to ensure that automatic resolution accounts for versions of your services. 
+- If the issue was last reported in a version that is more than 14 days old, and a newer version has been released but does not report the same error, Error Tracking automatically resolves the issue. Configure your services with version tags (see instructions for [APM][1], [RUM][2], and [Logs][3]) to ensure that automatic resolution accounts for versions of your services.
 - If `version` tags are not set up, Error Tracking automatically resolves an issue if there have been no new errors reported for that issue within the last 14 days.
 
 ## Automatic re-opening through regression detection
@@ -44,10 +44,10 @@ See [Regression Detection][4].
 
 The issue status appears anywhere the issue can be viewed, such as in the issues list or on the details panel for a given issue. To manually update the status of an issue, click the status and choose a different one in the dropdown menu.
 
-{{< img src="error_tracking/updating-issue-status.png" alt="The Activity Timeline in the Error Tracking Issue" style="width:100%;" >}}
+{{< img src="error_tracking/updating-issue-status-2.png" alt="The Activity Timeline in the Error Tracking Issue" style="width:100%;" >}}
 
 ## Issue history
-View a history of your issue activity with the **Activity Timeline**. On the details panel of any Error Tracking issue, view the Activity Timeline by clicking the **Activity** tab. 
+View a history of your issue activity with the **Activity Timeline**. On the details panel of any Error Tracking issue, view the Activity Timeline by clicking the **Activity** tab.
 
 {{< img src="error_tracking/issue-status-history.png" alt="The Activity Timeline in the Error Tracking Issue" style="width:80%;" >}}
 

content/en/error_tracking/manage_data_collection.md

@@ -19,15 +19,15 @@ You can define what data is included in Error Tracking in two ways:
 - [Rules](#rules-inclusion)
 - [Rate limits](#rate-limits)
 
-You can configure both rules and rate limits on the [**Error Tracking** > **Settings**][1] page. 
+You can configure both rules and rate limits on the [**Error Tracking** > **Settings**][1] page.
 
 ## Rules
 
-Rules allow you to select which errors are ingested into Error Tracking. They apply to both billable and non-billable errors. 
+Rules allow you to select which errors are ingested into Error Tracking. They apply to both billable and non-billable errors.
 
 Each rule consists of:
 - A scope: an inclusion filter, which contains a search query, such as `service:my-web-store`.
-- Optionally, one or more nested exclusion filters to further refine the rule. For example, an exclusion filter might use the `env:staging` query to exclude staging errors.
+- Optionally, one or more nested exclusion filters to further refine the rule and ignore some of the matching events. For example, an exclusion filter might use the `env:staging` query to exclude staging errors.
 
 A given rule can be toggled on or off. An error event is included if it matches a query in one of the active inclusion filters _and_ it does not match any active nested exclusion queries.
 
@@ -39,6 +39,33 @@ Each error event is checked against the rules in order. The event is processed o
 
 Rules are evaluated in order, with the evaluation stopping at the first matching rule. The priority of the rules and their nested filters depends on their order in the list.
 
+{{% collapse-content title="Example" level="p" %}}
+Given a list of rules:
+- Rule 1: `env:prod`
+    - Exclusion filter 1-1: `service:api`
+    - Exclusion filter 1-2: `status:warn`
+- Rule 2: `service:web`
+- Rule 3 (this rule is disabled): `team:security`
+- Rule 4: `service:foo`
+
+
+{{< img src="error_tracking/error-tracking-filters-example.png" alt="Error Tracking Filters example of setup" style="width:75%;" >}}
+
+The processing flow is as follows:
+{{< img src="error_tracking/error-tracking-filters-diagram-brand-design.png" alt="Error Tracking Filters" style="width:90%;" >}}
+
+
+An event with `env:prod service:my-service status:warn` 
+- will match rule 1 and go to its exclusion filters 
+- will not match exclusion 1-1 so will go to exclusion 1-2
+- at exclusion 1-2, it will be a match, so the event will be discarded
+
+An event with `env:staging service:web` 
+- will not match rule 1, so will go to rule 2 
+- at rule 2, it will be a match, so the event will be kept
+
+{{% /collapse-content %}}
+
 ### Default rules
 
 By default, Error Tracking has an `*` inclusion filter and no exclusion filters. This means all error with the [requirements][2] to be fingerprinted are ingested into Error Tracking.
@@ -54,7 +81,7 @@ To add a rule (inclusion filter):
 6. Click **Save Changes**
 7. Optionally, reorder the rules to change their [evaluation order](#evaluation-order). Click and drag the six-dot icon on a given rule to move the rule up or down in the list.
 
-{{< img src="logs/error_tracking/reorder_filters.png" alt="On the right side of each rule is a six-dot icon, which you can drag vertically to reorder rules." style="width:80%;">}}
+{{< img src="error_tracking/reorder-filters.png" alt="On the right side of each rule is a six-dot icon, which you can drag vertically to reorder rules." style="width:80%;">}}
 
 
 ## Rate limits
@@ -71,22 +98,55 @@ To set a rate limit:
 1. Edit the **errors/month** field.
 1. Click **Save Rate Limit**.
 
-{{< img src="logs/error_tracking/rate_limit.png" alt="On the left side of this page, under 'Set your Rate Limit below,' is a drop-down menu where you can set your rate limit." style="width:70%;">}}
+{{< img src="error_tracking/rate-limit.png" alt="On the left side of this page, under 'Set your Rate Limit below,' is a drop-down menu where you can set your rate limit." style="width:70%;">}}
 
 A `Rate limit applied` event is generated when you reach the rate limit. See the [Event Management documentation][4] for details on viewing and using events.
 
 {{< img src="logs/error_tracking/rate_limit_reached_event.png" alt="Screenshot of a 'Rate limit applied' event in the Event Explorer. The event's status is INFO, the source is Error Tracking, the timestamp reads '6h ago', and the title is 'Rate limit applied.' The event is tagged 'source:error_tracking'. The message reads 'Your rate limit has been applied as more than 60000000 logs error events were sent to Error Tracking. Rate limit can be changed from the ingestion control page. " style="width:70%;">}}
 
 ## Monitoring usage
 
-You can monitor your Error Tracking on Logs usage by setting up monitors and alerts for the `datadog.estimated_usage.error_tracking.logs.events` metric, which tracks the number of ingested error logs. 
+You can monitor your Error Tracking on Logs usage by setting up monitors and alerts for the `datadog.estimated_usage.error_tracking.logs.events` metric, which tracks the number of ingested error logs.
 
 This metric is available by default at no additional cost, and its data is retained for 15 months.
 
+## Dynamic Sampling
+
+Because Error Tracking billing is based on the number of errors, large increases in the errors for a single issue can quickly consume your Error Tracking budget. Dynamic Sampling protects you by establishing a threshold for the error rate per issue based on your daily rate limit and historical error volumes, sampling errors when that threshold is reached. Dynamic Sampling automatically deactivates when the error rate of your issue decreases below the given threshold.
+
+### Setup
+
+Dynamic Sampling is automatically enabled with Error Tracking with a default intake threshold based on your daily rate limit and historical volume.
+
+For best results, set up a daily rate limit on the [Error Tracking Rate Limits page][5]: Click **Edit Rate Limit** and enter a new value.
+
+{{< img src="error_tracking/dynamic-sampling-rate-limit.png" alt="Error Tracking Rate Limit" style="width:90%" >}}
+
+### Disable Dynamic Sampling
+
+Dynamic Sampling can be disabled on the [Error Tracking Settings page][4].
+
+{{< img src="error_tracking/dynamic-sampling-settings.png" alt="Error Tracking Dynamic Sampling Settings" style="width:90%" >}}
+
+### Monitor Dynamic Sampling
+
+A `Dynamic Sampling activated` event is generated when Dynamic Sampling is applied to an issue. See the [Event Management documentation][4] for details on viewing and using events.
+
+{{< img src="error_tracking/dynamic-sampling-event.png" alt="Error Tracking Rate Limit" style="width:90%" >}}
+
+#### Investigation and mitigation steps
+
+When Dynamic Sampling is applied, the following steps are recommended:
+
+- Check which issue is consuming your quota. The issue to which Dynamic Sampling is applied is linked in the event generated in Event Management.
+- If you'd like to collect additional samples for this issue, raise your daily quota on the [Error Tracking Rate Limits page][5].
+- If you'd like to avoid collecting samples for this issue in the future, consider creating an exclusion filter to prevent additional events from being ingested into Error Tracking.
+
 ## Further Reading
 
 {{< partial name="whats-next/whats-next.html" >}}
 
 [1]: https://app.datadoghq.com/error-tracking/settings/rules
 [2]: /error_tracking/troubleshooting/?tab=java#errors-are-not-found-in-error-tracking
 [4]: /service_management/events/
+[5]: https://app.datadoghq.com/error-tracking/settings/rate-limits

content/en/error_tracking/troubleshooting.md

@@ -22,7 +22,9 @@ To be processed by Error Tracking, a span must have these attributes:
 - `error.message`
 - `error.stack`
 
-**Note**: The stack must have at least two lines and one *meaningful* frame (a frame with a function name and a filename in most languages).
+<div class="alert alert-info">
+<strong>Note:</strong> The stack must have at least two lines and one <em>meaningful</em> frame (a frame with a function name and a filename in most languages).
+</div>
 
 This [example query][5] searches for spans meeting the criteria for inclusion in Error Tracking.
 
@@ -32,6 +34,10 @@ Error Tracking only processes errors that are sent with the source set to `custo
 
 This [example query][6] shows RUM errors that meet the criteria for inclusion in Error Tracking.
 
+### Inclusion/Exclusion filters
+
+Make sure the errors you are looking for match at least one inclusion filter and no exclusion filters. Check your filters setup (more information in [Manage Data Collection][8]).
+
 ## No error samples found for an issue
 
 All errors are processed, but only retained errors are available in the issue panel as an error sample.
@@ -46,3 +52,4 @@ Spans associated with the error need to be retained with a custom retention filt
 [5]: https://app.datadoghq.com/apm/traces?query=%40_top_level%3A1%20%40error.stack%3A%2A%20AND%20%40error.message%3A%2A%20AND%20error.type%3A%2A%20
 [6]: https://app.datadoghq.com/rum/sessions?query=%40type%3Aerror%20%40error.stack%3A%2A
 [7]: https://app.datadoghq.com/error-tracking/settings
+[8]: /error_tracking/manage_data_collection/