0x01 概述

前段时间监控到公司站点的手机号是否存在的接口被单IP高频率访问，站点解析到腾讯云上，LB后是20+腾讯云主机做Nginx代理，使用Filebeat+ELK收集监控此类异常行为，当前最新的是6.2，有些改动，我还是用5.5版本。

ELK可以当作一个MVC模型，logstash是controller层，Elasticsearch是一个model层，kibana是view层。



使用三台机器，配置和角色如下：

10.59.0.248(32核+64G内存) Logstash Elasticsearch(Master) Kibana

10.59.0.116(24核+32G内存) Logstash Elasticsearch(Data)

10.211.0.107(64核+64G内存) Logstash Elasticsearch(Data)

0x02 Filebeat

Filebeat的性能消耗要比logstash小的多，配置如下：



data/registry记录了文件读取的offset，如果文件data/registry不存在，则会重新发送文件。

配置tail_files: true 仅发送新的数据

0x03 Logstash

在logstash-5.4.0/bin/logstash.lib.sh文件第一行添加



所遇到的问题：

1）ELK部署运行后，非常常见的一个现象是429错误，如下所示：

[2018-04-04T09:08:16,479][INFO ][logstash.outputs.elasticsearch] retrying failed action with response code: 429 ({"type"=>"es_rejected_execution_exception", "reason"=>"rejected execution of org.elasticsearch.transport.TransportService$7@4e1276c3 on EsThreadPoolExecutor[bulk, queue capacity = 200, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@4892020c[Running, pool size = 24, active threads = 24, queued tasks = 200, completed tasks = 4786420]]"})

表示Elasticsearch处理不过来了。

在ES5.0以后，Elasticsearch将bulk、flush、get、index、search等线程池完全分离，自身的写入不会影响其他功能的性能。

来查询一下ES当前的线程情况：



其中



最需要关注的是rejected。当某个线程池active==threads时，表示所有线程都在忙，那么后续新的请求就会进入queue中，即queue>0，一旦queue大小超出限制，那么elasticsearch进程将拒绝请求（bulk HTTP状态码429），相应的拒绝次数就会累加到rejected中。

解决方案为优化logstash.yml的参数，修改batch.size参数为3000，增加每次发送的事件数，从而降低调用ES的频率。另外修改worker/output.workers为CPU数。

logstash.yml配置如下：



2）增加Logstash JVM内存，Logstash报错内存溢出



需要修改logstash启动文件bin/logstash



Logstash配置文件如下：

input {

    beats {

        port => 5044

      }

}



filter{

    grok{

        match => {

            "message" => "%{IP:client-ip}(,\s)?(?<proxy-ip>[\d\.,\s]*) (%{USER:ident}|-) (%{USER:auth}|-) \[%{HTTPDATE:timestamp}\] \"(?:%{WORD:verb} %{URIPATH:uri}%{DATA:parameter}(?: HTTP/%{NUMBER:http_version})?|-)\" %{NUMBER:status-code} %{NUMBER:bytes} \"(%{GREEDYDATA:referer}|-)\" \"(%{GREEDYDATA:user-agent}|-)\" (%{BASE16FLOAT:response_time}|-) (%{BASE16FLOAT:request_time}|-) \"(%{GREEDYDATA:cookie}|-)\" \[%{GREEDYDATA:servername}\]"

        }

    }

    if ([uri] =~ "\.(js|css)$"){

        drop {}

    }

    date {

        match => ["timestamp", "dd/MMM/yyyy:HH:mm:ss Z"]

        target => "@timestamp"

    }

    ruby {

        code => "event.set('timestamp', event.get('@timestamp').time.localtime + 8*60*60); event.set('@timestamp', event.get('timestamp'))"

    }

    if ([verb] == "POST")

    {

        mutate {

            add_field => {"dynamic" => 1}

        }

    }

    else if ([verb] == "GET" and [parameter])

    {

        mutate {

            add_field => {"dynamic" => 1}

        }

    }

    else {

        mutate {

            add_field => {"dynamic" => 0}

        }

    }

    mutate {

        remove_field => [ "message" ]

    }

}



output {

    if "_grokparsefailure" not in [tags] {

        elasticsearch {

            hosts => "10.59.0.248:9200"

            index => "nginx_%{+YYYY.MM.dd}"

        }

    }

}

这里grok正则匹配非常耗费性能，可以使用dissect替换。

0x04 ELasticsearch

ElasticSearch是一个基于Lucene的搜索服务器，Lucene是一个开源的全文检索引擎工具包（类似于Java api），而Elasticsearch底层是基于这些包，对其进行了扩展，提供了比Lucene更为丰富的查询语言，可以非常方便的通过Elasticsearch的HTTP接口与底层Lucene交互。Elasticsearch是Lucene面向企业搜索应用的扩展，极大的缩短研发周期。

