最好的日志文件格式是什么？ [关闭]答案

【问题标题】：What is the best log file format? [closed]最好的日志文件格式是什么？ [关闭]
【发布时间】：2011-05-12 09:02:38
【问题描述】：

我们正在开发一种数据库工具，我们希望以可扩展且易于导入数据库表的格式编写日志文件。我们都觉得使用 SQL 过滤这些信息是个好主意，因为日志将是一个长文件，“搜索”可能不够好。你能给我一些建议吗？任何经验也将是有用的！提前致谢。

【问题讨论】：

您还没有表明您的性能预期...？日志文件的创建或后续的数据库导入时间是否关键？

标签： java c++ c

【解决方案1】：

我要说的第一件事是您的文件格式应该是人类可读的。我的理由给here: Why should I use a human readable file format.

除此之外，不可能用如此模糊的问题来回答。但是，您应该考虑以下一些问题：

这个日志文件有多大？这与您拥有的空间相比如何？如果空间会成为问题，那么更简洁的格式会更好 - 例如Protocol Buffers。
如何查看日志文件？如果它使用特定工具，则格式的重要性不如使用文本编辑器或 excel
您要存储什么样的数据？如果只是 ASCII 文本，那么 CSV 效果很好。
类型信息在您的数据中重要吗？您是否需要将数字和日期作为数字和日期进行比较，而不仅仅是字符串？如果是这样，那么某种类型的系统（例如XML 或JSON）可能会更好
数据是否会转移给其他人？在这种情况下，具有良好的阅读和写作语言工具的东西可能很重要
需要以多快的速度写入数据？如果速度是一个问题（可能是实时日志文件），那么为此优化的格式可能很重要。
需要多快读取数据？
所有数据都需要在内存中，还是可以以序列化的方式进行扫描？

当您能够回答所有这些问题时，您可能自己就知道答案了。如果没有，请回答这些问题，让您的问题更加具体，这样别人会更容易帮助您。

就我个人而言，当日志数据被写入为 CSV 时，我一直很感激。它足够灵活，可以扩展（添加额外的列，更改字段的长度），可以快速读取和写入数据库电子表格以及数百种其他工具，并且可以在几秒钟内完成编码。但是，它确实有许多缺点——它很冗长，很容易出错，没有类型，并且如果重新排列列很容易破坏。

【讨论】：

首先感谢您提供如此详细和有用的答案。为什么这个问题如此模糊是因为该工具正在处理数据库问题。我不能说日志文件有多大。如果小，我们可以将其读取为 CSV 或文本文件，如果大，或发现许多问题，我们希望使用工具将信息导入表并使用 SQL 进行过滤和诊断。日志文件将从客户转移给我们，数字和日期对我们很重要。
（续）另一件事是，我们正在考虑如何定义日志文件，我们希望得到像您这样有经验的人的建议。我们当然有，再次感谢您。我们将考虑您在此处提到的所有问题，并可能会提出更多问题。 8-)

【解决方案2】：

我们发现日志往往是一个严重的性能问题。创建一个不会减慢您的公共网站速度的日志是一项挑战。

如果您有一个很大的日志，并且希望能够对其运行 SQL 查询而不会使它们变慢，那么您将需要在某些列上建立索引。您添加的每个索引都会大大减慢插入新日志条目的速度，从而导致高流量下的负载问题。

我们的技术是：

使用具有简单格式的基本纯文本文件作为日志文件（例如：制表符分隔）
不要使用 XML，它会使事情变得更复杂（即速度变慢）而没有任何好处。
网站使用 UNIX 文件锁定来简单地为每个日志条目附加一行
cron 作业每 10 分钟将日志内容插入 SQL 数据库（我们使用 MySQL，但这取决于您）。
此 cron 作业一次处理一行文件，使用 UNIX 文件锁定来防止在处理日志时写入日志，但在处理完每一行并从文件中删除后，让公共站点有机会访问日志（如何以您喜欢的语言执行此操作将是堆栈溢出的一个很好的第二个问题）
cron 作业的超时时间为 5 分钟（因此每 10 分钟它将花费最多 5 分钟处理日志。这样可以确保服务器在出现性能问题时不会无限期地处理日志文件）

这让我们可以快速记录日志条目，而不会牺牲我们在日志表中的索引，同时也为我们提供了针对日志表的快速 SQL 查询。

