Journalctl查看并操作Systemd日志
内容简介
作为最具吸引力的优势,systemd拥有强大的处理与系统日志记录功能。在使用其它工具时,日志往往被分散在整套系统当中,由不同的守护进程及进程负责处理,这意味着我们很难跨越多种应用程序对其内容进行解读。
相比之下,systemd尝试提供一套集中化管理方案,从而统一打理全部内核及用户级进程的日志信息。这套系统能够收集并管理日志内容,而这也就是我们所熟知的journal。
Journal的实现归功于journald守护进程,其负责处理由内核、initrd以及服务等产生的信息。在今天的教程中,我们将探讨如何使用journalctl工具,并在其帮助下访问并操作journal内部的数据。
总体思路
Systemd journal的深层驱动力在于以集中方式管理对来自任意来源的日志信息。由于大部分引导进程都是由systemd进程处理的,因此我们有理由以标准化方式实现日志的收集与访问。其中jornald守护进程会收集全部来源的数据并将其以二进制格式加以存储,从而轻松实现动态操作。
这种作法能够实现多种收益。通过单一工具与数据交互,管理员能够以动态方式显示日志数据。另外,我们也可以轻松查看历史引导数据,或者将日志条目同其它相关服务加以结合,从而 完成通信问题调试。
将日志数据以二进制形式存储还意味着这些数据可根据需求随时以二进制输出格式显示。例如,大家可以通过标准syslog格式查看日志以实现日常管理,并在需要使用图形服务时将各条目作为JSON对象交由图形化服务处理。由于数据不会以纯文本形式被写入磁盘,因此我们无需进行任何格式转换。
大家可以将systemd journal与现有syslog方案配合使用,也可利用其替代现有syslog功能,具体取决于实际需求。尽管systemd journal足以涵盖大部分管理工作需求,但其同时也能够补充现有日志记录机制。例如,大家可以建立一套集中式syslog服务器,从而对来自多台服务器的数据进行编译;或者,我们也能够利用systemd journal将来自多项服务的日志汇总在单一系统当中。
设置系统时间
使用二进制journal的一大好处在于,它能够以UTC或者本地时间显示日志记录。在默认情况下,systemd会以本地时间显示结果。
有鉴于此,在我们开始使用journal之前,首先要确保时区得到正确设置。Systemd套件中还提供一款timedatectl工具,专门用于解决此类问题。
首先,利用list-timezones选项查看可用时区:
timedatectl list-timezones
结果将列出系统上可用的全部时区。而后选择与服务器所在地相匹配的项目,并使用set-timezone选项加以设置:
sudo timedatectl set-timezone zone
为了确保我们的设备使用正确的时间,可单独使用timedatectl命令或者添加status选项。显示结果如下:
timedatectl status
Local time: Thu 2015-02-05 14:08:06 EST
Universal time: Thu 2015-02-05 19:08:06 UTC
RTC time: Thu 2015-02-05 19:08:06
Time zone: America/New_York (EST, -0500)
NTP enabled: no
NTP synchronized: no
RTC in local TZ: no
DST active: n/a
第一行所示应为正确时间。
基础日志查看
要查看journald守护进程收集到的日志,可使用journalctl命令。
在单独使用时,系统中的每个journal条目都会被显示在单一pager中供我们浏览。条目时间越早,排列越靠前:
journalctl
-- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).
Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 8 users, 102 roles, 4976 types, 294 bools, 1 sens,
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 83 classes, 104131 rules
. . .
大家可以一页页进行翻看,不过如果系统运行时间较长,那么systemd中的日志也将成千上万,这也证明了journal数据库中可观的数据量。
其格式与标准的syslog日志非常相似。然而,其收集数据的来源较syslog要丰富得多。其中包含有来自先前引导进程、内核、initrd以及应用程序标准错误与输出的日志。这一切都可在journal中查看到。
大家可能还注意到,全部时间戳都以本地时间为准。由于已经为系统正确设置了本地时间,所以显示的时间戳也都准确无误。
如果大家希望以UTC显示时间戳,则可使用–utc标记:
journalctl --utc
按时间进行journal过滤
浏览大量数据当然有其作用,但信息量过于庞大则会让我们很难甚至根本不可能找到真正重要的内容。因此,journalctl提供了极为关键的过滤选项。
显示当前引导进程下的日志
其中最常用的就是-b标记了,其将显示全部最近一次重新引导后收集到的journal条目。
journalctl -b
通过这种方式,我们能够识别并管理源自当前环境下的信息。
如果不使用这项功能,而且显示的引导数量超过一天,那么journalctl会在在系统关闭处插入说明:
. . .
-- Reboot --
. . .
这种方式能够帮助我们有效区分来自不同引导会话的信息。
过往引导记录
大家通常只需要查看当前引导环境下的信息,但有时候查看过往引导记录也非常必要。Journal能够保存大量过往引导信息,从而允许journalctl轻松显示相关内容。
有些版本会在默认情况下保存过往引导信息,而有些则默认禁用这项功能。要启用此功能,可以使用以下功能以创建用于存储journal信息的目录:
- sudo mkdir -p /var/log/journal
或者直接编辑journal配置文件:
- sudo nano /etc/systemd/journald.conf
在[Journal]区段下将Storage=选项设定为“persistent”以启用持久记录:
/etc/systemd/journald.conf
. . .
[Journal]
Storage=persistent
当启用保存过往引导信息功能后,journalctl会提供额外命令以帮助大家将各引导记录作为独立单元操作。要查看Journald中已经记录的引导信息,可使用–list-boots选项:
journalctl --list-boots
-2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
-1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC
这里每次引导都将显示为一行。第一列可用于在journalctl中引用该次引导。如果大家需要更为准确的引用方式,则可在第二列中找到引导ID。末尾记录的两次时间为当次引导的开始与结束时间。
要显示这些引导中的具体信息,则可使用第一或者第二列提供的信息。
例如,要查看上次引导的journal记录,则可使用-1相对指针配合-b标记:
journalctl -b -1
另外,也可以使用引导ID:
journalctl -b caf0524a1d394ce0bdbcff75b94444fe
时间窗
按照引导环境查看日志条目当然非常重要,但我们往往还需要使用与系统引导无关的时间窗作为浏览基准。这种情况在长期运行的服务器当中较为常见。
大家可以利用–since与–until选项设定时间段,二者分别负责说明给定时间之前与之后的记录。
时间值可以多种格式输出。对于绝对时间值,大家可以使用以下格式:
YYYY-MM-DD HH:MM:SS
例如,我们可以通过以下命令查看全部2015年1月10日下午5:15之后的条目:
journalctl --since "2015-01-10 17:15:00"
如果以上格式中的某些组成部分未进行填写,系统会直接进行默认填充。例如,如果日期部分未填写,则会直接显示当前日期。如果时间部分未填写,则缺省使用“00:00:00”(午夜)。第二字段亦可留空,默认值为“00”:
journalctl --since "2015-01-10" --until "2015-01-11 03:00"
另外,journal还能够理解部分相对值及命名简写。例如,大家可以使用“yesterday”、“today”、“tomorrow”或者“now”等表达。另外,我们也可以使用“-”或者“+”设定相对值,或者使用“ago”之前的表达。
获取昨天数据的命令如下:
journalctl –since yesterday
要获得早9:00到一小时前这段时间内的报告,可使用以下命令:
journalctl --since 09:00 --until "1 hour ago"
如大家所见,时间窗的过滤机制非常灵活且易用。
按信息类型过滤
现在我们要探讨如何利用感兴趣的服务或者组件类型实现过滤。Systemd journal同样提供多种方式供大家选择。
按单元
最常用的此类过滤方式当数按单元过滤了。我们可以使用-u选项实现这一效果。
例如,要查看系统上全部来自Nginx单元的日志,可使用以下命令:
journalctl -u nginx.service
一般来讲,我们可能需要同时按单元与时间进行信息过滤。例如,检查今天某项服务的运行状态:
journalctl -u nginx.service --since today
我们还可以充分发挥journal查看多种单元信息的优势。例如,如果我们的Nginx进程接入某个PHP-FPM单元以处理动态内容,则可将这两个单元合并并获取按时间排序的查询结果:
journalctl -u nginx.service -u php-fpm.service --since today
这种能力对于不同程序间交互及系统调试显然非常重要。
按进程、用户或者群组ID
由于某些服务当中包含多个子进程,因此如果我们希望通过进程ID实现查询,也可以使用相关过滤机制。
这里需要指定_PID字段。例如,如果PID为8088,则可输入:
journalctl _PID=8088
有时候我们可能希望显示全部来自特定用户或者群组的日志条目,这就需要使用_UID或者_GID。例如,如果大家的Web服务器运行在www-data用户下,则可这样找到该用户ID:
id -u www-data
33
接下来,我们可以使用该ID返回过滤后的journal结果:
journalctl _UID=33 --since today
Systemd journal拥有多种可实现过滤功能的字段。其中一些来自被记录的进程,有些则由journald用于自系统中收集特定时间段内的日志。
之前提到的_PID属于后一种。Journal会自动记录并检索进程PID,以备日后过滤之用。大家可以查看当前全部可用journal字段:
man systemd.journal-fields
下面来看针对这些字段的过滤机制。-F选项可用于显示特定journal字段内的全部可用值。
例如,要查看systemd journal拥有条目的群组ID,可使用以下命令:
journalctl -F _GID
32
99
102
133
81
84
100
0
124
87
其将显示全部journal已经存储至群组ID字段内的值,并可用于未来的过滤需求。
按组件路径
我们也可以提供路径位置以实现过滤。
如果该路径指向某个可执行文件,则journalctl会显示与该可执行文件相关的全部条目。例如,要找到与bash可执行文件相关的条目:
journalctl /usr/bin/bash
一般来讲,如果某个单元可用于该可执行文件,那么此方法会更为明确且能够提供更好的相关信息(与子进程相关的条目等)。但有时候,这种作法则无法奏效。
显示内核信息
内核信息通常存在于dmesg输出结果中,journal同样可对其进行检索。要只显示此类信息,可添加-k或者–dmesg标记:
journalctl -k
默认情况下,其会显示当前引导环境下的全部内核信息。大家也可以使用常规的引导选择标记对此前的引导记录进行查询。例如,要查询五次之前引导环境的信息:
journalctl -k -b -5
按优先级
管理员们可能感兴趣的另一种过滤机制为信息优先级。尽管以更为详尽的方式查看日志也很有必要,不过在理解现有信息时,低优先级日志往往会分散我们的注意力并导致理解混乱。
大家可以使用journalctl配合-p选项显示特定优先级的信息,从而过滤掉优先级较低的信息。
例如,只显示错误级别或者更高的日志条目:
journalctl -p err -b
这将只显示被标记为错误、严重、警告或者紧急级别的信息。Journal的这种实现方式与标准syslog信息在级别上是一致的。大家可以使用优先级名称或者其相关量化值。以下各数字为由最高到最低优先级:
- 0: emerg
- 1: alert
- 2: crit
- 3: err
- 4: warning
- 5: notice
- 6: info
- 7: debug
以上为可在-p选项中使用的数字或者名称。选定某一优先级会显示等级与之等同以及更高的信息。
修改journal显示内容
到这里,过滤部分已经介绍完毕。我们也可以使用多种方式对输出结果进行修改,从而调整journalctl的显示内容。
截断或者扩大输出结果
我们可以缩小或者扩大输出结果,从而调整journalctl的显示方式。
在默认情况下,journalctl会在pager内显示各条目,并通过右箭头键访问其信息。
如果大家希望截断输出内容,向其中插入省略号以代表被移除的信息,则可使用–no-full选项:
journalctl --no-full
. . .
Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot
大家也可以要求其显示全部信息,无论其是否包含不可输出的字符。具体方式为添加-a标记:
journalctl -a
标准输出结果
默认情况下,journalctl会在pager内显示输出结果以便于查阅。如果大家希望利用文本操作工具对数据进行处理,则可能需要使用标准格式。在这种情况下,我们需要使用–no-pager选项:
journalclt --no-pager
这样相关结果即可根据需要被重新定向至磁盘上的文件或者处理工具当中。
输出格式
如果大家需要对journal条目进行处理,则可能需要使用更易使用的格式以简化数据解析工作。幸运的是,journal能够以多种格式进行显示,只须添加-o选项加格式说明即可。
例如,我们可以将journal条目输出为JSON格式:
journalctl -b -u nginx -o json
{ "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }
. . .
这种方式对于工具解析非常重要。大家也可以使用json-pretty格式以更好地处理数据结构:
journalctl -b -u nginx -o json-pretty
{
"__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
"__REALTIME_TIMESTAMP" : "1422990364739502",
"__MONOTONIC_TIMESTAMP" : "27200938",
"_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
"PRIORITY" : "6",
"_UID" : "0",
"_GID" : "0",
"_CAP_EFFECTIVE" : "3fffffffff",
"_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
"_HOSTNAME" : "desktop",
"SYSLOG_FACILITY" : "3",
"CODE_FILE" : "src/core/unit.c",
"CODE_LINE" : "1402",
"CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
"SYSLOG_IDENTIFIER" : "systemd",
"MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
"_TRANSPORT" : "journal",
"_PID" : "1",
"_COMM" : "systemd",
"_EXE" : "/usr/lib/systemd/systemd",
"_CMDLINE" : "/usr/lib/systemd/systemd",
"_SYSTEMD_CGROUP" : "/",
"UNIT" : "nginx.service",
"MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
"_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
}
. . .
以下为可用于显示的各类格式:
- cat: 只显示信息字段本身。
- export: 适合传输或备份的二进制格式。
- json: 标准JSON,每行一个条目。
- json-pretty: JSON格式,适合人类阅读习惯。
- json-sse: JSON格式,经过打包以兼容server-sent事件。
- short: 默认syslog类输出格式。
- short-iso: 默认格式,强调显示ISO 8601挂钟时间戳。
- short-monotonic: 默认格式,提供普通时间戳。
- short-precise: 默认格式,提供微秒级精度。
- verbose: 显示该条目的全部可用journal字段,包括通常被内部隐藏的字段。
这些选项允许大家以最适合需求的格式显示journal条目。
活动进程监控
Journalctl命令还能够帮助管理员以类似于tail的方式监控活动或近期进程。这项功能内置于journalctl当中,允许大家在无需借助其它工具的前提下实现访问。
显示近期日志
要显示特定数量的记录,大家可以使用-n选项,具体方式为tail -n。
默认情况下,其会显示最近十条记录:
journalctl -n
大家可以在-n之后指定要查看的条目数量:
journalctl -n 20
追踪日志
要主动追踪当前正在编写的日志,大家可以使用-f标记。方式同样为tail -f:
journalctl -f
Journal维护
存储这么多数据当然会带来巨大压力,因此我们还需要了解如何清理部分陈旧日志以释放存储空间。
了解现有磁盘使用量
大家可以利用–disk-usage标记查看journal的当前磁盘使用量:
journalctl --disk-usage
Journals take up 8.0M on disk.
删除旧有日志
如果大家打算对journal记录进行清理,则可使用两种不同方式(适用于systemd 218及更高版本)。
如果使用–vacuum-size选项,则可硬性指定日志的总体体积,意味着其会不断删除旧有记录直到所占容量符合要求:
sudo journalctl --vacuum-size=1G
另一种方式则是使用–vacuum-time选项。任何早于这一时间点的条目都将被删除。
例如,去年之后的条目才能保留:
sudo journalctl --vacuum-time=1years
限定Journal扩展
大家可以配置自己的服务器以限定journal所能占用的最高容量。要实现这一点,我们需要编辑/etc/systemd/journald.conf文件。
以下条目可用于限定journal体积的膨胀速度:
- SystemMaxUse=: 指定journal所能使用的最高持久存储容量。
- SystemKeepFree=: 指定journal在添加新条目时需要保留的剩余空间。
- SystemMaxFileSize=: 控制单一journal文件大小,符合要求方可被转为持久存储。
- RuntimeMaxUse=: 指定易失性存储中的最大可用磁盘容量(/run文件系统之内)。
- RuntimeKeepFree=: 指定向易失性存储内写入数据时为其它应用保留的空间量(/run文件系统之内)。
- RuntimeMaxFileSize=: 指定单一journal文件可占用的最大易失性存储容量(/run文件系统之内)。
通过设置上述值,大家可以控制journald对服务器空间的消耗及保留方式。
总结
到这里,systemd journal对系统及应用数据的收集与管理机制就介绍完毕了。其出色的灵活性源自将广泛的元数据自动记录至集中化日志之内。另外,journalctl命令则显著简化了journal的使用方式,从而让更多管理员得以利用它完成面向不同应用组件的分析与相关调试工作。
本文来源自DigitalOcean Community。英文原文:How To Use Journalctl to View and Manipulate Systemd Logs By Justin Ellingwood
Mysql之binlog日志说明及利用binlog日志恢复数据操作记录
众所周知,binlog日志对于mysql数据库来说是十分重要的。在数据丢失的紧急情况下,我们往往会想到用binlog日志功能进行数据恢复(定时全备份+binlog日志恢复增量数据部分),化险为夷!
废话不多说,下面是梳理的binlog日志操作解说:
一、初步了解binlog
MySQL的二进制日志binlog可以说是MySQL最重要的日志,它记录了所有的DDL和DML语句(除了数据查询语句select),以事件形式记录,还包含语句所执行的消耗的时间,MySQL的二进制日志是事务安全型的。
----------------------------------------------------------------------------------------------------------------------------------------------
DDL
----Data Definition Language 数据库定义语言
主要的命令有CREATE、ALTER、DROP等,DDL主要是用在定义或改变表(TABLE)的结构,数据类型,表之间的链接和约束等初始化工作上,他们大多在建立表时使用。
DML
----Data Manipulation Language 数据操纵语言
主要的命令是SELECT、UPDATE、INSERT、DELETE,就象它的名字一样,这4条命令是用来对数据库里的数据进行操作的语言
----------------------------------------------------------------------------------------------------------------------------------------------
mysqlbinlog常见的选项有以下几个:
--start-datetime:从二进制日志中读取指定等于时间戳或者晚于本地计算机的时间
--stop-datetime:从二进制日志中读取指定小于时间戳或者等于本地计算机的时间 取值和上述一样
--start-position:从二进制日志中读取指定position 事件位置作为开始。
--stop-position:从二进制日志中读取指定position 事件位置作为事件截至
*********************************************************************
一般来说开启binlog日志大概会有1%的性能损耗。
binlog日志有两个最重要的使用场景:
1)MySQL主从复制:MySQL Replication在Master端开启binlog,Master把它的二进制日志传递给slaves来达到
master-slave数据一致的目的。
2)自然就是数据恢复了,通过使用mysqlbinlog工具来使恢复数据。
binlog日志包括两类文件:
1)二进制日志索引文件(文件名后缀为.index)用于记录所有的二进制文件
2)二进制日志文件(文件名后缀为.00000*)记录数据库所有的DDL和DML(除了数据查询语句select)语句事件。
二、开启binlog日志:
1)编辑打开mysql配置文件/etc/mys.cnf
[root@vm-002 ~]# vim /etc/my.cnf
在[mysqld] 区块添加
log-bin=mysql-bin 确认是打开状态(mysql-bin 是日志的基本名或前缀名);
2)重启mysqld服务使配置生效
[root@vm-002 ~]# /etc/init.d/mysqld stop
[root@vm-002 ~]# /etc/init.d/mysqld restart
Stopping mysqld: [ OK ]
Starting mysqld: [ OK ]
3)查看binlog日志是否开启
mysql> show variables like 'log_%';
+---------------------------------+---------------------+
| Variable_name | Value |
+---------------------------------+---------------------+
| log_bin | ON |
| log_bin_trust_function_creators | OFF |
| log_bin_trust_routine_creators | OFF |
| log_error | /var/log/mysqld.log |
| log_output | FILE |
| log_queries_not_using_indexes | OFF |
| log_slave_updates | OFF |
| log_slow_queries | OFF |
| log_warnings | 1 |
+---------------------------------+---------------------+
9 rows in set (0.00 sec)
三、常用的binlog日志操作命令
1)查看所有binlog日志列表
mysql> show master logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 149 |
| mysql-bin.000002 | 4102 |
+------------------+-----------+
2 rows in set (0.00 sec)
2)查看master状态,即最后(最新)一个binlog日志的编号名称,及其最后一个操作事件pos结束点(Position)值
mysql> show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000002 | 4102 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
3)flush刷新log日志,自此刻开始产生一个新编号的binlog日志文件
mysql> flush logs;
Query OK, 0 rows affected (0.13 sec)
mysql> show master logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 149 |
| mysql-bin.000002 | 4145 |
| mysql-bin.000003 | 106 |
+------------------+-----------+
3 rows in set (0.00 sec)
注意:
每当mysqld服务重启时,会自动执行此命令,刷新binlog日志;在mysqldump备份数据时加 -F 选项也会刷新binlog日志;
4)重置(清空)所有binlog日志
mysql> reset master;
Query OK, 0 rows affected (0.12 sec)
mysql> show master logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 106 |
+------------------+-----------+
1 row in set (0.00 sec)
四、查看binlog日志内容,常用有两种方式:
1)使用mysqlbinlog自带查看命令法:
注意:
-->binlog是二进制文件,普通文件查看器cat、more、vim等都无法打开,必须使用自带的mysqlbinlog命令查看
-->binlog日志与数据库文件在同目录中
-->在MySQL5.5以下版本使用mysqlbinlog命令时如果报错,就加上 “--no-defaults”选项
查看mysql的数据存放目录,从下面结果可知是/var/lib//mysql
[root@vm-002 ~]# ps -ef|grep mysql
root 9791 1 0 21:18 pts/0 00:00:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --pid-file=/var/run/mysqld/mysqld.pid --basedir=/usr --user=mysql
mysql 9896 9791 0 21:18 pts/0 00:00:00 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
root 9916 9699 0 21:18 pts/0 00:00:00 mysql -px xxxx
root 9919 9715 0 21:23 pts/1 00:00:00 grep --color mysql
[root@vm-002 ~]# cd /var/lib/mysql/
[root@vm-002 mysql]# ls
ibdata1 ib_logfile0 ib_logfile1 mysql mysql-bin.000001 mysql-bin.000002 mysql-bin.index mysql.sock ops test
使用mysqlbinlog命令查看binlog日志内容,下面截取其中的一个片段分析:
[root@vm-002 mysql]# mysqlbinlog mysql-bin.000002
..............
# at 624
#160925 21:29:53 server id 1 end_log_pos 796 Query thread_id=3 exec_time=0 error_code=0
SET TIMESTAMP=1474810193/*!*/;
insert into member(`name`,`sex`,`age`,`classid`) values('wangshibo','m',27,'cls1'),('guohuihui','w',27,'cls2') #执行的sql语句
/*!*/;
# at 796
#160925 21:29:53 server id 1 end_log_pos 823 Xid = 17 #执行的时间
.............
解释:
server id 1 : 数据库主机的服务号;
end_log_pos 796: sql结束时的pos节点
thread_id=11: 线程号
2)上面这种办法读取出binlog日志的全文内容比较多,不容易分辨查看到pos点信息
下面介绍一种更为方便的查询命令:
命令格式:
mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];
参数解释:
IN 'log_name' :指定要查询的binlog文件名(不指定就是第一个binlog文件)
FROM pos :指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)
LIMIT [offset,] :偏移量(不指定就是0)
row_count :查询总条数(不指定就是所有行)
mysql> show master logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 125 |
| mysql-bin.000002 | 823 |
+------------------+-----------+
2 rows in set (0.00 sec)
mysql> show binlog events in 'mysql-bin.000002'\G;
*************************** 1. row ***************************
Log_name: mysql-bin.000002
Pos: 4
Event_type: Format_desc
Server_id: 1
End_log_pos: 106
Info: Server ver: 5.1.73-log, Binlog ver: 4
*************************** 2. row ***************************
Log_name: mysql-bin.000002
Pos: 106
Event_type: Query
Server_id: 1
End_log_pos: 188
Info: use `ops`; drop table customers
*************************** 3. row ***************************
Log_name: mysql-bin.000002
Pos: 188
Event_type: Query
Server_id: 1
End_log_pos: 529
Info: use `ops`; CREATE TABLE IF NOT EXISTS `member` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(16) NOT NULL,
`sex` enum('m','w') NOT NULL DEFAULT 'm',
`age` tinyint(3) unsigned NOT NULL,
`classid` char(6) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
*************************** 4. row ***************************
Log_name: mysql-bin.000002
Pos: 529
Event_type: Query
Server_id: 1
End_log_pos: 596
Info: BEGIN
*************************** 5. row ***************************
Log_name: mysql-bin.000002
Pos: 596
Event_type: Intvar
Server_id: 1
End_log_pos: 624
Info: INSERT_ID=1
*************************** 6. row ***************************
Log_name: mysql-bin.000002
Pos: 624
Event_type: Query
Server_id: 1
End_log_pos: 796
Info: use `ops`; insert into member(`name`,`sex`,`age`,`classid`) values('wangshibo','m',27,'cls1'),('guohuihui','w',27,'cls2')
*************************** 7. row ***************************
Log_name: mysql-bin.000002
Pos: 796
Event_type: Xid
Server_id: 1
End_log_pos: 823
Info: COMMIT /* xid=17 */
7 rows in set (0.00 sec)
ERROR:
No query specified
mysql>
上面这条语句可以将指定的binlog日志文件,分成有效事件行的方式返回,并可使用limit指定pos点的起始偏移,查询条数!
如下操作示例:
a)查询第一个(最早)的binlog日志:
mysql> show binlog events\G;
b)指定查询 mysql-bin.000002这个文件:
mysql> show binlog events in 'mysql-bin.000002'\G;
c)指定查询 mysql-bin.000002这个文件,从pos点:624开始查起:
mysql> show binlog events in 'mysql-bin.000002' from 624\G;
d)指定查询 mysql-bin.000002这个文件,从pos点:624开始查起,查询10条(即10条语句)
mysql> show binlog events in 'mysql-bin.000002' from 624 limit 10\G;
e)指定查询 mysql-bin.000002这个文件,从pos点:624开始查起,偏移2行(即中间跳过2个),查询10条
mysql> show binlog events in 'mysql-bin.000002' from 624 limit 2,10\G;
五、利用binlog日志恢复mysql数据
以下对ops库的member表进行操作
mysql> use ops;
mysql> CREATE TABLE IF NOT EXISTS `member` (
-> `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
-> `name` varchar(16) NOT NULL,
-> `sex` enum('m','w') NOT NULL DEFAULT 'm',
-> `age` tinyint(3) unsigned NOT NULL,
-> `classid` char(6) DEFAULT NULL,
-> PRIMARY KEY (`id`)
-> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.10 sec)
mysql> show tables;
+---------------+
| Tables_in_ops |
+---------------+
| member |
+---------------+
1 row in set (0.00 sec)
mysql> desc member;
+---------+---------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------+---------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| name | varchar(16) | NO | | NULL | |
| sex | enum('m','w') | NO | | m | |
| age | tinyint(3) unsigned | NO | | NULL | |
| classid | char(6) | YES | | NULL | |
+---------+---------------------+------+-----+---------+----------------+
5 rows in set (0.00 sec)
事先插入两条数据
mysql> insert into member(`name`,`sex`,`age`,`classid`) values('wangshibo','m',27,'cls1'),('guohuihui','w',27,'cls2');
Query OK, 2 rows affected (0.08 sec)
Records: 2 Duplicates: 0 Warnings: 0
mysql> select * from member;
+----+-----------+-----+-----+---------+
| id | name | sex | age | classid |
+----+-----------+-----+-----+---------+
| 1 | wangshibo | m | 27 | cls1 |
| 2 | guohuihui | w | 27 | cls2 |
+----+-----------+-----+-----+---------+
2 rows in set (0.00 sec)
下面开始进行场景模拟:
1)
ops库会在每天凌晨4点进行一次完全备份的定时计划任务,如下:
[root@vm-002 ~]# crontab -l
0 4 * * * /usr/bin/mysqldump -uroot -p -B -F -R -x --master-data=2 ops|gzip >/opt/backup/ops_$(date +%F).sql.gz
这里手动执行下,将ops数据库备份到/opt/backup/ops_$(date +%F).sql.gz文件中:
[root@vm-002 ~]# mysqldump -uroot -p -B -F -R -x --master-data=2 ops|gzip >/opt/backup/ops_$(date +%F).sql.gz
Enter password:
[root@vm-002 ~]# ls /opt/backup/
ops_2016-09-25.sql.gz
-----------------
参数说明:
-B:指定数据库
-F:刷新日志
-R:备份存储过程等
-x:锁表
--master-data:在备份语句里添加CHANGE MASTER语句以及binlog文件及位置点信息
-----------------
待到数据库备份完成,就不用担心数据丢失了,因为有完全备份数据在!!
由于上面在全备份的时候使用了-F选项,那么当数据备份操作刚开始的时候系统就会自动刷新log,这样就会自动产生
一个新的binlog日志,这个新的binlog日志就会用来记录备份之后的数据库“增删改”操作
查看一下:
mysql> show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 | 106 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
也就是说, mysql-bin.000003 是用来记录4:00之后对数据库的所有“增删改”操作。
2)
早上9点上班了,由于业务的需求会对数据库进行各种“增删改”操作。
比如:在ops库下member表内插入、修改了数据等等:
先是早上进行插入数据:
mysql> insert into ops.member(`name`,`sex`,`age`,`classid`) values('yiyi','w',20,'cls1'),('xiaoer','m',22,'cls3'),('zhangsan','w',21,'cls5'),('lisi','m',20,'cls4'),('wangwu','w',26,'cls6');
Query OK, 5 rows affected (0.08 sec)
Records: 5 Duplicates: 0 Warnings: 0
mysql> select * from member;
+----+-----------+-----+-----+---------+
| id | name | sex | age | classid |
+----+-----------+-----+-----+---------+
| 1 | wangshibo | m | 27 | cls1 |
| 2 | guohuihui | w | 27 | cls2 |
| 3 | yiyi | w | 20 | cls1 |
| 4 | xiaoer | m | 22 | cls3 |
| 5 | zhangsan | w | 21 | cls5 |
| 6 | lisi | m | 20 | cls4 |
| 7 | wangwu | w | 26 | cls6 |
+----+-----------+-----+-----+---------+
7 rows in set (0.00 sec)
3)
中午又执行了修改数据操作:
mysql> update ops.member set name='李四' where id=4;
Query OK, 1 row affected (0.07 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> update ops.member set name='小二' where id=2;
Query OK, 1 row affected (0.06 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> select * from member;
+----+-----------+-----+-----+---------+
| id | name | sex | age | classid |
+----+-----------+-----+-----+---------+
| 1 | wangshibo | m | 27 | cls1 |
| 2 | 小二 | w | 27 | cls2 |
| 3 | yiyi | w | 20 | cls1 |
| 4 | 李四 | m | 22 | cls3 |
| 5 | zhangsan | w | 21 | cls5 |
| 6 | lisi | m | 20 | cls4 |
| 7 | wangwu | w | 26 | cls6 |
+----+-----------+-----+-----+---------+
7 rows in set (0.00 sec)
4)
在下午18:00的时候,悲剧莫名其妙的出现了!
手贱执行了drop语句,直接删除了ops库!吓尿!
mysql> drop database ops;
Query OK, 1 row affected (0.02 sec)
5)
这种时候,一定不要慌张!!!
先仔细查看最后一个binlog日志,并记录下关键的pos点,到底是哪个pos点的操作导致了数据库的破坏(通常在最后几步);
先备份一下最后一个binlog日志文件:
[root@vm-002 ~]# cd /var/lib/mysql/
[root@vm-002 mysql]# cp -v mysql-bin.000003 /opt/backup/
`mysql-bin.000003' -> `/opt/backup/mysql-bin.000003'
[root@vm-002 mysql]# ls /opt/backup/
mysql-bin.000003 ops_2016-09-25.sql.gz
接着执行一次刷新日志索引操作,重新开始新的binlog日志记录文件。按理说mysql-bin.000003
这个文件不会再有后续写入了,因为便于我们分析原因及查找ops节点,以后所有数据库操作都会写入到下一个日志文件。
mysql> flush logs;
Query OK, 0 rows affected (0.13 sec)
mysql> show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000004 | 106 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
6)
读取binlog日志,分析问题。
读取binlog日志的方法上面已经说到。
方法一:使用mysqlbinlog读取binlog日志:
[root@vm-002 ~]# cd /var/lib/mysql/
[root@vm-002 mysql]# mysqlbinlog mysql-bin.000003
方法二:登录服务器,并查看(推荐此种方法)
mysql> show binlog events in 'mysql-bin.000003';
+------------------+-----+-------------+-----------+-------------+----------------------------------------------------------------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+------------------+-----+-------------+-----------+-------------+----------------------------------------------------------------------------------------------------------------------------+
| mysql-bin.000003 | 4 | Format_desc | 1 | 106 | Server ver: 5.1.73-log, Binlog ver: 4 |
| mysql-bin.000003 | 106 | Query | 1 | 173 | BEGIN |
| mysql-bin.000003 | 173 | Intvar | 1 | 201 | INSERT_ID=3 |
| mysql-bin.000003 | 201 | Query | 1 | 444 | use `ops`; insert into ops.member(`name`,`sex`,`age`,`gsan','w',21,'cls5'),('lisi','m',20,'cls4'),('wangwu','w',26,'cls6') |
| mysql-bin.000003 | 444 | Xid | 1 | 471 | COMMIT /* xid=66 */ |
| mysql-bin.000003 | 471 | Query | 1 | 538 | BEGIN |
| mysql-bin.000003 | 538 | Query | 1 | 646 | use `ops`; update ops.member set name='李四' where id= |
| mysql-bin.000003 | 646 | Xid | 1 | 673 | COMMIT /* xid=68 */ |
| mysql-bin.000003 | 673 | Query | 1 | 740 | BEGIN |
| mysql-bin.000003 | 740 | Query | 1 | 848 | use `ops`; update ops.member set name='小二' where id= |
| mysql-bin.000003 | 848 | Xid | 1 | 875 | COMMIT /* xid=69 */ |
| mysql-bin.000003 | 875 | Query | 1 | 954 | drop database ops |
| mysql-bin.000003 | 954 | Rotate | 1 | 997 | mysql-bin.000004;pos=4 |
+------------------+-----+-------------+-----------+-------------+----------------------------------------------------------------------------------------------------------------------------+
13 rows in set (0.00 sec)
或者:
mysql> show binlog events in 'mysql-bin.000003'\G;
.........
.........
*************************** 12. row ***************************
Log_name: mysql-bin.000003
Pos: 875
Event_type: Query
Server_id: 1
End_log_pos: 954
Info: drop database ops
*************************** 13. row ***************************
Log_name: mysql-bin.000003
Pos: 954
Event_type: Rotate
Server_id: 1
End_log_pos: 997
Info: mysql-bin.000004;pos=4
13 rows in set (0.00 sec)
通过分析,造成数据库破坏的pos点区间是介于 875--954 之间(这是按照日志区间的pos节点算的),只要恢复到875前就可。
7)
先把凌晨4点全备份的数据恢复:
[root@vm-002 ~]# cd /opt/backup/
[root@vm-002 backup]# ls
mysql-bin.000003 ops_2016-09-25.sql.gz
[root@vm-002 backup]# gzip -d ops_2016-09-25.sql.gz
[root@vm-002 backup]# mysql -uroot -p -v < ops_2016-09-25.sql
Enter password:
--------------
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */
--------------
--------------
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */
--------------
.............
.............
--------------
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */
--------------
这样就恢复了截至当日凌晨(4:00)前的备份数据都恢复了。
mysql> show databases; #发现ops库已经恢复回来了
mysql> use ops;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+---------------+
| Tables_in_ops |
+---------------+
| member |
+---------------+
1 row in set (0.00 sec)
mysql> select * from member;
+----+-----------+-----+-----+---------+
| id | name | sex | age | classid |
+----+-----------+-----+-----+---------+
| 1 | wangshibo | m | 27 | cls1 |
| 2 | guohuihui | w | 27 | cls2 |
+----+-----------+-----+-----+---------+
2 rows in set (0.00 sec)
mysql>
但是这仅仅只是恢复了当天凌晨4点之前的数据,在4:00--18:00之间的数据还没有恢复回来!!
怎么办呢?
莫慌!这可以根据前面提到的mysql-bin.000003的新binlog日志进行恢复。
8)
从binlog日志恢复数据
恢复命令的语法格式:
mysqlbinlog mysql-bin.0000xx | mysql -u用户名 -p密码 数据库名
--------------------------------------------------------
常用参数选项解释:
--start-position=875 起始pos点
--stop-position=954 结束pos点
--start-datetime="2016-9-25 22:01:08" 起始时间点
--stop-datetime="2019-9-25 22:09:46" 结束时间点
--database=zyyshop 指定只恢复zyyshop数据库(一台主机上往往有多个数据库,只限本地log日志)
--------------------------------------------------------
不常用选项:
-u --user=name 连接到远程主机的用户名
-p --password[=name] 连接到远程主机的密码
-h --host=name 从远程主机上获取binlog日志
--read-from-remote-server 从某个MySQL服务器上读取binlog日志
--------------------------------------------------------
小结:实际是将读出的binlog日志内容,通过管道符传递给mysql命令。这些命令、文件尽量写成绝对路径;
a)完全恢复(需要手动vim编辑mysql-bin.000003,将那条drop语句剔除掉)
[root@vm-002 backup]# /usr/bin/mysqlbinlog /var/lib/mysql/mysql-bin.000003 | /usr/bin/mysql -uroot -p123456 -v ops
b)指定pos结束点恢复(部分恢复):
--stop-position=471 pos结束节点(按照事务区间算,是471)
注意:
此pos结束节点介于“member表原始数据”与更新“name='李四'”之前的数据,这样就可以恢复到更改“name='李四'”之前的数据了。
操作如下:
[root@vm-002 ~]# /usr/bin/mysqlbinlog --stop-position=471 --database=ops /var/lib/mysql/mysql-bin.000003 | /usr/bin/mysql -uroot -p123456 -v ops
mysql> select * from member;
+----+-----------+-----+-----+---------+
| id | name | sex | age | classid |
+----+-----------+-----+-----+---------+
| 1 | wangshibo | m | 27 | cls1 |
| 2 | guohuihui | w | 27 | cls2 |
| 3 | yiyi | w | 20 | cls1 |
| 4 | xiaoer | m | 22 | cls3 |
| 5 | zhangsan | w | 21 | cls5 |
| 6 | lisi | m | 20 | cls4 |
| 7 | wangwu | w | 26 | cls6 |
+----+-----------+-----+-----+---------+
7 rows in set (0.00 sec)
恢复截止到更改“name='李四'”之间的数据(按照事务区间算,是673)
[root@vm-002 ~]# /usr/bin/mysqlbinlog --stop-position=673 --database=ops /var/lib/mysql/mysql-bin.000003 | /usr/bin/mysql -uroot -p123456 -v ops
mysql> select * from member;
+----+-----------+-----+-----+---------+
| id | name | sex | age | classid |
+----+-----------+-----+-----+---------+
| 1 | wangshibo | m | 27 | cls1 |
| 2 | guohuihui | w | 27 | cls2 |
| 3 | yiyi | w | 20 | cls1 |
| 4 | 李四 | m | 22 | cls3 |
| 5 | zhangsan | w | 21 | cls5 |
| 6 | lisi | m | 20 | cls4 |
| 7 | wangwu | w | 26 | cls6 |
+----+-----------+-----+-----+---------+
7 rows in set (0.00 sec)
c)指定pso点区间恢复(部分恢复):
更新 name='李四' 这条数据,日志区间是Pos[538] --> End_log_pos[646],按事务区间是:Pos[471] --> End_log_pos[673]
更新 name='小二' 这条数据,日志区间是Pos[740] --> End_log_pos[848],按事务区间是:Pos[673] --> End_log_pos[875]
c1)
单独恢复 name='李四' 这步操作,可这样:
按照binlog日志区间单独恢复:
[root@vm-002 ~]# /usr/bin/mysqlbinlog --start-position=538 --stop-position=646 --database=ops /var/lib/mysql/mysql-bin.000003 | /usr/bin/mysql -uroot -p123456 -v ops
按照事务区间单独恢复
[root@vm-002 ~]# /usr/bin/mysqlbinlog --start-position=471 --stop-position=673 --database=ops /var/lib/mysql/mysql-bin.000003 | /usr/bin/mysql -uroot -p123456 -v ops
c2)
单独恢复 name='小二' 这步操作,可这样:
按照binlog日志区间单独恢复:
[root@vm-002 ~]# /usr/bin/mysqlbinlog --start-position=740 --stop-position=848 --database=ops /var/lib/mysql/mysql-bin.000003 | /usr/bin/mysql -uroot -p123456 -v ops
按照事务区间单独恢复
[root@vm-002 ~]# /usr/bin/mysqlbinlog --start-position=673 --stop-position=875 --database=ops /var/lib/mysql/mysql-bin.000003 | /usr/bin/mysql -uroot -p123456 -v ops
c3)
将 name='李四'、name='小二' 多步操作一起恢复,需要按事务区间,可这样:
[root@vm-002 ~]# /usr/bin/mysqlbinlog --start-position=471 --stop-position=875 --database=ops /var/lib/mysql/mysql-bin.000003 | /usr/bin/mysql -uroot -p123456 -v ops
查看数据库:
mysql> select * from member;
+----+-----------+-----+-----+---------+
| id | name | sex | age | classid |
+----+-----------+-----+-----+---------+
| 1 | wangshibo | m | 27 | cls1 |
| 2 | 小二 | w | 27 | cls2 |
| 3 | yiyi | w | 20 | cls1 |
| 4 | 李四 | m | 22 | cls3 |
| 5 | zhangsan | w | 21 | cls5 |
| 6 | lisi | m | 20 | cls4 |
| 7 | wangwu | w | 26 | cls6 |
+----+-----------+-----+-----+---------+
7 rows in set (0.00 sec)
这样,就恢复了删除前的数据状态了!!
-----------------
另外:
也可指定时间节点区间恢复(部分恢复):
除了用pos节点的办法进行恢复,也可以通过指定时间节点区间进行恢复,按时间恢复需要用mysqlbinlog命令读取binlog日志内容,找时间节点。
如上,误删除ops库后:
先进行全备份恢复
[root@vm-002 backup]# mysql -uroot -p -v < ops_2016-09-25.sql
查看ops数据库
mysql> select * from member;
+----+-----------+-----+-----+---------+
| id | name | sex | age | classid |
+----+-----------+-----+-----+---------+
| 1 | wangshibo | m | 27 | cls1 |
| 2 | guohuihui | w | 27 | cls2 |
+----+-----------+-----+-----+---------+
2 rows in set (0.00 sec)
mysql>
查看mysq-bin00003日志,找出时间节点
[root@vm-002 ~]# cd /var/lib/mysql
[root@vm-002 mysql]# mysqlbinlog mysql-bin.000003
.............
.............
BEGIN
/*!*/;
# at 173
#160925 21:57:19 server id 1 end_log_pos 201 Intvar
SET INSERT_ID=3/*!*/;
# at 201
#160925 21:57:19 server id 1 end_log_pos 444 Query thread_id=3 exec_time=0 error_code=0
use `ops`/*!*/;
SET TIMESTAMP=1474811839/*!*/;
insert into ops.member(`name`,`sex`,`age`,`classid`) values('yiyi','w',20,'cls1'),('xiaoer','m',22,'cls3'),('zhangsan','w',21,'cls5'),('lisi','m',20,'cls4'),('wangwu','w',26,'cls6') #执行的sql语句
/*!*/;
# at 444
#160925 21:57:19 server id 1 end_log_pos 471 Xid = 66 #开始执行的时间
COMMIT/*!*/;
# at 471
#160925 21:58:41 server id 1 end_log_pos 538 Query thread_id=3 exec_time=0 error_code=0 #结束时间
SET TIMESTAMP=1474811921/*!*/;
BEGIN
/*!*/;
# at 538
#160925 21:58:41 server id 1 end_log_pos 646 Query thread_id=3 exec_time=0 error_code=0
SET TIMESTAMP=1474811921/*!*/;
update ops.member set name='李四' where id=4 #执行的sql语句
/*!*/;
# at 646
#160925 21:58:41 server id 1 end_log_pos 673 Xid = 68 #开始执行的时间
COMMIT/*!*/;
# at 673
#160925 21:58:56 server id 1 end_log_pos 740 Query thread_id=3 exec_time=0 error_code=0 #结束时间
SET TIMESTAMP=1474811936/*!*/;
BEGIN
/*!*/;
# at 740
#160925 21:58:56 server id 1 end_log_pos 848 Query thread_id=3 exec_time=0 error_code=0
SET TIMESTAMP=1474811936/*!*/;
update ops.member set name='小二' where id=2 #执行的sql语句
/*!*/;
# at 848
#160925 21:58:56 server id 1 end_log_pos 875 Xid = 69 #开始执行的时间
COMMIT/*!*/;
# at 875
#160925 22:01:08 server id 1 end_log_pos 954 Query thread_id=3 exec_time=0 error_code=0 #结束时间
SET TIMESTAMP=1474812068/*!*/;
drop database ops
/*!*/;
# at 954
#160925 22:09:46 server id 1 end_log_pos 997 Rotate to mysql-bin.000004 pos: 4
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
恢复到更改“name='李四'”之前的数据
[root@vm-002 ~]# /usr/bin/mysqlbinlog --start-datetime="2016-09-25 21:57:19" --stop-datetime="2016-09-25 21:58:41" --database=ops /var/lib/mysql/mysql-bin.000003 | /usr/bin/mysql -uroot -p123456 -v ops
mysql> select * from member;
+----+-----------+-----+-----+---------+
| id | name | sex | age | classid |
+----+-----------+-----+-----+---------+
| 1 | wangshibo | m | 27 | cls1 |
| 2 | guohuihui | w | 27 | cls2 |
| 3 | yiyi | w | 20 | cls1 |
| 4 | xiaoer | m | 22 | cls3 |
| 5 | zhangsan | w | 21 | cls5 |
| 6 | lisi | m | 20 | cls4 |
| 7 | wangwu | w | 26 | cls6 |
+----+-----------+-----+-----+---------+
7 rows in set (0.00 sec)
[root@vm-002 ~]# /usr/bin/mysqlbinlog --start-datetime="2016-09-25 21:58:41" --stop-datetime="2016-09-25 21:58:56" --database=ops /var/lib/mysql/mysql-bin.000003 | /usr/bin/mysql -uroot -p123456 -v ops
mysql> select * from member;
+----+-----------+-----+-----+---------+
| id | name | sex | age | classid |
+----+-----------+-----+-----+---------+
| 1 | wangshibo | m | 27 | cls1 |
| 2 | guohuihui | w | 27 | cls2 |
| 3 | yiyi | w | 20 | cls1 |
| 4 | 李四 | m | 22 | cls3 |
| 5 | zhangsan | w | 21 | cls5 |
| 6 | lisi | m | 20 | cls4 |
| 7 | wangwu | w | 26 | cls6 |
+----+-----------+-----+-----+---------+
7 rows in set (0.00 sec)
[root@vm-002 ~]# /usr/bin/mysqlbinlog --start-datetime="2016-09-25 21:58:56" --stop-datetime="2016-09-25 22:01:08" --database=ops /var/lib/mysql/mysql-bin.000003 | /usr/bin/mysql -uroot -p123456 -v ops
mysql> select * from member;
+----+-----------+-----+-----+---------+
| id | name | sex | age | classid |
+----+-----------+-----+-----+---------+
| 1 | wangshibo | m | 27 | cls1 |
| 2 | 小二 | w | 27 | cls2 |
| 3 | yiyi | w | 20 | cls1 |
| 4 | 李四 | m | 22 | cls3 |
| 5 | zhangsan | w | 21 | cls5 |
| 6 | lisi | m | 20 | cls4 |
| 7 | wangwu | w | 26 | cls6 |
+----+-----------+-----+-----+---------+
7 rows in set (0.00 sec)
这样,就恢复了删除前的状态了!
总结:
所谓恢复,就是让mysql将保存在binlog日志中指定段落区间的sql语句逐个重新执行一次而已。
Apache日志配置
有时候我们需要定制Apache 默认日志的格式和内容,比如增加或减少日志所记录的信息、改变默认日志文件的格式等。本文介绍可以用日志记录的所有信息,以及如何设置Apache 使其记录这些信息。
一、定义日志格式(4月3日)
很久以前,日志文件只有一种格式,这就是“公共格式”,许多人已经习惯于使用这种格式。随后出现了定制日志格式,而且看起来定制日志格式更很受欢迎,即使 公共日志格式本身也重新用定制日志格式定义。本文介绍的就是如何随心所欲地定制日志文件的格式、如何让日志文件记录自己想要的信息。
定制日志文件的格式涉及到两个指令,即LogFormat指令和CustomLog指令,默认httpd.conf文件提供了关于这两个指令的几个示例。
LogFormat指令定义格式并为格式指定一个名字,以后我们就可以直接引用这个名字。CustomLog指令设置日志文件,并指明日志文件所用的格式 (通常通过格式的名字)。
LogFormat指令的功能是定义日志格式并为它指定一个名字。例如,在默认的httpd.conf文件中,我们可以找到下面这行代码:
LogFormat "%h %l %u %t /"%r/" %>s %b" common
该指令创建了一种名为“common”的日志格式,日志的格式在双引号包围的内容中指定。格式字符串中的每一个变量代表着一项特定的信息,这些信息按照格 式串规定的次序写入到日志文件。
Apache 文档已经给出了所有可用于格式串的变量及其含义,下面是其译文:
%...a: 远程IP地址
%...A: 本地IP地址
%...B: 已发送的字节数,不包含HTTP头
%...b: CLF格式的已发送字节数量,不包含HTTP头。例如当没有发送数据时,写入‘-’而不是0。
%...{FOOBAR}e: 环境变量FOOBAR的内容
%...f: 文件名字
%...h: 远程主机
%...H 请求的协议
%...{Foobar}i: Foobar的内容,发送给服务器的请求的标头行。
%...l: 远程登录名字(来自identd,如提供的话)
%...m 请求的方法
%...{Foobar}n: 来自另外一个模块的注解“Foobar”的内容
%...{Foobar}o: Foobar的内容,应答的标头行
%...p: 服务器响应请求时使用的端口
%...P: 响应请求的子进程ID。
%...q 查询字符串(如果存在查询字符串,则包含“?”后面的部分;否则,它是一个空字符串。)
%...r: 请求的第一行
%...s: 状态。对于进行内部重定向的请求,这是指*原来*请求 的状态。如果用%...>s,则是指后来的请求。
%...t: 以公共日志时间格式表示的时间(或称为标准英文格式)
%...{format}t: 以指定格式format表示的时间
%...T: 为响应请求而耗费的时间,以秒计
%...u: 远程用户(来自auth;如果返回状态(%s)是401则可能是伪造的)
%...U: 用户所请求的URL路径
%...v: 响应请求的服务器的ServerName
%...V: 依照UseCanonicalName设置得到的服务器名字
在所有上面列出的变量中,“...”表示一个可选的条件。如果没有指定条件,则变量的值将以“-”取代。分析前面来自默认httpd.conf文件的 LogFormat指令示例,可以看出它创建了一种名为“common”的日志格式,其中包括:远程主机,远程登录名字,远程用户,请求时间,请求的第一 行代码,请求状态,以及发送的字节数。
有时候我们只想在日志中记录某些特定的、已定义的信息,这时就要用到“...”。如果在“%”和变量之间放入了一个或者多个HTTP状态代码,则只有当请 求返回的状态代码属于指定的状态代码之一时,变量所代表的内容才会被记录。例如,如果我们想要记录的是网站的所有无效链接,那么可以使用:
LogFormat %404{Referer}i BrokenLinks
反之,如果我们想要记录那些状态代码不等于指定值的请求,只需加入一个“!”符号即可:
Apache 日志:访问日志(一)
想要知道什么人在什么时候浏览了网站的哪些内容吗?查看Apache 的访问日志就可以知道。访问日志是Apache 的标准日志,本文详细解释了访问日志的内容以及相关选项的配置。
一、访问日志的格式
Apache 内建了记录服务器活动的功能,这就是它的日志功能。这个《Apache 日志》系列文章介绍的就是Apache 的访问日志、错误日志,以及如何分析日志数据,如何定制Apache 日志,如何从日志数据生成统计报表等内容。
如果Apache 的安装方式是默认安装,服务器一运行就会有两个日志文件生成。这两个文件是access_log(在Windows上是access.log)和 error_log(在Windows上是error.log)。采用默认安装方式时,这些文件可以在/usr/local/apache /logs下找到;对于Windows系统,这些日志文件将保存在Apache 安装目录的logs子目录。不同的包管理器会把日志文件放到各种不同的位置,所以你可能需要找找其他的地方,或者通过配置文件查看这些日志文件配置到了什 么地方。
正如其名字所示,访问日志access_log记录了所有对Web服务器的访问活动。下面是访问日志中一个典型的记录:
216.35.116.91 - - [19/Aug/2000:14:47:37 -0400] "GET / HTTP/1.0" 200 654
这行内容由7项构成,上面的例子中有两项空白,但整行内容仍旧分成了7项。
第一项信息是远程主机的地址,即它表明访问网站的究竟是谁。在上面的例子中,访问网站的主机是216.35.116.91。随便说一句,这个地址属于一台 名为si3001.inktomi.com的机器(要找出这个信息,可以使用nslookup工具查找DNS),inktomi.com是一家制作Web 搜索软件的公司。可以看出,仅仅从日志记录的第一项出发,我们就可以得到有关访问者的不少信息。
默认情况下,第一项信息只是远程主机的IP地址,但我们可以要求Apache 查出所有的主机名字,并在日志文件中用主机名字来替代IP地址。然而,这种做法通常不值得推荐,因为它将极大地影响服务器记录日志的速度,从而也就减低了 整个网站的效率。另外,有许多工具能够将日志文件中的IP地址转换成主机名字,因此要求Apache 记录主机名字替代IP地址是得不偿失的。
然而,如果确实有必要让Apache 找出远程主机的名字,那么我们可以使用如下指令:
HostNameLookups on
如果HostNameLookups设置成double而不是on,日志记录程序将对它找到的主机名字进行反向查找,验证该主机名字确实指向了原来出现的 IP地址。默认情况下HostNameLookups设置为off。
上例日志记录中的第二项是空白,用一个“-”占位符替代。实际上绝大多数时候这一项都是如此。这个位置用于记录浏览者的标识,这不只是浏览者的登录名字, 而是浏览者的email地址或者其他唯一标识符。这个信息由identd返回,或者直接由浏览器返回。很早的时候,那时Netscape 0.9还占据着统治地位,这个位置往往记录着浏览者的email地址。然而,由于有人用它来收集邮件地址和发送垃圾邮件,所以它未能保留多久,很久之前市 场上几乎所有的浏览器就取消了这项功能。因此,到了今天,我们在日志记录的第二项看到email地址的机会已经微乎其微了。
日志记录的第三项也是空白。这个位置用于记录浏览者进行身份验证时提供的名字。当然,如果网站的某些内容要求用户进行身份验证,那么这项信息是不会空白 的。但是,对于大多数网站来说,日志文件的大多数记录中这一项仍旧是空白的。
日志记录的第四项是请求的时间。这个信息用方括号包围,而且采用所谓的“公共日志格式”或“标准英文格式”。因此,上例日志记录表示请求的时间是2000 年8月19日星期三14:47:37。时间信息最后的“-0400”表示服务器所处时区位于UTC之前的4小时。
日志记录的第五项信息或许是整个日志记录中最有用的信息,它告诉我们服务器收到的是一个什么样的请求。该项信息的典型格式是“METHOD RESOURCE PROTOCOL”,即“方法 资源 协议”。
在上例中,METHOD是GET,其他经常可能出现的METHOD还有POST和HEAD。此外还有不少可能出现的合法METHOD,但主要就是这三种。
RESOURCE是指浏览者向服务器请求的文档,或URL。在这个例子中,浏览者请求的是“/”,即网站的主页或根。大多数情况下,“/”指向 DocumentRoot目录的index.html文档,但根据服务器配置的不同它也可能指向其他文件。
PROTOCOL通常是HTTP,后面再加上版本号。版本号或者是1.0,或者是1.1,但出现1.0的时候比较多。我们知道,HTTP协议是Web得以 工作的基础,HTTP/1.0是HTTP协议的早期版本,而1.1是最近的版本。当前大多数Web客户程序仍使用1.0版本的HTTP协议。
日志记录的第六项信息是状态代码。它告诉我们请求是否成功,或者遇到了什么样的错误。大多数时候,这项值是200,它表示服务器已经成功地响应浏览器的请 求,一切正常。此处不准备给出状态代码的完整清单以及解释它们的含义,请参考相关资料了解这方面的信息。但一般地说,以2开头的状态代码表示成功,以3开 头的状态代码表示由于各种不同的原因用户请求被重定向到了其他位置,以4开头的状态代码表示客户端存在某种错误,以5开头的状态代码表示服务器遇到了某个 错误。
日志记录的第七项表示发送给客户端的总字节数。它告诉我们传输是否被打断(即,该数值是否和文件的大小相同)。把日志记录中的这些值加起来就可以得知服务 器在一天、一周或者一月内发送了多少数据。
二、配置访问日志
访问日志文件的位置实际上是一个配置选项。如果我们检查httpd.conf配置文件,可以看到该文件中有如下这行内容:
CustomLog /usr/local/apache /logs/access_log common
注意,对于版本较早的Apache 服务器,这行内容可能略有不同。它使用的可能不是CustomLog指令,而是TransferLog指令。如果你的服务器属于这类情况,建议你尽可能地 早日升级服务器。
CustomLog指令指定了保存日志文件的具体位置以及日志的格式。至于如何定制日志文件的格式以及内容,我们将在这个《Apache日志》系列文章的后面几篇讨论。上面这行指令指定的是common日志格式,自从有了Web服务器开始,common格式就是它的标准格式。由此我们也可 以理解,虽然几乎不再有任何客户程序向服务器提供用户的标识信息,但访问日志却还保留着第二项内容。
CustomLog指令中的路径是日志文件的路径。注意,由于日志文件是由HTTP用户打开的(用User指令指定),因此必须注意这个路径要有安全保 证,防止该文件被随意改写。
《Apache 日志》系列文章的后面几篇将继续介绍:Apache 错误日志,定制日志的格式和内容,如何将日志内容写入指定的程序而不是文件,如何从日志文件获得一些非常有用的统计信息,等等。
Apache 日志:访问日志(二)
3. 进程统计
UNIX可以跟踪每个用户运行的每条命令,如果想知道昨晚弄乱了哪些重要的文件,进程统计子系统可以告诉 你。它对还跟踪一个侵入者有帮助。与连接时间日志不同,进程统计子系统缺省不激活,它必须启动。在Linux系统中启动进程统计使用accton命令,必 须用root身份来运行。Accton命令的形式accton file,file必须先存在。先使用touch命令来创建pacct文件:touch /var/log/pacct,然后运行accton: accton /var/log/pacct。一旦accton被激活,就可以使用lastcomm命令监测系统中任何时候执行的命令。若要关闭统计,可以使用不带任何 参数的accton命令。
lastcomm命令报告以前执行的文件。不带参数时,lastcomm命令显示当前统计文件生命周期内纪录的所有命令的有关信息。包括命令名、用 户、tty、命令花费的CPU时间和一个时间戳。如果系统有许多用户,输入则可能很长。下面的例子:
crond F root ?? 0.00 secs Sun Aug 20 00:16
promisc_check.s S root ?? 0.04 secs Sun Aug 20 00:16
promisc_check root ?? 0.01 secs Sun Aug 20 00:16
grep root ?? 0.02 secs Sun Aug 20 00:16
tail root ?? 0.01 secs Sun Aug 20 00:16
sh root ?? 0.01 secs Sun Aug 20 00:15
ping S root ?? 0.01 secs Sun Aug 20 00:15
ping6.pl F root ?? 0.01 secs Sun Aug 20 00:15
sh root ?? 0.01 secs Sun Aug 20 00:15
ping S root ?? 0.02 secs Sun Aug 20 00:15
ping6.pl F root ?? 0.02 secs Sun Aug 20 00:15
sh root ?? 0.02 secs Sun Aug 20 00:15
ping S root ?? 0.00 secs Sun Aug 20 00:15
ping6.pl F root ?? 0.01 secs Sun Aug 20 00:15
sh root ?? 0.01 secs Sun Aug 20 00:15
ping S root ?? 0.01 secs Sun Aug 20 00:15
sh root ?? 0.02 secs Sun Aug 20 00:15
ping S root ?? 1.34 secs Sun Aug 20 00:15
locate root ttyp0 1.34 secs Sun Aug 20 00:15
accton S root ttyp0 0.00 secs Sun Aug 20 00:15
进程统计的一个问题是pacct文件可能增长的十分迅速。这时需要交互式的或经过cron机制运行sa命令来保持日志数据在系统控制内。sa命令报告、 清理并维护进程统计文件。它能把/var/log/pacct中的信息压缩到摘要文件/var/log/savacct和/var/log /usracct中。这些摘要包含按命令名和用户名分类的系统统计数据。sa缺省情况下先读它们,然后读pacct文件,使报告能包含所有的可用信息。 sa的输出有下面一些标记项:
avio--每次执行的平均I/O操作次数
cp--用户和系统时间总和,以分钟计
cpu--和cp一样
k--内核使用的平均CPU时间,以1k为单位
k*sec--CPU存储完整性,以1k-core秒
re--实时时间,以分钟计
s--系统时间,以分钟计
tio--I/O操作的总数
u--用户时间,以分钟计
例如:
842 173.26re 4.30cp 0avio 358k
2 10.98re 4.06cp 0avio 299k find
9 24.80re 0.05cp 0avio 291k ***other
105 30.44re 0.03cp 0avio 302k ping
104 30.55re 0.03cp 0avio 394k sh
162 0.11re 0.03cp 0avio 413k security.sh*
154 0.03re 0.02cp 0avio 273k ls
56 31.61re 0.02cp 0avio 823k ping6.pl*
2 3.23re 0.02cp 0avio 822k ping6.pl
35 0.02re 0.01cp 0avio 257k md5sum
97 0.02re 0.01cp 0avio 263k initlog
12 0.19re 0.01cp 0avio 399k promisc_check.s
15 0.09re 0.00cp 0avio 288k grep
11 0.08re 0.00cp 0avio 332k awk
用户还可以根据用户而不是命令来提供一个摘要报告。例如sa -m显示如下:
885 173.28re 4.31cp 0avk
root 879 173.23re 4.31cp 0avk
alias 3 0.05re 0.00cp 0avk
qmailp 3 0.01re 0.00cp 0avk
4. Syslog设备
Syslog已被许多日志函数采纳,它用在许多保护措施中--任何程序都可以通过syslog 纪录事件。Syslog可以纪录系统事件,可以写到一个文件或设备中,或给用户发送一个信息。它能纪录本地事件或通过网络纪录另一个主机上的事件。
Syslog设备依据两个重要的文件:/etc/syslogd(守护进程)和/etc/syslog.conf配置文件,习惯上,多数syslog信 息被写到/var/adm或/var/log目录下的信息文件中(messages.*)。一个典型的syslog纪录包括生成程序的名字和一个文本信 息。它还包括一个设备和一个优先级范围(但不在日之中出现)。
每个syslog消息被赋予下面的主要设备之一:
LOG_AUTH--认证系统:login、su、getty等
LOG_AUTHPRIV--同LOG_AUTH,但只登录到所选择的单个用户可读的文件中
LOG_CRON--cron守护进程
LOG_DAEMON--其他系统守护进程,如routed
LOG_FTP--文件传输协议:ftpd、tftpd
LOG_KERN--内核产生的消息
LOG_LPR--系统打印机缓冲池:lpr、lpd
LOG_MAIL--电子邮件系统
LOG_NEWS--网络新闻系统
LOG_SYSLOG--由syslogd(8)产生的内部消息
LOG_USER--随机用户进程产生的消息
LOG_UUCP--UUCP子系统
LOG_LOCAL0~LOG_LOCAL7--为本地使用保留
Syslog为每个事件赋予几个不同的优先级:
LOG_EMERG--紧急情况
LOG_ALERT--应该被立即改正的问题,如系统数据库破坏
LOG_CRIT--重要情况,如硬盘错误
LOG_ERR--错误
LOG_WARNING--警告信息
LOG_NOTICE--不是错误情况,但是可能需要处理
LOG_INFO--情报信息
LOG_DEBUG--包含情报的信息,通常旨在调试一个程序时使用
syslog.conf文件指明syslogd程序纪录日志的行为,该程序在启动时查询配置文件。该文件由不同程序或消息分类的单个条目组成,每个占一 行。对每类消息提供一个选择域和一个动作域。这些域由tab隔开:选择域指明消息的类型和优先级;动作域指明syslogd接收到一个与选择标准相匹配的 消息时所执行的动作。每个选项是由设备和优先级组成。当指明一个优先级时,syslogd将纪录一个拥有相同或更高优先级的消息。所以如果指 明"crit",那所有标为crit、alert和emerg的消息将被纪录。每行的行动域指明当选择域选择了一个给定消息后应该把他发送到哪儿。例如, 如果想把所有邮件消息纪录到一个文件中,如下:
#Log all the mail messages in one place
mail.* /var/log/maillog
其他设备也有自己的日志。UUCP和news设备能产生许多外部消息。它把这些消息存到自己的日志(/var/log/spooler)中并把级别限 为"err"或更高。例如:
# Save mail and news errors of level err and higher in aspecial file.
uucp,news.crit /var/log/spooler
当一个紧急消息到来时,可能想让所有的用户都得到。也可能想让自己的日志接收并保存。
#Everybody gets emergency messages, plus log them on anther machine
*.emerg *
*.emerg @linuxaid.com.cn
alert消息应该写到root和tiger的个人账号中:
#Root and Tiger get alert and higher messages
*.alert root,tiger
有时syslogd将产生大量的消息。例如内核("kern"设备)可能很冗长。用户可能想把内核消息纪录到/dev/console中。下面的例子 表明内核日志纪录被注释掉了:
#Log all kernel messages to the console
#Logging much else clutters up the screen
#kern.* /dev/console
用户可以在一行中指明所有的设备。下面的例子把info或更高级别的消息送到/var/log/messages,除了mail以外。级 别"none"禁止一个设备:
#Log anything(except mail)of level info or higher
#Don't log private authentication messages!
*.info:mail.none;authpriv.none /var/log/messages
在有些情况下,可以把日志送到打印机,这样网络入侵者怎么修改日志都没有用了。通常要广泛纪录日志。Syslog设备是一个攻击者的显著目标。一个为 其他主机维护日志的系统对于防范服务器攻击特别脆弱,因此要特别注意。
有个小命令logger为syslog(3)系统日志文件提供一个shell命令接口,使用户能创建日志文件中的条目。用法:logger 例如:logger This is a test!
它将产生一个如下的syslog纪录:Aug 19 22:22:34 tiger: This is a test!
注意不要完全相信日志,因为攻击者很容易修改它的。
5. 程序日志
许多程序通过维护日志来反映系统的安全状态。su命令允许用户获得另一个用户的权限,所以它的安全很重要,它的文件为sulog。同样的还有 sudolog。另外,想Apache 有两个日志:access_log和error_log。
通过对web日志的挖掘来实现内容推荐系统
先说一说问题,不知道大家有没有这样的经验,反正我是经常碰到。
举例1,某些网站每隔几天就发邮件给我,每次发的邮件内容都是一些我根本不感兴趣的东西,我不甚其扰,对其深恶痛绝。
举例2,添加具有某功能的一个msn机器人,每天都有几次突然蹦出一个窗口,推荐一堆我根本不想知道的内容,烦不烦啊, 我只好将你阻止掉。
每一个观众只想看他感兴趣的东西,而不是一下与之无关的事物,那么如何才能知道观众的兴趣所在呢,还是数据挖掘,经过一番思考,终于有点思路,即根据用户 以往的浏览历史来预测用户将来的行为,也就是基于内容的推荐。
基于内容的推荐(Content-based Recommendation)是信息过滤技术的延续与发展,它是建立在项目的内容信息上作出推荐的,而不需要依据用户对项目的评价意见,更多地需要用机 器学习的方法从关于内容的特征描述的事例中得到用户的兴趣资料。在基于内容的推荐系统中,项目或对象是通过相关的特征的属性来定义,系统基于用户评价对象 的特征,学习用户的兴趣,考察用户资料与待预测项目的相匹配程度。用户的资料模型取决于所用学习方法,常用的有决策树、神经网络和基于向量的表示方法等。 基于内容的用户资料是需要有用户的历史数据,用户资料模型可能随着用户的偏好改变而发生变化。
基于内容推荐 方法的优点是:
1)不需要其它用户的数据,没有冷开始问题和稀疏问题。
2)能为具有特殊兴趣爱好的用户进行推荐。
3)能推荐新的或不是很流行的项目,没有新项目问题。
4)通过列出推荐项目的内容特征,可以解释为什么推荐那些项目。
5)已有比较好的技术,如关于分类学习方面的技术已相当成熟。
缺点是要求内容能容易抽取成有意义的特征,要求特征内容有良好的结构性,并且用户的口味必须能够用内容特征形式来表达,不能显式地得到其它用户的判断情 况。
要实现内容推荐系统总体来说要经过4个大的步骤:
1 搜集数据,即搜集用户的行为资料,其中也包括很多方法,根据我找到的资料与以往的经验来看,web日志可以作为我们的切入点,即我们的数据来源。
2 过滤数据,web日志中有很多无用的信息,我们要把这些无用的信息排除掉,而且要区分出用户和日志数据之间的联系。
3 分析数据,利用分类聚类技术分析出这些日志数据之间的关联性,以及这些日志数据和用户之间的关联性,这也是最重要的一步。
4 输出结果。
有了这个思路之后,我们可以着手做第一步,即日志数据的收集
我们知道,大多数的web服务器都是有自己的日志记录的,比如说apache安装之后有一个logs目录,其中就有它的日志文件,一般说来它有自 己的一个格式,比如说:
1浏览器所在主机的 IP 地址(ip);
2访问日期和时间(date-time);
3客户机与服务器通信所用的方法(methed,get or post);
4客户机请求访问页面的 URL;
5服务器返回的状态(status);
6客户端浏览器的类型;
但是这个日志文件有一些不能克服的问题,或者我不知道如何克服,那么我先说说我的疑问,首先,这个日志文件中记录的是ip地址,据了解,网络中有很多计算 机的ip地址是相同的,因为他们在一个统一的路由后面,这个比例可能达到25%。那么我们就无法根据ip地址来唯一确定一个用户。其次,一般的web服务 器中都会用多个应用,那么其他应用的访问信息对我们来说有可能是多余的。再者,web服务器的日志形式比较单一,灵活性不大,可定制的余地很小,在日志数 据中有效数据所占的比例较小。还有,一些静态文件的请求也会被web服务器记录下来,比如说js文件,css文件,还有图片文件,等等这些东西对内容推荐 来说都是无用的资源。
基于上面3点原因,我认为可以自定义日志数据。为了解决用户唯一性,我们让应用为每一个浏览器生成一个clientId保存在对应的浏览器上,这样该浏览 器只要访问网站,我们就可以确定这个浏览器的唯一性,当然我们仍然不能确定浏览器使用者的唯一性,但是我们可以更进一步,如果浏览器的使用者登陆网站的 话,我们就可以使用用户id来确定用户的唯一性,不过大多数网站用户可能在使用网站的时候并不会登陆,我也是这样,没有关系,即使使用clientId问 题也不会太大,随着社会的发展,计算机的拥有量逐渐增加,一般来说一个人只会使用一台固定的电脑,在公司里尤其是这样。所以我认为clientId的方案 是可行的,也许有人要问,别人的浏览器禁止了cookie怎么办,那么我只能说没有办法,不过还好事实是绝大多数人都没有这样做。
接下来我们可以定义一下我们所需要的日志数据的格式,比如这样,
ip,clientId,userId,url,datetime,get or post等等。
这样数据有效性会大大提高。
在得到较为有效的数据之后,我们还需要对这些数据进行再次过滤:
1 去掉一些非内容的url,这些数据也是无效数据,这些非内容的url需要我们自己手工的统计出来,然后和日志数据中的数据进行比对,将这些非内容数据从日 志数据中清除出去。
2 同时我们也需要把post请求从日志数据中清除出去,或者我们在记录日志的时候根本不应该把post请求记录下来。
经过以上步骤之后我们就可以开始第3个阶段了,统计每个用户的访问的url,对这些url进行访问,得到对应的html中所包含的数据,这些数据都是文 本,将有用的文本提取出来,然后对这些有用的文本进行聚类。这样就可以得到每个用户喜欢的几个类别。
聚类完成之后我们就可以开始分类了,即把最新的文章或者内容和对应的类别进行匹配,匹配成功之后,我们可以认为这个新文章或者内容可以推荐给对应的用户。
问题:以上的流程只适用于没有使用缓存的系统,但是一般大型的网站都会使用varnish,squid等等,使用它们之后我们就无法得到用户访问的日志数 据了,所以如果使用了varnish或者squid,我们不得不再次面对web服务器的日志数据。
在不考虑varnish或者squid的情况下,使用lucene+jamon+htmlparse基本就可以实现以上推荐系统。
apache的日志access_log分析
当网站出问题时分析日志,第一步一般都不会是看访问日志。但是也不能忽视它,在访问日志中记录了很多的客户信息,如果你有心,可以从这个日志中获得很多有 用的信息!
访问日志access_log记录了所有对Web服务器的访问活动。
正如其名字所示,访问日志access_log记录了所有对Web服务器的访问活动。
下面是访问日志中一个典型的记录:
10.1.1.95 - e800 [18/Mar/2005:12:21:42 +0800] "GET /stats/awstats.pl?config=e800 HTTP/1.1" 200 899 "http://10.1.1.1/pv/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon)"
这行内容由9项构成,上面的例子中有两项空白,但整行内容仍旧分成了9项。
第一项信息是远程主机的地址。如果你想知道这个IP地址的域名,可通过nslookup或者host命令来查看。如果你想让Apache自己找出这个IP 的主机名,可以打开这个开关:HostnameLookups。(建议最好不要打开,会影响Apache记录服务器日志的速度)
第二项是空白,用一个"-"占位符替代。实际上绝大多数时候这一项都是如此。这个位置用于记录浏览者的标识,这不只是浏览者的登录名字,而是浏览者的 email地址或者其他唯一标识符。这个信息由identd返回,或者直接由浏览器返回。很早的时候,那时Netscape 0.9还占据着统治地位,这个位置往往记录着浏览者的email地址。然而,由于有人用它来收集邮件地址和发送垃圾邮件,所以它未能保留多久,很久之前市 场上几乎所有的浏览器就取消了这项功能。因此,到了今天,我们在日志记录的第二项看到email地址的机会已经微乎其微了。
第三项也是e800。这个位置用于记录浏览者进行身份验证时提供的名字。当然,如果网站的某些内容要求用户进行身份验证,那么这项信息是不会空白的。但 是,对于大多数网站来说,日志文件的大多数记录中这一项仍旧是空白的。
日志记录的第四项是请求的时间。这个信息用方括号包围,而且采用所谓的"公共日志格式"或"标准英文格式"。因此,上例日志记录表示请求的时间是2005 年3月18日12:21:42。时间信息最后的"+0800"表示服务器所处时区位于UTC之后的8小时。
日志记录的第五项信息或许是整个日志记录中最有用的信息,它告诉我们服务器收到的是一个什么样的请求。该项信息的典型格式是"METHOD RESOURCE PROTOCOL",即"方法 资源 协议"。
RESOURCE是指浏览者向服务器请求的文档,或URL。在这个例子中,浏览者请求的是"/stats/awstats.pl?config=e800 "。
在上例中,METHOD是GET,其他经常可能出现的METHOD还有POST和HEAD。此外还有不少可能出现的合法METHOD,但主要就是这三种。
PROTOCOL通常是HTTP,后面再加上版本号。
日志记录的第六项信息是状态代码。它告诉我们请求是否成功,或者遇到了什么样的错误。大多数时候,这项值是200,它表示服务器已经成功地响应浏览器的 请求,一切正常。一般地说,以2开头的状态代码表示成功,以3开头的状态代码表示由于各种不同的原因用户请求被重定向到了其他位置,以4开头的状态代码表 示客户端存在某种错误,以5开头的状态代码表示服务器遇到了某个错误。
日志记录的第七项表示发送给客户端的总字节数。它告诉我们传输是否被打断(即,该数值是否和文件的大小相同)。把日志记录中的这些值加起来就可以得知服务 器在一天、一周或者一月内发送了多少数据。
日志记录的第八项记录的是客户在提出请求时所在的目录或URL。这次的是"http://10.1.1.1/pv/"即10.1.1.1的pv目录下的首 页。大多数情况下,首页会是在httpd.conf中DocumentRoot 指令后面规定的那些类型和名字的web文件。
日志记录的第九项表示客户端的详细信息,这样你就不难理解为什么有些网站能够在页面中显示你的IP、OS、Browser了。