이벤트 센터 및 알림

이벤트 센터는 시스템에서 발생한 일을 기록하고, 알림 규칙은 어떤 이벤트를 어디로 보낼지 결정합니다. 먼저 이벤트가 안정적으로 기록되는지 확인한 뒤 가치 있는 알림만 소수 구성하여 정상적인 접속까지 모두 알림 소음이 되지 않도록 합니다.

데이터 간 관계

객체	역할
이벤트	로그인, 차단, 업데이트 또는 상태 변화 한 번을 나타내는 구조화된 레코드
제공자	Webhook, 이메일 또는 메시지 푸시 채널의 연결 설정과 자격 증명
규칙	이벤트 유형, 시간 범위, 임계값, 집계 기준 및 쿨다운에 따라 알림 여부 결정
알림 대상	규칙에서 참조하는 제공자와 해당 규칙에만 적용되는 수신 대상
전송 기록	규칙이 트리거된 뒤 대상별로 생성되는 전송 및 재시도 레코드

이벤트를 삭제해도 이미 생성된 전송 기록은 삭제되지 않습니다. 전송 기록을 모두 지워도 이벤트나 규칙은 삭제되지 않습니다. 규칙을 삭제하면 이후 알림만 중지되고 기존 이벤트에는 영향을 주지 않습니다.

이벤트 페이지

이벤트 페이지는 현재 다음 28가지 시스템 이벤트를 인식합니다.

• 인증: 로그인 성공, 로그아웃, 로그인 실패, 세션 IP 변경
• 보안: 스캐너 차단, 게이트웨이 요청 제한, 게이트웨이 접근 범위 차단, WAF 차단
• SSH: 로그인 성공, 로그인 실패, IP 차단
• 네트워크: DDNS 업데이트, FRP 연결/연결 끊김, Cloudflared 연결/연결 끊김
• 원격 깨우기: 관리자, 포털, Blinker 또는 Bemfa의 WOL 브로드캐스트 완료
• 터미널: SSH 대상 변경, 호스트 지문 확인, 연결 테스트, 로컬 터미널 활성화/비활성화, 로컬 또는 원격 세션의 생성·종료·Shell 종료·유실
• 시스템: fn-knock 업데이트 알림, CPU 경고/복구, 메모리 경고/복구
• 런타임: 구성 요소 시작, 중지, 다시 시작, 상태 검사 실패, 복구 및 비정상 종료

이벤트 레벨은 정보, 주의, 오류 및 심각으로 나뉘며 출처 시스템은 관리 패널, 인증 프록시, 시스템 모니터 및 런타임 모니터로 나뉩니다.

페이지에서 다음 작업을 수행할 수 있습니다.

• 이벤트 ID, IP, 세션 또는 자격 증명 검색
• 이벤트 유형, 레벨 및 출처 시스템으로 필터링
• 페이지별로 확인하고 구조화된 세부 정보 열기
• 이벤트 하나를 삭제하거나 선택한 이벤트를 일괄 삭제
• 모든 이벤트 비우기

‘이벤트 비우기’는 이벤트 센터에 저장된 모든 이벤트를 삭제합니다. 괄호 안의 숫자는 현재 보기에 일치하는 이벤트 수를 알려 줄 뿐, 현재 필터 결과만 지운다는 뜻이 아닙니다. 이 작업은 되돌릴 수 없지만 알림 규칙과 전송 기록은 지우지 않습니다.

이벤트 세부 정보에는 유형에 따라 자격 증명, 인증 방식, 세션, IP와 위치, 실패 횟수, 차단 시간, DDNS 주소 변경, Trace ID, WAF 규칙, 터널 PID, WOL 대상과 전달 출처, 리소스 임계값 등의 필드가 표시됩니다. 게이트웨이 접근 범위 차단은 요청 Host, 경로, 메서드와 함께 전역 범위 또는 Host 사용자 지정 범위 중 무엇이 적용되었는지도 기록합니다. 문제를 해결할 때 세부 정보를 복사하여 요청 로그, WAF 로그, 터널 로그 또는 장치 온라인 상태와 대조할 수 있습니다.

