分类 技术 下的文章

在本文中,我们将了解逻辑卷是如何通过条块化I/O来写入数据到磁盘的。逻辑卷管理的酷炫特性之一,就是它能通过条块化I/O跨多个磁盘写入数据。

LVM条块化是什么?

LVM条块化是LVM功能之一,该技术会跨多个磁盘写入数据,而不是对单一物理卷持续写入。

Manage LVM Disks Using Striping I/O

使用条块化I/O管理LVM磁盘

条块化特性

  • 它会改善磁盘性能。
  • 避免对单一磁盘的不断的大量写入。
  • 使用对多个磁盘的条块化写入,可以减少磁盘填满的几率。

在逻辑卷管理中,如果我们需要创建一个逻辑卷,扩展的卷会完全映射到卷组和物理卷。在此种情形中,如果其中一个PV(物理卷)被填满,我们需要从其它物理卷中添加更多扩展。这样,添加更多扩展到PV中后,我们可以指定逻辑卷使用特定的物理卷写入I/O。

假设我们有四个磁盘驱动器,分别指向了四个物理卷,如果各个物理卷总计可以达到100 I/O,我们卷组就可以获得400 I/O

如果我们不使用条块化方法,文件系统将横跨基础物理卷写入。例如,写入一些数据到物理卷达到100 I/O,这些数据只会写入到第一个PV(sdb1)。如果我们在写入时使用条块化选项创建逻辑卷,它会分割100 I/O分别写入到四个驱动器中,这就是说每个驱动器中都会接收到25 I/O。

这会在循环过程中完成。如果这些逻辑卷其中任何一个需要扩展,在这种情形下,我们不能添加1个或2个PV,必须添加所有4个pv来扩展逻辑卷大小。这是条块化特性的缺点之一,从中我们可以知道,在创建逻辑卷时,我们需要为所有逻辑卷分配相同的条块大小。

逻辑卷管理有着这些特性,它使我们能够同时在多个pv中条块化数据。如果你对逻辑卷熟悉,你可以去设置逻辑卷条块化。反之,你则必须了解逻辑卷管理的基础知识了,请阅读更基础的文章来了解逻辑卷管理。

我的服务器设置

这里,我使用CentOS6.5用作练习。下面这些步骤也适用于RHEL、Oracle Linux以及大多数发行版。

操作系统:    CentOS 6.5
IP地址:     192.168.0.222
主机名:        tecmint.storage.com

条块化I/O的逻辑卷管理

出于演示目的,我已经准备了4个硬盘驱动器,每个驱动器1GB大小。让我用下面的‘fdisk’命令来列给你看看吧。

# fdisk -l | grep sd

List Hard Drives

列出硬盘驱动器

现在,我们必须为这4个硬盘驱动器sdbsdcsddsde创建分区,我们将用‘fdisk’命令来完成该工作。要创建分区,请遵从本文第一部分步骤#4的说明,并在创建分区时确保你已将类型修改为LVM(8e)

# pvcreate /dev/sd[b-e]1 -v

Create Physical Volumes in LVM

在LVM中创建物理卷

PV创建完成后,你可以使用‘pvs’命令将它们列出来。

# pvs

Verify Physical Volumes

验证物理卷

现在,我们需要使用这4个物理卷来定义卷组。这里,我定义了一个物理扩展大小(PE)为16MB,名为vg\_strip的卷组。

# vgcreate -s 16M vg_strip /dev/sd[b-e]1 -v

上面命令中选项的说明:

  • [b-e]1 – 定义硬盘驱动器名称,如sdb1,sdc1,sdd1,sde1。
  • -s – 定义物理扩展大小。
  • -v – 详情。

接下来,验证新创建的卷组:

# vgs vg_strip

Verify Volume Group

验证卷组

要获取VG更详细的信息,可以在vgdisplay命令中使用‘-v’选项,它将给出vg\_strip卷组中所使用的全部物理卷的详细情况。

# vgdisplay vg_strip -v

