当前位置: 首页 > 知识库问答 >
问题:

Poco 日志记录框架中的记录器层次结构问题

牧梓
2023-03-14

我在使用日志框架时遇到了一些问题。我有一个如下的配置文件:

# core channel
logging.channels.c1.class = FileChannel
logging.channels.c1.path = <somePath>/core.log
logging.channels.c1.archive = timestamp
logging.channels.c1.times = utc
logging.channels.c1.rotation = daily
logging.channels.c1.formatter.class = PatternFormatter
logging.channels.c1.formatter.pattern = %Y-%m-%d %H:%M:%S %s: [%p] %t

# core logger
logging.loggers.l1.name = core
logging.loggers.l1.level = information
logging.loggers.l1.channel = c1

我的程序使用Poco::Util:ServerApplication框架,受益于子系统模式。我有多个子系统,每个子系统都存储对Poco::Logger对象的引用,该对象通过使用Poco::Logger::get(“Logger name”)方法获得。我试图使用日志层次结构,将“核心”日志(如上面的配置文件所示)作为日志层次结构的根。以下代码示例了我在每个susbsystem中所做的工作:

Subsystem1::Subsystem1() :
   Poco::Util::Subsystem(),      
   logger_(Poco::Logger::get("core." + std::string(name()))),
        ...

Subsystem2::Subsystem2() :
   Poco::Util::Subsystem(),      
   logger_(Poco::Logger::get("core." + std::string(name()))),
        ...

这适用于日志记录。这很好,因为我从属性文件继承了配置,每个子系统都有不同的Poco::消息源名称,因此很容易识别日志记录条目来自哪个子系统。

当我尝试更改记录器实例的属性(例如,从 Subsystem1 的记录器)时,问题就出现了。例如,如果我更改它的通道路径,则更改将传播到整个层次结构。以下代码演示了此问题:

Poco::Logger& subsystem1Logger = Poco::Logger::get("core.Subsystem1");
Poco::Logger& subsystem2Logger = Poco::Logger::get("core.Subsystem2");
subsystem1Logger.getChannel()->close(); //without this, the change to the channel's   path does nothing
subsystem1Logger.getChannel()->setProperty("path", <someOtherPath>/core2.log); // Ok, it's changed
poco_information(subsystem1Logger "some message"); // Ok, it logs to  <someOtherPath>/core2.log
poco_information(subsystem2Logger "some message"); // NOT OK, it also logs to  <someOtherPath>/core2.log instead of  <somePath>/core.log

我很困惑,因为Poco::Logger类的头文件中指出,“一旦创建了一个记录器,并且它继承了其祖先的通道和级别,它就失去了与它的连接。因此,对记录器的级别或通道的更改不会影响其后代”。

顺便说一下,我的root logger(核心)也受到了变化的影响。

我错过了什么吗?谢了。

Poco库版本:1.5.1

共有1个答案

姬向明
2023-03-14

我认为您在记录器和通道之间感到困惑。

记录器Core Core. Subsystem1 Core.Subsystem2

都连接到同一通道c1,因为它们在创建时是Core的副本。

您通过Logger.getChannel()函数更改的是通道c1。

如果记录器连接到不同的通道,那么您的方法将有效。

 类似资料:
  • 我想在我的应用程序中使用SLF4J+logback用于两个目的--日志和审计。 14:41:57.978[main]信息AUDIT_LOGGER-110欢迎使用main 如何确保审核消息在审核记录器下只出现一次?

  • 我需要为一个相当具体的设置设置日志记录。简而言之,我想在两个不同的“父”模块中处理来自一段通用库代码的日志记录。 app_one_main和app_two_main都导入lib_module(代码如下)。 这些模块显然不共享相同的包结构,因此默认情况下,如果我使用,来自lib_module的日志记录消息不会传播到app_one或app_two app_one和app_two将在同一个Python会

  • 问题内容: 我正在考虑将Redis用于Web应用程序日志记录目的。我用谷歌搜索,有人将日志转储到Redis队列/列表中,然后将计划的工作人员转储到磁盘中。 http://nosql.mypopescu.com/post/8652869828/another-redis-use-case- centralized-logging 我希望寻求理解,为什么不直接使用Redis持久化到磁盘?如果我分配了一

  • logging 模块自 2.3 版以来一直是 Python 标准库的一部分。在 PEP 282 中有对它的简洁描述。除了 基础日志教程 之外,这些文档是非常难以阅读的。 日志记录一般有两个目的: 诊断日志 记录与应用程序操作相关的日志。例如,当用户遇到程序报错时, 可通过搜索诊断日志以获得上下文信息。 审计日志 为商业分析而记录的日志。从审计日志中,可提取用户的交易信息, 并结合其他用户资料构成用

  • 从docker容器中将结构化日志写入journald的最佳方式是什么? 例如,我有一个使用sd_journal_send而不是更改应用程序的应用程序,我尝试通过 -v/var/log/systemd/journal:/var/log/systemd/journal docker journald输出日志记录选项有哪些限制?它似乎不支持应用程序编写不仅仅是消息字段。 -- 所以我发现我需要 C程序可

  • 问题内容: 我正在编写一个服务器应用程序,该应用程序应该能够在控制台和日志文件上以不同级别登录。 问题是,如果设置了logging.basicConfig(),它将登录到控制台,但是必须在主线程中进行设置。 也可以使用logging.basicConfig(filename =’logger.log’)进行设置以写入文件。 设置用于控制台日志记录(logging.StreamHandler())或

  • 在将big project移植到log4j2之后,我注意到异常日志不起作用。这样的代码

  • 主要内容:修改日志管理器配置每个初学者都很熟悉在有问题的代码中使用 System.out.println 方法在控制台打印消息,来帮助观察程序运行的操作过程。如果你使用  System.out.println 方法,一旦发现问题的根源,就要将这些语句从代码中删去。如果接下来又出现了问题,就需要再插入几个调用 System.out.println 方法的语句,如此反复,增加了工作量。 日志用来记录程序的运行轨迹,方便查找关键信