我们已经在各种 CentOS 服务器上使用它大约 6 或 7 年了，它一直坚如磐石。我想根据操作系统及其配置方式，这可能不是创建日志文件的好方法。但它在我们的测试中效果很好。

PS：我认为使文件可读性没有任何意义。您只会在调试期间阅读它，然后您将永远不会再触摸它。

【讨论】：

谢谢，真实世界测试的优点。我想问一下，由于cron作业每10分钟向数据库插入一次行，日志表会越来越大，你们是如何处理的？将历史记录行移动到另一个历史记录表中？
对于我心目中的客户，我们每隔几年创建一个备份，然后删除几个月前的所有内容。配置良好的数据库服务器可以处理这么多数据，而且磁盘空间很便宜。另一种方法可能是进行第二个 cron 作业（可能是每周一次），存档/删除任何超过特定年龄的内容。

【解决方案3】：

我们正在开发一种数据库工具，我们希望以可扩展且易于导入数据库表的格式编写日志文件。我们都觉得使用 SQL 过滤这些信息是个好主意，因为日志将是一个长文件，“搜索”可能不够好。你能给我一些建议吗？

假设您有某些理由不直接插入数据库表中...

“可扩展”

您可能希望在文件本身中包含元数据（字段名称和/或类型）
- 这可以让您制作一个通用且在很大程度上面向未来的数据库导入工具，该工具可以根据日志文件创建和填充数据库结构（而不是随着日志文件格式的发展而需要编辑的紧密耦合）
一种支持层次结构的记录日志格式，可以更轻松、更简洁地扩展

“易于导入”

您要么想要一些由 3rd 方工具/库支持的非常常见的格式（XML、CSV、SQL 插入语句或您的 SQL 工具支持的任何表转储格式），要么想要一些非常简单且易于编写和维护的格式

XML 是显而易见的选择，潜在的负面因素是：

冗长
性能
可读性

在我开始写这篇文章的时候，你没有表达过担心。

任何经验也会很有用！

我们在日志中使用 XML 和其他格式的组合（一些对象具有 XML 序列化例程，但整个文件不是 XML）...这很痛苦，因为您不能对整个文件使用 XML 工具，并且格式足够复杂，以至于在没有适当工具的情况下无法轻松可靠地进行解析。所以，要么全力以赴，要么根本不去。

【讨论】：

感谢您的 cmets。由于 XML 过于冗长，虽然性能对我们来说不是问题，但 JSON（Nick 提到，参见第一条评论）呢？我们现在正在考虑 JSON 格式。
@icespace：我自己从未使用过 JSON，但据我所知，它在每个值之前重复了“元素”名称，并且看起来和 XML 一样冗长。如果您想要更少的冗长，最大的潜在因素是在文件顶部描述一次字段名称/类型元数据，然后只描述其后的值。（YAML 的另一种可能性值得考虑，但似乎有同样的冗长问题）
对于这个用例，XML 的问题在于它有多复杂。与大多数其他格式相比，尝试将单个条目添加到 XML 文档的末尾是计算密集型的。 JSON 稍微好一点，但不是很多。顺便说一句，JSON 远没有 XML 那样冗长。例如：<?xml ...><list><item>a</item><item>b</item><item>c</item></list> 与 ["a", "b", "c"]。 JSON 是一种很棒的格式，我将它用于各种事情，但请记住 XML 更加灵活。
@Abhi：感谢您纠正我对 JSON 的错误印象。干杯。

【解决方案4】：

由于我不确切知道它将如何存储在数据库或其他地方，我想我会设置一种可计算的格式并使其可以被工具解释以注入数据库或生成一个文件。

例如，我会制作一个简单的 xml 格式，或者如果我需要人类直接在初始格式内阅读，我会制作更易于阅读的东西。否则，我会使用 xml。

该文档将提供至少是日期时间、模块名称、日志级别和消息的信息。转换工具可以添加或忽略其他信息。

然后我会为数据库编写一个转换工具，也许是一些 python 脚本，它会解析 xml 文件并将数据注入数据库。该工具完全取决于上下文。

我也可能会编写一个脚本来生成日志的 html 视图。

主要思想是拥有一种可被不同工具轻松使用的可解释格式。这种格式只会提供原始信息，尽可能多的信息。 这样，转换工具将决定什么是有价值的，将日志中的数据放在哪里以及如何放置。

【讨论】：

感谢您的 cmets。 HTML 视图确实是个好主意。我们没有考虑到这一点，我想所有人都会喜欢 HTML 视图。