You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Merge branch 'master' into feat/sidebar-section-separators
Resolved conflicts by combining sidebar separator feature with beta/new badge features:
- Added section_end_divider field alongside beta/new fields in Node type
- Kept beta/new badge rendering in sidebar links
- Merged CSS styles for both badge types and separator
- Both features are now compatible and working together
Copy file name to clipboardExpand all lines: develop-docs/sdk/telemetry/logs.mdx
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -398,6 +398,8 @@ A new data category for logs has been added to Relay, `log_item`. Both the `log`
398
398
399
399
Logs should be buffered before being sent. SDKs should keep a buffer of logs on the client (so you can have logs from multiple traces in the buffer) that flushes out based on some kind of condition. We recommend to follow the [telemetry buffer specification outlined](/sdk/telemetry/telemetry-buffer/) in the develop docs, but you should choose the approach that works best for your platform. When starting initial development on the SDK you can choose a simple approach to buffer like flushing logs if the buffer length exceeds 100 items, or if 5 seconds have passed.
400
400
401
+
SDKs must have a hard limit of 1000 log events queued up to avoid causing our customers applications going out of memory. Logs added once the hard limit has been reached are dropped.
402
+
401
403
SDKS should NOT release logging capabilities to users if a buffering implementation has not been added to their SDK when adding logging APIs.
Copy file name to clipboardExpand all lines: develop-docs/sdk/telemetry/spans/scrubbing-data.mdx
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ title: Scrubbing data
10
10
This document uses key words such as "MUST", "SHOULD", and "MAY" as defined in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) to indicate requirement levels.
11
11
</Alert>
12
12
13
-
## Scrubbing data with `beforeSendSpans`
13
+
## Scrubbing data with `beforeSendSpan`
14
14
15
15
This callback MUST NOT allow the removal of any spans from the span tree.
16
16
It receives a deep copy of all spans in the span tree and their attributes.
@@ -28,4 +28,4 @@ It receives a deep copy of all spans in the span tree and their attributes.
28
28
```
29
29
30
30
Users MAY mutate any exposed properties to perform sanitation on sensitive data or PII.
31
-
The return value of `beforeSendSpans` MUST be merged with the original span tree prior to emission.
31
+
The return value of `beforeSendSpan` MUST be merged with the original span tree prior to emission.
Copy file name to clipboardExpand all lines: develop-docs/sdk/telemetry/telemetry-buffer/index.mdx
+12-12Lines changed: 12 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -45,18 +45,18 @@ The BatchProcessor batches spans and logs into one envelope to reduce the number
45
45
46
46
Whenever the SDK finishes a span or captures a log, it MUST put it into the BatchProcessor. The SDK MUST NOT put unfinished spans into the BatchProcessor.
47
47
48
-
The BatchProcessor MUST start a timeout of 5 seconds when the SDK adds the first span or log. When the timeout exceeds, the BatchProcessor MUST send all spans or logs, no matter how many items it contains. The SDK MAY choose a different value for the timeout, but it MUST NOT exceed 30 seconds, as this can lead to problems with the span buffer on the backend, which uses a time interval of 60 seconds for determining segments for spans. The BatchProcessor SHOULD only start a new timeout, when it has spans or logs to send, to avoid running the timeout unnecessarily.
48
+
The BatchProcessor MUST start a timeout of 5 seconds when the SDK adds the first span or log. When the timeout exceeds, the BatchProcessor MUST forward all spans or logs to the transport, no matter how many items it contains. The SDK MAY choose a different value for the timeout, but it MUST NOT exceed 30 seconds, as this can lead to problems with the span buffer on the backend, which uses a time interval of 60 seconds for determining segments for spans. The BatchProcessor SHOULD only start a new timeout, when it has spans or logs to send, to avoid running the timeout unnecessarily.
49
49
50
-
The BatchProcessor MUST send all items after the SDK when containing spans or logs exceeding 1MiB in size. The SDK MAY choose a different value for the max batch size keeping the [envelope max sizes](/sdk/data-model/envelopes/#size-limits) in mind. The SDK MUST calculate the size of a span or a log to manage the BatchProcessor's memory footprint. The SDK MUST serialize the span or log and calculate the size based on the serialized JSON bytes. As serialization is expensive, the BatchProcessor SHOULD keep track of the serialized spans and logs and pass these to the envelope to avoid serializing multiple times.
50
+
The BatchProcessor MUST forward all items to the transport after the SDK when containing spans or logs exceeding 1MiB in size. The SDK MAY choose a different value for the max batch size keeping the [envelope max sizes](/sdk/data-model/envelopes/#size-limits) in mind. The SDK MUST calculate the size of a span or a log to manage the BatchProcessor's memory footprint. The SDK MUST serialize the span or log and calculate the size based on the serialized JSON bytes. As serialization is expensive, the BatchProcessor SHOULD keep track of the serialized spans and logs and pass these to the envelope to avoid serializing multiple times.
51
51
52
-
When the BatchProcessor sends all spans or logs, it MUST reset its timeout and remove all spans and logs. The SDK MUST apply filtering and sampling before adding spans or logs to the BatchProcessor. The SDK MUST apply rate limits to spans and logs after they leave the BatchProcessor to send as much data as possible by dropping data as late as possible.
52
+
When the BatchProcessor forwards all spans or logs to the transport, it MUST reset its timeout and remove all spans and logs. The SDK MUST apply filtering and sampling before adding spans or logs to the BatchProcessor. The SDK MUST apply rate limits to spans and logs after they leave the BatchProcessor to send as much data as possible by dropping data as late as possible.
53
53
54
-
The BatchProcessor MUST send all spans and logs in memory to avoid data loss in the following scenarios:
54
+
The BatchProcessor MUST forward all spans and logs in memory to the transport to avoid data loss in the following scenarios:
55
55
56
-
1. When the user calls `SentrySDK.flush()`, the BatchProcessor MUST send all data in memory.
57
-
2. When the user calls `SentrySDK.close()`, the BatchProcessor MUST send all data in memory.
58
-
3. When the application shuts down gracefully, the BatchProcessor SHOULD send all data in memory. This is mostly relevant for mobile SDKs already subscribed to these hooks, such as [applicationWillTerminate](https://developer.apple.com/documentation/uikit/uiapplicationdelegate/applicationwillterminate(_:)) on iOS.
59
-
4. When the application moves to the background, the BatchProcessor SHOULD send all data in memory and stop the timer. This is mostly relevant for mobile SDKs.
56
+
1. When the user calls `SentrySDK.flush()`, the BatchProcessor MUST forward all data in memory to the transport, and only then the transport SHOULD flush the data.
57
+
2. When the user calls `SentrySDK.close()`, the BatchProcessor MUST forward all data in memory to the transport. SDKs SHOULD keep their existing closing behavior.
58
+
3. When the application shuts down gracefully, the BatchProcessor SHOULD forward all data in memory to the transport. The transport SHOULD keep its existing behavior, which usually stores the data to disk as an envelope. It is not required to call transport `flush`. This is mostly relevant for mobile SDKs already subscribed to these hooks, such as [applicationWillTerminate](https://developer.apple.com/documentation/uikit/uiapplicationdelegate/applicationwillterminate(_:)) on iOS.
59
+
4. When the application moves to the background, the BatchProcessor SHOULD forward all data in memory to the transport and stop the timer. The transport SHOULD keep its existing behavior, which usually stores the data to disk as an envelope. It is not required to call transport `flush`. This is mostly relevant for mobile SDKs.
60
60
5. We're working on concept for crashes, and will update the specification when we have more details.
61
61
62
62
The detailed specification is written in the [Gherkin syntax](https://cucumber.io/docs/gherkin/reference/). The specification uses spans as an example, but the same applies to logs or any other future telemetry data.
@@ -68,15 +68,15 @@ Scenario: No spans in BatchProcessor 1 span added
68
68
When the SDK finishes 1 span
69
69
Then the SDK puts this span to the BatchProcessor
70
70
And starts a timeout of 5 seconds
71
-
And doesn't send the span to Sentry
71
+
And doesn't forward the span to the transport
72
72
73
73
Scenario: Span added before timeout exceeds
74
74
Given span A in the BatchProcessor
75
75
Given 4.9 seconds pass
76
76
When the SDK finishes span B
77
77
Then the SDK adds span B to the BatchProcessor
78
78
And doesn't reset the timeout
79
-
And doesn't send the spans A and B in the BatchProcessor to Sentry
79
+
And doesn't forward the spans A and B in the BatchProcessor to the transport
80
80
81
81
Scenario: Timeout exceeds and no spans or logs to send
82
82
Given no spans in the BatchProcessor
@@ -88,15 +88,15 @@ Scenario: Spans with size of 1 MiB - 1 byte added, timeout exceeds
88
88
Given spans with size of 1 MiB - 1 byte in the BatchProcessor
89
89
When the timeout exceeds
90
90
Then the SDK adds all the spans to one envelope
91
-
And sends them to Sentry
91
+
And forwards them to the transport
92
92
And resets the timeout
93
93
And clears the BatchProcessor
94
94
95
95
Scenario: Spans with size of 1 MiB - 1 byte added within 4.9 seconds
96
96
Given spans with size of 1 MiB - 1 byte in the BatchProcessor
97
97
When the SDK finishes another span and puts it into the BatchProcessor
98
98
Then the BatchProcessor puts all spans into one envelope
Copy file name to clipboardExpand all lines: develop-docs/self-hosted/optional-features/csp.mdx
+1-5Lines changed: 1 addition & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,13 +1,9 @@
1
1
---
2
2
title: Self-Hosted Content Security Policy (CSP)
3
3
sidebar_title: Content Security Policy (CSP)
4
-
sidebar_order: 70
4
+
sidebar_order: 2
5
5
---
6
6
7
-
<Alertlevel="warning">
8
-
This is an experimental feature. This means that features and workflows are not completely tested, so use at your own risk!
9
-
</Alert>
10
-
11
7
Starting with Sentry `23.5.0`, it is possible to enable the [CSP header](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) on self-hosted Sentry installations. The good news is that Sentry itself supports [collecting of CSP reports](https://docs.sentry.io/product/security-policy-reporting/). We recommend creating a separate Sentry project for CSP reports. To enable CSP and reports collection, you'll want to configure the following settings in `sentry.conf.py`:
This version of Sentry is enabled by default upon installation. Ensure that your [.env file](https://github.com/getsentry/self-hosted/blob/master/.env) includes `COMPOSE_PROFILES=feature-complete`.
33
+
This version of Sentry is enabled by default upon installation. Ensure that your [.env file](https://github.com/getsentry/self-hosted/blob/master/.env) includes `COMPOSE_PROFILES=feature-complete`.
Copy file name to clipboardExpand all lines: develop-docs/self-hosted/production-enhancements/external-storage.mdx
+2-6Lines changed: 2 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,13 +1,9 @@
1
1
---
2
-
title: SelfHosted External Storage
2
+
title: Self-Hosted External Storage
3
3
sidebar_title: External Storage
4
-
sidebar_order: 90
4
+
sidebar_order: 3
5
5
---
6
6
7
-
<Alerttitle="Important"level="warning">
8
-
These are community-contributed docs. Sentry does not officially provide support for self-hosted configurations beyond the default install.
9
-
</Alert>
10
-
11
7
In some cases, storing Sentry data on-disk is not really something people can do. Sometimes, it's better to offload it into some bucket storage (like AWS S3 or Google Cloud Storage).
0 commit comments