近日，有幸拜读《日志管理与分析权威指南》一书，本书由三位业界资深安全专家编著，从日志的基本概念开始，由浅入深讲述了整个日志生命周期的详细过程，从日志的概念、数据概念、人工分析日志、以及日志与合规的依从性、自动化分析日志引申到SIEM日志管理。而其一作者Anton A.Chuvakin博士是日志管理、SIEM和PCI DSS依从性领域公认的安全专家，他的博客www.securitywarrior.org是该领域中最受欢迎的博客之一，下面附一张Anton A.Chuvakin博士的博客截图。
题主并不是日志分析专家，只是借着学习后的总结分享出来，每个人在不同时机看的东西不一样，欢迎指正~
简单地说，日志消息就是计算机系统、设备、软件等在某种触发下反应生成的东西。确切的触发在很大程度上取决于日志消息的来源。例如，UNix操作系统会记录用户登录和注销的消息，防火墙将记录ACL通过和拒绝的消息，磁盘存储系统在故障发生或者在某些系统认为将会发生故障的情况下会生成日志消息。
日志数据就是一条日志消息里用来告诉你为什么生成消息的信息，例如，web服务器一般会在有人访问web页面请求资源（图片、文件等等）的时候记录日志。如果用户访问的页面需要通过认证，日志消息将会包含用户名。
-
信息：这种类型的消息被设计成告诉用户和管理员一些没有风险的事情发生了。例如，Cisco IOS将在系统重启的时候生成消息。不过，需要注意的是，如果重启发生在非正常维护时间或是业务时间，就有发出报警的理由。
-
调试：软件系统在应用程序代码运行时发生调试信息，是为了给软件开发人员提供故障检测和定位问题的帮助。
-
警告：警告消息是在系统需要或者丢失东西，而又不影响操作系统的情况下发生的。
-
错误：错误日志消息是用来传达在计算机系统中出现的各种级别的错误。例如，操作系统在无法同步缓冲区到磁盘的时候会生成错误信息。
-
警报：警报表明发生了一些有趣的事，一般情况下，警报是属于安全设备和安全相关系统的，但并不是硬性规定。在计算机网络中可能会运行一个入侵防御系统IPS，检查所有入站的流量。它将根据数据包的内容判断是否允许其进行网络连接。如果IPS检测到一个恶意连接，可能会采取任何预先配置的处置。IPS会记录下检测结果以及所采取的行动。
计算机或者其他设备都实现了日志记录子系统，能够在确定有必要的时候生成日志消息，具体的确定方式取决于设备。另外，必须有一个用来接收和收集日志消息的地方，这个地方一般被称为日志主机。日志主机是一个计算机系统，一般来说可能是linux和windows服务器系统，它是集中收集日志消息的地方。使用集中日志收集器的优点如下：
-
可以集中存储从多个地方得到的日志消息。
-
可以在上面备份你的日志。
-
可以在上面进行日志数据的分析。
那么，日志消息如何传输？最常见的方法是通过syslog协议。syslog协议是日志消息交换的一种标准。常见于Linux系统中，也使用在windows平台上。syslog基本上都实现了客户端和服务端组件，两者之间通过用户数据报协议（UDP）通信，但是为了可靠传输，很多开源和商业syslog实现同样也支持传输控制协议（TCP）。
syslog并不是传输和收集日志数据的唯一机制。例如，微软为windows开发了自己的日志记录系统，称为windows事件日志。用户登录注销，应用程序消息等都以专有的格式存储。有开源和商业的应用程序用来将windows事件日志转换成syslog的格式，以发送给syslog服务器。
简单网络管理协议（SNMP）是一种用来管理网络设备的基于标准的协议。
数据库已经变成了应用程序存储日志消息的简便途径。应用程序可以将它的日志消息写进数据库模式，而不是生成一条syslog消息。在某些情况下，syslog服务器本身也可以直接写入关系型数据库，特别是在结构化存储、分析和报告日志消息的情况下有着极大的优势。
最后，也有一些专有的日志记录格式。第三方设备和应用程序实现了用于生成和检索日志消息的专有机制。在这个领域，供应商可能以C或者java类库的形式给你提供应用编程接口（API），或者由你自行实现协议。可将windows事件日志看作一种专有格式，但时常人们将其看作非官方日志记录标准，类似syslog，因此这种方式很流行。
-
syslog：基于UDP的客户端/服务器协议。这是最常见和普遍的日志记录机制。
-
SNMP：SNMP最初是为了管理网络中的设备而创造的，然而多年来许多非网络系统已采用SNMP作为发出日志消息和其他状态类型数据的方式。
-
windows事件日志：微软的专有日志记录格式。
-
数据库：以结构化的方式来存储和检索日志消息。
-
LEA：日志提取API是Checkpoint用于从它的防火墙和安全产品线收集日志的API。
-
SDEE：安全设备事件交换是思科用于从它的IPS设备产品线收集日志消息的基于可扩展标记语言的协议。
-
E-Streamer：E-Streamer是Sourcefire公司为其IPS开发的专有协议。
选用以syslog方式采集日志数据非常方便，且具有下述原因：
第一，Syslog协议广泛应用在编程上，许多日志函数都已采纳syslog协议，syslog用于许多保护措施中。可以通过它记录任何事件。通过系统调用记录用户自行开发的应用程序的运行状况。研究和开发一些系统程序是日志系统的重点之一，例如网络设备日志功能将网络应用程序的重要行为向 syslog接口呼叫并记录为日志，大部分内部系统工具(如邮件和打印系统)都是如此生成信息的，许多新增的程序(如tcpwrappers和SSH)也是如此工作的。通过syslogd(负责大部分系统事件的守护进程)，将系统事件可以写到一个文件或设备中，或给用户发送一个信息。它能记录本地事件或通过网络记录到远端设备上的事件。
第二，当今网络设备普遍支持syslog协议。几乎所有的网络设备都可以通过syslog协议，将日志信息以用户数据报协议(UDP)方式传送到远端服务器，远端接收日志服务器必须通过syslogd监听UDP 端口514，并根据syslog.conf配置文件中的配置处理本机，接收访问系统的日志信息，把指定的事件写入特定文件中，供后台数据库管理和响应之用。意味着可以让任何事件都登录到一台或多台服务器上，以备后台数据库用off-line(离线) 方法分析远端设备的事件。
第三，Syslog协议和进程的最基本原则就是简单，在协议的发送者和接收者之间不要求严格的相互协调。事实上，syslog信息的传递可以在接收器没有被配置甚至没有接收器的情况下开始。反之，在没有清晰配置或定义的情况下，接收器也可以接收到信息。
对于基于“推”的日志来源，设备或者应用程序向本地磁盘或者通过网络发出消息。如果通过网络，你必须配备一个日志收集器来接收消息。3种主要的基于“推”来源是syslog、SNMP和windows事件日志。日志消息通过这些协议传输。从技术上说，windows事件日志包含协议、传输机制、存储和读取。
对于基于“拉”的日志来源，应用程序从来源拉取日志消息。这种方法几乎总是依赖客户-服务器模型。以这种方式运行的系统通常以专有格式保存日志数据。例如，Checkpoint提供OPSEC C程序库，开发人员可以用它编写应用程序，拉取Checkpoint防火墙日志。其他产品使用MSSQL、Qracle、Mysql等数据库存储数据。从数据库拉取日志稍微容易一些，可以用脚本或程序完成。
上面提到的三种最常见的日志来源协议，首先是syslog。
syslog最初是用于收集调试信息的，因此，它对于安全日志分析有一些限制，不是最优的，尽管如此，syslog已经成为了基于Linux的系统中记录应用程序事件的最常用方法。
SNMP设计用于满足网络管理员不断增长的需求。SNMP几乎集成到所有你能想到的网络中，包括许多网络安全设备。SNMP是查询和配置设备的一种协议。虽然SNMP协议整体来说不是一个日志记录系统，但是可以看作日志消息的类型。虽然许多网络设备能够通过syslog发送事件消息，但是有些设备不能，特别是旧设备，因此SNMP是从设备获得其他途径不能收集的事件信息的一种方式。
Microsoft在很久以前就决定要创造自己的日志生成和收集系统。这一系统被称作事件日志。现在的事件日志有一些高级特性。事件日志主要用于收集和查看两类日志：
Windows日志至少包括应用程序、安全和系统。最重要的是安全日志，登录、注销、资源访问记录的地方。
一、系统日志:
记录系统中硬件、软件和系统问题的信息，同时还可以监视系统中发生的事件。系统日志包括系统日志、应用程序日志和安全日志。
二、网站日志:
1.记录web服务器接收处理请求以及运行时错误等各种原始信息以.log结尾的文件。我们通过对日志进行统计、分析、综合，就能有效地掌握网站运行状况，发现和排除错误原因，了解客户访问分布等，更好的加强系统的维护和管理。
2.日志也是了解搜索引擎工作原理和搜索引擎对网页抓取频率的最佳途径。通过这个文件，可以了解搜索引擎什么时间、抓取了哪些页面，以及可以知道是主搜索蜘蛛还是从搜索蜘蛛抓取了您的网站等的信息。
3.通过不同的log日志级别来记录以往的操作行为，可以很轻易地分析得到：
4.通过分析网站日志Log文件我们可以看到用户、搜索引擎蜘蛛访问网站和管理人员操作的行为数据，这些数据能让我们分析出用户和蜘蛛对网站的偏好以及网站安全操作及健康情况。因此在网站日志分析中，我们主要需要分析的是蜘蛛行为和操作行为。
5.在分析日志时，对于单日日志文件我们需要分析的内容有：访问次数、停留时间、抓取量、目录抓取统计、页面抓取统计、蜘蛛访问IP、HTTP状态码、蜘蛛活跃时段、蜘蛛爬取路径等；对于多日日志文件我们需要分析的内容有：蜘蛛访问次数趋势、停留时间趋势、整体抓取趋势、各目录抓取趋势、抓取时间段、蜘蛛活跃周期等。
网站日志数据分析解读：
从这三项数据中我们可以得知：平均每次抓取页面数、单页抓取停留时间和平均每次停留时间。
从这些数据我们可以看出蜘蛛的活跃程度、亲和程度、抓取深度等，总访问次数、停留时间、抓取量越高、平均抓取页面、平均停留时间，表明网站页面越受搜索引擎喜欢。而单页抓取停留时间表明网站页面访问速度，时间越长，表明网站访问速度越慢，对搜索引擎抓取收录较不利，我们应尽量提高网页加载速度，减少单而立停留时间，让爬虫资源更多的去抓取收录。
通过日志分析我们可以看到网站哪些目录受蜘蛛喜欢、抓取目录深度、重要页面目录抓取状况、无效页面目录抓取状况等。对于重要目录，我们需要通过内外调整增加权重及爬取；对于无效页面，在robots.txt中进行屏蔽。
蜘蛛经常出现的状态码如301、404等，出现这些状态码要及时处理，以避免对网站造成坏的影响。
在网站日志中我们可以跟踪到特定IP的访问路径，则能发现对于本网站结构下蜘蛛的爬取路径偏好。由此，我们可以适当的引导蜘蛛的爬取路径，让蜘蛛更多的爬取重要、有价值、新更新页面。其中爬取路径中我们可以分析页面物理结构路径偏好以及url逻辑结构爬取偏好。
日志的存储和快速检索分析是企业中的一个关键问题。中小企业保存的日志记录会很快地增长到TB或PB级。这些数据在企业中会以各种不同的格式存储。
在当今的许多行业中，诞生了一大批健全的依从性需求。这方面的例子包括支付卡行业数据安全标准（PCI DSS）。它规定了非常具体的日志保存周期--1年。PCI DSS涉及到日志需求的内容我在《日志管理与分析（二）》中会涉及到。
内部和外部的风险驱动网络不同部分的保存周期。对企业来说，每个风险领域的时间长度以及日志的重要性可能有很大的不同。如果你的日志主要用于内部威胁调查，则需要较长的保存周期。因为事故常常是多年都未曾发现的。
防火墙、服务器、数据库、web代理服务，不仅基于需要，也基于典型日志体积及每个日志记录的大小和类型。各种设备或应用程序生成的日志体积有很大的不同，例如，主防火墙会生成大量的日志内容，因此为了满足此数据的长期保存需求，通常只存储30天的日志。然而，应该仔细评估某些企业的依从性需求以及主防火墙的关键程度，决定是否采用更长的保存周期。
日志存储选项包括硬盘、DVD、WORM、磁带、RDBMS、日志特定存储，以及基于云的存储。这方面的决策主要取决于价格、容量、访问速度，最重要的是以合理的周期得到正确日志记录的能力。
企业中的日志保存的时间和空间需求是压倒一切的第一需求。
4.1日志存储格式
我们的网络设备、应用程序以及操作系统产生多种不同的日志格式，在许多情况下，日志会被存储为基于文本、二进制或者压缩的格式。
4.1.1 基于文本的日志文件
基于文本的日志记录是目前最丰富的日志类型，这归功于生成这类日志时较低的系统成本，以及现有的许多计算机语言中包含了可以很轻松地生成基于文本日志的框架。许多流行的系统采用了基于文本的日志文件格式，因为这种格式有着许多的优点：
-
应用程序写入基于文本的日志文件，从CPU以及I/O资源来说代价很低。
-
文本格式是典型可读格式，可用常规文本工具（如grep和awk，都是各种lunix操作系统变种的固有工具）处理和查阅。
-
许多常见的基于文本的日志格式已经存在，例如syslog。使得运营和安全团队易于使用一种通用方法来集中化以及解析日志，创造一个更完善的日志管理系统。
扁平文本文件在许多方面上是一个扁平的无模式文件，可能遵循某种常见模式或自由格式。系统通常会创建一个新日志文件，并持续向其追加写入，直到磁盘空间不足或某个系统进程指示系统开始一个新日志文件并将当前文件存档。这种格式倾向于以时间先后排序，最早发生的事件位于文件开始处，最近发生的事件位于文件末尾。
许多系统采用的较常用格式之一是syslog格式。我们知道，许多服务器配置为使用syslog的514端口，通过用户数据报协议UDP或传输控制协议TCP发送自己的日志数据。通过syslog发送的日志在发送之前保存在磁盘上，具有非常简单的特殊格式。
使用扁平文本文件长期存储日志数据的显著优势之一是，可以使用大量工具来阅读和审核这种格式的数据。每个平台都有许多工具可以轻松访问和读取此类格式的文件。如果你在未来5、7或10年需要去阅读或审核数据，需要能够处理和关联事件记录的工具，这一点就变得非常重要。
企业在扁平文本文件上很快就会遇到的一个局限性是从扁平文本文件中快速查询、排序、检索关键元素。随着日志文件迅速增至GB、TB甚至PB级别，再使用传统的grep、awk和基于文本的搜索工具会让人失去耐心，变成一个极其耗时的过程。
索引文本文件是一种从日志文件中企业数据的方式，它使日志的关键元素能被快速查询。许多企业可能再企业成长和开始集中日志信息时，很快发现需要结构来生成报表，以及在超出保存周期时销毁日志数据，从而开始采用索引文本日志文件。索引文本文件具备扁平文本文件的许多优点，具备快速数据插入能力，并保持人类可读的数据格式。
/var/ossec/logs/alerts/2011
/var/ossec/logs/alerts/2011/jan
/var/ossec/logs/alerts/2011/feb
/var/ossec/logs/alerts/2011/mar
4.1.2 二进制文件
顾名思义，二进制日志文件是应用程序生成的极其可读日志文件，需要专有的工具或程序去阅读或处理他们，在各种环境中较常见的二进制日志文件的例子包括Micromoft Internet信息服务（IIS）日志以及windows事件日志。在使用大型主机或定制应用程序的许多环境下，日志文件也可能被编码为二进制或机器特定格式，如广义二进制编码的十进制交换码，在Intel和PC硬件平台需要工具去解码和阅读他们。
二进制日志文件的长期存储会给企业带来许多挑战，在存储和保存二进制日志文件的原生格式之前需要考虑的问题如下：
-
未来5、7甚至10年后阅读这些日志的工具的可用性。从现在开始的10年内，保留一台windows NT服务器来阅读遗留的iis6.0web服务器日志，并进行确证分析，几乎是不可能的。
-
二进制日志文件在磁盘空间利用上很高效，然而，无法进行很大的压缩。压缩的二进制文件的大小可能是原生文件的90%。相比之下，基于文本的文件压缩后可能仅占原文件的10%左右。与文本文件日志记录相比，二进制文件所需的存储空间会比较大。
Event_Type：用来设置数据的操作类型。如Query、Update。
Log_name：用来表明该事件保存的二进制日志文件名称
https://www.cnblogs.com/youzhongmin/p/9575167.html
4.1.3 压缩文件
大部分生成日志的系统一般会在日志增长到指定大小时，或者在每天、每周、每月配置的时间周期以及其他条件下开始一个新的日志文件。之前的日志文件通常会重命名，并以未压缩格式存档于系统硬盘中，以便使其易于访问和查询，随着日志文件的老化，某个日志文件与日常报告和日志审核任务的相关性越来越弱，但它对于符合依从性保存周期和执行取证仍然是关键。在许多情况下啊，我们依然期望日志文件能够快速访问，但是在磁盘上占用较小空间。在系统中压缩日志文件就是解决这种需求并节省宝贵磁盘空间的一种机制。
LINUX系统的许多标准工具都有等价的压缩工具集，zgrep和zcat工具可以从压缩文件中读取和检索数据，就像grep和cat在未压缩文件上所做的一样。在选择一个压缩格式时，为了避免陈旧过时，最好选择一种已经被使用很多年并在多个平台可用的格式，在linux中，tar和zip格式已经使用很长时间，而PKZip格式的压缩文件是windows中常见的压缩格式。就像二进制文件一样，我们应该避免未来用于解压和访问日志数据的工具集过时。
4.2日志文件的数据库存储
上面提到了几种存储技术需要直接访问系统和特定的日志审核工具集，这样做是很快速和高效的，但是在许多情况下，我们创建摘要报告、过滤器，以及在多台主机间关联日志数据的能力常常受到严重的限制。许多企业发现将日志信息写入数据库中，这样某种格式的日志信息可以快速搜索和查询，并且便于日志审核过程中前段工具的安装和使用。
使用数据库来实现日志保存主要的优点之一是易用性，你可以使用标准的SQL查询快速搜索和检索日志记录。数据库系统具有健全的用户访问和权限系统，而且可能已经是企业备份和恢复计划的一部分，现在有许多标准工具可以查询数据库，这些工具允许使用一个通用的工具集来查询日志数据，而不是使用需要专门知识和权限的平台特定工具。
将日志数据存入数据库系统并不能避免本身的一些问题和风险，向数据库中写日志消息会有显著的开销。向数据库中写数据明显比写入本地磁盘文本文件慢，主要是因为网络延迟、SQL解析、索引更新以及向磁盘提交信息。使用数据库存储日志对磁盘的空间需求也较高，主要是因为实现快速搜索和检索需要大量索引文件，压缩数据的选项也较为有限。数据库系统在一个企业中往往有多种用途，因此需要面临数据库故障、维护以及为支持日志记录或其他内部系统而升级时的数据丢失风险。当根据保存策略不再需要日志条目时、数据的销毁也会成为问题。若没有合适的规划或分区，删除日志数据可能花费相当长的时间。日志数据一般非常巨大，因此数据的销毁可能需要数据库系统删除数百万甚至数十亿行，并更新所有被删除数据的索引。
4.3 Hadoop日志存储
传统数据库作为日志数据系统面临各种挑战，包括对日志数据增长的可伸缩性和高峰活动时需要的存储和系统容量。与传统数据库系统相比，Hadoop是一个较新的替代方案。传统的数据库系统，利用具备快速SAN存储的高端硬件，支持大量的并发用户和请求，并满足数据存储需求。相比之下，Hadoop系统通常由运行着Linux的商业PC Intel硬件构成，集群的每个节点只有几个TB本地存储空间，且没有使用RAID。一个Hadoop集群由一系列从节点和最少一个主节点组成。这样的系统在需要增加空间和容量时，可以简单地向集群中添加新的节点。
Hadoop有传统数据库系统的很多优点，Hadoop不用在各个系统上使用平台特定的查询工具，就能对日志数据进行快速检索和搜索。Hadoop通过将搜索请求分布到集群各个节点，快速寻找、处理和检索结果，从而在数据尺寸增长时很好地实现了可伸缩性。Hadoop主要用java构建，可以开发工具、实现日志数据的实时查看和分析。Hadoop同样具备容错性，通过在集群节点间制作多个备份数据，当一个节点出现故障时，数据扔可以从其他节点检索。
Hadoop是一个强大的日志存储系统，但是同样存在许多可能影响企业的缺点。现有的许多日志记录工具对Hadoop的直接支持有限，Rsyslog已经添加了向Hadoop集群写入syslog消息的功能，但是对大部分其他日志源来说，依旧需要开发一个向Hadoop写入日志的工具。可以直接在Hadoop中查询和报告数据的工具集依旧非常有限。企业需要开发和维护定制的前端系统，以便进行实时分析和审核。
常识和各项法规制度迫使我们将工作的重点放在保护日志免于各种攻击上，其实还可以使用一种保护方法就是将日志文件和日志记录基础设施隐藏起来，使试图破坏的攻击者无法看到。加密、基于安全代理的日志收集以及完整性检查是有效的，在攻击者面前隐藏自己的日志记录和日志收集架构有一种独特的吸引力。多年实施“蜜罐”甚至整个蜜罐网络的经验告诉我们，大部分攻击者都没那么幸运，这种掩护下的基础设施是安全技术的一个罕见特例--防御者可能获得优势。
业务攻击者闯入linux或unix系统后，会首先结束syslog守护进程，阻止本地添加新增日志记录和向远程日志服务器传送日志。通过类似“killall syslogd”的命令执行。所以，在这个小公司网络中，系统管理员将编译了syslog守护进程的另一个拷贝，命名为”cachefd”并且用管理员主目录下的配置文件运行。该文件配置为将日志累计到一些非标准的目录下(例如/usr/src/kernel)。这样，能够有效地防止业余攻击者终止日志记录。这种方案取决于公司确实关注日志文件，并且有周期性的日志审核，或者具备准时的日志监控能力。
高级的安全专家可能会嘲笑这种“安全日志记录”，但是在“蜜罐”中观察到的业余攻击者的方法都没有超出结束syslog守护进程，并且从没有寻找其他日志记录机制。因此，以上的措施实际上100%有效。
5.1隐藏日志生成
隐藏日志生成提出了一个挑战，因为生成日志的程序非常可能存在于一个被入侵的信息资产上。通过包捕获采集的日志几乎都是隐藏的，但是生成日志这一环节很难隐蔽起来。
使用内核能力或linux专用可加载内核模块（LKM）来隐藏守护进程是众所周知的。本质上，当我们谈论日志记录的rootkit技术时，通常有两个额外的选择：
最后要注意一点，如果攻击者采用类似原理的rootkit，他仍然可能干扰我们对日志记录的隐藏。
如果我们运用上述技术，并留下默认的日志记录基础设施，让攻击者去杀死他，大部分攻击者都很可能不在进一步攻击，并认为没有其他的日志机制。
这只需要创建一个单独的syslog实例，并连接到基础设施，保留默认的实例，启用一些功能，使他不会干扰真正的日志记录。
人工阅读日志应该保留，用作地狱中的惩罚。在缺乏好的自动化工具时，人们总是不得不进行人工审核。
-
依从性和监管的要求
-
了解网络条件
-
基础设施ROI
-
安全度量
-
事故响应
6.1简单日志查看器
6.1.1 实时审核
在大部分unix和linux变种上，有多种工具能够辅助日志分析。有些在实时日志查看上有所帮助，而其他则有助于审核历史日志。
# tail -f/var/log/messages
上述命令将显示标准linux消息文件的最后几行，以及命令启动之后出现的新行。这是目前最简单的实时日志查看器，但是在大部分情况下没什么用处。如果你所需要的只是在系统日志记录出现时看到他们，这个命令就相当方便。
# tail -f/var/log/messages | grep sshd
为了进一步改进上述的实时日志查看，可以加入一个tee命令，它将帮助我们查看数据，并发送到一个文件：
# tail -f/var/log/messages | grep sshd | tee file-of-latest-sshd-logs.txt
上述命令显示日志行，并将其记录到”file-of-latest-sshd-logs.txt”文件。
Less可以使用这个命令的等待模式，完成同样的功能：
然后，按下F使less进入”tail”模式，显示最近和最新的数据。
在windows模式下，捆绑的事件查看器可以监控三种日志中新到的记录。
6.1.2历史日志审核
你所选择的平台上的任何文本编辑器都可以用于查看普通文本日志，但是有一点需要注意，有些日志文件非常大，不是所有文本编辑器都能够高效地处理它们。所以需要一个轻量级的工具，另外它还需要具备搜索和其他有用的功能。
在linux上，more和less工具通常符合上述要求。它们能够处理大文件（GB数量级），也有搜索功能。有时候，更多详细的帮助可以用info命令得到，如:
在windows上，唯一的捆绑工具是事件查看器，它能够阅读三种标准的windows日志（应用程序、系统和安全），等待新事件并显示，也可以进行过滤和排序。
Windows 7 事件查看器较为有趣的功能包括：
-
将单独的事件当做XML处理。
-
用事件订阅功能，在远程主机上订阅事件。
-
保存过滤器为自定义视图。
-
在应用程序日志中记录你的自定义事件。
-
运行一个任务，对事件作出相应。
6.1.3简单日志操纵
在Linux上用tail和less实时查看日志，并用许多文件查看器(cat、more或者less)查看存储的文件。
3）日志总结：查看紧凑的视图。
如上所述，tail和grep结合可以进行简单的过滤，grep还有助于在大的日志文件上进行更为高级的过滤：
# grep -ev ‘ssh|telnet’ /var/log/messages
# grep -f patterns /var/log/messages
查看匹配文件’patterns ’中模式的所有消息。
改进grep的其他命令还有tail和head。他们用于查看日志的开头部分和结束部分。
Log Parser和Log ParserLizard：筛查windows日志的最好手段
在windows上，事件查看器可以过滤、排序日志和将日志提取到文件中。在典型的windows系统上，过滤限于：
-
事件类型
-
事件分类
-
事件ID
-
源计算机
-
源应用程序或者系统组件名称
-
用户名称
-
为了进行windows日志的更高级分析，我们可以使用LogParser和Log Parser Lizard。Log Parser是一个MicrosoftWindows插件程序，为你提供一个类似Sql的Windows事件日志接口。LogParser本身就是一个命令行工具，在分析工作中难以使用，这就是Log Parser的用武之地。
6.1.4人工日志审核的局限性
到现在已经很明显，人工和使用简单的工具和命令进行的日志审核无疑在日志分析中占据一席之地。但是不应该依赖它作为日志分析的主要机制。
-
人工日志审核无法随着日志文件尺寸的增大而伸缩：我们查看了8行日志，但是现实的任务是查看800万行日志。在大规模的企业环境中，日志常常以每秒20000条记录的速度产生。在比这低得多的日志记录速度上，人工日志分析就已经无法继续且变得越来越低效。
-
人工日志审核只能用于简单的日志：告诉你具体的故障部位时，可以人工解读它，但是在日志来源较为模糊且没有文档时，这种方法必然失败。解读每一行的工作量将从一秒钟的快速思考变成几个小时的在线和其他来源研究。
-
简单的工具和人工审核可能无法获得计算环境中所发生情况的全貌，而更高级的工具能够从日志数据中还原这些情况。
-
除了令人困惑和模糊的格式之外，在许多情况下分析需要关联来自多个源的日志。这种活动确实可以人工进行，但是需要的时间将大大增加（与只查看一个日志文件相比）。这种关联最好留给自动工具完成。
-
最后，这种活动通常极其乏味。而且通常效率很低
可以看出，人工日志审核有明显的局限性，在日志管理与分析（二）会有关于日志分析工具。