Volume Group Information

卷组信息

回到我们的话题,现在在创建逻辑卷时,我们需要定义条块化值,就是数据需要如何使用条块化方法来写入到我们的逻辑卷中。

这里,我创建了一个名为lv\_tecmint-strp1,大小为900MB的逻辑卷,它需要放到vg\_strip卷组中。我定义了4个条块,就是说数据在写入到我的逻辑卷时,需要条块化分散到4个PV中。

# lvcreate -L 900M -n lv_tecmint_strp1 -i4 vg_strip
  • -L –逻辑卷大小
  • -n –逻辑卷名称
  • -i –条块化

Create Logical Volumes

创建逻辑卷

在上面的图片中,我们可以看到条块尺寸的默认大小为64 KB,如果我们需要自定义条块值,我们可以使用-I(大写I)。要确认逻辑卷已经是否已经创建,请使用以下命令。

# lvdisplay vg_strip/lv_tecmint_strp1

Confirm Logical Volumes

确认逻辑卷

现在,接下来的问题是,我们怎样才能知道条块被写入到了4个驱动器。这里,我们可以使用‘lvdisplay’和-m(显示逻辑卷映射)命令来验证。

# lvdisplay vg_strip/lv_tecmint_strp1 -m

Check Logical Volumes

检查逻辑卷

要创建自定义的条块尺寸,我们需要用我们自定义的条块大小256KB来创建一个1GB大小的逻辑卷。现在,我打算将条块分布到3个PV上。这里,我们可以定义我们想要哪些pv条块化。

# lvcreate -L 1G -i3 -I 256 -n lv_tecmint_strp2 vg_strip /dev/sdb1 /dev/sdc1 /dev/sdd1

Define Stripe Size

定义条块大小

接下来,检查条块大小和条块化的卷。

# lvdisplay vg_strip/lv_tecmint_strp2 -m

Check Stripe Size

检查条块大小

是时候使用设备映射了,我们使用‘dmsetup’命令来完成这项工作。它是一个低级别的逻辑卷管理工具,它用于管理使用了设备映射驱动的逻辑设备。

# dmsetup deps /dev/vg_strip/lv_tecmint_strp[1-2]

Device Mapper

设备映射

这里,我们可以看到strp1依赖于4个驱动器,strp2依赖于3个设备。

希望你已经明白,我们怎样能让逻辑卷条块化来写入数据。对于此项设置,必须掌握逻辑卷管理基础知识。

在我的下一篇文章中,我将给大家展示怎样在逻辑卷管理中迁移数据。到那时,请静候更新。同时,别忘了对本文提出有价值的建议。


via: http://www.tecmint.com/manage-multiple-lvm-disks-using-striping-io/

作者:Babin Lonston 译者:GOLinux 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

问题:我想要去除图像文件中的白色空白,有没有什么便捷的方法能在Linux命令行中对图像文件进行剪裁?

当涉及到在Linux中转换或编辑图像文件时,ImageMagick毫无疑问是最为熟知的一体化软件之一。它包含了一整套命令行工具,用以显示、转换,或复制超过200中类型的光栅或矢量图像文件,所有这一切都在命令行下完成。ImageMagick可以用于多样化的图像编辑工作,如转换文件格式,添加特殊效果,添加文本,以及改变图像(调整大小、旋转、翻转、剪裁)。

如果你想要剪裁映像以去除空白,你可以使用ImageMagick自带的两个命令行工具。如果你还没有安装ImageMagick,请参照本指南来安装。

在本教程中,让我们来剪裁以下PNG图像。我们想要去除图像右边和底部的边缘,以便让图标居中。

首先,鉴定图像文件的尺寸(宽度和高度)。你可以使用identity命令来完成。

 $ identify chart.png 

chart.png PNG 1500x1000 1500x1000+0+0 8-bit DirectClass 31.7KB 0.000u 0:00.000

就像上面显示的那样,输入的图像是1500x1000px。

