Day5: 《PacketBeat奇妙的OOM小记》
Advent • kira8565 发表了文章 • 0 个评论 • 5497 次浏览 • 2016-12-05 23:00
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的就没什么好说了，估计启动了之后没多久就崩溃掉了
不过轻量级、已部署的特点还是极大的吸引了我，于是就有了后面的事情了。
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的就没什么好说了，估计启动了之后没多久就崩溃掉了
ES聚合中文问题
Elasticsearch • twinboss 回复了问题 • 5 人关注 • 3 个回复 • 5292 次浏览 • 2017-02-09 17:39
Logstash5.0.X离线安装插件报错，仍然提示无法联网
Logstash • tzwgod 回复了问题 • 3 人关注 • 2 个回复 • 8354 次浏览 • 2016-12-16 15:20
kibana中的Metric里的高级中json input都有哪些玩法？
回复Kibana • guitar1314 回复了问题 • 2 人关注 • 1 个回复 • 14548 次浏览 • 2016-12-06 14:08
elasticsearch5.0集成ik分词问题(type报错)
Elasticsearch • medcl 回复了问题 • 3 人关注 • 2 个回复 • 5531 次浏览 • 2017-01-10 10:34
ES5.0 批量导入数据，设置导入结束后刷新不生效
Elasticsearch • Jaret 回复了问题 • 3 人关注 • 3 个回复 • 8461 次浏览 • 2020-04-22 14:30
有没有Elastic Stack 5.X的中文文档可有参考？
Elasticsearch • luyee2010 回复了问题 • 7 人关注 • 6 个回复 • 9913 次浏览 • 2017-03-23 11:31
ES5.0.0 安装记录
Elasticsearch • sunping 发表了文章 • 1 个评论 • 5179 次浏览 • 2016-12-05 09:42
创建用户：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添加节点的问题
Elasticsearch • famoss 回复了问题 • 4 人关注 • 1 个回复 • 6360 次浏览 • 2016-12-05 18:13
Day4: 《将sql转换为es的DSL》
Advent • Xargin 发表了文章 • 6 个评论 • 34961 次浏览 • 2016-12-04 23:23
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的例子：
sql的select语句在被解析之后生成一个Select的结构体，如果我们不关心使用者需要的字段的话，可以先把SelectExprs/Distinct/Comments/Lock里的内容忽略掉。如果不是分组统计类的需求，也可以先把GroupBy/Having忽略掉。这里我们关心的就剩下From、Where、OrderBy和Limit。
From对应的TableExprs实际上可以认为是简单的字符串，这里的值其实就是`x_order`。
OrderBy实际上是一个元素为
的数组。
Limit也很简单，
其实就是俩数字。
那么剩下的就是这个Where结构了。where会被解析为AST(`https://en.wikipedia.org/wiki/Abstract_syntax_tree`)，中文是抽象语法树。在不说子查询之类的情况下，这个AST也不会太复杂，毕竟where后面的情况比起编译原理里的程序语言来说情况还是要少得多的。以上述的sql为例，这里解析出来的Where结构是这样的：
只有一个节点，一个ComparisonExpr表达式，这个ComparisonExpr，中文比较表达式，指代的就是我们sql里的`user_id = 1`。实际上我们可以认为这个"比较表达式"即是所有复杂AST的叶子节点。叶子结点在AST遍历的时候一般也就是递归的终点。因为这里的查询比较简单，整棵AST只有一个节点，即根节点和叶子节点都是这个ComparisonExpr。
再来一个复杂点的例子。
稍微有一些二叉树的样子了吧。把这棵简单的树画出来：
回到文章开头的那个复杂的例子：
看着真够麻烦的，我们把这棵树画出来：
这样看着就直观多了。我们有了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又是这个boolmust的子节点。可以看出来，实际上这棵树和AST的节点可以一一对应。
再回到文章开头的例子，a and (b and (c or d) and e)：
和前文中ast来做个简单的结构对比~
和前文中sql的where解析后的AST树也是完全匹配的。思路来了，只要对sql解析生成的AST进行递归，即可得到这棵树。当然了，这里还可以进行一些优化，如果子节点的类型和父
节点的类型一致，例如都是and表达式或者都是or表达式，我们可以在生成dsl的时候将其作为并列的节点进行合并，这里不再赘述。
在递归中有这么几种情况：
这样问题就变成了如何处理AST的叶子节点。前面提到了叶子节点实际上就是Comparison Expression。只要简单进行一些对应即可，下面是我们的项目里的一些对应关系，仅供参考：
最后再附上demo
https://github.com/cch123/elasticsql
不过如果把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
Day3: 《创建一个你自己的 Beat》
Advent • medcl 发表了文章 • 0 个评论 • 8040 次浏览 • 2016-12-03 22:19
Elastic Advent 第三篇, 手头上事情实在太多，这两天正在进行权威指南翻译的冲刺阶段，临时填下坑，翻译官网的一篇文章吧(原文:https://www.elastic.co/blog/build-your-own-beat)，Advent 规则很自由的，没说不能翻译文章啊，嘿嘿嘿，另外号召大家踊跃报名，大家一起玩才有意思。
活动地址：http://elasticsearch.cn/article/107
言归正传！
Beat 是一个开源的用来构建轻量级数据汇集的平台，可用于将各种类型的数据发送至Elasticsearch 与 Logstash。我们有 Packetbeat 用于监控局域网内服务器之间的网络流量信息，有 Filebeat 收集服务器上的日志信息，还有新推出的 Metricbeat 可以定期获取外部系统的监控指标信息，除此以外，你还可以非常方便的基于 libbeat 框架来构建你属于自己的专属 Beat，目前 beas 社区已经有超过25个 Community Beats 了。
Elastic 还提供一个 Beat generator（Beat 生成器）来帮你快速构建属于你自己的 Beat。通过这篇博客你将会看到如何通过 Beat 生成器来快速创建一个你自己的 Beat。今天我们创建的是一个叫做 lsbeat 的 Beat，lsbeat 非常类似 Unix 系统下的命令行 ls，我们用 lsbeat 来索引目录和文件信息。本篇文章环境基于 Unix 系统，如果你是 Windows 或是其它系统，相关操作可能需要根据实际情况进行调整。
第一步 – 配置 Golang 环境
Beats 是用 Golang写的，显然，要创建和开发一个 beat，Golang 环境必不可少，关于这方面的文章很多，建议查看这篇 Golang 的安装向导： install Golang。当前 Beats 需要的最低版本是 Golang 1.6。另外请确保正确设置了你的 $GOPATH 环境变量。
另外 Golang Glide 被用来进行包的依赖管理，所以也需要确保正确安装，最低版本是 Glide 0.10.0，安装说明点这里。
让我们先来看看 lsbeat 将会用到的一段代码吧，这是一个简单的 golang 程序，通过命令行接收一个目录参数，然后列出该目录下的文件和子目录信息。
后面我们将使用到这段代码和 listDir 函数。
第二步 – 生成项目
要生成一个你自己的 Beat，就要用到 beat-generator 了，首先你必须安装 cookiecutter。安装的详细说明看这里。安装好 cookiecutter 之后，我们要给自己的 Beat 起一个好听的名字，最好是小写的英文字母，我们今天这个例子就叫 lsbeat 吧。
生成项目模板之前，我们需要下载 Beats generator 包文件，就在 beats 仓库。安装好 GoLang 之后，你就可以很方便的使用 go get 命令来下载 Beats generator 包文件了。 当你执行下面的这个命令后，所有的源码文件都会下载到 $GOPATH/src 目录。
在 GOPATH 下创建一个以你自己github账号名称命名的目录，并切换过去，然后执行 cookiecutter 命令并指向 Beat Generator 源码路径。
Cookiecutter 接下来会问你几个问题，比如项目名称，我们输入：lsbeat；你的 github 用户名，输入你自己的 github 账户；还有两个关于beat和beat_path应该会自动识别，默认回车就好；最后的问题，你可以输入你的姓和名。
现在应该已经创建好了一个名为 lsbeat 的目录，并且里面应该会生成一些文件，让我们一起来看一下吧，结构如下：
我们刚刚已经生成好了一个原始的 Beat 模板了，但是你还需要获取相关的依赖和设置好 git 仓库。
首先，你需要拉取依赖的相关包信息，我们的这个例子是 lsbeat，我们先做一些的基本的配置，回头再看看详细看看其它的模板和配置文件，只需要执行 make setup 就可以自动获取依赖。
当你创建好了自己的 Beat 之后，记得上传到 github 仓库，并和社区进行分享哦，如下：
要 push lsbeat 到你的 git 仓库，只需要执行如下命令:
恭喜你，现在你已经完成了一个 Beat ，并且发布了第一个版本到了 Github，不过里面还没有什么具体内容，现在让我们进一步看看里面的代码吧。
第四步 – 配置
执行过上面一系列命令之后，项目里将会自动创建名为 lsbeat.yml 和 lsbeat.template.json 的配置文件。所有的基本配置项都已经生成在了里面。
Period 参数包含在每一个生成的 Beats 里面，它表示 lsbeat 将会每隔 1 秒钟轮询一次，这里我们修改 period 时间间隔为 10 秒。还可以在修改 etc/ 目录下面的 beat.yml 文件，这里新增一个 path 参数表示我们具体要监听哪个目录。
参数添加好了之后，我们只需要运行 make update 命令就能让这些修改应用到配置文件lsbeat.yml。
修改完 yml 文件，记得修改 config/config.go文件，添加一个path 参数。
同时我们修改 period 默认时间间隔为 10 秒，默认监听的是当前目录 (.) 。.
第五步 – 添加代码
每一个 Beat 需要实现 Beater 接口，里面定义了 Run() 和 Stop() 函数。.
我们可以定义一个名为 Lsbeat 的结构体，然后用这个对象实现 Beater 接口。然后添加字段 lastIndexTime 来保存最后运行的时间戳信息。
另外，每个 Beat 还需要实现 New() 方法来接收 Beat 配置信息和返回 Lsbeat 的具体实例。
在我们的 lsbeat 例子中，我们要做的就是扩展默认的 Run() 函数来导出指定目录的文件和子目录信息。
在修改 Run() 函数之前，我们先在 lsbeat.go 增加 listDir() 函数，就是我们前面最开始测试的那段代码，用于收集目录和文件信息的简单例子稍微修改一下。另外我们还要生成以下字段信息：
第一次运行的时候我们将索引所有的文件和目录信息，然后我们再定期检查是否有新文件被创建或者修改，再索引这些新创建的文件和目录。每次定期检查的时间戳都会保存在 lasIndexTime 变量，完整代码如下：
记住在最开始需要导入 “io/ioutil” 包。
现在，让我们看看如何在 Run() 函数里面调用 listDir() 函数，并且保存时间戳到 lasIndexTime 变量。
函数 Stop() 用来中断 run 的循环执行，保持默认生成的就行。
到这里，编码部分基本就完成了。我们接下来添加新字段到 mapping 中，修改文件 etc/fields.yml。.
重新应用新的配置。
$ make update
字段 file_name 将使用 nGram 分词，我们还需要在文件 lsbeat.template.json 的 “settings” 节点添加一个自定义的 analyzer。
第六步 – 编译和运行
现在我们可以编译和运行了，只需要执行 make 命令就可以编译出可执行文件 lsbeat (lsbeat.exe on windows) 。
$ make
修改 lsbeat.yml 文件，设置需要监听的目录，如： “/Users/ec2-user/go”，记住是全路径。
同时确保你的 elasticsearch 和 kibana 正常运行。现在运行一下 lsbeat 命令看看会发生什么事情吧。
$ ./lsbeat
打开Kibana，通过调用 _cat 接口我们看看的索引是不是创建了。
可以看到创建了一个名为 lsbeat-2016.06.03 的索引，并且看到已经有了一些文档了。现在对 filename 字段查询一下，由于使用的是 nGram 分词，支持模糊匹配，我们使用 lsbe 关键字搜一下。
大功告成! 恭喜你，你已经完成了第一个属于你自己的 beat。
活动地址：http://elasticsearch.cn/article/107
言归正传！
Beat 是一个开源的用来构建轻量级数据汇集的平台，可用于将各种类型的数据发送至Elasticsearch 与 Logstash。我们有 Packetbeat 用于监控局域网内服务器之间的网络流量信息，有 Filebeat 收集服务器上的日志信息，还有新推出的 Metricbeat 可以定期获取外部系统的监控指标信息，除此以外，你还可以非常方便的基于 libbeat 框架来构建你属于自己的专属 Beat，目前 beas 社区已经有超过25个 Community Beats 了。
Elastic 还提供一个 Beat generator（Beat 生成器）来帮你快速构建属于你自己的 Beat。通过这篇博客你将会看到如何通过 Beat 生成器来快速创建一个你自己的 Beat。今天我们创建的是一个叫做 lsbeat 的 Beat，lsbeat 非常类似 Unix 系统下的命令行 ls，我们用 lsbeat 来索引目录和文件信息。本篇文章环境基于 Unix 系统，如果你是 Windows 或是其它系统，相关操作可能需要根据实际情况进行调整。
第一步 – 配置 Golang 环境
Beats 是用 Golang写的，显然，要创建和开发一个 beat，Golang 环境必不可少，关于这方面的文章很多，建议查看这篇 Golang 的安装向导： install Golang。当前 Beats 需要的最低版本是 Golang 1.6。另外请确保正确设置了你的 $GOPATH 环境变量。
另外 Golang Glide 被用来进行包的依赖管理，所以也需要确保正确安装，最低版本是 Glide 0.10.0，安装说明点这里。
让我们先来看看 lsbeat 将会用到的一段代码吧，这是一个简单的 golang 程序，通过命令行接收一个目录参数，然后列出该目录下的文件和子目录信息。
package main
import (
"fmt"
"io/ioutil"
"os"
)
func main() {
//apply run path "." without argument.
if len(os.Args) == 1 {
listDir(".")
} else {
listDir(os.Args[1])
}
}
func listDir(dirFile string) {
files, _ := ioutil.ReadDir(dirFile)
for _, f := range files {
t := f.ModTime()
fmt.Println(f.Name(), dirFile+"/"+f.Name(), f.IsDir(), t, f.Size())
if f.IsDir() {
listDir(dirFile + "/" + f.Name())
}
}
}后面我们将使用到这段代码和 listDir 函数。
第二步 – 生成项目
要生成一个你自己的 Beat，就要用到 beat-generator 了，首先你必须安装 cookiecutter。安装的详细说明看这里。安装好 cookiecutter 之后，我们要给自己的 Beat 起一个好听的名字，最好是小写的英文字母，我们今天这个例子就叫 lsbeat 吧。
生成项目模板之前，我们需要下载 Beats generator 包文件，就在 beats 仓库。安装好 GoLang 之后，你就可以很方便的使用 go get 命令来下载 Beats generator 包文件了。 当你执行下面的这个命令后，所有的源码文件都会下载到 $GOPATH/src 目录。
$ go get github.com/elastic/beats在 GOPATH 下创建一个以你自己github账号名称命名的目录，并切换过去，然后执行 cookiecutter 命令并指向 Beat Generator 源码路径。
$ cd $GOPATH/src/github.com/{user}
$ cookiecutter $GOPATH/src/github.com/elastic/beats/generate/beatCookiecutter 接下来会问你几个问题，比如项目名称，我们输入：lsbeat；你的 github 用户名，输入你自己的 github 账户；还有两个关于beat和beat_path应该会自动识别，默认回车就好；最后的问题，你可以输入你的姓和名。
project_name [Examplebeat]: lsbeat
github_name [your-github-name]: {username}
beat [lsbeat]:
beat_path [github.com/{github id}]:
full_name [Firstname Lastname]: {Full Name}现在应该已经创建好了一个名为 lsbeat 的目录，并且里面应该会生成一些文件，让我们一起来看一下吧，结构如下：
$ cd lsbeat
$ tree
.
├── CONTRIBUTING.md
├── LICENSE
├── Makefile
├── README.md
├── beater
│ └── lsbeat.go
├── config
│ ├── config.go
│ └── config_test.go
├── dev-tools
│ └── packer
│ ├── Makefile
│ ├── beats
│ │ └── lsbeat.yml
│ └── version.yml
├── docs
│ └── index.asciidoc
├── etc
│ ├── beat.yml
│ └── fields.yml
├── glide.yaml
├── lsbeat.template.json
├── main.go
├── main_test.go
└── tests
└── system
├── config
│ └── lsbeat.yml.j2
├── lsbeat.py
├── requirements.txt
└── test_base.py我们刚刚已经生成好了一个原始的 Beat 模板了，但是你还需要获取相关的依赖和设置好 git 仓库。
首先，你需要拉取依赖的相关包信息，我们的这个例子是 lsbeat，我们先做一些的基本的配置，回头再看看详细看看其它的模板和配置文件，只需要执行 make setup 就可以自动获取依赖。
$ make setup当你创建好了自己的 Beat 之后，记得上传到 github 仓库，并和社区进行分享哦，如下：
要 push lsbeat 到你的 git 仓库，只需要执行如下命令:
$ git remote add origin git@github.com:{username}/lsbeat.git
$ git push -u origin master恭喜你，现在你已经完成了一个 Beat ，并且发布了第一个版本到了 Github，不过里面还没有什么具体内容，现在让我们进一步看看里面的代码吧。
第四步 – 配置
执行过上面一系列命令之后，项目里将会自动创建名为 lsbeat.yml 和 lsbeat.template.json 的配置文件。所有的基本配置项都已经生成在了里面。
lsbeat.yml
lsbeat:
# Defines how often an event is sent to the output
period: 1sPeriod 参数包含在每一个生成的 Beats 里面，它表示 lsbeat 将会每隔 1 秒钟轮询一次，这里我们修改 period 时间间隔为 10 秒。还可以在修改 etc/ 目录下面的 beat.yml 文件，这里新增一个 path 参数表示我们具体要监听哪个目录。
lsbeat:
# Defines how often an event is sent to the output
period: 10s
path: "."参数添加好了之后，我们只需要运行 make update 命令就能让这些修改应用到配置文件lsbeat.yml。
$ make update
$ cat lsbeat.yml
################### Lsbeat Configuration Example #########################
############################# Lsbeat ######################################
lsbeat:
# Defines how often an event is sent to the output
period: 10s
path: "."
###############################################################################修改完 yml 文件，记得修改 config/config.go文件，添加一个path 参数。
package config
import "time"
type Config struct {
Period time.Duration `config:"period"`
Path string `config:"path"`
}
var DefaultConfig = Config{
Period: 10 * time.Second,
Path: ".",
}同时我们修改 period 默认时间间隔为 10 秒，默认监听的是当前目录 (.) 。.
第五步 – 添加代码
每一个 Beat 需要实现 Beater 接口，里面定义了 Run() 和 Stop() 函数。.
我们可以定义一个名为 Lsbeat 的结构体，然后用这个对象实现 Beater 接口。然后添加字段 lastIndexTime 来保存最后运行的时间戳信息。
type Lsbeat struct {
done chan struct{}
config config.Config
client publisher.Client
lastIndexTime time.Time
...
}另外，每个 Beat 还需要实现 New() 方法来接收 Beat 配置信息和返回 Lsbeat 的具体实例。
func New(b *beat.Beat, cfg *common.Config) (beat.Beater, error) {
config := config.DefaultConfig
if err := cfg.Unpack(&config); err != nil {
return nil, fmt.Errorf("Error reading config file: %v", err)
}
ls := &Lsbeat{
done: make(chan struct{}),
config: config,
}
return ls, nil
}在我们的 lsbeat 例子中，我们要做的就是扩展默认的 Run() 函数来导出指定目录的文件和子目录信息。
在修改 Run() 函数之前，我们先在 lsbeat.go 增加 listDir() 函数，就是我们前面最开始测试的那段代码，用于收集目录和文件信息的简单例子稍微修改一下。另外我们还要生成以下字段信息：
"@timestamp": common.Time(time.Now()),
"type": beatname,
"modtime": common.Time(t),
"filename": f.Name(),
"path": dirFile + "/" + f.Name(),
"directory": f.IsDir(),
"filesize": f.Size(),第一次运行的时候我们将索引所有的文件和目录信息，然后我们再定期检查是否有新文件被创建或者修改，再索引这些新创建的文件和目录。每次定期检查的时间戳都会保存在 lasIndexTime 变量，完整代码如下：
func (bt *Lsbeat) listDir(dirFile string, beatname string, init bool) {
files, _ := ioutil.ReadDir(dirFile)
for _, f := range files {
t := f.ModTime()
event := common.MapStr{
"@timestamp": common.Time(time.Now()),
"type": beatname,
"modtime": common.Time(t),
"filename": f.Name(),
"path": dirFile + "/" + f.Name(),
"directory": f.IsDir(),
"filesize": f.Size(),
}
if init {
// index all files and directories on init
bt.client.PublishEvent(event)
} else {
// Index only changed files since last run.
if t.After(bt.lastIndexTime) {
bt.client.PublishEvent(event)
}
}
if f.IsDir() {
bt.listDir(dirFile+"/"+f.Name(), beatname, init)
}
}
}记住在最开始需要导入 “io/ioutil” 包。
import (
"fmt"
"io/ioutil"
"time"
)现在，让我们看看如何在 Run() 函数里面调用 listDir() 函数，并且保存时间戳到 lasIndexTime 变量。
func (bt *Lsbeat) Run(b *beat.Beat) error {
logp.Info("lsbeat is running! Hit CTRL-C to stop it.")
bt.client = b.Publisher.Connect()
ticker := time.NewTicker(bt.config.Period)
counter := 1
for {
select {
case <-bt.done:
return nil
case <-ticker.C:
}
bt.listDir(bt.config.Path, b.Name, true) // call lsDir
bt.lastIndexTime = time.Now() // mark Timestamp
logp.Info("Event sent")
counter++
}
}函数 Stop() 用来中断 run 的循环执行，保持默认生成的就行。
func (bt *Lsbeat) Stop() {
bt.client.Close()
close(bt.done)
}到这里，编码部分基本就完成了。我们接下来添加新字段到 mapping 中，修改文件 etc/fields.yml。.
- key: lsbeat
title: LS Beat
description:
fields:
- name: counter
type: integer
required: true
description: >
PLEASE UPDATE DOCUMENTATION
#new fiels added lsbeat
- name: modtime
type: date
- name: filename
type: text
- name: path
- name: directory
type: boolean
- name: filesize
type: long
重新应用新的配置。
$ make update
字段 file_name 将使用 nGram 分词，我们还需要在文件 lsbeat.template.json 的 “settings” 节点添加一个自定义的 analyzer。
{
"mappings": {
...
},
"order": 0,
"settings": {
"index.refresh_interval": "5s",
"analysis": {
"analyzer": {
"ls_ngram_analyzer": {
"tokenizer": "ls_ngram_tokenizer"
}
},
"tokenizer": {
"ls_ngram_tokenizer": {
"type": "ngram",
"min_gram": "2",
"token_chars": [
"letter",
"digit"
]
}
}
}
},
"template": "lsbeat-*"
}
第六步 – 编译和运行
现在我们可以编译和运行了，只需要执行 make 命令就可以编译出可执行文件 lsbeat (lsbeat.exe on windows) 。
$ make
修改 lsbeat.yml 文件，设置需要监听的目录，如： “/Users/ec2-user/go”，记住是全路径。
lsbeat:
# Defines how often an event is sent to the output
period: 10s
path: "/Users/ec2-user/go"同时确保你的 elasticsearch 和 kibana 正常运行。现在运行一下 lsbeat 命令看看会发生什么事情吧。
$ ./lsbeat
打开Kibana，通过调用 _cat 接口我们看看的索引是不是创建了。
可以看到创建了一个名为 lsbeat-2016.06.03 的索引，并且看到已经有了一些文档了。现在对 filename 字段查询一下，由于使用的是 nGram 分词，支持模糊匹配，我们使用 lsbe 关键字搜一下。
大功告成! 恭喜你，你已经完成了第一个属于你自己的 beat。
开源一组ES工具包,请大家帮忙宣传下,谢谢
Elasticsearch • watano 发表了文章 • 6 个评论 • 5521 次浏览 • 2016-12-03 09:10
https://github.com/DataSays/wES/
wES 是一组开源的Java ElasticSearch客户端和工具; 简洁但是很勥 :)
wES = Java Retrofit2/OkHttp版本的客户端(不依赖Json类库,高度可定制) + 工具包 + spring-boot demo + 常用的ElasticSearch环境Dockerfile
wES 模块
wES 分割成许多模块, 可以按需选择.
wUtil: 一些有用的帮助类和工具类.
wES-client: 一个基于Retrofit2/OkHttp的Java客户端, 她是基于官方的ElasticSearch Rest API规范生成的. 她包含两种访问ElasticSearch的实现: OkHttp3版本的和Retrofit2版本. 而且她只依赖okhttp3/retrofit2,并且可以通过实现org.datasays.wes.core.IConvert接口支持任意一种Java Json类库. 你可以按照你的想法使用她.
wES-toolkit: 一些使用wES-client和ElasticSearch的工具包. 她包含了一套基于Gson的标准IConvert实现及封装代码库.
wES-demo: 一个Spring-boot + Vue.js的web应用, 用于展示一些通用的ElasticSearch使用场景.
wES-docker: 一些构建ElasticSearch开发/生产环境的常用Dockerfiles和shell脚本.
wES 是一组开源的Java ElasticSearch客户端和工具; 简洁但是很勥 :)
wES = Java Retrofit2/OkHttp版本的客户端(不依赖Json类库,高度可定制) + 工具包 + spring-boot demo + 常用的ElasticSearch环境Dockerfile
wES 模块
wES 分割成许多模块, 可以按需选择.
wUtil: 一些有用的帮助类和工具类.
wES-client: 一个基于Retrofit2/OkHttp的Java客户端, 她是基于官方的ElasticSearch Rest API规范生成的. 她包含两种访问ElasticSearch的实现: OkHttp3版本的和Retrofit2版本. 而且她只依赖okhttp3/retrofit2,并且可以通过实现org.datasays.wes.core.IConvert接口支持任意一种Java Json类库. 你可以按照你的想法使用她.
wES-toolkit: 一些使用wES-client和ElasticSearch的工具包. 她包含了一套基于Gson的标准IConvert实现及封装代码库.
wES-demo: 一个Spring-boot + Vue.js的web应用, 用于展示一些通用的ElasticSearch使用场景.
wES-docker: 一些构建ElasticSearch开发/生产环境的常用Dockerfiles和shell脚本.
Day2:《Kibana 系漫游指南》
Advent • 三斗室 发表了文章 • 6 个评论 • 10560 次浏览 • 2016-12-02 22:48
大家好，欢迎你们来到 ELK 三体星系的第二天。昨天，wood 送给大家一本脚踏实地的生存指南，今天让我们仰望星空，由我给大家介绍一下围绕在 Kibana 身边的诸多行星们~
Kibana Plugin 类型简介
我们最熟悉的 Kibana Plugin，其实就是 Kibana 本身~ Kibana 提供了一整套框架，我们可以在此基础上，开发诸多不同类型的插件，包括：
列这么几个源码里的名词出来可能大家觉得比较晦涩。其实呢，app 就是同时具有前后端实现的应用，在 Kibana 5 里，默认分发的 app 有四个：实现日志查询和可视化的 kibana app、实现时序指标统计和可视化的 timelion app、实现和 ES 接口交互命令的 console app、在有异常的时候才看得到的状态页面 status_page app。
而 visTypes 则是在 kibana 中具体可用的可视化效果。默认分发的有：kbn_vislib_vis_types、metric、table、markdown。我们常用的那些由 D3.js 完成的饼图线图地图，都是在 kbn_vislib_vis_types 中完成的。
fieldFormatter 则用来定义在 ES 中相同类型的数据，根据其实际含义，可以有不同的展示方式。比如说：URL 肯定是一个字符串，但是可以用 fieldFormatter 把它在页面展示的时候，加上 `<a href></a>` 的样式，让人一键点击；同理，还可以过滤判断一下图片类 URL，加上 `<img src></img>` 的样式，直接在 Kibana 界面上就看图片内容~~
官方的我们会看手册啦~
好啦好啦，我也不会真的去抄一把官方手册假冒《Kibana 系漫游指南》来骗你们流量的。下面给大家介绍一些社区开源的，让你绝对眼前一亮的各种新奇扩展：
1. logtrail
这是一个 app 插件，创意来自 papertrail 公司的产品。完全的满足了 Geeker 们喜欢黑底白字终端的癖好~不过其实实现非常简单：每隔 10 秒请求一次最近 500 条日志就是啦！
2. vectormap
这是一个 visType 插件，也就是我们在 Kibana3 里曾经用过的 map panel 效果。这个插件不被官方直接采用的一个原因是版权许可问题。不做商用的情况下，这个插件还是可以极大方便我们做行政区域的访问情况统计和展示的。
3. kbn_network
这也是一个 visType 插件，酷毙了的网状图效果！通过不同的 aggs 数据展示 node 和 relational。
注意这个跟 Elastic 的 graph 并不是完全一致的东西。该插件要求你本身的数据已经有直接的关联可用。
4. sentinl
这是一个同时带有 spyMode 和 app 双插件的项目。其基础思路是参照 Elastic 的 Watcher 接口，但是将监控告警的进程从 ES 挪到 Kibana 里。同时还可以通过 phantomjs 做到截图报表。
这个项目最大的特点，是通过 spyMode 插件，大大降低了配置告警规则的复杂度。这个扩展让你可以在 Kibana 上配置任意聚合效果之后，就地点击定义当前聚合语句为告警规则！
5. kibana-keynote
这是另一个剑走偏锋的 app 插件，出自 Kibana 作者本人之手。它的作用是：播放 keynote 演讲稿！事实上项目里放的演讲稿就是作者本人在 ELastic{ON} 2016 上用的。让我们猜一猜下周的大会上，他会不会就用这个插件给我们分享呢？
今天就先讲这几颗最闪亮的星了~有兴趣了解更多 Kibana 行星的游客，欢迎阅读全本《Kibana系漫游指南》。
也欢迎观看 Kibana 行星的《探索·发现》节目哟~
Kibana Plugin 类型简介
我们最熟悉的 Kibana Plugin，其实就是 Kibana 本身~ Kibana 提供了一整套框架，我们可以在此基础上，开发诸多不同类型的插件，包括：
- app
- visTypes
- spyModes
- fieldFormatter
列这么几个源码里的名词出来可能大家觉得比较晦涩。其实呢，app 就是同时具有前后端实现的应用，在 Kibana 5 里，默认分发的 app 有四个：实现日志查询和可视化的 kibana app、实现时序指标统计和可视化的 timelion app、实现和 ES 接口交互命令的 console app、在有异常的时候才看得到的状态页面 status_page app。
而 visTypes 则是在 kibana 中具体可用的可视化效果。默认分发的有：kbn_vislib_vis_types、metric、table、markdown。我们常用的那些由 D3.js 完成的饼图线图地图，都是在 kbn_vislib_vis_types 中完成的。
fieldFormatter 则用来定义在 ES 中相同类型的数据，根据其实际含义，可以有不同的展示方式。比如说：URL 肯定是一个字符串，但是可以用 fieldFormatter 把它在页面展示的时候，加上 `<a href></a>` 的样式，让人一键点击；同理，还可以过滤判断一下图片类 URL，加上 `<img src></img>` 的样式，直接在 Kibana 界面上就看图片内容~~
官方的我们会看手册啦~
好啦好啦，我也不会真的去抄一把官方手册假冒《Kibana 系漫游指南》来骗你们流量的。下面给大家介绍一些社区开源的，让你绝对眼前一亮的各种新奇扩展：
1. logtrail
这是一个 app 插件，创意来自 papertrail 公司的产品。完全的满足了 Geeker 们喜欢黑底白字终端的癖好~不过其实实现非常简单：每隔 10 秒请求一次最近 500 条日志就是啦！
2. vectormap
这是一个 visType 插件，也就是我们在 Kibana3 里曾经用过的 map panel 效果。这个插件不被官方直接采用的一个原因是版权许可问题。不做商用的情况下，这个插件还是可以极大方便我们做行政区域的访问情况统计和展示的。
3. kbn_network
这也是一个 visType 插件，酷毙了的网状图效果！通过不同的 aggs 数据展示 node 和 relational。
注意这个跟 Elastic 的 graph 并不是完全一致的东西。该插件要求你本身的数据已经有直接的关联可用。
4. sentinl
这是一个同时带有 spyMode 和 app 双插件的项目。其基础思路是参照 Elastic 的 Watcher 接口，但是将监控告警的进程从 ES 挪到 Kibana 里。同时还可以通过 phantomjs 做到截图报表。
这个项目最大的特点，是通过 spyMode 插件，大大降低了配置告警规则的复杂度。这个扩展让你可以在 Kibana 上配置任意聚合效果之后，就地点击定义当前聚合语句为告警规则！
5. kibana-keynote
这是另一个剑走偏锋的 app 插件，出自 Kibana 作者本人之手。它的作用是：播放 keynote 演讲稿！事实上项目里放的演讲稿就是作者本人在 ELastic{ON} 2016 上用的。让我们猜一猜下周的大会上，他会不会就用这个插件给我们分享呢？
今天就先讲这几颗最闪亮的星了~有兴趣了解更多 Kibana 行星的游客，欢迎阅读全本《Kibana系漫游指南》。
也欢迎观看 Kibana 行星的《探索·发现》节目哟~
Message not fully read
Elasticsearch • flydream 回复了问题 • 2 人关注 • 1 个回复 • 5660 次浏览 • 2016-12-19 10:49
