Updated extrapolation docs for clarity and adding an image

develop-docs/application-architecture/dynamic-sampling/extrapolation.mdx

@@ -3,34 +3,27 @@ title: Extrapolation
 sidebar_order: 5
 ---
 
-Dynamic sampling reduces the amount of data ingested, for reasons of both performance and cost. When configured, a fraction of the data is ingested according to the specified sample rate of a project: if you sample at 10% and initially have 1000 requests to your site in a given timeframe, you will only see 100 spans in Sentry. Without making up for the sample rate, any metrics derived from these spans will misrepresent the true volume of the application. When different parts of the application have different sample rates, there will even be a bias towards some of them, skewing the total volume towards parts with higher sample rates. This bias especially impacts numerical attributes like latency, reducing their accuracy. To account for this fact, Sentry uses extrapolation to smartly combine the data to account for sample rates.
+Client and server-side sampling reduces the amount of data ingested, to help with both performance and cost. When configured, a fraction of the data is ingested according to the specified sample rates within a project. For example, if you sample 10% of 1000 requests to your site in a given timeframe, you will see 100 spans in Sentry. 
 
-### Accuracy & Expressiveness
-What happens during extrapolation, how does one handle this type of data, and when is extrapolated data accurate and expressive? Let's start with some definitions:
+Without accounting for the lower request volume due to the sample rate, any metrics derived from these spans will misrepresent the true volume of the application. Perhaps more importantly, when different parts of your application have different sample rates, attention may be skewed with a bias towards parts with higher sample rates. This bias especially impacts numerical attributes like latency, reducing their accuracy. To account for this, Sentry uses extrapolation to a) derive a "true" volume of each part of your application and b) combine the extrapolated data from different parts of the application to provide a more wholistic view of the application's performance.
 
-- **Accuracy** refers to data being correct. For example, the measured number of spans corresponds to the actual number of spans that were executed. As sample rates decrease, accuracy also goes down because minor random decisions can influence the result in major ways.
-- **Expressiveness** refers to data being able to express something about the state of the observed system. Expressiveness refers to the usefulness of the data for the user in a specific use case.
-
-### Modes
-Given these properties, there are two modes that can be used to view data in Sentry: default mode and sample mode.
-
-- **Default mode** extrapolates the ingested data as outlined below.
-- **Sample mode** does not extrapolate and presents exactly the data that was ingested.
+### Benefits of Extrapolation
+For high-volume organizations, sampling is a way to control costs and reduce volume, as well as reduce the amount of redundant data sent to Sentry. Extrapolation is a way to account for the lower request volume due to the sample rate, and to provide a more wholistic view of the application's performance. Here are some of the benefits of extrapolation:
 
-Depending on the context and the use case, one mode may be more useful than the other. Generally, default mode is useful for all queries that aggregate on a dataset of sufficient volume. As absolute sample size decreases below a certain limit, default mode becomes less and less expressive. There are scenarios where the user needs to temporarily switch between modes, for example, to examine the aggregate numbers first and dive into the number of samples for investigation. In both modes, the user may investigate single samples to dig deeper into the details.
+- **The numbers correspond to the real world**: When data is sampled, there is some math you need to do to infer what the real numbers are, e.g., when you have 1000 samples at 10% sample rate, there are 10000 requests to your application. With extrapolation, you don't have to know your sample rate to understand what your application is actually doing. Instead, while viewing charts, you see the real behavior without additional knowledge or math required on your end.
 
-### Benefits of Extrapolation
-At first glance, extrapolation may seem unnecessarily complicated. However, for high-volume organizations, sampling is a way to control costs and egress volume, as well as reduce the amount of redundant data sent to Sentry. Why don't we just show the user the data they send? We don't just extrapolate for fun; it actually has some major benefits for the user:
+- **Steady timeseries when sample rates change**: Whenever you change sample rates, both the count and possibly the distribution of the values will change in some way. When you switch the sample rate from 10% to 1% for whatever reason, there will be a sudden change in all associated metrics. Extrapolation corrects for this, so your graphs are steady, and your alerts track on the same data, regardless of the sample rate.
 
-- **The numbers correspond to the real world**: When data is sampled, there is some math you need to do to infer what the real numbers are, e.g., when you have 1000 samples at 10% sample rate, there are 10000 requests to your application. With extrapolation, you don't have to know your sample rate to understand what your application is actually doing. Instead, you get a view of the real behavior without additional knowledge or math required on your end.
+- **Combining different sample rates**: When your endpoints don't have the same sample rate, how are you supposed to know the true p90 when one of your endpoints is sampled at 1% and another at 100%, but all you get is the aggregate of the samples? Extrapolation calculates the true p90 by combining the data from all endpoints, weighted by the sample rate.
 
