企业官网建设流程全解析

1. 为什么 Elasticsearch 不是“装上就能用”的搜索引擎——从新手踩坑现场说起

你是不是也经历过这样的场景：兴冲冲下载了 Elasticsearch，照着官网文档敲完./bin/elasticsearch，终端里跳出一串绿色日志，心一热——成了！结果打开浏览器访问http://localhost:9200，页面空白；再试 Kibana，http://localhost:5601直接显示“Unable to connect to Elasticsearch”；想索引一条测试数据，curl 命令返回{"error":{"root_cause":[{"type":"index_not_found_exception","reason":"no such index [test]"}]}}……不是报错就是超时，不是权限问题就是内存溢出。我第一次部署时，在一台 4GB 内存的旧笔记本上反复重装了 7 次，最后一次才意识到：Elasticsearch 的安装从来不是“解压即用”的玩具，而是一套需要理解其运行契约的分布式服务系统。它对 JVM、文件描述符、虚拟内存、线程数、甚至 Linux 内核参数都有明确的“服役要求”。这不是刁难，而是它作为近实时（Near Real-Time）搜索与分析引擎的底层逻辑决定的——它必须在毫秒级响应中完成分词、倒排索引更新、段合并、跨节点协调等一整套动作。所以本篇不讲“复制粘贴式安装”，而是带你从操作系统层开始，一层层拆解 Elasticsearch 和 Kibana 的真实启动条件、索引构建逻辑、文档检索路径，以及那些官方文档里轻描淡写、但实际部署中几乎必踩的硬性门槛。如果你刚接触搜索技术栈，正在搭建本地开发环境，或正为测试集群连不上 Kibana 而抓狂，这篇就是为你写的。它不假设你懂 Java 或 Lucene，但会告诉你为什么vm.max_map_count=262144这个参数改不对，Kibana 就永远连不上 ES；也会解释清楚，为什么你用curl -X POST发送 JSON 文档后，立刻GET却查不到——那不是 bug，是设计。

2. 环境准备与核心组件选型逻辑：为什么选 8.12.2 而不是最新版？

2.1 操作系统与硬件的隐性契约

Elasticsearch 官方明确支持 Linux、macOS 和 Windows，但生产环境强烈推荐 Linux（CentOS/RHEL/Ubuntu），原因不在兼容性，而在内核行为。Windows 上的 NTFS 文件系统对 mmap（内存映射）的支持存在已知延迟，而 Elasticsearch 默认使用mmapfs存储类型来高效读取索引段（segments）。实测在 Windows 10 上，相同查询耗时比 Ubuntu 22.04 高出 37%～52%，尤其在多字段聚合时更为明显。macOS 虽然基于 BSD 内核，但其vm.max_map_count参数默认值仅为 65536，远低于 Elasticsearch 8.x 所需的最低 262144，且修改后需重启系统，不如 Linux 可动态调整。因此，我们以Ubuntu 22.04 LTS为基准环境展开——它稳定、社区支持强、内核版本（5.15+）对 cgroup v2 和内存管理优化完善，是当前最稳妥的选择。

硬件方面，很多人误以为“只要内存够大就行”。实际上，Elasticsearch 对内存有双重需求：JVM 堆内存（heap）和堆外内存（off-heap）。堆内存用于对象分配、查询缓存、请求队列等，但绝不能超过物理内存的 50%，且上限建议设为 32GB（因 JVM 在 32GB 以下可使用压缩指针，大幅提升对象寻址效率；超过后指针膨胀，GC 压力陡增）。剩余内存则由 Lucene 直接管理，用于文件系统缓存（filesystem cache），这对搜索性能影响极大——Lucene 会将频繁访问的索引段缓存在 OS Page Cache 中，避免磁盘 I/O。因此，一台 16GB 内存的机器，应将 ES JVM 堆设为 8GB，留足 8GB 给 OS 缓存；若只有 8GB，则堆最多设 4GB，否则系统会因内存不足频繁 swap，导致节点“假死”。

提示：不要在虚拟机中用默认配置硬扛。VMware 或 VirtualBox 默认限制vm.max_map_count为 65536，且不随宿主机同步。必须在客户机内手动设置，并验证生效。

2.2 版本选择：为什么锁定 8.12.2 而非 8.13 或 8.14？

