elasticsearch导入pdf文件（非结构）以及导入json（结构化） 导入方法 因为pdf被索引后虽然能搜索到文档内容，但是这里的需求是能够返回文档的名字 使用循环计算出每个文件的md5值，然后同时插入文件的md5值和文件名到数据库中 达到这种效果之后还需要在索引文件的手动设置id，取md5值 到这里，当我们从elasticsearch的索引中查询关键字并且选择打开的时候，可以取其id值在数据库中查询到对应的文件名称，即可实现打开搜索内容也显示对应的文件名 需求 elasticsearch不支持还原pdf文件，所以，上面描述的打开，实际上是显示搜索到的内容，并不能真正打开搜索到关键字的整个文档 这里，我们可以通过两个办法来实现： 当选择需要打开的搜索内容的时候取其id值，然后再次通过id值搜索，可以得到整个pdf文件的base64编码，再通过base64解码后即可以还原文件，这种方案只是手动尝试过，并没有实现 把文件的md5值名称状态的文件放入目录中，当打开搜索到的内容的时候，取其md5值，去匹配文件夹中的所有文件，匹配得到则显示即可 pdf的内容可以和文件名称可以转换为json格式的文档，经过elasticsearch索引后即可搜索，目前的方案是抽取mysql数据库的值和字段 其他问题 elasticsearch在导入的时候值内不能有换行符，即每个记录从第一个字段到最后一个字段只能是一行，要求每行之前必须有索引和关键字，id则不是必须 满足上面的条件后即可通过POST方法接--data-binary @FILEA_NAME来导入json文件到索引中 需要搜索中文，并且分词，一定要提前在字段中设置好

elasticsearch磁盘空间的问题 问题现象 selenium定时截图kibana，但是发现数据连续几天都是一样的，感觉好久没有更新了一样，怀疑是查询有问题，尝试登录kibana手动执行查询，但有如下报错： 排查经过 排查了kibana，logstash日志中有报错，但都没有明显的相关内容，那只能继续排查elasticsearch日志，在日志文件logcheck.log中发现了明显的异常： [2022-05-30T14:20:24,401][WARN ][o.e.c.r.a.DiskThresholdMonitor] [lognode1] high disk watermark [90%] exceeded on [1__xs753R3uOME1Sugp4kg][lognode1][/data/elfk/els/data/nodes/0] free: 181gb[5.1%], shards will be relocated away from this node; currently relocating away shards totalling [0] bytes; the node is expected to continue to exceed the high disk watermark when these relocations are complete 可以看到告警提示高水位线90%，于是我们查询服务器磁盘空间，确实目录使用率已经超过了90%了。清理空间后解决。 感悟 这个问题一开始的提示太模糊了，以致于我们排查了整个elfk日志才能定位，而且如果我们只是排查服务器性能，那么90%+的空间使用率也算正常，无法直接显示出问题在哪里，最后要么对elasticsearch特性很熟悉，要么对els故障排查熟悉，否则还是需要耗费一定时间的。 最后我们看看els关于空间的说明： https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cluster.html#disk-based-shard-allocation