在if [ -x “$JAVA_HOME/bin/java” ]; then上添加两行



启动时遇到其他问题汇总：

1) 启动 elasticsearch 如出现异常  can not run elasticsearch as root

解决方法：创建ES 账户，修改文件夹 文件 所属用户 组

2) 启动异常：ERROR: bootstrap checks failed

system call filters failed to install; check the logs and fix your configuration or disable system call filters at your own risk

解决方法：在elasticsearch.yml中配置bootstrap.system_call_filter为false，注意要在Memory下面:

3) 启动后，如果只有本地可以访问，尝试修改配置文件 elasticsearch.yml中network.host(注意配置文件格式不是以 # 开头的要空一格， ： 后要空一格)

为 network.host: 0.0.0.0

默认端口是 9200

注意：关闭防火墙 或者开放9200端口

4) ERROR: bootstrap checks failed



解决方法：切换到root用户，编辑limits.conf 添加类似如下内容



添加如下内容:



5)


解决：切换到root用户，进入limits.d目录下修改配置文件。



修改如下内容：



#修改为



6)



解决：切换到root用户修改配置sysctl.conf，添加下面配置：



并执行命令：



然后，重新启动elasticsearch，即可启动成功。

Elasticsearch Master配置文件如下：



0x05 ELasticsearch plugins

1) Head插件



下载Node.js：



配置node.js环境变量：



执行source /etc/profile使环境变量生效

查看当前head插件目录下有无node_modules/grunt目录：

没有则执行命令创建：



安装head插件：



编辑Gruntfile.js

文件93行添加



检查head根目录下是否存在base文件夹，没有：将 _site下的base文件夹及其内容复制到head根目录下

修改elasticsearch.yml，添加：



启动grunt server：在head下运行



访问head插件：http://localhost:9100

2) bigdesk插件

bigdesk是elasticsearch的一个集群监控工具，可以通过它来查看es集群的各种状态，如：cpu、内存使用情况，索引数据、搜索情况，http连接数等。

安装步骤：

git clone https://github.com/hlstudio/bigdesk

cd bigdesk/_site/

python -m SimpleHTTPServer

0x06 ELasticsearch 优化

1) shard与Replicas

shard不能修改，一个node不要超过2个shard。

replica只会参与读操作，它的主要作用就是提高集群错误恢复的能力，并且可以在集群建立之后变更。

2) 索引存储

最好是使用SSD，没有的话，最好将es数据节点配置多个数据存储路径，尽量避免使用远程文件系统存储，如NFS 或 SMB。

3) “refresh_interval”: “30s”

优化点： 减少刷新频率，降低潜在的写磁盘性能损耗

另外如果需要一次加载较大的数据量进 index 里面时，可以先禁用 refresh ，把 index.refresh_interval 设置成为 -1 ，把 index.number_of_replicas 设置成 0。暂时把多个shard副本关闭，这样做可以大大加快索引速度。当初始化索引完成，可以将 index.refresh_interval 和 index.number_of_replicas 设置回原来的值。

4) translog优化

Lucene只有在commit的时候才会把之前的变更持久化存储到磁盘（每次操作都写到磁盘的话，代价太大），在commit之前如果出现故障，上一次commit之后的变更都会丢失

为了防止数据丢失，Lucene会把变更操作都记录在translog里，在出现故障的时候，从上次commit起记录在translog里的变更都可以恢复，尽量保证数据不丢失

Lucene的flush操作就是执行一次commit，同时开始记录一个新的translog，所以translog是用来记录从上次commit到下一次commit之间的操作的

flush操作的频率是通过translog的大小控制的，当translog大小达到一定值的时候就执行一次flush，对应参数为index.translog.flush_threshold_size，默认值是512mb，这里调整为1gb，减少flush的次数

translog本身是文件，也需要存储到磁盘，它的存储方式通过index.translog.durability和index.translog.sync_interval设定。默认情况下，index.translog.durability=request，意为每次请求都会把translog写到磁盘。这种设定可以降低数据丢失的风险，但是磁盘IO开销会较大

这里采用异步方式持久化translog，每隔30秒写一次磁盘

{

  "index": {

      "translog": {

          "flush_threshold_size": "1gb",

          "sync_interval": "30s",

          "durability": "async"

      }

  }

}

5) 429错误

增加bulk的queue大小



改配置会增加JVM内存，修改config/jvm.options

-Xms8g

-Xmx8g

建议配置为物理内存的一半，因为文件系统缓存是为了缓冲磁盘的IO操作。至少确保有一半机器的内存保留给操作系统，并且JVM内存不要超过32G。

