Elasticsearch 与 9200 端口
9200 是 Elasticsearch 的 HTTP REST 入口，Kibana、Logstash、Beats 与各类 SDK 都通过它读写索引、查看集群状态。集群节点之间的数据同步另走 9300。历史上 9200 无认证暴露是高发的数据泄露入口：一个索引列表请求就能看到全部索引与文档数量，甚至可以删除索引进行勒索。较新版本默认开启安全特性，存量旧集群则需要升级或手工加固。
基本信息
| 服务 | Elasticsearch HTTP REST（集群传输为 9300） |
|---|---|
| 协议 | TCP，HTTP 或 HTTPS（开启安全特性后） |
| 用途 | 索引读写、检索、集群管理与监控 |
| 认证方式 | Basic、API Key、证书（安全特性启用后） |
| 配置文件 | elasticsearch.yml 中 network.host、xpack.security 相关项 |
| 安全等级 | 仅内网并叠加认证，禁止公网 |
典型使用场景
- 日志检索：应用与系统日志集中入库，按时间与字段查询
- 业务搜索：商品、文档、内容的全文检索后端
- 监控数据存储：指标数据按时间索引存储并配可视化
- 数据管道：从消息队列或采集器写入，供后续分析使用
- 运维检查：查看集群健康、分片分布与磁盘水位
健康与索引检查
健康与索引检查
curl -s http://127.0.0.1:9200/ | head -20 # 根路径返回集群名称与版本
curl -s http://127.0.0.1:9200/_cluster/health?pretty # 健康状态与分片统计
curl -s http://127.0.0.1:9200/_cat/indices?v | head -20 # 索引清单与文档数
curl -sk -u elastic:'<口令>' https://127.0.0.1:9200/_cat/nodes?v # 安全集群需带凭据常见响应判读
| 现象 | 含义 | 处置方向 |
|---|---|---|
| health 为 green | 主副本分片均正常 | 无需处理 |
| health 为 yellow | 副本分片未分配，单节点常见 | 单节点开发可接受，生产需补足节点 |
| health 为 red | 存在未分配的主分片 | 先用分片分配解释接口定位原因 |
| 401 未授权 | 已开启安全但未带凭据 | 补 Basic 或 API Key 认证 |
| 429 写入被拒 | 写入队列打满 | 降低写入并发或扩容数据节点 |
安全集群的受限凭据访问
安全集群的受限凭据访问
# 申请一个只读用途的 API Key，供监控系统使用
curl -sk -u elastic:'<口令>' -XPOST 'https://127.0.0.1:9200/_security/api_key' -H 'Content-Type: application/json' -d '{"name":"monitor"}'
# 之后用该密钥访问，避免监控端持有 elastic 超级账号
curl -s -H 'Authorization: ApiKey <密钥>' 'https://127.0.0.1:9200/_cluster/health?pretty'9200 无认证暴露等于把全部索引与字段结构公开，且可被直接删除索引；这类事件在数据泄露案例中占比很高，务必先做网络隔离再叠加认证。
磁盘水位线要单独监控：接近低水位或高水位阈值会触发分片只读与迁移，写入突然失败往往不是应用问题，而是数据节点磁盘余量不足。
两个端口分工要记住：9200 供客户端与工具访问，9300 供节点之间通信；只放行 9200 而挡掉 9300，会表现为单节点可用但集群无法组建。