《Elastic Stack 实战手册》 介绍及下载
liuxg 发表了文章 • 1 个评论 • 3202 次浏览 • 2022-08-12 17:19
Elasticsearch 无疑是大数据搜索引擎中的王者，它以其开放及免费、易用、多语言接口、卓越性能及不断创新的优势，被许多 IT 企业所采用。当今的许多IT 企业很难绕过它。在中国，Elastic Stack 有一个很强大的生态圈。在本书的创作过程中，我非常高兴看到有数十位志愿者参与到本书的创作中。这本书集众技术大咖及专家们的无私奉献，是他们牺牲了自己宝贵的时间，利用业余时间共创完成，在一遍遍的修改中把内容做得更完善。在这里衷心感谢他们的无私付出和合作。
写书和做社区贡献，是需要情怀的。我一直坚信帮助别人，也会成就自己。分享自己的知识，也是一件很快乐的事，因为这样可以证明自己的人生价值。我有超过16 年的社区参与经历，也非常喜欢分享我学到的知识。从加入Elastic 公司以来，我在CSDN 上已经发表了将近660 篇关于Elastic Stack 方面的文章，涵盖了Elastic Stack 方方面面的知识。
作为本书主编，我投入了很多时间来策划、创作、校正及阅读这本书，尽力保证本书的完整性、正确性、一致性及每篇文章的独立性。尽管如此，里面可能有不尽之处，希望读者们海涵！这本书涵盖了Elastic Stack 的介绍、安装、实操、产品能力、方案及案例，特别适合初学者，
对有经验的开发者来说也是一本难得的参考书。在未来，希望有更多的开发者分享自己的知识，
让我们一起把Elastic 社区做得更好！
我强烈推荐想学 Elastic Stack 技术的开发者，下载这本书作为参考。下载连接为 Elastic Stack 实战手册-藏经阁-阿里云开发者社区 https://developer.aliyun.com/ebook/7687
https://elasticstack.blog.csdn ... 01982
极限网关初探（2）配置
xushuhui 发表了文章 • 0 个评论 • 1833 次浏览 • 2022-04-06 17:03
配置
上一篇我们先学习了极限网关的安装和启动，今天学习配置。
读写分离
现在我们遇到读写分离的需求，用网关该怎么做呢？
假设服务端现在从 http://127.0.0.1:8000 写入数据，从 http://127.0.0.1:9000 读取数据，怎么设计呢？
首先查看文档[配置文档](https://xn--d6q905cs0q16u.com/zh/docs/overview/)
我们在 gateway.yml 中定义两个 entry，分别绑定不同的端口，配置不同的 router
```yaml
entry:
- name: write_es
enabled: true
router: write_router
network:
binding: 0.0.0.0:8000 - name: read_es
enabled: true
router: read_router
network:
binding: 0.0.0.0:9000
router: - name: write_router
default_flow: default_flow
tracing_flow: logging - name: read_router
default_flow: default_flow
tracing_flow: logging
<br /> 为了演示效果，只配置一个 Elasticsearch<br />yaml
elasticsearch:
- name: dev
enabled: true
schema: http
hosts: - 192.168.3.188:9206
```
启动项目
我们从 http://127.0.0.1:8000 写入一条数据，再从 http://127.0.0.1:9000 读取该条数据
添加接口
返回字符串
我们想自定义添加一个接口，怎么在不写代码的情况下通过配置实现返回字符串
```yaml
flow:
- name: dev
- name: hello_flow
filter:
- echo:
message: "hello flow"
router:
- echo:
- name: read_router
default_flow: hello_flow
```
修改配置后启动
返回 json 数据
返回字符串不符合标准的 restful 接口规范，怎么返回给调用方标准 json 数据？
```yaml
filter: - set_response:
content_type: application/json
body: '{"message":"hello world"}'
```
修改配置后启动
修改路由
我们已经新加了接口，返回 json 数据，但是接口是直接定义在 http://127.0.0.1:9000 中，之前网关的接口就无法使用，所以我们需要单独为自定义的接口指定单独的路由
```yaml
router: - name: read_router
default_flow: default_flow
tracing_flow: logging
rules:
- method:
- GET
pattern: - "/hello"
flow: - hello_flow
```
default_flow: 默认的处理流，也就是业务处理的主流程，请求转发、过滤、缓存等操作都在这里面进行
tracing_flow：用于追踪请求状态的流，用于记录请求日志、统计等
如果我们有过开发经验，了解 MVC 模式，flow 就类似 MVC 中的 Controller，rules 中类似路由规则，当请求匹配到配置中的路由规则时，由配置的 flow 处理业务逻辑。
数据整体流向，从服务端发到网关，网关为每个 Elasticsearch 绑定不同的 IP 地址，每个 Elasticsearch 都有唯一一个 router 和它对应，根据请求的 method 和 path 匹配到 router 中的一个 flow，flow 中包含多个 filter 处理对数据进行流式处理。
如下图所示
流式处理是什么，假设水从一个管子里面流出来，管子旁边每一段依次站了几个人，第一个人往水里放点鱼，鱼和水到了第二个人，第二个人往水里放点草，鱼、水和草到了第三人等等，每个人对水做一定的操作，水经过这些操作后最后到达水池里。
我们可以把数据当成水，filter 是管子旁边的人，水池就是 Elasticsearch
总结
在学习了router/flow/filter后，我们已经对极限网关的配置有了初步的了解，后续开发的时候直接查阅文档。
- GET
- method:
极限网关初探（1） 安装启动
xushuhui 发表了文章 • 0 个评论 • 1835 次浏览 • 2022-04-06 16:54
产品介绍
极限网关（INFINI Gateway）是一个面向 Elasticsearch 的高性能应用网关。特性丰富，使用简单。
它和其他业务型网关最大的区别是业务网关把请求转发给各个底层微服务，而它把请求转发给 Elasticsearch，更多是类似 Mycat 的中间件的作用。
没有使用网关之前，服务端请求多个节点
使用网关后
下载地址
打开 [下载地址](http://release.infinilabs.com/gateway/stable/)，根据操作系统版本选择。
Windows 安装和启动
安装
下载 gateway-1.6.0_SNAPSHOT-597-windows-amd64.zip，解压如下。
gateway-windows-amd64.exe 是启动文件，gateway.yml 是默认配置文件。
启动失败
当 gateway.yml 的 elasticsearch 选项中的 hosts 不能正常响应请求的时候，启动界面如下。
为什么 elasticsearch 不能访问的时候，网关还要继续提供服务呢，为什么不像业务接口启动时在基础业务组件如 MySQL/Redis 不能正常响应就直接 panic？
一方面网关作为 elasticsearch 抵挡流量冲击的城墙，在 elasticsearch 不能提供服务的时候，对之前成功的请求缓存结果，继续提供有限度的服务，为 elasticsearch 修复后上线争取时间。
另一方面业务接口和基础组件是强耦合关系，没有基础组件就完全无法对外提供数据读写服务，而网关与 elasticsearch 是松耦合关系，网关在没有 elasticsearch 的情况下也能对外提供有限度的服务。
在 gateway.yml 的 elasticsearch 选项中的 hosts 改成能够正常响应的 elasticsearch 请求地址。启动成功
双击 gateway-windows-amd64.exe 文件，启动成功界面如下
访问
API 访问
由启动后终端显示可知，网关的 API 接口地址是 http://localhost:2900
sh<br /> [api.go:262] api listen at: <a href="http://0.0.0.0:2900" rel="nofollow" target="_blank">http://0.0.0.0:2900</a><br />
打开浏览器输入 http://localhost:2900，显示所有可以对外提供的 API 接口
我们选择其中一个，在浏览器中输入 http://localhost:2900/_framework/api/_version 从路由上看该接口是查询产品的版本信息，显示如下
gateway.yml 中可以看到有被注释掉的一段配置，看起来应该是配置 api 地址的地方。
```yamlapi:
enabled: true
network:
binding: 127.0.0.1:2900
<br /> 把注释去掉后尝试把端口改成 2901。<br />yaml
api:
enabled: true
network:
binding: 127.0.0.1:2901
```
改完后启动
打开浏览器先输入 http://localhost:2900，无法正常响应请求，再输入 http://localhost:2901，可以正常响应，界面和修改配置前访问 http://localhost:2900 的界面一样，说明 API 请求地址成功修改Elasticsearch 访问
启动日志中显示监听 8000 端口，猜测应该是 elasticsearch 请求地址，打开浏览器输入 http://127.0.0.1:8000/
sh<br /> entry [my_es_entry] listen at: <a href="http://0.0.0.0:8000" rel="nofollow" target="_blank">http://0.0.0.0:8000</a><br />
gateway.yml 中可以看到 my_es_entry 的 network 绑定 8000 端口，显而易见的这部分就是配置代理转发给 elasticsearch 的地址，所以安装后只需要把以前请求 elasticsearch 的地址修改为该地址。
```yaml
entry:
- name: my_es_entry
enabled: true
router: my_router
max_concurrency: 10000
network:
binding: 0.0.0.0:8000
```
总结
我们成功安装和启动极限网关，接下来我们学习怎么根据需求修改配置。
使用极限网关来处置 Elasticsearch 的 Apache Log4j 漏洞
medcl 发表了文章 • 2 个评论 • 5255 次浏览 • 2021-12-11 03:57
昨日爆出的 Log4j 安全漏洞，业界一片哗然，今天给大家介绍一下，如何使用极限网关来快速处置 Elasticsearch 的 Apache Log4j 漏洞。
【CVE 地址】
[https://github.com/advisories/GHSA-jfh8-c2jp-5v3q](https://github.com/advisories/GHSA-jfh8-c2jp-5v3q)
【漏洞描述】
Apache Log4j 是一款非常流行的开源的用于 Java 运行环境的日志记录工具包，大量的 Java 框架包括 Elasticsearch 的最新版本都使用了该组件，故影响范围非常之大。
近日, 随着 Apache Log4j 的远程代码执行最新漏洞细节被公开，攻击者可通过构造恶意请求利用该漏洞实现在目标服务器上执行任意代码。可导致服务器被黑客控制，从而进行页面篡改、数据窃取、挖矿、勒索等行为。建议使用该组件的用户第一时间启动应急响应进行修复。
简单总结一下就是，在使用 Log4j 打印输出的日志中，如果发现日志内容中包含关键词 ${，那么这个里面包含的内容会当做变量来进行替换和执行，导致攻击者可以通过恶意构造日志内容来让 Java 进程来执行任意命令，达到攻击的效果。
【漏洞等级】：非常紧急
此次漏洞是用于 Log4j2 提供的 lookup 功能造成的，该功能允许开发者通过一些协议去读取相应环境中的配置。但在实现的过程中，并未对输入进行严格的判断，从而造成漏洞的发生。
【影响范围】：Java 类产品：Apache Log4j 2.x < 2.15.0-rc2，Elasticsearch 当前所有版本。
【攻击检测】
可以通过检查日志中是否存在 jndi:ldap://、jndi:rmi 等字符来发现可能的攻击行为。
处理办法
最简单的办法是通过修改 config/jvm.options，新增以下参数，重启集群所有节点即可。
<br /> -Dlog4j2.formatMsgNoLookups=true<br />
不过，如果集群规模较大，数据较多，业务不能中断，不能通过修改 Elasticsearch 配置、或者替换 Log4j 的最新 jar 包来重启集群的情况，可以考虑使用极限网关来进行拦截或者参数替换甚至是直接阻断请求。
通过在网关层对发往 Elasticsearch 的请求统一进行参数检测，将包含的敏感关键词 ${ 进行替换或者直接拒绝，
可以防止带攻击的请求到达 Elasticsearch 服务端而被 Log4j 打印相关日志的时候执行恶意攻击命令，从而避免被攻击。
极限网关是透明代理，只需要在应用端，将以往配置指向 Elasticsearch 的地址替换为现在网关的地址即可，其他都不用动。
参考配置
下载最新的 1.5.0-SNAPSHOT 版本[http://release.elasticsearch.cn/gateway/snapshot/](http://release.elasticsearch.cn/gateway/snapshot/)
使用极限网关的 context_filter 过滤器，对请求上下文 _ctx.request.to_string 进行关键字检测，过滤掉恶意流量，从而阻断攻击。
新增一个配置文件 gateway.yml
```
path.data: data
path.logs: log
entry:
- name: es_entrypoint
enabled: true
router: default
max_concurrency: 20000
network:
binding: 0.0.0.0:8000
router: - name: default
default_flow: main_flow
flow: - name: main_flow
filter:
- context_filter:
context: _ctx.request.to_string
action: redirect_flow
status: 403
flow: log4j_matched_flow
must_not: # any match will be filtered
regex:
- \${.*?}
- "%24%7B.*?%7D" #urlencode
contain: - "jndi:"
- "jndi:ldap:"
- "jndi:rmi:"
- "jndi%3A" #urlencode
- "jndi%3Aldap%3A" #urlencode
- "jndi%3Armi%3A" #urlencode
- \${.*?}
- elasticsearch:
elasticsearch: es-server
- context_filter:
- name: log4j_matched_flow
filter:
- echo:
message: 'Apache Log4j 2, Boom!'
elasticsearch:
- echo:
- name: es-server
enabled: true
endpoints:
- http://localhost:9200
<br /> <br /> 启动网关：<br /> ````<br /> ➜ ./bin/gateway -config /tmp/gateway.yml<br /> ___ _ _____ __ __ __ _ <br /> / _ \ /_\ /__ \/__\/ / /\ \ \/_\ /\_/\<br /> / /_\///_\\ / /\/_\ \ \/ \/ //_\\\_ _/<br /> / /_\\/ _ \/ / //__ \ /\ / _ \/ \ <br /> \____/\_/ \_/\/ \__/ \/ \/\_/ \_/\_/ <br /> <br /> [GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway.<br /> [GATEWAY] 1.0.0_SNAPSHOT, 2021-12-10 23:55:34, 2212aff<br /> [12-11 01:55:49] [INF] [app.go:250] initializing gateway.<br /> [12-11 01:55:49] [INF] [instance.go:26] workspace: /Users/medcl/go/src/infini.sh/gateway/data/gateway/nodes/0<br /> [12-11 01:55:49] [INF] [api.go:261] api listen at: <a href="http://0.0.0.0:2900" rel="nofollow" target="_blank">http://0.0.0.0:2900</a><br /> [12-11 01:55:49] [INF] [reverseproxy.go:253] elasticsearch [es-server] hosts: [] => [localhost:9200]<br /> [12-11 01:55:49] [INF] [entry.go:296] entry [es_entrypoint] listen at: <a href="http://0.0.0.0:8000" rel="nofollow" target="_blank">http://0.0.0.0:8000</a><br /> [12-11 01:55:49] [INF] [module.go:116] all modules started<br /> [12-11 01:55:49] [INF] [app.go:357] gateway is running now.<br /> [12-11 01:55:49] [INF] [actions.go:236] elasticsearch [es-server] is available<br />
将要使用的测试命令${java:os}使用 urlencode 转码为%24%7Bjava%3Aos%7D，构造查询语句，分别测试。
不走网关：
<br /> ~% curl 'http://localhost:9200/index1/_search?q=%24%7Bjava%3Aos%7D' <br /> {"error":{"root_cause":[{"type":"index_not_found_exception","reason":"no such index","resource.type":"index_or_alias","resource.id":"index1","index_uuid":"_na_","index":"index1"}],"type":"index_not_found_exception","reason":"no such index","resource.type":"index_or_alias","resource.id":"index1","index_uuid":"_na_","index":"index1"},"status":404}% <br />
查看 Elasticsearch 端日志为：
<br /> [2021-12-11T01:49:50,303][DEBUG][r.suppressed ] path: /index1/_search, params: {q=Mac OS X 10.13.4 unknown, architecture: x86_64-64, index=index1}<br /> org.elasticsearch.index.IndexNotFoundException: no such index<br /> at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.infe(IndexNameExpressionResolver.java:678) ~[elasticsearch-5.6.15.jar:5.6.15]<br /> at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.innerResolve(IndexNameExpressionResolver.java:632) ~[elasticsearch-5.6.15.jar:5.6.15]<br /> at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.resolve(IndexNameExpressionResolver.java:580) ~[elasticsearch-5.6.15.jar:5.6.15]<br /> <br />
可以看到查询条件里面的q=${java:os}被执行了，变成了q=Mac OS X 10.13.4 unknown, architecture: x86_64-64, index=index1，说明变量被解析且执行，存在漏洞利用的风险。
那走网关之后呢：
<br /> ~% curl 'http://localhost:8000/index1/_search?q=%24%7Bjava%3Aos%7D' <br /> <br /> Apache Log4j 2, Boom!% <br />
可以看到请求被过滤掉了，返回了自定义的信息。
还有一些其他测试命令，大家也可以试试：
```
{java:vm}
~% curl 'http://localhost:9200/index/_search?q=%24%7Bjava%3Avm%7D'
[2021-12-11T02:36:04,764][DEBUG][r.suppressed ] [INFINI-2.local] path: /index/_search, params: {q=OpenJDK 64-Bit Server VM (build 25.72-b15, mixed mode), index=index}
~% curl 'http://localhost:8000/index/_search?q=%24%7Bjava%3Avm%7D'
Apache Log4j 2, Boom!%
{jndi:rmi://localhost:1099/api}
~% curl 'http://localhost:9200/index/_search?q=%24%7Bjndi%3Armi%3A%2F%2Flocalhost%3A1099%2Fapi%7D'
2021-12-11 03:35:06,493 elasticsearch[YOmFJsW][search][T#3] ERROR An exception occurred processing Appender console java.lang.SecurityException: attempt to add a Permission to a readonly Permissions object
~% curl 'http://localhost:8000/index/_search?q=%24%7Bjndi%3Armi%3A%2F%2Flocalhost%3A1099%2Fapi%7D'
Apache Log4j 2, Boom!%
```
另外不同版本的 Elasticsearch 对于攻击的复现程度参差不齐，因为 es 不同版本是否有 Java Security Manager 、不同版本 JDK 、以及默认配置也不相同，新一点的 es 其实同样可以触发恶意请求，只不过网络调用被默认的网络策略给拒绝了，相对安全，当然如果设置不当同样存在风险，见过很多用户一上来就关默认安全配置的，甚至还放开很多暂时用不上的权限，另外未知的攻击方式也一定有，比如大量日志产生的系统调用可能会拖垮机器造成服务不可用，所以要么还是尽快改配置换 log4j 包重启集群，或者走网关来过滤阻断请求吧。
使用极限网关处置类似安全事件的好处是，Elasticsearch 服务器不用做任何变动，尤其是大规模集群的场景，可以节省大量的工作，提升效率，非常灵活，缩短安全处置的时间，降低企业风险。
- http://localhost:9200
发布一个免费的 Elasticsearch 多集群监控和管理平台 - 极限数据平台
medcl 发表了文章 • 20 个评论 • 6096 次浏览 • 2021-11-22 18:48
随着单个 Elasticsearch 集群规模的越来越大，大家要么在拆集群的路上，要么是已经是多套集群了， 据路边社消息，一个公司超过5个集群的情况已经变得非常普遍，而管理多个集群着实是有点痛苦，比如常规的玩法可能是一套集群一个 Kibana，集群一多，切换来切换去就有点懵圈了有木有？
作为一个优雅的程序员或者运维管理员，是可忍孰不可忍啊。
另外，多个集群的监控也是一个麻烦事，目前常见的几种监控如：
- 使用 Kibana 自带的监控
- 使用 Prometheus + Grafana
- 使用 Zabbix
Kibana 自带的监控可以很好的满足单个集群的监控场景，不过集群规模大了之后，经常会出现指标丢失的问题，如果使用单独的监控集群，需要修改每个节点的配置，集群都需要重启，对于已经上了生产的集群，有点不方便，另外多集群监控需要商业授权。
那 Prometheus 呢， 一个 Elasticsearch 集群如果要监控起来，首先需要部署一个 Exporter 来暴露集群指标，然后部署一套Prometheus 来采集 Elasticsearch 指标，采集完了之后再部署一套 Grafana 来进行报表分析，不同的集群要做好切换，简单的事情，搞复杂了，整个监控体系偏重，维护成本高。
Zabbix 和 Prometheus 的场景差不多，就不赘述了。
那么问题来了，有没有一个更加简单方便的多集群监控和管理方案呢，并且要支持不同版本的集群，最好是 v2、v5、v6、v7 以及最新的 v8 都能统统接管，哈哈，没错了，这里给大家介绍一个我们极限实验室团队最近开发出来的一款免费的多集群监控和管理工具-极限数据平台，目前版本 v0.1，新鲜出炉。
废话不多少，咱们直接看图说话：
首先是多集群的纳管，目前从 1.0 到最新的 8.0 统统都可以接进来。
然后就是集群的监控拉，要多简单有多简单，就是一个开关的事情，注册集群的时候，启用即开启监控，目标集群啥都不用动，费那劲干啥。
监控界面如图：
集群概览，总体情况一目了然。
各个节点信息，分门别类。
各个索引级别的信息，挨个查看。
多个集群之间的监控查看一键切换，非常方便。
查看监控的时候，发现不对劲，要操作一下集群，直接调出控制台，如下图：
常用的操作命令，可以保存起来，方便下次使用。
别再保存在记事本里面了，下次又找不到，直接加载执行就好了。
好了，你要是用 Elasticsearch 不知道这个工具，那就 out 了，赶快耍起来吧。
下载地址：
[http://release.elasticsearch.cn/console/snapshot/](http://release.elasticsearch.cn/console/snapshot/)
安装巨简单，简直懒得说，一个二进制可执行文件，一个 yml 配置文件，里面修改 Elasticsearch 地址，结束。
可以在这里查看 [介绍和 Demo 演示视频](https://www.bilibili.com/video ... KdMVLQ)
最后，欢迎关注极限实验室，获取更多 Elasticsearch 免费工具及业界资讯的第一手消息。
ES容灾技术探讨和测试
yangmf2040 发表了文章 • 3 个评论 • 4768 次浏览 • 2021-10-27 13:33
ES灾备技术调研
早就听说极限网关了，最近有个ES要做灾备，就搜集了下技术方案：
- 应用双写两个集群
- 跨集群复制CCR
- 极限网关
三个方案的优缺点我也简单整理了下：
- 优点：自主研发，想怎样就怎样；缺点：难，水平、时间都是成本
- 优点：实施简单；缺点：需要license
- 优点：部署灵活，功能齐全；缺点：不熟悉，没用过
貌似方案 3，比较理想。不熟悉，那就多用用，测试测试找找感觉。
测试环境 笔记本
| 主集群：A | 7.14.1 | 10.0.2.15:9214 | Rbac+tls | 节点数：1 |
| --------- | ------ | -------------- | -------- | --------- |
| 备集群：B | 7.13.2 | 10.0.2.15:9213 | Rbac+tls | 节点数：2 |
| 极限网关 | 1.3.0 | 0.0.0.0:8000 | tls | 实例数：1 |
网关下载
先下载极限网关：http://release.elasticsearch.cn/gateway/snapshot/
解压后，可看到有几个预定义的配置，方便大家快速上车。
网关配置
这次是做灾备，应该就是在 dc-replica.yml的基础上改比较妥当，配置还是比较多的 300多行，很多都是为了保证两个集群数据一致性，解耦啥的做的判断和写队列之类的设置。我只修改了 elasticsearch资源的定义信息，还有网关也可选择tls，不用手工生成证书，非常方便。
贴下我修改的地方
启动网关
两个集群都是 available ，说明连接应该ok
测试场景：围绕主备集群之间数据复制展开
1. 主备集群间复制创建、写入、删除索引操作
目的：对网关（A集群）创建索引test，对test索引写文档，能自动同步到B集群
初始情况A、B无test
手工put test索引到网关
A,B集群都创建成功
用loadgen写点文档进去吧，loadgen直接写网关
都10000条写入成功，如果查看是0的话，先refresh下索引
看下文档
简单校验一下
感觉没问题，删点文档看看，把那23个删了吧
再看看
更新524个文档看看
增、删、改 完事
2. 主集群故障的处理和恢复
目的：主集群故障后，网关如何处理收到的请求：读、写
Kill 掉 A 集群，模拟主集群故障
网关直接有报错说连不上A集群
此时对网关查询、写入数据都会报错
重新启动主集群后，一切正常
3. 备集群故障的处理和恢复
目的：备集群故障，读、写主集群不受影响，备集群恢复后，自动追数据直到两边数据一致
Kill 掉B集群，网关报错，B集群无法连接
对A集群进行写入一个新文档，并查询下
启动B集群，查看，已自动添加了新的文档
4. 主集群容灾切换
目的：主集群故障，短时间不可用，网关切换指向备集群作为主集群，A集群作为备集群；待A集群恢复后，自动追数据
KILL A 集群 模拟A集群故障
Kill 网关，切换配置：
启动网关，B是主了，available
写B集群，删除前面创建的 test 索引，新建test2索引，并插入文档
启动A集群，检查数据，有test2索引，且文档一致
5. 主集群故障恢复后，网关回切
目的：假设A集群已经完全恢复，网关回切，A集群为主，B集群为备
Kill网关，恢复配置，再启动网关
再次测试写入test2 检查能否同步成功
写网关
查看A集群
查看B集群
两个集群数据一致，主备角色也恢复到最初了
**测试环境变更
中间工作比较忙，中断了测试，也就十来天吧
不成想 网关更新了，我就下了新版本的gateway和ES-7.15.1 继续捣鼓
环境 笔记本
| 主集群：es-751primary | 7.15.1 | 10.0.2.15:7151 | No：Rbac、tls | 节点数：1 |
| --------------------- | ------------------------ | -------------- | ------------- | --------- |
| 备集群：es-751backup | 7.15.1 | 10.0.2.15:7152 | No：Rbac、tls | 节点数：1 |
| 极限网关 | 场景6：1.4.0场景7：1.5.0 | 0.0.0.0:8000 | No：tls | 实例数：1 |
网关不光版本升级了，配置文件也稍稍有些变化，新版本示例配置如下
本着不会就猜的原则，我还是能做到见名之知意的
我仅仅对 cross-cluster-replication.yml 做了简单的修改，就是和前面一样
6. ES由代理暴露的能否正常工作
目的：检验，比如由nginx代理ES的时候，网关能否正常工作
使用 nginx 代理后端的ES
80-->primary
81-->backup
测试下反向代理工作是否正常
启动网关，网关里elasticsearch资源指向nginx，没错就改了下 url
开始测试，增删改查 once more，还是对着网关操作
创建索引
PUT 文档
抄家伙
看看数量
简单对比下
给 code为500的文档增加一个字段 new_field
直接通过代理查询，检验数据
没问题，测试删除
删除单条
批量删除
看看结果
删除索引，并确认真的删除
关调backup集群，然后primary集群创建索引后，再启动backup集群，看能否自动追平
创建test2索引
顺手put个文档
Primary上查看
OK 启动backup
妈的 奇迹
7. 请求压缩功能如何
目的：看看客户端和网关分别在不同的请求压缩配置下，是否工作正常
在网关的配置中，看到了 compress 压缩，也设计几个场景测试下
网关配置里面有个压缩的配置，意思是消费线程往ES发送请求的时候是否启用gzip压缩。
默认是 true
7.1 用压缩的方式写网关，但网关不启用压缩
我们把网关配置中的true改成false
启动网关
开始写数据，写的过程中，随机停止backup集群，等待一会儿后再启动
网关可看到 backup集群，从不可用到可用
看看网关的队列情况，这时候backup队列应该堆积了不少请求
等待队列被消费完后，我们对比数据。
简单看看文档条数
用网关对比下数据看看
妥妥的一致
7.2 用压缩的方式写网关，网关也启用压缩
就把前面网关贴图的false改成true
启动网关
压缩写入
写入过程中，随机重启backup集群
网关日志
等待网关backup队列消费完毕，后对比数据
没得问题，下一场
7.3 用不压缩的方式写网关，网关也不启用压缩
网关配置compress: false，后启动网关
不压缩请求
中途随机重启backup集群
队列消费完后对比数据
数据一致
7.4 用不压缩的方式写网关，网关backup队列的消费线程使用压缩
写入过程中，停止backup集群，稍等一会儿后启动backup集群
观察网关的backup 队列情况
等消费完之后，我们对比数据
数量一致
用网关来对比下两个集群的test索引的数据
至此，关于跨集群复制的场景测试可以告一段落了，功能大家也看到了确实强大，部署也很灵活，对环境无侵入，直接把应用连接ES的地址、端口改下就行。或者网关直接监听9200端口，替换原有的协调节点，应用无感知。
此外，极限网关还有很多别的使用场景和激动人心的功能，像在线修改查询、请求限流、请求流量分析，这都是保障ES集群稳定运行的手段。
看到一款国产软件如此强大很欣慰，很激动。希望各位感兴趣的小伙伴也下载测试下自己的场景，我们ES圈（论坛）多交流交流。让我也看看你们的场景和测试是怎样的。
最后一个图，我也不知道咋回事，请忽略。
使用极限网关来进行 Elasticsearch 跨集群跨版本查询及所有其它请求
medcl 发表了文章 • 7 个评论 • 3764 次浏览 • 2021-10-16 11:31
使用场景
如果你的业务需要用到有多个集群，并且版本还不一样，是不是管理起来很麻烦，如果能够通过一个 API 来进行查询就方便了，聪明的你相信已经想到了 CCS，没错用 CCS 可以实现跨集群的查询，不过 Elasticsearch 提供的 CCS 对版本有一点的限制，并且需要提前做好 mTLS，也就是需要提前配置好两个集群之间的证书互信，这个免不了要重启维护，好像有点麻烦，那么问题来咯，有没有更好的方案呢？
😁 有办法，今天我就给大家介绍一个基于极限网关的方案，极限网关的网址：http://极限网关.com/。
假设现在有两个集群，一个集群是 v2.4.6，有不少业务数据，舍不得删，里面有很多好东西 ：）还有一个集群是 v7.14.0，版本还算比较新，业务正在做的一个新的试点，没什么好东西，但是也得用 :(，现在老板们的的需求是希望通过在一个统一的接口就能访问这些数据，程序员懒得很，懂得都懂。
集群信息
- v2.4.6 集群的访问入口地址：192.168.3.188:9202
- v7.14.0 集群的访问入口地址：192.168.3.188:9206
这两个集群都是 http 协议的。
实现步骤
今天用到的是极限网关的 switch 过滤器：https://极限网关.com/docs/references/filters/switch/
网关下载下来就两个文件，一个主程序，一个配置文件，记得下载对应操作系统的包。
定义两个集群资源
```
elasticsearch:- name: v2
enabled: true
endpoint: http://192.168.3.188:9202 - name: v7
enabled: true
endpoint: http://192.168.3.188:9206
``<br /> <br /> 上面定义了两个集群，分别命名为v2和v7`，待会会用到这些资源。
定义一个服务入口
```
entry: - name: my_es_entry
enabled: true
router: my_router
max_concurrency: 1000
network:
binding: 0.0.0.0:8000
tls:
enabled: true
``<br /> <br /> 这里定义了一个名为my_es_entry的资源入口，并引用了一个名为my_router的请求转发路由，同时绑定了网卡的0.0.0.0:8000也就是所有本地网卡监听 IP 的8000端口，访问任意 IP 的8000端口就能访问到这个网关了。<br /> <br /> 另外老板也说了，Elasticsearch 用 HTTP 协议简直就是裸奔，通过这里开启tls，可以让网关对外提供的是 HTTPS 协议，这样用户连接的 Elasticsearch 服务就自带 buffer 了，后端的 es 集群和网关直接可以做好网络流量隔离，集群不用动，简直完美。<br /> <br /> 为什么定义 TLS 不用指定证书，好用的软件不需要这么麻烦，就这样，不解释。<br /> <br /> 最后，通过设置max_concurrency` 为 1000，限制下并发数，避免野猴子把我们的后端的 Elasticsearch 给压挂了。
定义一个请求路由
```
router: - name: my_router
default_flow: cross-cluster-search
``<br /> <br /> 这里的名称my_router就是表示上面的服务入口的router参数指定的值。<br /> <br /> 另外设置一个default_flow来将所有的请求都转发给一个名为cross-cluster-search` 的请求处理流程，还没定义，别急，马上。
定义请求处理流程
来啦，来啦，先定义两个 flow，如下，分别名为v2-flow和v7-flow，每节配置的filter定义了一系列过滤器，用来对请求进行处理，这里就用了一个elasticsearch过滤器，也就是转发请求给指定的 Elasticsearch 后端服务器，了否？
```
flow: - name: v2-flow
filter:
- elasticsearch:
elasticsearch: v2
- elasticsearch:
- name: v7-flow
filter:
- elasticsearch:
elasticsearch: v7
<br /> <br /> 然后，在定义额外一个名为 `cross-cluster-search` 的 flow，如下：<br /> <br />
- elasticsearch:
- name: cross-cluster-search
filter:
- switch:
path_rules:
- prefix: "v2:"
flow: v2-flow - prefix: "v7:"
flow: v7-flow
<br /> 这个 flow 就是通过请求的路径的前缀来进行路由的过滤器，如果是 `v2:`开头的请求，则转发给 `v2-flow` 继续处理，如果是 `v7:` 开头的请求，则转发给 `v7-flow` 来处理，使用的用法和 CCS 是一样的。so easy！<br /> <br /> 对了，那是不是每个请求都需要加前缀啊，费事啊，没事，在这个 `cross-cluster-search` 的 filter 最后再加上一个 `elasticsearch` filter，前面前缀匹配不上的都会走它，假设默认都走 `v7`，最后完整的 flow 配置如下：<br /> <br />
flow:
- prefix: "v2:"
- switch:
- name: v2-flow
filter:
- elasticsearch:
elasticsearch: v2
- elasticsearch:
- name: v7-flow
filter:
- elasticsearch:
elasticsearch: v7
- elasticsearch:
- name: cross-cluster-search
filter:
- switch:
path_rules:
- prefix: "v2:"
flow: v2-flow - prefix: "v7:"
flow: v7-flow
- prefix: "v2:"
- elasticsearch:
elasticsearch: v7
```
然后就没有然后了，因为就配置这些就行了。
启动网关
假设配置文件的路径为sample-configs/cross-cluster-search.yml，运行如下命令：
<br /> ➜ gateway git:(master) ✗ ./bin/gateway -config sample-configs/cross-cluster-search.yml<br /> ___ _ _____ __ __ __ _ <br /> / _ \ /_\ /__ \/__\/ / /\ \ \/_\ /\_/\<br /> / /_\///_\\ / /\/_\ \ \/ \/ //_\\\_ _/<br /> / /_\\/ _ \/ / //__ \ /\ / _ \/ \ <br /> \____/\_/ \_/\/ \__/ \/ \/\_/ \_/\_/ <br /> <br /> [GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway.<br /> [GATEWAY] 1.0.0_SNAPSHOT, 2021-10-15 16:25:56, 3d0a1cd<br /> [10-16 11:00:52] [INF] [app.go:228] initializing gateway.<br /> [10-16 11:00:52] [INF] [instance.go:24] workspace: data/gateway/nodes/0<br /> [10-16 11:00:52] [INF] [api.go:260] api listen at: <a href="http://0.0.0.0:2900" rel="nofollow" target="_blank">http://0.0.0.0:2900</a><br /> [10-16 11:00:52] [INF] [reverseproxy.go:257] elasticsearch [v7] hosts: [] => [192.168.3.188:9206]<br /> [10-16 11:00:52] [INF] [entry.go:225] auto generating cert files<br /> [10-16 11:00:52] [INF] [actions.go:223] elasticsearch [v2] is available<br /> [10-16 11:00:52] [INF] [actions.go:223] elasticsearch [v7] is available<br /> [10-16 11:00:53] [INF] [entry.go:296] entry [my_es_entry] listen at: <a href="https://0.0.0.0:8000" rel="nofollow" target="_blank">https://0.0.0.0:8000</a><br /> [10-16 11:00:53] [INF] [app.go:309] gateway is running now.<br />
可以看到网关输出了启动成功的日志，网关服务监听在<a href="https://0.0.0.0:8000" rel="nofollow" target="_blank">https://0.0.0.0:8000</a>。
试试访问网关
直接访问网关的 8000 端口，因为是网关自签的证书，加上 -k 来跳过证书的校验，如下：
<br /> ➜ loadgen git:(master) ✗ curl -k <a href="https://localhost:8000" rel="nofollow" target="_blank">https://localhost:8000</a> <br /> {<br /> "name" : "LENOVO",<br /> "cluster_name" : "es-v7140",<br /> "cluster_uuid" : "npWjpIZmS8iP_p3GK01-xg",<br /> "version" : {<br /> "number" : "7.14.0",<br /> "build_flavor" : "default",<br /> "build_type" : "zip",<br /> "build_hash" : "dd5a0a2acaa2045ff9624f3729fc8a6f40835aa1",<br /> "build_date" : "2021-07-29T20:49:32.864135063Z",<br /> "build_snapshot" : false,<br /> "lucene_version" : "8.9.0",<br /> "minimum_wire_compatibility_version" : "6.8.0",<br /> "minimum_index_compatibility_version" : "6.0.0-beta1"<br /> },<br /> "tagline" : "You Know, for Search"<br /> }<br />
正如前面配置所配置的一样，默认请求访问的就是 v7 集群。
访问 v2 集群
<br /> ➜ loadgen git:(master) ✗ curl -k <a href="https://localhost:8000/v2:/" rel="nofollow" target="_blank">https://localhost:8000/v2:/</a> <br /> {<br /> "name" : "Solomon O'Sullivan",<br /> "cluster_name" : "es-v246",<br /> "cluster_uuid" : "cqlpjByvQVWDAv6VvRwPAw",<br /> "version" : {<br /> "number" : "2.4.6",<br /> "build_hash" : "5376dca9f70f3abef96a77f4bb22720ace8240fd",<br /> "build_timestamp" : "2017-07-18T12:17:44Z",<br /> "build_snapshot" : false,<br /> "lucene_version" : "5.5.4"<br /> },<br /> "tagline" : "You Know, for Search"<br /> }<br />
查看集群信息：
<br /> ➜ loadgen git:(master) ✗ curl -k <a href="https://localhost:8000/v2:_cluster/health" rel="nofollow" target="_blank">https://localhost:8000/v2:_cluster/health</a>\?pretty<br /> {<br /> "cluster_name" : "es-v246",<br /> "status" : "yellow",<br /> "timed_out" : false,<br /> "number_of_nodes" : 1,<br /> "number_of_data_nodes" : 1,<br /> "active_primary_shards" : 5,<br /> "active_shards" : 5,<br /> "relocating_shards" : 0,<br /> "initializing_shards" : 0,<br /> "unassigned_shards" : 5,<br /> "delayed_unassigned_shards" : 0,<br /> "number_of_pending_tasks" : 0,<br /> "number_of_in_flight_fetch" : 0,<br /> "task_max_waiting_in_queue_millis" : 0,<br /> "active_shards_percent_as_number" : 50.0<br /> }<br />
插入一条文档：
<br /> ➜ loadgen git:(master) ✗ curl-json -k <a href="https://localhost:8000/v2:medcl/doc/1" rel="nofollow" target="_blank">https://localhost:8000/v2:medcl/doc/1</a> -d '{"name":"hello world"}'<br /> {"_index":"medcl","_type":"doc","_id":"1","_version":1,"_shards":{"total":2,"successful":1,"failed":0},"created":true}% <br />
执行一个查询
<br /> ➜ loadgen git:(master) ✗ curl -k <a href="https://localhost:8000/v2:medcl/_search" rel="nofollow" target="_blank">https://localhost:8000/v2:medcl/_search</a>\?q\=name:hello <br /> {"took":78,"timed_out":false,"_shards":{"total":5,"successful":5,"failed":0},"hits":{"total":1,"max_score":0.19178301,"hits":[{"_index":"medcl","_type":"doc","_id":"1","_score":0.19178301,"_source":{"name":"hello world"}}]}}% <br />
可以看到，所有的请求，不管是集群的操作，还是索引的增删改查都可以，而 Elasticsearch 自带的 CCS 是只读的，只能进行查询。
访问 v7 集群
<br /> ➜ loadgen git:(master) ✗ curl -k <a href="https://localhost:8000/v7:/" rel="nofollow" target="_blank">https://localhost:8000/v7:/</a><br /> {<br /> "name" : "LENOVO",<br /> "cluster_name" : "es-v7140",<br /> "cluster_uuid" : "npWjpIZmS8iP_p3GK01-xg",<br /> "version" : {<br /> "number" : "7.14.0",<br /> "build_flavor" : "default",<br /> "build_type" : "zip",<br /> "build_hash" : "dd5a0a2acaa2045ff9624f3729fc8a6f40835aa1",<br /> "build_date" : "2021-07-29T20:49:32.864135063Z",<br /> "build_snapshot" : false,<br /> "lucene_version" : "8.9.0",<br /> "minimum_wire_compatibility_version" : "6.8.0",<br /> "minimum_index_compatibility_version" : "6.0.0-beta1"<br /> },<br /> "tagline" : "You Know, for Search"<br /> }<br />
Kibana 里面访问
完全没问题，有图有真相：
其他操作也类似，就不重复了。
完整的配置
```
path.data: data
path.logs: log
entry:
- switch:
- name: my_es_entry
enabled: true
router: my_router
max_concurrency: 10000
network:
binding: 0.0.0.0:8000
tls:
enabled: true
flow: - name: v2-flow
filter:
- elasticsearch:
elasticsearch: v2
- elasticsearch:
- name: v7-flow
filter:
- elasticsearch:
elasticsearch: v7
- elasticsearch:
- name: cross-cluster-search
filter:
- switch:
path_rules:
- prefix: "v2:"
flow: v2-flow - prefix: "v7:"
flow: v7-flow
- prefix: "v2:"
- elasticsearch:
elasticsearch: v7
router:
- switch:
- name: my_router
default_flow: cross-cluster-search
elasticsearch: - name: v2
enabled: true
endpoint: http://192.168.3.188:9202 - name: v7
enabled: true
endpoint: http://192.168.3.188:9206
```
小结
好了，今天给大家分享的如何使用极限网关来进行 Elasticsearch 跨集群跨版本的操作就到这里了，希望大家周末玩的开心。😁
- name: v2
《腾讯Elasticsearch海量规模背后的内核优化剖析》答疑
howardhuang 发表了文章 • 37 个评论 • 8151 次浏览 • 2020-05-09 17:05
今天下午的《腾讯Elasticsearch海量规模背后的内核优化剖析》分享 大家反映强烈，由于时间关系，大家的问题没能及时答复，这里集中解答，大家如果还有其它疑问也可以持续提问。感谢大家的关注！
另外腾讯云上有内核增强版的ES服务，包含了我们所有的内核优化项，欢迎大家体验！
团队也在持续招聘，欢迎简历来砸：danielhuang@tencent.com; johngqjiang@tencent.com
今天下午的《腾讯Elasticsearch海量规模背后的内核优化剖析》分享 大家反映强烈，由于时间关系，大家的问题没能及时答复，这里集中解答，大家如果还有其它疑问也可以持续提问。感谢大家的关注！
另外腾讯云上有内核增强版的ES服务，包含了我们所有的内核优化项，欢迎大家体验！
团队也在持续招聘，欢迎简历来砸：danielhuang@tencent.com; johngqjiang@tencent.com
邀请参加 Elasticsearch 中文分词器需求调查问卷
medcl 发表了文章 • 4 个评论 • 4681 次浏览 • 2019-06-24 20:23
亲爱的 Elasticsearch 中文用户：
为了能够充分了解您对 Elasticsearch 中文分词需求的基本情况，以便我们更有针对性地改进中文分词下的使用体验，并优化相关分词器，请您抽出几分钟的时间填写以下问卷。问卷题目中的选项没有对错之分，请您根据实际情况或想法进行填写。您的信息将被严格保密，请放心填写！
调研结束后，我们将随机抽出 5 名同学，每人送 Elastic 纪念 T 恤一件。谢谢您对本次调查的参与和支持~
问卷填写地址：http://elasticsearch.mikecrm.com/nz0FxmK
谢谢！
以下是 5 位幸运的参与者：
- 韦先生 *4270
- 汪科 *9396
- 乔驰 *3096
- 彭先生 *4350
- 张丽斌 *5329
再次感谢大家的参与。
Elasticsearch 安全加固 101
medcl 发表了文章 • 8 个评论 • 20729 次浏览 • 2017-01-13 13:03
最近 MongoDB 的安全事件闹得沸沸扬扬，应该不少人都听说了吧，事情大概是，因为 MongoDB 默认的安全设置造成了数据外泄并且被黑客勒索才能找回数据，想了解的，这里有几个链接：
http://www.jianshu.com/p/48d17a69e190
http://mt.sohu.com/20170107/n478047698.shtml
http://bbs.tianya.cn/post-itinfo-503786-1.shtml
安全从来不是等到出事才要注意的事情，可以说安全是第一重要的事情，不管你是公司的CTO、技术总监、运维总监、架构师还是一线工程师，都应该有安全意识，好了，废话不多说了，Elasticsearch 的用户现在越来越多了，有些已经成为公司的基础服务，所以数据的安全非常重要，今天主要给大家介绍 Elasticsearch 围绕安全方面的的几点使用事项：
下载安装
请使用正规渠道下载 Elasticsearch，首选官方网站，下载完成，记得要验证下载文件的 sha1值和官网下载的提供的sha1值进行对比，避免下载过程中被人拦截破坏文件，甚至注入恶意代码。
不要随便安装第三方的插件，插件有可能引入安全漏洞甚至本身自带后门，需谨慎使用。
链接君：https://www.elastic.co/downloads
使用最新的 Elasticsearch
请关注 Elastic 网站，及时更新升级 Elasticsearch 的最新版本，Elasticsearch 每次版本发布都会优化和改进一部分功能，尤其是安全漏洞的补丁，仔细阅读 Elasticsearch 的更新记录，Elasticsearch 的版本遵照 语义化版本 ，所以小版本间应该是能够无缝升级的，建议及时本地测试和线上更新，升级前，记得 snapshot 做好备份。
链接君：https://www.elastic.co/downloads
修改默认的 Elasticsearch 集群名称
Elasticsearch 默认的集群名称是 elasticsearch，请在生成环境上一定要修改成其他的名称，并且不同的环境和不同的集群要保证不相同，监控集群节点情况，如果有未知节点加入，一定要及时预警。
文档君：https://www.elastic.co/guide/e ... .name
不要暴露 Elasticsearch 在公网上
Elasticsearch 默认端口是9200，绑定的是本机127.0.0.1的这个 ip，这个默认参数其实很安全，但是有很多人想要绑定其他的 lan 口或者公网的 ip，可以修改相应参数，记住，修改有风险，如果确实需要将 Elasticsearch 暴露在公网环境，请修改特定的端口绑定IP，不要直接修改参数： network.host，而是要分别修改：http.port 来绑定 HTTP 协议9200 端口的 IP（RESTful 接口调用），修改：transport.tcp.port 对应的 TCP 9300 端口的 IP（集群内通信），如果你不需要 http 端口，你干脆禁用掉，另外还需要在 Elasticsearch 之上加上成熟的安全防护措施（注意是成熟的！），在这里提供几种方案：
- 9200的 HTTP 接口之上加上 Nginx 来提供 Http Basic-Auth 的基本的身份认证，辅助 SSL 证书进行传输层的加密，Nginx 进一步限制可接受 Verb 请求类型及可被操作的索引前缀。
- 使用 Elastic 的 X-Pack 插件，同样提供了 Http Basic-Auth 和 SSL 传输层的加密，X-Pack 还能提供内外 Elasticsearch 集群节点间的流量加密，避免旁路攻击。
文档君：https://www.elastic.co/guide/e ... tings
禁用批量删除索引
Elasticsearch 支持通过_all（全部）和通配符（*）来批量删除索引，在生产环境，这个有点危险，你可以通过设置： action.destructive_requires_name: true 来禁用它。
安全使用动态脚本
Elasticsearch 的脚本很方便的可以对数据进行操作，不过如果你暂时没有用上，还请禁用它（Elasticsearch 在1.2.x 以后已经默认禁用了），如果你已经在使用动态脚本，比如 Groovy，它不是沙盒机制的脚本引擎，启用 inline 或 store 类型的groovy 有安全风险，请限制脚本的接触方，比如通过模板的方式来限制脚本的调用，只需要执行特定预先定义好的脚本，对调用参数进行过滤和参数值的检测，做好验证，同时各种日志都必须要保留好，方便进行日志分析，异常的调用和请求一定要有发现和预警机制。
Elasticsearch 默认启用了 Java Security Manager ，但还请正确配置其白名单。
使用 Groovy 或者JavaScript 等脚本的用户，尽快迁移到 Painless 脚本，Painless 更快更安全。
文档君：https://www.elastic.co/guide/e ... .html
给 Elasticsearch 服务器加固
服务器加固是一个必备流程，不管上面运行的是什么服务；
首先，请开启防火墙，请设置防火墙规则，只开启必备的端口，完成之后，使用扫描工具扫描服务器，检查端口开发情况；
如果可能，不要用密码的方法来远程登录服务器，使用公私钥的方式来 ssh 登录服务器，如果只能使用密码，请妥善保管好你的用户名和密码，禁用 root 用户，不用使用弱密码。
关注 Java 最新的漏洞，使用安全的 JVM 运行时。
服务器及时更新最新的软件，使用安全的 repo 软件源，绑定软件源的 host和 ip，避免 dns 污染造成的攻击，关注服务器软件漏洞，及时打上补丁。
收集系统日志和安装相应的入侵检测软件，及时发现服务器是否有异常行为。
不要以 root 身份运行 Elasticsearch
如果你的运维人员打算以 root 身份来运行某个服务，这个运维人员一定是一个不合格的运维人员，记住一定不要以 root 身份来运行 Elasticsearch，另外，要不和其他的服务公用相同的用户，然后还要保证该用户的权限要最小化。
范例君：
sudo -u es-user ES_JAVA_OPTS="-Xms1024m -Xmx1024m" /opt/elasticsearch/bin/elasticsearc正确设置 Elasticsearch 的数据目录
请确保 Elasticsearch 的目录分配了合理的读写权限，避免使用共享文件系统，确保只有 elasticsearch 的启动用户才能访问，同理，日志目录也一样需要正确配置，避免泄露敏感信息。
文档君：https://www.elastic.co/guide/e ... tings
定期对 Elasticsearch 进行备份
使用 Elasticsearch 提供的备份还原机制，定期对 Elasticsearch 的数据进行快照备份，以备不时之需。
文档君：https://www.elastic.co/guide/e ... .html
加上监控和预警
Elasticsearch 提供了很好的默认参数，对参数方面还做了正确性检测，bootstrap 启动检查，不准确的参数，直接不允许 Elasticsearch 启动，以至于有很多人抱怨，怎么现在部署到线上默认就需要做这么多设置才能使用呢，是的，以前启动就默认绑定了所有的网卡，集群见自动发现和相连，现在需要手动绑定局域网网卡，默认只是绑定的本机127.0.0.1的 ip，对上线来说麻烦了一点，做了这些检查也就是为了保证数据安全，以前很多的公网都能直接访问的 Elasticsearch 实例，都是因为默认设置就绑定了公网 ip，但是这些还不够，作为用户，你还需要收集各种日志和系统监控信息，及时主动掌握服务健康和资源使用情况，发现异常情况要及时处理，这里提供一些方案:
- 使用开源的 Elastic Stack 收集这些日志，可以使用 Filebeat 收集日志，Metricbeat收集系统监控信息，存进 Elasticsearch，一旦发现异常的波动，使用 Watcher 来进行预警，通过邮件或者 webhook 调用短信、微信或者电话。
- 使用其他厂商的安全监控产品。
- 使用托管的 Elasticsearch 云的产品，如 Elastic Cloud等等。
是的，把安全这个事情考虑进去之后，很多事情都要比没考虑要变得更加复杂和麻烦，千里之堤毁于蚁穴，一个不起眼的忽视就有可能造成全部数据的丢失和泄露，出来混迟早是要还的，安全问题千万不能忽视。
以上几点建议举例针对 linux 平台，其他平台思路基本上一样，仅供参考，安全是一个包含很多方方面面的学科，抛砖引玉，希望大家有用。
最后，Elastic 非常关心我们的产品安全，如果您发现有任何安全方面的问题，还请在这里上报：
https://www.elastic.co/community/security
企业用户需要 X-Pack 及 Elastic 官方技术支持，请访问下面的链接：
https://www.elastic.co/cn/contact
