What's the goto general-purpose library for logging

Learn
#1

So here’s the deal, I’m looking for a general purpose library that’s fast, structured, maintained, high-level and with a good documentation.
Now of course, I don’t expect the open source community to just provide a library with all these characteristics, I know I’ll have to write documentation, pull requests for missing features, etc, that’s fine I’m all in.

But searching on Hackage for even one or two of of these characteristics left me clueless.
There is fast-logger which seems to be the most downloaded on hackage, but it seems very low-level and impractical for app or web-server usage.
There is wai-logger but it seems quite specific to web servers.

And then there are many others with less downloads which all bring some specifics that are not directly related to what I’m seeking (mainly effects).

TL;DR what logging libraries do you use ? Are you happy with it ? What’s used in big haskell projects ?

PS : This question was already asked before without much success Which logger library should I use?

3 Likes
#2

At work we use @hackage/log-base, with which we are quite satisfied. We use the ElasticSearch backend for it.

I’d be happy to hear any feedback on what would prevent you from adopting it. :slight_smile:

5 Likes
#3

So that’s the one I was thinking was the goto haskell library for logging initially, but it’s not downloaded much (not that I care too much about that specific metric, but It made me ponder).

I’ll have a deeper look then, thanks.

1 Like
#4

oh you have to remember two things about download numbers

  1. Caching dependencies doesn’t hit Hackage
  2. Fetching the dependency from the CDN doesn’t hit Hackage either

And since cabal doesn’t do telemetry, it’s pretty hard to have reliable download numbers. :slight_smile:

4 Likes
#5

If you use RIO, that has structured logging built in, and you can either log to stdout with the default or log to wherever source you like.

https://hackage.haskell.org/package/rio-0.1.22.0/docs/RIO.html#g:17

1 Like
#6

Just roll your own. It isn’t hard and most logging frameworks do a bazillion things I don’t need and the things I want not quite right.

3 Likes
#7

Like @Kleidukos, I also suggest log-base (via log-effectful). There’s beauty in the simplicity behind it, there’s not a huge amount to it! I’m also the author of logging-effect: A mtl-style monad transformer for general purpose & compositional logging and I wanted to avocate structured logging there. Ultimately I find the API here a bit too cumbersome to work with, and prefer how log-base deals with this: log messages have text, and an optional blob of JSON.

9 Likes
#8

monad-logger is based on fast-logger and provides some useful abstractions. It is used in Yesod. I like the type class approach that lets you decide later on how and where to collect the log messages.
That said, sometimes you can get quite far with just a WriterT [Text] and discharge the WriterT component as you see fit.

#9

I’d suggest co-log-core and co-log, but I am not entirely sure whether these libraries are maintained.

#10

This advice applies only if you Know What You’re Doing. Otherwise it’s highly likely that you’ll make something that performs terribly and is not thread-safe. I’ve seen it a dozen times.

3 Likes
#11

hmm I can’t even think of an application I’ve built where my logger performance matters enough that I can just spew to stderr with what’s in base

Only thread safety issue I can imagine is disabling line buffering?

I rolled a logger in IO that used an implicit param for context (that the user never touches - so no user-facing -XImplicitParams). Worked great, was easy to write an mtl shim for parts of the code that preferred that, spewed JSON to stderr.

The main issues I’ve run into with logs are downstream in aggregators like ES.

Oh I guess I ran into my logger crashing my games on Windows because there was no stderr. But traceIO does the Right Thing so that was an easy fix.

#12

You can consider using katip. It is high level, actively maintained and used in production environments. I am really happy with it.

3 Likes
#13

You’ll encounter one eventually. :ok_hand:

3 Likes
#14

Besides, I don’t think it’s a very good vibe, community wise, to tell people to build their own libraries in this context. Not that I want to deter anyone from doing it, everyone’s free to enjoy any path towards success, but I don’t see it as a good answer to my question.

There are many good reasons for sharing code in libraries beyond “doing it myself is too hard”. And I don’t see any benefit/risk/cost ratio bending towards building it myself in this case.

4 Likes
#15

Oh yeah I’m sure they exist! I should’ve added that note in my comment. I’d love to hear about actual factual examples :nerd_face::ok_hand:

#16

We use a “roll your own” solution. And by that I mean a thin custom layer over fast-logger

2 Likes
#17

I very much enjoy monad-logger-aeson, both on personal projects and professionally. It provides structured logging, it is fast (I think based on fast-logger), it is maintained, and it is well documented.

1 Like