6)



index由多个shard组成，每个shard又分成很多segment，segment是index数据存储的最小单位。segment比较多的时候会影响搜索性能，ES通过merge对小的segment进行合并，优化查询性能。但是合并过程中会消耗较多磁盘IO，会影响查询性能。Elasticsearch 5 采用了多线程去执行merge，可以通过修改index.merge.scheduler.max_thread_count 来动态调整这个线程数，默认的话是通过下面公式去计算：



要注意的是如果你是用HDD而非SSD的磁盘的话，最好是用单线程为妙。

 

另外也可以手工进行merge操作，这里有3个参数可以用

max_num_segments 期望merge到多少个segments，1的意思是强行merge到1个segment

only_expunge_deletes 只做清理有deleted的segments，即瘦身

flush 清理完执行一下flush，默认是true

你可以用下面的URL来执行强行的merge

[root@localhost elasticsearch55]# curl -XPOST "http://localhost:9200/nginx_2018.04.12/_forcemerge?max_num_segments=1"

{"_shards":{"total":5,"successful":5,"failed":0}}

7) 避免内存交换

设置为true来锁住内存不进行swapping，因为当jvm开始swapping时es的效率会降低。



0x07 告警配置

告警方面可以选择Elastalert

这里我以单IP高频请求api监控为例，查询语句如下：

{

  "size": 0,

  "query": {

    "bool": {

      "must": [

        {

          "range": {

            "timestamp": {

              "from": "%d",

              "to": "%d"

            }

          }

        },

        {

          "term": {

            "status-code": {

              "value": "200"

            }

          }

        },

        {

          "term": {

            "dynamic": {

              "value": 1

            }

          }

        }                                  

      ]

    }

  },

  "aggs": {

    "group_by_clientip": {

      "terms": {

        "field": "client-ip",

        "order": {

          "_count": "desc"

        },

        "min_doc_count": %d

      },

      "aggs": {

        "group_by_servername": {

          "terms": {

            "field": "servername",

            "size": 2,

            "order": {

              "_count": "desc"

            }

          }

        }

      }

    }

  }

}

参考文章：

https://cloud.tencent.com/developer/article/1006124

https://www.jianshu.com/p/9b872a41d5bb

流量分析
网站流量统计分析是指获得网站访问量基础数据的悄况下，对有关数据进行统计、分析，以了解网站当前的访问效果和访问用户行为，以发现当前网络营销活动中存在的问题．监控异常情况，为一进修正或重新制定网络营销策略提供依据，支撑活动安排，维持流量的稳定和增长。
独立访问数：
UV即Unique Visitor，独立访客数，指一天内访问某站点的人数。1天内同一访客的多次访问只记录为一个访客。通过IP和cookie是判断UV值的两种方式。

用Cookie分析UV值：当客户端第一次访问某个网站服务器的时候，网站服务器会给这个客户端的电脑发出一个Cookie，通常放在这个客户端电脑的C盘当中。在这个Cookie中会分配一个独一无二的编号，这其中会记录一些访问服务器的信息，如访问时间，访问了哪些页面等等。当你下次再访问这个服务器的时候，服务器就可以直接从你的电脑中找到上一次放进去的Cookie文件，并且对其进行一些更新，但那个独一无二的编号是不会变的。

使用IP即独立IP数，指一天内使用不同IP地址的用户访问网站数量，同一IP无论访问了几个页面，独立的IP数均为1.但是假如说两台机器访问而使用的是同一个IP，那么只能算是一个IP的访问。

IP和UV之间的数据不会有太大的差异，通常UV量和比IP量高出一点，每个UV相对于每个IP更准确地对应一个实际的浏览者。
页面访问数：
PV即Page View，网站浏览量，指页面浏览的次数，用以衡量网站用户访问的网页数量。用户每次打开一个页面便记录1次PV，多次打开同一页面则浏览量累计。一般来说，PV与来访者的数量成正比，但是PV并不直接决定页面的真实来访者数量，如同一个来访者通过不断的刷新页面，也可以制造出非常高的PV。具体的说，PV值就是所有访问者在24小时（0点到24点）内看了某个网站多少个页面或某个网页多少次。PV是指页面刷新的次数，每一次页面刷新，就算做一次PV流量。

度量方法就是从浏览器发出一个对网络服务器的请求（Request），网络服务器接到这个请求后，会将该请求对应的一个网页（Page）发送给浏览器，从而产生了一个PV。那么在这里只要是这个请求发送给了浏览器，无论这个页面是否完全打开（下载完成），那么都是应当计为1个PV。
人均页面访问数：
跳出率：

