FluentBit를 로봇 쪽으로 당기다: ROS 통합으로 전처리 비용 줄인 운영 설계
로그 수집 시스템을 서버에서만 처리하면 확장할수록 비용과 운영 복잡도가 함께 증가한다.
이 글은 FluentBit를 별도 프로세스에서 ROS 패키지 통합 구조로 옮긴 이유와, 실제 운영에서 어떤 기준으로 설정을 나눴는지 정리한다.
문제 정의
- 기존 FluentBit는 시스템 서비스로 분리 실행됨
- 파이프라인 설정 변경 시 운영 절차가 번거로움
- 서버 전처리 부담이 커져 비용이 상승함
핵심 병목은 “수집"이 아니라 “수집 이후 가공 위치"였다. 가공이 모두 서버에 몰리면, 현장 수가 늘수록 CPU/스토리지/네트워크 비용이 동시에 증가한다.
선택
수집/전처리 일부를 로컬로 이동했다.
- FluentBit를 ROS 패키지 흐름에 통합
- 서버는 집계/활용 중심으로 단순화
이 방식은 “서버에서 다 하자"보다 운영 판단이 빠르다. 현장에서 필터 규칙을 조정해도 서버 배포를 기다릴 필요가 없기 때문이다.
파이프라인 분리 기준
로컬에서 처리할 것
- 불필요 필드 제거
- 로그 레벨 필터링
- 태그 정규화
서버에서 처리할 것
- cross-device 집계
- 장기 보관 정책
- 검색 인덱스 최적화
이 경계를 명확히 나누면 장애가 나도 “현장 수집 이슈"와 “중앙 집계 이슈"를 분리해 본다.
설정 예시
[INPUT]
Name tail
Path /var/log/robot/*.log
Tag robot.log
[FILTER]
Name grep
Match robot.log
Regex level (ERROR|WARN|INFO)
[OUTPUT]
Name forward
Match robot.*
Host collector.internal
Port 24224
위처럼 입력/필터/출력을 단순하게 유지해야 현장 디버깅이 가능하다.
효과
- 서버 리소스 사용량 감소
- 현장 단위 파이프라인 커스터마이징 용이
- 장애 지점이 전처리/집계로 명확히 분리됨
운영 체크리스트
- 로컬 디스크 버퍼 상한 고정
- 네트워크 단절 시 재전송 정책 확인
- 태그 스키마 버전 관리
- 파이프라인 변경 시 샘플 로그 회귀 테스트
장애 복구 절차
- 로컬 입력 소스(tail/systemd) 상태 확인
- 로컬 버퍼 사용량 확인
- 중앙 collector 연결 상태 확인
- 필터 규칙 변경 이력 확인
수집기가 로컬로 내려오면 장애 지점이 늘어나는 것처럼 보이지만, 실제로는 원인 분리가 빨라져 복구 시간이 짧아진다.
참고 및 인용
참고: Fluent Bit 공식 문서는 입력/필터/출력 플러그인 기반 수집 파이프라인을 정의한다. Fluent Bit Manual
참고: Fluent Bit의 버퍼링/스토리지 정책은 네트워크 단절 시 유실/지연 특성을 좌우한다. Buffering and storage
참고: ROS 문서는 로봇 런타임에서 노드/패키지 경계를 설계할 때 기준이 된다. ROS Documentation