统计工具R在排查和诊断中的实战

排查和诊断需要统计工具？

排查和诊断过程，就是数据处理过程。

有时候只要处理过程探索到一个信号出现了就足以确定致因和解决问题了，至少也会得到进一步的线索。比如，客户ECS并发访问量上不去，如果发现对进程能打开多少文件描述符有限制。那么，我们差不多就确定了致因，对于如何解决问题也有了答案。

我们可以把上面排查和诊断的过程规范化为基于数据回答问题的过程。对这个过程，我们的预期是找到一个信号，这个信号可以确定致因，同时也对解决问题给出线索或者依据。比如，上面的例子，我们就是基于ECS的系统日志、业务日志和运行时信息来回答“为什么并发量上不去”问题的过程。过程的结果是我们找到了进程能打开文件描述符数量受限这个信号。

如果就问题和致因信号关系而言，上面提到的例子是简单的。因为问题和信号出现与否有关，是非此即彼的关系。简单计，我们把这种关系称之为“二进制关系”。也就是说，信号出现，就会导致问题。这种情况下，简单的cat、grep命令探索数据，搜寻确认信号出现与否就足够了。但是，如果问题和信号之间的关系不是这种非此即彼的二进制关系，比如，是和信号出现的频率有关系。这种情况下，如果信号往往是在数天甚至几周内都有出现，即使我们基于经验能够把信号和问题联系起来，可能也不易让客户接受我们的排查和诊断过程以及结论，而且仅凭经验，也有不小的误判概率。

更为复杂的情形可能是问题和数据中某些信号集合的某些整体的特征相关。这些特征不使用工具统计汇总就无法被识别和确认。比如，与某个信号在一分钟内连续出现的频率有关，而与一分钟内出现的、总的次数关系不大。这种情形下，直接的观察是很难处理的，尤其是数据量比较大时。因此，我们需要工具改善排查和诊断过程。

对于因果之间没有简单对应关系的情形，抽象模型和处理方式，无论是理论还是实践，都是种类繁多。这里我们只介绍和引入传统的统计手段。

什么是R以及为什么选择R？

大多数编程语言，在其是否图灵完备的意义上，是没有区别的。但是，不同语言提供的抽象支持，在生产力和软件工程方面却相差悬殊。比如，把一个文件的内容输出到终端上，使用cat命令，估计简单了解过UNIX环境的工程师都可以；但是用汇编语言来做，估计得难道一大片。

那么，什么是R呢？学究一点，R是以统计处理为其领域的编程语言和平台。通俗一点，R是一个统计工具。就是说，R是围绕着统计来提供其抽象的，正如C++、Java、和Ruby是围绕对象来提供抽象的。

但是，对于诸多统计软件平台，就易用性和学习曲线而言，诸如SPSS和SAS等商用软件无疑是占有优势的。而开源软件，也不止R一家。比如Python社区就提供了多种实现供选择。而且现在还有Figaro，自称

Figaro is a probabilistic programming language that supports development of very rich probabilistic models and provides reasoning algorithms that can be applied to models to draw useful conclusions from evidence. Both model representation and reasoning algorithm development can be challenging tasks.

那么，我们为什么选择R这个平台呢？

首先，R是S语言的一个开源实现，S出身AT&T。因此R可以和UNIX经典工具等适配使用。

除此之外，在某种意义上，你可以把R看成是实现了M-expression的Scheme的一种实现。你在函数式编程里看到的各种玄妙都可以在R中尝试一番。

再者，R提供了强大的绘图能力。一图胜千言，尤其是在和客户交流时。

最后一点，有众多的以R为主题的出版书籍；google内部大规模使用了R；微软在其产品里直接支持R。

因此，R是个不错的选择。其作为语言既有命令式语言的语法，又有函数式编程的核，又因其目标领域是统计，因此又能改变你的思考方式 ，加之重量客户的投入，可以预期你的投资很有保证。如果正在提升自己，或者计划提升自己，为什么不选择R呢？

如何安装、启动和退出R以及安装R包？

R作为开源软件，支持Windows、MacOS和Linux等主流平台，但是官方安装手册只提供了编译安装方式。其实，对于Linux和MacOS，都有软件包管理软件可用，直接通过这样的工具安装即可。

安装

比如，对于MacOS，只要部署了homebrew可用，可以这样安装

brew cask install r-app

