日志与常见框架

生活需要深度

已于 2022-07-09 18:48:28 修改

阅读量1.1k

点赞数

分类专栏： C++ 文章标签：日志框架

于 2022-05-17 22:28:06 首次发布

本文链接：https://blog.csdn.net/u012294613/article/details/124831738

版权

105 篇文章 11 订阅

订阅专栏

日志框架都有哪些

C++ 中的日志框架有很多，其中比较著名的有：

这么多框架，应该选择哪一个呢？

由于每个人的需求和技术栈都不一样，所以很难直接回答这个问题，但是有一些选择标准可供参考。

日志选择标准

易用性

易于使用的框架，能让你事半功倍。

易用性，是优秀框架的一个重要特性。所以无论使用什么框架，都应优先考虑这一点。

对于日志框架而言，一旦被选定，在后期开发过程中，项目组中的每个人都会频繁使用。如果易用性不好的话，那绝对是一个噩梦！所以，在选择日志框架时，应尽量找那些由简单、直观的 API 实现的方案。衡量标准可参考：对于缺乏经验的团队成员，应该在查看文档和简单示例之后，就能够快速上手。

性能（效率）

功能决定当下，性能决定未来。

另一个要考虑的重要因素是性能影响。正如上面提到的，我们会经常调用日志，这可能会对程序的性能产生巨大的影响。

想象一下，一个日志框架，需要花费很长的时间才能启动，在每次调用时阻塞并执行文件 I/O，缺少缓冲机制……对于这样的框架，你会用吗？

因此，在评估日志框架时，可以参考网上的一些文章来比较，也可以自己做一些比较性实验（基准测试），例如：吞吐量 - 测量每秒可以完成多少次方法调用（越高越好）；采样 - 测量每次调用执行究竟花费了多少时间（越低越好）。

对现有代码的影响

影响越小，越容易维护。

在以后的使用中，日志将无处不在。就像会影响运行时性能一样，它们也会影响源码的可维护性。

从应用程序的角度来看，日志所处的位置比较尴尬。之所以这么说，是因为我们尽力隔离依赖性，提供良好的接口，并最小化耦合，在编程时考虑的是单一职责原则。然后日志出现了，它到处都是，与周围的代码无关。与这些优秀的设计原则相比，日志显得有些背道而驰。

因此，应充分考虑所引入日志的影响范围，尽量让我们的代码改动最小化！

社区支持

每一个成功框架的背后，都有一个伟大的社区。

框架的生命力源于不断地完善和发展，如果没有强大的社区做支撑，这个框架便失去了源动力。

因此，在选择框架时，这一点非常重要 - 所选的框架是否有专门的团队做支撑？在像 Stack Overflow 这样的问答网站上，它是否有很强的存在感？确保一点，如果在使用过程中遇到了问题，你能有办法快速解决。倘若选择了一个不知名的框架，当遇到了 Bug 时，那么可能会浪费大量的时间来解决问题。

完整性

完整的框架，铸就完美的生产力。

在最前面，我们将日志的功能分为三个主要部分：日志记录、格式化和输出地，所以要确保所选的日志框架彻底解决了这些问题。

日志记录和输出地比较基础，几乎所有日志框架都有这些概念。话虽如此，但对于好的框架来说，应该巧妙地将日志记录与输出地分开，并且还应该有多种可选的输出地。在理想情况下，最好能够自定义输出地。

一般情况下，格式化日志文件会整齐地排列，并具有很好的可读性。但在 DevOps 的世界里，这些远远不够。具体来说，日志文件需要被格式化为可解析的数据。通过将日志输出作为数据处理，可以很容易地聚合、搜索和可视化日志，从而能够在生产支持方面助你一臂之力。所以，要确保日志框架拥有这种能力。

发展前景

只有前途光明，方能大行其道。

无法绕过这一点 - 在选择日志框架时，不仅要考虑它的现状，还应该注重它的发展前景。

像上面提到的 C++ 日志框架，每一个都非常优秀且特点鲜明。但有一些却获得了更多的关注度，例如 log4cplus、glog，为什么如此呢？因为它们有很强大的“基因”和“后台”，一个是著名的 Log4j 的衍生品，另一个则是 Google 的“亲儿子”。

一个框架的发展前景，取决于众多因素 - 关注度、用户基数、社区活跃度 …… 要想大行其道，这些几乎都不能少。

关注