【日志工具】g3log_1_简介

最新推荐文章于 2025-04-07 10:40:29 发布

泡泡吐泡泡啊

最新推荐文章于 2025-04-07 10:40:29 发布

阅读量698

点赞数

分类专栏：编程语言学习 Linux学习文章标签： c++

本文链接：https://blog.youkuaiyun.com/weixin_41591545/article/details/129070112

版权

编程语言学习同时被 2 个专栏收录

7 篇文章

订阅专栏

Linux学习

6 篇文章

订阅专栏

欢迎来到g3log

为了更好地阅读/搜索/导航g3log的文档，请使用 kjellkod.github.io/g3log/

G3log 是一个异步日志工具，主要有3个特点：

直观的API接口 LOG(...)
Design-by-contract（契约式设计） CHECK(...) 功能性
对于致命的崩溃处理，可以正常关闭日志记录的进程，而不会丢失直到崩溃点为止的任何日志细节

g3log的快速介绍可以在下面的步骤1-9中看到。

有关更深入的信息，请参阅完整的使用说明g3log.md，与g3log进行更高级集成的内部API可以在API.md。

1. 在程序中轻松使用

为了避免深度依赖注入的复杂性，可以像下面这样进行简单的调用

#include <g3log/g3log.hpp>

2. 访问流和print_f的日志调用语法

流语法LOG 和print_f语法 LOGF都是可用的

LOGF(INFO, "Hi log %d", 123);
LOG(INF) << "Hi log " << 123;

3. 条件日志记录

LOG_IF(INFO, (1 < 2)) << "If true this message will be logged";
LOGF_IF(INFO, (1 < 2), "If true, then this %s will be logged", "message");

4. 契约式设计结构

CHECK(less != more); // not fatal
CHECK_F(less > more, "CHECK(false) will trigger a fatal message")

5. 致命崩溃处理

默认情况下g3log将捕获致命崩溃事件，例如LOG(FATAL), CHECK(false) ，以及其他的致命信号，如下:

    SIGABRT
    SIGFPE
    SIGILL
    SIGSEGV
    SIGTERM

当致命崩溃事件发生时，尚未写入的日志活动将会被刷新至日志接收器。只有当致命崩溃事件发生之前的所有日志活动都被写入到日志中时，g3log才会允许致命崩溃事件继续并退出进程。

如果object符号可用时，致命处理程序将尝试将堆栈跟踪推到致命原因并记录到日志记录接收器。

5b. 重写和自定义致命事件处理

如果需要用您自己的错误处理，或添加您想执行的代码hocks来重写致命错误处理，请参阅API.md

6. 默认和自定义日志记录级别

默认的日志记录级别是DEBUG, INFO, WARNING 和 FATAL. 您可以定义自己的日志记录级别或完全替换日志记录级别。请参考API.md

7. 日志过滤

如果配置中启用了动态日志记录级别，则g3log中将处理日志过滤。请参考API.md获得更多信息，日志过滤也可以通过接收器来处理，如github/Kjellod/g3sinks

8. 第三方和自定义日志记录接收器

默认的日志记录接收器没有外部第三方依赖项。有关更多的日志记录接收器，请参阅github/Kjellod/g3sinks

log rotate
log to syslog
log to colored terminal output
log rotate with filter

请参阅API.md中更多有关的简单步骤来创建自己的日志接收器。

9. 日志实例化

使用默认的应用程序名称（即“g3log”）创建记录器，可能会类似于以下内容：

  const std::string directory = "./";
  const std::string name = "TestLogFile";
  auto worker = g3::LogWorker::createLogWorker();
  auto handle = worker->addDefaultLogger(name, directory);

得到的文件名应该是这样的：

   ./TestLogFile.g3log.20160217-001406.log

性能

G3log旨在用尽可能少的日志开销和尽可能小的“最坏情况延迟”，将所有后台日志保存到接收器。因此，对于许多处理关键任务的系统来说，g3log是一个很好的记录器。根据平台的不同，平均日志开销将有所不同。在我2010年的笔记本电脑上，当进行极限性能测试时，平均调用大约是2 us。

关于最坏的情况下潜伏期保持稳定，没有极端峰值，突然给到极端的压力。我有一篇关于比较g3log和其他可能感兴趣的记录器的最坏情况延迟的博客文章。你可以在这里找到：https://kjellkod.wordpress.com/2015/06/30/the-worlds-fastest-logger-vs-g3log/

持续集成

g3log存储库正在评估github操作和CircleCI，以执行测试覆盖、安装和文档生成。对于windows系统，repo仍然依赖应用程序。如果您想查看这些设置中的任何更改，以下文件是您感兴趣的文件。

1. appveyor --> g3log/appveyor.yml
2. circleCI --> g3log/.circleci/config.yml
3. github actions --> g3log/.github/workflows/*.yml

反馈

如果你喜欢这个记录器（或者不喜欢），如果有一些反馈就好了。这样我就可以改进g3log，而且听到别人何时如何使用它总是很好的。

如果您有任何疑问或问题，请不要犹豫，联系我 Hedstrom @ Kjellod. cc

Kjell (a.k.a. KjellKod)

黎明就在眼前