随着单个 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/

安装巨简单，简直懒得说，一个二进制可执行文件，一个 yml 配置文件，里面修改 Elasticsearch 地址，结束。

可以在这里查看 介绍和 Demo 演示视频

最后，欢迎关注极限实验室，获取更多 Elasticsearch 免费工具及业界资讯的第一手消息。

Elastic 中国开发者大会 2021 是由 Elastic 官方、Elastic 中文社区和极限科技联合主办的开发者大会，作为中国国内唯一一个专门讨论 Elasticsearch 开源技术的大会，是中国最权威和最具实力干货的技术大会，其专业性和内容的质量一直以来在业内都是有口皆碑，大会最早发起于 2013 年初一个很小的线下聚会，之后每年迅速成长，往年大会的演讲嘉宾有来自 Elastic 官方、百度、腾讯、阿里巴巴、360、微博、美团、58、苏宁等众多公司的技术专家，带来过众多精彩的分享，与会听众大多为大数据领域相关的架构师、技术经理与一线开发工程师和运维工程师。 我们本着非盈利目的来举办大会，今年的大会将于2022年1月8号在深圳举行，举办开发者大会的目的是为中国广大的 Elasticsearch 开发者提供一个技术交流和学习切磋的地方，汇集业界众多的成功案例，集思广益，发散思维，促进社区和行业的进步。   大会官网：https://conf.elasticsearch.cn Elasticsearch铁粉福利： 预热-铁粉票(79元/张)， 共计100张，数量有限，赶紧去报名抢购吧！ 购票地址：https://www.bagevent.com/event/7899116   同时大会也在公开征集演讲议题与合作赞助商，欢迎各位Elastic相关技术大咖报名参与分享，欢迎有兴趣的赞助商金主大大前来合作。 演讲报名申请：http://elasticsearch.mikecrm.com/uXH61JL 赞助合作申请：http://elasticsearch.mikecrm.com/6LGkKK0    

活动介绍

本次Meetup杭州站由阿里云和Elastic联合举办，邀请来自滴滴、安恒信息、阿里云的资深技术专家探讨在搜索、安全、内核优化等方向的实践与创新，以及发布由数十位优秀技术开发者共创而成的实战指南，共同分享 Elasticsearch技术大咖的一线经验与深度思考。

报名方式

链接：https://www.bagevent.com/event/7449056
扫码:

活动时间

2021年06月05日 13:00-17:30

活动地址

浙江省杭州市余杭区阿里巴巴西溪园区访客中心 206-S越秀书院

活动流程

13:00~13:15 签到入座
13:15~13:30 开发者共创书籍《Elastic Stack 实战手册V1.0》发布
13:30~14:30 滴滴Elasticsearch内核优化之路
            韩宝君 滴滴Elasticsearch资深开发工程师/ES社区Contributor
14:30~15:30 Elasticsearch在SIEM的应用与实践
            汤乐奇 安恒信息AiLPHA大数据资深研发经理
15:30~16:30 Elasticsearch Serverless 云原生时代的创新实践
            马华标(城破) 阿里巴巴高级技术专家/阿里云ES内核研发负责人
16:30~17:20 圆桌交流
17:20~17:30 抽奖合影

活动奖品

阿里云双肩包、T恤、Elastic定制礼物

阿里云ACE

阿里云ACE即全称 Alibaba Cloud Engineer，是意为阿里云的工程师、代表着云计算的建设者。同时“ACE”又是扑克牌中的“A”，因此阿里云ACE也寓意着是云计算领域王牌的一群人。在线上，ACE拥有专属的页面和29个社群，承载论坛及专栏等内容； 在线下，ACE通过组织丰富的活动，包括技术沙龙、TechDay、Meetup、官方互动等来形成本地化的开发者的学习、社交平台。

通过ACE组织的各种活动，ACE用户可以结识本地的开发者，收获前沿知识，积累行业经验，并加深对阿里云的了解。

活动交流及杭州ACE同城会钉群

活动海报

各位社区的小伙伴们大家好！过去一年多以来，疫情阻挡了我们聚会的脚步，但阻挡不了我们 ES 技术演进的脚步，ES 中文社区前期持续举办了多期线上 meetup 活动，输出了多个高质量的技术主题分享。如今在深圳，线下 meetup 活动重磅重启！6月26日我们将在深圳腾讯滨海大厦多功能厅，和大家欢聚一堂，畅谈 ES 各个领域最新的黑科技。目前讲师招募持续进行中，欢迎各路大佬扫码报名！ 活动链接：https://www.bagevent.com/event/7440283

今天下午的《腾讯Elasticsearch海量规模背后的内核优化剖析》分享 大家反映强烈，由于时间关系，大家的问题没能及时答复，这里集中解答，大家如果还有其它疑问也可以持续提问。感谢大家的关注！ 另外腾讯云上有内核增强版的ES服务，包含了我们所有的内核优化项，欢迎大家体验！ 团队也在持续招聘，欢迎简历来砸：danielhuang@tencent.com; johngqjiang@tencent.com

1月16日 Elastic 中文社区深圳 Meetup 上，李猛将带来关于ES 实践方面的主题分享。借此机会，我们邀请到他聊聊作为ES深度用户在探索ES过程中的心得以及对ES社区、活动、未来生态发展等方面的看法。   李猛 架构师/Elastic认证工程师 Elastic Stack产品深度用户，2012/2013年接触Elasticsearch，对Elastic Stack开发、架构、运维等方面有深入体验，实践过多种ES项目，最暴力的大数据分析应用，最复杂的业务系统应用等。   Q1、作为深度用户，当初是基于什么样的动机和考量选择使用 ES 产品并持续深入探索的？ A：易用性与功能强大，个人平常比较爱好算法研究，选择任何数据产品本质上都是选择算法，算法的本质决定了产品的强大。 架构是个宏观问题，ES的设计是标准的分布式，架构的优秀设计带来的是易用性； 算法是个微观问题，ES集成了很多优秀的算法，这样在很多业务场景下都可满足，而不用更换不同的数据产品，这样也会带来产品运维方面的便利性，保障应用的技术栈不至于过多复杂。 Q2、在探索 DB 与 ES 的互通方面，有遇到什么难题吗？最后是如何解决的呢？ A：数据一致性与实时性问题。应用架构思维变化，业务调整变化与技术方案变化。 Q3、结合您的实践经历，对 ES 目前的生态发展、应用以及未来有什么样的看法？ A：ES目前主要应用是在单索引条件下查询，附带有简单的聚合分析能力。复杂的分析能力不具备，ES未来会增强复杂的分析能力，比如有条件的支持２个索引的关联分析。 Q4、您对本次技术沙龙活动的主题分享有什么期待？ A：期望更多人参加探讨更多的业务应用场景，比如传统应用方面、大数据方面、机器学习方面；帮助大家以后项目实战有更多的案例参考。 Q5、您对 Elastic 中文社区发展有什么意见或建议呢？ A：ES目前在国内的热度几乎超过任何数据库，几乎大大小小的公司，都在使用；从开始入门到成熟运用多多少少都会遇到很多问题，　　希望社区活动更加多一点，业余的交流更多一点。比如可以办一些，走进某些企业的活动。 11月16日 Elastic 中文社区深圳 Meetup 火热报名中 分享主题：《DB到ES数据实时同步之路》 李猛  主题摘要：关系型数据库天然具备最严格的事务特性，有效的保证数据库一致性，但在高效查询方面显得很无力；Elasticsearch天然具备高效的查询算法，但在数据一致性方面却是先天缺陷；如何将DB与ES的优点结合，是任何一个企业公司业务系统实践都值得探讨的事。  

近日，2023 移动云大会“数据库&云原生创新”论坛 在苏州隆重召开。现场精英荟萃、专家云集，共同探讨数据库与云原生技术发展及应用落地方案，为助力推动云原生数据库产业发展建言献策。极限科技创始人兼 CEO 曾勇受邀出席论坛。

会上，极限科技创始人兼 CEO 曾勇针对《Elasticsearch 国产化在移动云的演进之路》主题进行演讲，演讲围绕了什么是 Elasticsearch 以及 Elasticsearch 在移动云上的国产化演进过程。

Elasticsearch 在移动云的演进

随着数字化转型的不断深化，非结构化数据日益成为各类组织数据的增长主力，但其在管理和应用方面仍面临模态多样、管理复杂、检索挖掘难度大等挑战。为此，极限科技与移动云共同研发出搜索型数据库软件 Easysearch。

“Easysearch” 是极限科技在 Elasticsearch 软件原版本基础上，立足中国企业需求，助力移动云打造更符合其需求，独具 8 大特色功能的自有开源平替版本系统。-- 极限科技创始人兼 CEO 曾勇在会上介绍道