-- **Steady timeseries when sample rates change**: Whenever you change sample rates, both the count and possibly the distribution of the values will change in some way. When you switch the sample rate from 10% to 1% for whatever reason, there will be a sudden change in all associated metrics. Extrapolation corrects for this, so your graphs are steady, and your alerts don't fire when this happens.
-- **Combining different sample rates**: When your endpoints don't have the same sample rate, how are you supposed to know the true p90 when one of your endpoints is sampled at 1% and another at 100%, but all you get is the aggregate of the samples?
+**Note:** When a sample rate is too low, there may be a low confidence in the extrapolated data. When this is the case, you should consider increasing the sample rate, widening your time range or filter, or turning off extrapolation.  
 
 ## How Does Extrapolation Work?
+![extrapolation =1000x](./images/extrapolated_data_chart.png)
+
 ### Aggregates
 
-Sentry allows the user to aggregate data in different ways - the following aggregates are generally available, along with whether they are extrapolatable or not:
+Sentry allows you to aggregate data in different ways - the following aggregates are generally available, along with whether they are extrapolatable or not:
 
 | **Aggregate** | **Can be extrapolated?** |
 | --- | --- |
@@ -42,12 +35,12 @@ Sentry allows the user to aggregate data in different ways - the following aggre
 | max | no |
 | count_unique | no |
 
-Each of these aggregates has its own way of dealing with extrapolation, due to the fact that e.g., counts have to be extrapolated in a slightly different way from percentiles. While `min` and `max` are technically percentiles, we currently do not offer extrapolation due to the decreased stability of extreme aggregates when sampling. For example, the `p50` will also be more stable than the `p99`; the `min` and `max` are just extreme cases.
+Each of these aggregates has its own way of dealing with extrapolation, due to the fact that, for example, counts have to be extrapolated in a slightly different way from percentiles. While `min` and `max` are technically percentiles, we currently do not offer extrapolation due to the decreased stability of extreme aggregates when sampling. For example, the `p50` will also be more stable than the `p99`; the `min` and `max` are just extreme cases.
 
 ### Extrapolation for different aggregates
 To extrapolate, sampling weights are calculated as `1/sample rate`. The sampling weights of each row are then used in the following ways:
 
-- **Count**: Calculate a sum of the sampling weight
+- **Count**: Calculate a sum of the sampling weight.
 Example: the query `count()` becomes `round(sum(sampling_weight))`.
 - **Sum**: Multiply each value with `sampling_weight`.
 Example: the query `sum(foo)` becomes `sum(foo * sampling_weight)`
@@ -56,7 +49,7 @@ Example: the query `avg(foo)` becomes `avgWeighted(foo, sampling_weight)`
 - **Percentiles**: Calculate the weighted percentiles with sampling weight.
 Example: the query `percentile(0.95)(foo)` becomes `weightedPercentile(0.95)(foo, sampling_weight)`.
 
-As long as there are sufficient samples, the sample rate itself does not matter as much, but due to the extrapolation mechanism, what would be a fluctuation of a few samples may turn into a much larger absolute impact, e.g., in terms of the view count. Of course, when a site gets billions of visits, a fluctuation of 100,000 via the noise introduced by a sample rate of 0.00001 is not as critical.
+As long as there are sufficient samples, the sample rate itself does not matter as much, but due to the extrapolation mechanism, a fluctuation of a few samples in a small sample set may turn into a much larger absolute impact. When a site gets billions of visits, a fluctuation of 100,000 via the noise introduced by a sample rate of 0.00001 is not as critical.
 
 ## How to deal with extrapolation in the product?
 
@@ -72,20 +65,16 @@ In new product surfaces, the question of whether to use extrapolated vs. non-ext
 - Does the user care more about a truthful estimate of the aggregate data or about the actual events that happened?
     - Some scenarios, like visualizing metrics over time, are based on aggregates, whereas a case of debugging a specific user's problem hinges on actually seeing the specific events. The best mode depends on the intended usage of the product.
 
