当前位置: 首页 > elasticsearch, 搜索 > 正文

ElasticSearch的几点使用事项

1 星2 星3 星4 星5 星 (1 次投票, 评分: 5.00, 总分: 5)
Loading ... Loading ...
baidu_share

之前已经写过一些ES的使用,也翻译了一篇官网上关于ES存储日志的建议日志。今天稍微总结一下近期以来实践出来的方案。

shard和replica的选择
在测试期,可以单节点上设置成1 shard + 0 replica的方式,这种的indexing速度是最快的(存疑:我至今没搞清楚ES在index的时候集群”应该”是比单node快还是慢)。

我曾经按照”常理”(我想象中的)理解,设定成10 shards + 0 replica,期望能用上并行写双node加倍index,事实上压根没用,而且因为另一台node上有其他负载的原因导致更慢了。

更可怕的是:就在前几天,突然出现一个shard挂了,……毫无办法,整个index全作废了。

所以结论是:无论如何,一定要保证有 > 0 份的replica!! 至于shards,保持默认的5个,或者顶多到20个也就差不多了。在maillist里看到有哥们设了100个,然后苦着脸问性能问题…… 要知道shards的份数是一旦设定不能更改的。

template的使用
刚开始的时候,每次实验都去改/etc/elasticsearch/elasticsearch.yml配置文件。事实上在template里修改settings更方便而且灵活!当然最主要的,还是调节里面的properties设定,合理的控制store和analyze了。

template设定也有多种方法。最简单的就是和存储数据一样POST上去。长期的办法,就是写成json文件放在配置路径里。其中,default配置放在/etc/elasticsearch/下,其他配置放在/etc/elasticsearch/templates/下。举例我现在的一个templates/template-logstash.json内容如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
{
  "template-logstash" : {
    "template" : "logstash*",
    "settings" : {
      "index.number_of_shards" : 5,
      "number_of_replicas" : 1,
      "index" : {
        "store" : {
          "compress" : {
            "stored" : true,
            "tv": true
          }
        }
      }
    },
    "mappings" : {
      "_default_" : {
        "properties" : {
          "dynamic" : "true",
        },
      },
      "loadbalancer" : {
        "_source" : {
          "compress" : true,
        },
        "_ttl" : {
          "enabled" : true,
          "default" : "10d"
        },
        "_all" : {
          "enabled" : false
        },
        "properties" : {
          "@fields" : {
            "dynamic" : "true",
            "properties" : {
              "client" : {
                "type" : "string",
                "index" : "not_analyzed"
              },
              "domain" : {
                "type" : "string",
                "index" : "not_analyzed"
              },
              "oh" : {
                "type" : "string",
                "index" : "not_analyzed"
              },
              "responsetime" : {
                "type" : "double",
              },
              "size" : {
                "type" : "long",
                "index" : "not_analyzed"
              },
              "status" : {
                "type" : "string",
                "index" : "not_analyzed"
              },
              "upstreamtime" : {
                "type" : "double",
              },
              "url" : {
                "type" : "string",
                "index" : "not_analyzed"
              }
            }
          },
          "@source" : {
            "type" : "string",
            "index" : "not_analyzed"
          },
          "@timestamp" : {
            "type" : "date",
            "format" : "dateOptionalTime"
          },
          "@type" : {
            "type" : "string",
            "index" : "not_analyzed",
            "store" : "no"
          }
        }
      }
    }
  }
}

注意:POST 发送的 json 内容比存储的 json 文件内容要少最外层的名字,因为名字是在 url 里体现的。

mapping简介
上面template中除了index/shard/replica之外的部分,就是mapping了,大家注意到其中的dynamic,默认情况下,index会在第一条数据进入的时候自动分析这条数据的情况,给每个value找到最恰当的type,然后以此为该index的mapping。之后再PUT上来的数据,格式如果不符合mapping的,也能存储成功,但是就无法检索了。

mapping中关于store和compress的部分,之前翻译的《用ElasticSearch存储日志》已经说的比较详细了。这里我的建议是 disable 掉 _all,但是 enable 住 _source!! 经过我的惨痛测试,如果连 _source 也 disable 掉的话,一旦你重启进程,整个 index 里除了 _id,_timestamp 和 _score 三个默认字段,啥都丢了……

API简介
ES的API,最基本的就是CRUD操作了,这部分是标准的REST,就不说了。

然后还有三个API比较重要且常用,分别是: bulk/count/search。

Bulk顾名思义,把多个单条的记录合并成一个大数组统一提交,这样避免一条条发送的header解析,索引频繁更新,indexing速度大大提高
Count根据POST的json,返回命中范围内的总条数。当然没POST时就直接返回该index的总条数了。
Search根据POST的json或者GET的args,返回命中范围内的数据。这是最重要的部分了。下面说说常用的search API:
query
一旦使用search,必须至少提供query参数,然后在这个query的基础上进行接下来其他的检索。query参数又分三类:

“match_all” : { } 直接请求全部;
“term”/”text”/”prefix”/”wildcard” : { “key” : “value” } 根据字符串搜索(严格相等/片断/前缀/匹配符);
“range” : { “@timestamp” : { “from” : “now-1d”, “to” : “now” } } 根据范围搜索,如果type是时间格式,可以使用内置的now表示当前,然后用-1d/h/m/s来往前推。
filter
上面提到的query的参数,在filter中也都存在。此外,还有比较重要的参数就是连接操作:

“or”/”and” : [{"range":{}}, {"prefix":""}] 两个filter的查询,交集或者合集;
“bool” : ["must":{},"must_not":{},"should":{}] 上面的and虽然更快,但是只能支持两个,超过两个的,要用 bool 方法;
“not”/”limit” : {} 取反和限定执行数。注意这个limit和mysql什么的有点不同:它限定的是在每个shards上执行多少条。如果你有5个shards,其实对整个index是limit了5倍大小的设定值。
另一点比较关键的是:filter结果默认是不缓存的,如果常用,需要指定 “_cache” : true。