移动云版本 “Easysearch” 精简 Kernel ，只保留开源核心能力，回归轻量化；增强内核后，可更稳定可靠地支持万亿级数据规模；为进一步增强安全能力，系统支持字段内容脱敏的同时对字段级别采取权限控制；可降低灾难恢复时间，系统具备完整的备份与容灾能力，可实时切换；为更好地服务业务场景，此版本更关注搜索场景的优化；增强型中文分词，提供本地化的词库与拼音支持；增强数据压缩能力后，最高可降低 40%存储空间；信创兼容的系统，支持适配国产操作系统和 CPU 芯片。

目前 Elasticsearch 为移动云提供的后端架构，已由基于 Docker 容器的“移动云 ES v1.0”升级为基于 K8s 架构的“移动云 ES v2.0”版本。其优势可以体现在：

• 新版本更具自主可控性，应对新需求更具灵活性；
• 基于 K8s 架构的系统，能支持更大规模的集群服务；
• 在支持全链路 IPv6 和本地磁盘（IO 隔离）的基础上，实现了更优性能的升级。

Elasticsearch 在中国已有近十万+开发者，上万家企业已经在生产环境大规模运行 Elasticsearch，服务客户包括知名互联网公司及大型企事业单位，覆盖全国范围内生活消费、金融投资、娱乐学习、软件应用与安全等领域知名企业。-- 极限科技创始人兼 CEO 曾勇在会上介绍道

极限科技创始成员多来自 Elasticsearch 中国团队，深耕搜索及 Elasticsearch 十多年，且运营有国内最大的开源搜索技术社区，极限科技团队具备雄厚的技术实力和丰富的相关行业经验技术积累。

国产化替代的首选方案“Easysearch”

目前实时大数据搜索分析，尤其是结构化和非结构化数据结合的场景和需求非常大。针对海量数据，搜索技术成为核心，大多数企业都有不止部署一套搜索后端服务来满足各个场景的搜索业务需求。-- 极限科技创始人兼 CEO 曾勇在会上介绍道

Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本，并继续完善和支持更多的企业级功能。该软件衍生自开源的搜索引擎软件 Elasticsearch，具备相当的接口兼容能力，对于目前国内广大的 Elasticsearch 用户来说切换和接入的成本非常低。

与 Elasticsearch 相比，Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。基于团队在搜索和 Elasticsearch 生态的多年深耕，极限科技已具备完全自主自研可控能力，Easysearch 因更符合国产搜索技术生态需求，目前逐渐成为 Elasticsearch 国产化替代的首选方案。

作为一款具备自主可控的分布式近实时搜索型数据库产品 Easysearch 具备高性能、高可用、弹性伸缩、高安全性等特性，支持丰富的个性化搜索及聚合分析，且能承载 PB 级别的海量业务数据，可部署在物理机、虚拟机、容器、私有云和公有云，为金融核心系统、运营商、制造业和政企业务系统提供安全、稳定、可靠的快速检索和实时数据探索分析能力，满足不同业务场景的各项复杂需求。

持续丰富完善企业级服务能力

随着国内搜索型数据库的迅速发展，关键技术逐渐突破，应用场景和数据规模也逐年上升，已经成为企业必不可少的核心基础设施，产业生态日益繁荣。

截至目前，极限科技与移动云合作共建的 Easysearch 系统，已在无锡、呼和浩特、南基这 3 个城市上线，此外还有北京、上海、重庆、宁波、海南等 9 个城市的资源池正在上线中。-- 极限科技创始人兼 CEO 曾勇介绍道。

作为全球领先的近实时搜索数据库技术提供商，极限科技始终致力于搜索核心技术的研发与创新，基于国内搜索型数据库行业生态需求，在产品研发创新上，着力提升产品易用性、实时性、降低 IT 成本等，为推动国内搜索行业技术水平及相关技术社区的发展，建设数据强国提供强有力的基础技术支撑。

极限科技自成立起始终致力于提供本地化配套产品及解决方案，帮助客户解决在使用 Elasticsearch 时遇到的各种挑战。未来，极限科技将基于更多的真实客户场景提供个性化服务，持续丰富并完善更多维度、更高需求的企业级服务能力，与移动云等众多行业平台一起构建更“简单”的搜索服务。

关于极限科技

极限科技，全称极限数据（北京）科技有限公司，是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室（INFINI Labs）致力于打造极致易用的数据探索与分析体验。让搜索更简单是我们追求的目标。

极限科技是一支年轻的团队，采用天然分布式的方式来进行远程协作，员工分布在全球各地，希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选，为中国技术品牌输出添砖加瓦。