接下来,确定图像剪裁要做的两件事:(1)剪裁图像开始的位置(2)剪裁矩形区域的大小。

在本实例中,让我们假定图像剪裁从左上角开始,更精确点是在x=20px和y=10px,那样的话,剪裁后的图像尺寸为1200x700px。

用于剪裁图像的工具是convert。使用“-crop”选项后,convert命令会在输入图像中剪裁出一个矩形区域。

 $ convert chart.png -crop 1200x700+20+10 chart-cropped.png 

指定输入图像为chart.png,convert命令会将剪裁后的图像存储为chart-cropped.png。


via: http://ask.xmodulo.com/crop-image-command-line-linux.html

译者:GOLinux 校对:Caroline

本文由 LCTT 原创翻译,Linux中国 荣誉推出

RAID 10阵列(又名RAID 1+0 或先镜像后分区)通过结合RAID 0 (读写操作在多个磁盘上同时并行执行)和RAID 1(数据被完全相同地写入到两个或更多的磁盘)两者的特点实现高性能和高容错性的磁盘I/O。

这篇文章会指导你如何使用五块相同的8GB磁盘来组成一个软件RAID 10阵列。因为组成一个RAID 10阵列至少需要4块磁盘(比如,两个镜像各有一对分区组合),而且需要添加一块额外的备用磁盘以防某块主要的磁盘出错。本文也会分享一些工具,在稍后用来分析RAID阵列的性能。

注意RAID 10的优缺点和其它分区方法(在不同大小的磁盘和文件系统上)的内容不在本文讨论范围内。

Raid 10 阵列如何工作?

如果你需要实现一种支持I/O密集操作(比如数据库、电子邮件或web服务器)的存储解决方案,RAID 10就是你需要的。来看看为什么这么说,请看下图。

上图中的文件由A、B、C、D、E和F六种块组成,每一个RAID 1镜像对(如镜像1和2)在两个磁盘上复制相同的块。在这样的配置下,写操作性能会因为每个块需要写入两次而下降,每个磁盘各一次;而读操作与从单块磁盘中读取相比并未发生改变。不过这种配置的好处是除非一个镜像中有超过一块的磁盘故障,否则都能保持冗余以维持正常的磁盘I/O操作。

RAID 0的分区通过将数据划分到不同的块,然后执行同时将块A写入镜像1、将块B写入镜像2(以此类推)的并行操作以提高整体的读写性能。在另一方面,没有任何一个镜像包含构成主存的数据片的全部信息。这就意味着如果其中一个镜像故障,那么整个RAID 0组件将无法正常工作,数据将遭受不可恢复的损失。

建立RAID 10阵列

有两种建立RAID 10阵列的可行方案:复杂法(一步完成)和嵌套法(先创建两个或更多的RAID 1阵列,然后使用它们组成RAID 0)。本文会讲述复杂法创建RAID 10阵列的过程,因为这种方法能够使用偶数或奇数个磁盘去创建阵列,而且能以单个RAID设备的形式被管理,而嵌套法则恰恰相反(只允许偶数个磁盘,必须以嵌套设备的形式被管理,即分开管理RAID 1和RAID 0)。

假设你的机器已经安装mdadm,并运行着相应的守护进程,细节参见这篇文章。也假设每个磁盘上已经划分出一个主分区sd[bcdef]1 (LCTT 译注:共计五块磁盘,这里是从sdb - sdf)。使用命令:

ls -l /dev | grep sd[bcdef]

查看到的输出应该如下所示:

然后使用下面的命令创建一个RAID 10阵列(LCTT 译注:使用了四块磁盘 bcde 创建):

 # mdadm --create --verbose /dev/md0 --level=10 --raid-devices=4 /dev/sd[bcde]1 --spare-devices=1 /dev/sdf1 

当阵列创建完毕后(最多花费几分钟),执行命令

# mdadm --detail /dev/md0

的输出应如下所示:

