奥运会后期机票和酒店等旅游产品的搜索数量相比之前翻了三番。旅游搜索引擎网站去哪儿副总裁戴政感慨地说。从去哪儿市场数据研究中心的报告来看，8月1日、2日的酒店产品搜索量不增倒减，但就在昨天，我们发现8月23日至8月28日期间的酒店搜索量和预订量几乎增长了70%，这么大幅度的增长是只有节假日才会出现的这位负责人坚信奥运会对于中国旅游行业的影响不可小视。

奥运会后旅游消费能量在酝酿

市民高先生为了能在家观看奥运赛事，推迟了他们全家的香港购物之旅。近日，据调查发现，像高先生这样为了观看奥运而推迟或者改变旅行计划的大有人在，使得本应是暑期旅游高峰的八月上旬出现了反常的冷清。而海南、西安、昆明等许多旅行社已经开始忙碌起来，精心准备奥运后的旅游线路，打算在奥运会一结束就向市场推出精彩的全新线路产品。根据去哪儿旅游搜索引擎提供的数据显示，来自南京、西安、香港、天津、昆明、郑州等城市的酒店、机票产品搜索量位居全国所有城市的前列。其中西安的酒店搜索量更是以57%的份额高踞榜首，足以表明国内游客对于这个热点旅游城市的青睐。去哪儿副总裁戴政表示，去哪儿网站搜索量分布情况表明，奥运会后期出游的消费大潮正在酝酿之中。

行业机构信心满满

国家旅游局副局长王志发在北京国际新闻中心表示，奥运后，中国将迎来一个旅游高峰。他表示，目前中国旅游业已做好准备，在奥运主办、协办城市完善公共基础设施和服务设施，在国内其他省区加强对景点景区的设施完善，进一步增大接待能力。目前，许多旅行社已经将目光瞄准后奥运游。由于奥运后机票、酒店价格回落，奥运后酒店等旅游产品在价格上将有大幅跳水，基本恢复到今年7月份时的水平。同时，鸟巢、水立方等奥运赛事场馆将进一步丰富北京游产品。目前，京城各酒店集团对后奥运旅游市场充满期待，正着手准备以更多优惠的措施来吸引游客，以争取分得后奥运旅游的一杯羹。

旅游市场期待井喷

据去哪儿网站介绍：虽然8月初网络用户的酒店产品搜索量比往年同期有所下降，但反弹势头强劲，完全可以预测，9月中旬以后旅游市场将掀起新一波热潮。9月份开学之前，估计会有许多家庭会要搭上暑期末班车。他认为，今年奥运期间旅游业平淡有很多原因，比如四川地震后人们的出行意愿降低；物价上涨，燃油附加费增高，住宿、餐饮、机票折扣相对较低；奥运期间市民忙着看比赛，各地安检也比平时更加严格，交通管制增加，这些因素都导致不少游客将行程延期。因此，市场在8月份积累的消费能量，将会随着奥运会结束，形成一个市场能量的充分释放。

从往届奥运会举办国的情形看，奥运经济都是在奥运结束后的半年到三年的时间内体现出来的，去哪儿旅游搜索引擎建议各旅游城市和相关从业机构应当凭借自身的资源优势，吸引更多游客，积极着手为后奥运时代做准备了，如推出一些旅游产品，拓展直销渠道，加大广告投放，搞一些促销活动等多种营销手段，争取吸引住家庭游清凉游的游客大军。迅速告别奥运期间的冷清局面，迎来奥运后即将到来的市场井喷。而对于消费者来说，充分安排有限的假期，利用去哪儿这样的搜索引擎工具，将奥运后旅游产品的优惠折扣一网打尽，也不失为一种聪明的生活方式。

    三峡和清江峡谷，不仅仅是两条地理意义上的大峡谷，而应为彼此关联、超越狭义地理概念的地理人文一体化的“大三峡”。

    记者追访国家相关部门近年来的地质调查，采访相关专家学者及实地考察，以报道“大三峡”地理重大发现。

    重庆曾淹在水下100多米

    长江对三峡的水锯下切，深达上千米，这一过程持续了近300万年。在50万年前形成三峡、连通东西长江后，三峡崩山多次堵塞长江，这现象从远古一直持续到距今5000年左右。这也是长江多次循故道南流的主因。     

    华中科技大学83岁的张良皋教授肯定了长江南流清江的说法。他说，原湖北省博物馆馆长林奇在一次考察中，在巴东江段海拔310米的地方找到了东汉时水淹的痕迹。可见当时崩山壅水之高，已经将今天的重庆市淹没在100多米深的水下。事实上远古三峡崩山壅水的高度，可能很多次都要比310米高，长江南流寻找出路势所必然。

