2.2.2 日志语法
任何格式的日志文件都具有语法，日志语法在概念上与语言（如英语）语法相似。人类语言语法中的句子通常包含一个主语、一个谓语、有时还包含一个表语，当然还有补语和定语。句子的语法涵盖句子成员之间的关系和他们的含义。需要注意的是，语法并不涉及消息的内容。换句话说，语法处理的是如何构造我们所要表述的内容，而不是我们使用的具体词语。
那么，在日志消息的环境下语法又有什么意义呢？当然，每条日志消息都有表征它的结构。一些类型的日志消息自身具有人类语言的部分语法，日志消息每部分由各种类型的信息模式组成。基于规则，可以定义一组通用的日志字段。而正是由于其必要性，故应存在于每条日志条目中。例如，常见的一组字段如下：
1）日期/时间（理想的情况下应包含时区）
2）日志条目的类型
3）产生该条目的系统
4）产生该条目的应用程序或组件
5）成功与失败的指示
6）日志消息的严重性、优先级或重要性（通常存在于所有syslog消息）
7）和该日志相关的任何用户活动，也可记录用户名
网络设备制造商通常在其日志中遵循上述结构，但是，缺乏某些细节的例外情况也很多。
日志的句子中有哪些内容？让我们试着对syslog的单行记录做次“语法分析”。作为最灵活（也最混乱）的日志格式的例子，我们将使用syslog的一条日志消息。
它看上去是否很晦涩？我们故意选择了相当长且深奥的一行日志。我们可以知道“主语”（表明了“什么”）是一个命名进程，指出用户应该“check_hints”（“谓语”）指定DNS服务器，这个事件发生在11月16日00:26（令人吃惊的是，syslog在其日志时间戳中并不记载年份，这会在本章后面更详细地解释）。满足一下大家的好奇心，这里发生的事件其实就是根DNS服务器中的一个IP地址改变了，但这个DNS服务器（产生上面这条日志的服务器）依旧使用其配置文件中的旧信息发起查询（例如，可以参见论文《Some error message and problems with DNS》：http://www.reedmedia.net/misc/dns/errors.html）。
日志消息的语法有什么意义？日志语法对于任何一种日志数据的自动分析（本书讨论的主题）都非常重要。我们需要按照语法将日志分解成各个组成部分，才能从日志数据中得出明智的结论。
一些日志分析相关的软件产品（商用和开源）已经开发了“消息模式”（message schema）来确定各种日志类型的语法。这种模式被设计成可以满足从各种设备、系统、应用程序和其他来源日志文件产生的任何消息。
对读者来说，大部分上面的日志消息例子显然都适合于这种模式。例如如下的Dragon NIDS消息：
上例很容易融入表2.1所示的通用模式。这条消息表明，服务器10.1.1.3遭到从10.208.231.102发起的IIS Web服务器攻击（可能是由黑客或蠕虫病毒等恶意软件发起的）。此攻击与Internet Information Services（IIS，一个标准的Windows Web服务）的Unicolde解码漏洞相关。
注意，在收集这些消息时还添加了一些数据（由日志分析解决方案提供）。
注意，日志分析系统添加了EVENT和EVENT_TYPE以及变量名称（NDNS，NetBIOS，以及其他），以完成Dragon入侵检测系统所描绘的情景。
来自“不寻常应用程序”（尽管我们不确定是否曾经见过任何“正常”的应用程序日志）等特殊日志来源的数据如何处理呢？这种情况下，人们可能会使用通用的“自定义”字段存储这类数据。虽然这样会使日志结构看上去很混乱，但是很遗憾，当前日志分析的特性就是如此。
总的来说，在做任何一种日志分析之前，对日志文件语法有一定了解都是至关重要的。有些人可以在自己头脑中执行这样的分析，但这并不影响此方法的价值，只是说明这样的分析可能很简单（也凸显了人类对机器有一定的优势）。大多数情况下，自动化日志分析系统需要理解日志语法，这种理解通常被编码成某种模板。
总体上，各种各样的系统和设备供应商会采用少数特定日志记录类型，并结合几种常见语法（在前一小节中定义）。例如，一些安全日志被记录为XML格式，以便进行更简单、信息更丰富的集成。很多运营日志通过syslog记录，采用非结构化文本或半结构化消息。与此相似，许多调试日志采用syslog甚至临时文本文件。而高性能日志记录常常采用二进制和专有格式。
常用设备日志记录选项在表2.2进行了总结。
除了这些知名的日志记录方法之外，少数网络设备还会将日志记录为逗号分隔（CSV）或ELF格式（前文已经提到）。当然这些情况相对较少出现。