(참고) Elk stack 설치 및 kafka

ELK stack 설치 및
KAFKA, NIFI연동
김진규
1

0. ELK stack
3
● Elasticsearch
기본적으로 모든 데이터를 색인하여 저장하고 검색, 집계 등을 수행하며 결과를 클라이언트 또는 다른 프로그램
으로 전달하여 동작하게 합니다.
기존 관계 데이터베이스 시스템에서는 다루기 어려운 전문검색(Full Text Search) 기능과 점수 기반의 다양한 정
확도 알고리즘, 실시간 분석 등의 구현이 가능합니다. 또한 다양한 플러그인들을 사용해 손쉽게 기능의 혹장이
가능하며 아마존 웹 서비스(AWS), 마이크로소프트 애저(MS Azure) 같은 클라우드 서비스 그리고 하둡(Hadoop)
플랫폼들과의 연동도 가능합니다.

4
● Logstash
입력 기능에서 다양한 데이터 저장소로부터 데이터를 입력 받고 필터 기능을 통해 데이터를 확장, 변경, 필터링 및
삭제 등의 처리를 통해 가공을 합니다. 그 후 출력 기능을 통해 다양한 데이터 저장소로 데이터를 전송하게 됩니
다.Elasticsearch외에도 다양한 경로의 출력이 가능하기 때문에 Elasticsearch에 데이터를 색인하는 동시에 로컬 파일
이나 아마존 AWS S3 저장소로 동시에 송출도 가능합니다. 그리고 Elasticsearch와 상관 없이 Redis의 데이터를 Kafka
로 전송하는 경우 등과 같이 독자적으로 사용되기도 합니다.
0. ELK stack

5
● Kibana
Kibana는 Elasticsearch를 가장 쉽게 시각화 할 수 있는 도구입니다. 검색, 그리고 aggregation의 집계 기능을 이
용해 Elasticsearch로 부터 문서, 집계 결과 등을 불러와 웹 도구로 시각화를 합니다. Discover, Visualize,
Dashboard 3개의 기본 메뉴와 다양한 App 들로 구성되어 있고, 플러그인을 통해 App의 설치가 가능합니다.
0. ELK stack

6
● Beats
0. ELK stack
Beats - Filebeat 사용
파일의 내용을 수집하는 기능입니다. Web log 또는 machine log 등이 저장되는 파일 경로를
지정하기만 하면 Filebeat은 해당 경로에 적재되는 파일을 읽어들이며 새로운 내용이 추가될
때 마다 그 내용을 Elasticsearch로 색인합니다.

1. Elasticsearch, Kibana 설치
7

8
● https://www.elastic.co/kr/downloads/ 접속 후 elasticsearch 다운로드

9
● https://www.elastic.co/kr/downloads/ 접속 후 다운로드 링크 복사 후 wget

10
● Kibana도 마찬가지로 진행. Elasticsearch와 Kibana는 같은 버전이여야 합니다.

tar파일 정리하기 위해 mkdir /home/files 디렉토리 만들고
mv *.tar.gz files/
11
● 압축 풀고 tar 파일 정리

12
● 디렉토리 이름 변경

13
● bin - 실행파일,
users 사용자 추가 파일,
lib - 실행 프로그램 jar 파일.

14
● 실행.
bin에서 ./elasticseasrch
java 1.8로는 실행이 되지 않습니다.
elasticsearch 7점대 버전부터는 java
가 포함되어 있으니, 환경변수 설정을
해당 경로로 변경 후 재실행해주세요

15
● 실행.
ERROR:
java 1.8로는 실행이 되지 않습니다.
elasticsearch 7점대 버전부터는 java
가 포함되어 있으니, 환경변수 설정을
해당 경로로 변경 후 재실행해주세요

16
● 정상 실행.

17
● 실행 중 여러가지 모듈을 불러오는 모습.
Elasticsearch는 9200, 9300번 port를 사용한다.
엘라스틱서치는 클러스터로 구성. 각각의 노드들은
9200번을 통해 http 프로토콜을 이용, 클라이언트와 통신
9300번 tcp 프로토콜을 이용, 다른 노드들과 통신, 노드들끼리 데이터를 주고받는다.

18
● putty로 같은 노드에 접속 후 정상작동 확인 후 ctrl + c로 elasticsearch 종료
REST API 이용,
XGET 생략 가능

19
● 설정파일 수정. vi config/elasticsearch.yml
주석 해제 대신, 가독성 좋게 위에다 표기

20
로그와 데이터 경로. 실제 현업에서는 분리합니다

21
네트워크 호스트와 포트
네트워크 호스트는 설정을 하지 않으면 로컬로만 접속이 가능하다.
네트워크 호스트를 바꾸면 외부에서도 접속이 가능
하지만 네트워크 호스트를 실제 아이피로 적는 순간 엘라스틱서치는 따로 설정을
해주어야 한다. 뒤에서 진행.
9200번이 디폴트 포트다. 실제 운영 환경에서는 해킹 위험으로 포트를 바꿔서 사
용한다.

22
● 일단은 클러스터 네임과 노드네임만 적고 저장 후 재실행
설정에 따라 변경된 값 확인

23
● 실행 후 log생성 확인

24
● 실행 종료 후 백그라운드로 실행 (-d 옵션 주기)
-d옵션은 데몬으로 실행. 실행이 잘 되는지 확인하려면 로그를 확인해야함.

25
● -d 옵션 실행 후 종료
pid 검색 후 kill. 종료 방식이 불편하다.

26
● -d -p es.pid 옵션
실행과 동시에 es.pid 파일 생성 확인.
해당 프로세스 id가 적혀있음.

27
● -d -p es.pid 옵션
해당되는 프로세스 kill과 동시에 es.pid도 삭제된다.

28
● -d -p es.pid 옵션으로 shell 작성. 편리하게 백그라운드 실행 및 종료 가능
vi start.sh
vi stop.sh

29
● 실행 권한 부여
vi stop.sh

30
● 실행
start shell로 es.pid 생성.
stop shell 입력 이후에 es.pid 사라진거 확인.

31
● 환경설정 config
jvm.options - java 힙메모리 및 환경변수
elasticsearch.yml 엘라스틱서치 옵션
log4j2.properties - 로그 관련 옵션

● jvm.options
32
힙메모리 설정. 디폴트는 1GB
실행 시 로그에서 힙사이즈 확인 가능.

● jvm.options 수정 후 변경사항 확인
33
힙메모리 설정. 디폴트는 1GB
실행 시 로그에서 힙사이즈 확인 가능.

● elasticsearch.yml
대부분 실제 설정들은 이 파일에서 설정한다. YAML문법으로 설정하기 때문에 들여쓰기에 유의해야 한다.
Cluster.name : 클러스터명
Node.name : 노드명
Node.attr <key>:<value> : 노드별로 속성을 부여하기 위한 일종의 네임스페이스를 지정.
Path.date : 경로
Path.logs : 경로
Bootstrap.memory_loc :
엘라스틱서치가 사용중인 힙메모리 영역을 다른 자바 프로그램이 간섭 못하도록 미리 점유하는 설정입니다 항상 true로 놓고 사용하는것
을 권장.
Network.host :
엘라스틱서치가 실행되는 서버의 ip 주소. 디폴트는 루프백(127.0.0.1). 주석처리되어있거나 루프백인 경우에는 엘라스틱서치 노드가 개발
모드로 실행이 된다. 만약 이 설정을실제 ip주소로 변경하게 되면 그 때부터 운영 모드로 실행이 되며 노드를 시작할 때 부트스트랩 체크
를 하게 된다.
Network.host :
서버의 내 /외부 주소 를 모두 지정하는데 만약 내부망에서 사용하는 주소와 외부망에서 접근하는 주소를 다르게 설정하고자 하면 아래
의 값 들을 이용해서 구분이 가능.
Network.bind_host : 내부망
Network.publish_host : 외부망
34

● 노드 바인딩
노드가 처음 실행 될 때 같은 서버, 또는 discovery.seed_hosts: [ ] 에 설정된 네트워크 상의
다른 노드들을 찾아 하나의 클러스터로 바인딩 하는 과정을 디스커버리 라고 합니다.
디스커버리는 다음과 같은 순서로 이루어집니다.
1. discovery.seed_hosts 설정에 있는 주소 순서대로 노드가 있는지 여부를 확인
○ 노드가 존재하는 경우 > cluster.name 확인
● 일치하는 경우 > 같은 클러스터로 바인딩 > 종료
● 일치하지 않는 경우 > 1로 돌아가서 다음 주소 확인 반복
○ 노드가 존재하지 않는 경우 > 1로 돌아가서 다음 주소 확인 반복
1. 주소가 끝날 때 까지 노드를 찾지 못한 경우
○ 스스로 새로운 클러스터 시작
35

