팀 프로젝트) Fluent Bit -> Fluentd tag rewrite의 이점

1️⃣ Fluent Bit: kube.* 태그를 붙이는 이유

📍 이유

kube.* 태그는 Fluent Bit이 “Kubernetes 환경에서 수집한 로그”임을 식별하기 위한 공통 접두사(prefix) 이다.

[INPUT]
  Name tail
  Path /var/log/containers/*.log
  Tag  kube.*​

• 이 태그는 “이 로그는 K8s 컨테이너 로그다” 라는 신호 역할을 한다.
• Fluent Bit이 이후 kubernetes 필터를 적용할 때
  → Match kube.var.log.containers.* 패턴으로 동작하게 만드는 연결 고리
• 즉, Kubernetes 메타데이터(네임스페이스, Pod, 컨테이너 이름 등)를 병합할 수 있게 해주는 전처리 태그이다.

✅ 이점

항목	설명
메타데이터 병합	Kubernetes 필터가 pod 이름, label, namespace 등을 자동으로 매핑 가능
일관된 규칙	모든 컨테이너 로그가 동일한 접두사(kube.)로 시작해 관리 용이
필터 체이닝	이후 rewrite_tag, kubernetes 필터 등이 정확히 작동함

---

2️⃣ Fluent Bit: rewrite_tag로 system.auth.log 등으로 재작성하는 이유

📍 이유

Fluent Bit은 기본적으로 모든 로그를 kube.var.log.containers.<컨테이너이름>.log 형태로 태그를 붙인다.
하지만 Fluentd에서는 이렇게 세분화된 패턴을 모두 <match>에 지정하기 어렵다.

그래서:

[FILTER]
  Name rewrite_tag
  Match kube.var.log.containers.*system*
  Rule  $kubernetes['labels']['system'] .*auth.* system.auth.log false
  Rule  $kubernetes['labels']['system'] .*kmsg.* system.kmsg.log false

 

 

➡️ 복잡한 Kubernetes 로그 태그를 단순한 논리적 그룹명으로 바꾸는 것이다.

즉,

kube.var.log.containers.system-auth-pod.log  →  system.auth.log  
kube.var.log.containers.system-kmsg-pod.log  →  system.kmsg.log  
kube.var.log.containers.app-service-pod.log  →  service.application.log

 

✅ 이점

항목	설명
로그 분류 표준화	수많은 Pod 이름 대신, 시스템·서비스·커널 등 의미 단위로 구분
Fluentd 라우팅 단순화	<match system.auth.log> 한 줄로 매칭 가능
Kafka 토픽 구조 대응	system-auth-topic, system-kmsg-topic, service-topic으로 자동 매핑 가능
장애 분석 용이	로그 성격별(보안/서비스/커널)로 분리되어 분석·알람 설정이 쉬움

---

3️⃣ Fluentd → Kafka: 토픽별 전송의 효과

Fluentd는 위에서 재작성된 태그(service.application.log, system.auth.log, system.kmsg.log)를 기반으로 각각의 Kafka Topic으로 라우팅한다.

Fluentd match	Kafka Topic	설명
<match service.application.log>	service-topic	서비스 애플리케이션 로그 스트림
<match system.auth.log>	system-auth-topic	SSH 인증/보안 이벤트 로그
<match system.kmsg.log>	system-kmsg-topic	커널 및 장비 이상 로그

✅ 이점

항목	효과
데이터 분리	로그 성격별로 다른 Kafka Topic으로 분리되어 트래픽 혼잡 최소화
장애 격리	특정 토픽의 오류가 다른 로그에 영향 없음
분석 유연성	Kibana, Grafana, AI 분석 등에서 토픽 단위로 대시보드 분리 가능
실시간 파이프라인 확장	필요 시 특정 토픽만 별도 소비(Consumer) 서비스로 확장 가능

요약 다이어그램

📦 Containers (/var/log/containers/*)
     │
     ▼
🟦 Fluent Bit
 ├─ [INPUT] tail logs
 ├─ [FILTER] kubernetes meta
 ├─ [FILTER] rewrite_tag → service.application.log / system.auth.log / system.kmsg.log
 └─ [OUTPUT] forward → Fluentd:24224
     │
     ▼
🟩 Fluentd
 ├─ <source @type forward>
 ├─ <match service.application.log> → Kafka: service-topic
 ├─ <match system.auth.log> → Kafka: system-auth-topic
 └─ <match system.kmsg.log> → Kafka: system-kmsg-topic
     │
     ▼
🟥 AWS MSK (Kafka Cluster)
 ├─ service-topic
 ├─ system-auth-topic
 └─ system-kmsg-topic

결론 한 줄 정리

Fluent Bit에서 kube.* 태그를 붙이는 이유는 Kubernetes 메타데이터를 병합하기 위한 전처리이고,
rewrite_tag로 system.auth.log 같은 의미 단위로 재작성하는 이유는 Fluentd와 Kafka에서
로그를 목적별로 구분·라우팅하기 위함이며,
이를 통해 일관된 로그 구조, 손실 없는 전달, 분석 효율성을 모두 확보할 수 있다.