GSMSV 운영 컨테이너 상태 및 오류 로그 Discord 알림 구축

[exijn]

작업 배경

• CD Workflow는 실행 중인 배포의 실패는 감지할 수 있지만, 배포 완료 이후 GSMSV 서버에서 발생하는 장애를 지속적으로 감시하지는 못합니다.
• App·PostgreSQL·Redis 상태, readiness, 재시작 증가, 오류 로그, 디스크·메모리 사용률을 주기적으로 확인하고 Discord로 요약 알림할 운영 감시가 필요합니다.
• 실제 Discord Webhook Secret은 아직 등록하지 않으며, 서버 파일을 준비한 뒤 사용자가 별도로 등록합니다.

목표

• Compose project/service 기준으로 mudda-prod-app과 PostgreSQL·Redis 컨테이너 상태를 확인합니다.
• App readiness, restart count, Spring ERROR 로그, 루트 디스크·메모리 임계치를 감시합니다.
• 장애·복구를 Discord embed로 알리고 동일 장애의 반복 알림을 억제합니다.
• 상태 확인과 알림만 수행하며 앱 컨테이너나 운영 볼륨을 자동 조작하지 않습니다.

구현 체크리스트

• systemd oneshot service와 timer 기반 1분 주기 실행을 구성합니다.
• docker compose ps 또는 Compose label을 사용해 컨테이너를 안정적으로 식별합니다.
• 기본 임계치를 디스크 80/90%, 메모리 85%, readiness timeout 5초로 구성합니다.
• 컨테이너 running/healthy, readiness, restart count 증가를 구조화해 판정합니다.
• 최근 검사 구간의 App ERROR 로그를 보조 신호로 수집합니다.
• 동일 장애 fingerprint를 기본 10분 동안 억제합니다.
• 장애에서 정상 전환될 때 복구 알림을 한 번 전송합니다.
• 상태 파일을 전용 경로에 atomic update하고 동시 실행을 flock 등으로 방지합니다.
• Webhook URL은 /etc/mudda/discord-alert.env의 root:root, 600 파일에서만 읽습니다.
• 설치·제거·수동 dry-run·fixture 테스트 모드를 제공합니다.
• Docker socket 접근 권한과 systemd 권한 범위를 문서화합니다.
• 운영 컨테이너 재시작·자동 복구·볼륨 삭제 명령을 실행하지 않습니다.
• Discord embed에 상태·시각·환경·서비스·health·restart·요약 로그를 제공합니다.
• Secret·Authorization·Cookie·JWT·password·OAuth·AWS Key·개인정보 가능 로그를 마스킹합니다.
• 로그와 Discord payload를 약 2,000~3,000자 이내로 제한합니다.

문서·검증

• 설치 위치, Webhook 환경 파일, 권한, systemd service/timer 설치·활성화·제거를 문서화합니다.
• 수동 dry-run, fixture 테스트, journalctl, timer 상태, 장애·복구 검증 절차를 문서화합니다.
• 전체 로그는 Docker 로그 또는 향후 Loki/Grafana에서 확인하며 Discord에는 요약만 보냄을 문서화합니다.
• 정상·unhealthy·stopped·readiness timeout·restart·ERROR·디스크·메모리와 복구 테스트를 작성합니다.
• JSON 직렬화, 마스킹, 길이 제한, 중복 억제, atomic state, 동시 실행 방지를 검증합니다.
• Webhook 미설정 시 URL을 노출하지 않고 명확히 실패하는지 확인합니다.

제외 범위

• 실제 Webhook Secret 생성·등록·호출
• GSMSV 서버 접속·파일 설치·systemd 활성화
• 자동 재시작·자동 복구·자동 rollback
• Docker volume 조작, PostgreSQL 백업, Nginx·Certbot
• Kubernetes, Loki/Grafana 모니터링 스택 도입
• 작업 A의 미병합 브랜치나 파일에 대한 의존

완료 조건

• 운영 컨테이너와 호스트 자원 상태를 안전하게 감시합니다.
• 장애·복구 알림과 중복 억제가 fixture 기반 테스트로 검증됩니다.
• Secret 보관·설치·제거·장애 확인 방법이 문서화됩니다.
• develop 대상 별도 PR이 생성되며 작업 A와 독립적으로 병합할 수 있습니다.

대상 브랜치: develop