[ELK] 키바나 5.0 배우기

키바나는 Elastic Stack의 일부분으로, 저장 계층인 Elastic Search에 색인된 데이터 위에서 시각화 계층을 제공합니다.

 

데이터는 다양한 형태와 규모로 다가옵니다. 통신 업계의 경우, 10만 개의 네트워크 디바이스에서 수집한 데이터로부터 서비스 품질을 분석하는 프로젝트는 흔히 볼 수 있습니다.

 

 - 빠르게 증가하는 데이터를 취급하기 위해 복잡성을 어떻게 줄일 것인가?

 - 가장 효과적이면서 실시간으로 데이터를 시각화하기 위해 조직은 어떻게 해야 할까?

 

대부분의 애플리케이션은 위치와 프로파일에 기반을 둔 추천 항목을 만드는데 관련된 다양한 기술 계층에서 데이터를 생산합니다. 이들 위에서 돌아가는 모든 컴퓨터와 프로세스와 애플리케이션은 CPU 틱이나 사용자의 클릭에 의해 효과적으로 시스템의 '현재' 상태를 파악하면서 계속해서 데이터를 생산해내고 있습니다.

 

컴퓨터에 물리적으로 존재 대량의 데이터 ->  데이터를 추출 -> 잘알려지지 않은 데이터 형식을 변환 -> 집중화된 접근을 위해 이를 저장

 

이벤트 트리거를 통한 기능적 처리에 기반을 둔 시스템에서 이러한 데이터 스트리밍의 흐름은 확장할 수 있고, 분산 방식으로 적재/변환/저장/접근하는 적절한 아키텍처가 필요합니다.

 

이제는 관계형 데이터베이스 구축이 아닌, 처리량에 기반을 둔 on-demand 분산 데이터 저장소로 데이터 패러다임이 전환되었습니다. 밤사이의 배치 처리 데이터만이 아닌, 실시간 통찰(real-time insight)에가깝게 데이터를 시각화하는 반복적 접근법을 논합니다.

 

End-User는 쿼리 응답을 실시간으로 유지하는 동안에도 갈수록 더 많은 양의 데이터 처리가 필요해짐에 따라, 낮은 확장성이나 성능을 이유로 전통적인 관계형 데이터베이스나 데이터웨어하우스 솔루션에서 멀어지고 있습니다. 솔루션은 쉽게 분산되고 클러스터링된 데이터 저장소에서 점점 더 많이 발견됩니다.

 

각 애플리케이션 로그 데이터는 시스템 로그(syslog)처럼 중앙 집중화된 방식일 때도 있고 모든 로그가 여러 인프라에 걸쳐 퍼져 있을때도 있어, 데이터 스트림에 단일 지점으로 접근하기가 어렵습니다.

 

 - 위치: 로그는 어디에 저장되어 있는가?

 - 권한: 로그에 접근할 수 있는가? 그렇지 않다면 누구에게 연락해야 하는가?

 - 로그 구조의 이해

 

로그의 핵심을 추출하는 방법은 여러가지가 있습니다. 대다수의 사람들은 단순 문자열 패턴 검색(grep)을 사용하는데, 기본적으로는 로그에서 일치하는 패턴을 정규표현식으로 찾으려 시도합니다. 단일 로그 파일에서는 잘 동작하겠지만, 로그 파일을 로테이트하거나 일정 기간 범위에서 통찰을 얻고 싶거나 하나 이상의 애플리케이션이 있고 서로 연관 관계를 만들려고 한다면 확장성은 떨어집니다.

 

grep이 편리하긴 하지만, MTTR(Mean Time To Recovery)를 줄이기 위해 실패에 빠르게 반응해야 하는 요구사항에 명백히 적합하지는 않습니다. 예를 들어, 전자상거래 웹사이트의 구매 API에 관한 중대한 문제로 사용자가 특정 페이지에서 긴 latency를 경험한다거나 최악의 경우 구매 과정 마지막에서 직행할 수 없다면? 수 기가바이트의 로그에서 원인을 찾아서 애플리케이션 복구 시도까지 걸리는 시간은 잠재적인 금전적 손실로 이어질수 있습니다.

 