对于Linux系统，如果是RHEL-like系统，比如，Fedora或者CentOS（在较新的Fedora中请使用dnf替换yum；CentOS中需要部署EPEL的源），可以这样安装

yum -y install R

对于Debian/Ubuntu，可以这样安装

apt-get -y install r-base

对于Windows（其实也包括MacOS和Linux），其官方网站提供了预编译的二进制包，直接下载安装即可。当然，微软自己也提供了增强版本，感兴趣请到MRAN下载。

除了R，这里也推荐RStudio，R的IDE， 直接下载安装就好。

启动和退出R

鉴于被困在不熟悉的软件中无法退出都成了头条，为了避免恶劣的第一印象，我们对于如何退出R，特意说明下。

其实，如果使用的是图形界面，那么你如何操作浏览器窗口，就怎么操作R的图形界面就好。如果是使用的是终端界面呢？

进入R

R

退出R

q()

使用上面的退出方式，R会要求确认是否保存工作区。如果你想不确认就退出，那么你不想保存，那么

q(save="no")

如果想要保存，那么

q(save="yes")

安装R包

由Perl其，流行的脚本语言都有一个类似CPAN的站点，R也不例外。因此，我们可以按需从CRAN下载、安装需要的包。

在使用图形界面时，可以选择恰当的菜单，填入相应的包名称即可。细节请参考图形界面的帮助页。对于终端用户，可这样处理

install.packages(c("ggplot2", "lubridate"))

R在排查和诊断过程中的位置

R在排查和诊断过程中的位置，可以用韦恩图表示如下。额外说明下这里的“黑客技术”不是指脚本小子或者骇客技术。

热身准备

安装必需的R包

接下来我们用两个实际排查的case来介绍R。在开始之前，因为后续需要，我们要先安装两个R包。启动R后，请在R中执行如下命令

install.packages(c("ggplot2", "lubridate"))

这两个包，ggplot2用以绘图，lubridate用以处理日期时间。

没有为处理时间日期熬过夜的人不足以论技术。

内容说明

我们用两个实际case来说明R在排查和诊断中的用途以及如何使用之。如何处理的第一个case，我们给出详细步骤。第二个case，从简。

处理流程

通用的数据处理

数据处理，我们以OSEMN为框架

  1. obtaining data/获取数据
  2. crubbing data/清洗数据
  3. exploring data/探索数据
  4. modeling data/建模数据
  5. interpreting data/解释数据

具体处理流程

我们把上述通用的处理流程改造如下，后续我们就使用之

第一个case：症状和初步排查

补充说明

因客户误操作，排查用的实例被突然释放了。因此，整个排查过程实际上前后是在两台不同的实例上进行的。这是为什么在此case中，后续部分步骤和数据有时会提到到两台实例。

症状

客户:

大批量ECS服务器遇到...CPU被打满的问题，主要消耗在cpu_sys上。

相应的CPU监控数据如下

初步分析

开始我们先排查是不是资源争抢问题。但根据云台的监控数据，我们很快排除了这种可能。物理机有48颗CPU，但是仅有一个CPU波动较大，而且其他47颗CPU的消耗都不高。尽管物理机的CPU的消耗与实例CPU消耗有同步现象，空闲率也同步有所下降，但波动非常轻微，物理机上的总的CPU消耗和负载变动不大。并且总的CPU资源非常宽松。单独CPU的监控数据也佐证了这一点。因此可以断定是客户的业务逻辑导致的其实例CPU消耗较高。因此排查继续。

物理机监控数据如下

第一个case：分析系统日志

因为CPU消耗升高的时间点已知，检查对应时点前后的messages日志，立刻有发现。rsyslog的omkafka插件报告报警信息

Failed to produce to topic 'mkApiNginx' partition 1: Local: Queue full

因此立刻校验rsyslog软件包，看看有哪些东西被变更。结果很快发现/etc/rsyslog.conf配置文件有变更

因此，客户的实例应该有一个把G级别日志传递出去的操作。IO/Network的监控数据佐证了这一点

但是，根据时间戳，这个原因只能解释实例CPU很短时间内的一个波动。因此，排查继续。

第一个case：分析业务日志

客户实例上的系统日志没有更多的内容供分析了。所以，接下来我们转向客户的业务日志。因为我们知道CPU消耗高的时间段，因此，需要找出所有的日志逐一核实具体时间段的记录

find / ! \( -path "/dev/" -o -path "/proc/" -o -path "/sys/" -o -path "/var/" \) -name "*log" | less

