1.2 日志数据

虽然不同设备及应用输出的日志格式不同，但日志记录仍有行业规范可循。日志分析需要基于结构化清洗后的日志进行，而日志的结构化清洗规范则主要取决于对日志的认知。

下面分别从日志环境与日志类型、日志语法、日志管理规范、日志使用误区等方面来了解日志数据。

1.2.1 日志环境与日志类型

日志记录格式一般取决于生成日志的设备、操作系统或应用程序。日志存在于企业生产环境的各个环节，企业日志的应用与企业网站架构的变迁密切相关。

下面通过一个典型Web站点的建设流程来了解日志环境。

（1）项目前期规划：企业根据自身的业务需求确定网站内容及架构。例如，某互联网公司计划在3个月内上线网站。在上线前，需要根据业务规模（日访问量、总请求量、每秒并发访问数等）确定人员配置、服务器选型、基础系统、软件选型、架构设计等基础实施方案。

（2）项目准备：此阶段会明确人员分工，并进一步落实规划中涉及的各个方案，如软件是采用开源解决方案还是商业解决方案。采用商业解决方案可在服务商规划下落实服务器选型等细节工作，采用开源解决方案则需要企业自行规划，需要注意的细节如数据库需要单台性能极高的服务器，应用服务器可通过集群进行部署等。一种典型的开源Web架构是Linux+Nginx+MySQL+Tomcat。在基础架构设计完成之后还要考虑服务的持续可用性，这涉及安全管理（防火墙及安全设备添加）、前端请求分流（负载均衡）、资源请求快速响应（缓存）、集群资源管理（自动化运维）、实时了解服务器及应用健康度（监控告警）等重要内容。

（3）项目实施：画出详细架构图，并据此进行服务器上架、系统安装、应用部署、代码上线、添加监控、业务规则设置（负载均衡、动静分离等）、提供服务等一系列工作。

（4）后续管理及维护：包括备份、升级、迁移等。

根据以上环节涉及的设备及应用，将目前常见的日志分为以下几类：

■ 操作系统日志：如Windows、Linux、AIX、UNIX等系统日志。

■ 网络设备日志：如防火墙日志、交换机日志、路由器日志、IPS（Intrusion Detection System）日志、IDS（Intrusion Prevention System）日志等。

■ 中间件日志：如WebLogic、Tomcat、Apache、Nginx等应用日志。

■ 数据库日志：如MySQL、Oracle、SQL Server等数据库日志。

■ 数据库数据：MySQL、Oracle、SQL Server等数据库数据也可当作日志进行采集。

■ 业务系统日志：如ESB、Logic、NAS等业务系统日志。

■ 队列日志：如Kafka、Flume等日志。

此外，根据企业生产需求，如下一些重要的监控数据也可以作为日志生成：

■ 服务器性能数据。

■ 操作命令历史记录。

■ 监控软件日志。

由于不同厂商生产的设备、不同的应用程序所记录的日志格式存在差异，因此在对不同设备或应用的日志进行数据清洗或格式化时，往往要设立不同的清洗规则，而清洗规则与日志自身的语法有关。

1.2.2 日志语法

任何格式的日志文件都具有语法，日志语法在概念上与语言语法类似。一条日志通常由若干字段组成，这些字段包括如下几种：

（1）时间戳。

（2）日志条目的类型。

（3）产生该日志的系统或应用。

（4）日志的严重性、优先级或重要性。

（5）与该日志相关的操作者或用户。

（6）日志正文（用户操作行为、程序调用结果等）。

下面以一条Nginx日志为例来说明。

日志的应用集中在告警、故障排查及分析可视化方面。分析可视化依赖于日志解析效果，日志解析即依据各字段所代表的信息对日志进行规范化抽取。当面临海量数据时，日志解析对搜索性能的影响巨大。

日志解析效果受日志文本内容的影响。首先要了解日志各个字段的含义，上面的Nginx日志字段名称及含义见表1-1。

当对该日志添加时间戳规范（将现有时间格式转换为系统统一的时间格式）、Geo（IP地址地理位置解析）、UserAgent（这里指用户使用的浏览器）解析后，可以获取更多信息，如图1-2所示。

日志解析可以通过多种方式进行。以正则表达式解析为例，上述Nginx日志可使用如下的规则进行解析。

Nginx日志解析效果如图1-3所示。

日志解析就是将日志根据格式进行字段抽取并转换为结构化数据的过程，日志解析是数据清洗的方式之一。

日志解析的质量直接影响后期日志分析的效果。

1.2.3 日志管理规范

建立标准化的日志管理规范，将促进企业日志分析实现流程化、标准化，对IT服务的稳定性、安全性、可靠性和业务系统的稳健、高效运行都有不可小觑的作用。

日志管理规范化，包括日志生成规范化、日志输出规范化、日志采集规范化和日志存储规范化。在企业生产环境中，这一系列流程需要基于工单系统协同实现。

日志生成及输出往往存在一些共性。不同企业日志生成的差别，主要取决于企业业务系统的规模及成熟度、业务对IT系统的依赖程度、业务对性能及安全的依赖程度、企业数据挖掘的目的等因素。

通常来说，日志应该能够告诉运维人员如下信息：

■ 发生了什么（What）。

■ 何时发生的（When）。

■ 发生于何处（Where）。

■ 谁参与其中（Who）。

■ 参与者来源（第二个Where，注意与上面的Where区分）。

总的来说，日志记录只要能够清楚地描述所发生的事件即可。按日志种类的不同，有的日志内容较长，有的则较短。

日志维护与系统维护、安全审计、等级保护等相关。在性能上，应考虑系统负载、日志文件大小等因素；在安全上，应根据数据安全管理办法对数据进行脱敏处理；日志归档、备份、清理等规范则应参考行业审计要求，综合企业自身业务需求进行制定。

业务日志作为企业最关键的数据之一，其规范化管理是上述流程中重要性较高的一个环节。业务日志规范除了受上述规范影响，也与业务系统交易逻辑存在一定程度的关联。

日志管理规范化，是明确角色职责，加强交易状态跟踪，明确问题根源，分析应用性能，满足安全管控和审计要求的综合行为。

1.2.4 日志使用误区

常见的日志使用误区如下：

（1）不记录日志，导致问题发生时没有对应的日志可以查看。

（2）故障发生时，不查看日志数据，造成某些重大问题被忽略。

（3）日志保留时间过短，导致需要查询的日志已被删除。

（4）在日志收集之前排定优先顺序。实际上，在某些日志中有专用的优先级标志，排定优先顺序可能会错过很多重要信息。

（5）只收集单一日志，如分析系统性能时只收集系统性能日志，但应用程序日志中也有与系统性能相关的记录。

（6）只搜索已知的错误日志。只看错误日志可能不足以定位问题，与错误日志相关的上下文日志往往也具有极高的参考价值。

上述误区不仅存在于后期运维中，软件开发者也会犯类似的错误。在实际工作中，软件或站点的维护需要运维人员和开发人员相互配合，以提高工作效率。