[설계 면접] 만약 Filebeat, ELK중 하나라도 장애가 발생한다면 어떻게 처리할 수 있나요?

각 구성 요소는 비동기적으로 동작하기 때문에, 특정 컴포넌트에 장애가 발생해도 전체 로그 파이프라인이 즉시 중단되진 않습니다.
예를 들어, Logstash가 장애를 일으킨 경우, Filebeat는 내부 큐에 로그를 임시 저장하며 일정 시간 동안 버퍼링할 수 있습니다. 하지만 이 큐가 가득 차면 로그 유실이 발생할 수 있기 때문에, backpressure 상황에 대한 모니터링과 알림이 필요합니다.
Elasticsearch가 장애 나면 Logstash 출력이 실패하고 큐가 쌓이게 됩니다. 이때 Logstash 자체에 Persistent Queue를 설정해두면 디스크에 저장된 로그를 재처리할 수 있습니다.
Kibana는 단순 시각화 도구이므로, Kibana 장애는 로그 수집에는 영향을 주지 않습니다. 다만 관측 및 분석 기능이 제한될 뿐입니다.
전반적으로 각 구성 요소에 대해 retry, queue, alerting을 고려한 복구 전략이 필요합니다.

 

Filebeat.yml 복구 전략 설정

filebeat.inputs:
  - type: filestream
    paths:
      - /var/log/myapp/*.log
    id: myapp-logs
    multiline.pattern: '^\['
    multiline.negate: true
    multiline.match: after

# 메모리 큐 설정 (default: 4096 이벤트)
queue.mem:
  events: 8192
  flush.min_events: 512
  flush.timeout: 3s

# 비동기 출력 + 재시도 설정
output.logstash:
  hosts: ["logstash:5044"]
  loadbalance: true
  worker: 2
  backoff.init: 1s
  backoff.max: 60s
  max_retries: -1  # 무한 재시도

 

Logstash.conf 복구 설정

input {
  beats {
    port => 5044
  }
}

filter {
  json {
    source => "message"
  }
}

output {
  elasticsearch {
    hosts => ["http://elasticsearch:9200"]
    index => "myapp-logs-%{+YYYY.MM.dd}"
    retry_on_conflict => 3
    retry_count => 5
    flush_size => 200
    idle_flush_time => 5
  }
}

 

Logstash.yml

# Persistent Queue 활성화
queue.type: persisted
queue.max_bytes: 1gb
queue.checkpoint.acks: 1024
queue.checkpoint.writes: 1024
queue.checkpoint.interval: 1000ms