● 노드 바인딩
서로 다른 서버에서 접속을 하려면 yml파일의 network.host 설정을 해야한다. 설정 후 실행
36
"_site_"로 하게 되면 알아서 현재 주소로 지정

● 강제로 종료된다.
37

● 원인 : 로그확인
네트워크 호스트 설정을 하니까 실제로 엘라스틱서치가 운영 모드로 바뀌면서 부트스트랩 체크를 하게 된다.
엘라스틱서치는 로그가 굉장히 자세하다.
세가지 이유.
1. 운영 모드에서의 부트스트랩 체크로 인한 에러
2. max file descriptor 설정
3. max virtual memory 설정
2, 3번 두가지는 virtual machine 설정을 바꾸어야 한다.
38

● virtual machine 설정 변경 필요.
39
로그 확인.
max file descriptors 설정 변경 필요

● vi etc/security/limits.conf / max file descriptor 설정 변경
40
추가 기입

● vi etc/sysctl.conf
41
메모리 늘려주기. 후에 시스템 재시작
sudo shutdown -r

● 재시작 후 실행. 마지막 에러 확인
42
디스커버리 세팅을 해야한다.
vi elasticsearch.yml
에서 discovery 검색
:/discovery

● vi elasticsearch.yml
43
discovery.seed_hosts에 입력.

● vi elasticsearch.yml
44
yy, p 활용해서 맨 위에 정보 입력

● 설정 완료 후 elasticsearch 재실행
45
정상작동 확인.

● 웹으로 확인
46
Aws를 이용하는 경우에는 포트를 열어주고,
방화벽 설정을 해야한다.
network.host에 local도 추가

● 타 노드에 전송
47
이제 두개의 노드를 더 띄워서 세개의 엘라스틱 노드를 구성한다.
ex) hadoop01데이터를 hadoop02 hadoop03에 전송
sudo scp -r elk(엘라스틱서치, 키바나 상위 디렉토리) hadoop02:/home/
sudo scp -r elk hadoop03:/home/
sudo ssh hadoop02 chown -R hadoop01:hadoop01 /home/elk
sudo ssh hadoop03 chown -R hadoop01:hadoop01 /home/elk
클러스터는 동일하게, 노드 네임만 바꿔준다.
후에 위에서 진행했던 메모리 설정을
2, 3번노드에도 설정해주고 시스템 재시작.

● 노드 설정파일.
48
바인딩이 제대로 되지 않는다면 이전의 데이터가 남아
있어서 그렇습니다.
Data파일을 지우고 재실행하면 해결됩니다.

● 로컬 cmd창에서 클러스터링 확인
49
로컬 창에서 _cat/nodes 입력
*표시가 마스터노드.
curl "hadoop01:9200/_cat/nodes?v"
클러스터가 잘 형성된 것을 볼 수 있다.

● 클러스터 보안 설정. vi elasticsearch.yml
50
일단 실행중인 엘라스틱서치 모두 종류 후 hadoop01에다가만
xpack.security.enabled: true 입력

● 설정 후 elasticsearch 재실행
51
운영 모드로 실행중이기때문에 bootstrap checks failed error 발생.
ssl transprot를 무조건 지정해야한다.
클러스팅을 할 때 transport layer security를 적용하지 않으면 클러스터링 되지
않는다(위에 설정에서 security=enabled한 경우)

● vi elasticsearch.yml 에 설정 추가
52

● 공개키, 대칭키 생성
53
Generate certificates
엘라스틱서치에서는 certutil을 제공한다

● 공개키 생성
54
enter 후에 password 입력 ( 숫자로 하면 안됩니다)

● 공개키 생성
55
생성 확인

● 대칭키 생성
config 디렉토리 안에 certs 디렉토리 생성
mkdir config/certs
56

./elasticsearch-certutil cert
--ca elastic-stack-ca.p12
--dns hadoop01,hadoop02,hadoop03
--ip 192.168.0.128,192.168.0.129,192.168.0.130
--out config/certs/es-cluster.p12
57

아까 저장한 패스워드 입력.
58

es-cluster.p12의 패스워드 생성
59

● 대칭키 생성 완료
certs 디렉토리로 이동
60

● 키값 입력 vi elasticsearch.yml 후 저장. 엘라스틱서치 실행
61
절대경로로 지정하지 않으면 config 디렉토리를 기준으로 시작된다.

● 실행 후 패스워드 미설정 에러 발생
62

● 패스워드 입력
63
이런 식으로 입력하게 되면 다시 오류가 발생합니다. 키스토어 시큐어 패스워드 옵션은 시큐어 세팅이기때문에 엘
라스틱서치 키스토어에 저장을 해야합니다. 패스워드를 설정파일에 뻔하기 보이게 박아놓지 말라는 것!
그래서 엘라스틱 서치에서는 민감한 옵션들을 yml파일에 넣지 않고 키스토어에 보관합니다.
password 관련 line은 지워줍니다.

64
● bin에서 elasticsearch-keystore create. 없다면 생성. 이미 존재한다면 N

● Bin에서 ./elasticsearch-keystore add xpack.security.transport.ssl.keystore.secure_password 입력
65
password 입력해주기. 숫자입력 x
숫자로만 입력시에 Kibana 로그인이 되지 않습니다...

● bin에서 ./elasticseasrch-keystore list 입력
66
키 저장 확인

● bin에서 ./elasticsearch-keystore add xpack.security.transport.ssl.truststore.secure_password
67
위와 동일하게 비밀번호도 지정해줍니다.
저장 확인

● elasticsearch 실행
68
저장 확인
정상작동 확인

● node2, node3에 인증서 배포.
node2, node3에도 certs 디렉토리를 만들어준다.
69

● node2, node3에 인증서 배포.
node2, node3에도 certs 디렉토리를 만들어준다.
70

● 이후에 node2, node3에서
./elasticsearch-keystore add xpack.security.transport.ssl.keystore.secure_password
./elasticsearch-keystore add xpack.security.transport.ssl.truststore.secure_password
./elasticsearch-keystore list 입력으로 생성 확인
71
node 2
node 3

● 이후에 node2, node3 yml파일 수정
72
node 2
node 3
node 2

● 모든 노드에서 elasticsearch 실행 후 로컬 cmd창에서 curl 명령어 입력
73
이전과 다르게 보안 설정으로 인해
데이터를 불러오지 못하는 모습.
패스워드를 설정해주어야 한다.

● Bin에서 elasticsearch-setup-passwords
74
auto와 interactive 두개 모드가 있다.
비밀번호를 잃어버린경우 data디렉토
리를 삭제하고 다시 패스워드 생성.
interactive모드로 진행
./elasticsearch-setup-passwords
interactive

● 비밀번호 설정
75
숫자로만 할 경우
error

● curl + 비밀번호 입력
76
-u 옵션으로 유저:패스워드 입력 시 정상 작동.
setup password utility는 엘라스틱 클러스터 전체에 적용되기 때문에 하나
의 노드에서만 적용해도 나머지에 일괄적으로 입력이 된다.

● superuser 생성 ( node1에서만)
77

● superuser 생성 ( node1에서만)
78
해당 슈퍼유저는 node 1에서만 유효하
다(파일정보로 존재하기 때문) 당연히
node 2로의 curl명령어는 보안문제로
정상작동하지 않는다.

● 10 page 에서 설치한 kibana 디렉토리
80
2. Kibana 기본 설정
kibana를 통해 gui를 볼 수 있다. Elasticsearch 1,2,3 세 노드에서 실행중
kibana도 rest api로 통신을 하며, 5601번 포트를 사용한다.
예시에서는 3번노드에 설치 후 설정

● vi config/kibana.yml
81
server.port - default 5601
server.host -
엘라스틱서치의 network host와
같은 개념. 후에 수정해준다.
server. name -
엘라스틱서치의 nodename 같다.

● vi config/kibana.yml 수정
82

● vi config/kibana.yml 수정
83
user password도 필요하지만, 뻔히 보이는곳에
노출시킬 수는 없으니, keystore에 저장해야 한다.

● bin에서 keystore에 password 저장
84

● 저장 확인
85

● 실행
86
password 숫자로 지정 시 위와 같은 오류 발생.
정상 실행. 5601 포트로 접속

● id = elastic, password = 비밀번호 입력 후 접속
87
aws를 사용하는 경우에는 웹에서 따로 방화벽 세팅 필요.
새로운 방화벽 룰 추가. 0.0.0.0 tcp 5601 포트 추가.

● kibana를 통한 adduser 후 생성한 계정으로 로그인
88