更多详情参见官网 (https://infinilabs.com) 。

本次 INFINI Labs 产品更新主要包括 Gateway v1.12.1、Console v1.0.0，其中 Console v1.0.0 是一个重要里程碑版本，该版本做了很多UI交互优化；集成了Github SSO 单点登录功能；新增了数据迁移功能，支持跨搜索引擎、跨版本的数据迁移；新增了数据看板，支持自定义可视化报表；以及修复已知Bug等。值得一提的是，Console 非常轻量级，安装包只有16MB，架构简洁，除了使用 Elasticsearch 当作数据存储外无任何外部依赖，包含监控、告警、安全、可视化分析等日常管理功能，欢迎下载使用。在线体验DEMO：https://play.infinilabs.com:64443，用户名密码 readonly/readonly。

INFINI Gateway v1.12.1

极限网关本次更新如下：

Bug fix

• Elasticsearch 修复偶现连接断开的问题。
• Elasticsearch 修复连接超时未返回错误信息的问题。

更多 Gateway 更新可参考【Gateway 版本历史】。

INFINI Console v1.0.0

Console 本次主要更新如下：

1、集成 Github 单点登录，方便快速登录，减少用户名和密码登录经常忘记带来的烦恼。详情查看教程

2、新增了工作台界面，作为 Console 登录后的入口页面，可以快速预览整个系统的集群资源概要信息、集群动态、常用功能快捷入口等。

3、新增了数据迁移功能，支持 Elasticsearch、Opensearch、Easysearch 等搜索引擎的所有版本之间相互迁移。需要搭配 最新版本极限网关（INFINI Gateway） 使用，详情查看教程

4、新增了数据看板功能，支持多标签页，支持折线图、柱状图、饼图等图表，支持用户自定义可视化数据报表，详情查看教程

5、数据探索 Discover 添加搜索关键词高亮功能。

除了以上主要功能外还做了很多优化和Bug fix，如下：

Features

• 数据迁移添加初始化索引 settings, mappings 可选步骤
• 数据迁移添加删除功能

Improvements

• 添加 Opening scroll context 监控指标
• 数据迁移分区设置优化
• 优化数据迁移错误日志和异常情况处理
• 迁移后目标集群和源集群文档数量不匹配，标记迁移任务为失败状态

Bug fix

• 修复新注册集群状态不同步更新的问题
• 修复低版本 ES 多 type 分区查询时没有根据 doctype 过滤的问题
• 修复特殊情况下迁移任务没有被释放的问题
• 修复迁移任务结束，队列磁盘文件未释放的问题
• 修复bulk写入失败导致迁移任务卡住的问题

更多 Console 更新可参考【Console 版本历史】。

期待反馈

欢迎下载体验使用，如果您在使用过程中遇到如何疑问或者问题，欢迎前往 INFINI Labs Github（https://github.com/infinilabs） 中的对应项目中提交 Feature Request 或提交 Bug。

• INFINI Gateway： https://github.com/infinilabs/gateway/issues
• INFINI Console： https://github.com/infinilabs/console/issues
• 官网： https://www.infinilabs.com
• 下载地址： https://www.infinilabs.com/download

您还可以通过邮件联系我们：hello@infini.ltd

或者拨打我们的热线电话：(+86) 400-139-9200

也欢迎大家微信扫码添加小助手（INFINI-Labs），加入用户群讨论，或者扫码加入我们的知识星球一起学习交流。

最后祝大家周末愉快！

关于极限科技（INFINI Labs）

极限科技，全称极限数据（北京）科技有限公司，是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室（INFINI Labs）致力于打造极致易用的数据探索与分析体验。

极限科技是一支年轻的团队，采用天然分布式的方式来进行远程协作，员工分布在全球各地，希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选，为中国技术品牌输出添砖加瓦。

Web Scraper + Elasticsearch + Kibana + SearchKit 打造的豆瓣电影top250 搜索演示系统

作者：小森同学

声明：电影数据来源于“豆瓣电影”，如有侵权，请联系删除

Web Scraper

{
    "_id": "top250",
    "startUrl": ["https://movie.douban.com/top250?start=[0-225:25]&filter="],
    "selectors": [{
        "id": "container",
        "multiple": true,
        "parentSelectors": ["_root"],
        "selector": ".grid_view li",
        "type": "SelectorElement"
    }, {
        "id": "name",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "",
        "selector": "span.title:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "number",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "",
        "selector": "em",
        "type": "SelectorText"
    }, {
        "id": "score",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "",
        "selector": "span.rating_num",
        "type": "SelectorText"
    }, {
        "id": "review",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "",
        "selector": "span.inq",
        "type": "SelectorText"
    }, {
        "id": "year",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "\\d{4}",
        "selector": "p:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "tour_guide",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "^导演: \\S*",
        "selector": "p:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "type",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "[^/]+$",
        "selector": "p:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "area",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "[^\\/]+(?=\\/[^\\/]*$)",
        "selector": "p:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "detail_link",
        "multiple": false,
        "parentSelectors": ["container"],
        "selector": ".hd a",
        "type": "SelectorLink"
    }, {
        "id": "director",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "",
        "selector": "span:nth-of-type(1) .attrs a",
        "type": "SelectorText"
    }, {
        "id": "screenwriter",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "(?<=编剧: )[\\u4e00-\\u9fa5A-Za-z0-9/()\\·\\s]+(?=主演)",
        "selector": "div#info",
        "type": "SelectorText"
    }, {
        "id": "film_length",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "\\d+",
        "selector": "span[property='v:runtime']",
        "type": "SelectorText"
    }, {
        "id": "IMDb",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "(?<=[IMDb:\\s+])\\S*(?=\\d*$)",
        "selector": "div#info",
        "type": "SelectorText"
    }, {
        "id": "language",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "(?<=语言: )\\S+",
        "selector": "div#info",
        "type": "SelectorText"
    }, {
        "id": "alias",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "(?<=又名: )[\\u4e00-\\u9fa5A-Za-z0-9/()\\s]+(?=IMDb)",
        "selector": "div#info",
        "type": "SelectorText"
    }, {
        "id": "pic",
        "multiple": false,
        "parentSelectors": ["container"],
        "selector": "img",
        "type": "SelectorImage"
    }]
}

elasticsearch

{
    "mappings": {
      "properties": {
        "IMDb": {
          "type": "keyword",
          "copy_to": [
            "all"
          ]
        },
        "alias": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "all": {
          "type": "text",
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "area": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "director": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "film_length": {
          "type": "long"
        },
        "id": {
          "type": "keyword"
        },
        "language": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "link": {
          "type": "keyword"
        },
        "name": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "number": {
          "type": "long"
        },
        "photo": {
          "type": "keyword"
        },
        "review": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "score": {
          "type": "double"
        },
        "screenwriter": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "type": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "year": {
          "type": "long"
        }
      }
    }
  }

kibana

需要使用pipeline对索引字段进行处理，如对type 通过空格进行分割为数组等，可以参照官方文档或其他博客。

制作仪表板省略, 请自行搜索

SearchKit

参考 https://github.com/searchkit/searchkit-starter-app

岗位职责： 1. 参与ElasticSearch平台建设，赋能公司业务。 2. 参与ElasticSearch的集群管理维护与业务支持。 任职要求： 1. 编程能力扎实，熟练Java编程，具有良好的数据结构和算法的基本知识 2. 熟悉Elasticsearch架构和DSL 3. 熟悉倒排索引、中文分词排序等相关技术 4. 熟悉搜索引擎相关知识，如：建模、分词、索引、关联词等 5. 熟悉MySQL、java框架和组件(SpringMVC/SpringBoot/MyBatis) 6. 具有良好的沟通能力、职业稳定性，工作积极主动，学习能力强 加分项： 拥有ES集群运维经验，并优化, 对集群备份有研究 月薪18~23k，工作地点在上海杨浦，五险一金，法定节假日 不出差，双休日基本不加班，工作日最多加班到8点，工作氛围不鸡血 有兴趣的请发简历到邮箱： 876451600#qq.com VX： wowcat60

会议信息同步

1. 关于讲师议题：少部分讲师和议题有变化，组委会近期会与讲师沟通确认是否需要更换新的演讲议题。
2. 已经报名参会者无需再次报名。

其他说明

1. 目前大会报名购票通道已重新开启，欢迎推荐有兴趣的朋友报名参会，可享受八折购票优惠，折扣报名链接：https://www.bagevent.com/event/7899116?discountCode=80OFF
2. 由于部分议题陈旧，我们重新开放了演讲议题申请，欢迎大家提交和推荐。议题提交链接：http://elasticsearch.mikecrm.com/2gQNDKh
3. 赞助合作申请：http://elasticsearch.mikecrm.com/6gxTHs4
4. 如需要加入大会微信交流群，请加微信(lsy965145175)拉群。
5. 更多大会信息请关注官网：https://conf.elasticsearch.cn

感谢

这次的 Elastic 中国开发者大会虽然遇到了很多的困难与波折，但因为您们的理解和支持，一直鼓励着我们，给了我们信心与动力，我们会本着办好中国开发者大会的初心继续前行，再次感谢大家的大力支持！

在2023年新春到来之际，Elastic 中国开发者大会组委会祝大家新春快乐、身体健康、工作顺利、阖家幸福！

背景

1.ES PAAS管理的集群升级了100+，从7.5升级到7.17 （保证每个大版本最终仅维护一个小版本集群）

2.由于业务使用差异大，也出了不少问题，前面的文章也有提到过Integer类型字段使用terms查询效率低的情况

3.这里再分析一个CPU、IO飙升的场景

现象

1.用户报障：“ES集群写入吞吐量变小了”

2.观察下来发现确实CPU高了，IO也有明显抖动

排查与分析

1.发现YoungGC频率变高了一些，猜测可能是G1GC的问题（我们使用JDK11重新打了ES镜像），经过版本替换，没有明显变化。

参考issue：https://github.com/elastic/elasticsearch/pull/46169

这可能是另一个场景的case，经过测试，不属于我们的场景。

2.多次执行hot_threads API观察， 发现时不时会出现 update相关函数 消耗的 CPU多。

3.继续使用arthas抓取一段时间的数据，发现是 FST、DocID 读取慢

从图中可以看到Bulk请求执行过程中的getDocID方法占有大量CPU。

4.集群写多读少，使用的是niofs。可知，7.5版本的FST是在堆外，但是_id字段是在堆内。升级到7.17版本后，FST在堆外，该字段也放到了堆外（官方版本应该是7.9就开始放到堆外了）。数据放到堆外，其实也就是文件放到磁盘，读一次之后放到pagecache。

这样也就可以解释了，在upsert类请求多的时候会频繁查询docId，此时如果_id字段没有进入pageCache或者被踢出pageCache，那么就会出现响应慢，并且CPU高、IO高的情况。

5.mmapfs、hybridfs实测是什么情况暂时不明确，目前没有收到搜索类集群CPU、IO方面的报障。

测试验证

将FST、BKD等全部改成放到堆内（开源版需要改造）

可以看到，CPU有显著下降，也相对均衡。（之前蓝色线高，是因为该节点有大量的主分片）

结论

1.update、upsert、get等请求如果十分频繁，_id使用offheap将不会是个好的选择，除非给足够的堆外内存，并且保证尽可能常驻内存。

2.不同的业务场景下使用ES的同一版本也会有不一样的效果。

3.mmapfs、hybridfs在频繁update情况下，实测是什么情况暂时不明确，目前没有收到搜索类集群CPU、IO方面的报障，可能不会有这么明显的差距。（官方描述写入速度仅降低了1.8%）

4.最后吐槽一下，写入不停的情况下，translog的恢复实在是太慢了，由于大分片恢复/rebalance时，translog不会被清理，导致恢复/迁移速度急剧下降...目前各个版本也没什么好的解决方式。

背景

1.对于7版本（大版本）集群希望只维护一个版本，最终选择7.17，对同大版本的7.5版本集群进行升级

2.根据官方描述，_id放到堆外性能损失非常小可以忽略，且对BKD进行了优化

3.升级完成，一段时间之后，收到用户报障

4.抽样检查了下部分升级的集群，其中部分受到影响，部分不受影响。且每个集群内存均有一定优化（预期内）

调查&分析

1.发现is_deleted文档特别多，怀疑是7.17版本对于碎片过于敏感。做forcemerge，没什么效果。

2.GET _nodes/hot_threads 查看耗时部分，结果展示笼统，没得到关键信息。

3.给语句加上profile，查看耗时部分。

GET index-v1/_search
{"profile":"true","query":{"bool":{"filter":[{"term":{"xid":{"value":"11111111","boost":1.0}}},{"terms":{"status":[2,3,4],"boost":1.0}},{"terms":{"platform":["aaa","bbb"],"boost":1.0}},{"terms":{"pId":[1,2],"boost":1.0}}],"adjust_pure_negative":true,"boost":1.0}},"sort":[{"time":{"order":"desc"}}]}

从脱敏的简化结果中可以看出来，主要是 status、pId 字段耗时高，这两个字段都是integer类型，并且使用了terms查询。

{
  "took": 554,
  "timed_out": false,
  "_shards": {
    "total": 3,
    "successful": 3,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 5,
      "relation": "eq"
    },
    "max_score": null,
    "hits": [
      ...
    ]
  },
  "profile": {
    "shards": [
      {
        "id": "[APxxxxxxxxxxxxxxQ][index-v1][0]",
        "searches": [
          {
            "query": [
              {
                "type": "BooleanQuery",
                "description": "#xid:111111111 #status:{2 3 4} #ConstantScore(platform:aaa platform:bbb) #pId:{1 2}",
                "time_in_nanos": 415205306,
                "breakdown": {
                  ...
                  "build_scorer": 415028271
                },
                "children": [
                  {
                    "type": "TermQuery",
                    "description": "xid:111111111",
                    "time_in_nanos": 102656,
                    "breakdown": {
                      .....
                      "build_scorer": 86264
                    }
                  },
                  {
                    "type": "PointInSetQuery",
                    "description": "status:{2 3 4}",
                    "time_in_nanos": 220394978,
                    "breakdown": {
                      ....
                      "build_scorer": 220385119
                    }
                  },
                  {
                    "type": "ConstantScoreQuery",
                    "description": "ConstantScore(platform:aaa platform:bbb)",
                    "time_in_nanos": 341845,
                    "breakdown": {
                      .....
                      "build_scorer": 282277
                    },
                    "children": [
                      {
                        "type": "BooleanQuery",
                        "description": "platform:aaa platform:bbb",
                        "time_in_nanos": 329042,
                        "breakdown": {
                          .....
                          "build_scorer": 277752
                        },
                        "children": [
                          {
                            "type": "TermQuery",
                            "description": "platform:aaa",
                            "time_in_nanos": 62446,
                            "breakdown": {
                              .....
                              "build_scorer": 37931
                            }
                          },
                          {
                            "type": "TermQuery",
                            "description": "platform:bbb",
                            "time_in_nanos": 15093,
                            "breakdown": {
                              .....
                              "build_scorer": 6981
                            }
                          }
                        ]
                      }
                    ]
                  },
                  {
                    "type": "PointInSetQuery",
                    "description": "pId:{1 2}",
                    "time_in_nanos": 194164297,
                    "breakdown": {
                      ....
                      "build_scorer": 194160452
                    }
                  }
                ]
              }
            ],
            "rewrite_time": 40044,
            "collector": [
              {
                "name": "SimpleFieldCollector",
                "reason": "search_top_hits",
                "time_in_nanos": 144012
              }
            ]
          }
        ]

4.单个的profile无法说明问题，进一步排查：使用arthas工具获取一段时间内的火焰图

可以看到主要就是BKD数据结构占用的CPU。

5.参考官方论坛相似问题：https://discuss.elastic.co/t/very-slow-search-performance-after-upgrade-to-7-16-1/296152/3

6.integer类型的terms查询性能较差，看起来官方描述的BKD相关优化指的是range

7.测试验证，将字段改成keyword，查看结果，CPU查询耗时恢复到正常范围

今天 INFINI Labs 为大家又带来了一波产品更新，请查阅。

INFINI Gateway v1.8.0

极限网关本次迭代更新如下：

• 修复上下文条件 consumer_has_lag参数和 配置、文档不一致的 Bug。
• 修改备集群故障，主集群不能正常写数据的 Bug。
• 修复 Bulk 请求处理异常造成数据复制不一致的问题。
• 修复请求日志里面关于 Bulk 统计数据丢失的问题。
• 修复大并发情况下，请求体为空的异常。

INFINI Console v0.6.0

口碑爆棚的 Elasticsearch 多集群管控平台 INFINI Console 更新如下：

• 新增主机概览。

• 新增主机监控。

• 节点概览新增日志查看功能（需安装 Agent）。

• Insight 配置框新增 Search 配置。
• 优化 Discover 时间范围 Auto Fit，设为15分钟。
• 优化 Discover 保存搜索，会保存当前的字段过滤和 Insight 图表配置。
• 优化本地列表搜索查找，支持通配符过滤。
• 优化告警规则必填字段标记显示。
• 修复了 Discover 字段过滤白屏问题。
• 修复了 Discover 表格添加字段后排序失效问题。(感谢@卢宝贤反馈)
• 修复了 Elasticsearch 8.x 删除文档报错不兼容的问题。(感谢@卢宝贤反馈)
• 修复了创建新索引不成功时，异常处理的问题。
• 修复了低版本浏览器js不兼容导致集群注册不成功的问题。
• 修复了开发工具中使用加载命令失败报错的问题。

INFINI Agent v0.2.0

数据采集工具探针（INFINI Agent）更新如下：

• 新增按节点读日志文件列表的API
• 新增读具体日志文件内容的API
• 新增 Elasticsearch 节点掉线后的基础信息保存
• 新增主机在线状态的采集
• 新增基于 Centos 的 Docker 镜像
• 新增主机配置信息采集: 操作系统信息、磁盘大小、内存大小、CPU配置等
• 新增主机指标的采集: CPU使用率、磁盘使用率、磁盘IO、内存使用率、swap 使用率、网络IO等
• 新增 Elasticsearch 进程信息采集
• 修复发现 Elasticsearch 进程时频繁提示端口访问错误的Bug
• 修复 Elasticsearch 节点地址为 0.0.0.0 时无法获取节点信息的Bug
• 修复 CPU 指标数据显示异常的Bug
• 修复 stats API 在 Windows 平台的兼容性

INFINI Framework 2000923

INFINI Framework 也带来了很多改进：

• 重构了磁盘队列压缩相关配置，支持段文件的压缩。
• 当集群不可用的情况下，跳过集群节点元数据的获取。
• 完善节点可用性检测，避免频繁的不可用状态切换。
• 修复 Elasticsearch 主机地址为空的异常。
• 完善本地磁盘队列文件的清理，避免删除正在使用的文件。

期待反馈

如果您在使用过程中遇到如何疑问或者问题，欢迎前往 INFINI Labs Github（https://github.com/infinilabs）中的对应项目中提交 Feature Request 或提交 Bug。

• INFINI Gateway： https://github.com/infinilabs/gateway
• INFINI Console： https://github.com/infinilabs/console/issues
• 下载地址： https://www.infinilabs.com/#/download

您还可以通过邮件联系我们：hello@infini.ltd

或者拨打我们的热线电话：(+86) 400-139-9200

也欢迎大家微信扫码添加小助手，加入用户群讨论，或者扫码加入我们的知识星球一起学习交流。

感谢大家的围观，祝大家周末愉快。

本文将为你介绍 Apache APISIX 的 elasticsearch-logger 插件的相关信息，以及如何通过此插件获取 APISIX 的实时日志。

背景信息

Apache APISIX 是一个动态、实时、高性能的 API 网关，提供了负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。作为 API 网关，Apache APISIX 不仅拥有丰富的插件，而且支持插件的热加载。

Elasticsearch 是一个基于 Lucene 库的搜索引擎。它提供了分布式、RESTful 风格的搜索和数据分析引擎，具有可扩展性、可分布式部署和可进行相关度搜索等特点，能够解决不断涌现出的各种用例。同时还可以集中存储用户数据，帮助用户发现意料之中以及意料之外的情况。

插件介绍

APISIX 以 HTTP 请求的方式向 Elasticsearch 发送 APISIX 的 Runtime 日志。插件 elasticsearch-logger 采用 bulk 的格式进行日志上报，这允许 APISIX 可以将多条日志合并后再进行上报，这使得 APISIX 在对 Elasticsearch 进行日志上报方面更加灵活并且具有较好的性能。你可以参考文档 APISIX 批处理器 对日志合进行更加细致的配置。

配置步骤

首先，你需要安装完成 APISIX，本文所有步骤基于 Centos 7.5 系统进行。详细的安装步骤参考 APISIX 安装指南。

步骤1：启动 Elasticsearch

本示例只演示了通过 docker-compose 启动 Elasticsearch 单节点的方式，其它启动方式可参考 Elasticsearch 官方文档。

# 使用 docker-compose 启动 1 个 Elasticsearch 节点, 1 个 kibana
version: '3.8'
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.1
    container_name: elasticsearch
    environment:
      ES_JAVA_OPTS: -Xms512m -Xmx512m
      discovery.type: single-node
      xpack.security.enabled: 'false'
    networks:
      - es-net
    ports:
      - "9200:9200"
      - "9300:9300"

  kibana:
    image: docker.elastic.co/kibana/kibana:7.17.1
    container_name: kibana
    environment:
      ELASTICSEARCH_HOSTS: http://elasticsearch:9200
      I18N_LOCALE: zh-CN
    networks:
      - es-net
    depends_on:
      - elasticsearch
    ports:
      - "5601:5601"

networks:
  es-net:
    driver: bridge

步骤2：创建路由并配置插件

APISIX 默认配置文件中已启用 elasticsearch-logger 插件，所以你只需要通过下方命令创建路由并配置 elasticsearch-logger 插件就可以在 APISIX 中正常使用了。

curl http://127.0.0.1:9180/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins":{
        "elasticsearch-logger":{
            "endpoint_addr":"http://127.0.0.1:9200",
            "field":{
                "index":"services",
                "type":"collector"
            },
            "ssl_verify":false,
            "retry_delay":1,
            "buffer_duration":60,
            "max_retry_count":0,
            "batch_max_size":1000,
            "inactive_timeout":5,
            "name":"elasticsearch-logger"
        }
    },
    "upstream":{
        "type":"roundrobin",
        "nodes":{
            "127.0.0.1:1980":1
        }
    },
    "uri":"/elasticsearch.do"
}'

上述代码中配置了 Elasticsearch 地址、目标 field，用户名与密码。

通过上述设置，就可以实现将 /elasticsearch.do 路径的 API 请求日志发送至 Elasticsearch 的功能。

步骤3：发送请求

接下来我们通过 API 发送一些请求。

curl -i http://127.0.0.1:9080/elasticsearch.do\?q\=hello
HTTP/1.1 200 OK
...
hello, world

此时你可以登录 Kibana 控制台检索查看相关日志：

自定义日志结构

当然，在使用过程中我们也可以通过 elasticsearch-logger 插件提供的元数据配置，来设置发送至 Elasticsearch 的日志数据结构。通过设置 log_format 数据，可以控制发送的数据类型。

比如以下数据中的 $host、$time_iso8601 等，都是来自于 NGINX 提供的内置变量；也支持如 $route_id 和 $service_id 等 Apache APISIX 提供的变量配置。

curl http://127.0.0.1:9180/apisix/admin/plugin_metadata/elasticsearch-logger \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "log_format": {
        "host": "$host",
        "@timestamp": "$time_iso8601",
        "client_ip": "$remote_addr"
    }
}'

通过发送请求进行简单测试，可以看到上述日志结构设置已生效。目前 Apache APISIX 提供多种日志格式模板，在配置上具有极大的灵活性，更多日志格式细节可参考 Apache APISIX 官方文档。

此时你可以登录 Kibana 控制台检索查看相关自定义日志：

如需关闭自定义日志结构，可参考下方操作。

curl http://127.0.0.1:9180/apisix/admin/plugin_metadata/elasticsearch-logger \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X DELETE

此时，插件 elasticsearch-logger 将使用默认格式上报日志。

关闭插件

如使用完毕，只需移除路由配置中 elasticsearch-logger 插件相关的配置并保存，即可关闭路由上的插件。得益于 Apache APISIX 的动态化优势，开启和关闭插件的过程都不需要重启 Apache APISIX。

curl http://127.0.0.1:9080/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "methods": ["GET"],
    "uri": "/hello",
    "plugins": {},
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1
        }
    }
}'