这里我们给出第二台实例上CPU占用100%的监控数据

对于找到的文件，我们逐一手工检查其内容，重点是CPU消耗升高的时间点前后。 很快，一个日志里反复出现的超时循环操作引起了我们的注意

但问题是，这个循环从06:40到23:30之间频繁出现，但并不是整个时间段内CPU消耗都高。因此，如何确认超时循环操作和CPU消耗高之间的关系呢？仅凭观察肯定不行了。所以，我们引入R。

数据获取和数据清洗

我们先把日志下载到本地， 而后我们先清洗数据。

首先过滤出所有的超时循环

grep 'Yar_Concurrent_Client::loop():' warning.log > clean_data

接着，用filter.pl脚本把一分钟内每次连续执行的次数统计出来

#!/usr/bin/perl

use strict;
use warnings;
use feature qw(say);

my $curr = q[];
my $prev = q[];
my $count = 0;
while (<>) {
    chomp;
    next if (!m!Yar_Concurrent_Client::loop! || m!^$!);
    m!\[2017-05-20 (\d\d:\d\d):\d\d\]!;
    $curr = $1;
    if ($prev eq q[]) {
        $prev = $curr;
        $count = 1;
    }
    if ($curr eq $prev) {
        $count++;
    } else {
        say qq[$prev $count];
        $prev = $curr;
        $count = 1;
        next;
    }
}
# to print the last record
say qq[$curr $count];

脚本执行效果如下

但是，对于00:19这样的时间表示，R中处理起来不方便。我们进一步把时间转换成数字

perl ./filter.pl clean_data | perl -nE 'chomp;m!^(\d+):(\d+)\s+(\d+)!;my $date=$1*60+$2;say "$date $3"'

脚本执行效果如下

我们把获取的数据放到一个文件里，并且给数据列加上名称以便在R里操作

echo 'Date Freq' > data
perl ./filter.pl clean_data | perl -nE 'chomp;m!^(\d+):(\d+)\s+(\d+)!;my $date=$1*60+$2;say "$date $3"' >> data

这样我们就拿到了数据，可以继续操作了

数据探索

尽管为处理方便计，我们已经把时间转为数字，但是显示结果时最好还是看到HH:MM形式的时间，更为方便。因此，我们给R提供一个格式化
函数

timeHM_formatter <- function(x) {
  h <- floor(x/60) %% 24
  m <- floor(x %% 60)
  lab <- sprintf("%02d:%02d", h, m)
  return(lab)
}

另外，为方便R操作，我们还做一下当前目录和本地化设置。为美观计，我们直接使用ggplot2包。

setwd("./R/case1")
Sys.setlocale(locale="zh_CN.UTF-8")
library(ggplot2)

首先，加载数据

CPU_OCUPATION = read.table(file="./data", header=TRUE)

我们先粗略地看看数据分布的情况

summary(CPU_OCUPATION$Freq)

收获不多

再通过散点图看看

qplot(CPU_OCUPATION$Date, CPU_OCUPATION$Freq) +
geom_point(colour="red") +
scale_x_continuous(name="date", breaks=seq(0, 1500, by=80), labels=timeHM_formatter) +
scale_y_continuous(name="loop density", breaks=seq(0, 120, by=5))

仔细和CPU消耗的监控数据比较，会发现CPU消耗高在时间段，也是散点图的热点区域

有了这个发现，根据时间段，我们能够确认CPU消耗高和散点图的热点是一一对应的

如果我们把散点图做适当的平移和反转操作，则对应就更明显

那么，我们的散点图及其热点区域表达的是什么意义呢？

数据建模

我们给出的散点图，粗略的说，x轴显示的是时间，y轴显示的是超时循环执行的次数。根据探索得出的结论，CPU飙高与超时循环有关，但是却与每分钟执行此循环总的次数关系不大。这方面探索的细节请参考“第一个case：探索数据细节”这一章。那么，我们在上面小结里给出的散点图里的点究竟表达了什么呢？

为了便于理解，我们分析清洗的中间结果

perl filter.pl clean_data > middle_data

有趣的发现如下

进一步比较监控数据和我们处理的数据

即在某一时刻，连续执行超时循环的次数越多，每次连续执行时执行的超时循环的数量分布的越连续、密集，则散点图上对应这个时刻的点就会连成一条线。如果这个时刻附近的时刻都有类似特性，就会生成色块，形成热点区域，此时CPU消耗会同步升高。

数据解释

