ELK 스택 통합: Logstash, Elasticsearch, Kibana 동기화
Logstash, Elasticsearch, Kibana를 일치하는 파이프라인, 매핑, 인덱스 이름, TLS 및 데이터 뷰로 정렬합니다.
ELK 스택 통합: Logstash, Elasticsearch, Kibana 동기화
Logstash, Elasticsearch, Kibana가 동기화되지 않으면 로그가 사라지고, 대시보드가 비어 보이거나, 필드가 잘못된 유형으로 표시됩니다. ELK 스택 통합은 세 가지 서비스를 시작하는 것보다 인덱스 이름, 매핑, 타임스탬프, 자격 증명 및 데이터 뷰가 모두 일치하는지 확인하는 데 더 중점을 둡니다.
이 가이드는 실용적인 로깅 파이프라인을 안내합니다. Logstash가 이벤트를 수신하고, 구문 분석하고, Elasticsearch로 전송하며, Kibana가 결과 인덱스 또는 데이터 스트림을 읽습니다. 예제는 클래식 Logstash 파이프라인 구문과 Kibana Dev Tools에서 실행할 수 있는 Elasticsearch API를 사용합니다.
데이터 흐름 이해
스택을 통해 하나의 이벤트를 추적합니다.
- Logstash는 Beats, TCP, syslog, 파일, 큐 또는 다른 입력에서 데이터를 수신합니다.
- Logstash 필터는 필드를 구문 분석, 보강, 이름 변경 및 정규화합니다.
- Elasticsearch는 템플릿, 매핑 및 수명 주기 정책을 사용하여 이벤트를 인덱싱합니다.
- Kibana는 데이터 뷰를 통해 Elasticsearch를 쿼리하고 Discover, 대시보드, Lens 또는 알림에 이벤트를 표시합니다.
대부분의 통합 버그는 경계에서 발생합니다. Logstash가 연결할 수 없거나, Elasticsearch가 문서를 거부하거나, Kibana가 잘못된 데이터 뷰 또는 시간 범위를 보고 있습니다.
깔끔한 데이터 흐름을 위한 Logstash 구성
Logstash 파이프라인에는 input, filter, output의 세 가지 주요 블록이 있습니다. 각 블록을 단순하고 테스트 가능하게 유지하세요.
입력 플러그인
일반적인 입력 플러그인은 다음과 같습니다.
beats: Filebeat, Metricbeat 및 기타 Beats에서 이벤트를 수신합니다.tcp/udp: 네트워크 소켓을 통해 이벤트를 수신합니다.file: 로컬 파일을 읽습니다. 소규모 배포 및 테스트에 유용하지만, 분산 프로덕션 호스트에는 일반적으로 에이전트가 더 좋습니다.syslog: syslog 메시지를 수신합니다.
TLS를 사용한 Beats 입력 예제:
input {
beats {
port => 5044
ssl_enabled => true
ssl_certificate => "/etc/pki/tls/certs/logstash.crt"
ssl_key => "/etc/pki/tls/private/logstash.key"
}
}
포트가 열려 있고, 인증서가 클라이언트 연결 방식과 일치하며, 옵션 이름이 설치된 플러그인 버전과 일치하는지 확인하세요. 최근 Beats 입력 플러그인 버전은 ssl_enabled를 사용합니다.
필터 플러그인
필터는 원시 이벤트를 유용한 필드로 변환합니다. Logstash가 필터를 순차적으로 실행하므로 순서가 중요합니다.
filter {
grok {
match => { "message" => "%{COMBINEDAPACHELOG}" }
}
date {
match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]
}
mutate {
remove_field => [ "message" ]
}
}
비정형 텍스트에는 grok을, @timestamp 설정에는 date를, 필드 정리에는 mutate를, IP 기반 위치 보강이 필요할 때는 geoip를 사용하세요. 프로덕션에 적용하기 전에 실제 로그 라인에 대해 grok 패턴을 테스트하세요. 작은 구문 분석 실수로 인해 수천 개의 이벤트가 누락된 필드와 함께 Elasticsearch로 전송될 수 있습니다.
출력 플러그인
ELK 스택의 경우 Elasticsearch 출력이 일반적인 대상입니다.
output {
elasticsearch {
hosts => ["https://elasticsearch-node1:9200", "https://elasticsearch-node2:9200"]
index => "my-logs-%{+YYYY.MM.dd}"
user => "logstash_writer"
password => "${LOGSTASH_ES_PASSWORD}"
ssl_enabled => true
cacert => "/etc/logstash/certs/http_ca.crt"
}
}
index 값은 Elasticsearch 템플릿 및 Kibana 데이터 뷰와의 계약입니다. Logstash가 my-logs-2026.05.23을 쓰는 경우 템플릿과 데이터 뷰는 my-logs-*와 일치해야 합니다.
대규모 환경에서는 수동으로 관리되는 일일 인덱스 대신 데이터 스트림과 인덱스 수명 주기 관리를 고려하세요. 데이터 스트림을 사용하는 경우 데이터 스트림 및 클래식 인덱스 옵션을 혼합하지 말고 data_stream 설정에 대한 Elastic의 최신 Logstash 출력 지침을 따르세요.
Elasticsearch 템플릿 및 매핑
Elasticsearch는 문서가 도착하기 전에 일관된 매핑이 필요합니다. 그렇지 않으면 첫 번째 문서가 나중 이벤트를 손상시킬 수 있는 필드 유형을 설정할 수 있습니다. 먼저 "200"으로 도착하는 상태 코드는 숫자 대신 텍스트 또는 키워드가 될 수 있습니다.
구성 가능한 인덱스 템플릿 예제:
PUT _index_template/my_log_template
{
"index_patterns": ["my-logs-*"],
"template": {
"settings": {
"number_of_shards": 1,
"number_of_replicas": 1
},
"mappings": {
"properties": {
"@timestamp": {"type": "date"},
"message": {"type": "text"},
"host.name": {"type": "keyword"},
"log.level": {"type": "keyword"},
"http.response.status_code": {"type": "integer"}
}
}
}
}
정확한 일치 및 집계에는 keyword를, 전체 텍스트 검색에는 text를, 메트릭 및 상태 코드에는 숫자 유형을, 시간 필드에는 date를 사용하세요. 측정된 이유가 없는 한 샤드 수를 적당히 유지하세요. 너무 많은 작은 샤드는 클러스터 성능을 저하시킬 수 있습니다.
Kibana 데이터 뷰
Kibana의 현재 UI는 데이터 뷰를 사용합니다. 이전 버전에서는 인덱스 패턴이라고 불렀습니다. Elasticsearch가 실제로 가지고 있는 인덱스 이름 또는 데이터 스트림과 일치하는 데이터 뷰를 만드세요.
일반적인 설정:
- 스택 관리 -> Kibana -> 데이터 뷰로 이동합니다.
my-logs-*와 같은 데이터 뷰를 만듭니다.- 시간 필드로
@timestamp를 선택합니다. - Discover를 열고 테스트하는 동안 시간 선택기를 넓힙니다.
Discover가 비어 있으면 Logstash가 실패했다고 가정하지 마세요. 시간 범위, 데이터 뷰 패턴 및 @timestamp가 올바르게 구문 분석되었는지 확인하세요.
일반적인 통합 문제 해결
Kibana에 데이터가 표시되지 않음
각 홉을 확인하세요.
GET _cat/indices/my-logs-*?v
GET my-logs-*/_search?size=1&sort=@timestamp:desc
그런 다음 확인하세요.
- 연결, 인증, TLS 또는 매핑 오류에 대한 Logstash 로그.
- 거부된 문서 및 보안 실패에 대한 Elasticsearch 로그.
- Kibana 데이터 뷰 패턴 및 선택한 시간 범위.
- 이벤트 타임스탬프가 미래, 과거 또는 누락되었는지 여부.
문서가 Elasticsearch에 의해 거부됨
매핑 충돌이 일반적입니다. 예를 들어, 한 이벤트는 http.response.status_code를 200으로 보내고 다른 이벤트는 "OK"로 보냅니다. Elasticsearch는 둘 다 integer 필드에 저장할 수 없습니다.
필드가 일관되게 유형화되도록 Logstash 필터를 수정하거나, 잘못된 이벤트를 검토를 위해 별도의 인덱스로 라우팅하세요. 잘못된 문서를 생성하는 파이프라인을 수정하지 않고 인덱스를 계속 삭제하고 다시 생성하지 마세요.
Logstash가 너무 많은 CPU를 사용함
비용이 많이 드는 grok 패턴, 높은 이벤트 볼륨 및 큰 멀티라인 이벤트는 Logstash CPU를 빠르게 높일 수 있습니다. 먼저 어떤 파이프라인이 사용 중인지 측정한 다음, 패턴을 단순화하고, 정규식을 고정하고, 운영하기 더 쉬울 때 간단한 구문 분석을 Beats 또는 Elasticsearch 수집 파이프라인으로 이동하세요.
Kibana 쿼리가 느림
느린 대시보드는 종종 넓은 시간 범위, 높은 카디널리티 집계, 너무 많은 샤드 또는 Kibana가 keyword를 필요로 할 때 text로 매핑된 필드에서 발생합니다. 더 좁은 대시보드 기본값, ILM 롤오버 및 시각화와 일치하는 필드 매핑을 사용하세요.
결론
ELK 스택 통합을 세 계층 간의 계약으로 취급하세요. Logstash는 예측 가능한 필드를 내보내야 하고, Elasticsearch는 이를 올바르게 매핑하고 저장해야 하며, Kibana는 올바른 시간 범위에 걸쳐 올바른 데이터 뷰를 쿼리해야 합니다. 문제가 발생하면 입력에서 인덱스, 대시보드까지 하나의 샘플 이벤트를 따라가세요.