팀 프로젝트) Fluent Bit tag 작성 시 고려해야 할 점: 강한 결합 vs. 느슨한 결합

문제 상황:

fluentbit 단에서 service 태그는 ^service$ (강한 결합)으로 잘 바꿔져서 fluentd로 보내졌지만 이와 똑같이 auth, kmsg 태그들도 ^auth$, ^kmsg$로 바꿔서 fluentd로 보내니까 system 로그들은 전혀 flunetd로 보내지지 않는 문제가 있었다.

 

아래는 잘못된 코드

# 서비스: app=service → 최종 태그 service.application.log
[FILTER]
    Name                  rewrite_tag
    Match                 kube.var.log.containers.service*
    Rule                  $kubernetes['labels']['app'] ^service$ service.application.log false
    Rule                  $log ^.*$ service.unmatched.log false

# 시스템: system 라벨값에 따라 최종 태그 system.auth.log / system.kmsg.log
[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
    Rule                  $log ^.*$ system.unmatched.log false

invalid pattern or no match for record

 

-> rewrite_tag 규칙 내의 정규식(^auth$, ^kmsg$)이 실제 라벨 값과 일치하지 않아서 매칭 실패

 

 

Fluent Bit이 pod label을 어떻게 붙여주느냐, 그리고 그 값이 얼마나 일관되냐의 차이 때문에 하나는 “강결합(=정확히 일치)”로 쓸 수 있었고, 다른 하나는 “느슨한 결합(=부분 일치)”으로 쓸 수밖에 없었다.

이에 강결합과 느슨한 결합의 차이에 대해 알아보기로 했다.

---

🔍 핵심 차이 정리

구분	app 라벨	system 라벨
존재 방식	app=service 처럼 정확한 key-value 한 쌍	system=auth, system=kmsg, system=disk 처럼 값이 다양함
값의 패턴	단일 값 (정확히 “service”)	여러 패턴 (auth, kmsg, disk, etc.)
Fluent Bit 평가 방식	정규식이 정확히 일치해야만 매칭	다양한 값 중 일부가 포함되면 매칭해야 함
따라서...	^service$ (강결합) 가능	.*auth.*, .*kmsg.* (약결합) 필요

---

💡 쉽게 비유하자면

• app 라벨은 마치 “이 Pod는 100% 서비스용이야”
  → 그래서 ^service$ 라고 정확히 써도 항상 맞다.
• system 라벨은 “이 Pod는 시스템 계열인데, 종류가 auth일 수도 있고 kmsg일 수도 있어”
  → 값이 바뀌거나 일부만 포함될 수 있으니까,
  .*auth.* / .*kmsg.* 처럼 “포함(contains)” 형태로 느슨하게 걸러야 한다.

---

⚙️ 실제 동작 예시

✅ Service (강결합)

Rule  $kubernetes['labels']['app'] ^service$ service.application.log false

• pod label: app=service
• $kubernetes['labels']['app'] → 항상 "service"
• 정규식 ^service$ 완벽히 매칭 ✅

---

⚠️ System (약결합)

Rule $kubernetes['labels']['system'] .*auth.* system.auth.log false 
Rule $kubernetes['labels']['system'] .*kmsg.* system.kmsg.log false

• pod label: system=auth, system=kmsg로 한 개가 아님
• $kubernetes['labels']['system'] 값이 완전히 동일하지 않음
• 정규식 ^auth$ 로 하면 일부 누락 ❌
• .*auth.* 로 느슨하게 걸러야 포함 관계로 매칭 가능 ✅

---

최종 정답 코드

# 서비스: app=service → 최종 태그 service.application.log
[FILTER]
    Name                  rewrite_tag
    Match                 kube.var.log.containers.service*
    Rule                  $kubernetes['labels']['app'] ^service$ service.application.log false
    Rule                  $log ^.*$ service.unmatched.log false

# 시스템: system 라벨값에 따라 최종 태그 분기:
[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
    Rule                  $log ^.*$ system.unmatched.log false

🧠 결론

app 라벨은 값이 단일하고 고정되어 있어서 “정확히 일치(강결합)” 정규식(^service$)으로 평가해도 항상 맞지만,
system 라벨은 여러 종류(auth, kmsg, disk 등)의 값을 가질 수 있기 때문에 “포함(약결합)” 정규식(.*auth.*)으로 평가해야 매칭된다.

---

✨ 한 문장 요약

결국 app은 정확히 한 값(=service) 이라서 강결합(^service$)이 가능했고,
system은 여러 하위 종류(auth, kmsg) 를 포괄해야 해서
느슨한 결합(.*auth.*, .*kmsg.*) 정규식으로 써야 정상 동작한 것이다.