总结

本文为大家介绍了关于 elasticsearch-logger 插件的功能与使用步骤，更多关于 elasticsearch-logger 插件说明和完整配置列表，可以参考官方文档。

也欢迎随时在 GitHub Discussions 中发起讨论，或通过邮件列表进行交流。

背景

Elasticsearch CPU很高的场景很常见，优化读写以及扩容即可解决问题。

如果只有一个节点CPU高，那可能的情况就比较多了，节点机器异常？读写不均匀？GC过高？forcemerge？

这里描述一个极具迷惑性的case。

问题

收到用户报障碍，突然有写入被reject，并且有一个节点的CPU突然增高。

分析、验证与结论

1.常用套路，先大致了解集群、索引。

集群层面：6.8.5 版本，18个节点（冷热分离）

索引层面：近3000个索引，大多数小索引（mb、1～10gb级别），template（设置1主分片、1副本分片）

用户行为：写多读少的OLAP场景

2.检查节点（pod）监控、宿主机监控、ES集群监控。没有很明显的异常行为。只能观测到异常节点CPU高、出现reject。用户的读写流量也没有观测到明显变化。

3.集群GC、merge等行为都很正常，并且只有一个节点CPU高（刚好用户索引都是1主1副），开始认为和热点相关。可能是某个索引的读写导致了节点CPU的上升。