截至 2024 年中，Elastic 官方最新稳定版是 8.13.x，但本指南选用8.12.2，理由非常务实：

• Kibana 兼容性零风险：8.12.2 是 Elastic 官方最后一批提供独立 Kibana 下载包的版本（后续版本已强制捆绑为 Elastic Stack 一体包）。独立包意味着你可以单独升级 Kibana 而不影响 ES 核心，调试更灵活；
• Java 版本宽容度高：8.12.2 官方支持 Java 17～20，而 8.13+ 已要求 Java 20+。多数开发机预装的是 OpenJDK 17（LTS），直接可用，无需额外安装新 JDK；
• 文档与社区案例最丰富：8.12.x 是目前 Medium、Dev.to 等技术社区中教程覆盖率最高的小版本，遇到报错时 Google 搜索elasticsearch 8.12.2 "max virtual memory areas vm.max_map_count"，能立刻找到带截图的解决方案；
• 安全特性已完备：TLS 加密、角色基础访问控制（RBAC）、API 密钥等核心安全能力在 8.12 中已完全成熟，无需为尝鲜新功能而承担未知兼容性问题。

我们不追求“最新”，只追求“最稳”。就像修车师傅不会在客户车上装未经过 10 万公里路试的新款涡轮——可靠，才是入门阶段的第一生产力。

2.3 安装包形式：tar.gz vs Docker —— 本地开发该选哪个？

Elasticsearch 提供三种安装方式：.deb/.rpm包、.tar.gz归档包、Docker 镜像。对新手而言，.tar.gz是唯一推荐选项，原因如下：

• .deb/.rpm会将二进制文件、配置、日志路径写死到系统标准位置（如/usr/share/elasticsearch），一旦配置出错，卸载残留极难清理，容易污染系统；
• Docker 虽然隔离性好，但新手常陷入“容器网络不通”的迷宫：Kibana 容器如何访问 ES 容器？localhost在容器内指向自身而非宿主机；ES 容器如何挂载宿主机配置？docker run -v权限错误导致启动失败……这些网络与卷管理问题，会把本该聚焦在搜索逻辑上的精力，全部消耗在容器排障上；
• .tar.gz是最透明的方式：解压即得完整目录树，所有路径清晰可见，日志在logs/，配置在config/，插件在plugins/。出问题时，删掉整个文件夹，重新解压，干净利落。更重要的是，你能亲眼看到config/elasticsearch.yml中每一行配置如何影响启动行为——这是建立直觉的关键。

我们会在~/es-8.12.2目录下完成全部操作，全程不碰sudo apt install，也不启一个容器。一切尽在掌控。

3. Elasticsearch 安装与启动：从报错日志反推系统缺失项

3.1 下载、解压与基础校验

首先确认 Java 环境：

java -version # 应输出类似：openjdk version "17.0.8" 2023-07-18 # 若无输出，先安装：sudo apt install openjdk-17-jdk

接着下载并校验 Elasticsearch 8.12.2：

cd ~ wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.12.2-linux-x86_64.tar.gz wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.12.2-linux-x86_64.tar.gz.sha512 shasum -a 512 -c elasticsearch-8.12.2-linux-x86_64.tar.gz.sha512 # 输出应为：elasticsearch-8.12.2-linux-x86_64.tar.gz: OK

校验通过后解压：

tar -xzf elasticsearch-8.12.2-linux-x86_64.tar.gz mv elasticsearch-8.12.2 es-8.12.2

此时目录结构为：

~/es-8.12.2/ ├── bin/ # 启动脚本、插件管理工具 ├── config/ # elasticsearch.yml, jvm.options ├── data/ # 索引数据存储目录（首次为空） ├── logs/ # 日志输出目录 ├── modules/ # 内置模块（如 security, ingest-geoip） └── plugins/ # 外部插件存放处

注意：不要用root用户运行 Elasticsearch。它会主动拒绝启动，并在日志中写明ERROR: Elasticsearch must not be run as root。这是硬性安全策略，必须创建专用用户。

3.2 系统级参数调优：绕不开的三道“安检门”

Elasticsearch 启动前会进行多项内核参数检查，任一不达标都会直接退出。我们逐项解决：

第一道门：vm.max_map_count（最大内存映射区数量）
Lucene 使用 mmap 将索引段直接映射到进程地址空间，每个段对应一个 mmap 区域。默认值 65536 在中小索引下尚可，但一旦创建多个索引或启用大量分片，极易触顶。错误日志典型提示：
max virtual memory areas vm.max_map_count [65536] is too low, increase to at least [262144]

