kibana到5.0后可以直接在kibana.yml上面使用tilemap.url进行配置，
但是之前使用的url貌似都不行，有伙伴能提供个K5能用的url吗？

Beats这个项目的确很好用，几行命令下来，一个成型的Agent就出来了。使用者只需要关注采集什么数据就好，后续的事情libbeat基本都处理完了。不过值得吐槽的是，Beat太散了，管理起来东一个西一个的，产品化的时候对客户说，我们要在机器上放n个Agent不知道客户会是什么样的表情。





不过轻量级、已部署的特点还是极大的吸引了我，于是就有了后面的事情了。

PacketBeat不明原因的OOM

某天我把PacketBeat放到了我的服务器上面，这台服务器上面有个MongoDB，MongoDB主要是拿来存放ES的元数据的。ES2.x的时候并没有很好的元数据管理，为了能让ES的索引分配的比较均匀，并且有元数据辅助查询，设计好一个元数据管理的仓库是必要的。然后我打开了对MongoDB的抓包功能，恩，一切都很好，接着我打开了日志管理页面，看到了一条一条的MongoDB的包被抓回来，解码，然后塞到了ES。可是第二天一看，咦？？Packet跪了？不是吧，ElasticSearch做的产品这么不稳定么。我不信。





然后我又启动了第二次，紧接着熟练的top了一下，观察了PacketBeat半个多小时，在被观察的这段时间里面，PacketBeat的表现非常的正常，看不出有什么异样。好吧，那上一次的OOM可能只是个意外，Windows也经常蓝屏嘛，OOM一次也正常。结果第二天我再次打开终端，发现这货居然又OOM了！！





好吧好吧，我感觉我已经踩到Bug了，拿了开源社区这么多东西，总得贡献一下的，好吧，提个Issue去 https://github.com/elastic/beats/issues/2867

真相只有一个

微信群里面聊起这个奇妙的OOM，Medcl大神问是不是因为采集了ES的日志，（我的这台服务器和日志服务器有关系）然后导致滚雪球把PacketBeat给滚死了。咦？说不定真的是这个原因耶！但是看了看PacketBeat，我并没有抓ES的包，而且假如我采集了ES的包，应该一下就OOM掉了，不应该等那么久。不过这么一说，却仿佛打开了新世界的大门





我把这台服务器在日志服务器中的角色重新梳理了下，终于发现了这次OOM的原因了。。

由于2.X的ES没有比较好的元数据信息，所以当日志送到LogServer的时候，我做了些额外的操作，让LogServer持久化到ES一定量的时候就会往Mongo写一下元数据信息（当然也有其他服务会往里面做CRUD啦），开始的时候访问Mongo的次数其实是很少的，假设按1W来算。那么问题来了，由于我们的PacketBeat抓了Mongo的包，那么LogServer往ES的CRUD操作都会被PacketBeat给抓走，然后再送回给LogServer





那么一个隐藏的滚雪球事件就产生了，刚开始的那段时间，Mongo被抓包的次数只有1W，然后就往LogServer多送了1W条日志，不。。应该多很多，毕竟网络包嘛，然后就导致LogServer因为要管理元数据的频率开始逐渐地提高，逐渐提高CRUD的频率后抓包的内容也越来越多，紧接着到这发生到LogServer的频率也越来越高。。。。。每次PacketBeat崩掉的时候，都送了80W左右的日志量出去，然后它就OOM掉了（因为我那台机器就只剩下2G的空闲内存给它用，被系统给干掉了）。。我居然发现了这样的场景





结论

使用PacketBeat的时候，记得要留意一下有没这种反馈型滚雪球的情况，多发生在自己的日志服务器上面。当然那种直接抓ES的就没什么好说了，估计启动了之后没多久就崩溃掉了

