[Elasticsearch] Kibana 설치하기

0. 설치 방법의 종류

주로 rpm 으로 Kibana 설치를 많이 하는 것 같다. 

RPM이란?
Red Hat Package Manager의 약자로, Red Hat 계열의 Linux 배포판에서 주로 사용된다. Kibana RPM 패키지는 시스템 패키지 관리자를 통해 간단하게 설치할 수 있다. yum이나 dnf와 같은 패키지 관리자를 사용해 의존성을 자동으로 해결하며, upgrade/제거도 편리하다.

 

 

하지만 여기선 TAR 아카이브로 직접 파일을 다운받아 설치하려고 한다. (root가 아닌 계정으로는 rpm을 통해 설치할 수 없다고 한다)

TAR 아카이브란?
일반적으로 리눅스 시스템 어느곳에서나 압축을 해제할 수 있다. 이 방법은 배포판에 상관없이 사용할 수 있으며, 커스마이징이 자유롭다. 의존성 및 설정은 수동으로 관리해야 한다. 

 

 

1. 파일 다운로드

> Elasticsearch와 동일한 버전으로 다운받는다.

 

https://www.elastic.co/kr/downloads/past-releases/kibana-7-17-8

Kibana 7.17.8 | Elastic

 

 

wget 명령어를 사용해서 바로 파일을 다운 받을수도 있지만, 회사 서버라 외부로 통신이 되지 않아 파일을 직접 local에 다운받아 서버로 옮겼다. 

 

 

2. 압축 해제

tar -zxvf kibana-7.17.8-linux-x86_64.tar.gz

 

tar -zxcf의 의미는?
tar는 여러 개의 파일을 하나의 파일로 묶거나 풀 때 사용하는 명령이다. Tape Archiver의 약자로 tar로 명명된다.
zxcf의 의미는, gzip으로 압축된 tar 아카이브를 현재 디렉토리에 푸는 옵션이다.

 

 

3. 설정파일 수정

vi {kibana 설치 폴더}/config/kibana.yml

# 아래 내용만 수정
...
server.host = 0.0.0.0
...
elasticsearch.hosts: ["http://localhost:9200"]
...

 

여기서 server.host = 0.0.0.0 은 외부에서 접속하기 위한 설정이다.

 

 

 

4. 데몬(daemon) 실행

처음엔 kibana 설치 방법을 찾아서 무작정 아래 명령어를 입력했더니

sudo service kibana start

 

 

위와 같은 에러가 발생했다. 아마 위의 명령어는 rpm을 통해 설치했을 때 사용하는 명령어인 것 같다. 

 

처음엔 위의 명령어로 실행하기 위해, systemd 설정을 별도로 하려고 했으나..! systemctl을 되도록이면 쓰지 않는것이 좋다는 글을 보게 되었다. 

 

./bin/kibana 명령을 사용하는 편이 좋다
.. (중략) .. 
위 명령의 장점은 pid 파일이 생성되어, 쉘 스크립트로 서버에 엘라스틱서치가 띄워져 있는지 아닌지 판별하기 쉽다는 점이 있다.

 

 

 

따라서 nohup 명령어로 데몬 실행을 했다. 

nohup ./bin/kibana > kibana_log.txt &

 

* 여기서 'service kibana start' <->  'nohup' 의 차이점은?

[sudo service kibana start]
이 명령은 시스템 서비스 관리자에게 Kibana 서비스를 시작하도록 요청하는 것이다. 해당 서비스가 시스템 부팅 시 자동으로 시작하도록 구성할 수 있다. 이 방법은 주로 시스템 서비스를 관리하는 운영 체제에서 사용된다. 

[nohup]
"no hang up"의 약자로, 터미널 세션을 종료해도 프로세스가 계속 실행되도록 하는 역할을 한다. 이 방법은 사용자가 직접 프로세스를 백그라운드로 보내는 것이므로, 시스템 부팅시 자동으로 실행되지 않는다.

 

 

 

5. 결과

 

 

 

 

+ 에러 해결

 

1) 신규 포트로 접근이 안되는 상황

 

[설치 서버 환경]

회사 서버 + cloud에서 생성한 인스턴스

 

인스턴스란?
클라우드에서 서버는 인스턴스로 생성된다. 인스턴스란 실제 가동되고 있는 가상화 컴퓨터를 말한다. 즉, 인스턴스라고 하면 서버로 가동되고 있는 가상 서버(물리 서버 머신에 해당하는 컴퓨터)를 말한다. 

 

 

분명 로컬 -> 키바나 서버로 ACL 신청도 했고, 키바나 서버 내에서 위의 사진과 같이 실행 확인도 했는데 무한로딩에서 넘어가질 않았다. 

 

알고보니 cloud 관리쪽에서 security group의 인바운드 정책에 해당 5601, 5602 포트를 추가해주어야 했다. 

 

Security Group이란?
인스턴스에 대한 인바운드(외부 > 인스턴스) & 아웃바운드(인스턴스 > 외부) 트래픽을 제어하는 가상 방화벽을 말한다.

 

프로토콜, 패킷 출발지, 포트번호 에 대한 정책에 추가해주어야 한다. 포트를 추가해주고 나니 로컬에서 접근이 가능해졌다!

 

 

 

 

 

2) 한개의 서버에서 두개의 키바나를 띄운 문제

 

동일한 서버에서 ES 서버 A에 연결된 키바나를 5601 포트로, ES 서버 B에 연결된 키바나를 5602 포트로 띄우고자 했다. 

 

위에서 다운받은 tar를 두번 압축을 풀어 두 개의 키바나 디렉토리를 만들고, config/kibana.yml 에서 각 포트와 연결된 ES 호스트 주소를 적었다. 

 

A를 먼저 실행했을 땐 정상 실행이 되었는데, B를 실행하자 아래와 같은 에러가 발생했다.

 

에러1. kibana_task_manager alias is pointing to a newer version of ...

 

분명 ES A, B는 동일한 버전(7.17.8)이라 키바나도 동일한 버전으로 설치했는데 왜 갑자기 두번째 실행에선 kibana_task_manager가 생성될 때 7.17.10 버전으로 생긴걸까..?

 

원인은 잘 모르겠다. 하지만 아래와 같은 방법으로 해결했다.

curl -XDELETE http://{ES서버}:9200/.kibana_task_manager_7.17.10_001
curl -XDELETE http://{ES서버}:9200/.kibana_7.17.10_001

 

kibana_task_manager (아마 ES <-> Kibana 관련 설정인 것 같다)를 삭제하고, 새로 실행(/bin/kibana)해 7.17.8 버전으로 새로 생성했다. 

 

 

 

 

 

에러2. 그러자 새로운 에러가 발생했다. 무엇인가 작성(write)할 수 없다는 에러인 것 같다. 

 

response code: 403 ({"type"=>"cluster_block_exception", "reason"=>"blocked by: [FORBIDDEN/8/index write (api)];"})

 

아래와 같은 방법으로 해결했다.

 

curl -X PUT -H "Content-Type: application/json" 'http://{ES서버}:9200/_all/_settings' -d '{ "index": { "blocks": { "write": "false" } } }'