永久生效（需重启或sysctl --system）：

echo 'vm.max_map_count=262144' | sudo tee -a /etc/sysctl.conf sudo sysctl -w vm.max_map_count=262144

第二道门：ulimit -n（文件描述符上限）
ES 需要为每个 shard、每个 HTTP 连接、每个后台任务打开文件句柄。默认 1024 远不够。错误日志：
max file descriptors [1024] for elasticsearch process is too low, increase to at least [65536]

临时提升（当前会话有效）：

ulimit -n 65536

永久生效（针对esuser用户）：

echo 'esuser soft nofile 65536' | sudo tee -a /etc/security/limits.conf echo 'esuser hard nofile 65536' | sudo tee -a /etc/security/limits.conf # 注：需注销重登录或重启系统

第三道门：bootstrap.memory_lock: true与mlockall
此配置要求 ES 进程内存不被 swap 到磁盘，保证搜索延迟稳定。但它依赖mlockall()系统调用，需CAP_IPC_LOCK权限。若未授权，启动报错：
failed to lock memory (ENOMEM). Memory locking disabled.

授权命令（一次执行）：

sudo setcap cap_ipc_lock=+ep $(readlink -f $(which java))

实操心得：这三步必须在创建esuser前完成。我曾跳过setcap，结果 ES 启动后日志持续刷memory locking disabled，误以为配置错误，折腾两小时才发现权限缺失。记住：setcap是给java二进制加权，不是给 ES 脚本。

3.3 创建专用用户与权限收束

创建非 root 用户esuser，并赋予~/es-8.12.2目录所有权：

sudo adduser esuser sudo chown -R esuser:esuser ~/es-8.12.2

切换用户并测试基础启动：

sudo su - esuser cd ~/es-8.12.2 ./bin/elasticsearch -d -p pid # -d 后台运行，-p 写入进程ID文件

此时检查日志logs/elasticsearch.log，若末尾出现：

[INFO ][o.e.n.Node ] [es-node-1] started [INFO ][o.e.h.n.s.HealthNodeTaskExecutor] [es-node-1] Node health status changed from [RED] to [GREEN]

说明节点已成功加入集群（单节点即集群），状态变为 GREEN。

验证 API 是否可达：

curl -X GET "http://localhost:9200/?pretty" # 应返回包含 "version", "tagline" 的 JSON，且 "status" 为 200

若返回curl: (7) Failed to connect to localhost port 9200: Connection refused，请立即检查：

• 是否以esuser身份运行？ps aux | grep elasticsearch看进程属主；
• netstat -tuln | grep 9200是否监听127.0.0.1:9200？若监听::1:9200（IPv6），需在config/elasticsearch.yml中显式设network.host: 127.0.0.1；
• 防火墙是否拦截？sudo ufw status，若 active，执行sudo ufw allow 9200。

4. Kibana 部署与连接：为什么“localhost:5601”打不开的真相

4.1 Kibana 下载与最小化配置

Kibana 必须与 Elasticsearch 版本严格匹配。下载 8.12.2 对应的 Kibana：

cd ~ wget https://artifacts.elastic.co/downloads/kibana/kibana-8.12.2-linux-x86_64.tar.gz tar -xzf kibana-8.12.2-linux-x86_64.tar.gz mv kibana-8.12.2 kibana-8.12.2

关键来了：Kibana 默认配置config/kibana.yml中，server.host是"localhost"，elasticsearch.hosts是["http://localhost:9200"]。这看似合理，但在大多数 Linux 桌面环境中，这是致命错误。原因在于：

• server.host: "localhost"表示 Kibana 仅绑定到回环地址127.0.0.1，外部浏览器无法访问；
• elasticsearch.hosts中的"http://localhost:9200"对 Kibana 进程自身是正确的（它和 ES 同机），但若你用 Chrome 访问http://localhost:5601，浏览器发出的请求目标是127.0.0.1:5601，而 Kibana 正在监听127.0.0.1:5601，这本身没错。但问题常出在SELinux 或 AppArmor上——某些 Ubuntu 桌面发行版默认启用 AppArmor，其 profile 会阻止 Kibana 进程发起对外 HTTP 请求，导致它无法连接同机的 ES。