因为客户看到散点图后即接受了我们的排查结论，并且立刻去调整其业务逻辑了，并没有进一步向我们解释业务方面的致因。因此，我们没有办法给出一个结合客户业务逻辑的解释。

第一个case：探索数据细节

探索每秒数据

一秒内可能不止一笔数据，因此我们过滤数据继之以排序

grep 'Yar_Concurrent_Client::loop():' warning.log | sort -n > clean_data_per_min

而后由如下的filter-per-min.pl脚本做第一次处理，抽取每秒的数据。坦白说，脚本名称应该为filter-per-sec.pl

#!/usr/bin/perl

use strict;
use warnings;
use feature qw(say);

my $curr = q[];
my $prev = q[];
my $count = 0;
while (<>) {
    chomp;
    next if (!m!Yar_Concurrent_Client::loop! || m!^$!);
    m!\[2017-05-20 (\d\d:\d\d:\d\d)\]!;
    $curr = $1;
    if ($prev eq q[]) {
        $prev = $curr;
        $count = 1;
    }
    if ($curr eq $prev) {
        $count++;
    } else {
        say qq[$prev $count];
        $prev = $curr;
        $count = 1;
        next;
    }
}
# to print the last record
say qq[$curr $count];

脚本执行效果如下

同样，把时间日期转换为数字

perl ./filter-per-min.pl clean_data_per_min | perl -nE 'chomp;m!^(\d+):(\d+):(\d+)\s+(\d+)!;my $date=($160+$2)60+$3;say "$date $4"'

脚本执行效果如下

步骤继续，我们把获取的数据放到一个文件里，并且给数据加上列名称

echo 'Date Freq' > data_per_min
perl ./filter-per-min.pl clean_data_per_min | perl -nE 'chomp;m!^(\d+):(\d+):(\d+)\s+(\d+)!;my $date=($160+$2)60+$3;say "$date $4"' >> data_per_min

这样我们就拿到了数据，可以探究一下每秒数据了

同样，我们提供如下格式化函数以便把时间显示为HH:MM:SS

timeHMS_formatter <- function(x) {
  h <- floor(x/3600)
  m <- floor((x/60) %% 60)
  s <- floor(x %% 60)
  lab <- sprintf("%02d:%02d:%02d", h, m, s)
  return(lab)
}

我们加载数据，先看看数据分布的大致情况

CPU_OCUPATION = read.table(file="./data_per_min", header=TRUE)
summary(CPU_OCUPATION)

结果如下

看看散点图

CPU_OCUPATION = read.table(file="./data_per_min", header=TRUE)
qplot(CPU_OCUPATION$Date, CPU_OCUPATION$Freq) +
geom_point(colour="red") +
scale_x_continuous(name="date", breaks=seq(0, 90000, by=7200), labels=timeHMS_formatter) +
scale_y_continuous(name="loop amonunt per second", breaks=seq(0, 36, by=4))

明显数据处理的粒度太小，看不出什么有意义的规律

探索每分钟连续执行循环数量

我们以每分钟为单位计数一下超时循环执行的次数。

CPU_OCUPATION = read.table(file="./data", header=TRUE)
factors.continue_loop.per.min = factor(CPU_OCUPATION$Date)
continue_loop.amount.per.min = tapply(CPU_OCUPATION$Date, factors.continue_loop.per.min, length)
qplot(unique(CPU_OCUPATION$Date), continue_loop.amount.per.min) +
geom_point(colour="red") +
scale_x_continuous(name="date", breaks=seq(19, 1420, by=120), labels=timeHM_formatter) +
scale_y_continuous(name="loop amount per minute", breaks=seq(0, 74, by=3))

得到结果如下，没有发现和CPU消耗数据相关的特征。比如，考察06:51时刻，CPU消耗100%，但是对应的连续循环数量却不多。

第二个case：症状和初步排查

症状

客户：

SSD云盘 IO延时在30ms以上

初步排查

初步排查确定，在客户的使用方式下，SSD云盘延迟基本就在30ms左右，并不是突发的异常情况。

进一步沟通后得知，客户业务高峰时段网络访问延迟从原来的30ms左右增至50ms以上，甚至会出现秒级延迟。客户通过逐行源码插入print语句，自行排查结论是SSD云盘IO延迟30ms是致因。

客户是使用curl工具存取一指定URL来度量访问延迟的。抓包结果显示确实有秒级延迟情形出现。那么，如果在出现问题前在客户的使用方式下SSD云盘的延迟就是30ms左右，那么，SSD云盘的延迟就不会是致因。因此排查继续。