-### Switching to Sample Mode
-Sample mode is designed to help users investigate specific events. Here are two common scenarios where it makes the most sense:
-
-1. **When both sample rate and event volume are low**: Extrapolation becomes less reliable in these cases. You can either increase your sample rate to improve accuracy, or switch to sample mode to examine the actual events - both are valid approaches depending on the user's needs.
-2. **When you have a high sample rate but still see low event volumes**: In this case, increasing the sample rate won't help capture more data, and sample mode will give you a clearer picture of the events you do have.
+### When to Turn Off Extrapolation
+While extrapolation is usually helpful, if you are exclusively looking to confirm your sampling usage or look exclusively at sampled data, you can turn off extrapolation.
 
-### Opting Out of Extrapolation
-Users may want to opt out of extrapolation for different reasons. It is always possible to set the sample rate for specific events to 100% and therefore send all data to Sentry, implicitly opting out of extrapolation and behaving in the same way as sample mode. Depending on their configuration, users may need to change Dynamic Sampling settings or their SDK's traces sampler callback for this.
+You can always increase your sample rate to 100% to examine all events if traffic is too low to be otherwise useful via extrapolation or sampling.
 
 ### Confidence
-When users filter on data that has a very low count but also a low sample rate, yielding a highly extrapolated but low-sample dataset, developers and users should be careful with the conclusions they draw from the data. The storage platform provides confidence intervals along with the extrapolated estimates for the different aggregation types to indicate when there is elevated uncertainty in the data. These types of datasets are inherently noisy and may contain misleading information. When this is discovered, the user should either be very careful with the conclusions they draw from the aggregate data or switch to non-default mode for investigation of the individual samples.
+When there is not enough data to properly extrapolate, Sentry will indicate low confidence in the data. If this message is not present, Sentry has a high confidence in the data.
 
 ## **Conclusion**
 
 - Extrapolation offers benefits in many parts of the product but brings some inherent complexity.
-- Some aggregates can be extrapolated, others cannot - we may add the capability to additional aggregates in the future.
-- A lot of care should be taken about how to expose extrapolation and especially switching of the modes to the user.
+- Some aggregates can be extrapolated, others cannot.
+- A lot of care should be taken about how to expose extrapolation in the product, and especially in offering switching modes to a user.

docs/concepts/key-terms/extrapolation.mdx

@@ -0,0 +1,79 @@
+---
+title: Extrapolation
+sidebar_order: 80
+description: "Learn how extrapolation provides accurate metrics from sampled data so you can trust your dashboards and alerts even when you're not capturing every event." 
+---
+
+When you use [sampling](/concepts/key-terms/sample-rates/) to control the volume of data sent to Sentry, you're only capturing a portion of your app's actual traffic. For example, if you sample 10% of 1000 requests, Sentry receives 100 spans. But how do you easily see the actual traffic and performance metrics for your app? 
+
+That's where extrapolation comes in. Sentry automatically uses extrapolation to calculate accurate metrics from your sampled data, giving you a realistic view of your application's behavior without requiring you to capture every single event, or do the math yourself.
+
+## Why Extrapolation Matters
+
+When you sample data, you need a way to understand what the full picture looks like. Extrapolation solves three key problems:
+
+- **See real-world numbers**: View metrics that reflect your actual traffic volume, not just the sampled portion. If you sample 10% of 1000 requests, Sentry shows you metrics for all 1000 requests — no mental math required.
+
+- **Consistent data when sample rates change**: If you adjust your sample rate from 10% to 1%, your graphs and alerts stay stable. Without extrapolation, you'd see a sudden drop in all your metrics that has nothing to do with actual performance changes.
+
+- **Accurate aggregates across different sample rates**: Different parts of your application might have different sample rates. Extrapolation correctly combines data from an endpoint sampled at 1% with another at 100%, giving you accurate percentiles and averages across your entire app.
+
+## How Extrapolation Works
+![extrapolation =1000x](./img/extrapolated_data_chart.png)
+
+Every span sent to Sentry includes its sampling rate. Sentry uses this to calculate a **sampling weight** — the number of original spans that each sample represents.
+
+For example:
+- At a sampling rate of 10%, the weight is 10
+- At a sampling rate of 50%, the weight is 2  
+- At a sampling rate of 100%, the weight is 1
+
+When you run queries, Sentry uses these weights to give you accurate counts, averages, and percentiles.
+
+### Example
+
+Let's say you query for database spans (`span.op:db`) and Sentry returns 2 sampled spans:
+
+| span_id | span.op | span.duration | sampling_factor | sampling_weight |
+| --- | --- | --- | --- | --- |
+| a1b2c3 | db | 100ms | 0.1 | 10 |
+| d4e5f6 | db | 200ms | 0.5 | 2 |
+
+Even though you only see 2 spans, extrapolation helps Sentry calculate metrics for all the spans they represent:
+
+**Count**: `10 + 2 = 12` estimated spans
+
+**Sum**: `(10 × 100ms) + (2 × 200ms) = 1,400ms`
+
+**Average**: `(100ms × 10 + 200ms × 2) / (10 + 2) = 117ms`
+
+Sentry weights the metrics by the sampling rates so you get accurate results that reflect your application's true performance.
+
+## What Can Be Extrapolated
+
+Most common aggregates can be extrapolated:
+
+| Aggregate | Can be extrapolated? |
+| --- | --- |
+| count | Yes |
+| avg | Yes |
+| sum | Yes |
+| percentiles (p50, p75, p90, p95, p99) | Yes |
+| min | No |
+| max | No |
+| count_unique | No |
+
+Extreme values like `min` and `max` aren't extrapolated because they're less stable when sampling — a single outlier can have an outsized impact.
+
+## When to Turn Off Extrapolation
+
+While extrapolation is usually helpful, if you are exclusively looking to confirm your sampling usage or look exclusively at sampled data, you can turn off extrapolation.
+
+You can disable extrapolation using the settings icon above charts in tools like Trace Explorer. Note that with extrapolation off, your metrics will only reflect the sampled data, not your full traffic.
+
+<Alert>
+If Sentry displays a **low confidence warning**, it means there isn't enough sampled data for reliable extrapolation. Consider increasing your sample rate or widening your query filters.
+</Alert>
+
+![Trace Explorer low samples warning =500x](./img/Trace_explorer_low_samples.png)
+

