Fluent Bit → OpenSearch 중복 로그 이슈

Overview

EKS 환경에서 Fluent Bit을 통해 OpenSearch로 로그를 전달할 때, 같은 로그가 중복으로 저장되는 문제를 경험한 적이 있는가?

 

우리도 비슷한 문제를 겪었다. 로그 내용과 타임스탬프가 완전히 동일한데도 OpenSearch에는 두 번씩 저장되어 지표나 검색 결과가 과도하게 부풀려지는 현상이 반복되었다.

 

조사 결과, 각 로그가 서로 다른 `_id` 값을 가지고 있어 OpenSearch가 이를 서로 다른 문서로 인식하고 있었던 것이 원인이었다.

 

이 글에서는 Fluent Bit의 설정만으로 이 문제를 해결한 실제 사례를 공유한다. 특히 `_id` 충돌이 아닌, 내용은 동일하지만 `_id` 가 달라 중복 저장되는 현상에 대해 설명하고, 이를 Generate_ID 설정으로 해결한 과정을 정리한다.

 

 

 

 

 

 

---

 

 

문제 상황

AWS EKS 환경에서 aws-for-fluent-bit를 사용하여 Fluent Bit 로그를 OpenSearch로 전달하던 중, 동일한 로그가 두 번 이상 저장되는 문제가 발생했다.

 

OpenSearch 대시보드에서는 메시지와 타임스탬프까지 동일한 로그가 중복 저장되어 있었고, 이로 인해 다음과 같은 문제가 발생했다.

• 검색 결과의 수치가 실제보다 부풀려진다.
• 로그 기반 알람이 중복으로 트리거된다.
• 시각화 지표에 왜곡이 생긴다.

 

 

 

 

 

원인 분석

Fluent Bit이 OpenSearch로 로그를 보낼 때 `_id` 를 명시하지 않으면, OpenSearch는 각 로그에 대해 자동으로 `_id` 를 생성한다. 이 경우, 내용이 완전히 같더라도 서로 다른 `_id` 로 인해 중복 저장이 발생한다.

 

우리 환경에서는 `rewrite_tag` 필터로 인해 동일한 로그가 Fluent Bit 내에서 여러 경로로 전파되었고, 각 경로에서 `_id` 가 달라지며 OpenSearch에 서로 다른 문서로 저장되었다.

 

이 문제는 다음과 같은 조건에서 더 자주 발생한다.

• `Logstash_Format On` 옵션이 설정되어 있고,
• `Generate_ID` 옵션이 비활성화되어 있으며,
• 동일 로그가 여러 `OUTPUT` 경로를 통해 전송될 때

결과적으로 OpenSearch는 내용은 같지만 `_id` 가 다른 로그들을 중복된 문서로 저장하게 된다.

 

 

 

 

 

 

해결 방법

해당 문제는 Fluent Bit의 es Output 설정에 다음 옵션을 추가하여 해결한다

[OUTPUT]
    Name            es
    Match           es.*
    ...
    Generate_ID     On

 

 

 

`Generate_ID On` 옵션은 Fluent Bit이 OpenSearch로 로그를 전송할 때, 내부적으로 고유한 `_id` 를 생성하도록 강제한다. 이를 통해 동일한 로그가 여러 경로로 전달되더라도, OpenSearch는 이를 중복된 문서로 인식하지 않고 하나의 문서로만 저장한다.

 

이 설정은 특히 `rewrite_tag` 필터를 사용해 여러 Match 경로로 로그를 전달하는 경우 필수적이다. 동일한 로그가 `s3.*, es.*` 로 나뉘어 전송될 때 `_id` 가 강제로 생성되지 않으면, 로그는 내용이 같더라도 서로 다른 `_id` 를 가지게 된다. 그 결과 OpenSearch에 동일 로그가 2번 이상 저장되는 현상이 발생한다.

 

 

 

 

 

 

후속 조치 및 검증

설정을 적용한 후 다음 사항을 검증한다.

1. OpenSearch 대시보드에서 동일한 메시지와 타임스탬프를 가진 로그가 1건만 저장되는지 확인한다.
2. Generate_ID가 적용된 로그의 `_id` 패턴이 이전과 달라졌는지 비교하여 고유성이 확보되었는지 검토한다.
3. Fluent Bit 로그에서 에러나 retry 없이 정상적으로 로그가 전송되고 있는지 Health Check 경로를 통해 지속적으로 모니터링한다.
4. 필요 시 `rewrite_tag` 필터 로직을 간결하게 정리하여 중복 태깅의 가능성을 줄인다.

 

 

 

 

 

 

---

 

 

 

 

 

 

마무리

이번 문제는 단순히 로그가 중복 저장되는 증상이었지만, 원인은 Fluent Bit과 OpenSearch 간의 `_id` 생성 방식에 있었다. 다행히 Fluent Bit에서 제공하는 `Generate_ID` 옵션 하나로 문제를 말끔히 해결할 수 있었다.

 

이처럼 EKS 환경에서 Fluent Bit과 OpenSearch를 연동할 때는 로그 경로가 다중인 경우를 고려하여 `_id` 충돌이나 중복 생성을 사전에 방지하는 설정을 적용하는 것이 중요하다.

 

이후에도 지속적으로 로그 저장 구조를 점검하고, 필터링 및 태깅 전략을 정비해 나가는 것이 필요하다. 작은 설정 하나가 데이터 품질과 운영 효율성에 큰 차이를 만든다는 점을 다시 한 번 깨닫게 된다.

 

 

 

 

---

Reference

https://github.com/fluent/fluent-bit/issues/6272