[geonusp]

🧰 Chore PR

🔗 GitHub Issue

• Related chore: Grafana Alloy v1.21.0 업그레이드 및 filelog 정렬 동작 검증 #266

---

🧩 한눈에 요약

무엇을 변경했나?

• 인프라
• 설정파일
• 빌드 파일
• CI
• 의존성
• 런타임/비즈니스 로직 리팩터링 없음 (있으면 Refactor PR 템플릿 사용)

왜 필요한가?

• Alloy v1.21.0에 포함된 filelog 정렬 수정에 맞춰 기존 우회 설정을 제거하고, receiver의 정렬 설정을 직접 사용하도록 변경했다.

범위

• Included: Alloy 이미지 v1.21.0 업그레이드, filelog 설정 이전, 회전 로그 순서 검증 추가, 로컬 민감 파일 ignore 규칙 추가, CI 컨테이너가 임시 Alloy 설정 파일을 읽도록 권한 수정
• Not included: WSL Docker Desktop에서 로그 파일이 Alloy에 노출되지 않는 문제의 원인 확인([bug] WSL에서 Docker 로그 파일 마운트가 비어 Alloy 수집 검증 실패 #267), 운영 서버 적용

---

🧪 테스트 / 검증

로컬

• Command: python deploy/observability/scripts/verify-log-pipeline.py
• Result: PowerShell에서 전체 검증 PASS. 권한 수정 후 WSL에서는 Alloy가 설정을 읽고 기동하지만, Docker -> Alloy -> Loki 단계는 여전히 타임아웃되어 #267에서 조사 중이다.

CI

• 링크/결과: CI #427 실패는 임시 Alloy 설정 파일의 permission denied가 원인. 0644 권한 수정 커밋 5c5e3b75 반영 후 CI #428 진행 중.

Smoke / 수동 검증

• 시나리오: 로컬 Docker Compose로 로그 수집·회전·재시작·백엔드 재생성·Loki 장애 복구 검증
• 결과: PowerShell 실행에서 전체 검증 통과. 권한 수정 후 WSL 재실행에서는 Alloy 기동까지 확인했고 로그 수집은 [bug] WSL에서 Docker 로그 파일 마운트가 비어 Alloy 수집 검증 실패 #267 타임아웃 재현.

테스트 공백

• WSL 실행에서만 첫 Docker 로그 수집 단계가 실패한다. 원인은 미확정이며 #267에서 조사한다.

---

🧭 영향 범위

• 설정/환경변수 변경 없음
• 설정/환경변수 변경 있음 (항목: Alloy 이미지 버전 및 filelog receiver 설정)
• CI/빌드 파이프라인 영향 없음
• CI/빌드 파이프라인 영향 있음
• 의존성 변경 없음
• 의존성 변경 있음 (Grafana Alloy v1.19.2 → v1.21.0)

---

⚠️ 리스크 & 롤백

리스크

• filelog ordering 설정 지원 버전이 v1.21.0보다 낮으면 새 설정이 동작하지 않을 수 있다.
• WSL Docker Desktop에서는 테스트 스크립트가 로그 파일을 읽지 못하는 문제가 남아 있다([bug] WSL에서 Docker 로그 파일 마운트가 비어 Alloy 수집 검증 실패 #267).

롤백

• 단순 revert로 가능
• 버전 pin/되돌리기 필요 (대상: Alloy 이미지와 filelog 설정, 방법: 기존 v1.19.2 설정으로 revert)
• 배포 롤백(이전 태그/이미지) 가능

---

💬 리뷰 가이드

• 꼭 봐야 하는 파일/설정: deploy/observability/app-agent/alloy/config.alloy, deploy/observability/app-agent/docker-compose.yml, deploy/observability/scripts/verify-log-pipeline.py의 임시 설정 파일 권한과 회전 순서 검증 코드
• 트레이드오프/대안: 기존 file_input 우회 대신 Alloy v1.21.0의 receiver 정렬 설정을 직접 사용한다.
• 관련 PR: [feat] Loki·Alloy 로그 파이프라인 및 Grafana logs↔Trace 연결 (4/4) #264.
• upstream 수정: fix(otelcol.receiver.filelog): Use alphabetical instead of lexicographic sort type grafana/alloy#7212
• 성능/보안/호환성 영향: Alloy 이미지 버전만 변경되며 앱 API·DB 스키마에는 영향 없다.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Repository UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 77e43c89-18e3-45f8-8ccd-66257a643ec4

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[PHJ2000]

확인했습니다. 기존 버전에서 업그레이드할 때 이미 수집한 로그를 다시 읽는 문제가 있어 인라인으로 남겼습니다. 해당 부분 보완 부탁드립니다.

suggestion: deploy/observability/README.md에 아직 v1.19.2와 file_input 우회 설정을 사용한다고 적혀 있습니다. 이번 변경에 맞춰 문서도 갱신해 주세요.

[PHJ2000]

block : 기존 버전에서 업그레이드할 때 저장된 읽기 위치를 이어받도록 보완해 주세요.

기존 file_input을 제거하면서 입력기 ID가 docker_files에서 기본값인 file_input으로 바뀌어, 같은 볼륨을 사용해도 기존 읽기 상태를 찾지 못합니다. 실제로 v1.19.2에서 로그를 수집한 뒤 파일과 상태 저장 디렉터리를 유지한 채 이번 설정으로 전환하니, 이미 수집한 로그를 처음부터 다시 읽고 출력했습니다.

현재 테스트는 새 버전에서의 재시작만 확인하므로, 기존 버전에서 수집한 상태로 업그레이드해도 이전 로그를 다시 보내지 않는지 검증하는 테스트도 추가해 주세요.

[PHJ2000]

참고: 이번 버전 변경을 살펴보다가 흥미로운 의존성 관리 방식을 발견해서 공유합니다.

Alloy가 내부적으로 사용하는 Loki 라이브러리를 v3.7.8 같은 정식 버전 대신 특정 커밋(5cf8c23a258d)으로 고정하고 있더라고요. 필요한 호환성 수정이 정식 릴리스에는 아직 없어서, 그 수정이 포함된 브랜치의 특정 시점을 가져다 쓰는 방식이라고 합니다.

브랜치의 최신 코드를 계속 따라가는 게 아니라 커밋을 고정해서 항상 같은 코드로 빌드되게 한다는 점이 신기했습니다. Go에서는 이런 버전 표기를 pseudo-version이라고 하네요.

관련 upstream 설명