luckyframework / luckyframework/lucky

Refactor the entire logging system

Open
#1,936 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

help wanted
Dominant language
Crystal
Stars
2.7k
Forks
172
PR merge metrics
No merged PRs in 30d

Description

At the moment Lucky uses Dexter to handle logging. This shard was originally written before Crystal did a massive refactor on their Log system. The current Log system that Crystal has built-in is pretty robust, but also infuriatingly complex ref.

The issue I'm currently running in to is that my app often makes random API calls to 3rd party systems. The HTTP::Client will only tell you what is being made if you set logging to debug; however, in development I set most of my logs to info because many of the logs are too noisy to actually see what's important. So at the moment, my log setup looks like this:

backend = Log::IOBackend.new
backend.formatter = Lucky::PrettyLogFormatter.proc
Log.dexter.configure(:debug, backend)
# Avoid so many "Executing query"
DB::Log.level = :info
Avram::QueryLog.dexter.configure(:none)
Redis::Connection::LOG.level = :info

This allows me to see more of what Lucky tells me, and less of what Redis, and SQL are throwing at me. With this setup, all HTTP::Client calls will just say "Performing request" and nothing else. This isn't helpful.

If I change that log setup for HTTP::Client, then it'll blow out ALL of my other Lucky logs.

Log.setup("http.client", :debug)

Blowing out all of the previous logs is actually mentioned in the API docs

Image

It's mentioned to use the block setup, and basically reconfigure all of the logs again.

Log.setup do |c|
  # note that with this call, the `backend` is required. You can't just leave it blank like the previous call
  c.bind "http.client", :debug, backend
  c.bind "*", :info, backend
end

The issue here is that this still won't work since the Lucky::PrettyLogFormatter.proc doesn't account for how the http.client log data is formatted. So you end up getting nothing.

Log.setup do |c|
  c.bind "http.client", :debug, Log::IOBackend.new
  c.bind "*", :info, backend
end

This "works" in that now I can see the HTTP::Client calls being made, but I can only see some of the Lucky logs. I see the request coming in, and the response, but I now don't see any output by Carbon, and I don't see what actions are rendering. My mosquito logs are also a little different now.

This leads to the new issue. We should be able to add and remove and change log statuses to different modules/shards/etc without worry of it affecting any other log setup. DB and Redis will never use Dexter since it just doesn't make sense for them so we need to account for other code we don't control and how it's configured.

Maybe Lucky can somehow monkey-patch Log in a way to "append" what we want. Maybe some helper methods to make things easier?

Half-baked idea:

backend = Log::IOBackend.new
backend.formatter = Lucky::PrettyLogFormatter.proc
Log.setup do |c|
  c.set_level(DB::Log, :info)
  c.set_level(Avram::QueryLog, :none)
  c.set_level(Redis::Connection::LOG, :info)
  c.set_level(Lucky::Log, :debug, backend)
  c.set_level(HTTP::Client, :debug)
end

Basically I just want something that I can pass the known class/module/struct/whatever and it just appends the log settings I want. I don't want to figure out that HTTP::Client is "http.client" in the logs, I want something else to just handle that for me. And whatever logs were previously setup, I don't want to blow out their settings. I want those to be left alone until I decide to override them.

Related: https://github.com/luckyframework/lucky_cli/issues/863
Related: https://github.com/luckyframework/dexter/issues/38

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by examining the current Log.dexter and Log.setup usage, along with Lucky::PrettyLogFormatter.proc. Review Crystal's logging configuration behavior and the related Dexter and lucky_cli issues before defining the design. Done should preserve existing module log settings while allowing individual integrations such as HTTP::Client to be configured and formatted independently.

Written by the indexing model from the issue text.

Assessment

Tech stack
crystal
Domain
observability-sre
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.