Introduce Sentry.capture_log #2606
Conversation
solnic
force-pushed
the
2603-introduce-logevent
branch
3 times, most recently
from
43abb90 to
6ae5bef
Compare
solnic
force-pushed
the
2603-introduce-logevent
branch
from
ca4d04c to
be910c4
Compare
There was a problem hiding this comment.
Looks solid! Just one comment about the client method, and then we are good to ✅
Before we move on to the logger interface though (#2604), can we spec out a buffering implementation for logs? We can do it after this PR and create another issue to track it so that we contain the scope of this particular set of changes.
https://develop.sentry.dev/sdk/telemetry/logs/#implementation
It would be nice to get a lightweight logs buffer so that we don't overwhelm sentry with requests, logs were designed so you can send multiple log payloads in a single log envelope.
| @@ -167,6 +168,20 @@ def event_from_check_in( | |||
| ) | |||
| end | |||
|
|
|||
| # Initializes a LogEvent object with the given message and options | |||
| def event_from_log(message, level:, **options) | |||
There was a problem hiding this comment.
do we want to add processing to add default attributes to logs here? Like for environment, release, sdk name, sdk version, and parent span id?
We can grab environment, release, and sdk info from the client, but parent span id maybe we can only attach from the logger API calls (not super familiar with the tracing impl in the ruby sdk).
https://develop.sentry.dev/sdk/telemetry/logs/#default-attributes
@AbhiPrasad yes this makes sense, I reported #2613 :) |
First step towards Structured Logging #2600
This adds
Sentry.capture_loginterface with a new underlyingLogEventevent type.Closes #2603