在更进一步之前需要注意以下事项。

  1. Used Dev Space表示阵列所使用的每一块磁盘的容量。
  2. Array Size表示阵列的整体大小。RAID 10阵列的大小通过(N*C)/M计算,其中N是活跃磁盘的数目,C是每个活跃磁盘的容量,M是每一个镜像中磁盘的数目。在本文的情形下,这个值等于(4*8GiB)/2 = 16GiB。
  3. Layout是整个数据布局的详细信息。可能的布局数值如下所示。

  • n(默认选项):代表就近(near)拷贝。一个数据块的多个拷贝在不同磁盘里有相同的偏移量。这种布局提供和RAID 0阵列相似的读写性能。

  • o代表偏移量(offset)拷贝。块并不是在条带里面复制的,而是整个条带一起复制,但是循环会打乱,所以同一个分区中复制的块会出现在不同的磁盘。因此,一个块的后续拷贝会出现在下一个磁盘中,一个块接着一个块。为了在RAID 10阵列中使用这种布局,在创建阵列的命令中添加--layout=o2选项。

  • f代表远端(far)拷贝(多个拷贝在不同的磁盘中具有不同的偏移量)。这种布局提供更好的读性能但带来更差的写性能。因此,对于读远远多于写的系统来说是最好的选择。为了在RAID 10阵列中使用这种布局,在创建阵列的命令中添加--layout=f2。

跟在布局选项nfo后面的数字代表所需的每一个数据块的副本数目。默认值是2,但可以是2到阵列中磁盘数目之间的某个值。提供足够的副本数目可以最小化单个磁盘上的I/O影响。

  1. Chunk Size,参考Linux RAID wiki的说明,是写入磁盘的最小数据单元。最佳的chunk大小取决于I/O操作的速率和相关的文件大小。对于大量的写操作,通过设置相对较大的chunk可以得到更低的开销,但对于主要存储小文件的阵列来说更小的chunk性能更好。为了给RAID 10指定一个chunk大小,在创建阵列的命令中添加--chunk=desiredchunksize

不幸的是,并没有设置一个大小就能适合全局的策略来提高性能,但可以参考下面的一些方案。

  • 文件系统:就整体而言,XFS据说是最好的,当然EXT4也是不错的选择。
  • 最佳布局:远端布局能提高读性能,但会降低写性能。
  • 副本数目:更多的副本能最小化I/O影响,但更多的磁盘需要更大的花费。
  • 硬件:在相同的环境下,SSD比传统(机械旋转)磁盘更能带来出性能提升

使用DD进行RAID性能测试

下面的基准测试用于检测RAID 10阵列(/dev/md0)的性能。

1. 写操作

往磁盘中写入大小为256MB的单个文件:

# dd if=/dev/zero of=/dev/md0 bs=256M count=1 oflag=dsync 

写入1000次512字节:

# dd if=/dev/zero of=/dev/md0 bs=512 count=1000 oflag=dsync 

使用dsync标记,dd可以绕过文件系统缓存,在RAID阵列上执行同步写。这个选项用于减少RAID性能测试中缓存的影响。

2. 读操作

从阵列中拷贝256KiB*15000(3.9 GB)大小内容到/dev/null:

 # dd if=/dev/md0 of=/dev/null bs=256K count=15000 

使用Iozone进行RAID性能测试

Iozone是一款文件系统基准测试工具,用来测试各种磁盘I/O操作,包括随机读写、顺序读写和重读重写。它支持将结果导出为微软的Excel或LibreOffice的Calc文件。

在CentOS/RHEL 7上安装Iozone

先保证Repoforge可用,然后输入:

# yum install iozone 

在Debian 7上安装Iozone

# aptitude install iozone3 

下面的iozone命令会在RAID-10阵列中执行所有测试:

# iozone -Ra /dev/md0 -b /tmp/md0.xls 
  • -R:往标准输出生成兼容Excel的报告
  • -a:以全自动模式运行所有的测试,并测试各种记录/文件大小。记录大小范围:4K-16M,文件大小范围:64K-512M。
  • -b /tmp/md0.xls: 把测试结果存储到一个指定的文件中