　长江曾在三峡崖顶流淌

    1959年开始，为配合三峡筑坝，中国科学院地理研究所、北京大学、中山大学地理系曾经联合组成三峡地貌队，进行了系统的长江地貌野外调查。调查确定了重庆河段海拔315米，三峡河段海拔540米、宜昌河段海拔146米高度处古长江遗留下的砾石层。不过由于这些砾石层海拔较低，所以仍然无法解释切割深度为1000米上下的三峡成因。 　

    1982年起，中科院再组科考队，对长江全程进行连续750天不间断的野外科考。科考队在204公里的三峡区间耗时55天，在三峡上游丰都与三峡之中的巫山两处海拔1350米高度上，发现了20～30厘米厚（后来的考察发现厚达2～3米）的古长江堆积的砾石，从而确认了海拔1350米这一高度存在贯通的古长江。中国长江三峡古河底砾石层的1250米（扣除河床海拔高度约100米）相对高度远远高于其他世界大河，为全球第一。     

    记者日前走访位于湖北恩施的清江沐抚大峡谷发现：在恩施往利川的朝东岩、石板岭的1600米的崖顶上，也存在着古河床的砾石。在比长江三峡两岸诸山更高的长江和清江之间的巫山分水岭（海拔1850米）上，近年科考也发现存在多处砾石层。     

　世界最长暗河竖井108个

    今年8月，记者在恩施板桥镇遇到了考察龙桥暗河多年的中法探险队。专家推测，龙桥暗河、九曲连环的云龙洞、清江沐抚大峡谷以及20公里的云龙地缝都是长江壅水所致。     

    2004年9月25日，中法探险队宣布：在湖北恩施板桥镇与重庆奉节兴隆镇交界处，发现世界最长地下暗河——龙桥暗河，长50公里，其出口位于清江沐抚大峡谷板桥境内，与地表相通的竖井据说多达108个。龙桥暗河已探明有两条主流走向，旧道是从入口向南穿切分水岭，进入清江沐抚大峡谷。但后来洞穴可能因山体抬升产生了崩塌，堵塞了暗河，暗河在洞中改道向西，最终还是进入清江沐抚大峡谷。     

    比三峡还长的沐抚大峡谷

　中法探险队在寻找暗河出口时，在板桥境内“发现了一条巨大的地缝，地缝全长20公里，地势极其险要，两边的悬崖峭壁犹如刀砍斧削，白色的岩石裸露在外，蔚为壮观”。经探险队初步测量，“这条大地缝最深处约2300米，比排名世界第四的美国科罗拉多大峡谷（深2133米）还要深”。这条大地缝实际上是沐抚大峡谷上段云龙河切割出来的云龙地缝。

    沐抚大峡谷自板桥始，经云龙河到沐抚镇，再到大河碥和从西面高山盆地利川盆地（平均海拔1070米）伏流出土的雪照河（即清江）汇合，到马者镇以下出峡进入恩施盆地，全长108公里。沐抚大峡谷平均深切（1500米）、绝对高差（超过2000米）、峡谷不间断绵延的长度（峡谷地带108公里），已超过了长江三峡（峡谷地带90公里，平均深切1000米左右）。如果再计上下游的清江三峡（平洛峡15公里、巴山峡5公里、伴峡5公里），清江峡谷多项数据远超长江三峡。

    很多专家认为：清江沐抚大峡谷是长江故道，峡谷的形成与深切，和长江的水锯下切有关。

　背景资料

    古长江成因

    300万年以前，巫山山脉是和大巴山山脉连在一起的高地，还没有出现三峡裂谷。三峡的形成大致经历了退出古地中海，两水背流，东西长江连通东流三个阶段。

    因喜马拉雅造山——横断山脉持续隆起，西部古长江向西南流的路中断，壅水开始向东寻找出路。长江切穿齐岳山、横石溪、楠木园、黄陵等背斜，分别形成瞿塘峡、巫峡、西陵峡。在50万年前使东西古长江经由三峡，实现了贯通。

一种用于构建 Rich Internet Application（RIA）的方法就是使用动态 HTML（Dynamic HTML，DHTML），它是 Ajax、JavaScript、层叠样式表（Cascading Style Sheet，CSS）和 HTML 的组合（请参阅 参考资料）。但是 DHTML 并不是向 Web 应用程序中添加互动操作的惟一方法。另一种重要方法是使用 Adobe Flash Player，使用它为 Web 站点添加交互操作已经有十年的历史。

第一版的 Flash 曾是用于创建动画图片的工具，而最新版本的 Flash 已经可以托管一个完整的界面，可用于控制 Web 服务访问并使用 ECMAScript（JavaScript 的正式版本）来提供完整的脚本支持。

了解 Flash

Flash Player 是集成到运行 Microsoft® Windows®、Mac OS X 和 Linux® 的计算机的 Web 浏览器中的一个插件。截至本文完稿时，最新版本的 Flash Player 是 V8。它是可以免费获得的，大多数浏览器都附带安装了此插件。它十分流行并且具有优秀的客户机渗透力 —— 而这种渗透力随着 YouTube 和 Google Video 这类服务的出现得到了提高，这些服务都使用 Flash 显示视频流。

