What's your logging strategy?

Help General
22

Fantastic! Would you mind sharing the code of the AppLoggy mixin?

23

It’s really just a getter to service locator to get that logger service, which then adds log to Loggy package.

Note: I experimented with late final AppLoggerService logger, but while it works it turned out it does not support the mixin being on const classes.

mixin AppLogger {
  AppLoggerService get logger => GetIt.I<AppLoggerService>();

  static AppLoggerService get instance => GetIt.I<AppLoggerService>();
}

then setup of the Loggy instance is something like this

Loggy.initLoggy(
  logPrinter: CombinedLogPrinter(
    printers: [
      if (AppEnvironment.current.isBugfenderEnabled)
        BugfenderLogPrinter(bugfenderFacade: GetIt.I<BugfenderFacade>()),
      if (AppEnvironment.current.isCrashlyticsEnabled)
        LogGroup(
          logKeys: FirebaseKeysHandler(crashlyticsFacade: GetIt.I<FirebaseCrashlyticsFacade>()),
          logPrinter: FirebaseLogPrinter(crashlyticsFacade: GetIt.I<FirebaseCrashlyticsFacade>()),
        ),
      if (AppEnvironment.current.isConsoleLoggingEnabled) PrettyConsoleLogPrinter(),
      if (AppEnvironment.current.isSeqEnabled) SeqLogPrinter(seqFacade: GetIt.I<SeqFacade>()),
    ],
  ),
)

And again, those classes like CombinedLogPrinter, BugfenderLogPrinter, FirebaseLogPrinter are shared, just the platform connection to i.e. crashlytics is added using the facade. (so we dont have to have firebase etc. as dependency of the shared package, and rather apps should decide what and which version to use)

And these our shared printers basically just format message for given logging service and also parse error if that is using our interface etc.

And CombinedLogPrinter is basically a printer for Loggy package that accepts our printers (we decided to abstract those so we can build list of printers in our app rather than having wired up printers in the shared package between all of those apps.

3 Likes
24

Btw. currently we are adding a tool for dev/staging builds that would persist last X logs and for us this only means hooking another “printer” that would just forward logs to the persistance service. So for us it’s super useful that we have this thing set up. :slight_smile:

1 Like
25

I am a log minimalist.

I try and avoid having any logs in the app at all and the only time logs are added is when I’m trying to hunt down bug in production.

Why?

Whenever you add logs all over your app you’re essentially creating a huge haystack and then when you are trying to find the logs which are relevant for hunting down the bug it’s like searching a needle in a haystack when you have extremely busy logs.

I also prefer pkg:logging as this makes it easier to read through logs on error tracking tools like Sentry.

1 Like
26

Fair point. I’m the exact opposite, but I get where you’re coming from.

I use Sentry and other “error reporting from the wild” tools and I want to see exactly how things went before the error happened, even including things like viewport sizes and individual button taps and such. This has helped me a countless number of times.

1 Like
27

This is one of the issues I want to address in the next version of my logging system. I would like to be able to assign logs to a “feature”, where I can toggle all logs for a feature on and off.

1 Like