● kibana 백그라운드 실행을 위한 pm2 설치
89
kibana는 nodejs로 실행되기에 ps -ef : grep kibana 입력 시 검색되지 않는다.
kibana 종료시에는 ps -ef : grep node 명령어를 통해 pid 검색 후 kill 해야 한다.
kibana를 백그라운드에서 편리하게 실행하고, 종료할 수 있게 pm2를 설치한다.
nodejs가 프로세스를 데몬으로 실행해주는 여러 프로그램을 제공하는데 이 중 하나가 pm2다. 이 때 nodejs는무조건 호환
되는 버전을 받아야 한다. kibana의 package.json 확인
node : 14.17.2 확인

● kibana 백그라운드 실행을 위한 pm2 설치
90
위의 명령어로 설치.
배쉬 쉘을 사용하기 때문에 배쉬 쉘 안에
export NVM_DIR="$([ -z "${XDG_CONFIG_HOME-}" ] && printf %s "${HOME}/.nvm" || printf %s
"${XDG_CONFIG_HOME}/nvm")"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" # This loads nvm
추가. 일반적으로는 이미 입력되어있다.
설치 후에 source .bashrc 입력

● nvm 설치 완료
91
nvm 입력 후 환경변수 정상 적용 확인. 위에서 확인한 버전으로 install

● nvm 설치 완료
92
node 명령어 정상작동 확인.

● pm2 설치
93
-g : global 옵션으로 설치

● pm2로 kibana 실행
94
pm2 start app.js 로 app.js를 백그라운드로 실행이 가능.
프로세스 오류시 재시작도 시켜준다고 합니다.
kibana 클라이언트 js파일을 pm2로 시작.

● pm2로 kibana 실행 확인
95
pm2 list : 확인
pm2 stop ‘name’ : 중지

● pm2 process name 지정
96
pm2 delete cli
pm2 start /home/lek/kb-713/src/cli/cli.js --name kibana
이전에 있던 ‘cli’ 삭제 후 --name 옵션으로 실행.

● pm2 kibana start, stop shell 만들기
97

● start, stop shell 권한 부여 후 start.sh, stop.sh 정상작동 확인
98

3. Elasticsearch 인덱스와 샤드
99

elasticsearch 에서는 단일 데이터 단위를 도큐먼트(document) 라고 하며 이 도큐먼트를 모아놓은 집합을 인덱스(Index)
라고 합니다. 인덱스라는 단어가 여러 뜻으로 사용되기 때문에 데이터 저장 단위인 인덱스는 인디시즈(indices) 라고 표
현하기도 합니다. 여기서는 데이터를 Elasticsearch에 저장하는 행위는 색인, 그리고 도큐먼트의 집합 단위는 인덱스 라고
하겠습니다.
인덱스는 기본적으로 샤드(shard)라는 단위로 분리되고 각 노드에 분산되어 저장이 됩니다. 샤드는 루씬의 단일 검색 인
스턴스 입니다. 다음은 하나의 인덱스가 5개의 샤드로 저장되도록 설정한 예 입니다.
100

프라이머리 샤드(Primary Shard)와 복제본(Replica)
인덱스를 생성할 때 별도의 설정을 하지 않으면 7.0 버전부터는 디폴트로 1개의 샤드로 인덱스가 구성되며 6.x 이하 버
전에서는 5개로 구성됩니다. 클러스터에 노드를 추가하게 되면 샤드들이 각 노드들로 분산되고 디폴트로 1개의 복제본을
생성합니다. 처음 생성된 샤드를 프라이머리 샤드(Primary Shard), 복제본은 리플리카(Replica) 라고 부릅니다. 예를 들
어 한 인덱스가 5개의 샤드로 구성어 있고, 클러스터가 4개의 노드로 구성되어 있다고 가정하면 각각 5개의 프라이머리
샤드와 복제본, 총 10개의 샤드들이 전체 노드에 골고루 분배되어 저장됩니다.
101

같은 샤드와 복제본은 동일한 데이터를 담고 있으며 반드시 서로 다른 노드에 저장이 됩니다. 만약에 위 그림에서 Node-
3 노드가 시스템 다운이나 네트워크 단절등으로 사라지면 이 클러스터는 Node-3 에 있던 0번과 4번 샤드들을 유실하게
됩니다. 하지만 아직 다른 노드들 Node-1, Node-2 에 0번, 4번 샤드가 남아있으므로 여전히 전체 데이터는 유실이 없이
사용이 가능합니다.
102
노드가 3개로 줄었을 때도 전체 데이터 유지.
프라이머리 샤드가 유실된 경우에는 새로 프라이머리 샤드
가 생성되는 것이 아니라, 남아있던 복제본이 먼저 프라이머
리 샤드로 승격이 되고 다른 노드에 새로 복제본을 생성하게
됩니다.

샤드 개수 설정
샤드의 개수는 인덱스를 처음 생성할 때 지정할 수 있습니다. 프라이머리 샤드 수는 인덱스를 처음 생성할 때 지정하며,
인덱스를 재색인 하지 않는 이상 바꿀 수 없습니다. 복제본의 개수는 나중에 변경이 가능합니다.
만약에 4개의 노드를 가진 클러스터에 프라이머리 샤드 5개, 복제본 1개인 books 인덱스, 그리고 프라이머리 샤드 3개 복제
본 0개인 magazines 인덱스가 있다고 하면 전체 샤드들은 아래와 같은 모양으로 배치될 수 있습니다.
103

4. Elasticsearch CRUD, query
104

● kibana - dev tools 클릭
105
ctrl + enter 로 간단하게 실행

● create index
106
샤드가 5개,
리플리카가 1개짜리 books 인덱스 생성.
삭제 - DELETE
조회 - GET

● 클러스터 정보 확인
107
클러스터 정보 확인
GET _cat/nodes?v&h=ip,name,node.role
v는 헤더정보, h를 통해 보고싶은 필드 조회.

● 인덱스 정보 확인
108
Get _cat/indices
인덱스 조회

109
Get _cat/indices
인덱스 조회

110
Get _cat/indices
인덱스 조회
Books 인덱스의 샤드.
p : 프라이머리
r : 레플리카
각각 하나씩 5개 존재하니 총 10개의 샤드가 3개 노드에
분산저장 된 상태. 모니터링 기능으로 더 편하게 볼 수 있다.

● 모니터링
111
Stack Monitoring 클릭.
매트릭비트 설치 X
indices 클릭.

● 모니터링
112
제일 아래에 샤드 정보가 나와있다.
모니터링 종료
enabled 옵션 : null로 지정해서 초기값으로 돌려준다.
true로 전환 시 모니터링이 켜진다.
(불필요한 메모리 소요. 여기서는 일단 종료해주세요).
모니터링을 종료하더라도, 종료하기 전 최근 한시간
내의 데이터가 존재한다면 모니터링이 가능하다. 하
지만 갱신은 되지 않는다.

● CRUD
113
Get으로 읽어오기.
source 명령어를 추가하면 source만 가져옴.

● PUT
114
이런식으로 put을 해버리면 앞에서 넣었던 name, message는 사라진다.
업데이트는 POST 사용

● POST
115
포스트로 생성도 할 수 있다. 아이디 값을 주지 않으면 고유한 아이디값이 자동으로 생성이 되기에 (도큐먼트
아이디 값이 자동 생성) 여러 개의 데이터를 겹치지 않도록 저장할 때는 이런 방식이 좋을 수 있다.
GET으로 UPDATE 된 데이터 확인

● bulk 명령어
116
여러가지 명령어 한꺼번에 사용
- 두줄씩 쌍, 한줄은 명령 한줄은 데이터
POST _bulk
{"index":{"_index":"test", "_id":"1"}}
{"field":"value one"}
{"index":{"_index":"test", "_id":"2"}}
{"field":"value two"}
{"delete":{"_index":"test", "_id":"2"}}
{"create":{"_index":"test", "_id":"3"}}
{"field":"value three"}
{"update":{"_index":"test", "_id":"1"}}
{"doc":{"field":"value two"}}

● search 예시
117

118
Query DSL (Domain Specific Language)
Elasticsearch 는 검색을 위한 쿼리 기능을 제공합니다. 이런 데이터 시스템에서 제공하는 쿼리 기능을 Query DSL (Domain Specific
Language) 이라고 이야기 하며 Elasticsearch 의 Query DSL 은 모두 json 형식으로 입력해야 합니다
위에서 진행했던 my_index 삭제 후 진행
POST my_index/_bulk
{"index":{"_id":1}}
{"message":"The quick brown fox"}
{"index":{"_id":2}}
{"message":"The quick brown fox jumps over the lazy dog"}
{"index":{"_id":3}}
{"message":"The quick brown fox jumps over the quick dog"}
{"index":{"_id":4}}
{"message":"Brown fox brown dog"}
{"index":{"_id":5}}
{"message":"Lazy jumping dog"}
GET my_index/_search
{
"query": {
"match": {
"message": "dog"
}
}
}
검색조건은 디폴트가 or로 들어갑니다.
quick과 dog 둘 다 검색된 결과