定义：只浏览了一个页面便离开了网站的访问次数占总的访问次数的百分比，即只浏览了一个页面的访问次数 / 全部的访问次数汇总。
跳出率是非常重要的访客黏性指标，它显示了访客对网站的兴趣程度：跳出率越低说明流量质量越好，访客对网站的内容越感兴趣，这些访客越可能是网站的有效用户、忠实用户。该指标也可以衡量网络营销的效果，指出有多少访客被网络营销吸引到宣传产品页或网站上之后，又流失掉了，可以说就是煮熟的鸭子飞了。比如，网站在某媒体上打广告推广，分析从这个推广来源进入的访客指标，其跳出率可以反映出选择这个媒体是否合适，广告语的撰写是否优秀，以及网站入口页的设计是否用户体验良好。
页面访问时长：
平均每次访问在网站上的停留时长，即平均访问时长等于总访问时长与访问次数的比值。

平均访问时间越长则说明访客停留在网页上的时间越长：如果用户对网站的内容不感兴趣，则会较快关闭网页，那么平均访问时长就短;如果用户对网站的内容很感兴趣，在网站停留了很长时间，平均访问时长就长。
转化率分析
了解各环节转化情况，分析异常或不合理情况并进行调整以提升各环节转化率。

店铺转化率，所有到达店铺并产生购买行为的人数和所有到达你的店铺的人数的比率。计算方法为：转化率=（产生购买行为的客户人数 / 所有到达店铺的访客人数）× 100%。

访问到下单转化率，所有访问商品并购买的人数和所有访问该商品人数的比率。

下单到支付转化率，支付订单的人数和所有下单人数的比率。

广告投放订单转化率，广告投放产生的订单数/广告投放总数量
存留分析
通过分析用户的日活/存留规律，来帮助运营人员发现问题、监控数据，为调整策略提供数据支持，达到提高日活/存留的效果。

留存率=新增用户中登录用户数/新增用户数*100%（一般统计周期为天）

新增用户数：在某个时间段（一般为第一整天）新登录应用的用户数；

登录用户数：登录应用后至当前时间，至少登录过一次的用户数；

次日留存率：（当天新增的用户中，在注册的第2天还登录的用户数）/第一天新增总用户数；

第3日留存率：（第一天新增用户中，在注册的第3天还有登录的用户数）/第一天新增总用户数；

第7日留存率：（第一天新增的用户中，在注册的第7天还有登录的用户数）/第一天新增总用户数；

第30日留存率：（第一天新增的用户中，在注册的第30天还有登录的用户数）/第一天新增总用户数。
复购分析
通过对复购的监控分析，发现问题、细化原因，为运营策略调整提供支持，辅助达到稳定、提高复购率的效果。
重复购买率指消费者对某店铺、品牌、产品或者服务的重复购买比例，重复购买率越高，反映出消费者对店铺、品牌、产品、服务的忠诚度越高，客户黏性越强，反之则越差。

（1）以客户为对象的重复购买率

在一定的时间范围内，重复购买率=重复购买的客户数/购买客户数。

比如店铺今年内一共有10000个客户在店铺消费，其中2000个客户消费次数（今年内）大于2次（交易按天合并处理）。

公式
今年重复购买率=2000/10000=20%

同样的公式，如果去掉了时间范围的限制就变成了历史重复购买率，分子就变成了回头客：

公式
重复购买率=回头客/所有客户

（2）以订单为对象的重复购买率

在一定的时间范围内，重复购买率=重复购买的订单数/购买订单数。比如店铺今年有10000个订单（交易不合并），其中2000个客户购买了第2笔订单，这2000人中的1000人又购买了第3笔订单。
今年重复购买率=（购买2次的订单+购买3次的订单+购买N次的订单）
/所有订单=（1000+2000）/10000=30%

流失分析
监督流失情况、分析流失用户结构从而了解公司的流失状况，尽量进行调整。

顾客流失率又称客户流失率，是顾客流失的定量表述，是判断顾客流失的主要指标，直接反映了企业经营与管理的现状。
顾客流失率有绝对顾客流失率和相对顾客流失率之分，因而顾客流失率有两种计算方法：
1、绝对顾客流失率：(流失的顾客数量/全部顾客数量)×100%
2、相对顾客流失率：[(流失的顾客数量/全部顾客数量)×流失顾客的相对购买额]×100%

如果一家银行的顾客数量从500减少到475，那么它流失的顾客数量为 25，绝对顾客流失率即为25/500*100%=5%。绝对顾客流失率把每位流失的顾客同等看待。相对顾客流失率则以顾客的相对购买额为权数来考虑顾客流失率。若流失的25位顾客的单位购买额是平均数的3倍，那么相对顾客流失率即为25/5003100%=15%。