Elasticsearch 安全 （希望日报能给我发下。）
主要讲解如何通过Search guard 为Elasticsearch 进行安全加固。
http://rickywag.com/archives/618
http://rickywag.com/archives/618
主要讲解如何通过Search guard 为Elasticsearch 进行安全加固。
http://rickywag.com/archives/618
http://rickywag.com/archives/618
社区日报 第88期 (2017-11-02)
1.ES集群服务器CPU负载瞬间飚高分析
https://elasticsearch.cn/article/348
2.elasticsearch api 101
http://t.cn/RlZ1PND
3.一个免费的支持kibana多租户、加密、认证、授权、审计的Elasticsearch和Kibana安全插件
http://t.cn/RZpF03g
活动预告：Elastic 武汉交流会
https://elasticsearch.cn/article/344
感谢社区well的投稿
编辑：金桥
归档：https://elasticsearch.cn/article/349
订阅：https://tinyletter.com/elastic-daily
继续阅读 »
https://elasticsearch.cn/article/348
2.elasticsearch api 101
http://t.cn/RlZ1PND
3.一个免费的支持kibana多租户、加密、认证、授权、审计的Elasticsearch和Kibana安全插件
http://t.cn/RZpF03g
活动预告：Elastic 武汉交流会
https://elasticsearch.cn/article/344
感谢社区well的投稿
编辑：金桥
归档：https://elasticsearch.cn/article/349
订阅：https://tinyletter.com/elastic-daily
1.ES集群服务器CPU负载瞬间飚高分析
https://elasticsearch.cn/article/348
2.elasticsearch api 101
http://t.cn/RlZ1PND
3.一个免费的支持kibana多租户、加密、认证、授权、审计的Elasticsearch和Kibana安全插件
http://t.cn/RZpF03g
活动预告：Elastic 武汉交流会
https://elasticsearch.cn/article/344
感谢社区well的投稿
编辑：金桥
归档：https://elasticsearch.cn/article/349
订阅：https://tinyletter.com/elastic-daily 收起阅读 »
https://elasticsearch.cn/article/348
2.elasticsearch api 101
http://t.cn/RlZ1PND
3.一个免费的支持kibana多租户、加密、认证、授权、审计的Elasticsearch和Kibana安全插件
http://t.cn/RZpF03g
活动预告：Elastic 武汉交流会
https://elasticsearch.cn/article/344
感谢社区well的投稿
编辑：金桥
归档：https://elasticsearch.cn/article/349
订阅：https://tinyletter.com/elastic-daily 收起阅读 »
ES集群服务器CPU负载瞬间飚高分析
先观察了下集群系统资源的使用情况，发现网络、磁盘、内存等都没有什么迹象，唯独 CPU 负载就是居高不下，系统响应很慢，几乎不响应。几次使用 JVM 命令都无功而返。经过多次使用 Top 命令，才发现导致 CPU 负载过高（飙到200多）是 %sy 这项，表面现象是操作系统内核导致。之前无数次怀疑 Java 程序问题，GC 问题，看来方向错了，既然耗那么长时间才找到一丝线索，应该好好利用。
尝试了一些命令后，发现和使用 JVM 命令一样，搞不定，比如用 ltrace 就导致 JVM 进程僵死。由于并非稳定重现，耗时好几天，才使用 strace -T -r -c -f -F -p 得到 futex、epoll_wait 占用资源。这不行，这些信息不足以说明或支撑如何解决负载问题，但 futex 这个是系统调用是互斥的信号，难道有锁方面问题，似乎应该从这个方面下手。
Linux 中有什么好的工具能在这种敲命令都没响应的情况下来获取一些信息呢？于是再找一些工具，gdb 尝试了下，直接卡死，搞不定。gstack、gcore 都不行，难道非得要 dump kernel core？
但即使得到了，我对 Linux 内核的分析还没多少经验，而且耗时，中间少不了服务器频繁重启，不到万不得已不走这一步。
找了一些工具：systemtap、stap、dtrace、perf 等，于是在非繁忙时候搞了一把，systemtap 的 On-CPU、Off-CPU 及火焰图不错，至少我能拿到内核系统调用到底是哪些，然后针对火焰图里耗时的系统调用信息再找具体的解决方案。systemtap 虽好，但那个 sample-bt 脚本总不如意，在负载高的时候被自己的资源限制，改了些参数也不如意。于是转向 perf，这玩意好，轻量级，就取个 60s 信息，多来几把，嘿嘿，还正搞出一些数据。
# perf record -F 99 -ag -o p1.data -- sleep 60
# perf script -i p1.data | ./stackcollapse-perf.pl > out.perf-folded
# cat out.perf-folded | ./flamegraph.pl > perf-kernel-1.svg
将分析的数据转换为火焰图，用火眼金睛照一照，还真能看出一些问题。
通过调用依赖关系分析，根据 _spin_lock_irq 初步推测问题由 kernel 的内存管理部分触发。
似乎 CentOS 6 相对于 CentOS 5 在 kernel 内存管理模块的一些改进点（如 transparent huge page, 基于 NUMA 的内存分配等），有没有可能是 CentOS 6 新增的 THP 特性导致 cpu sys 过高？搜索下相关函数名的关键字，确定猜测正确。通过以下内核参数优化关闭系统 THP 特性（临时生效）:
# echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
# echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
从火焰图我们也可以看到，申请内存的线程在等待自旋锁，操作系统现在正回收 pagecache 到 freelist。于是 zone 里来申请内存的线程都得在这里等待着，于是 load 值就高了上来。外在的表现就是，系统反应好慢啊，ssh 都登不进去（因为 ssh 也会申请内存）；即使登录进去了，敲命令也没有反应（因为这些命令也都是需要申请内存的）。
几个概念（来源于网络）：
page cache
导致这个情况的原因是：线程在申请内存的时候，发现该 zone 的 freelist 上已经没有足够的内存可用，所以不得不去从该 zone 的 LRU 链表里回收 inactive 的 page，这种情况就是 direct reclaim（直接回收）。direct reclaim 会比较消耗时间的原因是，它在回收的时候不会区分 dirty page 和 clean page，
如果回收的是 dirty page，就会触发磁盘 IO 的操作，它会首先把 dirty page 里面的内容给刷写到磁盘，再去把该 page 给放到 freelist 里。
page reclaim
在直观上，我们有一个认知，当读了一个文件，它会被缓存到内存里面，如果接下来的一几天我们一直都不会再次访问它，而且这几天都不会关闭或者重启机器，那么在这几天之后该文件就不应该再在内存里头了。这就是内核对 page cache 的管理策略：LRU（最近最少使用）。即把最近最少使用的 page cache 给回收为 free pages。
内核的页回收机制有两种：后台回收和直接回收。
后台回收是有一个内核线程 kswapd 来做的，当内存里 free 的 pages 低于一个水位（page_low）时，就会唤醒该内核线程，然后它从 LRU 链表里回收 page cache 到内存的 free_list 里头，它会一直回收直至 free 的 pages 达到另外一个水位 page_high. 如下图所示：
直接回收则是，在发生 page fault 时，没有足够可用的内存，于是线程就自己直接去回收内存，它一次性的会回收 32 个 pages。逻辑过程如下图所示
所以要避免做 direct reclaim。
memory zone
对于多核 NUMA 系统而言，内存是分节点的，不同的 CPU 对不同的内存节点的访问速度是不一样的，所以 CPU 会优先去访问靠近自己的内存节点（即速度相对快的内存区域）。
CPU 内部是依靠 MMU 来进行内存管理的，根据内存属性的不同，MMU 将一个内存节点内部又划分了不同的 zone。
对 64-bit 系统而言，一个内存节点包含三个 zone：Normal，DMA，DMA32.
对 32-bit 系统而言，一个内存节点则是包括 zone：Normal，Highmem，DMA。
Highmem 存在的目的是为了解决线性地址空间不够用的问题，在 64-bit 上由于有足够的线性地址空间所以就没了该 zone。不同 zone 存在的目的是基于数据的局部性原则，我们在写代码的时候也知道，把相关的数据给放在一起可以提高性能，memory zone 也是这个道理。于是 MMU 在分配内存时，也会尽量给同一个进程分配同一个 zone 的内存。凡事有利就有弊，这样有好处自然也可能会带来一些坏处。
为了避免 direct reclaim，我们得保证在进程申请内存时有足够可用的 free pages，从前面我们可以看出，提高 watermark low 可以尽早的唤醒 kswapd，然后 kswapd 来做 background reclaim。为此，内核专门提供了一个 sysctl 接口给用户来使用：vm.extra_free_kbytes。
# cat /etc/sysctl.conf | grep kbytes
vm.extra_free_kbytes = 4096000
vm.min_free_kbytes = 2097152
于是我们增大这个值（比如增大到 5G），确实也解决了问题。增大该值来提高 low 水位，这样在申请内存的时候，如果 free 的内存低于了该水位，就会唤醒 kswapd 去做页回收，同时又由于还有足够的 free 内存可用所以进程能够正常申请而不触发直接回收。
线程的回收跟 memory zone 相关。也就是说 normal zone 里面的 free pages 不够用了，于是触发了 direct reclaim。但是，假如此时 DMA zone 里还有足够的 free pages 呢？线程会不会从 DMA zone 里来申请内存呢？
free 的 pages 都在其它的 zone 里头，所以线程去回收自己 zone 的 page cache 而不去使用其它 zone 的 free pages。对于这个内核也提供了一个接口给用户使用：vm.zone_reclaim_mode. 这个值在该机器上本来是1（即宁肯回收自己 zone 的 page cache，也不去申请其它 zone 的 free pages）,我把它更改为0（即只要其它 zone 有 free pages 就去其它 zone 里申请）,就解决了该问题（一设置后系统就恢复了正常）
从这个问题也可以看出，Linux 内核提供了各种各样的机制，然后我们根据具体的使用场景来选择使用的策略。目的是为了在不影响稳定性的前提下，尽可能的提升系统性能。
Linux 机制的多种多样，也给上层的开发者带来了一些苦恼：由于对底层了解的不深入，就很难选择出一个很好的策略来使用这些内核机制。
然而对这些机制的使用，也不会有一个万能公式，还是要看具体的使用场景。由于搜索服务器存在很多批量文件操作，所以对 page cache 的使用很频繁，
所以我们才选择了尽早的能够触发 background reclaim 这个策略；而如果你的文件操作不频繁，显然就没有必要去尽早的唤醒后台回收线程。
另外一个，作为一个文件服务器，它对 page cache 的需求是很大的，越多的内存作为 page cache，系统的整体性能就会越好，所以我们就没有必要为了数据的局部性而预留 DMA 内存，
两相比较肯定是 page cache 对性能的提升大于数据的局部性对性能的提升；而如果你的文件操作不多的话，那还是打开 zone_reclaim 的。
# cat /etc/sysctl.conf | grep zone
vm.zone_reclaim_mode = 0
经过调整以上这几个参数后，再持续监控一段时间，问题得以解决。
在 redhat 官网和 cloudera 官网也搜到了相关的内容，附录下来，供参考。
在 redhat 的官网上，有对THP特性的细化说明：
https://access.redhat.com/site ... .html
在 cloudera 的 CDH4 部署说明中，也建议将系统的 THP 的 compaction 特性关闭：
http://www.cloudera.com/conten ... .html
继续阅读 »
尝试了一些命令后，发现和使用 JVM 命令一样，搞不定，比如用 ltrace 就导致 JVM 进程僵死。由于并非稳定重现，耗时好几天，才使用 strace -T -r -c -f -F -p 得到 futex、epoll_wait 占用资源。这不行，这些信息不足以说明或支撑如何解决负载问题，但 futex 这个是系统调用是互斥的信号，难道有锁方面问题，似乎应该从这个方面下手。
Linux 中有什么好的工具能在这种敲命令都没响应的情况下来获取一些信息呢？于是再找一些工具，gdb 尝试了下，直接卡死，搞不定。gstack、gcore 都不行，难道非得要 dump kernel core？
但即使得到了，我对 Linux 内核的分析还没多少经验，而且耗时，中间少不了服务器频繁重启，不到万不得已不走这一步。
找了一些工具：systemtap、stap、dtrace、perf 等，于是在非繁忙时候搞了一把，systemtap 的 On-CPU、Off-CPU 及火焰图不错，至少我能拿到内核系统调用到底是哪些，然后针对火焰图里耗时的系统调用信息再找具体的解决方案。systemtap 虽好，但那个 sample-bt 脚本总不如意，在负载高的时候被自己的资源限制，改了些参数也不如意。于是转向 perf，这玩意好，轻量级，就取个 60s 信息，多来几把，嘿嘿，还正搞出一些数据。
# perf record -F 99 -ag -o p1.data -- sleep 60
# perf script -i p1.data | ./stackcollapse-perf.pl > out.perf-folded
# cat out.perf-folded | ./flamegraph.pl > perf-kernel-1.svg
将分析的数据转换为火焰图，用火眼金睛照一照，还真能看出一些问题。
通过调用依赖关系分析，根据 _spin_lock_irq 初步推测问题由 kernel 的内存管理部分触发。
似乎 CentOS 6 相对于 CentOS 5 在 kernel 内存管理模块的一些改进点（如 transparent huge page, 基于 NUMA 的内存分配等），有没有可能是 CentOS 6 新增的 THP 特性导致 cpu sys 过高？搜索下相关函数名的关键字，确定猜测正确。通过以下内核参数优化关闭系统 THP 特性（临时生效）:
# echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
# echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
从火焰图我们也可以看到，申请内存的线程在等待自旋锁，操作系统现在正回收 pagecache 到 freelist。于是 zone 里来申请内存的线程都得在这里等待着，于是 load 值就高了上来。外在的表现就是，系统反应好慢啊，ssh 都登不进去（因为 ssh 也会申请内存）；即使登录进去了，敲命令也没有反应（因为这些命令也都是需要申请内存的）。
几个概念（来源于网络）：
page cache
导致这个情况的原因是：线程在申请内存的时候，发现该 zone 的 freelist 上已经没有足够的内存可用，所以不得不去从该 zone 的 LRU 链表里回收 inactive 的 page，这种情况就是 direct reclaim（直接回收）。direct reclaim 会比较消耗时间的原因是，它在回收的时候不会区分 dirty page 和 clean page，
如果回收的是 dirty page，就会触发磁盘 IO 的操作，它会首先把 dirty page 里面的内容给刷写到磁盘，再去把该 page 给放到 freelist 里。
page reclaim
在直观上，我们有一个认知，当读了一个文件，它会被缓存到内存里面，如果接下来的一几天我们一直都不会再次访问它，而且这几天都不会关闭或者重启机器，那么在这几天之后该文件就不应该再在内存里头了。这就是内核对 page cache 的管理策略：LRU（最近最少使用）。即把最近最少使用的 page cache 给回收为 free pages。
内核的页回收机制有两种：后台回收和直接回收。
后台回收是有一个内核线程 kswapd 来做的，当内存里 free 的 pages 低于一个水位（page_low）时，就会唤醒该内核线程，然后它从 LRU 链表里回收 page cache 到内存的 free_list 里头，它会一直回收直至 free 的 pages 达到另外一个水位 page_high. 如下图所示：
直接回收则是，在发生 page fault 时，没有足够可用的内存，于是线程就自己直接去回收内存，它一次性的会回收 32 个 pages。逻辑过程如下图所示
所以要避免做 direct reclaim。
memory zone
对于多核 NUMA 系统而言，内存是分节点的，不同的 CPU 对不同的内存节点的访问速度是不一样的，所以 CPU 会优先去访问靠近自己的内存节点（即速度相对快的内存区域）。
CPU 内部是依靠 MMU 来进行内存管理的，根据内存属性的不同，MMU 将一个内存节点内部又划分了不同的 zone。
对 64-bit 系统而言，一个内存节点包含三个 zone：Normal，DMA，DMA32.
对 32-bit 系统而言，一个内存节点则是包括 zone：Normal，Highmem，DMA。
Highmem 存在的目的是为了解决线性地址空间不够用的问题，在 64-bit 上由于有足够的线性地址空间所以就没了该 zone。不同 zone 存在的目的是基于数据的局部性原则，我们在写代码的时候也知道，把相关的数据给放在一起可以提高性能，memory zone 也是这个道理。于是 MMU 在分配内存时，也会尽量给同一个进程分配同一个 zone 的内存。凡事有利就有弊，这样有好处自然也可能会带来一些坏处。
为了避免 direct reclaim，我们得保证在进程申请内存时有足够可用的 free pages，从前面我们可以看出，提高 watermark low 可以尽早的唤醒 kswapd，然后 kswapd 来做 background reclaim。为此，内核专门提供了一个 sysctl 接口给用户来使用：vm.extra_free_kbytes。
# cat /etc/sysctl.conf | grep kbytes
vm.extra_free_kbytes = 4096000
vm.min_free_kbytes = 2097152
于是我们增大这个值（比如增大到 5G），确实也解决了问题。增大该值来提高 low 水位，这样在申请内存的时候，如果 free 的内存低于了该水位，就会唤醒 kswapd 去做页回收，同时又由于还有足够的 free 内存可用所以进程能够正常申请而不触发直接回收。
线程的回收跟 memory zone 相关。也就是说 normal zone 里面的 free pages 不够用了，于是触发了 direct reclaim。但是，假如此时 DMA zone 里还有足够的 free pages 呢？线程会不会从 DMA zone 里来申请内存呢？
free 的 pages 都在其它的 zone 里头，所以线程去回收自己 zone 的 page cache 而不去使用其它 zone 的 free pages。对于这个内核也提供了一个接口给用户使用：vm.zone_reclaim_mode. 这个值在该机器上本来是1（即宁肯回收自己 zone 的 page cache，也不去申请其它 zone 的 free pages）,我把它更改为0（即只要其它 zone 有 free pages 就去其它 zone 里申请）,就解决了该问题（一设置后系统就恢复了正常）
从这个问题也可以看出，Linux 内核提供了各种各样的机制，然后我们根据具体的使用场景来选择使用的策略。目的是为了在不影响稳定性的前提下，尽可能的提升系统性能。
Linux 机制的多种多样，也给上层的开发者带来了一些苦恼：由于对底层了解的不深入，就很难选择出一个很好的策略来使用这些内核机制。
然而对这些机制的使用，也不会有一个万能公式，还是要看具体的使用场景。由于搜索服务器存在很多批量文件操作，所以对 page cache 的使用很频繁，
所以我们才选择了尽早的能够触发 background reclaim 这个策略；而如果你的文件操作不频繁，显然就没有必要去尽早的唤醒后台回收线程。
另外一个，作为一个文件服务器，它对 page cache 的需求是很大的，越多的内存作为 page cache，系统的整体性能就会越好，所以我们就没有必要为了数据的局部性而预留 DMA 内存，
两相比较肯定是 page cache 对性能的提升大于数据的局部性对性能的提升；而如果你的文件操作不多的话，那还是打开 zone_reclaim 的。
# cat /etc/sysctl.conf | grep zone
vm.zone_reclaim_mode = 0
经过调整以上这几个参数后，再持续监控一段时间，问题得以解决。
在 redhat 官网和 cloudera 官网也搜到了相关的内容，附录下来，供参考。
在 redhat 的官网上，有对THP特性的细化说明：
https://access.redhat.com/site ... .html
在 cloudera 的 CDH4 部署说明中，也建议将系统的 THP 的 compaction 特性关闭：
http://www.cloudera.com/conten ... .html
先观察了下集群系统资源的使用情况，发现网络、磁盘、内存等都没有什么迹象，唯独 CPU 负载就是居高不下，系统响应很慢，几乎不响应。几次使用 JVM 命令都无功而返。经过多次使用 Top 命令，才发现导致 CPU 负载过高（飙到200多）是 %sy 这项，表面现象是操作系统内核导致。之前无数次怀疑 Java 程序问题，GC 问题，看来方向错了，既然耗那么长时间才找到一丝线索，应该好好利用。
尝试了一些命令后，发现和使用 JVM 命令一样，搞不定，比如用 ltrace 就导致 JVM 进程僵死。由于并非稳定重现，耗时好几天，才使用 strace -T -r -c -f -F -p 得到 futex、epoll_wait 占用资源。这不行，这些信息不足以说明或支撑如何解决负载问题，但 futex 这个是系统调用是互斥的信号，难道有锁方面问题，似乎应该从这个方面下手。
Linux 中有什么好的工具能在这种敲命令都没响应的情况下来获取一些信息呢？于是再找一些工具，gdb 尝试了下，直接卡死，搞不定。gstack、gcore 都不行，难道非得要 dump kernel core？
但即使得到了，我对 Linux 内核的分析还没多少经验，而且耗时，中间少不了服务器频繁重启，不到万不得已不走这一步。
找了一些工具：systemtap、stap、dtrace、perf 等，于是在非繁忙时候搞了一把，systemtap 的 On-CPU、Off-CPU 及火焰图不错，至少我能拿到内核系统调用到底是哪些，然后针对火焰图里耗时的系统调用信息再找具体的解决方案。systemtap 虽好，但那个 sample-bt 脚本总不如意，在负载高的时候被自己的资源限制，改了些参数也不如意。于是转向 perf，这玩意好，轻量级，就取个 60s 信息，多来几把，嘿嘿，还正搞出一些数据。
# perf record -F 99 -ag -o p1.data -- sleep 60
# perf script -i p1.data | ./stackcollapse-perf.pl > out.perf-folded
# cat out.perf-folded | ./flamegraph.pl > perf-kernel-1.svg
将分析的数据转换为火焰图，用火眼金睛照一照，还真能看出一些问题。
通过调用依赖关系分析，根据 _spin_lock_irq 初步推测问题由 kernel 的内存管理部分触发。
似乎 CentOS 6 相对于 CentOS 5 在 kernel 内存管理模块的一些改进点（如 transparent huge page, 基于 NUMA 的内存分配等），有没有可能是 CentOS 6 新增的 THP 特性导致 cpu sys 过高？搜索下相关函数名的关键字，确定猜测正确。通过以下内核参数优化关闭系统 THP 特性（临时生效）:
# echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
# echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
从火焰图我们也可以看到，申请内存的线程在等待自旋锁，操作系统现在正回收 pagecache 到 freelist。于是 zone 里来申请内存的线程都得在这里等待着，于是 load 值就高了上来。外在的表现就是，系统反应好慢啊，ssh 都登不进去（因为 ssh 也会申请内存）；即使登录进去了，敲命令也没有反应（因为这些命令也都是需要申请内存的）。
几个概念（来源于网络）：
page cache
导致这个情况的原因是：线程在申请内存的时候，发现该 zone 的 freelist 上已经没有足够的内存可用，所以不得不去从该 zone 的 LRU 链表里回收 inactive 的 page，这种情况就是 direct reclaim（直接回收）。direct reclaim 会比较消耗时间的原因是，它在回收的时候不会区分 dirty page 和 clean page，
如果回收的是 dirty page，就会触发磁盘 IO 的操作，它会首先把 dirty page 里面的内容给刷写到磁盘，再去把该 page 给放到 freelist 里。
page reclaim
在直观上，我们有一个认知，当读了一个文件，它会被缓存到内存里面，如果接下来的一几天我们一直都不会再次访问它，而且这几天都不会关闭或者重启机器，那么在这几天之后该文件就不应该再在内存里头了。这就是内核对 page cache 的管理策略：LRU（最近最少使用）。即把最近最少使用的 page cache 给回收为 free pages。
内核的页回收机制有两种：后台回收和直接回收。
后台回收是有一个内核线程 kswapd 来做的，当内存里 free 的 pages 低于一个水位（page_low）时，就会唤醒该内核线程，然后它从 LRU 链表里回收 page cache 到内存的 free_list 里头，它会一直回收直至 free 的 pages 达到另外一个水位 page_high. 如下图所示：
直接回收则是，在发生 page fault 时，没有足够可用的内存，于是线程就自己直接去回收内存，它一次性的会回收 32 个 pages。逻辑过程如下图所示
所以要避免做 direct reclaim。
memory zone
对于多核 NUMA 系统而言，内存是分节点的，不同的 CPU 对不同的内存节点的访问速度是不一样的，所以 CPU 会优先去访问靠近自己的内存节点（即速度相对快的内存区域）。
CPU 内部是依靠 MMU 来进行内存管理的，根据内存属性的不同，MMU 将一个内存节点内部又划分了不同的 zone。
对 64-bit 系统而言，一个内存节点包含三个 zone：Normal，DMA，DMA32.
对 32-bit 系统而言，一个内存节点则是包括 zone：Normal，Highmem，DMA。
Highmem 存在的目的是为了解决线性地址空间不够用的问题，在 64-bit 上由于有足够的线性地址空间所以就没了该 zone。不同 zone 存在的目的是基于数据的局部性原则，我们在写代码的时候也知道，把相关的数据给放在一起可以提高性能，memory zone 也是这个道理。于是 MMU 在分配内存时，也会尽量给同一个进程分配同一个 zone 的内存。凡事有利就有弊，这样有好处自然也可能会带来一些坏处。
为了避免 direct reclaim，我们得保证在进程申请内存时有足够可用的 free pages，从前面我们可以看出，提高 watermark low 可以尽早的唤醒 kswapd，然后 kswapd 来做 background reclaim。为此，内核专门提供了一个 sysctl 接口给用户来使用：vm.extra_free_kbytes。
# cat /etc/sysctl.conf | grep kbytes
vm.extra_free_kbytes = 4096000
vm.min_free_kbytes = 2097152
于是我们增大这个值（比如增大到 5G），确实也解决了问题。增大该值来提高 low 水位，这样在申请内存的时候，如果 free 的内存低于了该水位，就会唤醒 kswapd 去做页回收，同时又由于还有足够的 free 内存可用所以进程能够正常申请而不触发直接回收。
线程的回收跟 memory zone 相关。也就是说 normal zone 里面的 free pages 不够用了，于是触发了 direct reclaim。但是，假如此时 DMA zone 里还有足够的 free pages 呢？线程会不会从 DMA zone 里来申请内存呢？
free 的 pages 都在其它的 zone 里头，所以线程去回收自己 zone 的 page cache 而不去使用其它 zone 的 free pages。对于这个内核也提供了一个接口给用户使用：vm.zone_reclaim_mode. 这个值在该机器上本来是1（即宁肯回收自己 zone 的 page cache，也不去申请其它 zone 的 free pages）,我把它更改为0（即只要其它 zone 有 free pages 就去其它 zone 里申请）,就解决了该问题（一设置后系统就恢复了正常）
从这个问题也可以看出，Linux 内核提供了各种各样的机制，然后我们根据具体的使用场景来选择使用的策略。目的是为了在不影响稳定性的前提下，尽可能的提升系统性能。
Linux 机制的多种多样，也给上层的开发者带来了一些苦恼：由于对底层了解的不深入，就很难选择出一个很好的策略来使用这些内核机制。
然而对这些机制的使用，也不会有一个万能公式，还是要看具体的使用场景。由于搜索服务器存在很多批量文件操作，所以对 page cache 的使用很频繁，
所以我们才选择了尽早的能够触发 background reclaim 这个策略；而如果你的文件操作不频繁，显然就没有必要去尽早的唤醒后台回收线程。
另外一个，作为一个文件服务器，它对 page cache 的需求是很大的，越多的内存作为 page cache，系统的整体性能就会越好，所以我们就没有必要为了数据的局部性而预留 DMA 内存，
两相比较肯定是 page cache 对性能的提升大于数据的局部性对性能的提升；而如果你的文件操作不多的话，那还是打开 zone_reclaim 的。
# cat /etc/sysctl.conf | grep zone
vm.zone_reclaim_mode = 0
经过调整以上这几个参数后，再持续监控一段时间，问题得以解决。
在 redhat 官网和 cloudera 官网也搜到了相关的内容，附录下来，供参考。
在 redhat 的官网上，有对THP特性的细化说明：
https://access.redhat.com/site ... .html
在 cloudera 的 CDH4 部署说明中，也建议将系统的 THP 的 compaction 特性关闭：
http://www.cloudera.com/conten ... .html 收起阅读 »
尝试了一些命令后，发现和使用 JVM 命令一样，搞不定，比如用 ltrace 就导致 JVM 进程僵死。由于并非稳定重现，耗时好几天，才使用 strace -T -r -c -f -F -p 得到 futex、epoll_wait 占用资源。这不行，这些信息不足以说明或支撑如何解决负载问题，但 futex 这个是系统调用是互斥的信号，难道有锁方面问题，似乎应该从这个方面下手。
Linux 中有什么好的工具能在这种敲命令都没响应的情况下来获取一些信息呢？于是再找一些工具，gdb 尝试了下，直接卡死，搞不定。gstack、gcore 都不行，难道非得要 dump kernel core？
但即使得到了，我对 Linux 内核的分析还没多少经验，而且耗时，中间少不了服务器频繁重启，不到万不得已不走这一步。
找了一些工具：systemtap、stap、dtrace、perf 等，于是在非繁忙时候搞了一把，systemtap 的 On-CPU、Off-CPU 及火焰图不错，至少我能拿到内核系统调用到底是哪些，然后针对火焰图里耗时的系统调用信息再找具体的解决方案。systemtap 虽好，但那个 sample-bt 脚本总不如意，在负载高的时候被自己的资源限制，改了些参数也不如意。于是转向 perf，这玩意好，轻量级，就取个 60s 信息，多来几把，嘿嘿，还正搞出一些数据。
# perf record -F 99 -ag -o p1.data -- sleep 60
# perf script -i p1.data | ./stackcollapse-perf.pl > out.perf-folded
# cat out.perf-folded | ./flamegraph.pl > perf-kernel-1.svg
将分析的数据转换为火焰图，用火眼金睛照一照，还真能看出一些问题。
通过调用依赖关系分析，根据 _spin_lock_irq 初步推测问题由 kernel 的内存管理部分触发。
似乎 CentOS 6 相对于 CentOS 5 在 kernel 内存管理模块的一些改进点（如 transparent huge page, 基于 NUMA 的内存分配等），有没有可能是 CentOS 6 新增的 THP 特性导致 cpu sys 过高？搜索下相关函数名的关键字，确定猜测正确。通过以下内核参数优化关闭系统 THP 特性（临时生效）:
# echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
# echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
从火焰图我们也可以看到，申请内存的线程在等待自旋锁，操作系统现在正回收 pagecache 到 freelist。于是 zone 里来申请内存的线程都得在这里等待着，于是 load 值就高了上来。外在的表现就是，系统反应好慢啊，ssh 都登不进去（因为 ssh 也会申请内存）；即使登录进去了，敲命令也没有反应（因为这些命令也都是需要申请内存的）。
几个概念（来源于网络）：
page cache
导致这个情况的原因是：线程在申请内存的时候，发现该 zone 的 freelist 上已经没有足够的内存可用，所以不得不去从该 zone 的 LRU 链表里回收 inactive 的 page，这种情况就是 direct reclaim（直接回收）。direct reclaim 会比较消耗时间的原因是，它在回收的时候不会区分 dirty page 和 clean page，
如果回收的是 dirty page，就会触发磁盘 IO 的操作，它会首先把 dirty page 里面的内容给刷写到磁盘，再去把该 page 给放到 freelist 里。
page reclaim
在直观上，我们有一个认知，当读了一个文件，它会被缓存到内存里面，如果接下来的一几天我们一直都不会再次访问它，而且这几天都不会关闭或者重启机器，那么在这几天之后该文件就不应该再在内存里头了。这就是内核对 page cache 的管理策略：LRU（最近最少使用）。即把最近最少使用的 page cache 给回收为 free pages。
内核的页回收机制有两种：后台回收和直接回收。
后台回收是有一个内核线程 kswapd 来做的，当内存里 free 的 pages 低于一个水位（page_low）时，就会唤醒该内核线程，然后它从 LRU 链表里回收 page cache 到内存的 free_list 里头，它会一直回收直至 free 的 pages 达到另外一个水位 page_high. 如下图所示：
直接回收则是，在发生 page fault 时，没有足够可用的内存，于是线程就自己直接去回收内存，它一次性的会回收 32 个 pages。逻辑过程如下图所示
所以要避免做 direct reclaim。
memory zone
对于多核 NUMA 系统而言，内存是分节点的，不同的 CPU 对不同的内存节点的访问速度是不一样的，所以 CPU 会优先去访问靠近自己的内存节点（即速度相对快的内存区域）。
CPU 内部是依靠 MMU 来进行内存管理的，根据内存属性的不同，MMU 将一个内存节点内部又划分了不同的 zone。
对 64-bit 系统而言，一个内存节点包含三个 zone：Normal，DMA，DMA32.
对 32-bit 系统而言，一个内存节点则是包括 zone：Normal，Highmem，DMA。
Highmem 存在的目的是为了解决线性地址空间不够用的问题，在 64-bit 上由于有足够的线性地址空间所以就没了该 zone。不同 zone 存在的目的是基于数据的局部性原则，我们在写代码的时候也知道，把相关的数据给放在一起可以提高性能，memory zone 也是这个道理。于是 MMU 在分配内存时，也会尽量给同一个进程分配同一个 zone 的内存。凡事有利就有弊，这样有好处自然也可能会带来一些坏处。
为了避免 direct reclaim，我们得保证在进程申请内存时有足够可用的 free pages，从前面我们可以看出，提高 watermark low 可以尽早的唤醒 kswapd，然后 kswapd 来做 background reclaim。为此，内核专门提供了一个 sysctl 接口给用户来使用：vm.extra_free_kbytes。
# cat /etc/sysctl.conf | grep kbytes
vm.extra_free_kbytes = 4096000
vm.min_free_kbytes = 2097152
于是我们增大这个值（比如增大到 5G），确实也解决了问题。增大该值来提高 low 水位，这样在申请内存的时候，如果 free 的内存低于了该水位，就会唤醒 kswapd 去做页回收，同时又由于还有足够的 free 内存可用所以进程能够正常申请而不触发直接回收。
线程的回收跟 memory zone 相关。也就是说 normal zone 里面的 free pages 不够用了，于是触发了 direct reclaim。但是，假如此时 DMA zone 里还有足够的 free pages 呢？线程会不会从 DMA zone 里来申请内存呢？
free 的 pages 都在其它的 zone 里头，所以线程去回收自己 zone 的 page cache 而不去使用其它 zone 的 free pages。对于这个内核也提供了一个接口给用户使用：vm.zone_reclaim_mode. 这个值在该机器上本来是1（即宁肯回收自己 zone 的 page cache，也不去申请其它 zone 的 free pages）,我把它更改为0（即只要其它 zone 有 free pages 就去其它 zone 里申请）,就解决了该问题（一设置后系统就恢复了正常）
从这个问题也可以看出，Linux 内核提供了各种各样的机制，然后我们根据具体的使用场景来选择使用的策略。目的是为了在不影响稳定性的前提下，尽可能的提升系统性能。
Linux 机制的多种多样，也给上层的开发者带来了一些苦恼：由于对底层了解的不深入，就很难选择出一个很好的策略来使用这些内核机制。
然而对这些机制的使用，也不会有一个万能公式，还是要看具体的使用场景。由于搜索服务器存在很多批量文件操作，所以对 page cache 的使用很频繁，
所以我们才选择了尽早的能够触发 background reclaim 这个策略；而如果你的文件操作不频繁，显然就没有必要去尽早的唤醒后台回收线程。
另外一个，作为一个文件服务器，它对 page cache 的需求是很大的，越多的内存作为 page cache，系统的整体性能就会越好，所以我们就没有必要为了数据的局部性而预留 DMA 内存，
两相比较肯定是 page cache 对性能的提升大于数据的局部性对性能的提升；而如果你的文件操作不多的话，那还是打开 zone_reclaim 的。
# cat /etc/sysctl.conf | grep zone
vm.zone_reclaim_mode = 0
经过调整以上这几个参数后，再持续监控一段时间，问题得以解决。
在 redhat 官网和 cloudera 官网也搜到了相关的内容，附录下来，供参考。
在 redhat 的官网上，有对THP特性的细化说明：
https://access.redhat.com/site ... .html
在 cloudera 的 CDH4 部署说明中，也建议将系统的 THP 的 compaction 特性关闭：
http://www.cloudera.com/conten ... .html 收起阅读 »
well 发表于 : 2017-11-01 09:51
评论 (7)
社区日报 第87期 (2017-11-01)
1. Scroll API 详解（文章有点老）
http://t.cn/RlvDxqS
2. 你真的了解 ES 的分页么？
http://t.cn/Rlvzfni
3. 分页查询 From&Size VS scroll
http://t.cn/RGBeOOK
活动预告：Elastic 武汉交流会
https://elasticsearch.cn/article/344
编辑：江水
归档：https://elasticsearch.cn/article/347
订阅：https://tinyletter.com/elastic-daily
继续阅读 »
http://t.cn/RlvDxqS
2. 你真的了解 ES 的分页么？
http://t.cn/Rlvzfni
3. 分页查询 From&Size VS scroll
http://t.cn/RGBeOOK
活动预告：Elastic 武汉交流会
https://elasticsearch.cn/article/344
编辑：江水
归档：https://elasticsearch.cn/article/347
订阅：https://tinyletter.com/elastic-daily
1. Scroll API 详解（文章有点老）
http://t.cn/RlvDxqS
2. 你真的了解 ES 的分页么？
http://t.cn/Rlvzfni
3. 分页查询 From&Size VS scroll
http://t.cn/RGBeOOK
活动预告：Elastic 武汉交流会
https://elasticsearch.cn/article/344
编辑：江水
归档：https://elasticsearch.cn/article/347
订阅：https://tinyletter.com/elastic-daily 收起阅读 »
http://t.cn/RlvDxqS
2. 你真的了解 ES 的分页么？
http://t.cn/Rlvzfni
3. 分页查询 From&Size VS scroll
http://t.cn/RGBeOOK
活动预告：Elastic 武汉交流会
https://elasticsearch.cn/article/344
编辑：江水
归档：https://elasticsearch.cn/article/347
订阅：https://tinyletter.com/elastic-daily 收起阅读 »
社区日报 第86期 (2017-10-31)
1.logstash实战，深入分析思科Meraki日志消息。
http://t.cn/RWrfOI7
2.基于 Elasticsearch实现搜索建议的一些方法。
http://t.cn/RWrfudV
3.如何在windows上安装Logstash与Kibana。
http://t.cn/RWrfQij
活动预告：Elastic 武汉交流会
https://elasticsearch.cn/article/344
编辑：叮咚光军
归档：https://elasticsearch.cn/article/345
订阅：https://tinyletter.com/elastic-daily
继续阅读 »
http://t.cn/RWrfOI7
2.基于 Elasticsearch实现搜索建议的一些方法。
http://t.cn/RWrfudV
3.如何在windows上安装Logstash与Kibana。
http://t.cn/RWrfQij
活动预告：Elastic 武汉交流会
https://elasticsearch.cn/article/344
编辑：叮咚光军
归档：https://elasticsearch.cn/article/345
订阅：https://tinyletter.com/elastic-daily
1.logstash实战，深入分析思科Meraki日志消息。
http://t.cn/RWrfOI7
2.基于 Elasticsearch实现搜索建议的一些方法。
http://t.cn/RWrfudV
3.如何在windows上安装Logstash与Kibana。
http://t.cn/RWrfQij
活动预告：Elastic 武汉交流会
https://elasticsearch.cn/article/344
编辑：叮咚光军
归档：https://elasticsearch.cn/article/345
订阅：https://tinyletter.com/elastic-daily
收起阅读 »
http://t.cn/RWrfOI7
2.基于 Elasticsearch实现搜索建议的一些方法。
http://t.cn/RWrfudV
3.如何在windows上安装Logstash与Kibana。
http://t.cn/RWrfQij
活动预告：Elastic 武汉交流会
https://elasticsearch.cn/article/344
编辑：叮咚光军
归档：https://elasticsearch.cn/article/345
订阅：https://tinyletter.com/elastic-daily
收起阅读 »
Elastic Meetup 武汉交流会
Elastic Meetup 线下交流活动首次来到江城武汉，武汉是湖北省省会、中部六省唯一的副省级市和特大城市、中国中部地区的中心城市，全国重要的工业基地、科教基地和综合交通枢纽。
主办：
本次活动由 Elastic 与 猫友会 联合举办。
媒体：
本次活动由 IT大咖说 独家提供现场直播。
时间：
2017.11.4 下午2:00-5:00（1点半开始签到）
地点：
氪空间（武汉市武昌区湖北省科技创业大厦A栋3楼客空间）
主题：
Elastic - Medcl - Elastic Stack 6.0 新功能介绍
尚德机构 - 白凡 - 高吞吐状况下斗鱼搜索引擎优化之路
基于爬虫和 Elasticsearch 快速构建站内搜索引擎
闪电分享（5-10分钟，可现场报名）
参会报名：
http://elasticsearch.mikecrm.com/O6o0yq3
现场直播
现场交流微信群
（❗️⚠️请注意：限武汉本地同学，外地毋加，微信人数限制，仅供现场参会人员沟通使用，谢谢合作???）
广州、深圳也在筹备中：https://elasticsearch.cn/article/261
关于 Elastic Meetup
Elastic Meetup 由 Elastic 中文社区定期举办的线下交流活动，主要围绕 Elastic 的开源产品（Elasticsearch、Logstash、Kibana 和 Beats）及周边技术，探讨在搜索、数据实时分析、日志分析、安全等领域的实践与应用。
关于 Elastic
Elastic 通过构建软件，让用户能够实时地、大规模地将数据用于搜索、日志和分析场景。Elastic 创立于 2012 年，相继开发了开源的 Elastic Stack（Elasticsearch、Kibana、Beats 和 Logstash）、X-Pack（商业功能）和 Elastic Cloud（托管服务）。截至目前，累计下载量超过 1.5 亿。Benchmark Capital、Index Ventures 和 NEA 为 Elastic 提供了超过 1 亿美元资金作为支持，Elastic 共有 600 多名员工，分布在 30 个国家/地区。有关更多信息，请访问 http://elastic.co/cn 。
关于猫友会
猫友会介绍：猫友会通过“人才回流，知识回流，创业回流”，来改变武汉互联网的行业环境。目前是影响力最大的湖北籍互联网社群，聚集了世界各地的5000余名湖北籍的互联网工程师。猫友会社区http://bbs.maoyouhui.cc. 光谷猫友会公众号：mtydev。
关于IT大咖说
IT大咖说，IT垂直领域的大咖知识分享平台，践行“开源是一种态度”，通过线上线下开放模式分享行业TOP大咖干货，技术大会在线直播点播，在线活动直播平台。http://www.itdks.com 。
再次感谢猫友会和IT大咖说的大力支持!
Elastic Meetup 线下交流活动首次来到江城武汉，武汉是湖北省省会、中部六省唯一的副省级市和特大城市、中国中部地区的中心城市，全国重要的工业基地、科教基地和综合交通枢纽。
主办：
本次活动由 Elastic 与 猫友会 联合举办。
媒体：
本次活动由 IT大咖说 独家提供现场直播。
时间：
2017.11.4 下午2:00-5:00（1点半开始签到）
地点：
氪空间（武汉市武昌区湖北省科技创业大厦A栋3楼客空间）
主题：
Elastic - Medcl - Elastic Stack 6.0 新功能介绍
尚德机构 - 白凡 - 高吞吐状况下斗鱼搜索引擎优化之路
基于爬虫和 Elasticsearch 快速构建站内搜索引擎
闪电分享（5-10分钟，可现场报名）
参会报名：
http://elasticsearch.mikecrm.com/O6o0yq3
现场直播
现场交流微信群
（❗️⚠️请注意：限武汉本地同学，外地毋加，微信人数限制，仅供现场参会人员沟通使用，谢谢合作???）
广州、深圳也在筹备中：https://elasticsearch.cn/article/261
关于 Elastic Meetup
Elastic Meetup 由 Elastic 中文社区定期举办的线下交流活动，主要围绕 Elastic 的开源产品（Elasticsearch、Logstash、Kibana 和 Beats）及周边技术，探讨在搜索、数据实时分析、日志分析、安全等领域的实践与应用。
关于 Elastic
Elastic 通过构建软件，让用户能够实时地、大规模地将数据用于搜索、日志和分析场景。Elastic 创立于 2012 年，相继开发了开源的 Elastic Stack（Elasticsearch、Kibana、Beats 和 Logstash）、X-Pack（商业功能）和 Elastic Cloud（托管服务）。截至目前，累计下载量超过 1.5 亿。Benchmark Capital、Index Ventures 和 NEA 为 Elastic 提供了超过 1 亿美元资金作为支持，Elastic 共有 600 多名员工，分布在 30 个国家/地区。有关更多信息，请访问 http://elastic.co/cn 。
关于猫友会
猫友会介绍：猫友会通过“人才回流，知识回流，创业回流”，来改变武汉互联网的行业环境。目前是影响力最大的湖北籍互联网社群，聚集了世界各地的5000余名湖北籍的互联网工程师。猫友会社区http://bbs.maoyouhui.cc. 光谷猫友会公众号：mtydev。
关于IT大咖说
IT大咖说，IT垂直领域的大咖知识分享平台，践行“开源是一种态度”，通过线上线下开放模式分享行业TOP大咖干货，技术大会在线直播点播，在线活动直播平台。http://www.itdks.com 。
再次感谢猫友会和IT大咖说的大力支持! 收起阅读 »
社区日报 第85期 (2017-10-30)
1.kibana dashborad嵌入式时间选择器插件。
http://t.cn/RWmjISQ
2.玩儿透日志分析集群搭建，调优，管理。
http://t.cn/RWmYDJv
3.现在就可以预约十一月一号的elastic官方kibana可视化教程。
http://t.cn/RWmRcgA
编辑：cyberdak
归档：https://elasticsearch.cn/article/343
订阅：https://tinyletter.com/elastic-daily
继续阅读 »
http://t.cn/RWmjISQ
2.玩儿透日志分析集群搭建，调优，管理。
http://t.cn/RWmYDJv
3.现在就可以预约十一月一号的elastic官方kibana可视化教程。
http://t.cn/RWmRcgA
编辑：cyberdak
归档：https://elasticsearch.cn/article/343
订阅：https://tinyletter.com/elastic-daily
1.kibana dashborad嵌入式时间选择器插件。
http://t.cn/RWmjISQ
2.玩儿透日志分析集群搭建，调优，管理。
http://t.cn/RWmYDJv
3.现在就可以预约十一月一号的elastic官方kibana可视化教程。
http://t.cn/RWmRcgA
编辑：cyberdak
归档：https://elasticsearch.cn/article/343
订阅：https://tinyletter.com/elastic-daily
收起阅读 »
http://t.cn/RWmjISQ
2.玩儿透日志分析集群搭建，调优，管理。
http://t.cn/RWmYDJv
3.现在就可以预约十一月一号的elastic官方kibana可视化教程。
http://t.cn/RWmRcgA
编辑：cyberdak
归档：https://elasticsearch.cn/article/343
订阅：https://tinyletter.com/elastic-daily
收起阅读 »
社区日报 第84期 (2017-10-29)
1.使用机器学习任务监测异常并向可视化的时间序列添加注释。
http://t.cn/RWH0Oyg
2.父子关系在Elasticsearch中的性能考量。
http://t.cn/RWH0TH3
3.(自备梯子)5天在5家硅谷顶级公司面试，作者如何拿到5份offer。
http://t.cn/RWinyw9
编辑：至尊宝
归档：https://elasticsearch.cn/article/342
订阅：https://tinyletter.com/elastic-daily
继续阅读 »
http://t.cn/RWH0Oyg
2.父子关系在Elasticsearch中的性能考量。
http://t.cn/RWH0TH3
3.(自备梯子)5天在5家硅谷顶级公司面试，作者如何拿到5份offer。
http://t.cn/RWinyw9
编辑：至尊宝
归档：https://elasticsearch.cn/article/342
订阅：https://tinyletter.com/elastic-daily
1.使用机器学习任务监测异常并向可视化的时间序列添加注释。
http://t.cn/RWH0Oyg
2.父子关系在Elasticsearch中的性能考量。
http://t.cn/RWH0TH3
3.(自备梯子)5天在5家硅谷顶级公司面试，作者如何拿到5份offer。
http://t.cn/RWinyw9
编辑：至尊宝
归档：https://elasticsearch.cn/article/342
订阅：https://tinyletter.com/elastic-daily 收起阅读 »
http://t.cn/RWH0Oyg
2.父子关系在Elasticsearch中的性能考量。
http://t.cn/RWH0TH3
3.(自备梯子)5天在5家硅谷顶级公司面试，作者如何拿到5份offer。
http://t.cn/RWinyw9
编辑：至尊宝
归档：https://elasticsearch.cn/article/342
订阅：https://tinyletter.com/elastic-daily 收起阅读 »
社区日报 第83期 (2017-10-28)
1.ES选举-类Bully算法
http://t.cn/RWWD6LM
2.如何更优雅的定制开发elasicsearch插件
https://elasticsearch.cn/article/339
3.你应该了解的5个 Logstash Filter 插件
https://elasticsearch.cn/article/332
活动预告：Elastic 长沙交流会
https://elasticsearch.cn/article/320
感谢jiangtao，dongne的投稿。
编辑：金桥
归档：https://elasticsearch.cn/article/341
订阅：https://tinyletter.com/elastic-daily
继续阅读 »
http://t.cn/RWWD6LM
2.如何更优雅的定制开发elasicsearch插件
https://elasticsearch.cn/article/339
3.你应该了解的5个 Logstash Filter 插件
https://elasticsearch.cn/article/332
活动预告：Elastic 长沙交流会
https://elasticsearch.cn/article/320
感谢jiangtao，dongne的投稿。
编辑：金桥
归档：https://elasticsearch.cn/article/341
订阅：https://tinyletter.com/elastic-daily
1.ES选举-类Bully算法
http://t.cn/RWWD6LM
2.如何更优雅的定制开发elasicsearch插件
https://elasticsearch.cn/article/339
3.你应该了解的5个 Logstash Filter 插件
https://elasticsearch.cn/article/332
活动预告：Elastic 长沙交流会
https://elasticsearch.cn/article/320
感谢jiangtao，dongne的投稿。
编辑：金桥
归档：https://elasticsearch.cn/article/341
订阅：https://tinyletter.com/elastic-daily 收起阅读 »
http://t.cn/RWWD6LM
2.如何更优雅的定制开发elasicsearch插件
https://elasticsearch.cn/article/339
3.你应该了解的5个 Logstash Filter 插件
https://elasticsearch.cn/article/332
活动预告：Elastic 长沙交流会
https://elasticsearch.cn/article/320
感谢jiangtao，dongne的投稿。
编辑：金桥
归档：https://elasticsearch.cn/article/341
订阅：https://tinyletter.com/elastic-daily 收起阅读 »
社区日报 第82期 (2017-10-27)
1、基于HBase+ ElasticSearch的车联网的应用
http://t.cn/RWoD1x8
2、携程大数据实践：高并发应用架构及推荐系统案例
http://t.cn/RWoDFX8
3、Elasticsearch相关度计算原理
http://t.cn/RWK4SQN
4、搞清楚logstash、filebeat到底什么区别？
http://t.cn/RWKPDDj
编辑：laoyang360
归档：https://elasticsearch.cn/article/340
订阅：https://tinyletter.com/elastic-daily
继续阅读 »
http://t.cn/RWoD1x8
2、携程大数据实践：高并发应用架构及推荐系统案例
http://t.cn/RWoDFX8
3、Elasticsearch相关度计算原理
http://t.cn/RWK4SQN
4、搞清楚logstash、filebeat到底什么区别？
http://t.cn/RWKPDDj
编辑：laoyang360
归档：https://elasticsearch.cn/article/340
订阅：https://tinyletter.com/elastic-daily
1、基于HBase+ ElasticSearch的车联网的应用
http://t.cn/RWoD1x8
2、携程大数据实践：高并发应用架构及推荐系统案例
http://t.cn/RWoDFX8
3、Elasticsearch相关度计算原理
http://t.cn/RWK4SQN
4、搞清楚logstash、filebeat到底什么区别？
http://t.cn/RWKPDDj
编辑：laoyang360
归档：https://elasticsearch.cn/article/340
订阅：https://tinyletter.com/elastic-daily
收起阅读 »
http://t.cn/RWoD1x8
2、携程大数据实践：高并发应用架构及推荐系统案例
http://t.cn/RWoDFX8
3、Elasticsearch相关度计算原理
http://t.cn/RWK4SQN
4、搞清楚logstash、filebeat到底什么区别？
http://t.cn/RWKPDDj
编辑：laoyang360
归档：https://elasticsearch.cn/article/340
订阅：https://tinyletter.com/elastic-daily
收起阅读 »
如何更优雅的定制开发elasicsearch插件
一，何为优雅：
在此需要感谢@Medcl,开发了ik,mmseg等为elasticsearch的分词插件，使我们能够比较容易的上手并应用elasticsearch。
但是我们如果要对插件进行二次定制，或者重新开发一个插件呢。按照官网教程，每次都得打包、替换、重启，这是一个很不方便的过程，固然可以通过testCase来做debug，但是所见即所得的编码习惯，直接上手debug，才是最高效的方式。
介绍插件开发的博客何其多，个人私以为都没有get到G点，其实深入研究下elasticsearch源码，fix 这个问题并不难，下面希望通过这篇文章帮助到大家。
二，elasticsearch插件的加载机制
①：Node节点启动过程，Elasticsearch.java会调用Bootstrap.java中的init函数。
environment.pluginsFile(),classpathPlugins等参数。而pluginsFile()即是elasticsearch所指定的plugin目录，elasticsearch会扫描该路径下所有的插件，并加载进来。
没有任何地方注入修改该参数。elasticsearch不但会扫描插件所在路径中的插件，同样也会加载classpathPlugins中所指定的插件，只不过问题是elasticsearch没有给我们提供相应的参数！！！！
三，如何更优雅的开发开发插件
接上一段小节④，我们只要利用classpathPlugins该参数，就可以在elasticsearch源码环境中进行debug了！！！
我的实现思路如下，通过继承Node.java，并重写Node类的构造方法，然后在bootstrap中直接实例化该子类，便可以通过elasticsearch直接bug 插件源码了。
下面贴出我的实现代码，供大家参考：
四，部署插件相关的注意事项：
有关插件开发的详细配置，es插件的种类，在此不再赘述，具体可参考官方文档，更权威，更直接。
下面贴个图，本人在elasticsearch中同时整合了多个插件，以供学习研究时用，直接debug，个人感觉十分不错。
继续阅读 »
在此需要感谢@Medcl,开发了ik,mmseg等为elasticsearch的分词插件，使我们能够比较容易的上手并应用elasticsearch。
但是我们如果要对插件进行二次定制，或者重新开发一个插件呢。按照官网教程，每次都得打包、替换、重启，这是一个很不方便的过程，固然可以通过testCase来做debug，但是所见即所得的编码习惯，直接上手debug，才是最高效的方式。
介绍插件开发的博客何其多，个人私以为都没有get到G点，其实深入研究下elasticsearch源码，fix 这个问题并不难，下面希望通过这篇文章帮助到大家。
二，elasticsearch插件的加载机制
①：Node节点启动过程，Elasticsearch.java会调用Bootstrap.java中的init函数。
static void init(...) {
...
INSTANCE = new Bootstrap();
INSTANCE.setup(true, environment);
...
INSTANCE.start();
} private void setup(boolean addShutdownHook, Environment environment) throws BootstrapException {
node = new Node(environment) {
...
}environment.pluginsFile(),classpathPlugins等参数。而pluginsFile()即是elasticsearch所指定的plugin目录，elasticsearch会扫描该路径下所有的插件，并加载进来。
public Node(Environment environment) {
this(environment, Collections.emptyList());
}
protected Node(final Environment environment, Collection<Class<? extends Plugin>> classpathPlugins) {
...
this.pluginsService = new PluginsService(tmpSettings, environment.modulesFile(), environment.pluginsFile(), classpathPlugins);
...
}public Node(Environment environment) {
this(environment, Collections.emptyList());
}没有任何地方注入修改该参数。elasticsearch不但会扫描插件所在路径中的插件，同样也会加载classpathPlugins中所指定的插件，只不过问题是elasticsearch没有给我们提供相应的参数！！！！
三，如何更优雅的开发开发插件
接上一段小节④，我们只要利用classpathPlugins该参数，就可以在elasticsearch源码环境中进行debug了！！！
我的实现思路如下，通过继承Node.java，并重写Node类的构造方法，然后在bootstrap中直接实例化该子类，便可以通过elasticsearch直接bug 插件源码了。
下面贴出我的实现代码，供大家参考：
/**
* Created by jiangtao on 2017/07/30.
*/
import org.elasticsearch.Version;
import org.elasticsearch.env.Environment;
import org.elasticsearch.node.Node;
import org.elasticsearch.plugins.Plugin;
import java.util.Collection;
public class EmbeddedNode extends Node {
private Version version;
private Collection<Class<? extends Plugin>> plugins;
public EmbeddedNode(Environment environment, Version version, Collection<Class<? extends Plugin>> classpathPlugins) {
super(environment, classpathPlugins);
this.version = version;
this.plugins = classpathPlugins;
}
public Collection<Class<? extends Plugin>> getPlugins() {
return plugins;
}
public Version getVersion() {
return version;
}
} private void setup(boolean addShutdownHook, Environment environment) throws BootstrapException {
.....
//注释Node初始化源码
/* node = new Node(environment) {
@Override
protected void validateNodeBeforeAcceptingRequests(
final Settings settings,
final BoundTransportAddress boundTransportAddress, List<BootstrapCheck> checks) throws NodeValidationException {
BootstrapChecks.check(settings, boundTransportAddress, checks);
}
};*/
Collection plugins = new ArrayList<>();
Collections.addAll(plugins, AnalysisIkPlugin.class, HelloPlugin.class, AnalysisMMsegPlugin.class);//, ,AnalysisMMsegPlugin.class
node = new EmbeddedNode(environment, Version.CURRENT, plugins) {
@Override
protected void validateNodeBeforeAcceptingRequests(final Settings settings, final BoundTransportAddress boundTransportAddress, List<BootstrapCheck> checks) throws NodeValidationException {
BootstrapChecks.check(settings, boundTransportAddress, checks);
}
};
}四，部署插件相关的注意事项：
有关插件开发的详细配置，es插件的种类，在此不再赘述，具体可参考官方文档，更权威，更直接。
下面贴个图，本人在elasticsearch中同时整合了多个插件，以供学习研究时用，直接debug，个人感觉十分不错。
一，何为优雅：
在此需要感谢@Medcl,开发了ik,mmseg等为elasticsearch的分词插件，使我们能够比较容易的上手并应用elasticsearch。
但是我们如果要对插件进行二次定制，或者重新开发一个插件呢。按照官网教程，每次都得打包、替换、重启，这是一个很不方便的过程，固然可以通过testCase来做debug，但是所见即所得的编码习惯，直接上手debug，才是最高效的方式。
介绍插件开发的博客何其多，个人私以为都没有get到G点，其实深入研究下elasticsearch源码，fix 这个问题并不难，下面希望通过这篇文章帮助到大家。
二，elasticsearch插件的加载机制
①：Node节点启动过程，Elasticsearch.java会调用Bootstrap.java中的init函数。
environment.pluginsFile(),classpathPlugins等参数。而pluginsFile()即是elasticsearch所指定的plugin目录，elasticsearch会扫描该路径下所有的插件，并加载进来。
没有任何地方注入修改该参数。elasticsearch不但会扫描插件所在路径中的插件，同样也会加载classpathPlugins中所指定的插件，只不过问题是elasticsearch没有给我们提供相应的参数！！！！
三，如何更优雅的开发开发插件
接上一段小节④，我们只要利用classpathPlugins该参数，就可以在elasticsearch源码环境中进行debug了！！！
我的实现思路如下，通过继承Node.java，并重写Node类的构造方法，然后在bootstrap中直接实例化该子类，便可以通过elasticsearch直接bug 插件源码了。
下面贴出我的实现代码，供大家参考：
四，部署插件相关的注意事项：
有关插件开发的详细配置，es插件的种类，在此不再赘述，具体可参考官方文档，更权威，更直接。
下面贴个图，本人在elasticsearch中同时整合了多个插件，以供学习研究时用，直接debug，个人感觉十分不错。
收起阅读 »
在此需要感谢@Medcl,开发了ik,mmseg等为elasticsearch的分词插件，使我们能够比较容易的上手并应用elasticsearch。
但是我们如果要对插件进行二次定制，或者重新开发一个插件呢。按照官网教程，每次都得打包、替换、重启，这是一个很不方便的过程，固然可以通过testCase来做debug，但是所见即所得的编码习惯，直接上手debug，才是最高效的方式。
介绍插件开发的博客何其多，个人私以为都没有get到G点，其实深入研究下elasticsearch源码，fix 这个问题并不难，下面希望通过这篇文章帮助到大家。
二，elasticsearch插件的加载机制
①：Node节点启动过程，Elasticsearch.java会调用Bootstrap.java中的init函数。
static void init(...) {
...
INSTANCE = new Bootstrap();
INSTANCE.setup(true, environment);
...
INSTANCE.start();
} private void setup(boolean addShutdownHook, Environment environment) throws BootstrapException {
node = new Node(environment) {
...
}environment.pluginsFile(),classpathPlugins等参数。而pluginsFile()即是elasticsearch所指定的plugin目录，elasticsearch会扫描该路径下所有的插件，并加载进来。
public Node(Environment environment) {
this(environment, Collections.emptyList());
}
protected Node(final Environment environment, Collection<Class<? extends Plugin>> classpathPlugins) {
...
this.pluginsService = new PluginsService(tmpSettings, environment.modulesFile(), environment.pluginsFile(), classpathPlugins);
...
}public Node(Environment environment) {
this(environment, Collections.emptyList());
}没有任何地方注入修改该参数。elasticsearch不但会扫描插件所在路径中的插件，同样也会加载classpathPlugins中所指定的插件，只不过问题是elasticsearch没有给我们提供相应的参数！！！！
三，如何更优雅的开发开发插件
接上一段小节④，我们只要利用classpathPlugins该参数，就可以在elasticsearch源码环境中进行debug了！！！
我的实现思路如下，通过继承Node.java，并重写Node类的构造方法，然后在bootstrap中直接实例化该子类，便可以通过elasticsearch直接bug 插件源码了。
下面贴出我的实现代码，供大家参考：
/**
* Created by jiangtao on 2017/07/30.
*/
import org.elasticsearch.Version;
import org.elasticsearch.env.Environment;
import org.elasticsearch.node.Node;
import org.elasticsearch.plugins.Plugin;
import java.util.Collection;
public class EmbeddedNode extends Node {
private Version version;
private Collection<Class<? extends Plugin>> plugins;
public EmbeddedNode(Environment environment, Version version, Collection<Class<? extends Plugin>> classpathPlugins) {
super(environment, classpathPlugins);
this.version = version;
this.plugins = classpathPlugins;
}
public Collection<Class<? extends Plugin>> getPlugins() {
return plugins;
}
public Version getVersion() {
return version;
}
} private void setup(boolean addShutdownHook, Environment environment) throws BootstrapException {
.....
//注释Node初始化源码
/* node = new Node(environment) {
@Override
protected void validateNodeBeforeAcceptingRequests(
final Settings settings,
final BoundTransportAddress boundTransportAddress, List<BootstrapCheck> checks) throws NodeValidationException {
BootstrapChecks.check(settings, boundTransportAddress, checks);
}
};*/
Collection plugins = new ArrayList<>();
Collections.addAll(plugins, AnalysisIkPlugin.class, HelloPlugin.class, AnalysisMMsegPlugin.class);//, ,AnalysisMMsegPlugin.class
node = new EmbeddedNode(environment, Version.CURRENT, plugins) {
@Override
protected void validateNodeBeforeAcceptingRequests(final Settings settings, final BoundTransportAddress boundTransportAddress, List<BootstrapCheck> checks) throws NodeValidationException {
BootstrapChecks.check(settings, boundTransportAddress, checks);
}
};
}四，部署插件相关的注意事项：
有关插件开发的详细配置，es插件的种类，在此不再赘述，具体可参考官方文档，更权威，更直接。
下面贴个图，本人在elasticsearch中同时整合了多个插件，以供学习研究时用，直接debug，个人感觉十分不错。
收起阅读 »
jiangtao 发表于 : 2017-10-26 21:06
评论 (2)
【环境篇】Intellij Idea编译Elasticsearch源码
一、软件环境
Intellij Idea:2017.1版本
Elasticsearch源码版本:5.3.1
JDK:1.8.0_111
Gradle :建议3.3及以上版本。官网：https://gradle.org/
二、下载Elasticsearch源码
到github clone源码，https://github.com/elastic/elasticsearch.git，建议选择稳定版本分支。
三、导入idea
1，编译执行gradle build.gradle，报错：
you must run gradle idea from the root of elasticsearch before importing into intellij
解决办法：运行命令：gradle idea。同理如使用eclipse编译器，运行gradle eclipse。该过程会向mvn仓库下载响应的jar包，视网络情况，大概会持续20分钟。
2，运行org.elasticsearch.bootstrap.Elasticsearch 方法，报错：
"path.home is not configured" when starting ES in transport and client mode“，
解决办法：在VM options中加入配置：-Des.path.home=/home/jiangtao/code/elasticsearch/core，即指向相应的core模块的路径。
3，报错：org.elasticsearch.bootstrap.BootstrapException: java.nio.file.NoSuchFileException
解决办法：将distribution模块src路径下的config整个文件copy到core模块中
4，报错： ERROR Could not register mbeans java.security.AccessControlException
解决办法：禁用jmx,在VM options中继续添加配置： -Dlog4j2.disable.jmx=true。注意：在VM options中多个配置中间用空格分隔。
5，报错： java.lang.IllegalStateException: Unsupported transport.type
错误栈如下：
这个是由于依赖的transport等jar并没有找到，可以在项目根目录找到models模块，然后将下面目录打包，然后copy到distribution/src/main/models目录下，
也可以直接去官网（https://www.elastic.co/downloads/elasticsearch）下载zip包，解压后直接copy。
我直接去官网下载的zip包：从官网下载完毕zip包后，具体解决办法请看：错误 6。
6，copy module版本冲突
错误栈如下：
解决办法：修改es当前版本
将core模块中的Version.java类由
public static final Version CURRENT = V_5_3_4_UNRELEASED;
修改为：
public static final Version CURRENT = V_5_3_1;
继续阅读 »
Intellij Idea:2017.1版本
Elasticsearch源码版本:5.3.1
JDK:1.8.0_111
Gradle :建议3.3及以上版本。官网：https://gradle.org/
二、下载Elasticsearch源码
到github clone源码，https://github.com/elastic/elasticsearch.git，建议选择稳定版本分支。
三、导入idea
1，编译执行gradle build.gradle，报错：
you must run gradle idea from the root of elasticsearch before importing into intellij
解决办法：运行命令：gradle idea。同理如使用eclipse编译器，运行gradle eclipse。该过程会向mvn仓库下载响应的jar包，视网络情况，大概会持续20分钟。
2，运行org.elasticsearch.bootstrap.Elasticsearch 方法，报错：
"path.home is not configured" when starting ES in transport and client mode“，
解决办法：在VM options中加入配置：-Des.path.home=/home/jiangtao/code/elasticsearch/core，即指向相应的core模块的路径。
3，报错：org.elasticsearch.bootstrap.BootstrapException: java.nio.file.NoSuchFileException
Exception in thread "main" org.elasticsearch.bootstrap.BootstrapException: java.nio.file.NoSuchFileException: /home/jiangtao/code/elasticsearch/core/config Likely root cause: java.nio.file.NoSuchFileException: /home/jiangtao/code/elasticsearch/core/config
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
at sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
at sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
at java.nio.file.Files.readAttributes(Files.java:1737)
at java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:225)
at java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:276)
at java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:322)
at java.nio.file.Files.walkFileTree(Files.java:2662)解决办法：将distribution模块src路径下的config整个文件copy到core模块中
4，报错： ERROR Could not register mbeans java.security.AccessControlException
2017-06-06 09:52:08,007 main ERROR Could not register mbeans java.security.AccessControlException: access denied ("javax.management.MBeanTrustPermission" "register")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:585)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission(DefaultMBeanServerInterceptor.java:1848)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:322)
at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
........
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:91)
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:84)解决办法：禁用jmx,在VM options中继续添加配置： -Dlog4j2.disable.jmx=true。注意：在VM options中多个配置中间用空格分隔。
5，报错： java.lang.IllegalStateException: Unsupported transport.type
错误栈如下：
[2017-06-06T10:04:21,327][WARN ][o.e.b.ElasticsearchUncaughtExceptionHandler] uncaught exception in thread [main]
org.elasticsearch.bootstrap.StartupException: java.lang.IllegalStateException: Unsupported transport.type
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:127) ~[main/:?]
at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:114) ~[main/:?]
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:58) ~[main/:?]
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:122) ~[main/:?]
at org.elasticsearch.cli.Command.main(Command.java:88) ~[main/:?]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:91) ~[main/:?]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:84) ~[main/:?]
Caused by: java.lang.IllegalStateException: Unsupported transport.type
at org.elasticsearch.common.network.NetworkModule.getTransportSupplier(NetworkModule.java:213) ~[main/:?]
at org.elasticsearch.node.Node.<init>(Node.java:421) ~[main/:?]
at org.elasticsearch.node.Node.<init>(Node.java:242) ~[main/:?]
at org.elasticsearch.bootstrap.Bootstrap$6.<init>(Bootstrap.java:242) ~[main/:?]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:242) ~[main/:?]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:360) ~[main/:?]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:123) ~[main/:?]
... 6 more这个是由于依赖的transport等jar并没有找到，可以在项目根目录找到models模块，然后将下面目录打包，然后copy到distribution/src/main/models目录下，
也可以直接去官网（https://www.elastic.co/downloads/elasticsearch）下载zip包，解压后直接copy。
我直接去官网下载的zip包：从官网下载完毕zip包后，具体解决办法请看：错误 6。
6，copy module版本冲突
错误栈如下：
org.elasticsearch.bootstrap.StartupException: java.lang.IllegalArgumentException: Plugin [lang-expression] is incompatible with Elasticsearch [5.3.4]. Was designed for version [5.3.1]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:127) ~[main/:?]
at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:114) ~[main/:?]
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:58) ~[main/:?]
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:122) ~[main/:?]
at org.elasticsearch.cli.Command.main(Command.java:88) ~[main/:?]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:91) ~[main/:?]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:84) ~[main/:?]
Caused by: java.lang.IllegalArgumentException: Plugin [lang-expression] is incompatible with Elasticsearch [5.3.4]. Was designed for version [5.3.1]解决办法：修改es当前版本
将core模块中的Version.java类由
public static final Version CURRENT = V_5_3_4_UNRELEASED;
修改为：
public static final Version CURRENT = V_5_3_1;
一、软件环境
Intellij Idea:2017.1版本
Elasticsearch源码版本:5.3.1
JDK:1.8.0_111
Gradle :建议3.3及以上版本。官网：https://gradle.org/
二、下载Elasticsearch源码
到github clone源码，https://github.com/elastic/elasticsearch.git，建议选择稳定版本分支。
三、导入idea
1，编译执行gradle build.gradle，报错：
you must run gradle idea from the root of elasticsearch before importing into intellij
解决办法：运行命令：gradle idea。同理如使用eclipse编译器，运行gradle eclipse。该过程会向mvn仓库下载响应的jar包，视网络情况，大概会持续20分钟。
2，运行org.elasticsearch.bootstrap.Elasticsearch 方法，报错：
"path.home is not configured" when starting ES in transport and client mode“，
解决办法：在VM options中加入配置：-Des.path.home=/home/jiangtao/code/elasticsearch/core，即指向相应的core模块的路径。
3，报错：org.elasticsearch.bootstrap.BootstrapException: java.nio.file.NoSuchFileException
解决办法：将distribution模块src路径下的config整个文件copy到core模块中
4，报错： ERROR Could not register mbeans java.security.AccessControlException
解决办法：禁用jmx,在VM options中继续添加配置： -Dlog4j2.disable.jmx=true。注意：在VM options中多个配置中间用空格分隔。
5，报错： java.lang.IllegalStateException: Unsupported transport.type
错误栈如下：
这个是由于依赖的transport等jar并没有找到，可以在项目根目录找到models模块，然后将下面目录打包，然后copy到distribution/src/main/models目录下，
也可以直接去官网（https://www.elastic.co/downloads/elasticsearch）下载zip包，解压后直接copy。
我直接去官网下载的zip包：从官网下载完毕zip包后，具体解决办法请看：错误 6。
6，copy module版本冲突
错误栈如下：
解决办法：修改es当前版本
将core模块中的Version.java类由
public static final Version CURRENT = V_5_3_4_UNRELEASED;
修改为：
public static final Version CURRENT = V_5_3_1; 收起阅读 »
Intellij Idea:2017.1版本
Elasticsearch源码版本:5.3.1
JDK:1.8.0_111
Gradle :建议3.3及以上版本。官网：https://gradle.org/
二、下载Elasticsearch源码
到github clone源码，https://github.com/elastic/elasticsearch.git，建议选择稳定版本分支。
三、导入idea
1，编译执行gradle build.gradle，报错：
you must run gradle idea from the root of elasticsearch before importing into intellij
解决办法：运行命令：gradle idea。同理如使用eclipse编译器，运行gradle eclipse。该过程会向mvn仓库下载响应的jar包，视网络情况，大概会持续20分钟。
2，运行org.elasticsearch.bootstrap.Elasticsearch 方法，报错：
"path.home is not configured" when starting ES in transport and client mode“，
解决办法：在VM options中加入配置：-Des.path.home=/home/jiangtao/code/elasticsearch/core，即指向相应的core模块的路径。
3，报错：org.elasticsearch.bootstrap.BootstrapException: java.nio.file.NoSuchFileException
Exception in thread "main" org.elasticsearch.bootstrap.BootstrapException: java.nio.file.NoSuchFileException: /home/jiangtao/code/elasticsearch/core/config Likely root cause: java.nio.file.NoSuchFileException: /home/jiangtao/code/elasticsearch/core/config
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
at sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
at sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
at java.nio.file.Files.readAttributes(Files.java:1737)
at java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:225)
at java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:276)
at java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:322)
at java.nio.file.Files.walkFileTree(Files.java:2662)解决办法：将distribution模块src路径下的config整个文件copy到core模块中
4，报错： ERROR Could not register mbeans java.security.AccessControlException
2017-06-06 09:52:08,007 main ERROR Could not register mbeans java.security.AccessControlException: access denied ("javax.management.MBeanTrustPermission" "register")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:585)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission(DefaultMBeanServerInterceptor.java:1848)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:322)
at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
........
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:91)
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:84)解决办法：禁用jmx,在VM options中继续添加配置： -Dlog4j2.disable.jmx=true。注意：在VM options中多个配置中间用空格分隔。
5，报错： java.lang.IllegalStateException: Unsupported transport.type
错误栈如下：
[2017-06-06T10:04:21,327][WARN ][o.e.b.ElasticsearchUncaughtExceptionHandler] uncaught exception in thread [main]
org.elasticsearch.bootstrap.StartupException: java.lang.IllegalStateException: Unsupported transport.type
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:127) ~[main/:?]
at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:114) ~[main/:?]
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:58) ~[main/:?]
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:122) ~[main/:?]
at org.elasticsearch.cli.Command.main(Command.java:88) ~[main/:?]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:91) ~[main/:?]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:84) ~[main/:?]
Caused by: java.lang.IllegalStateException: Unsupported transport.type
at org.elasticsearch.common.network.NetworkModule.getTransportSupplier(NetworkModule.java:213) ~[main/:?]
at org.elasticsearch.node.Node.<init>(Node.java:421) ~[main/:?]
at org.elasticsearch.node.Node.<init>(Node.java:242) ~[main/:?]
at org.elasticsearch.bootstrap.Bootstrap$6.<init>(Bootstrap.java:242) ~[main/:?]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:242) ~[main/:?]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:360) ~[main/:?]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:123) ~[main/:?]
... 6 more这个是由于依赖的transport等jar并没有找到，可以在项目根目录找到models模块，然后将下面目录打包，然后copy到distribution/src/main/models目录下，
也可以直接去官网（https://www.elastic.co/downloads/elasticsearch）下载zip包，解压后直接copy。
我直接去官网下载的zip包：从官网下载完毕zip包后，具体解决办法请看：错误 6。
6，copy module版本冲突
错误栈如下：
org.elasticsearch.bootstrap.StartupException: java.lang.IllegalArgumentException: Plugin [lang-expression] is incompatible with Elasticsearch [5.3.4]. Was designed for version [5.3.1]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:127) ~[main/:?]
at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:114) ~[main/:?]
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:58) ~[main/:?]
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:122) ~[main/:?]
at org.elasticsearch.cli.Command.main(Command.java:88) ~[main/:?]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:91) ~[main/:?]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:84) ~[main/:?]
Caused by: java.lang.IllegalArgumentException: Plugin [lang-expression] is incompatible with Elasticsearch [5.3.4]. Was designed for version [5.3.1]解决办法：修改es当前版本
将core模块中的Version.java类由
public static final Version CURRENT = V_5_3_4_UNRELEASED;
修改为：
public static final Version CURRENT = V_5_3_1; 收起阅读 »
jiangtao 发表于 : 2017-10-26 19:58
评论 (0)
【拓展篇】Elasticsearch 6.0 一个索引只允许有一个type
一，单index,单type
未来发布的elasticsearch 6.0.0版本为保持兼容，仍然会支持单index，多type结构，但是作者已不推荐这么设置。在elasticsearch 7.0.0版本必须使用单index,单type，多type结构则会完全移除。
针对这一问题，elasticsearch 作者的讨论：
https://github.com/elastic/ela ... 24317
https://www.elastic.co/guide/e ... .html
二，单index，多type结构弊端
人们经常会谈到index类似传统sql数据库的“database”,而type类似于"table"。现在想想，这是一个非常糟糕的比喻，而这个比喻会造成很多错误的假设。
在传统的sql数据库中，各个"table"之间是互相独立的，在一个表中的列都与另一个表相同名称的列无关。
①，而在我们elasticsearch中同一 Index 下，同名 Field 类型必须相同，即使不同的 Type；
②， 同一 Index 下，TypeA 的 Field 会占用 TypeB 的资源（互相消耗资源），会形成一种稀疏存储的情况。尤其是 doc value ，为什么这么说呢？doc value为了性能考虑会保留一部分的磁盘空间，这意味着 TypeB 可能不需要这个字段的 doc_value 而 TypeA 需要，那么 TypeB 就被白白占用了一部分没有半点用处的资源；
③，Score 评分机制是 index-wide 的，不同的type之间评分也会造成干扰。
④，索引元数据本身是放在主节点中维护的，CP 设计。意味着涉及到大量字段变更及元数据变更的操作，都会导致该 Index 被堵塞或假死。我们应该对这样的 Index 做隔离，避免影响到其他 Index 正常的增删改查。甚至当涉及到字段变更十分频繁且无法预定义 schema 的场景时，是否要使用 ES 都应该慎思熟虑了！
三，doc value 扩展介绍
参见官方文档docvalues
先看倒排索引组织结构大致如下：
如果我要查询包含 brown 的文档有哪些？这个就是全文检索了，也相当好办，先从词典里遍历到 brown 这个单词，然后根据倒排索引查得 Doc_1 和 Doc_2 包含这个单词。
如果我要查 Doc_1 和 Doc_2 包含的单词分别有什么？这个用倒排索引的话开销会非常大，至少是要将整张表关于 Doc_1 和 Doc_2 的列数据遍历一遍才行。这时候我们将数据换一种组织形式，将会起到非常好的效果。
Doc_1 和 Doc_2 存了什么单词，一目了然。我们把这种数据的组织方式叫做doc_value。
倒排索引的特点很明显，就是为了全文检索而生的，但是对于一些聚合查询（排序、求平均值等等）的场景来说，显然不适用。那么这样一来我们为了应对一些聚合场景就需要结构化数据来应付，这里说的结构化数据就是『列存储』，也就是上面说的doc_value。
doc_value在 ES 中有几个应用场景：
对某个字段排序；
某个字段聚合查询（ max/min/count ）；
部分过滤器 （ 地理位置过滤器 ）；
某个字段的脚本执行。等等。
doc_value是顺序存储到磁盘的，因此访问是很快的。当我们所处理的集合小于所给的 JVM 堆内存，那么整个数据集合是会被加载到内存里的；如果数据集合大于所给的堆内存，那么就会分页加载到内存之中，而不会报出『OutOfMemory Error』。
值得一提的是，doc_value的字段使用极其频繁，因此在5.x 版本后强化成为两个字段，分别是 text 和 keyword。
text：string 类型，支持倒排索引，不支持 doc_value；
keyword：string 类型，不支持倒排索引，支持doc_value。
四：参考
①：ElasticSearch 内部机制浅析
继续阅读 »
未来发布的elasticsearch 6.0.0版本为保持兼容，仍然会支持单index，多type结构，但是作者已不推荐这么设置。在elasticsearch 7.0.0版本必须使用单index,单type，多type结构则会完全移除。
针对这一问题，elasticsearch 作者的讨论：
https://github.com/elastic/ela ... 24317
https://www.elastic.co/guide/e ... .html
二，单index，多type结构弊端
人们经常会谈到index类似传统sql数据库的“database”,而type类似于"table"。现在想想，这是一个非常糟糕的比喻，而这个比喻会造成很多错误的假设。
在传统的sql数据库中，各个"table"之间是互相独立的，在一个表中的列都与另一个表相同名称的列无关。
①，而在我们elasticsearch中同一 Index 下，同名 Field 类型必须相同，即使不同的 Type；
②， 同一 Index 下，TypeA 的 Field 会占用 TypeB 的资源（互相消耗资源），会形成一种稀疏存储的情况。尤其是 doc value ，为什么这么说呢？doc value为了性能考虑会保留一部分的磁盘空间，这意味着 TypeB 可能不需要这个字段的 doc_value 而 TypeA 需要，那么 TypeB 就被白白占用了一部分没有半点用处的资源；
③，Score 评分机制是 index-wide 的，不同的type之间评分也会造成干扰。
④，索引元数据本身是放在主节点中维护的，CP 设计。意味着涉及到大量字段变更及元数据变更的操作，都会导致该 Index 被堵塞或假死。我们应该对这样的 Index 做隔离，避免影响到其他 Index 正常的增删改查。甚至当涉及到字段变更十分频繁且无法预定义 schema 的场景时，是否要使用 ES 都应该慎思熟虑了！
三，doc value 扩展介绍
参见官方文档docvalues
先看倒排索引组织结构大致如下：
如果我要查询包含 brown 的文档有哪些？这个就是全文检索了，也相当好办，先从词典里遍历到 brown 这个单词，然后根据倒排索引查得 Doc_1 和 Doc_2 包含这个单词。
如果我要查 Doc_1 和 Doc_2 包含的单词分别有什么？这个用倒排索引的话开销会非常大，至少是要将整张表关于 Doc_1 和 Doc_2 的列数据遍历一遍才行。这时候我们将数据换一种组织形式，将会起到非常好的效果。
Doc_1 和 Doc_2 存了什么单词，一目了然。我们把这种数据的组织方式叫做doc_value。
倒排索引的特点很明显，就是为了全文检索而生的，但是对于一些聚合查询（排序、求平均值等等）的场景来说，显然不适用。那么这样一来我们为了应对一些聚合场景就需要结构化数据来应付，这里说的结构化数据就是『列存储』，也就是上面说的doc_value。
doc_value在 ES 中有几个应用场景：
对某个字段排序；
某个字段聚合查询（ max/min/count ）；
部分过滤器 （ 地理位置过滤器 ）；
某个字段的脚本执行。等等。
doc_value是顺序存储到磁盘的，因此访问是很快的。当我们所处理的集合小于所给的 JVM 堆内存，那么整个数据集合是会被加载到内存里的；如果数据集合大于所给的堆内存，那么就会分页加载到内存之中，而不会报出『OutOfMemory Error』。
值得一提的是，doc_value的字段使用极其频繁，因此在5.x 版本后强化成为两个字段，分别是 text 和 keyword。
text：string 类型，支持倒排索引，不支持 doc_value；
keyword：string 类型，不支持倒排索引，支持doc_value。
四：参考
①：ElasticSearch 内部机制浅析
一，单index,单type
未来发布的elasticsearch 6.0.0版本为保持兼容，仍然会支持单index，多type结构，但是作者已不推荐这么设置。在elasticsearch 7.0.0版本必须使用单index,单type，多type结构则会完全移除。
针对这一问题，elasticsearch 作者的讨论：
https://github.com/elastic/ela ... 24317
https://www.elastic.co/guide/e ... .html
二，单index，多type结构弊端
人们经常会谈到index类似传统sql数据库的“database”,而type类似于"table"。现在想想，这是一个非常糟糕的比喻，而这个比喻会造成很多错误的假设。
在传统的sql数据库中，各个"table"之间是互相独立的，在一个表中的列都与另一个表相同名称的列无关。
①，而在我们elasticsearch中同一 Index 下，同名 Field 类型必须相同，即使不同的 Type；
②， 同一 Index 下，TypeA 的 Field 会占用 TypeB 的资源（互相消耗资源），会形成一种稀疏存储的情况。尤其是 doc value ，为什么这么说呢？doc value为了性能考虑会保留一部分的磁盘空间，这意味着 TypeB 可能不需要这个字段的 doc_value 而 TypeA 需要，那么 TypeB 就被白白占用了一部分没有半点用处的资源；
③，Score 评分机制是 index-wide 的，不同的type之间评分也会造成干扰。
④，索引元数据本身是放在主节点中维护的，CP 设计。意味着涉及到大量字段变更及元数据变更的操作，都会导致该 Index 被堵塞或假死。我们应该对这样的 Index 做隔离，避免影响到其他 Index 正常的增删改查。甚至当涉及到字段变更十分频繁且无法预定义 schema 的场景时，是否要使用 ES 都应该慎思熟虑了！
三，doc value 扩展介绍
参见官方文档docvalues
先看倒排索引组织结构大致如下：
如果我要查询包含 brown 的文档有哪些？这个就是全文检索了，也相当好办，先从词典里遍历到 brown 这个单词，然后根据倒排索引查得 Doc_1 和 Doc_2 包含这个单词。
如果我要查 Doc_1 和 Doc_2 包含的单词分别有什么？这个用倒排索引的话开销会非常大，至少是要将整张表关于 Doc_1 和 Doc_2 的列数据遍历一遍才行。这时候我们将数据换一种组织形式，将会起到非常好的效果。
Doc_1 和 Doc_2 存了什么单词，一目了然。我们把这种数据的组织方式叫做doc_value。
倒排索引的特点很明显，就是为了全文检索而生的，但是对于一些聚合查询（排序、求平均值等等）的场景来说，显然不适用。那么这样一来我们为了应对一些聚合场景就需要结构化数据来应付，这里说的结构化数据就是『列存储』，也就是上面说的doc_value。
doc_value在 ES 中有几个应用场景：
对某个字段排序；
某个字段聚合查询（ max/min/count ）；
部分过滤器 （ 地理位置过滤器 ）；
某个字段的脚本执行。等等。
doc_value是顺序存储到磁盘的，因此访问是很快的。当我们所处理的集合小于所给的 JVM 堆内存，那么整个数据集合是会被加载到内存里的；如果数据集合大于所给的堆内存，那么就会分页加载到内存之中，而不会报出『OutOfMemory Error』。
值得一提的是，doc_value的字段使用极其频繁，因此在5.x 版本后强化成为两个字段，分别是 text 和 keyword。
text：string 类型，支持倒排索引，不支持 doc_value；
keyword：string 类型，不支持倒排索引，支持doc_value。
四：参考
①：ElasticSearch 内部机制浅析
收起阅读 »
未来发布的elasticsearch 6.0.0版本为保持兼容，仍然会支持单index，多type结构，但是作者已不推荐这么设置。在elasticsearch 7.0.0版本必须使用单index,单type，多type结构则会完全移除。
针对这一问题，elasticsearch 作者的讨论：
https://github.com/elastic/ela ... 24317
https://www.elastic.co/guide/e ... .html
二，单index，多type结构弊端
人们经常会谈到index类似传统sql数据库的“database”,而type类似于"table"。现在想想，这是一个非常糟糕的比喻，而这个比喻会造成很多错误的假设。
在传统的sql数据库中，各个"table"之间是互相独立的，在一个表中的列都与另一个表相同名称的列无关。
①，而在我们elasticsearch中同一 Index 下，同名 Field 类型必须相同，即使不同的 Type；
②， 同一 Index 下，TypeA 的 Field 会占用 TypeB 的资源（互相消耗资源），会形成一种稀疏存储的情况。尤其是 doc value ，为什么这么说呢？doc value为了性能考虑会保留一部分的磁盘空间，这意味着 TypeB 可能不需要这个字段的 doc_value 而 TypeA 需要，那么 TypeB 就被白白占用了一部分没有半点用处的资源；
③，Score 评分机制是 index-wide 的，不同的type之间评分也会造成干扰。
④，索引元数据本身是放在主节点中维护的，CP 设计。意味着涉及到大量字段变更及元数据变更的操作，都会导致该 Index 被堵塞或假死。我们应该对这样的 Index 做隔离，避免影响到其他 Index 正常的增删改查。甚至当涉及到字段变更十分频繁且无法预定义 schema 的场景时，是否要使用 ES 都应该慎思熟虑了！
三，doc value 扩展介绍
参见官方文档docvalues
先看倒排索引组织结构大致如下：
如果我要查询包含 brown 的文档有哪些？这个就是全文检索了，也相当好办，先从词典里遍历到 brown 这个单词，然后根据倒排索引查得 Doc_1 和 Doc_2 包含这个单词。
如果我要查 Doc_1 和 Doc_2 包含的单词分别有什么？这个用倒排索引的话开销会非常大，至少是要将整张表关于 Doc_1 和 Doc_2 的列数据遍历一遍才行。这时候我们将数据换一种组织形式，将会起到非常好的效果。
Doc_1 和 Doc_2 存了什么单词，一目了然。我们把这种数据的组织方式叫做doc_value。
倒排索引的特点很明显，就是为了全文检索而生的，但是对于一些聚合查询（排序、求平均值等等）的场景来说，显然不适用。那么这样一来我们为了应对一些聚合场景就需要结构化数据来应付，这里说的结构化数据就是『列存储』，也就是上面说的doc_value。
doc_value在 ES 中有几个应用场景：
对某个字段排序；
某个字段聚合查询（ max/min/count ）；
部分过滤器 （ 地理位置过滤器 ）；
某个字段的脚本执行。等等。
doc_value是顺序存储到磁盘的，因此访问是很快的。当我们所处理的集合小于所给的 JVM 堆内存，那么整个数据集合是会被加载到内存里的；如果数据集合大于所给的堆内存，那么就会分页加载到内存之中，而不会报出『OutOfMemory Error』。
值得一提的是，doc_value的字段使用极其频繁，因此在5.x 版本后强化成为两个字段，分别是 text 和 keyword。
text：string 类型，支持倒排索引，不支持 doc_value；
keyword：string 类型，不支持倒排索引，支持doc_value。
四：参考
①：ElasticSearch 内部机制浅析
收起阅读 »
jiangtao 发表于 : 2017-10-26 19:46
评论 (0)
【源码篇】elasticsearch 搜索模块之cross-cluster-search
一：cross-cluster-search简述：
cross cluster search（跨集群搜索）功能允许任何节点在多个集群之间充当federated client（联合客户端）。 与tribe node（部落节点）功能相比，进行cross cluster search（跨集群搜索）的节点将不会加入远程集群，而是以轻量的方式连接到远程集群，以便执行联合搜索请求。
cross cluster search（跨集群搜索）的工作原理是在集群状态中配置一个远程集群，并且仅连接到远程集群中有限数量的节点。 每个远程集群都由一个名称和一个seed nodes（种子节点）的列表引用。 这些seed nodes（种子节点）用于发现远程集群中有资格作为gateway nodes（网关节点）的节点。 集群中配置了远程集群的每个节点都连接到一个或多个gateway nodes（网关节点），并使用它们将搜索请求联合到远程集群。
注意
此功能处于测试阶段，可能会发生变化。设计和代码不如官方GA功能成熟。弹性将采取最大的努力来解决任何问题，但beta功能不受SLA官方GA功能的支持。
二：配置跨集群搜索：
远程集群可以通过cluster settings API（集群设置api）来全局性地指定（可以动态更新），或者在各个节点的elasticsearch.yml文件中单独设定
如果通过elasticsearch.yml配置远程集群，则只有具有该配置的节点才能连接到远程集群。 换句话说，联合搜索请求必须被专门发送到那些节点。 通过cluster settings API（集群设置api）设置的远程集群在集群中的每个节点上都可用。
注意
此功能已添加到Elasticsearch v5.3中，并且要求gateway eligible（具有网关资格）的节点在v5.3之后。
对于cross cluster search（跨集群搜索）节点的elasticsearch.yml配置文件只需要列出应连接到远程集群，例如：
cluster_one和cluster_two是表示与每个集群的连接的任意集群别名。 这些名称随后用于区分本地和远程索引。
使用cluster settings API（集群设置api）将远程集群添加到集群中的所有节点的示例如下：
通过将其种子设置为null，可以从群集设置中删除远程群集：:
cluster_one将从集群设置中删除，cluster_two保持不变。
使用跨集群搜索
要搜索远程群集cluster_one上的twitter索引，index（索引）名称必须带有以:字符分隔的群集别名的前缀：
与tribe（部落）功能相反，cross cluster search（跨群集搜索）还可以搜索具有相同名称的不同群集的索引：
搜索结果的消歧与在请求中消除索引歧义的方法相同。 即使索引名称相同，当结果合并时，这些索引将被视为不同的索引。 从远程索引检索的所有结果将以其远程集群名称作为前缀：
跨集群搜索配置
search.remote.connections_per_cluster
要连接到每个远程集群的节点数。 默认值为3。
search.remote.initial_connect_timeout
节点启动时与远程节点建立连接的等待时间。 默认是30秒。
search.remote.node.attr
过滤掉远程集群中有资格作为gateway node（网关节点）的节点的节点属性。 例如，节点可以具有节点属性node.attr.gateway：true，如果search.remote.node.attr设置为gateway，只有具有此属性的节点才能将连接到。
search.remote.connect
默认情况下，群集中的任何节点都可以充当 cross-cluster client（跨群集客户端）并连接到远程群集。 search.remote.connect设置可以设置为false（默认为true），以防止某些节点连接到远程群集。 Cross-cluster search（跨群集搜索）请求必须发送到允许充当跨群集客户端的节点。
三：官方文档
https://www.elastic.co/guide/e ... tings
继续阅读 »
cross cluster search（跨集群搜索）功能允许任何节点在多个集群之间充当federated client（联合客户端）。 与tribe node（部落节点）功能相比，进行cross cluster search（跨集群搜索）的节点将不会加入远程集群，而是以轻量的方式连接到远程集群，以便执行联合搜索请求。
cross cluster search（跨集群搜索）的工作原理是在集群状态中配置一个远程集群，并且仅连接到远程集群中有限数量的节点。 每个远程集群都由一个名称和一个seed nodes（种子节点）的列表引用。 这些seed nodes（种子节点）用于发现远程集群中有资格作为gateway nodes（网关节点）的节点。 集群中配置了远程集群的每个节点都连接到一个或多个gateway nodes（网关节点），并使用它们将搜索请求联合到远程集群。
注意
此功能处于测试阶段，可能会发生变化。设计和代码不如官方GA功能成熟。弹性将采取最大的努力来解决任何问题，但beta功能不受SLA官方GA功能的支持。
二：配置跨集群搜索：
远程集群可以通过cluster settings API（集群设置api）来全局性地指定（可以动态更新），或者在各个节点的elasticsearch.yml文件中单独设定
如果通过elasticsearch.yml配置远程集群，则只有具有该配置的节点才能连接到远程集群。 换句话说，联合搜索请求必须被专门发送到那些节点。 通过cluster settings API（集群设置api）设置的远程集群在集群中的每个节点上都可用。
注意
此功能已添加到Elasticsearch v5.3中，并且要求gateway eligible（具有网关资格）的节点在v5.3之后。
对于cross cluster search（跨集群搜索）节点的elasticsearch.yml配置文件只需要列出应连接到远程集群，例如：
search:
remote:
cluster_one:
seeds: 127.0.0.1:9300
cluster_two:
seeds: 127.0.0.1:9301cluster_one和cluster_two是表示与每个集群的连接的任意集群别名。 这些名称随后用于区分本地和远程索引。
使用cluster settings API（集群设置api）将远程集群添加到集群中的所有节点的示例如下：
PUT _cluster/settings
{
"persistent": {
"search": {
"remote": {
"cluster_one": {
"seeds": [
"127.0.0.1:9300"
]
},
"cluster_two": {
"seeds": [
"127.0.0.1:9301"
]
}
}
}
}
}通过将其种子设置为null，可以从群集设置中删除远程群集：:
PUT _cluster/settings
{
"persistent": {
"search": {
"remote": {
"cluster_one": {
"seeds": null
}
}
}
}
}cluster_one将从集群设置中删除，cluster_two保持不变。
使用跨集群搜索
要搜索远程群集cluster_one上的twitter索引，index（索引）名称必须带有以:字符分隔的群集别名的前缀：
POST /cluster_one:twitter/tweet/_search
{
"query": {
"match_all": {}
}
}与tribe（部落）功能相反，cross cluster search（跨群集搜索）还可以搜索具有相同名称的不同群集的索引：
POST /cluster_one:twitter,twitter/tweet/_search
{
"query": {
"match_all": {}
}
}搜索结果的消歧与在请求中消除索引歧义的方法相同。 即使索引名称相同，当结果合并时，这些索引将被视为不同的索引。 从远程索引检索的所有结果将以其远程集群名称作为前缀：
{
"took" : 89,
"timed_out" : false,
"_shards" : {
"total" : 10,
"successful" : 10,
"failed" : 0
},
"hits" : {
"total" : 2,
"max_score" : 1.0,
"hits" : [
{
"_index" : "cluster_one:twitter",
"_type" : "tweet",
"_id" : "1",
"_score" : 1.0,
"_source" : {
"user" : "kimchy",
"postDate" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
},
{
"_index" : "twitter",
"_type" : "tweet",
"_id" : "1",
"_score" : 1.0,
"_source" : {
"user" : "kimchy",
"postDate" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
}
]
}
}跨集群搜索配置
search.remote.connections_per_cluster
要连接到每个远程集群的节点数。 默认值为3。
search.remote.initial_connect_timeout
节点启动时与远程节点建立连接的等待时间。 默认是30秒。
search.remote.node.attr
过滤掉远程集群中有资格作为gateway node（网关节点）的节点的节点属性。 例如，节点可以具有节点属性node.attr.gateway：true，如果search.remote.node.attr设置为gateway，只有具有此属性的节点才能将连接到。
search.remote.connect
默认情况下，群集中的任何节点都可以充当 cross-cluster client（跨群集客户端）并连接到远程群集。 search.remote.connect设置可以设置为false（默认为true），以防止某些节点连接到远程群集。 Cross-cluster search（跨群集搜索）请求必须发送到允许充当跨群集客户端的节点。
三：官方文档
https://www.elastic.co/guide/e ... tings
一：cross-cluster-search简述：
cross cluster search（跨集群搜索）功能允许任何节点在多个集群之间充当federated client（联合客户端）。 与tribe node（部落节点）功能相比，进行cross cluster search（跨集群搜索）的节点将不会加入远程集群，而是以轻量的方式连接到远程集群，以便执行联合搜索请求。
cross cluster search（跨集群搜索）的工作原理是在集群状态中配置一个远程集群，并且仅连接到远程集群中有限数量的节点。 每个远程集群都由一个名称和一个seed nodes（种子节点）的列表引用。 这些seed nodes（种子节点）用于发现远程集群中有资格作为gateway nodes（网关节点）的节点。 集群中配置了远程集群的每个节点都连接到一个或多个gateway nodes（网关节点），并使用它们将搜索请求联合到远程集群。
注意
此功能处于测试阶段，可能会发生变化。设计和代码不如官方GA功能成熟。弹性将采取最大的努力来解决任何问题，但beta功能不受SLA官方GA功能的支持。
二：配置跨集群搜索：
远程集群可以通过cluster settings API（集群设置api）来全局性地指定（可以动态更新），或者在各个节点的elasticsearch.yml文件中单独设定
如果通过elasticsearch.yml配置远程集群，则只有具有该配置的节点才能连接到远程集群。 换句话说，联合搜索请求必须被专门发送到那些节点。 通过cluster settings API（集群设置api）设置的远程集群在集群中的每个节点上都可用。
注意
此功能已添加到Elasticsearch v5.3中，并且要求gateway eligible（具有网关资格）的节点在v5.3之后。
对于cross cluster search（跨集群搜索）节点的elasticsearch.yml配置文件只需要列出应连接到远程集群，例如：
cluster_one和cluster_two是表示与每个集群的连接的任意集群别名。 这些名称随后用于区分本地和远程索引。
使用cluster settings API（集群设置api）将远程集群添加到集群中的所有节点的示例如下：
通过将其种子设置为null，可以从群集设置中删除远程群集：:
cluster_one将从集群设置中删除，cluster_two保持不变。
使用跨集群搜索
要搜索远程群集cluster_one上的twitter索引，index（索引）名称必须带有以:字符分隔的群集别名的前缀：
与tribe（部落）功能相反，cross cluster search（跨群集搜索）还可以搜索具有相同名称的不同群集的索引：
搜索结果的消歧与在请求中消除索引歧义的方法相同。 即使索引名称相同，当结果合并时，这些索引将被视为不同的索引。 从远程索引检索的所有结果将以其远程集群名称作为前缀：
跨集群搜索配置
search.remote.connections_per_cluster
要连接到每个远程集群的节点数。 默认值为3。
search.remote.initial_connect_timeout
节点启动时与远程节点建立连接的等待时间。 默认是30秒。
search.remote.node.attr
过滤掉远程集群中有资格作为gateway node（网关节点）的节点的节点属性。 例如，节点可以具有节点属性node.attr.gateway：true，如果search.remote.node.attr设置为gateway，只有具有此属性的节点才能将连接到。
search.remote.connect
默认情况下，群集中的任何节点都可以充当 cross-cluster client（跨群集客户端）并连接到远程群集。 search.remote.connect设置可以设置为false（默认为true），以防止某些节点连接到远程群集。 Cross-cluster search（跨群集搜索）请求必须发送到允许充当跨群集客户端的节点。
三：官方文档
https://www.elastic.co/guide/e ... tings
收起阅读 »
cross cluster search（跨集群搜索）功能允许任何节点在多个集群之间充当federated client（联合客户端）。 与tribe node（部落节点）功能相比，进行cross cluster search（跨集群搜索）的节点将不会加入远程集群，而是以轻量的方式连接到远程集群，以便执行联合搜索请求。
cross cluster search（跨集群搜索）的工作原理是在集群状态中配置一个远程集群，并且仅连接到远程集群中有限数量的节点。 每个远程集群都由一个名称和一个seed nodes（种子节点）的列表引用。 这些seed nodes（种子节点）用于发现远程集群中有资格作为gateway nodes（网关节点）的节点。 集群中配置了远程集群的每个节点都连接到一个或多个gateway nodes（网关节点），并使用它们将搜索请求联合到远程集群。
注意
此功能处于测试阶段，可能会发生变化。设计和代码不如官方GA功能成熟。弹性将采取最大的努力来解决任何问题，但beta功能不受SLA官方GA功能的支持。
二：配置跨集群搜索：
远程集群可以通过cluster settings API（集群设置api）来全局性地指定（可以动态更新），或者在各个节点的elasticsearch.yml文件中单独设定
如果通过elasticsearch.yml配置远程集群，则只有具有该配置的节点才能连接到远程集群。 换句话说，联合搜索请求必须被专门发送到那些节点。 通过cluster settings API（集群设置api）设置的远程集群在集群中的每个节点上都可用。
注意
此功能已添加到Elasticsearch v5.3中，并且要求gateway eligible（具有网关资格）的节点在v5.3之后。
对于cross cluster search（跨集群搜索）节点的elasticsearch.yml配置文件只需要列出应连接到远程集群，例如：
search:
remote:
cluster_one:
seeds: 127.0.0.1:9300
cluster_two:
seeds: 127.0.0.1:9301cluster_one和cluster_two是表示与每个集群的连接的任意集群别名。 这些名称随后用于区分本地和远程索引。
使用cluster settings API（集群设置api）将远程集群添加到集群中的所有节点的示例如下：
PUT _cluster/settings
{
"persistent": {
"search": {
"remote": {
"cluster_one": {
"seeds": [
"127.0.0.1:9300"
]
},
"cluster_two": {
"seeds": [
"127.0.0.1:9301"
]
}
}
}
}
}通过将其种子设置为null，可以从群集设置中删除远程群集：:
PUT _cluster/settings
{
"persistent": {
"search": {
"remote": {
"cluster_one": {
"seeds": null
}
}
}
}
}cluster_one将从集群设置中删除，cluster_two保持不变。
使用跨集群搜索
要搜索远程群集cluster_one上的twitter索引，index（索引）名称必须带有以:字符分隔的群集别名的前缀：
POST /cluster_one:twitter/tweet/_search
{
"query": {
"match_all": {}
}
}与tribe（部落）功能相反，cross cluster search（跨群集搜索）还可以搜索具有相同名称的不同群集的索引：
POST /cluster_one:twitter,twitter/tweet/_search
{
"query": {
"match_all": {}
}
}搜索结果的消歧与在请求中消除索引歧义的方法相同。 即使索引名称相同，当结果合并时，这些索引将被视为不同的索引。 从远程索引检索的所有结果将以其远程集群名称作为前缀：
{
"took" : 89,
"timed_out" : false,
"_shards" : {
"total" : 10,
"successful" : 10,
"failed" : 0
},
"hits" : {
"total" : 2,
"max_score" : 1.0,
"hits" : [
{
"_index" : "cluster_one:twitter",
"_type" : "tweet",
"_id" : "1",
"_score" : 1.0,
"_source" : {
"user" : "kimchy",
"postDate" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
},
{
"_index" : "twitter",
"_type" : "tweet",
"_id" : "1",
"_score" : 1.0,
"_source" : {
"user" : "kimchy",
"postDate" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
}
]
}
}跨集群搜索配置
search.remote.connections_per_cluster
要连接到每个远程集群的节点数。 默认值为3。
search.remote.initial_connect_timeout
节点启动时与远程节点建立连接的等待时间。 默认是30秒。
search.remote.node.attr
过滤掉远程集群中有资格作为gateway node（网关节点）的节点的节点属性。 例如，节点可以具有节点属性node.attr.gateway：true，如果search.remote.node.attr设置为gateway，只有具有此属性的节点才能将连接到。
search.remote.connect
默认情况下，群集中的任何节点都可以充当 cross-cluster client（跨群集客户端）并连接到远程群集。 search.remote.connect设置可以设置为false（默认为true），以防止某些节点连接到远程群集。 Cross-cluster search（跨群集搜索）请求必须发送到允许充当跨群集客户端的节点。
三：官方文档
https://www.elastic.co/guide/e ... tings
收起阅读 »
jiangtao 发表于 : 2017-10-26 19:36
评论 (2)