Flash Player 只是天平的一端。要发挥作用，Flash Player 还需要使用一个 Flash 动画。此类动画通常是使用一种 Flash 的开发工具编译的文件，其文件扩展名为 .swf。但正如您将在本文中看到的那样，还可以使用 Ming 库用几乎与动态创建图片相同的方法来动态构建 .swf 文件，并在 Web 服务器上绘制图形。Ming 库利用由 PHP 代码构建的对象和方法在新的 .swf 文件中构建操作代码。

您可以通过两种方法中的任意一种方法来查看 Web 站点中的 .swf 文件。第一种方法只需导航到 .swf 文件的 URL。这样做将把 Web 服务器的整个内容区域替换为 Flash 动画。此方法便于进行调试，但主要的用法还是将动画嵌入到 HTML Web 页面的 <object> 标记中。该 <object> 标记然后再通过 URL 引用 SWF 动画。<object> 方法的优点在于您可以把动画放在页面的任意位置，并可通过 JavaScript 代码进行动态控制，就像处理页面中的任何其他元素一样。

清单 1 显示的是一个引用 SWF 动画的 <object> 标记的示例。

清单 1. 嵌入式 Flash 动画
    
<OBJECT classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#
        version=6,0,40,0"
WIDTH="550" HEIGHT="400">
<PARAM NAME="movie" VALUE="lines.swf">
<EMBED src="lines.swf" WIDTH="550" HEIGHT="400"
TYPE="application/x-shockwave-flash"
PLUGINSPAGE="http://www.macromedia.com/go/getflashplayer">
</EMBED>
</OBJECT> 

这组标记将引用一个名为 lines.swf 的动画。内部的 <embed> 标记用于确保 Flash 动画可以在安装了插件的各种浏览器中播放。

标记还把 Flash Player 的高度和宽度分别指定为 550 像素和 400 像素。非常值得注意的是，Flash 动画中的图形都是基于矢量的，这意味着当您使用 Flash 命令绘制线条和文本时，那些元素都被存储为坐标并且按照匹配显示区域的比例进行缩放。如您所见，Flash 动画有自己的坐标系统，您可以按照适合自己的方法使代码尽可能整洁。

 回页首 

Ming

本文中提供的使用 Flash 动画的第一种方法是使用 Ming 库动态生成它们。Ming 库是一个 PHP 库，其中有一组映射到 SWF 动画中的数据类型的对象：子图形、图形、文本、位图等等。我将不讨论如何构建和安装 Ming，因为其操作是特定于平台的而且并不特别简单（请参阅 参考资料）。在本文中，我使用了预编译的扩展 php_ming.dll 库用于 Windows 版本的 PHP。

必须指出的是，Ming 仍处于开发阶段。截至本文完稿时，库的版本是 V0.4，并且较老版本中的一些命令在最新版本中不能使用。我使用了 V0.4 撰写本文，因此，要使用这段代码，您需要使用这个版本。

清单 2 显示了使用 Ming 库实现的 HelloWorld 示例。

更详细地可以看看IBM网站：http://www.ibm.com/developerworks/cn/opensource/os-php-flash/index.html

多服务器日志合并统计的必要性

越来越多大型的WEB服务使用DNS轮循来实现负载均衡：使用多个同样角色的服务器做前台的WEB服务，这大大方便了服务的分布规划和扩展性，但多个服务器的分布使得日志的分析统计也变得有些麻烦。如果使用webalizer等日志分析工具对每台机器分别做日志统计：
1 会对数据的汇总带来很多麻烦，比如：统计的总访问量需要将SERVER1 SERVER2...上指定月份的数字相加。
2 会大大影响统计结果中唯一访客数unique visits，唯一站点数unique sites的等指标的统计，因为这几个指标并非几台机器的代数相加。

统一日志统计所带来的好处是显而易见的，但如何把所有机器的统计合并到一个统计结果里呢？
首先也许会想：多个服务器能不能将日志记录到同一个远程文件里呢？我们不考虑使用远程文件系统记录日志的问题，因为带来的麻烦远比你获得的方便多的多……
因此，要统计的多个服务器的日志还是：分别记录=>并通过一定方式定期同步到后台=>合并=>后用日志分析工具来进行分析。

首先，要说明为什么要合并日志：因为webalizer没有将同一天的多个日志合并的功能
先后运行
webalizer log1
webalizer log2
webalizer log3
这样最后的结果是：只有log3的结果。

能不能将log1<<log2<<log3简单叠加呢？
因为一个日志的分析工具不是将日志一次全部读取后进行分析，而且流式的读取日志并按一定时间间隔，保存阶段性的统计结果。因此时间跨度过大（比如2条日志间隔超过5分钟），一些日志统计工具的算法就会将前面的结果“忘掉”。因此， log1<<log2<<log3直接文件连接的统计结果还是：只有log3的统计结果。

多台服务日志合并问题：把多个日志中的记录按时间排序后合并成一个文件

典型的多个日志文件的时间字段是这样的：
log1 log2 log3
00:15:00 00:14:00 00:11:00
00:16:00 00:15:00 00:12:00
00:17:00 00:18:00 00:13:00
00:18:00 00:19:00 00:14:00
14:18:00 11:19:00 10:14:00
15:18:00 17:19:00 11:14:00
23:18:00 23:19:00 23:14:00