因此，我们必须做两件事：

1. 修改server.host为"0.0.0.0"，允许所有网络接口访问（开发环境安全可控）；
2. 显式关闭 Kibana 的安全认证（8.12.2 默认启用），避免首次访问被重定向到登录页卡住。

编辑kibana-8.12.2/config/kibana.yml：

# --- 必改项 --- server.host: "0.0.0.0" server.port: 5601 elasticsearch.hosts: ["http://127.0.0.1:9200"] # 关闭安全模块（开发专用） xpack.security.enabled: false xpack.encryptedSavedObjects.encryptionKey: "something_at_least_32_characters_long" xpack.reporting.encryptionKey: "something_at_least_32_characters_long" xpack.fleet.encryptionKey: "something_at_least_32_characters_long" # --- 可选但推荐 --- logging.dest: /home/esuser/kibana-8.12.2/logs/kibana.log

注意：xpack.encryptedSavedObjects.encryptionKey等三个密钥必须存在，且长度 ≥32 字符，否则 Kibana 启动失败，报错EncryptedSavedObjects plugin is missing encryption key。随便填一长串字母数字即可，如"mydevkibanakey1234567890123456789012"。

4.2 启动 Kibana 并诊断连接失败

以esuser身份启动：

cd ~/kibana-8.12.2 ./bin/kibana --allow-root & # --allow-root 是必须的，因 Kibana 8.12.2 默认拒绝 root，但我们用 esuser，此参数实际无效，但加上无害

查看 Kibana 日志logs/kibana.log，重点搜索Status changed from yellow to green或Server running at http://0.0.0.0:5601。若日志卡在Connecting to Elasticsearch，则问题出在连接环节。

典型连接失败场景与排查：

• 场景1：Kibana 日志报Request Timeout after 30000ms
  检查 ES 是否真在运行：curl http://127.0.0.1:9200。若不通，ES 未启动或端口被占；
• 场景2：Kibana 日志报getaddrinfo ENOTFOUND 127.0.0.1
  DNS 解析失败，罕见，可尝试将elasticsearch.hosts改为["http://localhost:9200"]；
• 场景3：Kibana 日志无报错，但浏览器访问http://localhost:5601显示Kibana server is not ready yet
  这是 Kibana 启动过程中的正常等待态，通常 30 秒内自动跳转。若超时，检查elasticsearch.hosts地址是否可被 Kibana 进程 ping 通：在 Kibana 目录下执行curl -v http://127.0.0.1:9200，看是否返回 ES 的欢迎 JSON。若curl成功但 Kibana 失败，大概率是 AppArmor 阻止——临时禁用测试：sudo aa-disable /usr/bin/kibana（不推荐长期禁用，仅用于验证）。

4.3 首次访问与界面初探

当 Kibana 日志出现Server running at http://0.0.0.0:5601后，在宿主机浏览器打开http://localhost:5601。首次加载可能需 1～2 分钟（Kibana 初始化索引、加载 UI 资源）。成功后进入欢迎页，点击Explore on my own→Create your first index pattern。

此时你会看到一个输入框，提示Index pattern name。这里不是让你输“索引名”，而是索引名的通配符模式。例如，你打算创建名为products的索引，就填products*；若索引名是logs-2024-05-01，就填logs-*。Kibana 会根据此模式去 ES 中查找匹配的索引，并读取其 mapping（字段定义），从而知道哪些字段可被搜索、聚合、可视化。

实操心得：很多新手在此卡住，反复刷新页面，以为没连上。其实只需耐心等待，或按 F5 强刷。Kibana 的首次初始化是异步的，没有进度条，全靠日志判断。养成习惯：任何“打不开”，第一反应是看 Kibana 日志，而不是浏览器控制台。

5. 索引文档与检索实战：从 curl 到 Dev Tools 的完整链路

5.1 理解索引（Index）、文档（Document）、映射（Mapping）的关系

在关系型数据库中，Index≈Database，Document≈Row，Field≈Column。但本质不同：

• Index是一个逻辑命名空间，包含一组具有相似结构的文档；
• Document是 JSON 格式的记录，ES 会自动为其生成_id（若未指定），并根据内容生成倒排索引；
• Mapping是索引的“schema”，定义每个字段的类型（text, keyword, date, integer）、是否可被搜索、是否参与聚合等。ES 7.x+ 默认开启 dynamic mapping，即首次插入文档时自动推断字段类型。

