I think this might hurt for checking logs, because the gap between logging levels is quite big.

The server side usually does not have many logs, if there are, they are logs that require special attention. Did you have any trouble during the checking in the past?

Um, sorry for confusing. I meant it as below. I'll summarize it again.

whatever loglevel is set, ALL of the logs are written in valkey.log.
though we can filter it by some specific words, but I think if we can split the logs into with its purpose, then it will be fancy.

--

Also, just for suggestion, if the verbosity has more level, then it will be also useful
This suggestion is just my selfish thoughts, so you can ignore it if this concept is not suitable for valkey. lol
just wanted to get only client connection logs, without other verbose logs
Of course we can log and filter it with some specific words, but it may leads to large files with operating for a long time.

The server side usually does not have many logs

Think that VERBOSE is too noisy, cause it is executed every 5 sec. (even if it is literally 'verbose'.)
But VERBOSE is just next to NOTICE - the default verbosity.

/* Show some info about non-empty databases */
if (server.verbosity <= LL_VERBOSE) {
    run_with_period(5000) {
        for (j = 0; j < server.dbnum; j++) {
            long long size, used, vkeys;

            size = kvstoreBuckets(server.db[j].keys);
            used = kvstoreSize(server.db[j].keys);
            vkeys = kvstoreSize(server.db[j].expires);
            if (used || vkeys) {
                serverLog(LL_VERBOSE,"DB %d: %lld keys (%lld volatile) in %lld slots HT.",j,used,vkeys,size);
            }
        }
    }
}

@LiiNen, I see you touched upon a few points in the logging area (and you remind me of Windows's log manager)

1. Logging levels

I can see AUDIT logging being useful in some cases. For instance, when a new user is added/deleted, etc. We can probably consider introducing this level. Though it branches the existing log levels so that they won't be monodically increasing anymore.

2. Separate log files

I am not sure what value separate log files would bring. As @enjoy-binbin mentioned above, there isn't a lot of things to log today - the only exception is the cluster topology changes, which I do think we need to improve on next to help with operations. But even there I wouldn't expect us to add 100s or more log lines. A single log is still quite manageable IMO.

3. Structured log

I do think the current Valkey log is way too free-formed, which makes parsing unnecessarily hard. However, this is unlike a priority right now, for the same reason that there just isn't a lot of things to log today. But, IF we ever got a chance to redo the logging:

• First of all, I don't think we should remove the old log lines. They should be retained for "backward compat".

• Then, we could consider a schema like below:

    a. identity of "engine" vs "modules"
    b. for "engine", the component file name, such as server.c/rdb.c/etc
    c. for "modules", the actual module name
    d. the entity identity, such as node/shard/ip/db num/slot/etc.

    the schema should also be extensible since the requirements can change and flexible schema would also allow us to evolve the logging gradually with smaller changes.

• Lastly, we build on top of the schema our new richer logging utility functions.

@PingXie Thanks for your comments.

And thanks for comment about 1. Logging levels and 3. Structured log. I hope sometimes valkey branches the existing log levels with more fancy logs. This maybe quite a big change (even if it does not hurts any core operations), so I will wait this to be considered positive by your side (and also maintainers' side)

First of all, I don't think we should remove the old log lines. They should be retained for "backward compat".
Maybe this might be useless, because, as i know, there isn't any libraries or else that parse logfile. I think it is just for us-users that maintain server-so 'old log lines' could be removed after debating of it.

And lastly, for 2. Separate log files, agree to your disagree.
It really does not have giant logs, and I agree that single log has its advantages. But the point I wanted to tell is, if users can choose whether using a single logfile or multiple logfiles, then it could be nice in some part.

Anyway, thanks for your comment again and this issue could be closed if there is no plans to fix it in the near future.
I would be glad if this issue is mentioned when there are some move to re-design logging. (or else left this issue as open)