記一次kibana出現頁面帳號鎖定處理

                               記一次kiban出現頁面帳號鎖定處理

1、問題出現：

今天配置了elk,準備作個日誌分析平臺，因爲第一次搭建，不是很熟悉，因此遇到的問題就多了，然而就在啓動的時候出現錯誤。

  log   [08:16:48.906] [error][status][plugin:ml@6.3.0] Status changed from red to red - Red

 一直說服務Service Unavailable，服務的狀態問red。

可是kinaba是已經啓動的了

接着咱們訪問一下kinaba,咱們發現出現如下的狀況：

 

帳號與密碼填不進去。

2、問題分析

   分析一：出現這個狀況，我百度找找了，不少人沒有遇到過，遇到的都是重啓kibana，或說沒用安裝x-pack插件

   分析二：kibana配置有問題，或者es的配置出了問題，致使啓動kibana鏈接不上es。

 

3、解決思路以及辦法

思路一：

把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

 

能夠發現集羣已經正常了，接下就能夠愉快的玩耍了。

 4、總結

      通過一步步的分析，問題總算是解決了，總之獲益良多。