4.使用 GET _nodes/hot_threads 查看CPU使用情况，果然抓到了异常节点占用CPU的主要是 write 线程。

5.由于hot_threads只能抓取瞬时的数据，不一定准确。准备进入容器，使用arthas工具抓取perf信息（arthas是阿里的开源工具、已经被我们集成到ES镜像里）。

通过arthas简要的获取热点线程：可以看到主要是write线程在执行bulk请求，然后还有日志打印的堆栈。

继续抓取2min内的统计信息：可以看到主要是search在使用CPU。和之前获取的信息不符。

6.分析到底是读还是写影响的CPU。

a.如果是写热点导致，应该会有2个节点CPU高；

b.写入一般很难长时间打高CPU，而一个拉全量/大量数据的大请求很可能拉高CPU，由于index设置1主1副本，刚好可以解释只有一个节点CPU高；

c.考虑到抓取的数据perf结果，2min内的抓取结果比瞬时的可信；

综合来看，大查询导致的CPU高的概率很大。

7.继续走排障流程，查看日志信息

看到异常节点日志里大多都是这类异常。

elasticsearch org.apache.logging.log4j.core.appender.AppenderLoggingException: Error writing to stream /usr/share/elasticsearch/logs/e100024741.log org.apache.logging.log4j.core.appender.AppenderLoggingException: Error writing to stream....

由于节点已经跑了很长时间，log盘写满也是有可能的，而且不太可能瞬间拉高CPU，暂时忽略。

8.进一步验证，将异常节点重启。

果然异常节点CPU下去了，另一个节点CPU起来了，进一步证明了是查询导致的，1主1副的case下，一个节点挂了，另一个承载流量。

继续观察异常节点的流量：outgoing的流量比较高，又进一步佐证了是查询带来的异常。

继续查看IO，write/read都相对比较高。

9.考虑到查询无法被阻断、且该节点异常带来的影响并不大，准备等“拉数据的大请求”执行完毕自动恢复。

10.开始关注其他问题。等待一段时间，发现依然没有恢复，且CPU完全没有下降的趋势。考虑到一个大请求不会执行这么长时间，如果多个大请求，至少reject、cpu曲线会有些波动，不会如此稳定。准备继续排查。再次执行多次hot_thread API，依然有很多次都只抓到了write线程占用大量CPU，如果大请求存在，不会一直抓不到search请求。

11.考虑其他思路。找到重启前异常节点和重启异常节点后才异常的节点共有的index（互为主备），在众多index中发现了一个较大的index（800G）。看了下文档数：2147483519，至此，找到了问题的答案。

12.结论：使用了同一template的大量索引（1 primary 1 replica），存在一个index写了大量doc数，超过了lucene的最大限制（integer的最大值），疯狂报错reject，并且记录大量异常日志，日志不断的rotate、清理造成了CPU的大幅上升。

仔细检查异常开始时间节点的日志，可以发现如下异常信息：

[2022-07-22T12:00:36,376][DEBUG][o.e.a.b.TransportShardBulkAction] [e100024741-es-default-1][cp0006014_2022_07][0] failed to execute bulk item (index) index {[cp0006014_2022_07][event_cp][Ir_HJYIBi3-VIQ2V8GIT], source[{"rowkey":"fff5e48f-13d9-4f68-b9c9-8cfc1f0fefa3","column01":"BatchValidateRecevieCouponRealTime","column02":"1","column03":"289358095","column04":"100009826","column05":"nkryj","column06":"32001052810269459246","column08":"fff5e48f-13d9-4f68-b9c9-8cfc1f0fefa3","column09":"[34m~L[34m~A34m~O~Q34m~H[34m~D34m| "column11":"2022-07-22 20:00:29.703","column12":"1","column20":"0","datachangelasttime":1658491229707,"rules":[],"rulesh":[],"scenes":[]}]}
java.lang.IllegalArgumentException: number of documents in the index cannot exceed 2147483519
        at org.apache.lucene.index.DocumentsWriterPerThread.reserveOneDoc(DocumentsWriterPerThread.java:226) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:235) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:494) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1616) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1235) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.elasticsearch.index.engine.InternalEngine.addDocs(InternalEngine.java:1175) ~[elasticsearch-6.8.5.jar:6.8.5]
        at org.elasticsearch.index.engine.InternalEngine.indexIntoLucene(InternalEngine.java:1120) ~[elasticsearch-6.8.5.jar:6.8.5]

进一步验证：进入容器清理日志文件，会立刻生成并rotate出多个日志文件。

最终处理：清理掉异常索引立刻恢复正常：

解释前面的坑

1.arthas采集2min内的CPU信息，得到的search结论是正确的，该集群确实存在search大请求。虽然频率不高，但是采集到的概率很大。

2.异常节点的out流量很大。这个逻辑也是正确的，只是并不是导致异常的根本原因。

确实有拉数据的请求存在；节点存在大量索引的分片，无法确认流量来源是否是其他index；该异常情况下用户收到异常ack之后会有重试，影响到流量的统计。