로컬 터미널 이벤트에는 터미널 백엔드, 실행 계정 및 특권 계정 여부가 표시되어 세션이 실제로 어떤 권한으로 실행되었는지 확인할 수 있습니다. 터미널 이벤트는 설정 변경과 세션 수명 주기만 감사하며 관리자가 Shell에 입력한 개별 명령은 저장하지 않습니다. 명령 단위 기록이 필요하면 호스트나 원격 SSH 대상에 별도의 감사 기능을 구성해야 합니다.

페이지 위의 Trace ID 조회에는 응답 헤더, 차단 페이지, 요청 로그 또는 알림의 전체 ID를 붙여 넣을 수 있습니다. 전체 경로 추적은 같은 요청의 WAF, 시스템 이벤트, 알림 트리거와 전송을 연결합니다. 이전 이벤트나 비활성화된 수집은 일부 경로만 표시할 수 있습니다.

내비게이션 패널 동기화 실패/복구와 원격 장치 SSH 종료도 기록되므로 고정된 이벤트 유형 개수에 의존하지 마세요. 인증 및 보안 이벤트는 IP 위치 캐시를 공유합니다. 캐시되지 않은 주소는 먼저 저장한 뒤 비동기로 위치를 보완하며 알림도 사용 가능한 보완 필드를 사용합니다.

핵심 서비스 상태 및 진단

이벤트 센터 → 상태는 5초마다 관리 서비스, Go 게이트웨이 프로세스, 게이트웨이 데이터 플레인, 인증 브리지, 저장소 및 설정 동기화 상태를 갱신합니다. 프로세스 카드에는 버전, PID, 시작 시각, CPU, 메모리 또는 Go 런타임 정보가 표시되고 서비스 카드에는 검사 지연 시간과 연속 실패 원인이 표시됩니다. 종속 구성 요소로 인해 차단됨은 현재 구성 요소 자체는 실행할 수 있지만 필요한 상위 구성 요소가 준비되지 않은 상태입니다.

상태 페이지는 세 가지 문제 해결 자료를 제공합니다.

작업	내용 및 범위
진단 정보 복사	현재 버전, 플랫폼, 구성 요소 상태 및 최근 런타임 이벤트의 JSON 요약 복사
로그 보기	관리 서비스 또는 Go 게이트웨이의 마스킹된 핵심 런타임 로그를 최근 200개 표시하며 요청, WAF 및 인증 레코드는 제외
진단 패키지 내보내기	diagnostics.json과 크기가 제한된 관리, 게이트웨이 및 감독 프로세스 로그 다운로드

핵심 진단 로그 전체 한도는 6 MiB입니다. 한도에 도달하면 파일을 교체하거나 우선순위가 낮은 항목을 버립니다. 상태 페이지에서 로그 범위, 디스크 사용량 및 버린 INFO 수를 확인할 수 있습니다. 구성 요소 로그를 비우면 해당 구성 요소의 현재 및 이전 세대 핵심 런타임 로그만 삭제되며 런타임 이벤트, 충돌 로그 및 다른 구성 요소 로그는 유지됩니다.

일반적인 비밀 키 필드는 마스킹되지만 진단 패키지에는 버전, 플랫폼, 경로, 구성 요소 상태 및 장애 시각이 포함될 수 있습니다. 공유하기 전에 내용을 검토합니다. 요청 세부 정보는 요청 로그 또는 WAF 로그에서 별도로 내보냅니다.

Rust 런타임 진단

이벤트 센터 → 상태 → 런타임 진단에서 60초 수집 시작을 누르면 현재 Rust 관리 프로세스의 리소스, 백그라운드 작업, SQLite 작업 통계를 매초 수집합니다. 창을 여는 것만으로 수집을 시작하지 않습니다. 중간에 중지하고 결과를 보관할 수 있으며 창을 닫아도 서버 수집은 자동 완료됩니다.

메모리 상세 수집은 별도의 요청 시점 스냅샷이며 메모리를 회수하지 않습니다. JSON 내보내기로 초별 샘플, 작업 통계, 메모리 상세를 보관합니다. 상태 페이지의 진단 내보내기에도 현재 보고서가 포함됩니다. 새 수집은 이전 결과를 대체하며 서비스 재시작 시 사라지므로 먼저 내보냅니다.