日志合并必须是按时间将多个日志的交叉合并。合并后的日志应该是：
00:15:00 来自log1
00:15:00 来自log2
00:16:00 来自log1
00:17:00 来自log3
00:18:00 来自log2
00:19:00 来自log1
....

如何合并多个日志文件？
下面以标准的clf格式日志（apache）为例：
apche的日志格式是这样的：
%h %l %u %t \"%r\" %>s %b
具体的例子：
111.222.111.222 - - [03/Apr/2002:10:30:17 +0800] "GET /index.html HTTP/1.1" 200 419

最简单的想法是将日志一一读出来，然后按日志中的时间字段排序
cat log1 log2 log3 |sort -k 4 -t " "
注释：
-t " ": 日志字段分割符号是空格
-k 4: 按第4个字段排序，也就是：[03/Apr/2002:10:30:17 +0800] 这个字段
-o log_all: 输出到log_all这个文件中

但这样的效率比较低，要知道。如果一个服务已经需要使用负载均衡，其服务的单机日志条数往往都超过了千万级，大小在几百M，这样要同时对多个几百M的日志进行排序，机器的负载可想而之……
其实有一个优化的途径，要知道：即使单个日志本身已经是一个“已经按照时间排好序“的文件了，而sort对于这种文件的排序合并提供了一个优化合并算法：使用 -m merge合并选项，
因此：合并这样格式的3个日志文件log1 log2 log3并输出到log_all中比较好方法是：
sort -m -t " " -k 4 -o log_all log1 log2 log3
注释：
-m: 使用 merge优化算法

注意：合并后的日志输出最好压缩以后再发给webalizer处理
有的系统能处理2G的文件，有的不能。有的程序能处理大于2G的文件，有的不能。尽量避免大于2G的文件，除非确认所有参与处理的程序和操作系统都能处理这样的文件。所以输出后的文件如果大于2G，最好将日志gzip后再发给webalizer处理：大于2G的文件分析过程中文件系统出错的可能性比较大，并且gzip后也能大大降低分析期间的I/O操作。

日志的按时间排序合并就是这样实现的。

日志的轮循机制

让我们关心一下数据源问题：webalizer其实是一个按月统计的工具，支持增量统计：因此对于大型的服务，我可以按天将apache的日志合并后送给 webalizer统计。WEB日志是如何按天（比如每天子夜00:00:00）截断呢？
如果你每天使用crontab：每天0点准时将日志备份成access_log_yesterday
mv /path/to/apache/log/access_log /path/to/apache/log/access_log_yesterday
的话：你还需要：马上运行一下：apache restart 否则：apache会因为的日志文件句柄丢失不知道将日志记录到哪里去了。这样归档每天子夜重启apache服务会受到影响。
比较简便不影响服务的方法是：先复制，后清空
cp /path/to/apache/log/access_log /path/to/apache/log/access_log_yesterday
echo >/path/to/apache/log/access_log

严肃的分析员会这样做发现一个问题：
但cp不可能严格保证严格的0点截断。加入复制过程用了6秒，截断的access_log_yesterday日志中会出现复制过程到00:00:06期间的日志。对于单个日志统计这些每天多出来几百行日志是没有问题的。但对于多个日志在跨月的1天会有一个合并的排序问题：
[31/Mar/2002:59:59:59 +0800]
[31/Mar/2002:23:59:59 +0800]
[01/Apr/2002:00:00:00 +0800]
[01/Apr/2002:00:00:00 +0800]