3.重启后另一个节点CPU就开始激增，是因为副本分片成为了主分片，然后开始reject，并疯狂打印日志、进行rotate和清理。

4.为什么只有一个节点CPU高。写入流程是主分片写入成功后，异步转发请求给所有副本（此处只有1），由于主分片写入失败，直接异常，副本也就不会受到影响。

思考

1.经验流大多情况有效，有时却不可取。时刻根据事实排障，避免先入为主。

2.相似的现象以及采集排障数据的巧合进入思维误区，集群业务复杂度增加了排障难度：

大量的日志难以查找（被AppenderLoggingException淹没），且都被判定为和本次异常无关，如 bulk reject 被认为是CPU高的场景下正常的表现，AppenderLoggingException 被认为无法快速消耗CPU，number of documents in the index cannot exceed 2147483519 刚看到时也被认为无法导致CPU增高（仅仅是无法写入）；

index太多，无法从单个index层面获取更多信息。（没有明确目标的情况下难以发现那一个异常index）。

3.arthas write线程的堆栈信息中有体现，bulk之后就在打印日志，这两点之间的关联被忽略。

4.优化方向：需要更细粒度的监控和巡检能力，快速发现异常index可大大加快排障进程，不再强依赖OPS的知识体系与推理。

INFINI Console v0.3 正式发布

极限实验室上新啦，期待已久的 INFINI Console 最新的 0.3 版本正式发布！

01 产品名称的变化

还记得最开始的极限数据平台么，现在已经升级成为 INFINI Console 了。

与极限实验室的其它产品保持一致，家族 Logo 一览如下：

接下来，将为大家隆重介绍一下本次产品更新都有哪些亮点吧。

02 统一的监控

作为目前最方便的 Elasticsearch 管理工具，跨版本、跨集群的监控自然是必不可少的一个基础能力啦。

除了使用方便，颜值自然也是高高的，多套集群的监控终于在一起了。

INFINI Console 提供了市面上最全面的各项统计指标的监控，帮助您快速掌握集群内部运行状态，快速定位集群问题，提高诊断效率，缩短故障时间。

03 统一的安全

相信您的 Elasticsearch 集群不止一个，INFINI Console v0.3 新增了平台级统一的安全管控能力。

多个集群可以统一实现基于角色的用户权限管理，数据和 UI 的权限也可以分别进行设置，可以做到不同的部门看到的集群各不一样，不同的人员看到的索引各不一样，不同的角色读写权限各不一样。

在一个平台里面统一的进行管理，再也不用割裂的维护 N 套安全配置了。

04 统一的告警

平台层的监控还是空白么？还在一套集群一套集群的配置告警规则么？Elasticsearch 内的业务数据还在被动响应么？

INFINI Console v0.3 新增了强大的告警规则引擎，通过配置告警规则，将业务关注点自动化、流程化、主动化，引擎支持常见的统计函数，使用起来简单且灵活，支持 Webhook 方式灵活对接钉钉、微信、Slack 或是内部通知系统。

只要是在 Elasticsearch 的数据，都可以借助告警引擎“活”起来。

05 统一的探索

还在不同 Kibana 之间来回跳转么？还在傻傻创建 IndexPattern 才能分析数据么？

拒绝复杂，回归简单，INFINI Console 新增了跨集群的数据探索功能，不需要提前创建 IndexPattern，想要探索数据一键直达，切换不同集群、切换不同索引、切换不同时间维度，都只在一步完成。

让数据分析和探索的体验尽可能简单是我们努力在做的事情。

06 更多细节

当然本次更新也新增了不少细节特性和修复了不少 Bug，具体的细节请访问产品的 Release Notes 页面：

• http://console.infinilabs.com/zh/docs/release-notes/

欢迎大家下载体验，下载安装及文档地址：

• http://console.infinilabs.com/

背景

1.有个向量搜索相关需求，选择使用ES8版本，并且在k8s环境中容器化部署； 2.考虑核心程度以及成本问题，不需要准备多数据中心的备份集群，为了保证数据可靠性，预期使用snapshot备份能力；

选型

ES支持将snapshot存储到各种存储产品，例如 fs(本地)、S3（或者ceph）、hdfs等。 1.OSS，考虑到已经和阿里云OSS有合作，且支持S3接口 -----> 测试 2.ceph，私有云部署，不好控制容量，成本偏高 --------> 暂不考虑 3.hdfs，私有云部署，不好控制容量，成本偏高，需要安装插件 -----> 暂不考虑 4.fs，本地，由于团队还在做juicefs产品，可以juicefs挂载到本地目录，ES snapshot 存到本地目录即可完成上传到公有云OSS ------> 测试

snapshot直接从ES传到OSS

1.创建账号、bucket，获取ak/sk；

略

2.ES容器实例如何加载密钥库

通过官方文档可知需要执行如下命令：将密钥设置到ES密钥库 https://www.elastic.co/guide/en/elasticsearch/reference/current/repository-s3.html

bin/elasticsearch-keystore add s3.client.default.access_key
bin/elasticsearch-keystore add s3.client.default.secret_key

考虑到容器环境不允许直接进入pod执行命令，secret也不允许直接写死到镜像中，则需要在entrypoint.sh中设置完成该命令。 最终方案如下：

1.在k8s环境中创建secret，记录ak/sk信息 2.pod创建时候mount到指定目录 3.container（ES）启动的时候读取指定目录信息，并执行elasticsearch-keystore命令

3.具体操作

0.安装 repository-s3 插件 略（ES8版本内置了该插件，无需安装）

1.创建secret

kubectl apply -f secret.yml

# cat secret.yml
apiVersion: v1
kind: Secret
metadata:
  namespace: uat-es
  name: es-snapshot-oss-secret
type: Opaque
data:
  access_key: xxx(注意base64编码)
  secret_key: xxx(注意base64编码)

2.修改crd的yaml，将该secret mount到指定目录

# 定义secret
  volumes:  
  - name: "oss-secret"
    secret: 
      secretName: "es-snapshot-oss-secret"

# 指定容器挂载选项
containers:
    ...
  volumeMounts:
  - mountPath: "/mnt/secret/oss"
    name: "oss-secret"
    readOnly: true

3.镜像修改 注：Dockerfile中最后是通过docker-entrypoint.sh完成ES实例的启动 ENTRYPOINT ["/usr/local/bin/docker-entrypoint.sh"]

# docker-entrypoint.sh 增加如下内容
/usr/share/elasticsearch/bin/elasticsearch-keystore create
chown root:root /usr/share/elasticsearch/config/elasticsearch.keystore
echo "$(</mnt/secret/oss/access_key)" | /usr/share/elasticsearch/bin/elasticsearch-keystore add --stdin s3.client.default.access_key
echo "$(</mnt/secret/oss/secret_key)" | /usr/share/elasticsearch/bin/elasticsearch-keystore add --stdin s3.client.default.secret_key
chown elasticsearch:elasticsearch /usr/share/elasticsearch/config/elasticsearch.keystore

1.可以看到先执行了 bin/elasticsearch-keystore create 命令，因为发行版的ES中config目录并没有elasticsearch.keystore文件，需要通过 bin/elasticsearch-keystore create 命令生成密钥库（即 config/elasticsearch.keystore 文件）；

注：如果不create，可以发现pod中最后也会生成密钥库，并且含有一个 seed 的密钥信息。该部分是ES启动时创建的，所以在启动之前必须create，否则执行bin/elasticsearch-keystore add 会触发一个密钥库不存在的异常； 2.可以看到先通过 chown root:root xxx 命令将config/elasticsearch.keystore文件的用户和group都设置成了root，执行完成命令后将其改回elasticsearch，因为bin/elasticsearch-keystore命令执行时对密钥库的权限有要求，pod启动是root用户，所以必须将该文件改成root权限，后续改成elasticsearch用户是为了保证container（ES）启动时的权限，ES的启动是使用elasticsearch用户； 注：该方式是在ES启动之前先将密钥加载到密钥库，ES提供另一个方式，允许在ES启动后执行 elasticsearch-keystore add 命令后再 reload，也能生效，这里不讨论。

4.测试创建repository、snapshot命令

# 创建repository
# 注：对象存储OSS不允许出现对象name中带 “/” ，所以 base_path 中 “-” 表示层级
PUT _snapshot/zmc_test_oss_repository
{
  "type": "s3",
  "settings": {
    "bucket": "es-snapshot",
    "endpoint": "http://dataplatform.xxxx.com",
    "base_path":"user-elasticsearch-uat-1067"
  }
}