CPU는 논리 코어 하나의 최대 부하를 100%로 표시하며 기준이 없는 첫 샘플은 0이 아닙니다. 작업 경과 시간은 대기를 포함하므로 CPU 시간과 다릅니다. Linux는 더 상세한 정보, macOS는 주로 프로세스 CPU와 RSS, Windows는 주로 작업 집합을 제공합니다. 사용 불가 필드를 0으로 해석하지 않습니다. 다른 인스턴스와 Go 게이트웨이 사용량은 포함하지 않으며 한 번의 RSS 증가만으로 메모리 누수를 판단할 수 없습니다.

Go 게이트웨이 메모리

Go 게이트웨이 프로세스 카드 오른쪽 아래의 메모리 버튼에서 가비지 컬렉션 강도와 Go 런타임 소프트 메모리 한도를 조정하고 즉시 회수를 실행할 수 있습니다. 상태 카드의 Heap, RSS, GC 횟수, 활성 요청 및 연결 수는 추세를 판단하는 데 사용합니다. 소프트 한도는 Go 런타임이 관리하는 메모리를 제한하며 프로세스 RSS의 하드 한도가 아닙니다.

• 적극적(GOGC 50)은 더 자주 회수하여 보통 메모리를 줄이지만 CPU 사용량을 늘립니다. 균형(100)이 기본값이고 여유(200)는 처리량을 우선합니다. 사용자 지정 범위는 25–500입니다.
• 자동 메모리 한도는 실행 환경 유효 메모리의 약 4분의 1을 사용하며 128–512 MiB 범위로 제한합니다. 유효 메모리를 읽지 못하면 256 MiB를 사용합니다.
• 수동 한도는 64–4096 MiB이며 현재 유효 시스템 메모리의 50%를 넘을 수 없습니다. 저장한 값은 게이트웨이 시작 시 서비스 트래픽을 받기 전에 복원됩니다.
• 즉시 회수는 잠시 CPU 사용량을 높이거나 일시 정지를 일으킬 수 있습니다. 문제 해결이나 회수 효과 확인에만 사용하고 정기 최적화 버튼처럼 반복해서 누르지 않습니다.

메모리가 적은 NAS나 컨테이너에서는 먼저 자동 한도를 유지합니다. 상태 페이지에서 Heap/RSS 압박이 계속되고 트래픽, 심층 모니터링 또는 비정상 연결을 제외한 뒤에만 GOGC를 단계적으로 낮추거나 수동 한도를 설정합니다. 변경 후 CPU, 지연 시간 및 게이트웨이 상태를 함께 관찰합니다.

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 비밀번호 및 수신자 식별자는 민감한 설정이므로 공개 로그나 스크린샷에 넣으면 안 됩니다. 제공자를 규칙에서 사용 중이면 백엔드가 삭제를 차단합니다. 먼저 해당 규칙을 수정하거나 삭제합니다.

Webhook 사용자 지정 내용

Webhook 제공자는 사용자 지정 헤더와 표준, JSON, 텍스트 본문을 지원합니다. 규칙의 Webhook 대상은 제공자 설정을 상속하거나 본문을 재정의할 수 있습니다. 미리 본 뒤 테스트 요청을 보내 수신 측 형식을 확인합니다.

편집기는 이벤트별 알림 상세 필드와 이벤트 유형, 위험 수준, 출처, 발생 시간, 집계 같은 공통 필드를 제공합니다. {{message.fact_values.login_ip}}, {{message.fact_values.credential_name}} 등 고정 이름을 사용합니다. 이름은 언어나 순서에 따라 바뀌지 않으며 값은 알림의 표시 형식을 유지합니다. 원본 데이터에는 event.payload.*를 사용합니다.

{{message.fact_values}}는 전체 객체를 참조합니다. JSON 문자열에 변수 하나만 있으면 타입을 유지하고 다른 텍스트와 섞이면 문자열이 됩니다. 이벤트에 없는 필드는 미리보기에서 누락으로 표시되며 독립 JSON 변수는 null, 텍스트 안에서는 빈 문자열로 처리됩니다. 전송은 차단하지 않습니다.

샘플 Context를 비우면 서버 샘플을 사용합니다. 샘플 JSON을 채워 대상 이벤트 데이터로 수정하면 표준 및 사용자 지정 본문 미리보기와 테스트에 사용됩니다. 저장되지 않으며 실제 전송에 영향을 주지 않습니다. 재시도는 원본 메시지 스냅샷을 사용하고 과거 메시지에는 fact_values가 없을 수 있습니다.

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 업데이트는 주제별로 집계
• Wake-on-LAN 완료는 장치를 구분하도록 주제별로 집계
• 로그인 성공 및 로그아웃은 글로벌로 집계

