年初有个日志检索的需求环境是一台Windows服务器没有装任何可视化面板手头只有一个CMD窗口。任务很明确让Elasticsearch 7.7.0在这台机器上跑起来然后用命令行完成索引创建、文档写入、检索和集群状态排查这一套基本操作。折腾完一轮之后我发现命令行操作ES其实比想象中直接它把所有操作都收敛成了HTTP请求CMD窗口里一条curl命令就能搞定绝大多数事。这篇就按我实际操作的顺序把ES 7.7.0基于CMD命令行的基本操作完整过一遍适合刚接触ES、又不想一上来就依赖Kibana的开发者也适合需要在Windows环境做最小化部署的运维同学。1. 启动前先搞清版本与JDK7.7.0自己带了一套Java环境1.1 为什么7.7.0不再需要你手动装JDKES是Java应用早期版本对JDK版本的要求相当严格2.x、5.x时代装完ES还得小心翼翼地配系统Java环境版本不匹配直接启动失败。但从官方开始捆绑运行时之后这个坑基本被填平了。7.7.0的Windows发行包解压后自带一个jdk目录我解压的时候还专门进去确认过确实是一套完整的Java运行时。这意味着你下载官方zip包后连环境变量都不用配直接进bin目录跑elasticsearch.bat就行。系统里有别的JDK也没关系ES默认优先用自己的这套。只有在确实需要指定其他Java环境时才需要设置ES_JAVA_HOME或JAVA_HOME环境变量这个设计对快速部署非常友好。我在某项目环境里就是靠这个特性省掉了在一台干净服务器上装JDK的额外步骤。1.2 用CMD把ES跑起来的完整步骤我在实际环境里的操作路径是这样的下载elasticsearch-7.7.0-windows-x86_64.zip后解压到D:\es\elasticsearch-7.7.0这一层注意路径里别带中文和空格Windows下bat脚本对带空格的路径偶尔会抽风。然后打开CMD窗口执行cd /d D:\es\elasticsearch-7.7.0\bin elasticsearch.bat首次启动时CMD窗口会刷出大量日志。重点看两处一是[INFO] ... [节点名] ... publish_address {127.0.0.1:9200}这说明节点HTTP端口已经监听二是最后出现的[INFO] ... started看到这个词基本可以确认启动成功。ES启动过程受磁盘和内存影响通常需要十几秒到几十秒耐心等。启动成功后另开一个CMD窗口执行curl验证curl http://localhost:9200只要返回一段JSON包含cluster_name、cluster_uuid、version.number这些字段说明核心服务已经可用。version里能直接看到7.7.0的版本号Lucene版本也会一并返回。这一步是我每次部署后必做的冒烟测试。1.3 第一次启动时的三个常见异常第一次跑ES最容易遇到三类问题。第一双击bat文件窗口一闪而过这时候别双击改用CMD窗口手动执行elasticsearch.bat让错误信息留在屏幕上。窗口直接关闭多半是JVM启动失败比如内存参数写错、路径里有中文。第二端口被占用启动日志里报AddressAlreadyInUseException或者java.net.BindException基本就是9200端口被占。先确认是谁占了端口再说。第三是内存参数问题。7.7.0默认堆内存是1GB如果服务器内存紧张可以在config/jvm.options.d目录下新建一个文件比如heap.options写上自定义的堆大小-Xms512m -Xmx512m不要直接改主jvm.options文件ES推荐用jvm.options.d目录做扩展配置升级版本时主文件被覆盖也不影响你的自定义设置。这个小习惯我后来一直保留。2. 索引管理四条curl命令撑起基础结构2.1 核心概念速记索引、分片、副本开始敲命令之前先花一分钟理解索引。索引在ES里类似关系数据库里的表但底层是倒排索引结构。一个索引的数据会被拆成多个分片存储分片是数据分布的最小单位副本则是分片的拷贝负责高可用和读负载分摊。7.7.0创建索引时默认配置是1个主分片加1个副本。单节点环境下主分片可以正常分配但副本因为无法和主分片放在同一个节点会停留在未分配状态这一点后面讲健康检查时会再提到。创建索引时要不要手动指定分片数我个人的习惯是日志类、数据量增长快的索引提前规划分片数数据量小或临时验证用的索引用默认值就好。分片数设定后基本不能改想调整只能重建索引所以别拍脑袋。2.2 创建带settings的索引在CMD下创建索引最省事的写法是直接用curl加内联JSON。下面这条命令创建一个名为logs的索引指定3个主分片、1个副本curl -X PUT http://localhost:9200/logs -H Content-Type: application/json -d {\settings\:{\number_of_shards\:3,\number_of_replicas\:1}}不过说句实话这种内联JSON写法非常考验对转义的理解写短JSON还能忍长了就是折磨。我后来在这个环境里改用了文件方式先把JSON内容写到一个文件里再用curl读取发送。建好create_logs.json文件内容如下{ settings: { number_of_shards: 3, number_of_replicas: 1 }, mappings: { properties: { message: {type: text}, level: {type: keyword}, timestamp: {type: date} } } }然后执行curl -X PUT http://localhost:9200/logs -H Content-Type: application/json -d create_logs.json文件方式可以同时把settings和mappings一次定义好。我在这个例子里提前定义了字段类型message用text做全文检索level用keyword做精确匹配timestamp用date类型。生产环境强烈建议先定义好mapping再写数据不然ES靠自动推断生成的类型经常和业务预期对不上。2.3 查看索引的真实状态索引建完别急着写数据先确认状态。查看所有索引健康情况和占用信息用curl http://localhost:9200/_cat/indices?v输出里有一堆列最有用的几个是health表示索引健康状态status表示索引是否打开可用pri和rep分别显示主分片数和副本数docs.count是已写入的文档数store.size则是索引实际占用的磁盘空间。再看单索引的mapping和settingscurl http://localhost:9200/logs/_mapping?pretty curl http://localhost:9200/logs/_settings?pretty?pretty参数会让返回的JSON自动格式化。CMD里看格式化后的JSON比挤成一坨的要舒服太多这也是我日常排查时很喜欢加的参数。2.4 删除索引前必须知道的不可逆操作删除索引的命令很简单curl -X DELETE http://localhost:9200/logs返回{acknowledged:true}就代表删完了。但这一条命令会连带把索引里所有文档全部清掉ES没有回收站误删了只能靠备份恢复。所以我在这个环境里养成一个习惯批量操作前先用_cat/indices确认索引名拼写尤其是脚本里用了变量的时候最怕变量为空导致把前缀匹配的索引全删了。如果只是暂时不想让某个索引被搜索到、但又不想删数据可以先把索引关闭curl -X POST http://localhost:9200/logs/_close关闭后索引不再占内存和搜索资源数据还保留需要时再打开curl -X POST http://localhost:9200/logs/_open关闭索引在磁盘不足、需要临时释放内存的场景下很有用比直接删除安全得多。3. 文档操作写入、更新、删除与版本号3.1 PUT与POST的语义差异索引建好后就开始写数据。ES写文档有两种入口语义完全不同。第一种是PUT指定ID写入curl -X PUT http://localhost:9200/logs/_doc/1 -H Content-Type: application/json -d {\message\:\user login success\,\level\:\info\,\timestamp\:\2020-06-01T10:00:00Z\}这个请求的意思是向logs索引的_doc类型下写入ID为1的文档。如果ID 1已经存在整个文档会被覆盖版本号加1。适合业务上有明确主键的场景比如订单号、用户ID。第二种是POST不指定IDcurl -X POST http://localhost:9200/logs/_doc/ -H Content-Type: application/json -d {\message\:\user login success\,\level\:\info\,\timestamp\:\2020-06-01T10:00:00Z\}响应里会返回一个自动生成的ID形如20位 UUID。适合日志、事件流这类没有自然主键的数据。无论哪种方式响应都包含_index、_type、_id、_version字段。_index说明文档落在哪个索引_id是文档唯一标识_version是版本号。每次覆盖写入版本号递增这是ES实现乐观并发控制的基础。3.2 局部更新与覆盖更新的取舍更新文档最容易踩的坑是误用覆盖。比如要修改age字段直接PUT同一个ID、只带age字段结果其他字段全被清空了因为PUT是整体替换。ES也提供了局部更新接口curl -X POST http://localhost:9200/logs/_doc/1/_update -H Content-Type: application/json -d {\doc\:{\level\:\error\}}这里的doc字段包含要合并进去的字段ES会先把旧文档读出来把doc里的字段合并进去再写回新文档。好处是不会动其他字段。代价是性能。局部更新内部至少一次读加一次写比直接PUT多一次操作。日志类高吞吐写入场景尽量直接PUT或POST整篇覆盖少用_update。另外update同样受版本控制如果多个客户端同时改同一个文档后到的那方会收到409版本冲突响应业务上需要重试或合并逻辑。3.3 删除文档不是立即清理磁盘删除单条文档curl -X DELETE http://localhost:9200/logs/_doc/1正常响应里的result字段是deleted再次GET这个ID会返回found为false。但这里要注意删除操作只是给文档打上了删除标记磁盘空间不会立刻释放。ES底层采用Lucene分段存储真正清理要等段合并也就是后台的_forcemerge操作。如果大量删除数据后想尽快回收磁盘可以用curl -X POST http://localhost:9200/logs/_forcemerge?max_num_segments1这个操作比较重会占用大量IO建议在业务低峰期执行。日常使用中不必频繁做让ES自己管理段合并就够了。我遇过一次磁盘空间报警后紧急forcemerge的情况从那以后就记住了删除和磁盘回收之间有时间差。4. 查询实操从q参数到结构化DSL4.1 临时搜索用q参数查数据最容易上手的是带q参数的URI搜索直接拼在URL后面curl http://localhost:9200/logs/_search?qlevel:infopretty这就表示在logs索引里搜索level字段等于info的文档。临时验证数据有没有写进去这条命令够用。但这里有个CMD专属陷阱查询语句里加了多个条件时URL的符号会被CMD当成命令分隔符。比如curl http://localhost:9200/logs/_search?qlevel:infosize5CMD会截断URL导致请求不完整。解决方法是把整个URL用双引号包起来这也是我在CMD下操作ES严格保持的习惯。q参数适合快速验证复杂查询还是推荐用请求体DSL。4.2 match、term、range怎么选请求体查询才是ES真正的核心。新建一个query.json文件内容如下{ query: { bool: { must: [ {match: {message: user login}}, {term: {level: error}} ], filter: [ {range: {timestamp: {gte: 2020-06-01T00:00:00Z}}} ] } }, size: 20 }执行curl -X POST http://localhost:9200/logs/_search?pretty -H Content-Type: application/json -d query.json这里同时用到了三种查询。match会对查询词做分词再和索引里的分词结果匹配适合全文检索场景message字段是text类型所以能查出包含user、login相关词组的文档。term则是精确匹配不对查询词做任何分词处理适合keyword类型字段比如level。很多新手在term上翻车拿term查text字段经常什么都查不到。原因就是text字段的原始值在索引时已被拆分成多个词项term直接拿整个词去匹配匹配不上。range专门处理数值和日期范围gte、lte、gt、lt分别表示大于等于、小于等于、大于、小于。bool查询里must和filter的区别也很关键。must里的条件会参与相关度评分影响_score。filter里的条件只做过滤不参与评分ES会对filter结果做缓存性能更好。能用filter表达的区间、精确条件优先放filter。4.3 学会读查询响应查询返回的JSON看着长核心就几个字段。took是本次查询耗时毫秒数timed_out表示是否超时。hits.total在7.x版本是一个对象结构包含value和relation两个子字段value是实际命中数量relation标记结果是精确值还是近似值。hits.hits数组里才是真正的文档列表每一条包含_index、_id、_score和_source。_score是文档和查询条件的相关度分数。match查询会算分filter不影响分数。在日志检索场景我一般不怎么关心_score主要看hits.hits里的_source内容。响应的size字段控制返回条数默认是10条。翻页可以用from配合size比如from20、size10取第三页但深翻页性能很差生产环境超过一定深度建议改用search_after游标方式。作为基本操作先把size和from用明白就够了。5. 集群健康检查yellow不代表出故障5.1 三连命令health、nodes、indices单机部署也要养成分秒查看集群状态的意识。三条cat命令组合使用基本能掌握全部核心信息curl http://localhost:9200/_cat/health?v curl http://localhost:9200/_cat/nodes?v curl http://localhost:9200/_cat/indices?vhealth命令返回集群整体状态重点看status、node.total、shards、pri、unassign这几列。nodes命令列出集群里的节点清单包含节点名、IP、角色、持有分片数。indices命令按索引维度展示每个索引各自的状态、分片和文档数。我还经常搭配使用_cat/shards?v它可以精确到每个分片分配在哪个节点、处于什么状态。排查分片问题时光看索引级别不够需要分片级信息才能定位。5.2 状态颜色的真实含义集群状态只有三种颜色。green表示所有主分片和副本都成功分配最理想。yellow表示所有主分片都已分配但至少有一个副本没有被分配。red表示至少有一个主分片未分配对应索引无法完整读写。单节点环境里最常见的其实是yellow。原因前面提过副本不允许和它的主分片放在同一个节点单节点只有一个节点副本永远找不到地方分配。所以看到yellow先别慌不代表集群坏了。如果业务不需要副本可以把副本数改成0curl -X PUT http://localhost:9200/logs/_settings -H Content-Type: application/json -d {\index\:{\number_of_replicas\:0}}对于已经有数据的索引也可以用这条命令动态调整副本数改完可以在indices命令里看到rep列已经从1变成0。生产环境有多节点时yellow持续存在就要警惕了那通常意味着副本确实分配不出去。5.3 分片分配异常排查遇到red状态或长期的yellow先看unst assigned分片的原因。执行curl http://localhost:9200/_cat/shards?v输出中有一个unassigned.reason列会直接给出原因常见的有INDEX_CREATED表示索引刚创建还没分配完成NODE_LEFT表示节点离开导致分片丢失CLUSTER_RECOVERED表示集群恢复时遗留。我遇到过一例red就是因为磁盘写满后节点上的分片无法落地。这种场景下先别无脑reroute分片reroute只是把分片强制分配到指定节点磁盘不够照样失败。正确顺序是先看磁盘空间再看分片数量找到根本原因。ES集群本身有自动均衡能力很多临时unassigned在节点恢复后会自行解决没必要急着手动干预。6. CMD操作ES的四个真坑6.1 JSON转义推荐把请求体写成文件在CMD里用curl发送JSON最大的坑就是转义。刚上手时我习惯这样写curl -X POST http://localhost:9200/logs/_doc -H Content-Type: application/json -d {\message\:\test\,\level\:\info\}这条在CMD里能跑通是因为Windows命令解析会把反斜杠引号处理成字面双引号curl收到的body就是合法的JSON。但问题在于一旦JSON里有中文、空格变多或者多嵌套几层错误率直线上升。CMD不支持单引号包裹很多人把Linux下的习惯带过来写成-d {message:test}在Linux没问题在CMD里单引号会被原样传给curl发起请求保准400。我最终的方案是复杂JSON一律先写入文件再通过符号引用curl -X POST http://localhost:9200/logs/_doc -H Content-Type: application/json -d body.jsonbody.json用支持UTF-8无BOM的编辑器维护。这个做法既绕开转义也绕开编码问题是Windows CMD下操作ES最稳的姿势。6.2 中文乱码chcp 65001与文件编码CMD默认代码页是GBK而ES返回的是UTF-8所以直接curl查询带中文的文档时显示出来就是一团乱码。最简单的临时办法是在当前CMD窗口执行chcp 65001把代码页切换到UTF-8再执行curl命令控制台输出就正常了。注意这个只对当前窗口有效新开的CMD窗口还是GBK。发送中文数据时更麻烦。直接在CMD里手敲中文JSONCMD会用GBK编码传给curlES按UTF-8解析轻则乱码重则直接报解析异常。所以有中文内容时尽量把JSON保存成UTF-8无BOM文件再用-d file方式提交。还有一种做法是把返回结果重定向到文件再查看curl http://localhost:9200/logs/_search?pretty result.json然后用支持UTF-8的编辑器打开result.json比在控制台苦等显示正常要靠谱得多。6.3 磁盘水位线导致索引只读这个坑平时不出现一出现就是业务事故。ES默认对磁盘使用率设置了水位线超过85%停止分配新分片超过90%可能停止分配主分片超过95%会触发洪水警戒把索引自动置为只读。置为只读后写入操作会直接返回403错误信息里带disk watermark exceeded。我当时遇到的情况是服务器数据盘被日志文件塞到96%ES自动把索引锁成了只读。查了_cat/allocation?v后确认磁盘占用异常清理掉一堆旧文件后再用下面命令手动解除只读curl -X PUT http://localhost:9200/logs/_settings -H Content-Type: application/json -d {\index.blocks.write\: false}经验是别试图调大水位数让ES硬撑。磁盘满带来的后果比暂时写入失败严重得多ES的水位线机制是在保护数据安全。日常监控磁盘占用比事后补救要省心太多。6.4 端口占用netstat定位旧进程9200端口被占用是启动失败的常见原因。定位占用进程CMD下用netstat -ano | findstr 9200输出最后一列是进程PID再通过PID定位是什么程序tasklist | findstr PID号码如果是残留的旧ES进程直接结束它taskkill /PID 进程号 /F如果9200必须留给其他程序也可以改ES配置文件config/elasticsearch.yml里的http.port比如改成9201同时改transport.port保持集群内部通信独立。改完端口后记得重启ES。另外提醒一句多个ES实例千万不要指向同一个data目录这不是端口问题但一旦踩了直接导致数据目录锁冲突排查起来比端口问题更头疼。CMD窗口操作ES 7.7.0这段时间我最大的感受是命令行反而逼着你去理解REST API和集群原理。没有可视化面板帮忙掩盖细节每次操作都得清楚自己在对哪个接口发什么请求索引、分片、副本、版本这些概念也会在一次次的报错里真正立起来。如果你也刚接触ES建议先别急着装各种工具拿一个CMD窗口把基本操作过一遍基础会扎实很多。