또 다른 잠재적 문제는 보안 북석의 부족으로 애플리케이션에 무작위 공격을 시도하는 IP를 블랙리스트에 등록할 수 없다는 점입니다. 한 그룹의 IP가 매일 밤 시스템에 침투하려 시도하고 있었음을 모르는 사례가 발생할 수도 있습니다. 지도에서 IP를 시각화할 수 없었고 그 값을 기반으로 경고를 발생시킬 수도 없는 경우라면 말입니다.

 

시스템을 보호하기 위해 단순하지만 상당히 효과적인 패턴은 리소스나 서비스 접근을 내부 시스템만으로 제한하는 것입니다. 알려진 IP 주소로 접근하는 화이트 리스트 기능은 필수적입니다.

 

이러한 가시성과 제어의 부족, MTTR 증가, 고객 불만족, 재정적인 영향, 보안 누설, 나쁜 응답 시간과 사용자 경험 같은 요구사항에 대해 탄탄한 시각화 계층을 갖춘 적절한 데이터 기반 아키텍처를 제공하지 않는다면 치명적인 결과를 초래할 수 있습니다.

 

---

 

- 경량화는 실제 데이터를 생성하는 프로세스와 리소스를 경쟁하지 않아야 하는데, 그렇지 않다면 기대하는 처리 성능에 못 미칠 수 있다.

- 수많은 데이터 운송 기술이 나와있는데, 어떤 것은 특정 기술에 종속적이고, 어떤 것은 특정 데이터 소스에 상대적으로 조정 가능한 확장성 있는 프레임워크에 기반을 둔다.

- 데이터 운송은 네트워크로 데이터를 전송하는 것뿐만 아니라, 보안과 관련해서 종단 간 보안 파이프라인으로 데이터가 적절한 목적지로 전송됐는지도 확인하는 것이다.

- 데이터 운송의 또 다른 측면은 데이터 적재 관리다. 데이터 운송은 종착지에서 처리할 수 있는 수준을 고려해서 전송해야 한다. 이 기능은 Back Pressure 관리라 부른다.

 

 

- 일반적으로, 수집 계층은 플러그인 집합의 도움으로 다양한 데이터의 원천 및 목적지와 통합하기 쉬운 플러그 가능한 아키텍처(pluggable architecture)를 갖는다. 어떤 플러그인은 shipper로부터 데이터를 수신하기 위해 만들어진다. 즉 데이터가 항상 운송자로부터 수신되는 것은 아니고, 파일이나 네트워크, 데이터베이스 같은 데이터 소스로부터 직접 올 수도 있다는 뜻이다. '파일로부터 데이터를 수집하기 위해, 운송자나 파이프라인을 사용해야 하는가?'는 경우에 따라 모호할 수 있는데, 사용 사례와 기대하는 SLA(Service Level Agreement)에 따라 다를 것이다.

- 수집 계층은 데이터 구문 분석(parsing), 데이터 형식 지정(formatting), 다른 데이터소스와 연관관계 만들기 및 저장 전에 데이터 정규화(normalizing)와 강화(enriching)로 데이터를 준비하는데 사용할 수 있다. 이는 수많은 장점이 있지만, 가장 중요한 건 데이터 품질을 향상할 수 있어 시각화에 관한 더 나은 통찰을 제공한다는 데 있다. 또한 향후 값을 선행 처리하거나 참조를 조회하는 등의 처리 오버헤드를 제거할 수 있다는 장점도 있다. 단점은, 시각화를 위해 데이터가 적절하게 형식화나 강화되지 않았다면 데이터를 다시 처리해야 한다는 것이다. 물론 데이터를 수집한 이후에 다시 데이터를 처리하는 방법도 있다.