希望这篇文章对你有所帮助,如果想到任何想法或建议可能会提升RAID 10的性能,请讲出来。


via: http://xmodulo.com/setup-raid10-linux.html

作者:Gabriel Cánepa 译者:KayGuoWhu 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

我有时候会听到我们的团队成员这样议论:

"项目的Code review 只是浪费时间。"

"我没有时间做Code review。"

"我的发布时间延迟了,因为我的同事还没有完成我代码的Code review。"

"你相信我的同事居然要求我对我的代码做修改吗?请跟他们说代码中的一些联系会被打断——如果在我原来代码的基础之上做修改的话。"

(LCTT 译注:Code Review中文可以翻译成代码审查,一般由开发待review的代码的成员以外的团队成员来进行这样的工作。由于是专业术语,没有将Code review用中文代替。)

为什么要做Code review?

每个专业软件开发者都有一个重要的目标:持续的提高他们的工作质量。即使你团队中都是一些优秀的程序员,但是你依然不能将你自己与一个有能力的自由职业者区分开来,除非你从团队的角度来工作。Code review是团队工作的一个重要的方面。尤其是:

代码复查者(reviewer)能从他们的角度来发现问题并且提出更好的解决方案。

确保至少你团队的另一个其他成员熟悉你的代码,通过给新员工看有经验的开发者的代码能够某种程度上提高他们的水平。

公开reviewer和被复查者的想法和经验能够促进团队间的知识的分享。

能够鼓励开发者将他们的工作进行的更彻底,因为他们知道他们的代码将被其他的人阅读。

在review的过程中的注意点

但是,由于Code review的时间有限,上面所说的目标未必能全部达到。就算只是想要打一个补丁,都要确保意图是正确的。如果只是将变量名改成骆驼拼写法(camelCase),那不算是code review。在开发过程中进行结对编程是有益处的,它能够使两个人得到公平的锻炼。你能够在code review上花许多时间,并且仍然能够比在结对编程中使用更少的时间。

我的感受是,在项目开发的过程中,25%的时间应该花费在code review上。也就是说,如果开发者用两天的时间来开发一个东西,那么复查者应该使用至少四个小时来审查。

当然,只要你的review结果准确的话,具体花了多少时间就显得不是那么的重要。重要的是,你能够理解你看的那些代码。这里的理解并不是指你看懂了这些代码书写的语法,而是你要知道这段代码在整个庞大的应用程序、组件或者库中起着什么样的作用。如果你不理解每一行代码的作用,那么换句话说,你的code review就是没有价值的。这就是为什么好的code review不能很快完成的原因。需要时间来探讨各种各样的代码路径,让它们触发一个特定的函数,来确保第三方的API得到了正确的使用(包括一些边缘测试)。

为了查阅你所审查的代码的缺陷或者是其他问题,你应该确保:

  • 所有必要的测试都已经被包含进去。
  • 合理的设计文档已经被编写。

再熟练的开发者也不是每次都会记得在他们对代码改动的时候把测试程序和文档更新上去。来自reviewer的一个提醒能够使得测试用例和开发文档不会一直忘了更新。

避免code review负担太大

如果你的团队没有强制性的code review,当你的code review记录停留在无法管理的节点上时会很危险。如果你已经两周没有进行code review了,你可以花几天的时间来跟上项目的进度。这意味着你自己的开发工作会被阻断,当你想要处理之前遗留下来的code review的时候。这也会使得你很难再确保code review的质量,因为合理的code review需要长期认真的努力,最终会很难持续几天都保持这样的状态。

