Sourced from sentry's releases.
0.43.0
Breaking changes
- ref(tracing): rework tracing to Sentry span name/op conversion (#887) by
@lcian
- The
tracingintegration now uses the tracing span name as the Sentry span name by default.- Before this change, the span name would be set based on the
tracingspan target (<module>::<function>when using thetracing::instrumentmacro).- The
tracingintegration now uses<span target>::<span name>as the default Sentry span op (i.e.<module>::<function>when usingtracing::instrument).- Before this change, the span op would be set based on the
tracingspan name.- Read below to learn how to customize the span name and op.
- When upgrading, please ensure to adapt any queries, metrics or dashboards to use the new span names/ops.
- ref(tracing): use standard code attributes (#899) by
@lcian
- Logs now carry the attributes
code.module.name,code.file.pathandcode.line.numberstandardized in OTEL to surface the respective information, in contrast with the previously senttracing.module_path,tracing.fileandtracing.line.- fix(actix): capture only server errors (#877) by
@lcian
- The Actix integration now properly honors the
capture_server_errorsoption (enabled by default), capturing errors returned by middleware only if they are server errors (HTTP status code 5xx).- Previously, if a middleware were to process the request after the Sentry middleware and return an error, our middleware would always capture it and send it to Sentry, regardless if it was a client, server or some other kind of error.
- With this change, we capture errors returned by middleware only if those errors can be classified as server errors.
- There is no change in behavior when it comes to errors returned by services, in which case the Sentry middleware only captures server errors exclusively.
- fix: send trace origin correctly (#906) by
@lcian
TraceContextnow has an additional fieldorigin, used to report which integration created a transaction.Behavioral changes
- feat(tracing): send both breadcrumbs and logs by default (#878) by
@lcian
- If the
logsfeature flag is enabled, andenable_logs: trueis set on your client options, the default Sentrytracinglayer now sends logs for all events at or above INFO.Features
ref(tracing): rework tracing to Sentry span name/op conversion (#887) by
@lcian
- Additional special fields have been added that allow overriding certain data on the Sentry span:
sentry.op: override the Sentry span op.sentry.name: override the Sentry span name.sentry.trace: given a string matching a validsentry-traceheader (sent automatically by client SDKs), continues the distributed trace instead of starting a new one. If the value is not a validsentry-traceheader or a trace is already started, this value is ignored.sentry.opandsentry.namecan also be applied retroactively by declaring fields with valuetracing::field::Emptyand then recorded usingtracing::Span::record.- Example usage:
#[tracing::instrument(skip_all, fields( sentry.op = "http.server", sentry.name = "GET /payments", sentry.trace = headers.get("sentry-trace").unwrap_or(&"".to_owned()), ))] async fn handle_request(headers: std::collections::HashMap<String, String>) { // ... }- Additional attributes are sent along with each span by default:
sentry.tracing.target: corresponds to thetracingspan'smetadata.target()code.module.name,code.file.path,code.line.numberfeat(core): add Response context (#874) by
@lcian
- The
Responsecontext can now be attached to events, to include information about HTTP responses such as headers, cookies and status code.
... (truncated)
Sourced from sentry's changelog.
0.43.0
Breaking changes
- ref(tracing): rework tracing to Sentry span name/op conversion (#887) by
@lcian
- The
tracingintegration now uses the tracing span name as the Sentry span name by default.- Before this change, the span name would be set based on the
tracingspan target (<module>::<function>when using thetracing::instrumentmacro).- The
tracingintegration now uses<span target>::<span name>as the default Sentry span op (i.e.<module>::<function>when usingtracing::instrument).- Before this change, the span op would be set based on the
tracingspan name.- Read below to learn how to customize the span name and op.
- When upgrading, please ensure to adapt any queries, metrics or dashboards to use the new span names/ops.
- ref(tracing): use standard code attributes (#899) by
@lcian
- Logs now carry the attributes
code.module.name,code.file.pathandcode.line.numberstandardized in OTEL to surface the respective information, in contrast with the previously senttracing.module_path,tracing.fileandtracing.line.- fix(actix): capture only server errors (#877) by
@lcian
- The Actix integration now properly honors the
capture_server_errorsoption (enabled by default), capturing errors returned by middleware only if they are server errors (HTTP status code 5xx).- Previously, if a middleware were to process the request after the Sentry middleware and return an error, our middleware would always capture it and send it to Sentry, regardless if it was a client, server or some other kind of error.
- With this change, we capture errors returned by middleware only if those errors can be classified as server errors.
- There is no change in behavior when it comes to errors returned by services, in which case the Sentry middleware only captures server errors exclusively.
- fix: send trace origin correctly (#906) by
@lcian
TraceContextnow has an additional fieldorigin, used to report which integration created a transaction.Behavioral changes
- feat(tracing): send both breadcrumbs and logs by default (#878) by
@lcian
- If the
logsfeature flag is enabled, andenable_logs: trueis set on your client options, the default Sentrytracinglayer now sends logs for all events at or above INFO.Features
ref(tracing): rework tracing to Sentry span name/op conversion (#887) by
@lcian
- Additional special fields have been added that allow overriding certain data on the Sentry span:
sentry.op: override the Sentry span op.sentry.name: override the Sentry span name.sentry.trace: given a string matching a validsentry-traceheader (sent automatically by client SDKs), continues the distributed trace instead of starting a new one. If the value is not a validsentry-traceheader or a trace is already started, this value is ignored.sentry.opandsentry.namecan also be applied retroactively by declaring fields with valuetracing::field::Emptyand then recorded usingtracing::Span::record.- Example usage:
#[tracing::instrument(skip_all, fields( sentry.op = "http.server", sentry.name = "GET /payments", sentry.trace = headers.get("sentry-trace").unwrap_or(&"".to_owned()), ))] async fn handle_request(headers: std::collections::HashMap<String, String>) { // ... }- Additional attributes are sent along with each span by default:
sentry.tracing.target: corresponds to thetracingspan'smetadata.target()code.module.name,code.file.path,code.line.number
... (truncated)
b08b24a
release: 0.43.01c08ca8
ref(tracing): keep old span name as op instead of default (#905)75aff83
fix(tracing): skip default span attributes when propagating to event (#904)6b61b31
fix: send trace origin correctly (#906)75a8c03
ref(tracing): use standard code attributes (#899)bbd667a
meta: add pull request template (#898)5c8ab31
ref(tracing): rework tracing to Sentry span name/op
conversion (#887)045c2e2
feat(tracing): send both breadcrumbs and logs by default (#878)a5932c0
fix(transport): add rate limit for logs (#894)280dab9
build(deps): bump tracing-subscriber from 0.3.19 to 0.3.20 (#891)Sourced from sentry-tracing's releases.
0.43.0
Breaking changes
- ref(tracing): rework tracing to Sentry span name/op conversion (#887) by
@lcian
- The
tracingintegration now uses the tracing span name as the Sentry span name by default.- Before this change, the span name would be set based on the
tracingspan target (<module>::<function>when using thetracing::instrumentmacro).- The
tracingintegration now uses<span target>::<span name>as the default Sentry span op (i.e.<module>::<function>when usingtracing::instrument).- Before this change, the span op would be set based on the
tracingspan name.- Read below to learn how to customize the span name and op.
- When upgrading, please ensure to adapt any queries, metrics or dashboards to use the new span names/ops.
- ref(tracing): use standard code attributes (#899) by
@lcian
- Logs now carry the attributes
code.module.name,code.file.pathandcode.line.numberstandardized in OTEL to surface the respective information, in contrast with the previously senttracing.module_path,tracing.fileandtracing.line.- fix(actix): capture only server errors (#877) by
@lcian
- The Actix integration now properly honors the
capture_server_errorsoption (enabled by default), capturing errors returned by middleware only if they are server errors (HTTP status code 5xx).- Previously, if a middleware were to process the request after the Sentry middleware and return an error, our middleware would always capture it and send it to Sentry, regardless if it was a client, server or some other kind of error.
- With this change, we capture errors returned by middleware only if those errors can be classified as server errors.
- There is no change in behavior when it comes to errors returned by services, in which case the Sentry middleware only captures server errors exclusively.
- fix: send trace origin correctly (#906) by
@lcian
TraceContextnow has an additional fieldorigin, used to report which integration created a transaction.Behavioral changes
- feat(tracing): send both breadcrumbs and logs by default (#878) by
@lcian
- If the
logsfeature flag is enabled, andenable_logs: trueis set on your client options, the default Sentrytracinglayer now sends logs for all events at or above INFO.Features
ref(tracing): rework tracing to Sentry span name/op conversion (#887) by
@lcian
- Additional special fields have been added that allow overriding certain data on the Sentry span:
sentry.op: override the Sentry span op.sentry.name: override the Sentry span name.sentry.trace: given a string matching a validsentry-traceheader (sent automatically by client SDKs), continues the distributed trace instead of starting a new one. If the value is not a validsentry-traceheader or a trace is already started, this value is ignored.sentry.opandsentry.namecan also be applied retroactively by declaring fields with valuetracing::field::Emptyand then recorded usingtracing::Span::record.- Example usage:
#[tracing::instrument(skip_all, fields( sentry.op = "http.server", sentry.name = "GET /payments", sentry.trace = headers.get("sentry-trace").unwrap_or(&"".to_owned()), ))] async fn handle_request(headers: std::collections::HashMap<String, String>) { // ... }- Additional attributes are sent along with each span by default:
sentry.tracing.target: corresponds to thetracingspan'smetadata.target()code.module.name,code.file.path,code.line.numberfeat(core): add Response context (#874) by
@lcian
- The
Responsecontext can now be attached to events, to include information about HTTP responses such as headers, cookies and status code.
... (truncated)
Sourced from sentry-tracing's changelog.
0.43.0
Breaking changes
- ref(tracing): rework tracing to Sentry span name/op conversion (#887) by
@lcian
- The
tracingintegration now uses the tracing span name as the Sentry span name by default.- Before this change, the span name would be set based on the
tracingspan target (<module>::<function>when using thetracing::instrumentmacro).- The
tracingintegration now uses<span target>::<span name>as the default Sentry span op (i.e.<module>::<function>when usingtracing::instrument).- Before this change, the span op would be set based on the
tracingspan name.- Read below to learn how to customize the span name and op.
- When upgrading, please ensure to adapt any queries, metrics or dashboards to use the new span names/ops.
- ref(tracing): use standard code attributes (#899) by
@lcian
- Logs now carry the attributes
code.module.name,code.file.pathandcode.line.numberstandardized in OTEL to surface the respective information, in contrast with the previously senttracing.module_path,tracing.fileandtracing.line.- fix(actix): capture only server errors (#877) by
@lcian
- The Actix integration now properly honors the
capture_server_errorsoption (enabled by default), capturing errors returned by middleware only if they are server errors (HTTP status code 5xx).- Previously, if a middleware were to process the request after the Sentry middleware and return an error, our middleware would always capture it and send it to Sentry, regardless if it was a client, server or some other kind of error.
- With this change, we capture errors returned by middleware only if those errors can be classified as server errors.
- There is no change in behavior when it comes to errors returned by services, in which case the Sentry middleware only captures server errors exclusively.
- fix: send trace origin correctly (#906) by
@lcian
TraceContextnow has an additional fieldorigin, used to report which integration created a transaction.Behavioral changes
- feat(tracing): send both breadcrumbs and logs by default (#878) by
@lcian
- If the
logsfeature flag is enabled, andenable_logs: trueis set on your client options, the default Sentrytracinglayer now sends logs for all events at or above INFO.Features
ref(tracing): rework tracing to Sentry span name/op conversion (#887) by
@lcian
- Additional special fields have been added that allow overriding certain data on the Sentry span:
sentry.op: override the Sentry span op.sentry.name: override the Sentry span name.sentry.trace: given a string matching a validsentry-traceheader (sent automatically by client SDKs), continues the distributed trace instead of starting a new one. If the value is not a validsentry-traceheader or a trace is already started, this value is ignored.sentry.opandsentry.namecan also be applied retroactively by declaring fields with valuetracing::field::Emptyand then recorded usingtracing::Span::record.- Example usage:
#[tracing::instrument(skip_all, fields( sentry.op = "http.server", sentry.name = "GET /payments", sentry.trace = headers.get("sentry-trace").unwrap_or(&"".to_owned()), ))] async fn handle_request(headers: std::collections::HashMap<String, String>) { // ... }- Additional attributes are sent along with each span by default:
sentry.tracing.target: corresponds to thetracingspan'smetadata.target()code.module.name,code.file.path,code.line.number
... (truncated)
b08b24a
release: 0.43.01c08ca8
ref(tracing): keep old span name as op instead of default (#905)75aff83
fix(tracing): skip default span attributes when propagating to event (#904)6b61b31
fix: send trace origin correctly (#906)75a8c03
ref(tracing): use standard code attributes (#899)bbd667a
meta: add pull request template (#898)5c8ab31
ref(tracing): rework tracing to Sentry span name/op
conversion (#887)045c2e2
feat(tracing): send both breadcrumbs and logs by default (#878)a5932c0
fix(transport): add rate limit for logs (#894)280dab9
build(deps): bump tracing-subscriber from 0.3.19 to 0.3.20 (#891)