- 데이터 수집과 변환은 연산 리소스를 소모한다. 대개 unit 당 최대 데이터처리량 측면에서 이를 고려해야 하고, 다수의 수집 인스턴스에 대한 부하 분산 계획을 세워야 한다. 이는 실시간(정확하게는 준 실시간) 시각화 측면에서 매우 중요하다. 다수의 인스턴스에서 분산 수집한다면, 데이터 저장 속도를 가속할 수 있어서 결국 시각화가 더 빨라진다.

 

 

- 확장성은 주된 측면이다. 저장소는 데이터의 GB, TB, PB로 시작할 수 있는 다양한 데이터 볼륨으로 사용한다. 확장성은 수평적이다. 다시 말해, 수요와 볼륨이 증가하면 더 많은 머신을 추가해 끊임없이 저장소의 용량을 증가시킬 수 있어야 한다.

- 대부분 경우, 다양한 데이터 유형과 다량의 볼륨에서 분석과 빠른 데이터 접근을 가능케 하는 NoSQL 데이터 저장소로 불리는 비 관계형이면서 고도로 분산된 데이터 저장소가 사용된다. 데이터는 데이터 읽기 또는 쓰기 동안 부하의 균형을 맞추기 위해 나누어져 여러 머신의 집합에 분산된다.

- 데이터 시각화를 위해 저장소는 데이터를 분석하는 API 제공이 필수적이다. 시각화 계층은 주어진 차원(집계)으로 데이터 그룹을 만드는 등의 통계적 분석을 하지만, 확장성은 없을 것이다.(시각화 계층은 저장 계층이 제공하는 API를 호출하는 역할을 할 뿐 데이터 처리의 확장성과는 관련성이 낮다)

- API의 특성은 시각화 계층에서 무엇을 기대하는지에 달렸지만, 대부분의 경우 집계에 관한 것이다. 시각화는 저장소 수준에서 실행한 무거운 작업의 결과만 렌더링한다.

- 데이터 기반 아키텍처는 다양한 애플리케이션과 사용자에게 다양한 수준의 SLA(Service Level Agreement)로 데이터를 공급할 수 있다. 이러한 아키텍처에 있어 고가용성은 확장성과 마찬가지로 이제는 표준이 되었으므로 솔루션의 일부가 돼야 한다.

 

 

- 경량이며, 저장 계층에서 처리하는 결과만을 렌더링한다.

- 사용자가 데이터를 탐색하게 하고, 데이터로부터 통찰력을 빠르게 도출하게 한다.

- 데이터로의 적절한 요청을 구현하는 것이 아니라, 데이터에 예상 밖의 질문을 던지는 시각적인 방법을 제공한다.

- 현대의 데이터 아키텍처는 가능한 한 빨리 KPI에 접근하는 요구사항을 처리해야하고, 시각화 계층은 준 실시간으로 데이터를 만들어야 한다.

- 시각화 프레임워크는 확장 가능해야 하고, 사용자가 기존 자산을 사용자 정의하거나 필요에 따라 새 기능을 추가할 수 있어야 한다.

- 사용자는 시각화 애플리케이션 외부로 대시보드를 공유할 수 있어야 한다.

 

 

 

여타 시각화 도구와 비교했을때 키바나의 주된 차이점은 이러한 스택의 모든 계층이 완벽하게 통합된 Elastic Stack의 풀 스택으로 제공된다는 것인데, 이러한 아키텍처의 배치조차도 쉽게 할 수 있다.

 

- 하둡 분산 파일 시스템은 연속적인 읽기와 쓰기 파일 시스템으로, 무작위 접근에 도움이 안된다.

- 대화형 즉성 쿼리나 기존 실시간 API조차도 시각화 애플리케이션 통합측면에서 확장성이 없다. 대부분의 경우 사용자는 시각화하기 위해 하둡 외부로 데이터를 추출해야 하고, 일부 시각화는 HDFS와의 투명한 통합을 요구하는데, 내부적으로 데이터를 추출해서 배치로 메모리에 적재한다. 이는 상당히 무겁고 느린 사용자 경험을 제공한다.