根据测试的时间点，检查系统日志，一条报警记录进入了我们的视野

May 27 21:47:40 iZ2zeepzcp7dzdd9e3pe8dZ kernel: TCP: time wait bucket table overflow

相关的测试结果、抓包记录和日志报警信息整理如下。但问题是，报警信息和网络访问延迟增大有关系吗？

第二个case：系统日志排查和结论

此处和处理第一个case的步骤一致，只是处理逻辑有微调

  1. 从系统日志而非业务日志获取数据。
  2. 因为问题连续多日出现，因此这里我们获取了整个五月份的数据（因为lograte的工作机制，其实是获取的4周内的数据）。但是我们并不是从05月01日开始制作散点图的。
  3. 因为第2项，R中的时间戳格式化函数也相应做了调整。

按照处理第一个case的步骤，我们可以的到散点图如下

从散点图可以看到，从05月23日起，信号开始出现；自05月26日起，连续三日，每日10:30至次日凌晨01:28之间，信号出现。将图反馈给客户后，客户确认散点图热点区域出现的时段和延迟出现的时段同步。再结合抓包结果显示的时间消耗，客户接受了我们的排查结论。

问题是05月23日客户作了什么调整导致问题出现？结论出人意料，客户答复说05月23日暂时撤除了高防以便使用更稳定带宽的高防。

更进一步：R在工具化中的位置

由以上两个case可以看出，排查和诊断过程中，一如在其他数据处理过程中一样，引入R，使用得当，对于解决疑难杂症，颇见功效。而工具化是共享我们排查技能、流程和知识的合适媒介。因此有必要考察一下R在工具化中的位置。

正如先前已经提到的，排查和诊断过程就是数据处理过程。而R一直是诸如统计学家等数据处理从业者工具箱里最趁手的工具之一。而且就R支持的功能而言，前面我们流程中的每一步，均可由R实现。加之R成熟的社区、各种机器学习算法在R中也不乏高质量实现、不断改进与完善的API以及CRAN（一个R包共享与分发的站点）。因此，我们有理由相信，R或者类似R的组件在工具化中会扮演一个足够重要的角色。

同样，以我们前面给出的流程为例，设想我们要工具化之。比如，以从日志中搜集可能的致因信号为例。稍加考察你就会发现，我们肯定不是事先在头脑中记忆了各种可能的系统和业务致因信号后，再进行排查的。比如，第一个case中业务日志中的超时循环信号，对于不少同学应该都是初次见到。而且一直到解决掉客户的问题，我们也没有了解这个日志记录在业务逻辑中的意义。以工程师处理过程类比，很明显，工具化过程中，分类、聚类、预测，这些机器学习的基础功能模块，我们都需要。因此，工具化中必定有R或者类似R的组件。

所以，无论是手工排查和诊断，还是更进一步工具化，对于工程师而言，R都是上佳之选。

参考

  1. R官方站点
  2. 我需要学习R吗？
  3. 服务器诊所: 数据处理的利器 R
  4. R 和数据世界
  5. First-class citizen
  6. Google's R Style Guide
  7. R (programming language)
时间： 2024-10-29 21:39:23

统计工具R在排查和诊断中的实战的相关文章

