本节书摘来华章计算机《日志管理与分析权威指南》一书中的第2章 ，第2.2.1节，（美） Anton A. Chuvakin Kevin J. Schmidt Christopher Phillips 著 姚 军 简于涵 刘 晖 等译更多章节内容可以访问云栖社区“华章计算机”公众号查看。
2.2.1 日志格式和类型
在开始讨论格式和其他信息之前，我们应该指出，为了满足前文所述的目标，任何日志记录机制都可以从逻辑上分为四个部分：
- 日志传输
- 日志语法与格式
- 日志事件分类学
- 日志记录的设置、配置与建议
这些主要特性将在整个报告以及本项目下生成的其他文档中使用。让我们来详细地研究它们的关键概念。
日志传输就是将日志消息从一个地方转移到其他地方的方式。
事件传输协议有许多种，例如syslog、WS-Mangement和许多专有的产品特定的日志传输协议，还有一些日志记录机制没有自己的传输方法（例如，只有本地日志文件）。合格的日志传输机制必须既能保证日志数据的完整性、可用性以及机密性（如果有需求的话），又能维护日志的格式和意义并使发生的所有事件都能得到正确的表示，具备正确的时间和事件顺序。日志传输中最重要的需求是保证各个日志（事件记录）以及整个事件流/日志的完整性。更重要的是保存每个日志条目的正确时间戳。
以下列出一些知名的日志传输机制：
- syslog UDP
- syslog TCP
- 加密syslog
- SOAP over HTTP
- SNMP
- 传统文件传输方式，例如FTPS或SCP
例如，syslog UDP作为迄今为止最流行的日志传输机制，应用于数以百万计的Unix派生系统和网络设备之上。尽管自身有多个极大的弱点（例如缺少消息送达和可用性的保证），但syslog依旧被认为是转移日志数据的最佳方式。
日志语法与格式定义日志消息形成、传输、存储、审核以及分析的方式。在最简单的情况下，每条事件记录可以作为文本字符串看待，事件的消费者可以在日志中执行全文搜索，期望文本具有一致性。但为了进行可靠的自动化事件分析，事件的消费者和生产者对事件记录语法的理解和认同就显得十分必要了。
下面列出一些知名的日志格式：
- W3C扩展日志文件格式（Extended Log File Format，ELF），（http://www.w3.org/TR/WD-logfile.html）.
- Apache访问日志(http://httpd.apache.org/docs/current/logs.html).
- Cisco SDEE/CIDEE(http://www.cisco.com/en/US/docs/security/ips/specs/CIDEE_Specification.htm).
- ArcSight公共事件格式(Common event format,CEF)(http://www.arcsight.com/solutions/solutions-cef/).
- syslog(RFC3195和更新的RFC5424).
- IDMEF——一种基于XML的格式(http://www.ietf.org/rfc/rfc4765.txt).
对于最后一个项目，“syslog”这一术语通常指通过UDP协议514端口转移消息的方法（syslog传输），也指以一些结构化元素创建日志消息（syslog格式）。
特别需要说明的是，每个格式化事件记录的每个字段都包含着以某种形式表示的信息。尽管对人类来说可能显而易见，但是“sun 12 3 2010 11：11pm”和“2010-12-03T11:11:00Z”并不能清晰地表示同一个时间。而且，在第一个例子中，由于时区信息缺失，我们并不能确切地知道真正的时间，考虑到不同地区的日期表示顺序习惯不同，日期信息也存在歧义（3月12日还是12月3日）。下面是日志文件格式的一些例子：
很不幸的是，现在的大部分日志依然没能遵循任何指定或预定的格式（或者说只有消息的一小部分遵循，例如时间戳），它们仍然被认为是自由格式的文本。
日志格式有不同的特性。首先，日志文件是二进制还是ASCII码格式？是否可以用一个简单的文本浏览器或编辑器读取日志文件，或者需要使用转换工具以得到日志中的信息？
人类可读或ASCII码日志的最明显例子是Unix syslog，下面是一个例子：
Web服务器、防火墙和各种平台上的许多应用程序都采用容易查看的文本文件记录日志。
但是要注意，人类可读、文本以及ASCII码日志格式并非完全同义，Unicode文本（并非ASCII）并不少见，而且，并不是每个人都能够（或愿意）阅读嵌套关系复杂、包含冗长文本行和许多标记的XML格式日志文件。
二进制文件最常见的例子就是Windows事件日志。读者可能表示反对，认为事件日志是容易阅读的。但是阅读事件日志需要使用事件查看器。这个实用工具将二进制日志文件（一般存储在C:WINDOWSSYSTEM32CONFIGdirectory，扩展名为Evt）转换成人类可读的形式，如图2.2所示。
其他的常见二进制格式还有Unix wtmp文件，它包括了登录记录和包含进程统计信息的pacct。虽然严格地说不算是一种日志格式，但Tcpdump二进制格式可以被定义为一种网络包数据的日志记录格式，因此也可被归入这一类。
为什么一些程序员选择二进制作为日志数据格式？可以肯定的是，如果所有日志记录是基于文本、容易阅读的，对我们人类来说会更简单！但是，二进制日志记录有极具说服力的理由：性能和空间。如果某个系统每秒要收集成千上万条日志记录，即使对于现代CPU此任务也并不轻松。而且系统用户通常有一个合理的期望，即日志记录不会破坏系统性能。事实上，反对日志记录最常见的理由就是“它将影响性能”。而我们的回应通常是：“如果系统崩溃的时候你不知道原因，性能再好又能如何？”
二进制格式日志条目通常尺寸更小（平均信息量低），因此格式化或写入花费的处理更少。由于消息通常比ASCII码的消息更小，所以日志文件占据的磁盘空间更少，在传输时占用的IO资源也更少。
另外，解析二进制文件需要的处理通常更少，而且字段与数据类型的定义清晰，使分析更加高效。ASCII码日志解析器不得不处理更多的数据，并且常常需要模式匹配来抽取信息中的有用内容。
压缩日志从定义上看属于二进制日志，它进一步为采用二进制日志记录提供了理由：日志记录可以进行压缩。显而易见，若日志文件是一个加密格式，则它必须采用二进制形式。采用二进制日志的其他原因包括它们更难于阅读。为什么这一点成为优势呢？因为所谓的“无名安全性（security by obscurity）”，许多人认为这使得他们的日志文件“更安全”。
另一类日志格式则是关系型数据库，它既不是真正的文本也非二进制格式，或者可以视为一种很花哨的二进制格式。关系型数据库将二进制记录存储在一个添加（称为“插入”（insertion））和读取（称为“选择”（selection））性能很高的表中，该表由数据库模式（schema）定义。数据库模式是用来定义表中的记录和整个数据库中的表的方法。
日志类型的另一个重要区分方法就是其格式是开放的还是专有的。开放格式意味着其格式在某个地方记载，可能是标准化文档（例如ISO、ANSI或Internet标准）或参考文档（例如RFC）。专有格式可能公开也可能不公开，通常由特定的设备供应商使用。但是，专有格式通常是没有文档的，人们只有依靠供应商的日志阅读和处理工具。
理解专有文本格式的方法只能是研究它（“逆向工程”，尽管这个术语更常用于二进制格式）。但是，这种方法面临曲解某个特定字段意义、数据类型以及取值范围的风险，往往得到相当无用或者误导性的结果。
日志记录的设置、配置和建议，对于事件生产者和系统操作人员决定哪些事件应该记录，或在单个设备上启用哪些日志记录来说是最常见的途径。利用常见的事件表达方式，倡导产品应该生成什么样的事件是可能的。虽然人们期待防火墙记录日志事件，如它拦截的连接企图，但是迄今为止并没有标准的日志记录规则。同样重要的是，不仅要关注所记录的事件，还要着眼于每个事件日志记录应包含的细节信息。
目前这一领域没有任何行业范围的日志记录建议。PCI DSS依从性是这种建议的常见例子之一。
具体而言，PCI DSS日志记录规定（参见图2.3）每条日志条目最少应包含用户名、事件类型、日期和时间、成功或失败的指示、受影响的组件名称以及事件的源系统（事实上这表示了一套非常有用的常见日志细节信息）。
许多其他行业组织针对日志记录的事件和详情也创造了自己的日志记录建议，本报告的下文会概括总结这些建议。