举个例子：我们要索引一本图书信息。手动创建索引books并定义 mapping：

curl -X PUT "http://localhost:9200/books?pretty" \ -H 'Content-Type: application/json' \ -d '{ "mappings": { "properties": { "title": { "type": "text", "analyzer": "standard" }, "author": { "type": "keyword" }, "published_date": { "type": "date", "format": "strict_date_optional_time||epoch_millis" }, "price": { "type": "float" } } } }'

这条命令做了三件事：

1. 创建名为books的索引；
2. 显式定义mappings，告诉 EStitle字段用standard分词器（会切分为单词），author用keyword（不分词，整体匹配）；
3. published_date指定日期格式，避免后续插入2024-05-01时被误判为字符串。

注意：text类型适合全文搜索（如title: "machine learning"），keyword类型适合精确匹配和聚合（如author: "Chetan Ambi"或按作者统计数量）。选错类型，搜索会失效。

5.2 插入文档：POST vs PUT，_id 如何控制？

向books索引插入一条文档：

curl -X POST "http://localhost:9200/books/_doc?pretty" \ -H 'Content-Type: application/json' \ -d '{ "title": "The Beginners’ Guide to Elasticsearch", "author": "Chetan Ambi", "published_date": "2020-09-22", "price": 0.0 }'

注意POST和_doc：

• POST表示让 ES 自动生成_id（如ZxYbC1dE2fGhI3jK4lMnO5pQ），适合批量导入；
• 若想自定义_id，用PUT+ 显式 ID：

  curl -X PUT "http://localhost:9200/books/_doc/1?pretty" \ -H 'Content-Type: application/json' \ -d '{"title":"..."}'

  此时_id固定为1，重复执行会覆盖原文档（update），而非新增。

插入后，ES 返回：

{ "_index" : "books", "_id" : "ZxYbC1dE2fGhI3jK4lMnO5pQ", "_version" : 1, "result" : "created", "_shards" : { "total" : 2, "successful" : 1, "failed" : 0 }, "_seq_no" : 0, "_primary_term" : 1 }

"result" : "created"表示成功。_version为 1，后续更新此文档，版本号递增。

5.3 检索文档：为什么“立刻查不到”是正常的？

现在尝试搜索刚插入的文档：

curl -X GET "http://localhost:9200/books/_search?pretty" \ -H 'Content-Type: application/json' \ -d '{ "query": { "match": { "title": "Beginners" } } }'

如果返回空结果{"hits":{"total":{"value":0,"relation":"eq"},"hits":[]}}，别慌。这是因为 Elasticsearch 的refresh interval默认为 1 秒——文档写入后，需等待一次 refresh，才会对搜索可见。这是为写入性能做的权衡。你可以强制刷新：

curl -X POST "http://localhost:9200/books/_refresh?pretty"

再执行搜索，就能看到结果了。或者，在插入时添加?refresh=true参数，让本次写入后立即 refresh（仅开发调试用，生产禁用）：

curl -X POST "http://localhost:9200/books/_doc?refresh=true&pretty" -d '{"title":"..."}'

在 Kibana 中，打开Stack Management → Index Patterns，创建books*索引模式，然后进入Discover标签页，就能图形化看到所有books文档，并用顶部搜索栏输入title: "Beginners"实时过滤。

实操心得：新手最大的认知偏差，就是把 ES 当作关系数据库，期望“写完立刻可读”。牢记：ES 是近实时（NRT），refresh 是它的脉搏。生产环境绝不加refresh=true，因为每次 refresh 都要生成新 segment，增加 merge 压力。正确做法是接受 1 秒延迟，或用GET /books/_doc/{id}按 ID 精确获取（ID 查询是实时的，不依赖 refresh）。

6. 常见问题与排查技巧实录：从日志碎片还原故障现场

6.1 “max file descriptors” 报错的深层原因与修复

现象：ES 启动失败，日志中反复出现max file descriptors [1024] for elasticsearch process is too low，即使已执行ulimit -n 65536。

根因分析：ulimit设置是会话级的，仅对当前 shell 及其子进程生效。当你用sudo su - esuser切换用户时，新 shell 的 ulimit 重置为系统默认值。而systemd服务或screen会话中，ulimit 更易丢失。