由于这个原因,开发者应当每天都完成他们的review任务。一种好办法就是将code review作为你每天的第一件事。在你开始自己的开发工作之前完成所有的code review工作,能够使你从头到尾都集中注意力。有些人可能更喜欢在午休前或午休后或者在傍晚下班前做review。无论你在哪个时间做,都要将code review看作你的工作之一并且不能分心,你要避免:

  • 没有足够的时间来处理你的review任务。
  • 由于你的code review工作没有做完导致版本的推迟发布。
  • 提交不再相关的review,由于代码在你review期间已经改动太大。
  • 因为你要在最后一分钟完成他们,以至于review质量太差。

书写易于review的代码

有时候review没有按时完成并不都是因为reviewer。如果我的同事使用一周时间在一个大工程中添加了一些乱七八糟的代码,且他们提交的补丁实在是太难以阅读。在一段代码中有太多的东西要浏览。这样会让人难以理解它的作用,自然会拖慢review的进度。

为什么将你的工作划分成一些易于管理的片段很重要有很多原因。我们使用scrum方法论(一种软件开发过程方法),因此对我们来说一个合理的单元就是一个story。通过努力将我们的工作使用story组织起来,并且只是将review提交到我们正在工作的story上,这样,我们写的代码就会更加易于review。你们也可以使用其他的软件开发方法,但是目的是一样的。

书写易于review的代码还有其他先决条件。如果要做一些复杂的架构决策,应该让reviewer事先知道并参与讨论。这会让他们之后review你们的代码更加容易,因为他们知道你们正在试图实现什么功能并且知道你们打算如何来实现。这也避免了开发者需要在reviewer提了一个不同的或者更好的解决方案后大片的重写代码。

项目需要应当在设计文档中详细的描述。这对于一个项目新成员想要快速上手并且理解现有的代码来说非常重要。这从长远角度对于一个reviewer来说也非常有好处。单元测试也有助于reviewer知道一些组件是怎么使用的。

如果你在你的补丁中包含的第三方的代码,记得单独的提交它。当jQuery的9000行代码被插入到了项目代码的中间,毫无疑问会造成难以阅读。

创建易读的review代码的另一个非常重要的措施是添加相应的注释代码。这就要求你事先自己做一下review并且在一些你认为会帮助reviewer进行review的地方加上相应的注释。我发现加上注释相对于你来说往往只需要很短的时间(通常是几分钟),但是对于review来说会节约很多的时间。当然,代码注释还有其他相似的好处,应该在合理的地方使用,但往往对code review来说更重要。事实上,有研究表明,开发者在重读并注释他们代码的过程中,通常会发现很多问题。

代码大范围重构的情况

有时候,有必要重构一段代码使其能够作用于多个其他组件。若是一个大型的应用要这样做,会花费几天甚至是更多的时间,结果是生成一个诺大的补丁包。在这种情况下,进行一个标准的code review可能是不切实际的。

最好的方法是增量重构你的代码。找出合理范围内的一部分改变,以此为基础来重构。一旦修改和review完成,进入第二个增量。以此类推,直到整个重构完成。这种方法可能不是在所有的情况下都可行,但是尽管如此,也能避免在重构时出现大量的单片补丁。开发者使用这种方式重构可能会花去更多的时间,但这也使得代码质量更高并且之后的review会更简单。

如果实在是没有条件去通过增量方式重构代码(有人可能会说之前的代码书写并组织的是多么的好),一种解决方案是在重构时进行结对编程来代替code review。

解决团队成员之间的纠纷

你的团队中都是一些有能力的专家,在一些案例中,完全有可能因为对一个具体编码问题的意见的不同而产生争论。作为一个开发者,应该保持一个开发的头脑并且时刻准备着妥协,当你的reviewer更想要另一种解决方法时。不要对你的代码持有专有的态度,也不要自己持有审查的意见。因为有人会觉得你应该将一些重复的代码写入一个能够复用的函数中去,这并不意味着这是你的问题。

作为一个reviewer,要灵活。在提出修改建议之前,考虑你的建议是否真的更好或者只是无关紧要。如果你把力气和注意力花在那些原来的代码会明确需要改进的地方会更加成功。你应该说"它或许值得考虑..."或者"一些人建议..."而不是”我的宠物都能写一个比这个更加有效的排序方法"。