- 데이터 시각화는 모두 데이터로의 쉬운 접근 및 API와 관련되어 있는데, 그런 측면에서 하둡은 사용자가 항상 구현해야 하므로 썩 훌륭해 보이지는 않는다.

 

---

 

Elastic Stack의 개요

 

ELK라 부르는 elastic stack은 데이터 기반 아키텍처를 구현하는데 필요한 다양한 계층을 제공합니다.

 

Beats, Logstash, ES-Hadoop 커넥터의 수집 계층으로부터 Elastic Search의 분산 데이터 저장에서 시작해, 마지막으로 Kibana로 시각화 합니다. 키바나는 단지 하나의 구성요소일 뿐입니다. 

 

(Beats / Logstash / ES-Hadoop) -> (Elastic Search) -> (Kibana)

 

 

 

 

1. 일래스틱서치

---

Elastic Search는 키바나의 시각화에서 사용하는 모든 집계 결과를 추출하는, 분산되고 확장 가능한 데이터 저장소이다. 본래 탄력적이며 확장 가능하도록 설계되어 있어, 필요에 따라 노드를 elasticsearch 클러스터에 아주 쉬운 방식으로 추가할 수 있다. Elastic Search는 고가용성 기술이다.

 

- 복제되어 실패했을 경우 최소한 하나의 데이터 복제본은 여전히 남아있다.

- 분산 특성으로 인해 일래스틱서치는 서비스 연속성과 SLA 보장을 위해 색인과 검색을 클러스터 노드로 부하 분산할 수 있다.

 

Elastic Search는 구조화된 데이터와 구조화되지 않은 데이터를 다룰 수 있다. 키바나에서 데이터를 시각화하면, 데이터 또는 Elastic 용어를 사용하는 다큐먼트가 JSON 도큐먼트 형태로 색인된다는 사실을 알게 될 것이다. JSON은 중첩 도큐먼트, 배열 등을 지원하므로 복잡한 데이터 구조를 다루는데 매우 편리하다.

 

Elastic Serach Doc: https://www.elastic.co/guide/en/elasticsearch/reference/current/docs.html

 

키바나는 각 시각화를 위해 클러스터에 대한 요청을 만든다. Elastic Search의 마지막 주요 측면은 GB에서 PB까지 모든 범위의 데이터 규모에서 다양한 API와 함께 작업 가능한 실시간 기술이라는 것이다.

 

키바나 외에도 데이터 위에서 시각화를 구현하기 위해 Elastic Search가 제공하는 오픈 API를 활용할 수 있는 수많은 솔루션이 있다. 그러나 키바나는 Elastic Search 전용의 유일한 기술이다.

 

 

2. 비트

---

Beats는 애플리케이션/머신/네트워크 같은 다양한 소스로부터 데이터를 전송하는 경량의 데이터 Shipper다. 비트는 오픈소스 라이브러리인 libbeat 기반으로 구축되는데, 다음 그림처럼 모든 비트가 이를 통해 ElasticSearch로 데이터를 전송한다.

 

 

패킷비트: 기본적으로 네트워크 연결을 통해 MySQL./HTTP 같은 특정 프로토콜의 패킷을 수집한다. 기본적으로 문제의 프로토콜을 모니터링하는데 사용되는 모든 기본 메트릭을 수집한다. 예를 들어, HTTP의 경우 요청과 응답을 도큐먼트로 만들어 ElasticSearch에 색인한다.

 

파일비트: tail 명령처럼 동작해서 파일 내용을 A에서 B로 안전하게 전송한다. 파일에서 ElasticSearch로 직접 데이터를 보내는 새로운 수집 노드와 함께 이 비트를 사용해, 색인하기 전에 데이터를 처리할 것이다. 비트가 처음으로 데이터를 전송해 message broker에 넣으면, ElasticSearch가 색인하기 전에 Logstash가 처리한다. 아키텍처는 파일비트와 수집 노드 2개의 구성요소로 줄어들 수 있고, 키바나에서 수집한 내용을 시각화할 수 있다.

 

