Currently, each functional block type of Gatekeeper has a log level. This approach is meant to help those investigating a functional block since one would only raise the log level of the target block. However, this approach can run into the following issue: when a block calls functions provided by another block, these functions are potentially subject to another log level.

Consider the following example, one is investigating the communication between a routing daemon and the CPS block. The CPS block will make a number of calls to the FIB functions that the GK block provides. Raising the log level of the CPS block won't affect the FIB functions. And raising the log level of the GK block to affect the FIB functions will include a lot of log entries from the GK blocks that are not related to the calls from the CPS block.

A solution for this problem is for all log entries to use the log level of the calling block instance. This change may sound complicated at first, however, given that all block instances already have a log rate, the change won't add new infrastructure but an extension of the log rate subsystem. Thus, after the change, each block instance would have a log rate and a log level.

While the improvement proposed above seems desirable, it requires tests in production to make sure that it is so.