119
● operator
And로 검색하려면 operator 이용
{
"query": {
"match": {
"message": {
"query":"quick dog",
"operator":"and"
}
}
}
}

120
● match_phrase
lazy dog와 일치하는 데이터 검색
{
"query": {
"match_phrase": {
"message": "lazy dog"
}
}

121
● slop 옵션
Lazy랑 dog사이의
한 개까지의 검색어를 허용.

122
● query_string
{
"query": {
"query_string": {
"default_field": "message",
"query": "(jumping AND lazy) OR "quick dog""
}
}
}
스코어 (score) 점수
Elasticsearch의 검색 결과에는 스코어 점수가 표시가 됩니다. 이 점수는 검색된
결과가 얼마나 검색 조건과 일치하는지를 나타내며 점수가 높은 순으로 결과를
보여줍니다.

123
● bool query - 복합 쿼리
앞의 query_string 쿼리는 여러 조건을 조합하기에는 용이한 문법이지만 옵션이 한정되어 있습니다. 본문 검색에서 여러 쿼
리를 조합하기 위해서는 상위에 bool 쿼리를 사용하고 그 안에 다른 쿼리들을 넣는 식으로 사용이 가능합니다.
bool 쿼리는 다음의 4개의 인자를 가지고 있으며 그 인자 안에 다른 쿼리들을 배열로 넣는 방식으로 동작합니다.
● must : 쿼리가 참인 도큐먼트들을 검색합니다.
● must_not : 쿼리가 거짓인 도큐먼트들을 검색합니다.
● should : 검색 결과 중 이 쿼리에 해당하는 도큐먼트의 점수를 높입니다.
● filter : 쿼리가 참인 도큐먼트를 검색하지만 스코어를 계산하지 않습니다. must 보다 검색 속도가 빠르고 캐싱이 가
능합니다.

124
bool 쿼리 사용 문법
GET <인덱스명>/_search
{
"query": {
"bool": {
"must": [
{ <쿼리> }, …
],
"must_not": [
{ <쿼리> }, …
],
"should": [
{ <쿼리> }, …
],
"filter": [
{ <쿼리> }, …
]
}
}
}
bool 쿼리로 quick 그리고 "lazy dog" 검색
{
"query": {
"bool": {
"must": [
{
"match": {
"message": "quick"
}
},
{
"match_phrase": {
}
}
]
}
}

125
bool 쿼리로 quick 그리고 "lazy dog" 검색
{
"query": {
"bool": {
"must": [
{
"match": {
"message": "quick"
}
},
{
"match_phrase": {
}
}
]
}
}

126
must, must not

127
should
get일때는 id 순서가 1, 4, 2 순서로 조회됐지만
should 사용시 score 순으로 조회된다.
{
"query": {
"bool": {
"must": [
{
"match": {
"message": "fox"
}
}
],
"should": [
{
"match": {
"message": "lazy"
}
}
]
}
}
}

128
● Exact Value Query - 정확값 쿼리
지금까지 살펴본 풀 텍스트 검색은 스코어 점수 기반으로 정확도(relevancy)가 높은 결과부터 가져옵니다.
Elasticsearch는 정확도를 고려하는 풀 텍스트 외에도 검색 조건의 참 / 거짓 여부만 판별해서 결과를 가져오는 것이
가능합니다. 풀 텍스트와 상반되는 이 특성을 정확값(Exact Value) 이라고 하는데 말 그대로 값이 정확히 일치 하는
지의 여부 만을 따지는 검색입니다. Exact Value 에는 term, range 와 같은 쿼리들이 이 부분에 속하며, 스코어를 계
산하지 않기 때문에 보통 bool 쿼리의 filter 내부에서 사용하게 됩니다.

129
● Exact Value Query - 정확값 쿼리
{
"query": {
"bool": {
"must": [
{
"match": {
"message": "fox"
}
}
],
"filter": [
{
"match": {
"message": "quick"
}
}
]
}
점수에는 영향을 미치지 않고 검색에만 영향
을 미친다.
처음 must 결과를 바탕으로 score 순위는 변
경되지 않고 보기 싫은 검색 결과를 제외할때
filter를 사용한다.

130
● Range Query - 범위 쿼리
POST phones/_bulk
{"index":{"_id":1}}
{"model":"Samsung GalaxyS
5","price":475,"date":"2014-02-24"}
{"index":{"_id":2}}
6","price":795,"date":"2015-03-15"}
{"index":{"_id":3}}
7","price":859,"date":"2016-02-21"}
{"index":{"_id":4}}
8","price":959,"date":"2017-03-29"}
{"index":{"_id":5}}
9","price":1059,"date":"2018-02-25"}

131
GET phones/_search
{
"query": {
"range": {
"price": {
"gte": 700,
"lt": 900
}
}
}
}
Range쿼리 사용
Price가 700이상 900이하인것 검색
gte (Greater-than or equal to) - 이상 (같거나 큼)
gt (Greater-than) – 초과 (큼)
lte (Less-than or equal to) - 이하 (같거나 작음)
lt (Less-than) - 미만 (작음)

132
날짜도 검색 가능
GET phones/_search
{
"query": {
"range": {
"date": {
"gt": "2014-01-01",
"lt": "2017-01-01"
}
}
}
}

133
● 역 인덱스
일반적인 관계형 DB
elasticsearch의 역 인덱싱
역 인덱스는 책의 맨 뒤에 있는, 주요 키워드에 대한 내용이 몇 페이지에 볼 수 있는 찾아보기 페
이지에 비유할 수 있습니다. Elasticsearch에서는 추출된 각 키워드를 term이라고 부릅니다. 이렇
게 역 인덱스가 있으면 fox를 포함하고 있는 도큐먼트들의 id를 바로 얻어올 수 있습니다.

134
● 애널라이저
Elasticsearch는 문자열 필드가 저장 될 때 데이터에서 검색어 토큰을 저장하기 위해 여러 단계의 처리
과정을 거칩니다. 이 전체 과정을 Text 분석(Text Analysis)이라고 하고 이 과정을 처리하는 기능을 애
널라이저(Analyzer)라고 합니다. Elasticsearch의 애널라이저는 0~3개의 캐릭터 필터(character filter)와
1개의 토크나이저(Tokenizer) 그리고 0~n개의 토큰 필터(Token Filter)로 이루어집니다.
텍스트 데이터가 입력되면 가장 먼저 필요에 따라 전체 문장에서 특정 문자를 대치하거나 제거하는데
이 과정을 담당하는 기능이 캐릭터 필터입니다. 문장에 속한 단어들을 텀 단위로 하나씩 분리 해 내는
처리 과정을 거치는데 이 과정을 담당하는 기능이 토크나이저 입니다. 토크나이저는 반드시 1개만 적
용이 가능합니다.

135
● 애널라이저
GET _analyze
{
"text": "The quick brown fox jumps over the lazy dog",
"tokenizer": "whitespace",
"filter": [
"lowercase",
"stop",
"snowball"
]
}
whitespace 토크나이저로 공백 기준으로 분리.
Stop토큰필터로 the같은 필요없는 단어는 토크나이징
과정에서 제외된다. Snowball필터는 형태소 분석.
jumps jumping를 jump로 합쳐준다.

136
● 애널라이저
Jumps를 put 했는데 jumping으로도 검색이 된다.
Snowball 애널라이저로 형태소 분석이 되서 그런건데. jumps가 jump로 저장이 되어있고 jumping을 검색하더라고 jump로 검색을
하기 때문이다. 소문자로 바꾸고 형태소 분리하고 저장되는 순서로 이루어져있다.
하지만 term쿼리를 사용한다면 해당되는 문자만 찾아준다.

137
● 애널라이저
jump로 저장되어 있기에 검색 결과는 null

138
● 애널라이저
_analyze API로 애널라이저, 토크나이저, 토큰필터들의 테스트가 가능하지만, 실제로 인덱스에 저장되는 데이터의 처리
에 대한 설정은 애널라이저만 적용할 수 있습니다. 인덱스 매핑에 애널라이저를 적용 할 때 보통은 이미 정의되어 제공
되는 애널라이저 보다는 토크나이저, 토큰필터 등을 조합하여 만든 사용자 정의 애널라이저(Custom Analyzer)를 주로
사용합니다. 이미 정의된 애널라이저들은 매핑에 정의한 text 필드의 analyzer 항목에 이름을 명시하기만 하면 쉽게 적
용이 가능합니다.
Elasticsearch에 사전에 만들어진 애널라이저들은 https://www.elastic.co/ 홈페이지의 공식 도큐먼트를 참고하시기 바랍
니다. 매핑에 아무 설정을 하지 않는 경우 디폴트로 적용되는 애널라이저는 standard 애널라이저 입니다.
사용자 정의 애널라이저는 인덱스 settings 의 "index" : { "analysis" : 부분에 정의합니다. 생성한 다음에는 해당 인덱스
에서 GET 또는 POST <인덱스명>/_analyze 명령으로 사용이 가능합니다.
다음은 my_index3 안에 whitespace 토큰크나이저 그리고 lowercase, stop, snowball 토큰필터를 사용하는
my_custom_analyzer 라는 이름의 애널라이저를 추가하는 예제입니다.

139
● 사용자 정의 애널라이저
my_index3 안에 whitespace 토큰크나이저 그리고 lowercase, stop, snowball 토큰필터를 사용하는
my_custom_analyzer 라는 이름의 애널라이저를 추가하는 예제입니다.
PUT my_index3
{
"settings": {
"index": {
"analysis": {
"analyzer": {
"my_custom_analyzer": {
"type": "custom",
"filter": [
"lowercase",
"stop",
"snowball"
]
}
}
}
}
}
}

140
● 사용자 정의 토큰 필터
토크나이저, 토큰필터의 경우에도 옵션을 지정하는 경우에는 사용자 정의 토크나이저, 토큰필터로 만들어 추가해야 합니다. 다음은 stop 토큰필터
에 "brown"을 불용어로 적용한 my_stop_filter 사용자 정의 토큰필터를 생성하고 이것을 my_custom_analyzer에서 사용하도록 설정 한 예제입
니다. 아래 명령 실행 전에 기존 my_index3 인덱스는 먼저 삭제해야 합니다.
my_stop_filter 를 생성 후 my_custom_analyzer 에서 사용
PUT my_index3
{
"settings": {
"index": {
"analysis": {
"analyzer": {
"type": "custom",
"filter": [
"lowercase",
"my_stop_filter",
"snowball"
]
}
},
"filter": {
"my_stop_filter": {
"type": "stop",
"stopwords": [
"brown"
]
}
}
}}}}

141
● 사용자 정의 토큰 필터
이제 다시 my_custom_analyzer를 사용해서 텍스트를 분석 해 보면 brown이 불용어 처리가 되어 사라진 것
을 확인할 수 있습니다.

142
● mapping에 사용자 정의 애널라이저 적용
애널라이저를 실제 인덱스에 입력할 데이터에 적용하려면 settings 부분에서 만든 애널라이저를 mappings 의 text 필드별로 지정
합니다. 앞에서 만든 my_custom_analyzer 를 message 필드에 적용하는 방법은 다음과 같습니다. setting 부분은 위 예제와 동일
합니다.
message 필드에 my_custom_analyzer 애널라이저 적용
PUT my_index3
{
"settings": {
"index": {
"analysis": {
"analyzer": {
"type": "custom",
"filter": [
"lowercase",
"my_stop_filter",
"snowball"
]
} },
"filter": {
"my_stop_filter": {
"type": "stop",
"stopwords": [
"brown"
] } }
} } },
"mappings": {
"properties": {
"message": {
"type": "text",
"analyzer": "my_custom_analyzer"
}
} } }

143
● mapping에 사용자 정의 애널라이저 적용
적용 후 brown이 검색되지 않는 것을 확인

144
● nori 한글 형태소 분석기
Nori 개요
Elasticsearch 6.6 버전 부터 공식적으로 Nori(노리) 라고 하는 한글 형태소 분석기를 Elastic사에서 공식적으
로 개발해서 지원을 하기 시작했습니다. 특이하게 nori는 프랑스 엔지니어인 Jim Ferenczi 에 의해 처음 개발
이 되었습니다. Jim 은 아파치 루씬의 커미터이며 Elasticsearch의 일본어 형태소 분석기인 Kuromoji(구로모
지) 역시 Jim 이 처음 개발했습니다. Nori 는 은전한닢에서 사용하는 mecab-ko-dic 사전을 재 가공 하여 사
용하고 있습니다. Nori 는 루씬의 기능으로 개발되었으며 루씬 소스에 반영되어 있으며 개발 이력은
https://issues.apache.org/jira/browse/LUCENE-8231 에서 확인 할 수 있고 프로그램 소스는
https://github.com/apache/lucene-solr/tree/master/lucene/analysis/nori 에서 확인이 가능합니다.

145
● nori 설치
Nori 를 사용하기 위해서는 먼저 elasticsearch에 analysis-nori 플러그인을 설치해야 합니다. elasticsearch 홈 디렉토리
에서 다음 명령을 실행하면 버전에 맞는 nori 플러그인을 받아서 자동으로 설치합니다.
설치 완료 후에 키바나도 재시작 해야합니다

146
● nori 사용

147
● nori 사용
nori는 nori_tokenizer 토크나이저와 nori_part_of_speech, nori_readingform 토큰 필터를 제공합니다. 먼저
nori_tokenizer 토크나이저를 사용해서 한글을 간단하게 테스트 할 수 있습니다. 다음은 standard와 nori_tokenizer
를 비교해서 "동해물과 백두산이" 를 분석한 예제입니다. 당연히 테스트 하는 elasticsearch 에는 analysis-nori 플러
그인이 설치되어 있어야 합니다.
standard 토크나이저로 "동해물과 백두산이" 문장 분석
GET _analyze
{
"tokenizer": "standard",
"text": [
"동해물과 백두산이"
]
}
response
standard 토크나이저로 "동해물과 백두산이" 문장 분석 결과
{
"tokens" : [
{
"token" : "동해물과",
"start_offset" : 0,
"end_offset" : 4,
"type" : "<HANGUL>",
"position" : 0
},
{
"token" : "백두산이",
"start_offset" : 5,
"end_offset" : 9,
"type" : "<HANGUL>",
"position" : 1
}
]
}

148
● nori 사용
nori_tokenizer 토크나이저로 "동해물과 백두산이" 문장 분석
GET _analyze
{
"tokenizer": "nori_tokenizer",
"text": [
"동해물과 백두산이"
]
}
response
{
"tokens" : [
{
"token" : "동해",
"start_offset" : 0,
"end_offset" : 2,
"type" : "word",
"position" : 0
},
{
"token" : "물",
"start_offset" : 2,
"end_offset" : 3,
"type" : "word",
"position" : 1
},
{
"token" : "과",
"start_offset" : 3,
"end_offset" : 4,
"type" : "word",
"position" : 2
},
{
"token" : "백두",
"start_offset" : 5,
"end_offset" : 7,
"type" : "word",
"position" : 3
},
{
"token" : "산",
"start_offset" : 7,
"end_offset" : 8,
"type" : "word",
"position" : 4
},
{
"token" : "이",
"start_offset" : 8,
"end_offset" : 9,
"type" : "word",
"position" : 5 } ] }

149
● nori 사용
Standard 토크나이저는 공백 외에 아무런 분리를 하지 못했지만 nori_tokenizer는 한국어 사전 정보를 이
용해 "token" : "동해", "token" : "산" 같은 단어를 분리 한 것을 확인할 수 있습니다. nori_tokenizer 에는
다음과 같은 옵션들이 있습니다.
user_dictionary : 사용자 사전이 저장된 파일의 경로를 입력합니다.
user_dictionary_rules : 사용자 정의 사전을 배열로 입력합니다.
decompound_mode : 합성어의 저장 방식을 결정합니다. 다음 3개의 값을 사용 가능합니다.
none : 어근을 분리하지 않고 완성된 합성어만 저장합니다.
discard (디폴트) : 합성어를 분리하여 각 어근만 저장합니다.
mixed : 어근과 합성어를 모두 저장합니다.
user_dictionary는 다른 애널라이저들과 마찬가지로 config 디렉토리의 상대 경로를 입력하며 변경시 인
덱스를 _close / _open 하면 반영됩니다. 사전의 단어들에는 우선순위가 있으며 문장 "동해물과" 에서는 "
동해" 가 가장 우선순위가 높아 "동해" 가 먼저 추출되고 다시 "물" 그리고 "과" 가 추출되어 "동해"+"물
"+"과" 같은 형태가 됩니다. user_dictionary 경로에 있는 사전 파일이나 user_dictionary_rules 설정값에
단어만 나열 해 주면 이 단어들을 가장 우선으로 추출합니다

150
● nori 사용 - user_dictionary_rules
PUT my_nori
{
"settings": {
"analysis": {
"tokenizer": {
"my_nori_tokenizer": {
"type": "nori_tokenizer",
"user_dictionary_rules": [
"해물"
]
}
}
}
}
}
동해가 아니라 해물로 저장.
사전에 어떤 사전 룰을 사용해
야 할 지 정하는게 굉장히 중요
합니다.

151
● nori 사용 - tokenizer
decompound_mode 모드를 각각 none, discard, mixed 로 설정한 토크나이저 설정
PUT my_nori
{
"settings": {
"analysis": {
"tokenizer": {
"nori_none": {
"decompound_mode": "none"
},
"nori_discard": {
"decompound_mode": "discard"
},
"nori_mixed": {
"decompound_mode": "mixed"
}
}
}
}
}
nori_none 토크나이저로 "백두산이" 분석. 복합어 그대로 저장
GET my_nori/_analyze
{
"tokenizer": "nori_none",
"text": [ "백두산이" ]
}
nori_discard 토크나이저로 "백두산이" 분석. 백두랑 산 분리
{
"tokenizer": "nori_discard",
}
nori_mixed 토크나이저로 "백두산이" 분석. 다 저장. 백두산. 백두. 산
{
"tokenizer": "nori_mixed",
}

152
● nori 사용 - 수사 제거
my_pos 인덱스에 수사(NR)을 제거하는 my_pos_f 토큰필터 지정
PUT my_pos
{
"settings": {
"index": {
"analysis": {
"filter": {
"my_pos_f": {
"type": "nori_part_of_speech",
"stoptags": [
"NR"
]
}
}
}
}
}
}
my_pos_f 토큰필터로 "다섯아이가" 분석
GET my_pos/_analyze
{
"filter": [
"my_pos_f"
],
"text": "다섯아이가"
}
Stoptags를 NR 수사로 지정. 다섯이 안나온다.
저장을 할때 필요없는 조사 수사 등등을 없애고 싶으면 설정해주자

153
● nori 사용 - nori_readingform
nori_readingform 토큰필터로 "春夏秋冬"(춘
하추동) 분석
GET _analyze
{
"filter": [
"nori_readingform"
],
"text": "春夏秋冬"
}
한자를 한글로 변환하여 저장

154
● nori 사용 - nori_readingform
nori_readingform 토큰필터로 "春夏秋冬"(춘
하추동) 분석
GET _analyze
{
"filter": [
"nori_readingform"
],
"text": "春夏秋冬"
}
한자를 한글로 변환하여 저장

155
● nori 사용 - explain
한글 검색엔진 구현시에는 고려해야 할 사항이 많습니다.

5. Elasticsearch
Mapping, Data type
156

157
5. Elasticsearch mapping, data type
● mapping
pages : long type으로 저장
Author : text type
pages : log 타입으로 맵핑된걸 볼 수 있다

158
● 문자열 - text, keyword
Elasticsearch 에서 선언이 가능한 문자열 타입에는 text, keyword 두 가지가 있습니다. 2.x 버전
이전에 문자열은 string 이라는 하나의 타입만 있었고 텍스트 분석 여부, 즉 애널라이저 적용을
할 것인지 아닌지를 구분하는 설정이 있었습니다. 5.0 버전 부터는 텍스트 분석의 적용 여부를
text 타입과 keyword 타입으로 구분을 합니다. 인덱스를 생성할 때 매핑에 필드를 미리 정의하
지 않으면 동적 문자열 필드가 생성 될 때 text 필드와 keyword 필드가 다중 필드로 같이 생성
됩니다.

159
● text
text 타입은 입력된 문자열을 텀 단위로 쪼개어 역 색인 (inverted index) 구조를 만듭니다. 보통은 풀텍스트 검색에 사용할 문
자열 필드 들을 text 타입으로 지정합니다. text 필드에 설정 가능한 옵션들은 다음과 같은 것들이 있습니다.
"analyzer" : "<애널라이저명>" - 색인에 사용할 애널라이저를 입력하며 디폴트로는 standard 애널라이저를 사용합니다. 토크나이저,
토큰필터들을 따로 지정할수가 없으며 필요하다면 사용자 정의 애널라이저를 settings에 정의 해 두고 사용합니다.
"search_analyzer" : "<애널라이저명>" - 기본적으로 text 필드는 match 쿼리로 검색을 할 때 색인에 사용한 동일한 애널라이저로 검색
쿼리를 분석합니다. search_analyzer 를 지정하면 검색시에는 색인에 사용한 애널라이저가 아닌 다른 애널라이저를 사용합니
다. 보통 NGram 방식으로 색인을 했을 때는 지정 해 주는 것이 바람직합니다.
"index" : <true | false> - 디폴트는 true 입니다. false로 설정하면 해당 필드는 역 색인을 만들지 않아 검색이 불가능하게 됩니다.
"boost" : <숫자 값> - 디폴트는 1 입니다. 값이 1 보다 높으면 풀텍스트 검색 시 해당 필드 스코어 점수에 가중치를 부여합니다. 1
보다 낮은 값을 입력하면 가중치가 내려갑니다.
"fielddata" : <true | false> - 디폴트는 false 입니다. true로 설정하면 해당 필드의 색인된 텀 들을 가지고 집계(aggregation) 또는 정
렬(sorting)이 가능합니다. 이 설정은 다이나믹 설정으로 이미 정의된 매핑에 true 또는 false로 다시 적용하는 것이 가능합니다.
"fielddata": true 설정이 되면 쿼리에 메모리 사용량이 많아지기 때문에 일반적으로는 권장하지 않는 옵션입니다. 그리고 모든 텀
들은 애널라이저가 적용되어 처리된 형태로 집계나 정렬에 사용되기 때문에 특히 정렬 같은 경우 일반적으로 예상하는 정렬과
결과가 다르게 나오는 경우가 많습니다. 집계와 정렬은 항상 keyword 필드로 사용하는 것을 권장합니다.

160
● keyword
keyword 타입은 입력된 문자열을 하나의 토큰으로 저장합니다. text 타입에 keyword 애널라이저를 적용 한 것과 동일합니다.
보통은 집계(aggregation) 또는 정렬(sorting)에 사용할 문자열 필드를 keyword 타입으로 지정합니다. keyword 필드에 설정
가능한 옵션들은 다음과 같은 것들이 있습니다.
index, boost 설정은 text 필드와 동일하게 동작합니다.
"doc_values" : <true | false> - 디폴트는 true 입니다. keyword 값들은 기본적으로 집계나 정렬에 메모리를 소모하지 않기 위해
값들을 doc_values 라고 하는 별도의 열 기반 저장소(columnar store)를 만들어 저장합니다. 이 값을 false로 하면 doc_values
에 값을 저장하지 않아 집계나 정렬이 불가능해집니다.
"ignore_above" : <자연수> - 디폴트는 2,147,483,647 이며 다이나믹 매핑으로 생성되면 ignore_above: 256 로 설정이 됩니다.
설정된 길이 이상의 문자열은 색인을 하지 않아 검색이나 집계가 불가능합니다. _source에는 남아있기 때문에 다른 필드 값을
쿼리해서 나온 결과로 가져오는 것은 가능합니다.
"normalizer" : "<노멀라이저명>" - keyword 필드는 애널라이저를 사용하지 않는 대신 노멀라이저(normalizer) 의 적용이 가능
합니다. 노멀라이저는 애널라이저와 유사하게 settings 에서 정의하며 토크나이저는 적용할 수 없고 캐릭터 필터와 토큰 필터만
적용해서 사용이 가능합니다.

161
text로 저장되어있기에, 띄어쓰기. 대소문자
전부 구분해야한다
PUT books/_doc/1
{
"title": "Romeo and Juliet",
"author": "William Shakespeare",
"category": "Tragedies",
"publish_date": "1562-12-01T00:00:00",
"pages": 125
}
GET books/_search
{
"query":{
"match":{
"title.keyword":"Romeo and Juliet"
}
}
}
GET books/_search
{
"query":{
"match":{
"title.keyword":"Juliet"
}
}
}
Juliet 검색 시 null값 조회되는 모습.

162
● 커스터마이징
GET books/_mapping
DELETE books
PUT books/
{
"mappings":{
"properties" : {
"author" : {
"type" : "text",
"fields" : {
"keyword" : {
"type" : "keyword",
"ignore_above" : 256
}
}
},
"category" : {
"type" : "keyword"
},
"pages" : {
"type" : "short"
},
"publish_date" : {
"type" : "date"
},
"title" : {
"type" : "text"
}
}
}
}

163
● 커스터마이징
PUT number_test
{
"mappings":{
"properties":{
"value":{
"type":"integer",
"coerce": false
}
}
}
}
PUT number_test/_doc/2
{
"value":"ddd"
}
소수점은 반드시 double float으로 지정해준다. Int로 지정하면 표시는 소수로 되더라도 정
수값만 저장이 되어 데이터 조회 시 오류가 날 수 있다.
int 3.4 -> 조회는 3.4로 되지만 3으로 저장되어있음.
Coerce:false옵션을 추가하면 해당 되는 타입이 아니면 데이터가 들어가지 않는다.
우측의 400 status 확인.

6. Logstash 설치 및 기본 설정
164

165
● Logstash
데이터 흐름을 컨트롤 하기 위한 도구
다양한 곳에서 데이터를 수집, 보낼 수 있다 .
https://www.elastic.co/downloads/logstash
https://www.elastic.co/support/matrix#matrix_jvm
wget https://artifacts.elastic.co/downloads/logstash/logstash-7.13.4-linux-x86_64.tar.gz

166
● 파일이름 변경 및 config 디렉토리 확인

167
● Logstash 실행
Logstash는 실행 시 파이프라인을 명시해주어야 한다.
-e 옵션으로
인풋 경로와 아웃풋 경로를 지정해준다.
일단 빈칸으로 실행

168
● Logstash 실행
메세지를 보내본다.
이러한 메세지들은 메시지 필드 안으로 들어간다 . 일단 종료.

169
● 공식 문서 참고
공식 문서에 많은 input, output 정보가 있다. (kafka, tcp 등등)
https://www.elastic.co/guide/en/logstash/current/input-plugins.html

170
● logstash tcp input
111 입력했는데 아까와 달리 메세지가 오지
못한다. logstash가 9900포트를 향해있기 때
문

171
● nc(netcat) 사용
넷캣이란?
● TCP/IP swiss army knife. 네트워크 해킹의 맥가이버같은 도구
● netcat (혹은 nc)은 TCP 또는 UDP를 사용하여 네트워크 연결을 읽고 쓰는 데 사용되는 컴퓨
터 네트워킹 유틸리티
● 윈도우, 리눅스, 맥 등 다른 운영체제 및 스크립트에서 직접 또는 쉽게 구동
● 리눅스나 맥의 경우 기본적으로 내장되어있는 경우가 대다수
● 네트워크 디버깅 및 조사 도구로도 사용 가능함
● 사용자가 필요로하는 거의 모든 종류의 연결을 생성 할 수 있고 여러 내장 기능이 있음.
● 기능 목록에는 포트 스캔, 파일 전송 및 포트 수신이 포함되며 백도어로 사용가능
echo 파이프라인은 echo로 출력한 결과물을 파이
프라인 오른쪽의 input으로 던져주는 것 .

172
● output - elasticsearch
엘라스틱서치 hosts, user, password
저장 후 재실행.

173
● output - elasticsearch
putty 하나 더 키고, 아까와 같은 명령어 입력.
output이 elasticsearch로 지정되어 있어, 아무 메세지도 출력되지 않는다.

174
● kibana로 확인
Get _cat/indices
오른쪽에 logstash 인덱스가 보인다.
메세지 저장 확인
GET logstash-*/_search

175
● logstash - filter
원래 이런식으로 컨피그 파일을 수정하게 되면 logstash를 재시작
해야하는데 yml파일을 수정해서 이러한 불편함을 해결할 수 있다
일단 stdout으로 변경

176
vi logstash.yml
reload 검색
config.reload.automatic : true
로 변경

177
재실행
예제 실습을 위한 아파치 웹 로그 다운로드
https://drive.google.com/file/d/1anN2G31WlQxzCM39RHraYgoLHXbAibWM/view

178
일반적인 아파치 웹로그 형식의 파일이다 이걸 logstash를 통해 보내보자 .

179
테스트로 한줄만 전송. 정상작동 확인.
이제 메세지필드의 텍스트들을 각각의 위치에 맞는 필터로 나누어줘야한다.
그록 필터를 이용한다.

180
● logstash - Grok filter
Grok fileter
https://www.elastic.co/guide/en/logstash/current/plugins-filters-grok.html
%{NUMBER:duration} %{IP:client}
%{IP:client} %{WORD:method} %{URIPATHPARAM:request}
%{NUMBER:bytes} %{NUMBER:duration}
위의 패턴을 Grok이 인식한다.
출처: <https://www.elastic.co/guide/en/logstash/current/plugins-filters-grok.html>

181
input {
tcp {
port => 9900
}
}
filter {
grok {
match => { "message" =>
"%{COMBINEDAPACHELOG}" }
}
}
output {
stdout { }
}
메세지 필드를 그록패턴에 적용(COMBINEDAPACHELOG)
저장을 하면 아까 yml파일에서 수정한 덕분에 알아서 간략하게 재
시작을 해준다. 이제 넷캣으로 넣어보자

182
아까와 달리 메세지 필드 뿐만 아니라 여러 필드가 생겼다.

183
● logstash - Geoip filter
Geoip Filter.
ip 주소만 가지고 다양한 정보를 가지고 오는 필터.
소스를 필수로 적어주어야 한다

184
clientip는 오른쪽의 clientip 태그를 의미한다. 저장 후 다시 nc

185
Geoip 필드가 생성된걸 볼 수 있다
그 아래의 다양한 정보들이 추가되었다.
ip주소만 가지고, 그 ip주소가 어디서 왔는지 그 클라
이언트의 위치가 어디 인지도 알 수 있다.
이를 통해 키바나에서 위치 정보를 알 수 있다.
맨 밑에 에이전트 필드가 있는데 이는 사용자 클라이
언트의 디바이스 정보를 뜻한다
이것도 파싱 가능.

186
● logstash - useragent filter
Geoip와 useragent트는 당연히 Grok보다 나
중에 실행이 되어야 한다.
Grok 밑에다가 적어준다.

187
● logstash - mutate filter
Grok filter는 바이트 필드를 텍스트로 받아오기에 int로 변환해주는 mutate filter를 이용한다.

188
● logstash - mutate filter
timestamp 필드
logstash가 만든 날짜타입이다
저렇게 들어가면 텍스트타입으로 인식하기에
날짜 타입으로 바꿔주는 date필터가 필요하다

189
● logstash - date filter

190
● logstash - date filter
설정 완료 후 elasticsearch로
output 설정 후 logstash 실행

191
● logstash - elasticsearch output
GET _cat/indices
GET logstash/_search

7. Filebeat 설치 및 pipeline 구축
192

193
● beats 설치
https://www.elastic.co/kr/downloads/beats/
각각의 목적에 맞는 beats를 다운받아야 한다.
아파치 웹로그 파일을 받기 위해 filebeat 설치.

194
● yml 파일 설정
아까 저장한 웹로그 샘플을 수집할거고 이걸 엘라스틱
서치로 넣기 위해 로그스태쉬 아웃풋으로 지정했던 엘
라스틱서치 호스트 정보와 유저네임 패스워드 입력 후
저장.

195
● Filebeat 실행
실행하면 아무 메세지도 발생하지 않지만, 실행중인 상태.
키바나로 확인할 수 있다.

196
● Filebeat 실행 - Kibana로 확인
30만건의 데이터가 들어오는 중. 현
재 15만건정도 들어온 상태. 속도가
굉장히 빠르다

197
● pipeline 구축
이런식으로 beats는 빠르게 데이터를 수집한다.
beats에서 수집한걸 logstash보내서 우리가 만든 필터를 태워 elasticseasrch로 보내는 구조로 실습.
filebeat.yml파일 수정
logstash, filebeats 모두 같은 호스트니까
같게 적어준다.
주석 제거 꼭 해주자.

198
● pipeline 구축
workshop.conf 수정.
이렇게 하면 로그스태쉬는 비츠를 입력받고 필터링을 통해서 엘라
스틱서치로 보내게 된다
비츠에서 에이전트필드도 엘라스틱서치로 보내게 되는데 이는 엘
라스틱서치가 수집한 호스트 정보이다.
이 때 중복이 나기 때문에 오류가 생긴다.
그래서 그록 콜 실행하기 전에 에이전트 필드를 지워주도록 하자.

199
● pipeline 구축
비츠에서 수집한 에이전트 필드를
삭제해주고 그로크를 태우는 형식

200
● pipeline 구축
스탠다드 아우풋을 띄워놓게 되면 30만건의 로그가 계
속 뜨니까 정신없다 이럴 때 코덱을 사용하게 되면 데
이터가 정상적으로 가는지의 여부만 확인할 수 있다
하나의 이벤트당 점 하나로 보이는 dots코덱 사용
코덱의 디폴트는 루비디버그다(이전에 보던 형식)

201
● pipeline 구축
불필요한 필드를 지워주고, 인덱스 이름에 날짜가 자동
으로 입력되도록 수정한다.

202
● pipeline 구축 후 재실행
재실행 시 유의 : filebeat는 읽어온 데이터는 다시 읽어오지 않는다. 플래그 마킹을 지워주자.
data 디렉토리 삭제

204
8. 재색인
● pipeline 실행 후 kibana로 확인
이제 샘플데이터의 데이트타임에 따
라 아파치로그의 인덱스들이 생기게
된다

205
● 재색인 - reindex
로케이션 필드는 float이 아니라
geopoint 필드로 들어가야 한다. 다이나
믹 맵핑으로 형성이 되서 깔끔하지 못한
모습. 재색인을 통해 변경하자.
8. 재색인

206
1. 복사
2. PUT mylog
{
사이에 붙여넣는다
}
8. 재색인

207
클라이언트 아이피는 삭제한다
geoip 안에 아이피정보가 이미 들어있기 때문
ecs도 삭제
8. 재색인

208
나라 코드는 집계의 가능성이 있으므로 키워
드로 변경.
위치정보도 타입 변경.
8. 재색인

209
input은
삭제
8. 재색인

210
log 파일비트에서 생성되는 로그. 삭제
메세지 필드는 키워드로 저장할 일이 없다.
텍스트만 남겨두고 다 지운다
type : keyword만 입력 후 나머지 드래그 부분 삭제
8. 재색인

211
설정 끝. 해당 구문 실행
8. 재색인

212
source : mylog, dest : 아파치 로그 지정
아파치 로그 확인 - 재색인 완료.
8. 재색인

9. Elasticsearch
index template, scripts
213

214
9. Elasticsearch Index template, scripts
● 앞에서 전송했던 모든 아파치 로그 인덱스들을 위에서 진행했던 형태로 맵핑해준다.
Index template을 사용하면 편리하다.
template 안에 기존의 맵핑정
보를 붙여넣어준다.
붙여넣기
복사

215
상단에 있는 PUT 명령어를 실행해서 템플릿이 만들어졌고
중단에 있는 reindex를 통해 다이나믹 맵핑이 생성되었다
하단에 있는 GET 명령어 실행시 우리가 설정한 템플릿대로 맵핑이 되어있는걸 볼 수있다
apache log 뒤의 여러 datetime이 존재한다.
이걸 mylogs 인덱스 하나로 묶을수는 없다. 이 부분에서 변경이 필
요하다.

216
● apache log를 한꺼번에 가져와서 mylogs 날짜별로 묶을 수 있다.
이런식으로 입력하게 되면 source에선 문제
되지 않지만, dest 부분에서 오류가 난다. 이
경우 scripts를 사용한다.
일단 mylogs는 삭제한다.

217
● scripts
POST _reindex
{
"source": {
"index": "apachelog-*"
},
"dest": {
"index": "mylogs"
},
"script": {
"lang": "painless",
"source": "ctx._index =
'mylogs-' +
(ctx._index.substring('apachelog-'.length(),
ctx._index.length()))"
}
}
apachelog 앞부분 제외, 뒤의 날짜만 mylog 뒤에 붙인다.
실행하기 전, 이전에 지웠던 필드들을 파이프라인을 통해서 지운 후에
mylogs로 넘어가게 해야 한다.

218
● ingest pipeline
{
"processors": [
{
"remove": {
"field": ["clientip", "ecs",
"input", "tags", “log”]
}
}
]
}

219
● 실행 시 다소 시간이 소요된다. 502 bad gateway 에러가 뜨는데 단순 http 에러니 무시해도 좋다.
sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss

220
● 재색인 확인
이전에 변경했던 맵핑값들이 잘 들어간걸 확인할 수 있다.
색인이 잘못되면 다시 재색인을 해야한다 .
엄청난 대용량의 경우 시간낭비가 심하니까 전체 색인 전에 하나씩 혹은 일부만 미리 진행해본다.

222
10. Kibana 활용하기
● create index pattern
Stack Management / Index Patterns / Create index pattern 클릭.

223
● 인덱스 패턴을 만들어주어야 키바나에서 제공하는 다양한 시각화 자료를 볼 수 있다.
날짜 필드를 선택해주는것이 중요하다
키바나는 기본적으로 시계열 데이터를 가정하고 만들기 때문에
날짜 타입을 하나 지정해주어야 해당 데이터의 기준이 된다

224
● 필드정보 확인 / Discover 메뉴로 이동

225
● Discover
데이터가 나타나지 않는데 이는 최근 한시간 데이터를 기준으로 잡고 있기 때
문이다. 오른쪽 필터에서 날짜를 최근 1년으로 바꾸어준다.
후에 Update

226
● Discover
날짜 기준으로 나온다.
키바나는 모든 메뉴에 타임피커기능이 있다.
그걸로 날짜를 지정해주자.

227
● Discover
드래그해서 범위를 좁힐 수 있다
discover 메뉴는 해당하는 인덱스의 필드를 볼 수 있
고 각각의 도큐먼트들의 내용을 살펴볼 수 있다 . 원하
는 필드만 볼 수도 있다.

228
● Discover
검색 기능과 쿼리를 사용할 수 있다.

229
● Discover
필터를 저장해놓으면 일시적으로 필터를 끌 수도 있고 여러
모로 편리하다 . 해당 필터와 반대되는 결과를 얻을수도 있
다. (exclude results)

11. Kibana dashboard (참조)
230

231
11. Kibana dashboard
● dashboard

232
● Metric 추가

233
● source 선택
metric은 기본적으로 도큐먼트 카운트 값을
가져온다 몇가지 더 추가해보자.

234
● add aggregations

235
● add aggregations

236
● save visualization

237
● save dashboard

238
● stack management / Kibana / index pattern 이동.

239
● bytes 필드 설정
설정 후 세이브

240
● bytes 필드 설정

241
● bar chart 추가
우측
edit / create 클릭.
timestamp, response
드래그 해서 넣기.

242
● bar chart 추가
같은 대시보드에 잇는 패널들은 규격을 통일
시켜주는게 좋다. 나중에 검색하기 좋음

243
● donut chart 추가

244
● donut chart 추가

245
● treemap chart 추가

246
● treemap chart 추가

247
● dashboard 저장

248
● 지도 추가
우상단 add layer 클릭
집계 - Clusters and grids

249
● 지도 추가
세이브

250
● 지도 추가
세이브

251
● 지도 추가
하단에서 컬러 바꾸고 세이브 .

252
● dashboard 확인

253
● filter 사용
드래그 하게 되면 해당 지역별로 데이터가 바뀐다.
필터를 적용한 후 대시보드를 저장하게 되면 이전 데이터로 돌릴 수 없다. 주의하자

254
● filter 저장
자주 사용하는 필터를 미리 저장해 놓을 수 있는 기능이 있다
controls 클릭

255
● filter 저장
response 추가 device 추가

256
● filter 저장
렌더 슬라이드로 바이트 값 추가.
우측 상단 save 클릭. 라이브러리에 추가

257
● add from library
dashboard로 돌아가서, add from library 클릭. 필터 추가

12. KAFKA로 output 지정하기
258

259
● logstash를 이용, elasticsearch의 데이터를 kafka topic으로 전달.
hadoop01 Filebeat, Logstash, Elasticsearch,
kafka,zookeeper
hadoop02 Elasticsearch, kafka, zookeeper
hadoop03 Elasticsearch, Kibana, kafka, zookeeper

260
● Elasticsearch input 지정하기 / 공식 문서 확인
input {
# Read all documents from Elasticsearch matching the given
query
elasticsearch {
hosts => "localhost"
query => '{ "query": { "match": { "statuscode":
200 } }, "sort": [ "_doc" ] }'
}
}

261
● Elasticsearch input 지정하기 / standard output으로 테스트.
당연한 것이지만 패스워드를 입력하지 않는 경우 데이터
를 받아올 수 없다.
mylogs-2020.08.08 인덱스에서 404 응답을 가진 데이터
만 가져온다.

262
● Elasticsearch input 지정하기 / standard output으로 테스트.
정상 작동. input 지정 완료.

263
● kafka topic으로 output 지정하기 / 공식 문서 확인

264
● kafka 실행 / topic 생성 / output 지정

265
● consumer 생성
데이터 전송 완료.

266
● 전체 데이터 전송하기. (404 response)

13. Nifi / Elasticsearch / kafka 연동
267

(참고) Elk stack 설치 및 kafka

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to (참고) Elk stack 설치 및 kafka

Similar to (참고) Elk stack 설치 및 kafka (20)

(참고) Elk stack 설치 및 kafka