-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RUMM-1113 Pass logged error to RUM integration #423
RUMM-1113 Pass logged error to RUM integration #423
Conversation
Now Log has its own Error property Integration use Error property and pass it to RUM Also, Scopes take error.type instead of using error.message for type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks very good 👌, but I left few notes on how we can make DDError
definition & usage better for what's required in crash reporting.
internal struct DDError: Equatable { | ||
let title: String | ||
let message: String | ||
let details: String |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Today we know much more on the unified "Datadog error format". Error Tracking team uses error.type
, error.message
and error.stackTrace
consistently and those values are commonly present in Logging, APM and RUM. This is a new knowledge comparing to what we knew when introducing this DDError
.
How about improving DDError
to act as a unified Datadog Error format? Can be done with simple renaming:
/// Datadog Error format
internal struct DDError: Equatable {
let type: String
let message: String
let stack: String
}
This should make the work with DDError
much easier, as all the downstream mappings will be more straightforward, e.g.:
- in
Log
encoding: error stack =dderror.details
will become error stack =dderror.stack
- in
Logging
toRUM
integration, error type =dderror.title
will become error type =dderror.type
Also, this would help a lot with upcoming RUMM-1050
(Send crash reports as Logs
), where type
, message
and stack
are read separately from DDCrashReport
. With this change, we could simply build DDError(type: ddcrash.type, message: ddcrash.message, stack: ddcrash.stack)
and pass it to the LogBuilder
using new logic added in this PR 👌.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good idea, done ✅
@@ -15,5 +15,5 @@ internal struct LogAttributes { | |||
|
|||
/// Type writting logs to some destination. | |||
internal protocol LogOutput { | |||
func writeLogWith(level: LogLevel, message: String, date: Date, attributes: LogAttributes, tags: Set<String>) | |||
func writeLogWith(level: LogLevel, message: String, error: Error?, date: Date, attributes: LogAttributes, tags: Set<String>) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we change error: Error?
to dderror: DDError?
here, we won't need to play with the vague Error
representation downstream (it will be mapped to DDError
early in the Logger
). This will also enable seamless integration of crash reporting (RUMM-1050
), as the DDError()
for crash report can be easily constructed.
recordedLog = RecordedLog( | ||
level: level, | ||
message: message, | ||
error: error.flatMap { DDError(error: $0) }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DDError
in LogOutput
signature. Now we need to make this mock smarter (by using part of the real output logic), to make it work. Mapping to DDError
as soon as possible (in Logger
) would fix this.
Sources/Datadog/RUMMonitor.swift
Outdated
@@ -307,11 +307,13 @@ public class RUMMonitor: DDRUMMonitor, RUMCommandSubscriber { | |||
} | |||
return nil | |||
}() | |||
addError(message: message, stack: stack, source: RUMInternalErrorSource(source), attributes: attributes) | |||
// Note for CR: should `type` be nil? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is what we concluded with the Android SDK team, right?
// Note for CR: should `type` be nil? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, removed ✅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice 🚀! Should help a lot with crash reporting as well.
Sources/Datadog/RUMMonitor.swift
Outdated
@@ -491,6 +494,8 @@ public class RUMMonitor: DDRUMMonitor, RUMCommandSubscriber { | |||
resourceKey: resourceKey, | |||
time: dateProvider.currentDate(), | |||
message: errorMessage, | |||
// Note for CR: should we leave it nil? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same - concluded with the Android SDK team.
// Note for CR: should we leave it nil? |
01a6f60
to
c32ee1d
Compare
What and why?
When
logger.error(...)
is called,LoggingWithRUMIntegration
creates an equivalent RUM error.However, this integration is not fully up to date: when it was written
logger.error(...)
could only takemessage: String
as parameter but now it also takeserror: Error?
as parameter.How?
This PR passes logged
error
to RUM integration. That way, RUM error is created out of the loggederror
instead of loggedmessage
. This gives more accurate information in RUM Explorer as can be seen in screenshots below.log.error("an error message occurred")
log.error("some message", error: NSError(...))
Review checklist