创建用户：adduser elasticsearch
可查看创建结果：
##########/etc/passwd
##########/etc/shadow
##########/etc/group
配置环境变量
修改文件：/home/elasticsearch/.profile
追加内容：
export JAVA_HOME=/home/elasticsearch/java/jdk1.8.0_73
export PATH=$JAVA_HOME/bin:$PATH
export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar:$CLASSPATH
export PATH
配置elasticsearch5.0.0
tar -xf elasticsearch-5.0.0.tar.gz -C /home/elasticsearch/
cd /home/elasticsearch/
ln -sv elasticsearch-5.0.0 elasticsearch
mkdir -pv /esdata/elasticsearch/{data,logs}
chown -R elasticsearch.elasticsearch /esdata/elasticsearch
修改ES配置文件
/home/elasticsearch/elasticsearch-5.0.0/config/elasticsearch.yml
http.cors.enabled: true
http.cors.allow-origin: "*"
path.data: /esdata/elasticsearch/data
path.logs: /esdata/elasticsearch/logs
network.host: 192.168.25.57
http.port: 8201
transport.tcp.port: 8301
bootstrap.memory_lock: true
/home/elasticsearch/elasticsearch-5.0.0/config/jvm.options
-Xms8g
-Xmx8g
修改系统参数
/etc/security/limits.conf
elasticsearch soft nproc 65536
elasticsearch hard nproc 65536
elasticsearch soft nofile 65536
elasticsearch hard nofile 65536
elasticsearch - memlock unlimited
/etc/sysctl.conf
vm.max_map_count = 262144
加载更新：sysctl -p
启动ES服务
su - elasticsearch -c "/home/elasticsearch/elasticsearch/bin/elasticsearch &"
 

es现在几乎已经是开源搜索引擎的事实标准了，搭建简易，使用方便。不过在很多公司里(包括我司的部分部门)，并不是把它当搜索引擎来用，而是当db来用。因为本身查询/搜索原理的区别，使es在千万或者亿级的数据中进行逻辑筛选相对高效。例如一些wms、工单查询系统，单表几十个甚至上百个字段，如果在数据库里为每种类型的查询都建立合适的索引，成本比较高，更不用说索引建多了还会影响到插入速度，后期的索引优化也是比较麻烦的问题。

不过如果把es当db来使的话，始终会有一个绕不过去的坎。就是es的DSL。让所有业务开发去学习dsl的话也不是不可以，但DSL真的有点反人类(不要打我)。简单的a and b或者a or b还比较容易写，如果我要的是a and (b and (c or d) and e)的查询逻辑，那我觉得谁写都会晕。即使是用官方或者第三方提供的client，如果需求多种多样的话，想要灵活地实现`需求=>DSL`的过程还是比较痛苦。

对于业务开发来说，当然是sql更平易近人(毕竟写了这么多年CRUD)。所以还有一种歪门邪道的流派，直接把sql转成DSL。要做sql和DSL转换的工作，需要进行sql的解析，先不要怵，这个年代找一个靠谱的sql parser还是比较容易的。比如阿里开源的druid连接池里的sql模块：
 
https://github.com/alibaba/dru ... d/sql

因为笔者的实现是用的下面这个golang版的parser：

https://github.com/xwb1989/sqlparser

所以用这个来举例吧~

这个是其作者从youtube/vitness里提取并进行改进的一个parser，我们能用到的是一部分子集功能，只需要解析select类的sql。

先举个简单的sql的例子：

select * from x_order where userId = 1 order by id desc limit 10,1;



解析之后会变成golang的一个struct，来看看具体的定义：



&sqlparser.Select{

    Comments:sqlparser.Comments(nil),

    Distinct:"",

    SelectExprs:sqlparser.SelectExprs{(*sqlparser.StarExpr)(0xc42000aee0)},

    From:sqlparser.TableExprs{(*sqlparser.AliasedTableExpr)(0xc420016930)},

    Where:(*sqlparser.Where)(0xc42000afa0),

    GroupBy:sqlparser.GroupBy(nil),

    Having:(*sqlparser.Where)(nil),

    OrderBy:sqlparser.OrderBy{(*sqlparser.Order)(0xc42000af20)},

    Limit:(*sqlparser.Limit)(0xc42000af80),

    Lock:""

}

sql的select语句在被解析之后生成一个Select的结构体，如果我们不关心使用者需要的字段的话，可以先把SelectExprs/Distinct/Comments/Lock里的内容忽略掉。如果不是分组统计类的需求，也可以先把GroupBy/Having忽略掉。这里我们关心的就剩下From、Where、OrderBy和Limit。

