Commit 1c94dae
feat(nlog)!: the Sentry target no longer initializes the SDK (#5585)
* feat: Serilog sink no longer initializes the SDK
The Sentry sink for Serilog now only configures the sink. Sentry must be
initialized separately (SentrySdk.Init, UseSentry, etc).
- SentrySerilogOptions no longer derives from SentryOptions and only
carries sink settings; InitializeSdk is removed
- Remove the WriteTo.Sentry(string dsn, ...) overload
- Rename ApplySerilogScopeToEvents() to UseSerilog(), make it idempotent
- The sink logs a one-time diagnostic warning when UseSerilog() was not
called on the options used to initialize Sentry
Part of #5245
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Accept API verifier changes
* Tweak comments in the samples
* feat: NLog target no longer initializes the SDK
The Sentry target for NLog now only configures the target. Sentry must be
initialized separately (SentrySdk.Init, UseSentry, etc).
- SentryNLogOptions no longer derives from SentryOptions and only carries
target settings; FlushTimeout moves onto it directly
- Remove InitializeSdk, Dsn/DsnLayout, Release/ReleaseLayout,
Environment/EnvironmentLayout and ShutdownTimeoutSeconds. Events take
release and environment from the SDK options
- Collapse the AddSentry overloads into
AddSentry(optionsConfig, targetName); the dsn overloads are removed
- The target no longer routes SDK diagnostics to NLog's InternalLogger
Part of #5245
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Tweaked wording
Co-authored-by: James Crosswell <jamescrosswell@users.noreply.github.com>
* feat: NLog target flushes using the SDK's FlushTimeout
Remove SentryTarget.FlushTimeoutSeconds and SentryNLogOptions.FlushTimeout.
When NLog flushes the target, the hub is now flushed with the FlushTimeout
from the options used to initialize Sentry, since the target no longer
owns the SDK.
Part of #5245
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs: drop unused Sentry settings from the Serilog sample appsettings
The sample sets the DSN in code via UseSentry, so the commented-out Dsn
entry is misleading. EnableTracing is declared on BindableSentryOptions
but never applied, so setting it has no effect.
Part of #5245
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(serilog): make the UseSerilog warning check atomic
Emit can run concurrently, so the check-then-set on the warned flag could
let more than one thread log the warning.
Part of #5245
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* refactor: the Serilog sink no longer sets the SDK name
Sdk.Name should identify the integration that initialised the hub, which after
this change can no longer be a logging integration. The sink identifies itself
through the log origin (auto.log.serilog) instead.
See #5497.
Events are no longer stamped with sentry.dotnet.serilog, and structured logs no
longer carry it as sentry.sdk.name; both now report the SDK that initialised
Sentry.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* refactor: the NLog target no longer sets the SDK name
Sdk.Name should identify the integration that initialised the hub, which after
this change can no longer be a logging integration. The target identifies itself
through the log origin (auto.log.nlog) instead.
See #5497.
Events are no longer stamped with sentry.dotnet.nlog, and structured logs no
longer carry it as sentry.sdk.name; both now report the SDK that initialised
Sentry. With no remaining callers, Constants is deleted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* feat(serilog): configuring a DSN on the sink now fails with a migration error
Serilog configuration providers bind sink arguments by parameter name, so
removing the dsn-first overload made them drop `dsn` silently: the sink still
binds, Sentry is never initialized, and nothing is reported. Keeping the
overload as an [Obsolete(error: true)] tombstone that throws makes both
Serilog.Settings.Configuration (appsettings.json) and Serilog.Settings.AppSettings
(app.config) fail loudly with migration guidance, while code callers get a
compile error instead of a type mismatch on the second argument.
The overload mirrors the surviving overload's parameters plus `dsn`. With only
`string dsn` it loses Serilog's overload ranking whenever a configuration
supplies two or more of the surviving arguments, which would restore the silent
behaviour.
Part of #5245
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* test(serilog): pin the DSN tombstone against Serilog.Settings.Configuration
The migration guard works only because of Serilog's overload ranking, and
nothing exercised that path. These tests bind a sink from IConfiguration
the way a provider does, so a Serilog change that stops selecting the
tombstone fails here rather than silently dropping the DSN again.
Verified they fail without the tombstone overload. Selection behaves the
same on Serilog.Settings.Configuration 3.4.0 (Serilog 2.12) and 10.0.1
(Serilog 4.3); 3.4.0 is referenced to avoid bumping Serilog in the tests.
Part of #5245
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* feat(nlog): configuring a DSN on the target now fails with a migration error
Mirrors the Serilog guard (#5611). The v6 AddSentry(dsn, ...) overloads and
the SentryTarget.Dsn / InitializeSdk properties come back as tombstones:
obsolete-as-error for code callers, throwing NotSupportedException so
NLog.config bindings fail loudly with migration guidance instead of
reporting an unknown property.
Part of #5245
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs(serilog): reword the DSN migration error
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs(nlog): reword the DSN migration error to match Serilog
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(serilog): the Sentry sink registers the Serilog scope event processor automatically (#5612)
* fix: make the SentryOptions processor collections thread safe
SentryClient enumerates these collections lazily for the whole duration of a capture, and
AddEventProcessor is documented as supporting registration after the SDK is initialised.
They were plain Lists, so appending to one while a capture was in flight threw
InvalidOperationException - which the SDK catches and logs at Debug, silently dropping the
event.
Swap them for ConcurrentBagLite, which snapshots on enumeration. Scope.EventProcessors
already uses it for the same reason.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(serilog): register the Serilog scope event processor automatically
The sink no longer initialises the SDK, so integrators have to call UseSerilog() on the
options used to initialise Sentry. Forgetting it was only reported as a warning gated behind
Debug and DiagnosticLevel, so in practice it was silent.
The sink now registers SerilogScopeEventProcessor itself: at construction when Sentry is
already initialised, otherwise on the first log event. The sink and the processor live in the
same assembly, so no reflection is needed and this stays AOT safe. UseSerilog() is still the
better option - it applies from the first event rather than from the first log line - and the
warning now says so.
Also fixes a feedback loop this exposed. Emit answered a reentrant log event with another
diagnostic, which Serilog routed straight back into the sink, each message embedding the
last. With DiagnosticLevel at Info that produced 55 MB of logs in 17 seconds and the app
stopped serving requests. The SDK-namespace filter that breaks the cycle now runs before the
reentrancy check instead of after it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Removed unnecessary comments
Co-authored-by: James Crosswell <jamescrosswell@users.noreply.github.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: James Crosswell <jamescrosswell@users.noreply.github.com>
* fix(serilog): register the scope event processor atomically
Sinks sharing one set of SentryOptions can reach registration concurrently -
each sink's guard is per-instance - so the check and the add have to happen
under a lock, not as check-then-act. The sink now learns from the result
whether it was the one that registered, which is what the warning reports.
Part of #5245
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* refactor(serilog): use the Lock shim for the registration lock
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs: samples are exempt from the no-comments rule
Restores the DSN comment dropped from the Serilog sample's appsettings.json,
pointing at where this sample actually sets it, and records in AGENTS.md that
"prefer no comments" covers the library rather than samples - including their
JSON configuration files.
Part of #5245
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* Apply suggestion from @jamescrosswell
* feat(serilog): warn at runtime when the sink drops events because Sentry is not initialized
The tombstoned overloads catch everyone who passes a DSN to the sink, but they cannot see
the `WriteTo.Sentry(o => ...)` callback that only sets sink options and gets its DSN from
SENTRY_DSN or a [Dsn] assembly attribute. On 6.x that overload initialized the SDK itself;
now it compiles, nothing calls Init, and the sink drops everything silently.
Warn once, on the first event at or above MinimumEventLevel, when the hub is disabled and a
DSN can still be found. There is no DiagnosticLogger to write to in that state, so the
warning goes to Serilog's SelfLog and to standard error.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* feat(nlog): warn at runtime when the target drops events because Sentry is not initialized
Mirrors the Serilog sink: the tombstoned Dsn/InitializeSdk properties cannot see an
AddSentry(o => ...) call that only sets target options and gets its DSN from SENTRY_DSN or a
[Dsn] assembly attribute, so warn once on the first event at or above MinimumEventLevel when
the hub is disabled and a DSN can still be found. The warning goes to NLog's InternalLogger
and to standard error.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(nlog): report a stale dsn and accept initializeSdk=false (#5652)
* fix(nlog): Report a stale dsn and accept initializeSdk=false
Both tombstones could leave an upgraded app worse off than it needed to be.
A dsn left in NLog.config was silent with NLog's default settings. NLog swallows the setter's
exception unless throwConfigExceptions is on, so the target attached, Sentry was never
initialized and nothing was printed. The runtime warning also stayed quiet, because it only looks
for a DSN in the environment or an assembly attribute. The Dsn setter now writes the migration
message to standard error before it throws.
initializeSdk="false" was the recommended v6 setting next to UseSentry, and it already matches
the new behavior. With throwConfigExceptions on, it still threw, NLog rejected the whole
configuration and the app lost every NLog target. The setter now only throws for true, like the
Microsoft.Extensions.Logging tombstone.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(nlog): report a stale initializeSdk="true" as well
The stale dsn message only came from the Dsn setter, so a config carrying
initializeSdk="true" instead was still silent with NLog's default
throwConfigExceptions: the setter threw, NLog discarded it, the target attached and
nothing was printed. Both setters now go through one report-and-throw helper.
Reporting from both setters means a v6 config carrying dsn and initializeSdk="true"
together would print the same message twice, so the helper reports at most once per
target. A configuration reload builds a new target, and so reports again.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: James Crosswell <jamescrosswell@users.noreply.github.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Sentry Github Bot <bot+github-bot@sentry.io>
Co-authored-by: Ricardo Colombo Oliveira <github@ricoliv.com>1 parent 2f21e3f commit 1c94dae
26 files changed
Lines changed: 442 additions & 703 deletions
File tree
- samples/Sentry.Samples.NLog
- src/Sentry.NLog
- test/Sentry.NLog.Tests
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
10 | 10 | | |
11 | 11 | | |
12 | 12 | | |
13 | | - | |
14 | | - | |
15 | | - | |
| 13 | + | |
16 | 14 | | |
17 | | - | |
18 | 15 | | |
19 | 16 | | |
20 | 17 | | |
| |||
24 | 21 | | |
25 | 22 | | |
26 | 23 | | |
27 | | - | |
28 | | - | |
29 | | - | |
30 | | - | |
31 | | - | |
32 | | - | |
33 | | - | |
34 | 24 | | |
35 | 25 | | |
36 | 26 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
12 | 12 | | |
13 | 13 | | |
14 | 14 | | |
| 15 | + | |
| 16 | + | |
| 17 | + | |
| 18 | + | |
| 19 | + | |
| 20 | + | |
| 21 | + | |
| 22 | + | |
| 23 | + | |
| 24 | + | |
| 25 | + | |
| 26 | + | |
15 | 27 | | |
16 | 28 | | |
17 | 29 | | |
| |||
97 | 109 | | |
98 | 110 | | |
99 | 111 | | |
100 | | - | |
| 112 | + | |
101 | 113 | | |
102 | 114 | | |
103 | 115 | | |
104 | 116 | | |
105 | | - | |
106 | | - | |
107 | | - | |
108 | | - | |
109 | | - | |
110 | | - | |
111 | 117 | | |
112 | 118 | | |
113 | 119 | | |
114 | 120 | | |
115 | | - | |
116 | | - | |
117 | | - | |
118 | | - | |
| 121 | + | |
119 | 122 | | |
120 | 123 | | |
121 | | - | |
122 | 124 | | |
123 | 125 | | |
124 | 126 | | |
| |||
134 | 136 | | |
135 | 137 | | |
136 | 138 | | |
137 | | - | |
138 | | - | |
139 | 139 | | |
140 | 140 | | |
141 | 141 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
2 | 2 | | |
3 | 3 | | |
4 | 4 | | |
5 | | - | |
6 | | - | |
| 5 | + | |
| 6 | + | |
| 7 | + | |
7 | 8 | | |
8 | 9 | | |
9 | | - | |
10 | 10 | | |
11 | 11 | | |
12 | 12 | | |
13 | 13 | | |
14 | 14 | | |
15 | 15 | | |
16 | | - | |
17 | | - | |
18 | | - | |
19 | 16 | | |
20 | 17 | | |
21 | 18 | | |
| |||
25 | 22 | | |
26 | 23 | | |
27 | 24 | | |
28 | | - | |
29 | | - | |
30 | 25 | | |
31 | 26 | | |
32 | 27 | | |
33 | | - | |
34 | | - | |
35 | | - | |
36 | | - | |
37 | | - | |
38 | | - | |
39 | 28 | | |
40 | 29 | | |
41 | 30 | | |
| |||
48 | 37 | | |
49 | 38 | | |
50 | 39 | | |
51 | | - | |
52 | | - | |
53 | | - | |
54 | | - | |
55 | 40 | | |
56 | 41 | | |
57 | 42 | | |
| |||
61 | 46 | | |
62 | 47 | | |
63 | 48 | | |
64 | | - | |
65 | 49 | | |
66 | 50 | | |
67 | 51 | | |
68 | 52 | | |
69 | 53 | | |
70 | 54 | | |
71 | | - | |
72 | | - | |
73 | | - | |
74 | | - | |
75 | 55 | | |
76 | 56 | | |
77 | 57 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
12 | 12 | | |
13 | 13 | | |
14 | 14 | | |
| 15 | + | |
| 16 | + | |
| 17 | + | |
| 18 | + | |
| 19 | + | |
15 | 20 | | |
16 | | - | |
| 21 | + | |
17 | 22 | | |
18 | | - | |
19 | | - | |
20 | | - | |
21 | | - | |
22 | 23 | | |
| 24 | + | |
23 | 25 | | |
24 | | - | |
| 26 | + | |
| 27 | + | |
| 28 | + | |
25 | 29 | | |
26 | 30 | | |
| 31 | + | |
27 | 32 | | |
28 | | - | |
29 | | - | |
30 | | - | |
31 | | - | |
32 | | - | |
33 | | - | |
34 | | - | |
35 | | - | |
36 | | - | |
| 33 | + | |
37 | 34 | | |
38 | 35 | | |
39 | | - | |
| 36 | + | |
40 | 37 | | |
41 | 38 | | |
42 | | - | |
43 | | - | |
44 | | - | |
45 | | - | |
| 39 | + | |
| 40 | + | |
46 | 41 | | |
47 | | - | |
| 42 | + | |
| 43 | + | |
| 44 | + | |
48 | 45 | | |
49 | 46 | | |
50 | 47 | | |
| 48 | + | |
51 | 49 | | |
52 | | - | |
53 | | - | |
54 | | - | |
55 | | - | |
56 | | - | |
57 | | - | |
58 | | - | |
59 | | - | |
60 | | - | |
| 50 | + | |
61 | 51 | | |
62 | 52 | | |
63 | 53 | | |
64 | 54 | | |
| 55 | + | |
| 56 | + | |
| 57 | + | |
| 58 | + | |
65 | 59 | | |
66 | | - | |
67 | | - | |
68 | 60 | | |
| 61 | + | |
69 | 62 | | |
70 | 63 | | |
71 | 64 | | |
72 | | - | |
73 | | - | |
74 | | - | |
| 65 | + | |
| 66 | + | |
75 | 67 | | |
76 | 68 | | |
77 | 69 | | |
| |||
95 | 87 | | |
96 | 88 | | |
97 | 89 | | |
98 | | - | |
99 | | - | |
100 | | - | |
101 | | - | |
102 | | - | |
103 | 90 | | |
104 | 91 | | |
105 | 92 | | |
| |||
This file was deleted.
This file was deleted.
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
28 | 28 | | |
29 | 29 | | |
30 | 30 | | |
| 31 | + | |
31 | 32 | | |
32 | 33 | | |
33 | 34 | | |
| |||
0 commit comments