如果你真的决定不了,那就询问另一个你及你所审查的人都尊敬的开发者来听一下你意见并给出建议。


via: http://blog.salsitasoft.com/practical-lessons-in-peer-code-review/

作者:Matt 译者:john 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

Linux 有一个显著的特点,在正常情况下,你可以通过日志分析系统日志来了解你的系统中发生了什么,或正在发生什么。的确,系统日志是系统管理员在解决系统和应用问题时最需要的第一手资源。我们将在这篇文章中着重讲解 Apache HTTP web server 生成的 Apache access 日志。

这次,我们会通过另类的途径来分析 Apache access 日志,我们使用的工具是 asql。asql 是一个开源的工具,它能够允许使用者使用 SQL 语句来查询日志,从而通过更加友好的格式展现相同的信息。

Apache 日志背景知识

Apache 有两种日志:

  • Access log:存放在路径 /var/log/apache2/access.log (Debian) 或者 /var/log/httpd/access\_log (Red Hat)。Access Log 记录所有 Apache web server 执行的请求。
  • Error log:存放在路径 /var/log/apache2/error.log (Debian) 或者 /var/log/httpd/error\_log (Red Hat)。Error log 记录所有 Apache web server 报告的错误以及错误的情况。Error 情况包括(不限于)403(Forbidden,通常在请求被拒绝访问时被报告),404(Not found,在请求资源不存在时被报告)。

虽然管理员可以通过配置 Apache 的配置文件来自定义 Apache access log 的详细程度,不过在这篇文章中,我们会使用默认的配置,如下:

远程 IP - 请求时间 - 请求类型 - 响应代码 - 请求的 URL - 远程的浏览器信息 (也许包含操作系统信息)

因此一个典型的 Apache 日志条目就是下面这个样子:

192.168.0.101 - - [22/Aug/2014:12:03:36 -0300] "GET /icons/unknown.gif HTTP/1.1" 200 519 "http://192.168.0.10/test/projects/read_json/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0"

但是 Apache error log 又是怎么样的呢?因为 error log 条目主要记录 access log 中特殊的请求(你可以自定义),所以你可以通过 access log 来获得关于错误情况的更多信息(example 5 有更多细节)。

此外要提前说明的, access log 是系统级别的日志文件。要分析虚拟主机的日志文件,你需要检查它们相应的配置文件(例如: 在 /etc/apache2/sites-available/[virtual host name] 里(Debian))。

在 Linux 上安装 asql

asql 由 Perl 编写,而且需求以下两个 Perl 模块:SQLite 的 DBI 驱动以及 GNU readline。

在 Debian, Ubuntu 以及其衍生发行版上安装 asql

使用基于 Debian 发行版上的 aptitude,asql 以及其依赖会被自动安装。

# aptitude install asql

在 Fedora,CentOS,RHEL 上安装 asql

在 CentOS 或 RHEL 上,你需要启用 EPEL repository,然后运行以下代码。在 Fedora 中,直接运行以下代码:

# sudo yum install perl-DBD-SQLite perl-Term-Readline-Gnu
# wget http://www.steve.org.uk/Software/asql/asql-1.7.tar.gz
# tar xvfvz asql-1.7.tar.gz
# cd asql
# make install

asql 是如何工作的?

从上面代码中的依赖中你就可以看出来,asql 转换未结构化的明文 Apache 日志为结构化的 SQLite 数据库信息。生成的 SQLite 数据库可以接受正常的 SQL 查询语句。数据库可以通过当前以及之前的日志文件生成,其中也包括压缩转换过的日志文件,类似 access.log.X.gz 或者 access\_log.old。

首先,从命令行启动 asql:

# asql

你会进入 asql 内置的 shell 交互界面。

输入 help 列表可执行的命令:

首先在 asql 中加载所有的 access 日志:

asql > load <apache-access-logs 的路径>