docs/product/explore/logs/index.mdx

@@ -19,25 +19,30 @@ Not everything that you want to track in your application generates an error eve
 
 ## Set up Logs
 
-To get started with Logs, navigate to the [Getting Started](/product/explore/logs/getting-started/) and select your SDK from the list.
+To get started with Logs, navigate to the [Getting Started](/product/explore/logs/getting-started/) page and select your SDK from the list.
 
 ## Viewing and Searching Logs
 
-Raw text search is case sensitive and allows you to search for specific strings within the *message* attribute of the Log. Raw text search over the entire log's JSON is not supported.
+**Raw Text Search**  
+Raw text search is case sensitive and allows you to search for specific strings within the *message* attribute of the Log. **Raw text search over the entire log's JSON is not supported.**
 
 ![Raw Text Logs Search](./img/LogSearchRawText.png)
 
+**Default Properties Search**  
 You can also search using the default properties (like `severity`) or additional custom properties that you've added to your log entries.
 
 ![Property Logs Search](./img/LogSearchTags.png)
 
+
+**Expand Logs**  
 Log entries can be expanded to view all properties of logs entry. Individual properties can be added as columns to the results view, allowing you to quickly view properties that matter specifically to you alongside your search results.
 
 ![Expanded Logs View](./img/LogsExpanded.png)
 
+**Auto-Refresh**  
 You can also enable auto refreshing of the logs view to see your latest logs as they come in.
 
-![Auto Refresh Logs](./img/AutoRefresh.png)
+![Auto Refresh Logs =700x](./img/AutoRefresh.png)
 
 Conditions in which auto-refresh is disabled:
 
@@ -48,6 +53,18 @@ Conditions in which auto-refresh is disabled:
 - Auto-refresh will be disabled if there is an error fetching logs.
 - Auto-refresh is not available in the aggregates view.
 
+### Query Volumes
+When the number of logs returned by a query is too high, there are a couple of changes to explorer functionality.
+ - Auto-refresh will be disabled.
+ - Data shown in the chart will be extrapolated from a sampled amount of the complete dataset.  
+
+ ![Extrapolated logs =600x](./img/ExtrapolatedLogs.png)
+
+ When doing very specific queries, like looking for a particular line of code that is causing an issue, you may see a message that says "No logs found yet". This happens when the dataset is very large, and Sentry needs to batch the results. You can continue scanning to see the next batch of logs by clicking "Continue Scanning".
+
+ ![Continue scanning message =1000x](./img/ContinueScanning.png)
+
+
 ## Log based Alerts and Dashboard widgets
 
 You can create Alert rules and dashboard widgets based on your log queries.