什么是最好的日志文件格式

我要说的第一件事是你的文件格式应该是人类可读的。我的理由在这里给出：为什么我应该使用人类可读的文件格式。

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

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

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

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

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

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

我们的技术是：

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

这使我们能够快速记录日志条目，而不会牺牲日志表中的索引，从而还可以针对日志表进行快速的 SQL 查询。

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

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

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

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

"可扩展"

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

"易于进口"

• 您要么想要第三方工具/库支持的一些非常常见的格式（XML，CSV，SQL 插入语句或SQL工具支持的任何表转储格式），要么想要一些非常简单的可以轻松编写和维护的格式

XML是显而易见的选择，潜在的缺点是：

• 冗长
• 性能
• 可读性

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

任何经验也会有用！

我们在日志中使用 XML 和其他格式的组合（某些对象具有 XML 序列化例程，但整个文件不是 XML）...这很痛苦，因为您无法对整个文件使用 XML 工具，而且格式非常复杂，以至于在没有适当工具的情况下无法进行简单可靠的解析。 所以，去整头猪或根本不去。

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

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

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

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

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

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