이벤트 센터 및 알림
이벤트 센터는 시스템에서 발생한 일을 기록하고, 알림 규칙은 어떤 이벤트를 어디로 보낼지 결정합니다. 먼저 이벤트가 안정적으로 기록되는지 확인한 뒤 가치 있는 알림만 소수 구성하여 정상적인 접속까지 모두 알림 소음이 되지 않도록 합니다.
데이터 간 관계
| 객체 | 역할 |
|---|---|
| 이벤트 | 로그인, 차단, 업데이트 또는 상태 변화 한 번을 나타내는 구조화된 레코드 |
| 제공자 | Webhook, 이메일 또는 메시지 푸시 채널의 연결 설정과 자격 증명 |
| 규칙 | 이벤트 유형, 시간 범위, 임계값, 집계 기준 및 쿨다운에 따라 알림 여부 결정 |
| 알림 대상 | 규칙에서 참조하는 제공자와 해당 규칙에만 적용되는 수신 대상 |
| 전송 기록 | 규칙이 트리거된 뒤 대상별로 생성되는 전송 및 재시도 레코드 |
이벤트를 삭제해도 이미 생성된 전송 기록은 삭제되지 않습니다. 전송 기록을 모두 지워도 이벤트나 규칙은 삭제되지 않습니다. 규칙을 삭제하면 이후 알림만 중지되고 기존 이벤트에는 영향을 주지 않습니다.
이벤트 페이지
이벤트 페이지는 현재 다음 21가지 시스템 이벤트를 인식합니다.
- 인증: 로그인 성공, 로그아웃, 로그인 실패, 세션 IP 변경
- 보안: 스캐너 차단, 게이트웨이 요청 제한, 게이트웨이 접근 범위 차단, WAF 차단
- SSH: 로그인 성공, 로그인 실패, IP 차단
- 네트워크: DDNS 업데이트, FRP 연결/연결 끊김, Cloudflared 연결/연결 끊김
- 시스템: fn-knock 업데이트 알림, CPU 경고/복구, 메모리 경고/복구
이벤트 레벨은 정보, 주의, 오류 및 심각으로 나뉘며 출처 시스템은 관리 패널, 인증 프록시 및 시스템 모니터로 나뉩니다.
페이지에서 다음 작업을 수행할 수 있습니다.
- 이벤트 ID, IP, 세션 또는 자격 증명 검색
- 이벤트 유형, 레벨 및 출처 시스템으로 필터링
- 페이지별로 확인하고 구조화된 세부 정보 열기
- 이벤트 하나를 삭제하거나 선택한 이벤트를 일괄 삭제
- 모든 이벤트 비우기
‘이벤트 비우기’는 이벤트 센터에 저장된 모든 이벤트를 삭제합니다. 괄호 안의 숫자는 현재 보기에 일치하는 이벤트 수를 알려 줄 뿐, 현재 필터 결과만 지운다는 뜻이 아닙니다. 이 작업은 되돌릴 수 없지만 알림 규칙과 전송 기록은 지우지 않습니다.
이벤트 세부 정보에는 유형에 따라 자격 증명, 인증 방식, 세션, IP와 위치, 실패 횟수, 차단 시간, DDNS 주소 변경, Trace ID, WAF 규칙, 터널 PID, 리소스 임계값 등의 필드가 표시됩니다. 게이트웨이 접근 범위 차단은 요청 Host, 경로, 메서드와 함께 전역 범위 또는 Host 사용자 지정 범위 중 무엇이 적용되었는지도 기록합니다. 문제를 해결할 때 세부 정보를 복사하여 요청 로그, WAF 로그 또는 터널 로그와 대조할 수 있습니다.
CPU 및 메모리 모니터링
리소스 모니터링은 런타임 기능을 지원하는 플랫폼에서만 시작되며 현재 Windows 배포에서는 사용할 수 없습니다. Linux 계열 환경에서는 시스템 리소스 정보를 바탕으로 전체 호스트 또는 현재 컨테이너에서 볼 수 있는 범위의 CPU와 사용 가능한 메모리를 계산하고 경고·복구 이벤트를 생성합니다. 프로세스별 성능 분석기가 아니므로 어떤 프로세스가 부하를 일으켰는지는 알려 주지 않습니다.
현재 기본 규칙은 다음과 같습니다.
| 지표 | 경고 임계값 | 복구 임계값 | 샘플링 간격 | 지속 시간 |
|---|---|---|---|---|
| CPU | 80% | 60% | 5초 | 30초 |
| 메모리 | 80% | 60% | 5초 | 30초 |
사용률이 경고 임계값에 지속적으로 도달해야 경고가 생성됩니다. 경고가 생성된 뒤에는 복구 임계값까지 지속적으로 내려가야 복구 이벤트가 생성됩니다. 60%–80%의 중간 구간은 임계값 부근에서 경고가 반복되는 것을 방지합니다. 짧은 순간 부하는 즉시 이벤트가 되지 않으며 첫 CPU 샘플은 계산 기준을 만드는 데만 사용됩니다.
현재 관리 화면에서는 리소스 이벤트를 보고 알림을 설정할 수 있지만 위의 샘플링 값과 임계값을 조정하는 UI는 없습니다. 알림 규칙의 시간 범위와 트리거 횟수를 리소스 샘플링 임계값으로 혼동하지 않습니다. 전자는 이미 생성된 이벤트를 어떻게 보낼지 결정하고 후자는 이벤트가 언제 생성되는지를 결정합니다.
Docker에서는 컨테이너 실행 환경에서 볼 수 있는 CPU와 메모리 범위가 표시됩니다. 배포할 때 리소스 제한을 설정했다면 해당 제한을 기준으로 경고를 해석합니다. 리소스 이벤트가 없다면 먼저 현재 플랫폼이 기능을 지원하고 이벤트 시스템이 정상인지 확인한 뒤 부하가 실제로 임계값을 계속 넘었는지 점검합니다.
제공자 설정
이벤트 센터 → 알림 → 제공자로 이동하여 전송 채널을 먼저 만들고 테스트합니다. 현재 제공자 목록은 다음과 같습니다.
- Webhook
- WxPusher
- ServerChan
- PushPlus
- WeCom
- DingTalk
- Feishu
- 이메일
- PushDeer
- HarmonyOS MeoW
- MagicPush
- Bark
- Telegram
채널마다 Markdown, 작업 버튼, 멘션 및 메시지 길이 지원 범위가 다릅니다. 제공자를 추가할 때 표시되는 필드와 기능 안내를 기준으로 설정합니다.
제공자를 만들 때 이름, 유형, 활성화 상태 및 연결 설정을 입력합니다. 일부 채널은 기본 수신 대상도 제공합니다. 규칙에서 같은 대상 필드를 비워 두면 제공자의 기본값을 사용합니다. 현재 WxPusher 알림을 받으려면 공식 클라이언트를 설치하고 로그인해야 하며 더 이상 WeChat 안에서 직접 메시지를 받을 수 없습니다.
저장하기 전에 폼의 초안 설정으로 전송을 테스트할 수 있고, 저장한 뒤에도 목록에서 다시 테스트할 수 있습니다. 민감한 필드는 편집할 때 ‘이미 설정되어 있습니다. 기존 값을 유지하려면 비워 둡니다.’라고 표시됩니다. 키를 유지하려고 이전 값을 다시 붙여넣지 않습니다.
Webhook URL, 토큰, SMTP 비밀번호 및 수신자 식별자는 민감한 설정이므로 공개 로그나 스크린샷에 넣으면 안 됩니다. 제공자를 규칙에서 사용 중이면 백엔드가 삭제를 차단합니다. 먼저 해당 규칙을 수정하거나 삭제합니다.
HarmonyOS MeoW
HarmonyOSMeoW를 선택한 뒤 다음 항목을 입력합니다.
| 필드 | 설명 |
|---|---|
서비스 URL | 공식 API는 기본 https://api.chuckfang.com을 사용. 자체 호스팅 호환 서비스는 루트 주소 입력 |
수신자 닉네임 | MeoW 클라이언트에 설정한 사용자 닉네임. /를 포함할 수 없으며 수신자 식별자이므로 민감한 자격 증명처럼 보관 |
시간 초과(초) | 기본값 5초, 1~30초로 설정 가능 |
이 채널은 Markdown 알림과 알림 작업을 지원하지만 멘션은 지원하지 않습니다. 저장한 뒤 테스트 메시지를 먼저 보내 HarmonyOS 기기에서 내용을 받는지 확인한 다음 제공자를 알림 규칙에 추가합니다.
알림 규칙 만들기
이벤트 센터 → 알림 → 규칙으로 이동합니다. 제공자가 하나 이상 있어야 규칙을 만들 수 있으며 현재 이벤트 유형마다 규칙을 하나만 만들 수 있습니다. 새 규칙을 만들 때는 아직 규칙이 없는 이벤트만 표시되며 여러 이벤트를 선택해 한 번에 만들 수 있습니다.
일괄 생성에는 다음 기본 트리거 조건을 사용합니다.
| 필드 | 새 규칙 기본값 | 설명 |
|---|---|---|
| 시간 범위 | 60초 | 해당 범위 안에서 같은 그룹의 이벤트 누적 |
| 트리거 횟수 | 1회 | 지정한 횟수에 도달하면 알림 생성 |
| 집계 기준 | 이벤트별 자동 권장 | 같은 그룹으로 계산할 이벤트 결정 |
| 쿨다운 | 60초 | 같은 그룹에서 트리거된 뒤 중복 알림 억제 |
규칙을 만든 뒤 트리거 조건을 하나씩 편집할 수 있습니다. 집계 기준에는 글로벌, IP, 세션, 주제, 호스트 이름 및 제공자가 있습니다. 자동 권장의 예는 다음과 같습니다.
- 로그인 실패, 스캐너, 게이트웨이 요청 제한, WAF 및 SSH 이벤트는 IP별로 집계
- 게이트웨이 접근 범위 차단은 전역으로 집계
- 세션 IP 변경은 세션별로 집계
- DDNS 업데이트는 제공자별로 집계
- CPU 및 메모리 이벤트는 호스트 이름별로 집계
- 터널 및 fn-knock 업데이트는 주제별로 집계
- 로그인 성공 및 로그아웃은 글로벌로 집계
규칙 하나에 제공자를 여러 개 추가할 수 있지만 같은 제공자를 한 규칙에 두 번 추가할 수는 없습니다. 일부 제공자는 규칙 대상에 수신자, Topic, Chat ID 또는 기타 대상 필드를 입력합니다. 이 필드는 현재 규칙에만 영향을 줍니다.
권장 시작 규칙
- 로그인 실패: IP별로 집계하고 짧은 시간 안에 여러 번 발생하면 알림
- 스캐너, 게이트웨이 요청 제한, WAF 및 SSH 차단: IP별로 집계
- 게이트웨이 접근 범위 차단: 기본적으로 전역 집계. 트래픽이 많으면 임계값을 높이거나 쿨다운을 늘려 같은 정책의 알림 폭주 방지
- DDNS: 제공자별로 집계하고 실패 결과에 주목
- FRP 및 Cloudflared: 주제별로 서로 다른 터널 구분
- CPU와 메모리: 경고 이벤트와 복구 이벤트에 모두 규칙 설정
- fn-knock 업데이트: 주제별로 알림 한 번 전송
로그인 성공, SSH 로그인 성공처럼 자주 발생하는 이벤트의 임계값을 1로 두면 알림이 매우 많이 생성될 수 있습니다. 실제 접속량에 맞춰 시간 범위, 임계값 및 쿨다운을 조정합니다.
전송 결과 확인
전송 기록에는 트리거 시각, 규칙, 제공자, 상태, 메시지 요약 및 시도 횟수가 표시됩니다. 상태에는 대기 중, 보내는 중, 성공, 실패 후 재시도, 최종 실패 및 건너뜀이 있습니다.
세부 정보에서 다음 항목을 확인할 수 있습니다.
- 규칙, 제공자 및 현재 상태
- 시도 횟수, 트리거 시각, 전송 시각 및 다음 재시도 시각
- 실패 또는 건너뛴 이유
- 전송 시점에 고정된 제목, 요약 및 본문 스냅샷
- 민감 정보를 가린 요청 요약과 응답 요약
‘규칙이 트리거되지 않음’과 ‘제공자가 받지 못함’을 구분하여 다음 순서로 확인합니다.
- 먼저 이벤트 자체가 생성되었는지 확인합니다.
- 해당 이벤트 유형에 규칙이 있고 규칙과 대상이 계속 활성화되어 있는지 확인합니다.
- 시간 범위, 임계값, 집계 기준 및 쿨다운을 확인합니다.
- 전송 기록이 있다면 상태, 실패 이유, 시도 횟수 및 다음 재시도 시각을 확인합니다.
- 제공자 연결, 자격 증명, 수신 대상 및 상대측 속도 제한을 확인합니다.
전송 기록을 지우면 전체 전송 이력이 삭제되어 복원할 수 없지만 이벤트와 이후 규칙 트리거에는 영향을 주지 않습니다. 감사 기록이 필요하다면 관련 세부 정보를 먼저 복사합니다.
알림 시스템은 대응을 돕는 보조 기능이며 요청 로그, WAF 로그 및 백업을 대신하지 않습니다.