Java正则表达式（三）、代码量统计工具（统计java源文件中注释、代码、空白行数量）

       比如想统计一个Java程序员一天写代码的工作量(如:有效代码多少行.空行多少.注释多少行等),这个小工具也许能做为一个参考的依据.     思路:因为每个java源文件的内容基本包括java语句.空白行.注释三部份组成(不包括注解),所以要统计某个文件这三部份的内容各占多少时,只需写三个匹配这几部份内容的正则表达式即可.然后通过IO流读取文件中的每一行,并根据正则匹配的结果,累加每部份匹配的数量即可.     注释行:单行注释(//).多行注释.文档注释.正则:((//)|(/\\

统计工具中一些对网站推广有很大作用的功能

&http://www.aliyun.com/zixun/aggregation/37954.html">nbsp;   近日,通过国内知名独立第三方数据统计分析服务提供商CNZZ(www.cnzz.com )处获悉,CNZZ对于公司旗下所有统计产品从用户体验角度出发,再次进行了大量功能性优化.此次新功能的推出,业内人士认为,众多细节的变化往往与创新密不可分,作为国内最大的独立第三方数据统计分析服务提供商CNZZ,在如今日益激烈的市场竞争中,构建强劲的企业核心竞争力,已成为其今日发

系统诊断小技巧（7）：利用Iptables进行排查和诊断的简易方案

TL;DR Iptables 严格说来,Iptables只是Linux系统防火墙用户空间的接口工具而已,但是,日常大家都以Iptables指称包括用户空间和内核空间在内的整个防火墙.这里我们也使用这个惯用法,但是,还是先明确下防火墙内核空间的名称(netfilter),这样大家容易理解为什么防火墙相关的命名往往有"nf"或者"netfilter"这样的字眼或者前缀. Iptables在内核的网络栈放置了钩子.通过给这些钩子提供回调函数,我们可以在内核网络栈中注入我们

hta应用—代码统计工具

统计 作者的blog: blog.never-online.net "Never Modules"-NCC(never code counter) tools-代码统计工具V1.01统计js,asp,aspx,cs,html,xml等 把源代码存为(hta)文件,因为hta文件没有状态栏,所以我这里建议大家存为html文件,这样可以在状态栏下看到NCC扫描的进度,我这里把NCC的maxloop设置为3000,所以文件统计到3000的时候,会自动终止,以防文件夹中文件太多造成运行的负担.

Python实现代码统计工具（终极篇）_python

本文对于先前系列文章中实现的C/Python代码统计工具(CPLineCounter),通过C扩展接口重写核心算法加以优化,并与网上常见的统计工具做对比.实测表明,CPLineCounter在统计精度和性能方面均优于其他同类统计工具.以千万行代码为例评测性能,CPLineCounter在Cpython和Pypy环境下运行时,比国外统计工具cloc1.64分别快14.5倍和29倍,比国内SourceCounter3.4分别快1.8倍和3.6倍. 运行测试环境本文基于Windows系统平台,运行和测

vmstat：一个标准的报告虚拟内存统计工具

什么是 RAM? 在智能手机世界,我们每一个人都知道 RAM.因此,我不想深入介绍,这样我就简要概括下.RAM 代表"随机访问内存Random Access Memory",是一种计算机数据存储,它会存储经常使用的程序来提升系统性能. 什么是虚拟内存? 虚拟内存是一种内存管理方式,计算机通过临时将最近未使用的程序数据从 RAM 转移到硬盘,以平衡或管理内存的短缺. 什么是 vmstat? vmstat 是一个标准的工具,它会报告 Linux 系统的虚拟内存统计.vmstat 会报告有关

牟长青：优秀站长工具推荐之网站速度诊断

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 一个网站能做好,用户体验很重要.其中网站打开速度,又是用户体验里最重要的一个环节.一个网站的功能做得再好,再有实用价值,但网站如果访问非常吃力,打开速度特慢,最终用户也只会选择放弃访问. 网站打开慢,曾经也是28推最大的软肋.因为之前28推服务器是电信单线,经常有部分地区的会员反映打开28推非常吃力,因此慢慢放弃登陆28推,或者减少来的次数.

常用的网站流量统计工具比较

比较|流量|统计 最近试用了几个流量统计工具,粗略的比较了一下,不当之处望指正: 163流量统计 :(没全面测试) 优点:几乎没有看到广告,页面干净 缺点:1.中规中矩,没有出彩的地方 2.安装后,网页显示速度有所降低,浏览器告警"阻挡cookie发送" 51Yes : 优点:1.客户地理位置统计用地图显示,并在地图用不同颜色标记各省的客户比例 2.功能较全面 缺点:广告超多 太极链 :(没全面测试) 优点:广告少 缺点:1.只对PV访问量大于5000的用户开通历史统计功能 2.统计响

做网站内容时先看统计工具或者能为你指明方向

这是大数据时代,一个讲究精准营销的时代,精准营销是靠什么呢?靠的不就是发数据为眼睛做更精准的推广吗?所以数据不管对于什么行业都是很重要的.对于我们做网站优化的人来说那也就更重要啦,在这里建议大家每天都去观察网站的各项数据.其实如果说到网站数据这块那就有很多东西值得跟大家说的,但今天只想跟大家讲一点,那就是利用数据做网站的内容.利用统计工具里面用户搜索进来的关键词来做内容,只有统计工具里面的关键词才是真正有用户需求的. 当然利用统计工具里的数据来做网站内容势必是需要这个网站是有数据的,那也就是说这