# 创建snapshot
PUT /_snapshot/zmc_test_oss_repository/snapshot_1?wait_for_completion=true
{
  "indices": "zmc",
  "ignore_unavailable": true,
  "include_global_state": false,
  "metadata": {
    "taken_by": "zmc",
    "taken_because": "backup test"
  }
}
# 该命令异常：
amazon_s3_exception: Aws MultiChunkedEncoding is not supported. (Service: Amazon S3; Status Code: 400; Error Code: NotImplemented; Request ID: xxxxx; S3 Extended Request ID: es-snapshot.dataplatform.xxx.com

5.测试结果

很不幸，OSS暂时不支持MultiChunkedEncoding；（和OSS同学沟通后发现是 主集群暂时不支持，海外小集群已经支持该接口，后续会推到主集群） 这条路无法走通，继续测试其他方案；

snapshot存本地后通过juicefs上传OSS

juicefs是一个分布式文件系统，简言之就是通过juicefs程序可以将远程对象存储与本地目录关联，将文件写入本地即可上传到对象存储。该产品对ES而言比较适合作为snapshot的存储以及ES冷热分离架构中的冷数据存储。 juicefs有一定的维护成本，这里仅提供一种snapshot备份设计的新思路。对ES8而言更简要的方案可以考虑hdfs、ceph以及亚马逊的s3对象存储，弊端主要在成本和容量规划，体量较小或者公司支持较好则可以忽略。

预期架构如下：

可以看到从使用层面看ES只需将snapshot存在本地目录即可完成上公有云操作； juicefs部分只需从运维层面考虑，将进程打到镜像中、或者通过CSI、静态PVC的方式均可实现。图中元数据引擎是juicefs架构中的一环，从ES使用的角度看可以忽略； 此处juicefs可以替换成任何分布式共享存储。 ----------------------------end---------------------------------

你是否遇到过新搭建一个 Elasticsearch 集群，但是却无法评估该集群的最大吞吐是多少，或者使用一些压测工具，比如 esrally，需要花费很大力气准备，但是却无法压测到极限速度，服务器资源跑不满，或者测试产生的数据和实际的业务有很多出入，又或者测试的请求太简单，比如查询，就是对单个固定的搜索请求进行查询，不仅测不准还可能浪费时间没有参考意义，so，有没有一个简单的工具可以支持灵活的自定义压测，并且足够快，答案是 Loadgen。

Loadgen

Elasticsearch 压测工具 Loadgen ，由极限实验室出品，基于 Elasticsearch 的开发运维需求而开发，久经实际客户环境的真实考验，简单好用速度快。

一个没有经过压测的 Elasticsearch 不是一个完整的 Elasticsearch。

Loadgen 具有以下主要特点：

• 性能强劲
• 轻量级无依赖
• 支持模板化参数随机
• 支持高并发
• 支持压测端均衡流量控制

只有模拟自己真实业务数据场景的压测才有意义，通过使用 Loadgen 定义写入文档或者查询模板，同时将里面的变量词典化，确保每次请求都是足够随机，变量可以灵活复用，支持多个请求混合压测，最大程度模拟真实环境。

• 下载地址：http://release.infinilabs.com/loadgen/
• Docker 地址：https://hub.docker.com/r/infinilabs/loadgen

Loadgen

Loadgen 使用非常简单，下载解压之后会得到两个文件，一个可执行程序和一个配置文件 loadgen.yml，配置文件样例如下：

variables:
  - name: ip
    type: file
    path: test/ip.txt
  - name: user
    type: file
    path: test/user.txt
  - name: id
    type: sequence
  - name: uuid
    type: uuid
  - name: now_local
    type: now_local
  - name: now_utc
    type: now_utc
  - name: now_unix
    type: now_unix
requests:
  - request:
      method: GET
      basic_auth:
        username: elastic
        password: pass
      url: http://localhost:8000/medcl/_search
      body: '{  "query": {"match": {    "name": "$[[user]]"  }}}'

变量的使用

上面的配置中，variables 用来定义变量参数，根据 name 来设置变量标识，在构造请求的使用 $[[变量名]] 即可访问该变量的值，变量目前支持的类型有：

类型	说明
file	文件型外部变量参数
sequence	自增数字类型的变量
range	数字范围类型的变量，支持参数 from 和 to 来限制范围
uuid	UUID 字符类型的变量
now_local	当前时间、本地时区
now_utc	当前时间、UTC 时区
now_unix	当前时间、Unix 时间戳

file 类型变量参数加载自外部文本文件，每行一个变量参数，访问该变量时每次随机取其中一个，变量里面的定义格式举例如下：

➜  loadgen git:(master) ✗ cat test/user.txt 
medcl
elastic

请求的定义

配置节点 requests 用来设置 Loadgen 将依次执行的请求，支持固定参数的请求，也可支持模板变量参数化构造请求，以下是一个普通的查询请求：

requests:
  - request:
      method: GET
      basic_auth:
        username: elastic
        password: pass
      url: http://localhost:8000/medcl/_search?q=name:$[[user]]

上面的查询对 medcl 索引进行了查询，并对 name 字段执行一个查询，每次请求的值来自随机变量 user。

命令行参数

Loadgen 会循环执行配置文件里面定义的请求，默认 Loadgen 只会运行 5s 就自动退出了，如果希望延长运行时间或者加大并发可以通过启动的时候设置参数来控制，通过查看帮助命令如下：

➜  loadgen git:(master) ✗ ./bin/loadgen --help
Usage of ./bin/loadgen:
  -c int
        Number of concurrent threads (default 1)
  -compress
        Compress requests with gzip
  -config string
        the location of config file, default: loadgen.yml (default "loadgen.yml")
  -d int
        Duration of tests in seconds (default 5)
  -debug
        run in debug mode, loadgen will quit with panic error
  -l int
        Limit total requests (default -1)
  -log string
        the log level,options:trace,debug,info,warn,error (default "info")
  -r int
        Max requests per second (fixed QPS) (default -1)
  -v    version

执行压测

执行 Loadgen 程序即可执行压测，如下:

➜  loadgen git:(master) ✗ ./bin/loadgen -d 30 -c 100 -compress
   __   ___  _      ___  ___   __    __
  / /  /___\/_\    /   \/ _ \ /__\/\ \ \
 / /  //  ///_\\  / /\ / /_\//_\ /  \/ /
/ /__/ \_//  _  \/ /_// /_\\//__/ /\  /
\____|___/\_/ \_/___,'\____/\__/\_\ \/

[LOADGEN] A http load generator and testing suit.
[LOADGEN] 1.0.0_SNAPSHOT, 83f2cb9, Sun Jul 4 13:52:42 2021 +0800, medcl, support single item in dict files
[07-19 16:15:00] [INF] [instance.go:24] workspace: data/loadgen/nodes/0
[07-19 16:15:00] [INF] [loader.go:312] warmup started
[07-19 16:15:00] [INF] [app.go:306] loadgen now started.
[07-19 16:15:00] [INF] [loader.go:316] [GET] http://localhost:8000/medcl/_search
[07-19 16:15:00] [INF] [loader.go:317] status: 200,<nil>,{"took":1,"timed_out":false,"_shards":{"total":1,"successful":1,"skipped":0,"failed":0},"hits":{"total":{"value":0,"relation":"eq"},"max_score":null,"hits":[]}}
[07-19 16:15:00] [INF] [loader.go:316] [GET] http://localhost:8000/medcl/_search?q=name:medcl
[07-19 16:15:00] [INF] [loader.go:317] status: 200,<nil>,{"took":1,"timed_out":false,"_shards":{"total":1,"successful":1,"skipped":0,"failed":0},"hits":{"total":{"value":0,"relation":"eq"},"max_score":null,"hits":[]}}
[07-19 16:15:01] [INF] [loader.go:316] [POST] http://localhost:8000/_bulk
[07-19 16:15:01] [INF] [loader.go:317] status: 200,<nil>,{"took":120,"errors":false,"items":[{"index":{"_index":"medcl-y4","_type":"doc","_id":"c3qj9123r0okahraiej0","_version":1,"result":"created","_shards":{"total":2,"successful":1,"failed":0},"_seq_no":5735852,"_primary_term":3,"status":201}}]}
[07-19 16:15:01] [INF] [loader.go:325] warmup finished

5253 requests in 32.756483336s, 524.61KB sent, 2.49MB received

[Loadgen Client Metrics]
Requests/sec:       175.10
Request Traffic/sec:    17.49KB
Total Transfer/sec: 102.34KB
Avg Req Time:       5.711022ms
Fastest Request:    440.448µs
Slowest Request:    3.624302658s
Number of Errors:   0
Number of Invalid:  0
Status 200:     5253

[Estimated Server Metrics]
Requests/sec:       160.37
Transfer/sec:       93.73KB
Avg Req Time:       623.576686ms

Loadgen 在正式压测之前会将所有的请求执行一次来进行预热，如果出现错误会提示是否继续，预热的请求结果也会输出到终端，执行完成之后会输出执行的摘要信息。

因为 Loadgen 最后的结果是所有请求全部执行完成之后的累计统计，可能存在不准的问题，建议通过打开 Kibana 或者 INFINI Console 的监控仪表板来实时查看 Elasticsearch 的各项运行指标。

模拟批量写入

使用 Loadgen 来模拟 bulk 批量写入也非常简单，在请求体里面配置一条索引操作，然后使用 body_repeat_times 参数来随机参数化复制若干条请求即可完成一批请求的准备，如下：

  - request:
      method: POST
      basic_auth:
        username: test
        password: testtest
      url: http://localhost:8000/_bulk
      body_repeat_times: 1000
      body: "{ \"index\" : { \"_index\" : \"medcl-y4\",\"_type\":\"doc\", \"_id\" : \"$[[uuid]]\" } }\n{ \"id\" : \"$[[id]]\",\"field1\" : \"$[[user]]\",\"ip\" : \"$[[ip]]\",\"now_local\" : \"$[[now_local]]\",\"now_unix\" : \"$[[now_unix]]\" }\n"

限制客户端压力

使用 Loadgen 并设置命令行参数 -r 可以限制客户端发送的每秒请求数，从而评估固定压力下 Elasticsearch 的响应时间和负载情况，如下：

➜  loadgen git:(master) ✗ ./bin/loadgen -d 30 -c 100 -r 100

注意，在大量并发下，此客户端吞吐限制可能不完全准确。

限制请求的总条数

通过设置参数 -l 可以控制客户端发送的请求总数，从而制造固定的文档，修改配置如下：

requests:
  - request:
      method: POST
      basic_auth:
        username: test
        password: testtest
      url: http://localhost:8000/medcl-test/doc2/_bulk
      body_repeat_times: 1
      body: "{ \"index\" : { \"_index\" : \"medcl-test\", \"_id\" : \"$[[uuid]]\" } }\n{ \"id\" : \"$[[id]]\",\"field1\" : \"$[[user]]\",\"ip\" : \"$[[ip]]\" }\n"

每次请求只有一个文档，然后执行 loadgen

./bin/loadgen -config loadgen-gw.yml -d 600 -c 100 -l 50000

执行完成之后，Elasticsearch 的索引 medcl-test 将增加 50000 条记录。

使用自增 ID 来确保文档的顺序性

如果希望生成的文档编号自增有规律，方便进行对比，可以使用 sequence 类型的自增 ID 来作为主键，内容也不要用随机数，如下：

requests:
  - request:
      method: POST
      basic_auth:
        username: test
        password: testtest
      url: http://localhost:8000/medcl-test/doc2/_bulk
      body_repeat_times: 1
      body: "{ \"index\" : { \"_index\" : \"medcl-test\", \"_id\" : \"$[[id]]\" } }\n{ \"id\" : \"$[[id]]\" }\n"

上下文复用变量

在一个请求中，我们可能希望有相同的参数出现，比如 routing 参数用来控制分片的路由，同时我们又希望该参数也保存在文档的 JSON 里面， 可以使用 runtime_variables 来设置请求级别的变量，或者 runtime_body_line_variables 定义请求体级别的变量，如果请求体复制 N 份，每份的参数是不同的，举例如下：

variables:
  - name: id
    type: sequence
  - name: uuid
    type: uuid
  - name: now_local
    type: now_local
  - name: now_utc
    type: now_utc
  - name: now_unix
    type: now_unix
  - name: suffix
    type: range
    from: 10
    to: 15
requests:
  - request:
      method: POST
      runtime_variables:
        batch_no: id
      runtime_body_line_variables:
        routing_no: uuid
      basic_auth:
        username: ingest
        password: password
      #url: http://localhost:8000/_search?q=$[[id]]
      url: http://192.168.3.188:9206/_bulk
      body_repeat_times: 10
      body: "{ \"create\" : { \"_index\" : \"test-$[[suffix]]\",\"_type\":\"doc\", \"_id\" : \"$[[uuid]]\" , \"routing\" : \"$[[routing_no]]\" } }\n{ \"id\" : \"$[[uuid]]\",\"routing_no\" : \"$[[routing_no]]\",\"batch_number\" : \"$[[batch_no]]\", \"random_no\" : \"$[[suffix]]\",\"ip\" : \"$[[ip]]\",\"now_local\" : \"$[[now_local]]\",\"now_unix\" : \"$[[now_unix]]\" }\n"

我们定义了 batch_no　变量来代表一批文档里面的相同批次号，同时又定义了　routing_no　变量来代表每个文档级别的 routing 值。

最后，欢迎大家反馈使用过程遇到的任何问题。

Elasticsearch 系列技术短视频分享持续更新中......   https://space.bilibili.com/471049389   不大不小的视频试水，欢迎大家留言和拍砖！    

在学习 ES 前一般都需要安装 ES，虽然 ES 可以开箱即用，但如果要学习分布式特性的时候，需要安装多个节点，这个时候还是有点工作量的。下面提供两个小脚本，一个是在 Ubuntu 中安装 3 节点的 ES 伪集群，一个是在 docker 中安装3节点 ES 集群。除了安装 ES 外，脚本还提供了对应版本的 Kibana、Cerebro 0.9.4 的安装。

1、在 Ubuntu 中安装 ES 7.13

这里我们采取下载 ES 安装包并且解压安装的方式，并没有走 Ubuntu apt 的方式。ES 的安装非常简单，这里先献上安装脚本。

下面介绍比较重要的配置项：

• discovery.seed_hosts 在开箱即用的情境下（本机环境）无需配置，ES 会自动扫描本机的 9300 到 9305 端口。一旦进行了网络环境配置，这个自动扫描操作就不会执行。discovery.seed_hosts 配置为 master 候选者节点即可。如果需要指定端口的话，其值可以为：["localhost:9300", "localhost:9301"]

• cluster.initial_master_nodes 指定新集群 master 候选者列表，其值为节点的名字列表。如果配置了 node.name: my_node_1，所以其值为 ["my_node_1"]，而不是 ip 列表 ！

• network.host 和 http.port 是 ES 提供服务的监听地址和端口，线上一定不能配置 ip 为 0.0.0.0，这是非常危险的行为！！！

怎么样来理解这个 discovery.seed_hosts 和 cluster.initial_master_nodes 呢？

cluster.initial_master_nodes 是候选者列表，一般我们线上环境候选者的数量比较少，毕竟是用来做备用的。而且这个配置只跟选举 master 有关，也就是跟其他类型的节点没有关系。就算你有100个数据节点，然后经常增加或者剔除都不需要动这个列表。

discovery.seed_hosts 这个可以理解为是做服务或者节点发现的，其他节点必须知道他们才能进入集群~ 一般配置为集群的master 候选者的列表。

但是这些 master 候选者（组织联系人）可能经常变化，那怎么办呢？这个配置项除了支持 ip 外还支持域名 ~所以可以用域名来解决这个问题，其他节点的配置上写的是域名，域名解析到对应的 ip，如果机器挂了，新的节点 ip 换了，就把域名解析到新的ip即可，这样其他节点的配就不用修改了。所以非 master 候选节点要配 discovery.seed_hosts （组织联系人）

除了修改 ES 服务配置外，还需要配置 JVM 的配置，我们主要配置服务占用的堆内存的大小。JVM 配置需要以下几点：

• 这两个 jvm 的配置必须配置一样的数值。启动时就分配好内存空间，避免运行时申请分配内存造成系统抖动。
• Xmx不要超过机器内存的 50%，留下些内存供 JVM 堆外内存使用
• 并且Xmx不要超过 32G。建议最大配置为 30G。接近 32G，JVM 会启用压缩对象指针的功能，导致性能下降。具体可以参考：a-heap-of-trouble。

安装成功后，可以访问： ES：localhost:9211

Kibana: localhost:5601

cerebro： localhost:9800

2、在docker 中安装 ES 7.13

在做一切工作之前，我们必须安装 docker。如果你已经安装好了 docker、docker-compose，可以访问我为你准备的 docker-compose.yaml 文件。

如果你没有安装 docker，完整的教程可以参考在 docker 中安装 ES 文档。

下载此文件，将文件保存为 docker-compose.yaml 后，进入这个文件的目录，执行以下指令即可：

docker-compose up

如果你没有下载镜像文件，docker-compose 会自动帮你下载镜像，并且启动容器。

如果 docker-compose 启动失败，说是无权限链接 docker 的话，其报错如下：

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: 

Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json?all=1&filters=%7B%22label%22%3A%7B%22com.docker.compose.project%3Ddocker_es%22%3Atrue%7D%7D&limit=0": 

dial unix /var/run/docker.sock: connect: permission denied

可以运行以下指令临时修改：

sudo chmod 666 /var/run/docker.sock

其原因是因为你的 docker 用了 root 启动了。

最后可以访问：

cerebro：ip:9000

Kibana：ip:5601

Elasticsearch: ip:9200，ip:9202，ip:9203

其他学习资料

创建自己的 ES Docker Image

在 docker image 中安装 Elasticsearch 插件

一个开源的 ELK docker-compose 配置

docker 中安装 ES 7.13

docker 中安装 Kibana 7.13

最后附上我写的小册，欢迎刚入门的朋友来订阅~