单机二进制部署7.0.1版本elasticsearch与kibana遇到的坑

发布于 2019-05-15  31 次阅读


前言
今天开发让安装elasticsearch和kibana 版本是最新版的7.0.1,由于是开发环境不必采用集群模式部署,系统是Ubuntu系统。我也采用了比较麻烦的二进制安装。在部署elasticsearch时为了配置文件看着简单方便,我把原有配置参数清空,然后只保留了我之前部署elasticsearch的必要配置,可是这个操作很坑,首先你要确定这个版本有没有参数废弃或者说需要额外新加必须配置,启动elasitcsearch后查看status正常。在网页访问http://192.168.1.53:9200也能返回正确的json。我就认为服务正常,于是接着部署kibana。但是kibana启动后查看日志不停报错。报错如下。
Unable to bulk upload the stats payload to the local cluster 。由于问题变现直观出现在kibana上,思维就一致固化在kibana上了。得到的报错信息也只有这一条。google上对这个报错的解释也很少。导致排错卡住了很久,最后和开发一起梳理,发现elasticsearch是不健康状态,虽然可以返回json。
排查过程
首先kibana和elasticsearch关联最大。kibana本身没什么配置的,说白了他就是一个可视化界面,一个node写的web服务,然后调用elasticsearch里面的数据如果自己出问题,无非就是监听问题。所以这种报错出现后,优先考虑是不是elasticseach有问题。于是我想起来当时仅仅查看了elastic的status状态和返回json状态。这就能代表elasticsearch正常么?通过这个教训发现,之前的理解是错的。
知识点总结
1.可以通过 curl http://192.168.1.53:9200/_cat/health 查看elasitcsearch状态,也可以/_cat查看可用api

2.elasticsearch中,network.hosts代表监听地址。单节点的话并且kibana和elasticsearch在同一台机器监听127.0.0.1 或者192.168.1.53都可以。但是不要监听0.0.0.0,因为真的没必要,并且不安全。另外当通过api查看node/master信息时,他会显示ip为172.17.90.1?这个是我机器的docker-0网卡ip。排在最前面。
3.因为elasticsearch和kibana官方要求以普通用户启动,可以建立一个普通用户,取消登陆权限,然后配置service服务文件来管理。但是需要注意各自的配置文件中所涉及的数据目录和日志目录以及服务安装目录都应该提前chown 授权。
4.单机elasticsearch,虽然没有集群发现等配置,但是仍然需要添加以下参数,否则虽然启动status正常,但是日志会报错。

添加如下参数后正常:
discovery.seed_hosts: ["127.0.0.1", "[::1]"]
cluster.initial_master_nodes: ["node-1"]
5.有时候如果配置错误,此时data 和log目录存的是错误数据,重新配置后需要清空旧的数据和日志,重新生成正确节点信息,如果不删除也会提示启动失败。
6.跨域问题
# 开启跨域访问支持,默认为false
http.cors.enabled: true
# 跨域访问允许的域名地址,(允许所有域名)以上使用正则
http.cors.allow-origin: /.*/
7.kibana监听0.0.0.0的话,虽然让我们访问方便,随时随地。但是为了安全可以设置登陆验证:用户名和密码。
配置文件展示
  • elasitcsearch配置
node.name: node-1
path.data: /data/elastic/data
path.logs: /data/elastic/log
network.host: 192.168.1.53
http.port: 9200
discovery.seed_hosts: ["127.0.0.1", "[::1]"]
cluster.initial_master_nodes: ["node-1"]
http.cors.enabled: true
  • kibana配置
server.port: 5601
server.host: "0.0.0.0"
elasticsearch.hosts: ["http://192.168.1.53:9200"] #旧版本是elaticsearch.url 。7.0.1已废弃
logging.dest: /var/log/kibana/kibana.log
总结
1.出现这次的问题主要是自己想当然了,百度了几个单机安装elasitc+kibana 就把参数直接复制粘贴了,而实际上你需要考虑版本问题,并且该版本对应的一些注释参数是否可以删除,因为有些参数,可能是必须的且用的默认,如果你删除了,他就会出现各种各样的问题。
2.排查问题时候,要梳理下两个服务之间的工作原理,联系和逻辑,这样就可以确定是直接(本身)问题?还是被被间接影响?
3.不要认为查看service的 status状态是绿色的就代表正常了,你要最起码tail查看日志是否有错误输出,然后进一步通过更高层的测试(本次例子是通过curl api 查看elasticsearch的health状态)比如说web服务 你会先看端口是否起来?进程是否存在?甚至到最后保证访问web成功才可以说明他是工作的。


一个幽默,喜欢动漫,音乐,爱小动物,逐渐成为二次元肥宅的LINUX运维工程师,我会用心写博客,刚开始写的不太好。但是我会不断进步的!。就像我的博客下面写的。我宁愿做错,也不愿什么都不做 ps:好像是伊泽瑞尔说的,看来你游戏没少玩啊 23333333333333