탑비트: 머신이나 애플리케이션 실행 metric을 ElasticSearch로 전송하는 MetricBeat의 한 종류다. 키바나에서 랩톱의 데이터를 전송하고 시각화해볼 수도 있다. 이 비트가 표준 도큐먼트를 생성하므로 키바나에서 입력돼야 하는 사전 제작된 템플릿이 딸려 있다는 장점이 있다.

 

비트 목록(https://www.elastic.co/guide/en/beats/libbeat/current/beats-reference.html)

 

비트는 기본적인 필터링만 제공하고 LogStash 수준의 변환은 제공하지 않는다.

 

 

3. 로그스태시

---

Logstash는 중앙 집중된 데이터 처리 패러다임을 포괄하는 데이터 프로세서로, 200여 개 이상의 플러그인 도움으로 사용자가 수집, 강화/변환 및 목적지로의 데이터 전송을 담당한다.

 

 

Logstash는 비트를 비롯한 어떤 소스로부터든 데이터를 수집할 수 있고, 모든 비트는 로그스태시와 바로 통합할 수 있다. Beat는 데이터 운송을 책임지고 Logstash는 색인 전에 데이터 처리를 담당한다.

 

 

4. 키바나

---

키바나에서 모든 사용자 인터페이스 행위가 발생한다. 대부분의 시각화 기술은 분석 처리를 다루지만, Elastic Search가 분석처리를 하고 키바나는 이를 렌더링하는 웹 애플리케이션일 뿐이다. 키바나는 Elastic Search로부터 데이터를 로드하지 않고 처리하며, 모든 무거운 작업은 ElasticSearch의 성능을 이용할 뿐이다. 기본적으로 규모있는 실시간 시각화가 가능하고, 데이터가 증가하면 ElasticSearch 클러스터는 SLA에 따라 최선의 응답 시간을 제공하도록 상대적으로 확장된다.

 

 

키바나는 ElasticSearch 집계에 시각적 능력을 부여해서 시계열 데이터 집합이나 데이터 필드 일부분을 쉽게 원형 차트로 만든다. 키바나는 색인된 도큐먼트를 파헤치면서 데이터를 발굴한다. 대시보드에서 다양한 시각화를 작성하면서 분석 경험을 쌓을 수 있다.

 

키바나의 플러그인 구조는 확장성이 좋다. 키바나가 데이터를 분석할 뿐만 아니라 Elastic Stack을 모니터링하고, Document 간 관계를 만들고, Metric 분석도 한다는 사실을 알게될 것이다. Elastic Search는 Kibana가 지원하는 유일한 DataSource다.

 

---

 

Kibana 구조

 

 

키바나 핵심 기능: Discover, Visualize, Dashboard, Console

키바나 플러그인: Timelion, Graph, Monitoring, elastic, Logout

 

데이터입력 -> 색인 패턴 작성 -> 데이터 탐색 -> 시각화 작성 -> 대시보드 작성 -> 추가적인 시각화

Import data -> Create Index Pattern -> Discover data -> Create Viz -> Create Dashboards -> more Viz

 

- 사용자가 아직 데이터를 갖고 있지 않다면, CSV Importer를 사용해 입력할 수 있다.

- Elastic Search에 데이터가 이미 있다면, 사용자는 색인 패턴을 만들어야 한다. 색인 패턴의 개념이 실제 색인 구조 위에 메타 구조를 기술한다. 이는 키바나가 데이터 계층을 추상화하는 용도로만 사용한다. 이렇게 해서 키바나는 데이터 계층에 영향을 주지않고 시각화 계층에서만 사용자 지정을 허용한다.

- 그런 다음 사용자는 Discover 탭에서 데이터를 탐색하고, 시각화의 일부분으로 사용될 수 있는 어떤 term과 metric이 있는지 찾는다. Discover 탭에서 사용자는 UI 구성요소를 통해 데이터를 쿼리하고 필터링하고 Data 뷰를 만들고 이름을 지정해서 저장할 수도 있다.

- 계속해서 사용자는 시각화탭에서 데이터를 표현할 시각화 유형을 선택한다. 근본적으로 궁금한 사항을 질문하고 패턴으로 시각화하는 방식을 제공한다.

- 모든 궁금한 사항은 저장된 시각화 목록으로부터 drag and drop으로 대시보드에 넣는데, 여기서부터 시각화 경험이 시작된다.

- 시각화의 기타 기능은 Graph와 Timelion처럼 플러그인으로 제공한다.

 

 

Discover

---

Discovr 섹션은 ElasticSearch에서 어떤 데이터를 색인하면 데이터를 탐색하기 위해 가장 먼저 확인하게 되는 메뉴입니다.

 

1. 색인 패턴. 여기서는 metricbeats-*를 사용한다.

2. 색인 내에 있는 필드, 필드 이름을 클릭하면 필드 상위 값들을 엿볼 수 있다. 

3. 시간에 따른 이벤트 개수(날짜 히스토그램 형태). 기간은 화면 좌상단에 있는 시간 선택기로 설정한다.

4. 색인된 도큐먼트. 단일 항목을 확장하면 도큐먼트 상세 설명을 볼 수 있다.

 

 

여기서 MetricBeat로 Document를 생성한 모습을 볼 수 있는데, 맥북의 시스템 메모리 같은 실행 메트릭을 모두 수집/저장한 것이다.

 

 

Visualize

---

시각화 섹션은 색인된 데이터 위에서 시각화를 만드는 장소다. 이미 저장해둔 시각화가 있고 수정하고 싶다면, 메뉴 하단에서 찾을 수 있다. 시각화를 만들어 뒀다면, 다음은 대시보드를 작성하는 것이 일반적인 과정이다.

 

 

Dashboard

---

이전에 만들어둔 시각화를 함게 넣어 대시보드를 만들 수 있다. 5.0에서 키바나 대시보드는 사용되지 않은 많은 공간을 제거해 더 많은 공간을 제공한다. 이는 사용자에게 더 넓은 시각화 경험을 제공한다. 색상 사용은 간소화됐는데, 다시 말하자면 현대화됐다고 볼 수 있다.

 

새로 만들고, 저장하고, 기존 대시보드를 열 수 있으며, 이전 버전 키바나처럼 기존 포털에 통합되는 링크나 iFrame 형태로 이를 공유할 수도 있다. Export PDF 옵션을 이용하면, 대시보드를 PDF 파일로도 내보낼 수 있다.

 

 

Timelion

---

타임라이온은 타임라이온의 메트릭 분석 시각화 구성요소다. 타임라이온의 시각화 작성이 표현식 기반이라 키바나 시각화와는 완전히 다른 경험을 제공한다. 사용자는 단일 또는 더 많은 DataSource로부터 데이터를 읽어오거나 수학 함수를 적용하는 표현식을 조합해 시계열 데이터로부터 통계를 만들 수 있다. 표현식의 결과는 고도로 사용자 정의가 가능한 시각화다.

 

보다시피 타임라이온에는 표현식 바가 있는데, 시각화를 만드는 API를 제공한다. 외부 데이터 소스를 사용하는 방법도 살펴볼텐데, 이 역시 키바나 시각화에서 할 수 있는 기능은 아니다.

 

 

Management

---

이전에는 settings 섹션이었던 Management 섹션은 다음 그림과 같이 데이터, ElasticSearch, Kibana의 모든 관리 옵션을 포함한다.

 

 

Monitoring

---

엑스팩이 제공하는 모니터링 플러그인에서 사용자는 애플리케이션 상태와 리소스 소비 같은 최상위 수준 메트릭의 고수준 시점에서부터 주어진 인스턴스 수준까지 ElasticSearch와 Kibana 실행 상태를 추적할 수 있다.

 

동시 접속 수 같은 키바나 모니터링이 제공하는 매트릭을 볼 수 있다. 이는 IT 조직이나 문제의 실사례를 진단하는 데 키바나를 사용하는 모든 사용자에게 문제가 발생했을때 추적해야 하는 주요한 지표가 될 수 있다.

 

 

---

 

키바나 5.0 비즈니스 분석

 

로그는 타임스탬프와 설명을 포함하는 이벤트다. 연속적으로 저널이나 로그 파일에 추가되는데, 로그의 모든 라인은 타임스탬프를 기반으로 정렬된다. 가장 대표적인 예를 아파치 서버 로그라 할 수 있는데, 로그를 이용하여 특정 정보의 의미를 추정할 수 있다. 이러한 모든 정보는 서버의 트래픽 분석, 의심스러운 행위 탐지, 웹사이트의 사용자 환경을 개선하기 위한 데이터 활용 같은 다양한 목적에 있어 중요하다.

 

로그 분석의 실질적인 솔루션으로 시각화 애플리케이션이 자리 잡기 전에는, 일반적으로 IT 운영 팀은 핵심 의미를 추출하기 위해 데이터에서 수많은 grep 명령을 만들었다. 그러나 이는 grep만으로 감당 못할, 인간의 능력으로는 실현 불가능한 규모에 도달할 정도로 데이터가 증가하는 환경에서는 더는 환영받을 수 없다.

 

키바나는 분명한 시각화를 통해 로그 관리 기능을 단순하게 하는 능력을 제공하지만, 예상치 못했던 데이터를 발견하는 능력되 제공한다. 키바나는 IT 운영팀이 애플리케이션 상태를 모니터링하는데 한정해서 사용하는 것이 아니라, 시각화를 위한 애플리케이션이다.

 

 

데이터 모델링: 엔티티 중심 도큐먼트

---

키바나는 ElasticSearch에서 집계 결과로 받은 데이터를 렌더링한다. ElasticSearch는 같은 색인에 있느 ㄴ데이터에서 집계한다. 색인은 필드가 들어 있는 도큐먼트를 포함한다. 그 결과, 더 일관성 있는 도큐먼트가 많을수록 데이터 집계 범위도 넓어진다. 도큐먼트에서 일관성이란 이벤트 또는 엔티티를 서술하기 위한 가능한 많은 필드를 의미한다. 이를 우리는 엔티티 중심 도큐먼트라 부른다.

 

ElasticSearch가 요구하는 적절한 JSON 형식으로 변환된 로그 데이터들은 일기 쉽고, 집계 측면에서 다양한 가능성을 얻기 위해 ElasticSearch에서 얻으려는 것이다.

 

 

데이터 입력하기

---

로그스태시는 Elastic Stack의 서버 측 변환 구성요소인데, 여기서는 수집하고 변환하며 ElasticSearch로 전송하는데 사용할 것이다.

 

로그스태시를 사용한다면 구성 파일을 만들고 파일 입력, 필터, 출력 같은 각기 다른 단계에 대한 구성을 설정해야 한다.

 

 

1. 입력 구성하기(파일)

이 입력은 로컬 파일시스템 파일로부터 기본적으로 라인 단위로 데이터를 수집한다.

 

input {

file {

path => "/path/to/accidents/files/directory/accident*"

type => "accident"

start_position => "beginning"

}

}

 

구성은 수집하려는 파일 경로를 명시하는 것으로 시작한다. 같은 이름 패턴을 가진 다수의 소스 파일이 있을 때 와일드카드를 사용하는 모습을 볼 수 있다.

 

ElasticSearch의 도큐먼트 타입으로 사용될 type에 accident를 설정한다. 마지막의 start_position 파라미터는 로그스태시에게 파일의 처음부터 읽기 시작하라고 요청하는 것이다.

 

 

2. 필터 설정하기

적절한 위치에 입력(input)을 설정했다면, 로그스태시 구성 파일에 필터(filter)를 사용해서 ElasticSearch로 색인하기 전에 데이터를 준비한다.

 

filter {

csv {

seperator => ","

columns => ["timestamp","Date","Hour","Dept","Com","Address","Zipcode","Corner","Segment","Address1","Address2","Vehicle 1 description","Vehicle 1",...,"fullAdress","latitude","longitude","season","involvedCount","periodOfDay"]

}

if ([Corner] == "Corner") {

drop { }

}

date {

match => ["timestamp", "dd/MM/YYYY HH:mm"]

target => "@timestamp"

locale => "fr"

timezone => "Europe/Paris"

}

mutate {

convert => ["latitude","float"]

convert => ["longitude","float"]

rename => ["longitude", "[location][lon]", "latitude", "[location][lat]"]

}

}

 

첫번째 필터는 콤마로 구분된 값을 가지는 이벤트를 파싱하는 csv 필터다. 명시된 컬럼이름은 ElasticSearch JSON 도큐먼트에서 필드 이름으로 사용될 것이다. 원본 파일의 첫 라인은 그 자체의 헤더이기 때문에 포함될 필요가 없으므로 대괄호를 사용해 Corner 컬럼의 값이 Corner이면 제외한다.

 

date 필터를 사용해 예상 패턴으로 날짜의 서식을 지정하고 로케일과 시간대를 설정한다.

 

마지막으로, geopoint를 만들기 위해 사용하려는 원본 파일에 포함된 longitude와 latitude 필드를 가져온다.

 

 

3. 출력 구성하기(ElasticSearch)

마지막 부분은 ElasticSearch에서 데이터 색인을 위해 사용하는 출력(output)이다. 설정은 매우 간단하다.

 

output {

elasticsearch {

action => "index"

hosts => "localhost:9200"

index => "accidents-%{+YYYY}"

user => "elastic"

password => "changeme"

template => "/path_to_template/template.json"

template_overwrite => true

}

}

 

ElasticSearch에 연결할 수 있도록 정확하게 설정한다. 그 밖의 부분은 템플릿 경로인데, 템플릿은 색인에서 사용하는 매핑을 설명하는 파일이다. 색인은 필드 형식을 지정하는 것처럼 설정 가능한 타입을 포함할 것이다. 이 예제는 ElasticSearch가 기본 템플릿을 만들지 않고 지정한 템플릿을 사용하도록 요청하고 있다. 그 이유는 키바나에서는 시각화에 적절한 데이터 형식이 필요하기 때문이다. 예를들어 주소 같은 대부분의 텍스트 데이터는 텍스트로 색인해야 겠지만, 키바나에서 집계에 사용될때는 keyword 타입 필드가 적합하다.

 

데이터 수집을 위해 다음 명령을 실행할 수 있다.

 

/elastic/logstash-5.0.0/bin/logstash -f csv_to_es.conf

 

 

로그스태시는 크게 입력(Inputs), 출력(Outputs), 필터(Filters) 단계로 이루어진다. 입력은 다양한 경로로부터 데이터를 읽어오는 작업이고, 필터는 읽어온 데이터를 가공하는 절차다. 그리고 출력은 가공된 데이터를 다시 다른 프로그램이나 채널로 입력하기 위해 내보내는 단계다.

 

 

표준입력/파일/Syslog -> (입력 -> 필터 -> 출력) -> 표준출력/파일/ElasticSearch

 

http://logstash.net/docs/1.4.2/

 

로그스태시 실행 파일은 설치된 디렉터리의 bin 디렉터리 아래에 있는 logstash다. 로그스태시의 설정은 별도 파일로 저장하며 실행시 bin/logstash -f <설정파일> 명령으로 실행한다. 로그스태시 설정 파일의 내용은 다음과 같은 형식이다.

 

input {

<입력 경로> {

<옵션명> => <옵션값>

}

}

 

filter {

<필터> {

<옵션명> => <옵션값>

}

if [<필드명>] == <필드값>{

<필터> {

<옵션명> => <옵션값>

}

}

}

 

output {

<출력 경로> {

<옵션명> => <옵션값>

}

}

 

 

로그스태시에는 다양한 필터가 있는데, mutate 필터는 로그스태시가 읽어 들인 데이터의 값을 변경하거나 추가하는 등 값을 제어하는 기본적인 기능을 제어한다. 로그스태시에서 필드의 값은 %{필드명}과 같은 형식으로 지정할 수 있다.