要知道[01/Apr/2002:00:00:00 这个字段是不可以进行“跨天排序”的。因为日期中使用了dd/mm/yyyy，月份还是英文名，如果按照字母排序，很有可能是这样的结果：排序导致了日志的错误
[01/Apr/2002:00:00:00 +0800]
[01/Apr/2002:00:00:00 +0800]
[01/Apr/2002:00:00:00 +0800]
[01/Apr/2002:00:00:00 +0800]
[01/Apr/2002:00:00:00 +0800]
[01/Apr/2002:00:00:00 +0800]
[01/Apr/2002:00:00:00 +0800]
[31/Mar/2002:59:59:59 +0800]
[31/Mar/2002:59:59:59 +0800]
[31/Mar/2002:23:59:59 +0800]
[31/Mar/2002:59:59:59 +0800]
[31/Mar/2002:23:59:59 +0800]

这些跨天过程中的非正常数据对于webalizer等分析工具来说简直就好像是吃了一个臭虫一样，运行的结果是：它可能会把前一个月所有的数据都丢失！因此这样的数据会有很多风险出现在处理上月最后一天的数据的过程中。

问题的解决有几个思路：
1 事后处理：
。所以一个事后的处理的方法是：用grep命令在每月第1天将日志跨月的日志去掉，比如：
grep -v "01/Apr" access_log_04_01 > access_log_new

修改SORT后的日志:所有跨天的数据去掉。也许对日志的事后处理是一个途径，虽然sort命令中有对日期排序的特殊选项 -M（注意是：大写M），可以让指定字段按照英文月份排序而非字母顺序，但对于apache日志来说，用SORT命令切分出月份字段很麻烦。（我尝试过用 "/"做分割符，并且使用“月份” “年:时间”这两个字段排序）。虽然用一些PERL的脚本肯定可以实现，但最终我还是放弃了。这不符合系统管理员的设计原则：通用性。并且你需要一直问自己：有没有更简单的方法呢？
还有就是将日志格式改成用TIMESTAMP（象SQUID的日志就没有这个问题，它的日志本身就是使用TIMESTAMP做时间时间戳的），但我无法保证所有的日志工具都能识别你在日期这个字段使用了特别的格式。

2 优化数据源：
最好的办法还是优化数据源。将数据源保证按天轮循，同一天的日志中的数据都在同一天内。这样以后你无论使用什么工具（商业的，免费的）来分析日志，都不会因为日志复杂的预处理机制受到影响。

首先可能会想到的是控制截取日志的时间：比如严格从0点开始截取日志，但在子夜前1分钟还是后一分钟开始截取是没有区别的，你仍然无法控制一个日志中有跨 2天记录的问题，而且你也无法预测日志归档过程使用的时间。
因此必须要好好考虑一下使用日志轮循工具的问题，这些日志轮循工具要符合：
1 不中断WEB服务：不能停apache=>移动日志=>重启apache
2 保证同一天日志能够按天轮循：每天一个日志00:00:00-23:59:59
3 不受apache重启的影响：如果apache每次重启都会生成一个新的日志是不符合要求的
4 安装配置简单

首先考虑了apache/bin目录下自带的一个轮循工具：rotatelogs 这个工具基本是用来按时间或按大小控制日志的，无法控制何时截断和如何按天归档。
然后考虑logrotate后台服务：logrotate是一个专门对各种系统日志（syslogd，mail）进行轮循的后台服务，比如SYSTEM LOG，但其配置比较复杂，放弃，实际上它也是对相应服务进程发出一个-HUP重启命令来实现日志的截断归档的。

在apache的FAQ中，推荐了经过近2年发展已经比较成熟的一个工具cronolog：安装很简单：configure=>make=> make install

他的一个配置的例子会让你了解它有多么适合日志按天轮循：对httpd.conf做一个很小的修改就能实现：
TransferLog "|/usr/sbin/cronolog /web/logs/%Y/%m/%d/access.log"
ErrorLog "|/usr/sbin/cronolog /web/logs/%Y/%m/%d/errors.log"

然后：日志将写入
/web/logs/2002/12/31/access.log
/web/logs/2002/12/31/errors.log
午夜过后：日志将写入
/web/logs/2003/01/01/access.log
/web/logs/2003/01/01/errors.log
而2003 2003/01 和 2003/01/01 如果不存在的话，将自动创建

所以，只要你不在0点调整系统时间之类的话，日志应该是完全按天存放的（00:00:00-23:59:59），后面日志分析中： [31/Mar/2002:15:44:59这个字段就和日期无关了，只和时间有关。

测试：考虑到系统硬盘容量，决定按星期轮循日志
apache配置中加入：
#%w weekday
TransferLog "|/usr/sbin/cronolog /path/to/apache/logs/%w/access_log"

重启apache后，除了原来的CustomLog /path/to/apche/logs/access_log继续增长外，系统log目录下新建立了 3/目录（测试是在周3），过了一会儿，我忽然发现2个日志的增长速度居然不一样！
分别tail了2个日志才发现：
我设置CustomLog使用的是combined格式，就是包含（扩展信息的），而TransferLog使用的是缺省日志格式，看了apache的手册才知道，TransferLog是用配置文件中离它自己最近的一个格式作为日志格式的。我的httpd.conf里写的是：
LogFormat ..... combined
LogFormat ... common
...
CustomLog ... combined
TransferLog ...

所以TrasferLog日志用的是缺省格式，手册里说要让TRANSFER日志使用指定的格式需要：
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""
TransferLog "|/usr/local/sbin/cronolog /path/to/apache/logs/%w/access_log"

重启，OK，日志格式一样了。
这样的设置结果其实是同时在logs目录下分别记录2个日志access_log和%w/access_log，能不能只记录%w/下的日志那？
查apache手册，更简单的方法：直接让CustomLog输出到cronolog归档日志，并且还能指定格式。
CustomLog "|/usr/local/sbin/cronolog /path/to/apache/logs/%w/access_log" combined

最后是一个日志同步的问题。

任务：每天凌晨找到前1天的日志，另存一个文件准备发送到服务器上。
比如我要保留前1周的日志：每天复制前1天的日志到指定目录，等待日志服务器来抓取：
/bin/cp -f /path/to/apache/logs/`date -v-1d +%w`/access_log /path/for/backup/logs/access_log_yesterday

在FREEBSD上使用以下命令
date -v-1d +%w
注释：
-v-1d: 前1天，而在GNU/Linux上这个选项应该是date -d yesterday
+%w: weekday，由于使用的都是标准时间函数库，所有工具中的WEEKDAY定义都是一样的 0-6 => 周日－周六

注意：
写到CRONTAB里的时候"%"前面需要加一个"\"转义：每天0点5分进行一次日志归档，
另外一个问题就是在cront中需要用：rm -f {} ; 而不是rm -f {}\;
5 0 * * * /bin/cp /path/to/logs/`date -v-1d +\%w`/access_log /path/to/for_sync/logs/access_yesterday
37 10 * * * /usr/bin/find /home/apache/logs/ -name access_log -mtime +1 -exec /bin/rm -f {} ;

首次开始cronolog日志统计是周3，一周以后日志又将轮循回3/access_log
但这次日志是追加到3/access_log还是重新创建一个文件呢？>>access_log or >access_log？
我测试的结果是日志将被追加：
[01/Apr/2002:23:59:59 +0800]
[01/Apr/2002:23:59:59 +0800]
[08/Apr/2002:00:00:00 +0800]
[08/Apr/2002:00:00:00 +0800]

肯定是不希望每次日志还带着上周的数据的并重复统计一次的（虽然对结果没影响），而且这样%w/下的日志不是也越来越多了吗？
解决方法1 把每天的cp改成mv
解决方法2 每天复制完成后：删除6天以前的access_log日志
find /path/to/apache/logs -name access_log -mtime +6 -exec rm -f {}\;
多保留几天的日志还是有必要的：万一日志分析服务器坏了一天呢？

以下是把apache安装在/home/apache下每天统计的一个脚本文件：
#!/bin/sh

#backup old log
/bin/cp -f /home/apache/logs/`date -d yesterday +%w`/access_log /home/apache/logs/access_log_yesterday

#remove old log
/usr/bin/find /home/apache/logs -name access_log -mtime +6 -exec rm -f {}\;

#analysis with webalizer
/usr/local/sbin/webalizer

总结：
1 用 cronolog 干净，安全地轮循日志
2 用 sort -m 排序合并多个日志


参考资料：

日志分析统计工具：
http://directory.google.com/Top/Computers/Software/Internet/Site_Management/Log_Analysis/

Apche的日志设置：
http://httpd.apache.org/docs/mod/mod_log_config.html

Apache的日志轮循：
http://httpd.apache.org/docs/misc/FAQ.html#rotate

Cronolog
http://www.cronolog.org

Webalizer
http://www.mrunix.net/webalizer/
Webalzer的Windows版
http://www.medasys-lille.com/webalizer/

AWStats的使用简介
http://www.chedong.com/tech/awstats.html

附1：Webalizer配置文件说明：重要的地方做了翻译并附有一些重要的配置修改

#
# Webalizer 样例配置文件
# Copyright 1997-2000 by Bradford L. Barrett (brad@mrunix.net)
# 翻译： 车东 (chedong@bigfoot.com)
#
# Distributed under the GNU General Public License.  See the
# files "Copyright" and "COPYING" provided with the webalizer
# distribution for additional information.
#
# 这是一个Webalizer (版本 2.01)的配置文件样例
# 所有以'#'开始的行都是被程序忽略的注释，此外空白行也会被跳过，其他行都是具体的配置选项。
# 并按照"ConfigOption  Value"的格式，ConfigOption是合法的配置选项关键词，而Value是相应选项对应的值
# 非法的键/值会被忽略并会有相应的警告提示。关键词和值之间至少需要一个空格或制表符tab分割
#
# 从0.98版本开始，Webalizer会找缺省在当前目录下找一个名为webalizer.conf缺省配置文件
# 如果没有找到，会使用/etc/webalizer.conf


# LogFile 定义了WEB服务的日志文件，如果这里没有定义，并且命令行参数也没有指定文件名，
# 则将STDIN（系统标准输入）作为输入数据源
# 如果日志文件扩展名为'.gz' (是一个gzip压缩文件),程序会一边读取一边进行解压缩。

LogFile        /home/apache/log/access_log_yesterday

# LogType 定义了日志的类型，Webalizer一般用于CLF和Combined格式的WEB服务日志格式
指定这个选项，你可以处理FTP日志(比如wu-ftp生成的xferlog，和Squid自己的日志
值可以是：'clf', 'ftp' 或'squid', 缺省是'clf'
# JNH : 新的'iis'是为IIS设计的，IIS4缺省使用标准日志格式，IIS5缺省使用W3C格式
# webalizer会自动根据日志的文件名进行识别：标准格式的日志文件名以I开头，W3C的是E
# 你可以在一个目录下同时存放2种日志，webalizer会全部读取并生成一份报告

LogType    iis

# OutputDir 报告的输出目录地址，必须是完整的全路径名，但相对路径也许也行，
# 如果没有指定，输出目录就是当前目录。

OutputDir      /home/apache/htdocs/usage/

# HistoryName 允许你设置webalizer生成的历史数据文件名
# 历史数据文件保存了12个月内的数据，这些数据会用来生成首页的HTML页面index.html
# 缺省文件名是："webalizer.hist"，缺省存放在指定的输出目录中， 也可以使用绝对路径指定到其他目录中。

#HistoryName    webalizer.hist

# Incremental 增量处理允许你处理被分隔成多个小文件的大日志，对于大型站点的按周，按天的日志轮循会非常有用
# 为了继续上次的处理，Webalizer在退出前会保存当时处理的数据并在下次运行是恢复当时的状态
在这个模式下，Webalizer会扫描并忽略重复的记录，请看README文件，里面有更详细的解说
值可以是：'yes'或'no'缺省为'no'.
# 'webalizer.current'这个文件用来保存当前数据，位置在OutputDir设置的输出目录中
# 启用这个选项前，请至少阅读一下README文件中的增量处理一节

Incremental    yes

# IncrementalName 允许你设置保存当前数据的文件名，和HistoryName选项一样，除非设置绝对路径，否则文件就在缺省输出目录中，
# 这个选项只有在启用了Incremental模式后才有意义

#IncrementalName    webalizer.current

# ReportTitle是标题文字，除非这个字符串是空的，否则主机名会空一格后显示在后面，
# 缺省是英文："Usage Statistics for".

#ReportTitle    Usage Statistics for

# HostName 定义了报告对应的主机名，用在报告的标题和URL统计里，这样
# 即使在一个虚拟主机的统计中，点击URL统计的链接也可以转向相应的正确地址。
# 或者生成报告的服务器是在另外一台机器，clicking on URL's in the report to go to the proper location in
# the event you are running the report on a 'virtual' web server,
# or for a server different than the one the report resides on.
# 如果这里没有指定webalizer会尝试调用uname命令获得系统的主机名，如果失败缺省为"localhost"

HostName       www.chedong.com

# HTMLExtension 允许你设置生成报告的文件扩展名，一般缺省是"html",但你也可以根据站点改成你需要的名字
(像配置PHP一样 embeded pages)?

#HTMLExtension  html

# PageType 你告诉Webalizer那种类型的URL是你定义的'页面访问'(Page View).  大部分人认为一个html或cgi请求文档是页面，
# 而嵌入在页面中的图片和声音不算，如果没有指定，如果是WEB日志统计，页面的扩展名就是'htm*'和'cgi'，
# 如果是ftp日志，扩展名就是'txt' 对于Servlet这样没有扩展名的请求Webalizer也是算页面的。

PageType    htm*
PageType    cgi
PageType    asp
PageType    p*
#PageType    phtml
#PageType    php3
#PageType    pl

# UseHTTPS 如果分析的站点使用安全服务器，URL的链接将是以'https://'开头，而不是缺省的'http://'.
如果需要，把它设置成'yes'。缺省是'no'.  这个配置只影响'Top URL's'里的链接.

#UseHTTPS       no

# DNSCache 指定了用于反相DNS解析的DNS缓存文件，如果你希望对所有日志中所有的IP地址进行反相域名解析
# addresses found in the log file.  如果没有指定绝对路径（文件名不是以'/'开头），这个文件缺省就在输出目录下
更多详细说明请参考DNS.README
# JNH : 如果你使用ListServer选项，你必须指定DnsCache的全路径

#DNSCache    dns_cache.db

# DNSChildren 允许你设置用多少个"子"进程进行DNS解析和更新DNS缓存文件。
# 如果指定了数字，Webalizer会创建DNS缓存文件并且每次运行都会更新，DNS解析会在
日志分析之前根据指定的数值调起子进程进行。如果使用DNS解析，DNS缓存文件名也必须指定。
# DNS lookups.  If used, the DNS cache filename MUST be specified as
# well.  缺省值是0，等于禁用DNS缓存文件，子进程的个数可以是用1 到100之间，如果更大会影响系统运行。
比较合理的值是5到20之间，更多详细信息请参考DNS.README

#DNSChildren    0

# HTMLPre 定义了输出页面中最开头的HTML代码，缺省是以下的DOCTYPE声明
# 每行最长是80个字符，如果需要更多代码可以使用多条配置。

#HTMLPre <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

# HTMLHead 定义了插入到<HEAD></HEAD>中间，紧接在<TITLE>行后的HTML代码
# 每行最长是80个字符，如果需要更多代码可以使用多条配置。

#HTMLHead <META NAME="author" CONTENT="The Webalizer">

# HTMLBody 定义了第一行<BODY>标签的HTML代码，缺省如下：
# 每行最长是80个字符，如果需要更多代码可以使用多条配置。


#HTMLBody <BODY BGCOLOR="#E8E8E8" TEXT="#000000" LINK="#0000FF" VLINK="#FF0000">

# HTMLPost 定义了输出页面中紧跟在第个<HR>标签后面紧跟在标题
# 和"summary period"-"Generated on:"这几行后面的代码。
# As with HTMLHead, you can define as many of these as you want and
# they will be inserted in the output stream in order of apperance.
# 每行最长是80个字符，如果需要更多代码可以使用多条配置。

２００１年秋季网络泡沫的破灭标志着互联网的一个转折点。很多人得出结论说，互联网被过分夸大了，实际上，泡沫和随之而来的衰退看上去是所有科技革命的共同特点。衰退是正处于上升期的科技准备占据中央舞台的特色。伪装者被逐出门外，真正的成名故事显示出他们的实力，开始理解一个事物与其他分开的原因。

Web 2.0的概念开始于O’Reilly与 MediaLive International的一个献计献策会。网络先锋人物和O’Reilly公司副总裁Dale Dougherty指出，网络非但没有破灭，而且随着许多令人激动的新程序和网站让人惊讶的突然规律性出现，网络比以往的作用更重要。更重要的是，在互联网灾难中幸存下来的公司看上去有一些共同的特点。.com公司的垮掉能在某种程度上标志互联网的转折点吗, web 2.0这样的称呼有意义吗？我们同意它的确是，web 2.0大会就这样诞生了。

在那以后的一年半时间内，web 2.0这个词就无疑已经生根，在Google上有超过９５０万个引用结果。但仍有大量对web 2.0含义的不同观点，一些人谴责这只不过是一个毫无意义的市场时髦吵作词汇（buzzword），其他人则认为它是一个新的传统概念。

本文旨在阐明我们通过web2.0想要表达的含义。

在最初的集体讨论上，我们用例子阐明了我们对web2.0的理解。

Web 1.0―> Web 2.0
DoubleClick―>Google AdSense
Ofoto（网上照片
贮存和共享服务的提供商）―>Flickr
Akamai（阿卡迈技术公司）―>BitTorrent
mp3.com―>Napster
不列颠百科全书在线―>Wikipedia
个人网站―>网络日志（博客、部落格）
evite―>upcoming.org and EVDB
域名投机买卖―>搜索引擎优化（SEO）
网页浏览―>每次点击成本
屏幕抓取―>网络服务
发表/出版―>参与
内容管理系统（CMS）―>维基（wiki）
目录(分类)―>标签(“folksonomy”)
粘性―>聚合

这个表格还可以不断往前进。但是，究竟什么可以让我们确定一种程序或道路是web 1.0，而另外一种则是web 2.0呢?（这个问题非常迫切，因为web 2.0 概念已经非常流行，许多公司把它当作市场时髦词汇了，却并不真正理解它的含义。问题特别困难，因为许多对时髦词汇有癖好的创业型公司绝对不是web 2.0。其他有些程序如napster和BT被认为是web2.0，但它们甚至不是适当的网络应用程序！译者注：应该是由于版权问题）
web 1.0有一些被成功故事以及最有趣的新应用程序证明的原则，下面是列表。

1.所有的标记都必须要有一个相应的结束标记
以前在HTML中，你可以打开许多标签，例如<p>和<li>而不一定写对应的</p>和</li>来关闭它们。但在XHTML中这是不合法的。XHTML要求有严谨的结构，所有标签必须关闭。如果是单独不成对的标签，在标签最后加一个"/"来关闭它。例如:
<br /><img height="80" alt="网页设计师" src="../images/logo_w3cn_200x80.gif" width="200" />

2.所有标签的元素和属性的名字都必须使用小写
与HTML 不一样，XHTML对大小写是敏感的，<title>和<TITLE>是不同的标签。XHTML要求所有的标签和属性的名字都必须使用小写。例如：<BODY>必须写成<body> 。大小写夹杂也是不被认可的，通常dreamweaver自动生成的属性名字"onMouseOver"也必须修改成"onmouseover"。

3.所有的XML标记都必须合理嵌套
同样因为XHTML要求有严谨的结构，因此所有的嵌套都必须按顺序，以前我们这样写的代码：
<p><b></p></b>
必须修改为：
<p><b></b></p>
就是说，一层一层的嵌套必须是严格对称。

4.所有的属性必须用引号""括起来
在HTML中，你可以不需要给属性值加引号，但是在XHTML中，它们必须被加引号。例如:
<height=80>
必须修改为：
<height="80">
特殊情况，你需要在属性值里使用双引号，你可以用"，单引号可以使用'，例如：
<alt="say'hello'">

5.把所有<和&特殊符号用编码表示
任何小于号（<），不是标签的一部分，都必须被编码为& l t ;
任何大于号（>），不是标签的一部分，都必须被编码为& g t ;
任何与号（&），不是实体的一部分的，都必须被编码为& a m p;
注：以上字符之间无空格。

6.给所有属性赋一个值
XHTML规定所有属性都必须有一个值，没有值的就重复本身。例如：
<td nowrap> <input type="checkbox" name="shirt" value="medium" checked> 必须修改为：
<td nowrap="nowrap"> <input type="checkbox" name="shirt" value="medium" checked="checked">
 
7.不要在注释内容中使“--”
“--”只能发生在XHTML注释的开头和结束，也就是说，在内容中它们不再有效。
例如下面的代码是无效的:
<!--这里是注释-----------这里是注释-->
用等号或者空格替换内部的虚线。
<!--这里是注释============这里是注释-->
以上这些规范有的看上去比较奇怪，但这一切都是为了使我们的代码有一个统一、唯一的标准！以便于将来的数据再利用！！