facets
facets接口可以根据query返回统计数据,最基础的是terms和statistical两种。不过在日志分析的情况下,最常用的是:

“histogram” : { “key_field” : “”, “value_field” : “”, “interval” : “” } 根据时间间隔返回柱状图式的统计数据;
“terms_stats” : { “key_field” : “”, “value_field” : “” } 根据key的情况返回value的统计数据,类似group by的意思。
这里就涉及到前面mapping里为什么针对每个field都设定type的原因了。因为 histogram 里的 key_field 只能是 dateOptionalTime 格式的,value_field 只能是 string 格式的;而 terms_stats 里的 key_field 只能是 string 格式的,value_field 只能是 numberic 格式的。

而我们都知道,http code那些200/304/400/503神马的,看起来是数字,我们却需要的是他们的count数据,不是算他们的平均数。所以不能由ES动态的认定为long,得指定为string。

analyze简介
对于logstash分析日志,基本没有提到analyze的部分,包括Kibana也是。但是做web日志分析,其实也需要注意analyze。因为ES默认提供并开启了一些analyze。最简单的比如空格分隔表示单词,斜线分割表示url路径,@分割表示email地址等等。文档地址见http://www.elasticsearch.org/guide/reference/index-modules/analysis/。当然ES社区的中国人也有提供中文分词的plugin。通常情况下,analyze工作的很好。嗯,ES比其他全文索引工具在默认情况下都工作的好。

但是当你想算的是今天访问的url排名,或者来访者IP排名的时候,麻烦来了,你苦苦等待N久,最后一看排名是这样的:

jpg 2345678
html 123456
20121021 34567
bbs 9876
对,你的url被ES辛辛苦苦的用 / 和 . 分割了,然后每个单词排序来再返回给你。如果你是在一个数千万条的大型库上运行的话,基本吃个饭回来才能有结果。

事实上,url就是一个整体,所以在mapping中,要定义好在indexing的时候,不要启用analyzer。这样,返回一个你心目中想要的正确的url排名,时间从吃个午饭直接缩减到打个喷嚏了!而如果是访问者ip,时间则是眨下眼就够了!

注意:analyze不是只有indexing的时候能用,在query的时候,也可以单独指定某个analyze来分析记录。analyze其实是和search并列的API,不过目前场景下用不上,就不说了。

有以上API,基本上一个针对logstash的ES数据分析系统后台就足够构建出来了。剩下的就是前端页面的事情,这方面可以参考logstash的Kibana,更广义一些的ES数据可视化可以参考ES的blog: http://www.elasticsearch.cn/blog/2011/05/13/data-visualization-with-elasticsearch-and-protovis.html

性能监控
ES周边的工具有很多。目前我主要用三种方式:

es_head: 这个主要提供的是健康状态查询,当然标签页里也提供了简单的form给你提交API请求。es_head现在可以直接通过 elasticsearch/bin/plugin -install mobz/elasticsearch-head 安装,然后浏览器里直接输入 http://$eshost:9200/_plugin/head/ 就可以看到cluster/node/index/shards的状态了。
bigdesk: 这个主要提供的是节点的实时状态监控,包括jvm的情况,linux的情况,elasticsearch的情况。排查性能问题的时候很有用,现在也可以通过 elasticsearch/bin/plugin -install lukas-vlcek/bigdesk 直接安装了。然后浏览器里直接输入 http://$eshost:9200/_plugin/bigdesk/ 就可以看到了。注意如果使用的 bulk_index 的话,如果选择的刷新间隔太长,indexing per second数据是不准的。
然后是最基础的办法,通过ES本身的status API获取状态。因为上面都是web工具,如果想要避免上文提到的故障很久才发现的问题,我们需要一个可以提供给nagios使用的办法,这很简单就可以做到。刚巧ES本身也有green/yellow/red等不同的状态。所以很简单完成一个check_es_health.sh如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#!/bin/sh
    ES_HOST=$1
    ES_URI="http://${ES_HOST}:9200/_cluster/health"
    RES_JSON=`curl -s ${ES_URI}`
    status=`echo ${RES_JSON}|awk -F\" '{print $8}'`
    failed=`echo ${RES_JSON}|awk -F\" '{print $NF}'|sed 's/^:\([0-9]*\)}/\1/'`
    if [[ "$status" -eq "green" ]];then
        echo "ES Cluster OK | failed_node=${failed}"
        exit 0
    elif [[ "$status" -eq "yellow" ]];then
        echo "Warning! ES Cluster shards relocating or initializing. | failed_node=${failed}"
        exit 1
    else
        echo "Critical! ES Cluster shards unassigned. | failed_node=${failed}"
        exit 2
    fi

其他插件
ES是一个很活跃的开源项目,所以如果有其他目前ES没有你有觉得有需要的功能,大可以上github搜索一下,或许别人早已经做完相关插件了。

比如我就在上面找到一个plugin叫elasticfacets。加强了ES的 date_histogram 功能,原先只能针对某个 value_field 做攻击,这个plugin可以在这个基础上,把 value_field 加强成又一层facets。项目地址: https://github.com/bleskes/elasticfacets。之前和作者反馈了在ES 0.19.8上的问题,不知道修复没。或许最好还是用0.19.9吧。

邮件列表
ES的邮件列表基本每天都有四五十封邮件,地址是:elasticsearch@googlegroups.com。

本文固定链接: http://www.chepoo.com/apply-elasticsearch-notice.html | IT技术精华网

ElasticSearch的几点使用事项:等您坐沙发呢!

发表评论