From对应的TableExprs实际上可以认为是简单的字符串，这里的值其实就是`x_order`。

OrderBy实际上是一个元素为

type Order struct {

    Expr      ValExpr

    Direction string

}\

的数组。

Limit也很简单，

type Limit struct {

    Offset, Rowcount ValExpr

}

其实就是俩数字。

那么剩下的就是这个Where结构了。where会被解析为AST(`https://en.wikipedia.org/wiki/Abstract_syntax_tree`)，中文是抽象语法树。在不说子查询之类的情况下，这个AST也不会太复杂，毕竟where后面的情况比起编译原理里的程序语言来说情况还是要少得多的。以上述的sql为例，这里解析出来的Where结构是这样的：

&sqlparser.Where{

    Type:"where",

    Expr:(*sqlparser.ComparisonExpr)(0xc420016a50)

}

只有一个节点，一个ComparisonExpr表达式，这个ComparisonExpr，中文比较表达式，指代的就是我们sql里的`user_id = 1`。实际上我们可以认为这个"比较表达式"即是所有复杂AST的叶子节点。叶子结点在AST遍历的时候一般也就是递归的终点。因为这里的查询比较简单，整棵AST只有一个节点，即根节点和叶子节点都是这个ComparisonExpr。

再来一个复杂点的例子。

select * from users where user_id = 1 and product_id =2



=>



&sqlparser.Where{

    Type:"where",

    Expr:(*sqlparser.AndExpr)(0xc42000b020)

}



AndExpr有Left和Right两个成员，分别是：



Left:

&sqlparser.ComparisonExpr{

    Operator:"=",

    Left:(*sqlparser.ColName)(0xc4200709c0),

    Right:sqlparser.NumVal{0x31}

}



Right:

&sqlparser.ComparisonExpr{

    Operator:"=",

    Left:(*sqlparser.ColName)(0xc420070a50),

    Right:sqlparser.NumVal{0x32}

}

稍微有一些二叉树的样子了吧。把这棵简单的树画出来：





回到文章开头的那个复杂的例子：

a and (b and (c or d) and e)



=>



select * from user_history where user_id = 1 and (product_id = 2 and (star_num = 4 or star_num = 5) and banned = 1)

看着真够麻烦的，我们把这棵树画出来：





这样看着就直观多了。我们有了AST的结构，那要怎么对应到es的查询DSL呢？少安毋躁。

我们知道es的bool query是可以进行嵌套的，所以实际上我们可以同样可以构造出树形结构的bool query。这里把bool嵌套must和bool嵌套should简化一下，写成boolmust和boolshould：

例如a and (b and c)

query {

    boolmust {

        a,

        boolmust {

            b,

            c

        }

    }

}

我们把query内部的第一个boolmust当作根节点，内部嵌套的a和另一个boolmust当作它的两个子节点，然后b和c又是这个boolmust的子节点。可以看出来，实际上这棵树和AST的节点可以一一对应。

再回到文章开头的例子，a and (b and (c or d) and e)：

query {

    boolmust {

        a,

        boolmust {

            b,

            boolshould {

                c,

                d

            },

            e

        }

    }

}

和前文中ast来做个简单的结构对比~






和前文中sql的where解析后的AST树也是完全匹配的。思路来了，只要对sql解析生成的AST进行递归，即可得到这棵树。当然了，这里还可以进行一些优化，如果子节点的类型和父
节点的类型一致，例如都是and表达式或者都是or表达式，我们可以在生成dsl的时候将其作为并列的节点进行合并，这里不再赘述。


在递归中有这么几种情况：

AndExpr => bool must [{left}, {right}]

OrExpr => bool should [{left}, {right}]

ComparisonExpr => 一般是叶子节点

ParenBoolExpr => 指代括号表达式，其实内部是上述三种节点的某一种，所以直接取出内部节点按上述方法来处理

这样问题就变成了如何处理AST的叶子节点。前面提到了叶子节点实际上就是Comparison Expression。只要简单进行一些对应即可，下面是我们的项目里的一些对应关系，仅供参考：



最后再附上demo
 
https://github.com/cch123/elasticsql