記一次kiban出現頁面賬號鎖定處理
一、問題出現：
今天配置了elk,準備做個日誌分析平臺，由於第一次搭建，不是很熟悉，所以遇到的問題就多了，然而就在啓動的時候出現錯誤。
log [08:16:48.906] [error][status][plugin:[email protected]] Status changed from red to red - Red
一直說服務Service Unavailable，服務的狀態問red。
但是kinaba是已經啓動的了
接着我們訪問一下kinaba,我們發現出現以下的情況：
賬號與密碼填不進去。
二、問題分析
分析一：出現這個情況，我百度找找了，很多人沒有遇到過，遇到的都是重啓kibana，或說沒用安裝x-pack插件
分析二：kibana配置有問題，或者es的配置出了問題，導致啓動kibana連接不上es。
三、解決思路以及辦法
思路一：
把kibana kill掉，重新啓動
找到kibana啓動的端口
[root@node2 ~]# netstat -ntpl | grep 5601 tcp 0 0 172.25.0.30:5601 0.0.0.0:* LISTEN 12180/./bin/../node
重新kill點kibana的進程
[root@node2 ~]#ps -ef | grep node | awk '{print $2}'| xargs kill -9切換用戶啓動，重新啓動kibana
[root@node2 kibana-6.3.0]# su - www Last login: Sat Sep 29 16:14:07 CST 2018 on pts/3 [www@node2 ~]$ cd /usr/local/src/kibana-6.3.0 [www@node2 kibana-6.3.0]$ ./bin/kibana &
重啓完，發現，還是同樣的錯誤。
思路二：
安裝x-pack插件
[root@node2 kibana-6.3.0]# bin/kibana-plugin install x-pack Kibana now contains X-Pack by default, there is no longer any need to install it as it is already present.
發現x-pack是已經裝的了，找了一下官網，發現在kibana的6.3版本以上的，x-pack是已經安裝的了。
所以這個已經是排除的了。
思路三：
檢查kibana與es的配置；
kibana的配置，發現只是配置了幾個項包括服務ip、es的密碼配置：
server.host: "172.25.0.30" xpack.security.enabled: true elasticsearch.username: "elastic" elasticsearch.password: "changeme"
可以很明確的發現，這個不太影響的。
Es的配置:
cluster.name: es-log node.name: node2 path.data: /data/elasticsearch/data path.logs: /data/elasticsearch/logs network.host: 172.25.0.30 discovery.zen.ping.unicast.hosts: ["172.25.0.30", "172.25.0.33"] discovery.zen.minimum_master_nodes: 2 xpack.security.enabled: false
可以發現，好像配置都正常，日誌路徑、日誌路徑，集羣配置，還真找不出啥問題。
思路四：
判斷是否是集羣影響的問題
取消集羣的配置
把discovery.zen.ping.unicast.hosts: ["172.25.0.30", "172.25.0.33"]去掉 把 discovery.zen.minimum_master_nodes: 2 改爲 discovery.zen.minimum_master_nodes: 1
啓動es
#su - www #./bin/elasticsearch &
啓動kibana
#./bin/kibana
啓動發現，kibana啓動正常啦。
訪問一下kibana。
發現可以進去了啊，可以發現kibana已經是可以正常登陸了。到這裏我們已經是可以知道，是什麼原因導致kibana出現這種情況的了。
思路五：
查看集羣情況：
可以發現，我們的集羣，主要是通過ip與默認端口來建立集羣關係，導致集羣出現這種情況的原因有cluster.name配置與discovery.zen.ping配置與主集羣的配置不對應。
更改從es配置：
#vim cong/elasticsearch cluster.name: es-log discovery.zen.ping.unicast.hosts: ["172.25.0.33", "172.25.0.30"]
重新啓動集羣
#su - www #./bin/elasticsearch &
在主es啓動head插件
#grunt server &
訪問head然後訪問web的ip與端口
http://172.25.0.30:9100
可以發現集羣已經正常了，接下就可以愉快的玩耍了。
四、總結
經過一步步的分析，問題總算是解決了，總之獲益良多。