search

Soostone / katip

A structured logging framework for Haskell
205 stars 69 forks source link

Consider adding full stack support rather than just locs #19

Open MichaelXavier opened 8 years ago

MichaelXavier commented 8 years ago

This springs out of the #18 PR: Currently our logging has the concept of a location of the log statement, but cannot support log stacks. If we did something like changing the type to Maybe (NonEmpty Loc), then both the current location and a callstack could be representable. A couple initial thoughts:

  1. Callstacks can be big. I wouldn't want to all of the sudden start doubling (or more) the storage requirements of all users. One approach could be to make whether or not location logs the whole stack or just the location to be a configuration option in LogEnv. However, when I think about how I would use katip in production, I think I would want to pick and choose what log locations get full callstacks and which don't. This would be more of a reactive strategy (i.e. if some area of the code is having problems, I'll go through and switch to callstack logging functions just in those spots and redeploy). The downside to this is it requires a redeploy, whereas if it were an option, you could potentially flip a runtime switch and start logging callstacks without any restarts, its just that it would log all callstacks. Interested to hear other thoughts on this.
  2. Some handlers may not be so amenable to this. ElasticSearch would be fine (although the mapping would need a manual migration). Currently, the handler logger logs one line per log, so would the handler logger always take the head of the loc list or do we need to switch to multi-line logging. The downside to multi-line logging is that its more difficult to process.
ibotty commented 8 years ago

I can provide some notes on the CallStack api. There you only get callstacks (i.e. more than one location) once you change the type signature of the calling functions that you want to include in the stack. So you will get more detailed call stacks when you explicitly enable it.

ibotty commented 8 years ago

Oh and re 2: multi-line logs are painful. Please just truncate the call stack in that case.

gridaphobe commented 8 years ago

Very cool to see folks using the implicit call-stacks in the real world! Feel free to ping me if you have any questions.

Re 2: you can also use getCallStack to extract a list of call-sites ([(String, SrcLoc)]) and produce your own, machine-friendly serialization. showCallStack is really just intended for human-friendly output (and has recently been renamed to prettyCallStack to make that clear).

bitemyapp commented 7 years ago

FWIW I investigated this idea for a similar library (bugsnag) and it proved not very useful because of how CallStack history can get cleaved if there's a missing constraint in-between. We're going to reuse the TH + ?loc approach for now.

domenkozar commented 5 years ago

This might actually be a good use case for http://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-ExecutionStack.html - I had a quick discussion with @bgamari on #ghc today.

The drawback is that this only works on Linux and with DWARF debugging symbols enabled(which I'd recommend anyone to enable anyway if you can risk the binary size).

Formatting per each scribe is tricky, JSON based scribes can just do [(String, SrcLoc)] and stderr scribe could do some multi-line pretty printing.

Anway, Ben is doing a talk about this at MuniHac so let's wait another three days :)

bgamari commented 5 years ago

On November 14, 2018 3:16:03 PM EST, "Domen Kožar" notifications@github.com wrote:

This might actually be a good use case for http://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-ExecutionStack.html

  • I had a quick discussion with @bgamari on #ghc today.

The drawback is that this only works on Linux and with DWARF debugging symbols enabled(which I'd recommend anyone to enable anyway if you can risk the binary size).

Formatting per each scribe is tricky, JSON based scribes can just do [(String, SrcLoc)] and stderr scribe could do some multi-line pretty printing.

Anway, Ben is doing a talk about this at MuniHac so let's wait another three days :)

Sorry, to be clear I will be speaking about another topic at Munihac. I'm afraid the DWARF talk will need to wait until another venue.

domenkozar commented 5 years ago

Thanks @bgamari, misunderstood you then.