Replies: 1 comment
-
Sorry for the delay here. A lot of these get bumped with "we'll look at it when we get done with ___", and there's always another ___. Moving to discussions as well. Anyway... The issue here is API design. Kermit is attempting to provide a common logging API that can reasonably be adapted to downstream logging systems. That makes the decision about what to include and not include somewhat difficult. For example, most logger implementations don't have a tag parameter. Android, however, does, and since the bulk of KMP editing is done by Android devs, generally speaking, not having tag would be a problem. Similarly, most logging systems have a concept of severity, but they don't all have the same levels. For attributes and metadata, you start to leave the conceptual world of "logger" and move more to "telemetry". Adding a log writer to Kermit to write telemetry log strings makes sense, but adding other features of telemetry systems to a logger starts to feel more like there should be a common telemetry API that calls out to Kermit if needed, rather than the other way around. Currently, for Crashlytics and Bugsnag specifically, to add this kind of data, you can just call out to CrashKiOS directly. I'm definitely not an expert in the telemetry domain, so if various systems attached metadata directly to the log statement itself, that approach wouldn't quite work. |
Beta Was this translation helpful? Give feedback.
-
Datadog has a concept of "attributes", Bugsnag has a concept of "metadata". Both are very helpful for performing advanced telemetry - for example correlating traces with logs. Right now, Kermit doesn't seem to provide a way to log attributes/metadata.
Beta Was this translation helpful? Give feedback.
All reactions