比如在 Debian 下:

asql > load /var/log/apache2/access.*

在 CentOS/RHEL 下:

asql > load /var/log/httpd/access_log*

当 asql 完成对 access 日志的加载后,我们就可以开始数据库查询了。注意一下,加载后生成的数据库是 "temporary" (临时)的,意思就是数据库会在你退出 asql 的时候被清除。如果你想要保留数据库,你必须先将其保存为一个文件。我们会在后面介绍如何这么做(参考 example 3 和 4)。

生成的数据库有一个名为 logs 的表。输入下面的命令列出 logs 表中提供的域:

一个名为 .asql 的隐藏文件,保存于用户的 home 目录下,记录用户在 asql shell 中输入的命令历史。因此你可以使用方向键浏览命令历史,按下 ENTER 来重复执行之前的命令。

asql 上的示例 SQL 查询

下面是几个使用 asql 针对 Apache 日志文件运行 SQL 查询的示例:

Example 1:列出在 2014 年 10 月中请求的来源 / 时间以及 HTTP 状态码。

SELECT source, date, status FROM logs WHERE date >= '2014-10-01T00:00:00' ORDER BY source;

Example 2:从小到大显示单个客户端处理的请求大小(bytes)。

SELECT source, SUM(size), AS NUMBER FROM logs GROUP BY source ORDER BY Number DESC;

Example 3:在当前目录中保存数据库为 [filename]。

save [filename]

这样做可以避免使用 load 命令对日志的语法分析所占用的处理时间。

Example 4:在重新进入 asql 后载入数据库。

restore [filename]

Example 5:返回 access 日志中记录的 error 情况。在这个例子中,我们将显示所有返回 HTTP 状态码为 403(access forbidden)的请求。

SELECT source, date, status, request FROM logs WHERE status='403' ORDER BY date

这个例子想要表现的是:虽然 asql 只分析 access 日志,我们还是可以通过使用请求的状态域来显示有 error 情况的请求。

小结:

我们体验了 asql 如何帮助我们分析 Apache 日志文件,并将结果通过友好的格式输出。虽然你也可以通过使用命令行的工具(例如 cat 与 grep,uniq,sort,wc 等等之间的管道)来实现类似功能,与此比较起来 asql 展示了它如同瑞士军刀一般的强大功能,使我们在自己的需求下能够通过标准 SQL 查询语句来过滤日志。

希望这篇教程能帮助到你们。

请不要拘束地将评论文章,分享文章,提出疑问。


via: http://xmodulo.com/sql-queries-apache-log-files-linux.html

作者:Gabriel Cánepa 译者:ThomazL 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

问题:当我运行一个Python应用程序时,出现了这个提示消息“ImportError: No module named scapy.all”。我怎样才能修复这个导入错误呢?

Scapy是一个用Python写的灵活的数据包生成及嗅探程序。使用Scapy,你可以完成创建任意数据包并发送到网络上、从网络上或转储文件中读取数据包、转换数据包等工作。使用Scapy的通用包处理能力,你可以很容易地完成像SYN扫描、TCP路由跟踪以及OS指纹检测之类的工作。你也可以通过Import,将Scapy整合到其它工具中。

该导入错误表明:你还没有在你的Linux系统上安装Scapy。下面介绍安装方法。

安装Scapy到Debian, Ubuntu或Linux Mint

 $ sudo apt-get install python-scapy 

安装Scapy到Fedora或CentOS/RHEL

在CentOS/RHEL上,你首先需要启用EPEL仓库

 $ sudo yum install scapy 

源码安装Scapy

如果你的Linux版本没有提供Scapy包,或者你想要试试最新的Scapy,你可以手工使用源码包安装。

下载最新版的Scapy,然后按照以下步骤安装。

$ unzip scapy-latest.zip
$ cd scapy-2.*
$ sudo python setup.py install 

via: http://ask.xmodulo.com/importerror-no-module-named-scapy-all.html

译者:GOLinux 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出