getsentry/sentry-cocoa

Logging improvements

Opened this issue · 3 comments

armcknight commented

Description

As we continue developing the SDK, we might find the amount of logs emitted (esp in debug mode) grows unwieldy.

There are a couple things to consider implementing:

  1. component-based logging (and/or log levels). the way i've seen this done in the past is to allow enabling either all logs, or to disable all logs and then be able to selectively enable logs only in particular code files. this is easier with macros in objc, not sure how it'd work with swift. maybe we would want something more at the "module" level: e.g. profiling has more than one file we'd want logs from.
  2. another more verbose log level like "trace" to put things that either output at high frequency or output large amounts of data per message, like dumping all configuration options or the entire contents of each envelope.
  3. Logging for Swift is also important.
  4. The SentryCrash logs should be unified with the normal SentryLog. (Note, #4061 brings back file-based logging from the crash reporter, but I'd like to see the entire logging apparatus from the crash reporter simplified and more tightly integrated with our other logging code.)

With (2), we'd eventually want:

  1. a way to avoid evaluating the expressions in a log statement if it is below the currently configured log level. No point allocating and building a huge string just to throw it away. This would have a positive perf impact today as-is.

  2. provide other log sinks besides just NSLog, like printf or writing to files.

philipphofmann commented

I fixed point 5 with #4028.

  • ❤️1
armcknight commented

I just thought of one more point:

6: provide other log sinks besides just NSLog. For two reasons:

  • NSLog is not async-safe; it causes crashes if I try to log from the profiler's thread, eg. Using printf() and write() are both async-safe, so separate sinks for those would be nice.
  • in the case of writing to a file instead of the console, we can debug a wider variety of cases, like crash reports (see point (4) above, the current logging interface is kind of clunky) or retrieving logs from customers.
  • 👍1
armcknight commented

The chain of PRs starting with #4101 helps with points (4) and (6)