개념 사전 · 프로그램

Elastic Beats

Elastic Beats · 비츠

Beats는 파일·메트릭·가용성·네트워크 등 목적별 운영 자료를 수집해 전달하는 Elastic의 경량 수집기 계열이다. 서로 다른 Beat는 입력이 다르며 저장·검색·화면 역할을 모두 수행하는 하나의 은 아니다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

01무엇이고, 어떤 일을 하나

호스트와 서비스의 자료를 수집한다.
모듈·Metricset 등으로 입력 구조를 해석한다.
또는 로 이벤트를 전달한다.

02어떤 순서로 동작하나

수집기 선택
파일·수치·가용성·감사 중 필요한 자료에 맞는 Beat와 지원 버전을 선택한다. 같은 호스트에 여러 수집기를 넣을 때 중복 수집을 확인한다.
입력 구성
모듈·경로·권한·파싱 옵션으로 수집 대상을 정한다. 프로그램이 실행 중이어도 읽을 파일이나 계정 권한이 틀리면 원하는 이벤트가 없다.
출력 전달
인증··목적지를 구성하여 나 로 보낸다. 출력 설정 시험과 실제 표본 한 건의 적재를 따로 확인한다.
연속성 확인
재시작·로그 회전·출력 장애 전후의 누락·중복을 관찰한다. 원문 참조와 전달 위치가 유지되는지 저장소 검색까지 대조한다.

03먼저 알아둘 용어와 구성요소

: 파일·저널 등의 로그를 수집하는 Beat.
: 시스템·서비스 메트릭을 수집하는 Beat.
: 대상의 가용성 점검 자료를 수집하는 Beat.
: 네트워크 트래픽에서 프로토콜 관련 자료를 수집하는 Beat.
: 감사 관련 자료를 수집하는 Beat.
: 이벤트 로그를 수집하는 Beat.
: 제품과 자료 유형에 맞춰 수집·해석을 구성하는 Beats의 단위.
: 통합을 이용해 자료 수집 등을 관리하는 별도 Elastic 수집 구성으로 Beat 설정과 동일하지 않다.

LEARN THROUGH PRACTICE

Filebeat 입력 설정에서 Kibana 문서 세 건까지 추적하기

설정 파일의 입력·출력과 검색 화면의 문서·시간·필드를 연결한다.

실습 구성과 전제

자신의 격리 Elastic 환경과 비밀값을 별도로 관리한 수집 계정을 사용한다.
설정 화면과 검색 화면은 같은 제품의 서로 다른 수집 사례다. filestream 입력이 사진 속 세 문서의 유일한 출처였다고 단정하지 않는다.

입력 경로와 출력 주소를 분리한다
- filestream은 paths에 일치하는 파일을 수집하고 output.는 문서를 보낼 목적지를 정한다. setup.는 대시보드 등의 설정 연결이며 로그 본문을 로 직접 보내는 경로가 아니다.
- 사진에는 시험용 관리자 계정이 보이지만 실제 배포에서는 전용 권한·keystore를 사용한다. fingerprint 길이와 작은 파일 처리 조건은 설치 버전의 문서로 확인한다.
shell
```
filebeat test config -e
filebeat test output -e
```
실제 비밀값이 출력될 수 있는 디버그 로그는 외부에 복사하지 않는다.
원본 크기로 보기 ↗
- setup.kibana, output.elasticsearch, filebeat.inputs 세 블록이 나뉘어 보인다.
- filestream의 id·paths와 fingerprint.length 64가 표시된다. 필드 이름은 같아도 버전별 기본 동작을 확인해야 한다.
확인 기준
test config와 test output을 각각 수행해 문법과 연결을 구분한다.
시간 필터와 문서 수를 먼저 확인한다
- Discover에서 Data view와 시간 범위를 맞춘 뒤 Documents 수를 읽는다. 서비스가 실행 중이어도 해당 인덱스·시간 범위에 문서가 없으면 검색은 비어 있다.
- 화면의 세 문서는 테스트 로그·로그인 성공·결제 오류라는 메시지를 가진다. 메시지 이름은 사건 분류의 입력이며 실제 비즈니스 성공을 독립 검증한 값은 아니다.
원본 크기로 보기 ↗
- Data view는 elk-basic이고 시간 범위는 Last 7 days, Documents는 3으로 표시된다.
- 각 행에 @timestamp·host.hostname·message·_index가 보여 수집 문서를 구조화된 필드로 읽을 수 있다.
확인 기준
시각·인덱스·데이터 뷰가 틀려 생긴 빈 결과와 수집 실패를 분리한다.
검색어와 필드 조건의 차이를 시험한다
- 사진의 검색창은 호스트 이름 문자열을 검색한다. 정확한 필드 조건을 쓰려면 KQL의 필드:값 구문과 해당 필드의 매핑을 확인한다.
- 원본 message와 event.original을 보존하면서 필요한 구조 필드를 추가하고, 파싱 실패를 성공 문서와 구분한다.
text
```
host.hostname : "lab-host"
```
KQL의 필드 조건 예시. 자신의 문서에 저장된 호스트 이름으로 바꾼다.
원본 크기로 보기 ↗
- 왼쪽 Available fields에 @timestamp·event.original·host.hostname·lab·message가 보인다.
- 검색 후에도 Documents 3이 보이며 호스트 문자열이 강조된다. 강조 표시만으로 정확한 필드 동등 비교가 수행됐다고 해석하지 않는다.
확인 기준
시간 범위와 필드 매핑을 고정한 뒤 검색 결과 수를 비교한다.