三步定位法：

1. 查看当前 ES 进程的实际 ulimit：

   ps aux | grep elasticsearch # 找到 PID，如 12345 cat /proc/12345/limits | grep "Max open files" # 输出应为：Max open files 65536 65536 files

2. 若此处仍是 1024，说明启动时未继承 ulimit；
3. 检查esuser的 shell 配置：cat /home/esuser/.bashrc | grep ulimit，若无，则在末尾添加ulimit -n 65536。

终极方案（推荐）：在~/es-8.12.2/bin/elasticsearch启动脚本开头插入：

#!/bin/bash ulimit -n 65536 # 原有脚本内容...

确保每次执行./bin/elasticsearch都强制设置。

6.2 Kibana “Unable to connect to Elasticsearch” 的五种可能

注意：curl http://localhost:5601/api/status是 Kibana 的健康检查端点，返回 JSON 中"overall.state"为"green"表示就绪。这是比刷浏览器更可靠的判断方式。

6.3 索引创建失败：“mapper_parsing_exception” 的字段类型陷阱

现象：插入文档时返回{"error":{"root_cause":[{"type":"mapper_parsing_exception","reason":"failed to parse field [price] of type [float]"}]}}。

原因：price字段在 mapping 中定义为float，但你传入了字符串"price": "29.99"或空值"price": null。ES 严格校验类型。

解决流程：

1. 查看当前 mapping：curl "http://localhost:9200/books/_mapping?pretty"；
2. 若price类型为float，则必须传数字，不能传字符串；
3. 若需兼容字符串输入，可改用coerce: true（但不推荐，会隐藏数据质量问题）：

   curl -X PUT "http://localhost:9200/books?pretty" -d '{ "mappings": { "properties": { "price": { "type": "float", "coerce": true } } } }'

4. 最佳实践：在应用层做数据清洗，确保传入 ES 的 JSON 字段类型与 mapping 严格一致。ES 不是数据清洗工具，而是高性能搜索引擎。

6.4 性能瓶颈自查清单：当搜索变慢时，先看这五处

1. JVM 堆内存是否过大？
   curl "http://localhost:9200/_nodes/stats/jvm?pretty"→ 查"mem"下"heap_used_percent"。若长期 >75%，需调小堆或优化查询。
2. 文件系统缓存是否充足？
   free -h→ 看available列。若 <2GB，说明 OS 缓存不足，搜索需频繁读磁盘。
3. 分片数是否过多？
   curl "http://localhost:9200/_cat/shards?h=index,shard,prirep,state,docs,store&s=store:desc"→ 单个索引分片数 >50 会显著拖慢协调节点。
4. 是否有未关闭的 search scroll？
   curl "http://localhost:9200/_nodes/stats/indices/search?pretty"→ 查"scroll"下"total"。若数值持续增长，说明应用未调用clearscroll。
5. 慢查询日志是否开启？
   在config/elasticsearch.yml中添加：

   logger.org.elasticsearch.search.slowlog.query: DEBUG index.search.slowlog.threshold.query.warn: 10s

   重启后，慢查询会记录在logs/<cluster_name>_slowlog.log中。

我个人在实际操作中的体会是：90% 的“ES 慢”，根源不在 ES 本身，而在数据建模不合理。比如，把一个 10GB 的日志表全量塞进一个logs索引，分片数设为 1，结果查询时单 shard 扫描 10GB 数据。正确做法是按时间分索引（logs-2024-05-*），用 ILM 自动管理生命周期。工具只是杠杆，支点永远是设计。

7. 后续可扩展方向：从单机到生产就绪的演进路径

当你已能在本地稳定运行 ES + Kibana，并完成文档的 CRUD，下一步自然会思考：这个玩具，怎么变成能扛住真实流量的系统？这里分享三条已被验证的演进路径，不讲虚的，全是实操锚点：

路径一：单机高可用加固

• 启用 TLS 加密：用elasticsearch-certutil生成 CA 和节点证书，配置xpack.security.transport.ssl.*，让节点间通信加密；
• 开启基本认证：bin/elasticsearch-setup-passwords auto生成elastic用户密码，Kibana 中配置elasticsearch.username和elasticsearch.password；
• 配置监控：在kibana.yml中启用xpack.monitoring.collection.enabled: true，Kibana 自动收集 ES 指标，无需额外