콘텐츠로 이동

changedetection.io 스케줄과 Discord 알림 운영 가이드

changedetection.io의 활성 시간대와 Discord 웹훅 알림을 설정할 때 필요한 의미, 전제, 실패 처리와 완료 증거를 정리합니다.

적용 범위와 증거 상태

UI 이름, 스케줄 경계, timezone 처리와 알림 URL 형식은 changedetection.io 및 알림 라이브러리 버전에 따라 달라질 수 있습니다. 이 문서의 필드 이름은 개념 설명이며 현재 배포 버전의 UI와 공식 문서에서 확인해야 합니다.

  • 사전 기록: 애플리케이션 버전, 시스템 및 컨테이너 timezone, 검사 간격, 큐 worker 수, 프록시 비용 정책과 Discord 권한을 기록합니다.
  • 비밀 관리: Discord 웹훅 URL은 메시지 전송 권한을 가진 비밀입니다. 화면 캡처, 저장소, 로그와 티켓에 노출하지 않고 유출 시 Discord에서 폐기 후 재발급합니다.
  • 실패 원칙: 스케줄 누락과 알림 실패를 변경 없음으로 간주하지 않습니다. 검사 실행 기록, 마지막 성공 시각, 알림 응답과 재시도 상태를 별도로 관측합니다.

Duration 또는 Run duration의 의미

Start At은 활성 구간의 시작이고 Run duration은 그 구간의 길이입니다. 예를 들어 월요일 09:00에 8시간을 지정하면 의도한 활성 구간은 월요일 09:00부터 17:00까지입니다.

활성 구간은 한 번의 검사가 8시간 계속 실행된다는 뜻이 아닙니다. 실제 요청 시점은 watch의 검사 간격, 스케줄러 tick, worker 지연과 이전 작업 실행 시간의 영향을 받습니다. 종료 시각을 포함하는지, 구간 끝에 밀린 작업을 실행하는지는 대상 버전에서 경계 시험으로 확인합니다.

시간대와 DST

IANA timezone 이름을 명시하고 호스트, 컨테이너와 애플리케이션 표시 시간이 일치하는지 확인합니다. 일광 절약 시간 전환일에는 한 시간이 중복되거나 사라질 수 있으므로 중요한 watch는 전환일 시나리오를 시험합니다. 매일 24시간 감시가 목적이라면 23시간 59분 같은 우회값보다 제품이 제공하는 상시 또는 무제한 구간을 우선합니다.

비용 해석

활성 구간 축소는 요청 수를 줄일 수 있지만 절감액을 보장하지 않습니다. 실제 검사 횟수, 브라우저 렌더링, 프록시 과금 단위, 실패 재시도와 알림 호출을 측정해 전후 비용을 비교합니다.

Discord 웹훅 설정

  1. 대상 Discord 채널에서 웹훅 관리 권한이 있는 계정으로 전용 웹훅을 만듭니다.
  2. 원본 URL에서 webhook ID와 token을 추출하되 값을 기록하거나 공유하지 않습니다.

  3. 현재 changedetection.io 버전이 Apprise 형식을 사용하는지 확인합니다. 지원되는 경우 형식은 다음과 같습니다.

    discord://WEBHOOK_ID/WEBHOOK_TOKEN

  4. 개별 watch 또는 전역 Notifications 설정 중 의도한 범위에 등록합니다.

  5. 테스트 알림을 전송하고 대상 채널, 메시지 내용, timestamp와 애플리케이션 로그를 확인합니다.

이 통신은 서버 간 outbound 요청이므로 브라우저 CORS 설정은 일반적인 해결책이 아닙니다. 방화벽 또는 프록시가 있다면 Discord HTTPS endpoint에 대한 outbound DNS와 TLS 연결만 최소 범위로 허용합니다.

내용, 첨부와 개인정보

스크린샷과 diff에는 계정 정보, 주문 내역, 내부 URL 또는 세션 데이터가 포함될 수 있습니다. 최소 채널 권한, 보존 기간, 첨부 크기와 마스킹 정책을 정하고 필요한 watch에만 첨부를 활성화합니다. Jinja 템플릿 값은 신뢰되지 않은 페이지 내용이므로 멘션 폭주와 과도한 메시지 크기를 제한합니다.

실패, 재시도와 중복

Discord의 429 응답은 Retry-After를 존중하고 일시적 5xx와 네트워크 오류만 상한이 있는 backoff로 재시도합니다. 동일 변경의 중복 알림을 식별할 key를 두고, 영구 4xx는 자동 반복하지 말고 자격 증명 또는 payload 오류로 경보합니다. 긴 장애 후 밀린 알림을 모두 보낼지 최신 상태 하나만 보낼지도 운영 정책으로 정합니다.

완료 조건

  • 지정 구간의 시작 직전, 시작, 종료 직전과 종료 직후 검사 실행 여부가 의도와 일치합니다.
  • 설정 timezone과 DST 경계에서 다음 실행 시각이 확인됩니다.
  • 테스트 변경 한 건이 올바른 채널에 한 번 전달되고 비밀값과 민감한 페이지 데이터가 로그에 남지 않습니다.
  • 잘못된 웹훅, 429와 네트워크 단절이 구분되어 기록되고 재시도 상한과 경보가 동작합니다.
  • 웹훅 폐기와 재발급, 설정 백업 및 복원 절차를 운영자가 수행할 수 있습니다.