생산자와 소비자의 속도 차이를 흡수하고, 일시적 장애에도 데이터를 버티게 하기 위해서입니다. queue 없이 처리 서버로 직접 전송하면 소비자가 느려질 때 생산자까지 영향을 받습니다.

agent local buffer, durable queue, retry, ack 기반 전송을 사용합니다. 다만 모든 로그를 절대 유실하지 않으려면 비용과 지연이 커집니다. 서비스 특성에 따라 허용 가능한 유실 수준을 정하는 것이 현실적입니다.

agent 방식은 호스트 단위로 데몬을 실행해 여러 컨테이너의 로그를 수집합니다. sidecar 방식은 pod 내에 로그 수집 컨테이너를 함께 배포합니다. agent 방식은 리소스 효율이 높고, sidecar 방식은 애플리케이션별로 세밀한 설정이 가능합니다.

검색이 중요한지, 장기 보관이 중요한지, 집계 분석이 중요한지에 따라 Elasticsearch, object storage, columnar DB 등을 선택합니다. 비용과 쿼리 패턴을 함께 고려해야 합니다.

필드 이름과 타입이 일관되어야 검색, 집계, alert rule 작성이 쉬워집니다. 비정형 로그만 있으면 분석 비용이 커집니다.

debug는 개발 중 상세 흐름 추적, info는 정상 동작 이벤트, warn은 예상 가능한 이상 상황, error는 처리 실패나 시스템 오류에 사용합니다. 프로덕션에서는 보통 info 이상만 수집하고, 문제가 있을 때 debug를 임시 활성화하는 식으로 운영합니다.

수집 단계에서 PII를 마스킹하거나 제거하는 것이 기본입니다. 로그에 이메일, 전화번호, 토큰 같은 민감 정보가 남지 않도록 로깅 레이어에서 필터링 규칙을 적용합니다. 법적 요건(GDPR 등)이 있다면 보존 기간과 접근 권한도 함께 관리해야 합니다.