규칙 하나에 제공자를 여러 개 추가할 수 있지만 같은 제공자를 한 규칙에 두 번 추가할 수는 없습니다. 일부 제공자는 규칙 대상에 수신자, Topic, Chat ID 또는 기타 대상 필드를 입력합니다. 이 필드는 현재 규칙에만 영향을 줍니다.

권장 시작 규칙

• 로그인 실패: IP별로 집계하고 짧은 시간 안에 여러 번 발생하면 알림
• 스캐너, 게이트웨이 요청 제한, WAF 및 SSH 차단: IP별로 집계
• 게이트웨이 접근 범위 차단: 기본적으로 전역 집계. 트래픽이 많으면 임계값을 높이거나 쿨다운을 늘려 같은 정책의 알림 폭주 방지
• DDNS: 제공자별로 집계하고 실패 결과에 주목
• FRP 및 Cloudflared: 주제별로 서로 다른 터널 구분
• CPU와 메모리: 경고 이벤트와 복구 이벤트에 모두 규칙 설정
• fn-knock 업데이트: 주제별로 알림 한 번 전송
• Wake-on-LAN: 주제별로 집계. 실패 결과는 경고에 사용하며 성공 결과도 브로드캐스트가 제출되었다는 뜻일 뿐 장치가 온라인이라는 보장은 아님

로그인 성공, SSH 로그인 성공처럼 자주 발생하는 이벤트의 임계값을 1로 두면 알림이 매우 많이 생성될 수 있습니다. 실제 접속량에 맞춰 시간 범위, 임계값 및 쿨다운을 조정합니다.

애플리케이션 업데이트 이벤트에 릴리스 노트가 포함된 경우 시스템은 현재 업데이트 대상의 릴리스 노트 요약을 일반 텍스트 본문과 Markdown 본문에 모두 기록합니다. 따라서 구조화된 세부 정보가 아닌 본문만 표시하는 푸시 채널에서도 내용을 받을 수 있습니다. 알림은 여러 이전 릴리스의 내용을 이어 붙이지 않습니다. 전체 내용이나 더 오래된 내용은 버전 및 업데이트 페이지 또는 프로젝트 릴리스 기록에서 확인해야 합니다.

전송 결과 확인

전송 기록에는 트리거 시각, 규칙, 제공자, 상태, 메시지 요약 및 시도 횟수가 표시됩니다. 상태에는 대기 중, 보내는 중, 성공, 실패 후 재시도, 최종 실패 및 건너뜀이 있습니다.

세부 정보에서 다음 항목을 확인할 수 있습니다.

• 규칙, 제공자 및 현재 상태
• 시도 횟수, 트리거 시각, 전송 시각 및 다음 재시도 시각
• 실패 또는 건너뛴 이유
• 전송 시점에 고정된 제목, 요약 및 본문 스냅샷
• 민감 정보를 가린 요청 요약과 응답 요약

‘규칙이 트리거되지 않음’과 ‘제공자가 받지 못함’을 구분하여 다음 순서로 확인합니다.

1. 먼저 이벤트 자체가 생성되었는지 확인합니다.
2. 해당 이벤트 유형에 규칙이 있고 규칙과 대상이 계속 활성화되어 있는지 확인합니다.
3. 시간 범위, 임계값, 집계 기준 및 쿨다운을 확인합니다.
4. 전송 기록이 있다면 상태, 실패 이유, 시도 횟수 및 다음 재시도 시각을 확인합니다.
5. 제공자 연결, 자격 증명, 수신 대상 및 상대측 속도 제한을 확인합니다.

전송 기록을 지우면 전체 전송 이력이 삭제되어 복원할 수 없지만 이벤트와 이후 규칙 트리거에는 영향을 주지 않습니다. 감사 기록이 필요하다면 관련 세부 정보를 먼저 복사합니다.

알림 시스템은 대응을 돕는 보조 기능이며 요청 로그, WAF 로그 및 백업을 대신하지 않습니다.

• 요청 로그
• WAF
• SSH 보안
• Wake-on-LAN