통계 메트릭

개요

이 페이지는 통계 보기에서 사용 가능한 모든 메트릭에 대한 상세한 설명을 제공합니다. 이러한 메트릭은 과거 데이터에서 집계되고 계산된 값을 나타내며, 실시간 모니터링 값과 계산 방법에서 차이를 보일 수 있습니다.

통계는 세 가지 주요 섹션으로 구성됩니다:

1. 프로젝트: 프로젝트 수준에서 집계된 메트릭으로, 프로젝트 관리자에게 유용합니다
2. NetFUNNEL 서버 인스턴스: NetFUNNEL 서버 인스턴스 수준의 메트릭으로, 서버 관리자에게 유용합니다
3. 세그먼트: 세그먼트 수준의 메트릭으로, 세그먼트 관리자에게 유용합니다

메트릭 요약 표

다음 표는 모든 통계 메트릭에 대한 빠른 참조를 제공합니다. 각 메트릭은 아래 섹션에서 자세히 설명됩니다.

메트릭	단위	설명	실시간 동등 항목
프로젝트 및 세그먼트 메트릭
전체 요청 수	TPS	모든 트래픽 제어 API 호출의 평균 TPS	N/A
진입 요청	TPS	초기 진입 요청의 평균 TPS	진입 요청량
처리 시간	초	진입부터 키 반환까지의 평균 시간	처리 시간
대기 시간	초	기간 중 최대 대기 시간	대기 시간 (평균)
대기자	명	기간 중 누적 대기자 수	대기자 수 (현재)
진입 허용	-	기간 중 구성된 용량 제한	진입 허용 수
사용자	명	특정 순간의 활성 사용자 스냅샷	활성 사용자 수 (현재)
완료율(%)	%	명시적 종료의 완료율	완료율
우회	TPS	우회된 요청의 속도	N/A
차단	TPS	차단된 요청의 속도	N/A
NetFUNNEL 메트릭
CPU 점유율 (%)	%	측정 순간의 CPU 사용률	N/A
전체 요청 수	TPS	모든 API 요청의 평균 TPS (관리 API 포함)	N/A
세션	-	완료된 세션 수 (진입부터 완료까지)	N/A
차단	TPS	반복 요청 차단 기능에 의해 차단된 요청의 평균 속도	N/A

전역 메트릭 규칙

개별 메트릭을 살펴보기 전에 통계가 어떻게 계산되는지 이해하는 것이 중요합니다:

규칙 1: 1분 집계

모든 메트릭은 매분 새로운 값으로 집계됩니다. 이것은 다음을 의미합니다:

• 데이터가 지속적으로 수집됩니다
• 매분 새로운 집계 값이 계산됩니다
• 과거 데이터는 이러한 분 단위 값을 보여줍니다

예시:

00:00:00 - 00:01:00: 처리 시간 = 2.5초
00:01:00 - 00:02:00: 처리 시간 = 3.1초
00:02:00 - 00:03:00: 처리 시간 = 2.8초

규칙 2: 프로젝트 수준 집계

프로젝트 수준에서 값은 모든 세그먼트의 메트릭 합계입니다. 이것은 다음을 의미합니다:

• 3개의 세그먼트가 있으면 프로젝트 수준 메트릭은 3개 세그먼트의 합계입니다
• 전체 프로젝트 활동을 이해하는 데 유용합니다

예시:

프로젝트에 3개의 세그먼트가 있음:
- 세그먼트 A: 진입 요청 = 10 TPS
- 세그먼트 B: 진입 요청 = 15 TPS
- 세그먼트 C: 진입 요청 = 5 TPS
=> 프로젝트 진입 요청 = 30 TPS (10 + 15 + 5)

프로젝트 및 세그먼트 메트릭

이러한 메트릭은 프로젝트 및 세그먼트 수준 모두에서 사용할 수 있습니다. 프로젝트 수준 메트릭은 모든 세그먼트 메트릭의 합계입니다.

전체 요청 수

단위: TPS (초당 트랜잭션 수)

측정 내용:

⚠️ 중요: 이것은 프로젝트/세그먼트 수준 전체 요청 수 메트릭입니다. NetFUNNEL 에이전트가 만든 트래픽 제어 API 호출만 측정합니다.

초당 모든 트래픽 제어 API 호출이 이루어지는 평균 속도입니다. 이것을 애플리케이션과 NetFUNNEL 서버 간의 "총 트래픽 제어 통신량"으로 생각하세요.

중요한 이유: 이 메트릭은 전체 트래픽 제어 통신 부하를 이해하는 데 도움이 됩니다. 요청 유형에 관계없이 트래픽 제어 시스템이 얼마나 바쁜지 보여줍니다.

포함되는 내용 (트래픽 제어 API 호출만): NetFUNNEL 에이전트는 NetFUNNEL 서버에 네 가지 유형의 트래픽 제어 호출을 만듭니다:

1. 초기 진입 요청: 최초 키 발급 요청 (사용자가 진입하려고 시도)
2. 재진입 요청: 대기실에서의 진입 요청 (대기 후 재시도하는 사용자)
3. Alive Notice 요청: 구간 제어 중 활성 상태 알림 (세션 유지)
4. 완료 요청: 키 반환 요청 (사용자 완료, 키 반환)

포함되지 않는 내용:

• 데이터 쿼리 API 요청 (통계, 모니터링 대시보드용)
• 관리 API 요청
• 기타 비트래픽 제어 API 요청

실제 예시:

1분 동안:
- 100개의 초기 진입 요청
- 50개의 재진입 요청
- 200개의 Alive Notice 요청
- 100개의 완료 요청
총계: 60초 동안 450개의 트래픽 제어 요청 = 7.5 TPS

중요 참고사항: 이 메트릭은 실시간 모니터링에서 보이지 않습니다. 통계에서만 사용할 수 있어 트래픽 제어 통신의 과거 분석에 유용합니다.

NetFUNNEL 수준 전체 요청 수와의 차이:

• 이 메트릭 (프로젝트/세그먼트): 트래픽 제어 API 호출만 (위에 나열된 4가지 유형)
• NetFUNNEL 수준 전체 요청 수: 데이터 쿼리, 관리 API 등을 포함한 모든 API 요청

사용 시기:

• 트래픽 제어 통신 부하 이해
• 트래픽 제어 운영을 위한 용량 계획
• 비정상적인 트래픽 제어 패턴 식별

진입 요청

단위: TPS (초당 트랜잭션 수)

측정 내용: 초당 초기 키 발급 요청의 평균 속도. 초당 몇 명의 새 사용자가 서비스에 진입하려고 하는지 보여줍니다.

중요: 실시간 모니터링 진입량과 다름

⚠️ 실시간 모니터링의 "진입량"과 혼동하지 마세요! 둘 다 "진입"이라는 이름을 사용하지만 다른 것을 측정합니다:

측면	통계 진입 요청	실시간 모니터링 진입량
측정 내용	초기 진입 요청 (수요)	실제로 서비스에 진입하는 요청 (실제 부하)
해당 항목	실시간 모니터링의 진입 요청량	실시간 모니터링의 진입량
포함	최초 진입 시도만	PASS를 받은 모든 요청 (직접 진입 + 대기실에서 재진입)
의미	몇 명의 사용자가 진입하려고 하는지	몇 명의 사용자가 실제로 진입했는지

통계 진입 요청의 의미:

• 수요를 보여줍니다 (몇 명의 사용자가 진입하려고 하는지)
• 시도를 측정합니다 (최초 진입 요청)
• 일부는 대기실로 가고, 일부는 직접 진입할 수 있습니다
• 과거 평균: 현재 값이 아님

실시간 모니터링 진입량의 의미:

• 실제 부하를 보여줍니다 (실제로 서비스에 진입하는 요청)
• 성공적인 진입을 측정합니다 (PASS를 받은 요청)
• 직접 진입과 대기실에서 재진입 모두 포함
• 현재 값 (지금 일어나고 있는 것)

실제 예시:

1분 동안 (60초):
- 1-10초: 5개의 초기 진입 요청
- 11-20초: 8개의 초기 진입 요청
- 21-30초: 12개의 초기 진입 요청
- 31-40초: 10개의 초기 진입 요청
- 41-50초: 7개의 초기 진입 요청
- 51-60초: 9개의 초기 진입 요청

총계: 60초 동안 51개의 초기 진입 요청
통계 진입 요청 = 51 ÷ 60 = 0.85 TPS

참고: 이 51개 요청이 모두 즉시 진입한 것은 아닙니다.
일부는 대기실로 갔고, 일부는 직접 진입했습니다.
실제 서비스 부하는 실시간 모니터링 진입량에 표시됩니다.

실시간 모니터링과의 관계:

• 통계 진입 요청은 실시간 모니터링의 진입 요청량에 해당합니다 (수요 측면)
• 실시간 모니터링 진입량은 실시간 모니터링의 진입량에 해당합니다 (실제 부하 측면)

통계는 현재 값이 아닌 과거 평균 값을 보여줍니다.

사용 시기:

• 과거 수요 패턴 이해
• 다른 기간 간 수요 비교
• 과거 수요를 기반으로 용량 계획

처리 시간

단위: 초 (초)

측정 내용: 사용자가 서비스를 활발히 사용하는 평균 시간으로, 진입(PASS 수신)부터 키를 반환할 때까지입니다. 이것은 실제 서비스 사용 기간을 나타냅니다.

중요한 이유: 처리 시간은 사용자가 실제로 서비스를 사용하는 시간을 알려줍니다. 더 긴 시간은 다음을 의미할 수 있습니다:

• 서비스가 더 많은 작업을 수행하고 있음
• 서버가 부하 상태 (처리 속도 저하)
• 사용자가 서비스에서 더 많은 시간을 보내고 있음

계산 방법: 시스템은 1분 기간 동안의 모든 처리 시간의 평균을 계산합니다.

계산 예시:

1분 동안 (00:00:00 ~ 00:01:00):
- 사용자 A: 00:00:10에 진입, 00:00:11에 키 반환 → 1초
- 사용자 B: 00:00:15에 진입, 00:00:17에 키 반환 → 2초
- 사용자 C: 00:00:20에 진입, 00:00:26에 키 반환 → 6초
- 사용자 D: 00:00:30에 진입, 00:00:32에 키 반환 → 2초
- 사용자 E: 00:00:45에 진입, 00:00:46에 키 반환 → 1초

평균 처리 시간 = (1 + 2 + 6 + 2 + 1) ÷ 5 = 2.4초

실제 시나리오:

시나리오 1: 빠른 서비스 (예: 간단한 API 호출)

처리 시간: 0.5 - 1.5초
→ 서비스가 빠르게 응답하고, 사용자가 빠르게 완료함

시나리오 2: 보통 서비스 (예: 페이지 로드)

처리 시간: 2 - 5초
→ 정상적인 페이지 로딩 시간

시나리오 3: 느린 서비스 (예: 무거운 계산)

처리 시간: 10초 이상
→ 서비스가 부하 상태이거나 복잡한 작업을 수행 중일 수 있음

처리 시간에 영향을 미치는 요인:

• 환경 특성: 서버 성능, 네트워크 속도
• 서비스 유형: 간단한 API vs 복잡한 페이지 vs 무거운 계산
• 통합 구현: nfStart() 및 nfStop() 호출 방법

사용 시기:

• 일반적인 서비스 사용 기간 이해
• 시간에 따른 성능 저하 식별
• 다른 기간 간 처리 시간 비교

대기 시간

단위: 초

측정 내용: 1분 기간 동안 모든 사용자가 경험한 가장 긴 대기 시간. 가장 부정적이었던 사용자 경험을 보여줍니다.

중요한 이유: 평균 대기 시간은 일반적인 경험을 알려주지만, 최대 대기 시간은 최악의 경험을 알려줍니다. 이 수치는 다음을 이해하는 데 도움이 됩니다:

• 피크 기간 사용자 경험
• 일부 사용자가 너무 오래 대기하고 있는지 여부
• 용량 조정이 필요한지 여부

계산 방법: 시스템은 해당 분 동안 대기한 모든 사용자 중 단일 최장 대기 시간을 찾습니다.

계산 예시:

1분 동안 (00:00:00 ~ 00:01:00):
- 사용자 A: 00:00:10부터 00:00:11까지 대기 → 1초 대기
- 사용자 B: 00:00:15부터 00:00:17까지 대기 → 2초 대기
- 사용자 C: 00:00:20부터 00:00:26까지 대기 → 6초 대기 (가장 김!)
- 사용자 D: 00:00:30부터 00:00:32까지 대기 → 2초 대기

대기 시간 = 6초 (최대값)

실제 시나리오:

시나리오 1: 낮은 대기 시간 (좋음)

대기 시간: 1-3초
→ 사용자가 오래 대기하지 않음, 좋은 사용자 경험

시나리오 2: 보통 대기 시간 (허용 가능)

대기 시간: 5-10초
→ 일부 대기하지만 대부분의 사용자에게 허용 가능

시나리오 3: 높은 대기 시간 (주의 필요)

대기 시간: 30초 이상
→ 사용자가 너무 오래 대기 중, 진입 허용 증가 고려

운영 인사이트: 통계의 높은 대기 시간은 수요에 비해 진입 허용이 너무 낮게 설정된 기간을 나타낼 수 있습니다. 지속적으로 높은 대기 시간이 보이면 다음을 고려할 수 있습니다:

• 진입 허용 증가 (서버 용량이 허용하는 경우)
• 용량을 더 잘 계획하기 위해 수요 패턴 검토

실시간 모니터링과의 관계: 이것은 실시간 모니터링의 대기 시간과 유사하지만, 통계는 현재 평균이 아닌 과거 최대 값을 보여줍니다.

사용 시기:

• 최악의 사용자 경험 이해
• 긴 대기가 있는 피크 기간 식별
• 용량 조정 계획

대기자

단위: 명

측정 내용: 1분 기간 동안 대기실에 진입한 사용자의 누적 수. 이것은 총 대기 수요를 보여주며, 현재 대기자 수가 아닙니다.

중요한 구분:

• 통계 대기자: 기간 동안 대기한 모든 사용자의 누적 수
• 실시간 대기자 수: 지금 대기 중인 사용자의 현재 수

중요한 이유: 이 메트릭은 다음을 이해하는 데 도움이 됩니다:

• 몇 명의 사용자가 대기를 경험했는지
• 기간 동안 총 대기 수요
• 대기가 일반적인 경험인지 여부

계산 방법: 시스템은 1분 기간 동안 대기실에 진입한 모든 사용자를 계산합니다.

계산 예시:

1분 동안 (00:00:00 ~ 00:01:00):
- 00:00:05: 사용자 A가 대기실에 진입
- 00:00:12: 사용자 B가 대기실에 진입
- 00:00:18: 사용자 C가 대기실에 진입
- 00:00:25: 사용자 D가 대기실에 진입
- 00:00:35: 사용자 E가 대기실에 진입
- 00:00:48: 사용자 F가 대기실에 진입

대기자 = 6명 (누적 수)

실제 시나리오:

시나리오 1: 대기 없음

대기자: 0명
→ 모든 사용자가 즉시 진입, 대기실이 필요 없음

시나리오 2: 가벼운 대기

대기자: 분당 10-50명
→ 일부 사용자가 대기하지만 많지 않음

시나리오 3: 무거운 대기

대기자: 분당 100명 이상
→ 많은 사용자가 대기를 경험하고 있음, 높은 수요

실시간 모니터링과의 관계: 이것은 실시간 모니터링의 대기자 수와 유사하지만, 통계는 현재 값이 아닌 과거 누적 값을 보여줍니다.

사용 시기:

• 대기 수요 패턴 이해
• 다른 기간 간 대기 비교
• 피크 대기 기간 식별

진입 허용

단위: - (차원 없는 수, 단순 숫자)

측정 내용: 1분 기간 동안 관리자 콘솔에서 구성된 진입 허용 값. 이것은 해당 시간에 허용된 최대 용량을 나타냅니다.

중요한 이유: 진입 허용은 "용량 게이트"입니다. 동시에 활성화될 수 있는 사용자 수를 제어합니다. 이것을 실제 사용량(사용자 메트릭)과 비교하면 다음을 볼 수 있습니다:

• 용량이 적절하게 설정되었는지
• 사용하지 않은 용량이 있었는지
• 용량이 너무 낮았는지 (대기자 발생)

실제 예시:

1분 동안:
- 진입 허용: 100명
- 사용자 (실제): 95명
→ 5명의 용량 미사용 (5% 여유)

다른 1분 동안:
- 진입 허용: 100명
- 사용자 (실제): 100명
→ 용량 완전 활용 (0% 여유)

또 다른 1분 동안:
- 진입 허용: 100명
- 사용자 (실제): 100명
- 대기자: 50명
→ 용량 가득 참, 사용자 대기 중 (증가 필요할 수 있음)

해석 방법:

• 진입 허용 > 사용자: 사용하지 않은 용량이 있음
• 진입 허용 = 사용자: 용량이 완전히 활용됨
• 진입 허용 < 수요: 사용자가 대기실에 배치됨 (대기자 메트릭 확인)

실시간 모니터링과의 관계: 이것은 실시간 모니터링에서 사용되는 진입 허용 수 설정에 해당합니다.

사용 시기:

• 과거 용량 설정 검토
• 대기자가 형성된 이유 이해 (진입 허용이 너무 낮았는지)
• 과거 패턴을 기반으로 향후 용량 설정 계획

사용자

단위: 명

측정 내용: 특정 순간의 활성 사용자 스냅샷. 활성 사용자는 키를 받았지만 아직 반환하지 않은 사용자입니다. 현재 서비스를 사용 중입니다.

중요: 이것은 스냅샷이며 평균이 아닙니다!

• 특정 순간의 수를 보여줍니다 (예: 00:00:01)
• 누적 값이 아닙니다 (시간에 따라 합산되지 않음)
• 평균이 아닙니다 (여러 측정값의 평균이 아님)

중요한 이유: 이것은 해당 순간에 서비스를 활발히 사용 중인 사용자 수를 알려줍니다. 방의 사진을 찍고 그 안에 몇 명이 있는지 세는 것과 같습니다.

실제 예시:

00:00:01 (스냅샷 순간):
- 사용자 A: 키 보유, 서비스 사용 중
- 사용자 B: 키 보유, 서비스 사용 중
- 사용자 C: 키 보유, 서비스 사용 중
- 사용자 D: 키 보유, 서비스 사용 중
- 사용자 E: 키 보유, 서비스 사용 중

사용자 = 5명 (스냅샷 수)

00:01:01 (다음 스냅샷):
- 사용자 A: 키 반환 (더 이상 활성 아님)
- 사용자 B: 여전히 키 보유
- 사용자 C: 여전히 키 보유
- 사용자 D: 키 반환 (더 이상 활성 아님)
- 사용자 E: 여전히 키 보유
- 사용자 F: 방금 키 수신 (새로 활성화됨)

사용자 = 4명 (새 스냅샷)

진입 허용과의 비교:

진입 허용: 100명
사용자 (스냅샷): 95명
→ 5명의 용량 사용 가능

진입 허용: 100명
사용자 (스냅샷): 100명
→ 용량 가득 참, 새 사용자는 대기실에 배치됨

실시간 모니터링과의 관계: 이것은 실시간 모니터링의 활성 사용자 수와 유사하지만, 통계는 현재 값이 아닌 과거 스냅샷을 보여줍니다.

사용 시기:

• 특정 순간의 동시 사용량 이해
• 실제 사용량과 용량 제한 비교
• 피크 사용량 순간 식별

완료율(%)

단위: % (비율)

측정 내용: 서비스에 진입하고 명시적으로 키를 반환한 (제대로 완료한) 사용자의 비율. 이것은 통합 상태를 보여줍니다 - 사용자가 세션을 제대로 완료하고 있나요?

중요한 이유: 높은 완료율(%)은 사용자가 세션을 제대로 완료하고 있음을 의미합니다. 낮은 비율은 다음을 나타낼 수 있습니다:

• 코드에 nfStop() 호출 누락
• 통합 문제
• 사용자가 세션을 포기함

계산 방법: 시스템은 다음을 계산합니다: (명시적으로 키를 반환한 사용자) ÷ (진입한 사용자) × 100

계산 예시:

1분 동안 (00:00:00 ~ 00:01:00):
진입한 사용자: 10명
- 사용자 A: 진입하고 키 반환 ✅
- 사용자 B: 진입하고 키 반환 ✅
- 사용자 C: 진입하고 키 반환 ✅
- 사용자 D: 진입했지만 키 반환하지 않음 (타임아웃) ❌
- 사용자 E: 진입하고 키 반환 ✅
- 사용자 F: 진입하고 키 반환 ✅
- 사용자 G: 진입했지만 키 반환하지 않음 (타임아웃) ❌
- 사용자 H: 진입하고 키 반환 ✅
- 사용자 I: 진입하고 키 반환 ✅
- 사용자 J: 진입하고 키 반환 ✅

명시적으로 키를 반환한 사용자: 8명
완료율(%) = (8 ÷ 10) × 100 = 80%

실제 시나리오:

시나리오 1: 우수한 통합 (좋음)

완료율(%): 90-100%
→ 거의 모든 사용자가 세션을 제대로 완료함
→ 통합이 잘 작동하고 있음

시나리오 2: 좋은 통합 (허용 가능)

완료율(%): 70-89%
→ 대부분의 사용자가 제대로 완료함
→ 일부는 타임아웃될 수 있지만 허용 가능

시나리오 3: 나쁜 통합 (주의 필요)

완료율(%): <70%
→ 많은 사용자가 제대로 완료하지 않음
→ nfStop() 호출 누락 또는 통합 문제일 가능성
→ 조사하고 수정해야 함

완료율(%)이 낮을 때 해야 할 일:

1. 즉시: 용량을 빠르게 해제하기 위해 타임아웃 값 감소
2. 조사: nfStop()이 제대로 호출되고 있는지 확인
3. 장기: 키 반환 누락을 유발하는 통합 문제 수정

실시간 모니터링과의 관계: 이것은 실시간 모니터링의 완료율에 해당하지만, 통계는 과거 평균을 제공합니다.

사용 시기:

• 시간에 따른 통합 상태 모니터링
• 통합 문제가 있는 기간 식별
• 다른 기간 간 완료율 비교

우회

단위: TPS (초당 트랜잭션 수)

측정 내용: 초당 BYPASS 응답을 받은 요청의 평균 속도. 이것들은 NetFUNNEL 대기실을 완전히 우회한 요청입니다.

발생 이유: 일반적으로 사용자가 진입하려고 하면 NetFUNNEL은 다음으로 응답합니다:

• WAIT: 대기실로 이동
• PASS: 즉시 진입

하지만 세그먼트 또는 프로젝트가 비활성화되면 NetFUNNEL은 다음을 보냅니다:

• BYPASS: 대기실을 완전히 우회 (NetFUNNEL이 활성화되지 않은 것처럼)

실제 예시:

시나리오: 세그먼트가 비활성화됨
- 사용자 A가 초기 진입 요청 전송 → BYPASS 수신
- 사용자 B가 초기 진입 요청 전송 → BYPASS 수신
- 사용자 C가 재진입 요청 전송 → BYPASS 수신

1분 동안: 30개의 BYPASS 응답
우회 = 30 ÷ 60 = 0.5 TPS

우회가 보일 때:

• 세그먼트가 비활성화됨
• 프로젝트가 비활성화됨

해석:

• 우회 > 0: 일부 요청이 대기실을 우회함 (세그먼트/프로젝트가 비활성화됨)
• 우회 = 0: 모든 요청이 정상적인 NetFUNNEL 흐름을 거침

사용 시기:

• 세그먼트가 비활성화된 시기 이해
• 유지보수/테스트 기간 검토
• 트래픽 제어가 활성화되었는지 확인

차단

단위: TPS (초당 트랜잭션 수)

측정 내용: 초당 BLOCK 응답을 받은 요청의 평균 속도. 이것들은 진입이 차단된 요청입니다.

발생 이유: 일반적으로 사용자가 진입하려고 하면 NetFUNNEL은 다음으로 응답합니다:

• WAIT: 대기실로 이동
• PASS: 즉시 진입

하지만 요청이 차단되는 경우 (BLOCK 수신):

• 세그먼트 차단 모드: 세그먼트가 차단 모드로 설정됨 (의도적 차단)

참고: 반복 요청 차단 기능에 의해 차단된 요청(302 상태 코드 반환)은 이 차단 메트릭에 포함되지 않습니다. 반복 요청 차단 통계는 NetFUNNEL 서버 인스턴스 수준에서 별도로 추적됩니다.

실제 예시:

시나리오: 세그먼트가 차단 모드로 설정됨
- 사용자 A가 초기 진입 요청 전송 → BLOCK 수신 (세그먼트가 차단 모드)
- 사용자 B가 초기 진입 요청 전송 → BLOCK 수신 (세그먼트가 차단 모드)
- 사용자 C가 초기 진입 요청 전송 → BLOCK 수신 (세그먼트가 차단 모드)
- 사용자 D가 초기 진입 요청 전송 → BLOCK 수신 (세그먼트가 차단 모드)

1분 동안: 20개의 BLOCK 응답
차단 = 20 ÷ 60 = 0.33 TPS

참고: 반복 요청 차단이 트리거된 경우 (302 응답), 그것들은 여기에 계산되지 않습니다.

차단이 보일 때:

• 세그먼트가 의도적으로 차단 모드로 설정됨
• 봇 방지 보호가 트리거됨
• 남용 방지 보호가 트리거됨
• 의심스러운 요청 패턴이 감지됨

중요: 이 메트릭은 반복 요청 차단(302 응답)에 의해 차단된 요청을 포함하지 않습니다. 반복 요청 차단 통계는 NetFUNNEL 서버 인스턴스 수준 차단 메트릭을 참조하세요.

해석:

• 차단 > 0: 일부 요청이 차단됨 (보안/남용 방지 작동 중)
• 차단 = 0: 차단된 요청 없음

사용 시기:

• 보안/남용 방지 효과 이해
• 차단된 요청 패턴 검토
• 차단 기능이 작동하고 있는지 확인

NetFUNNEL 서버 인스턴스 수준 메트릭

이러한 메트릭은 NetFUNNEL 서버 인스턴스 수준에서 확인됩니다. 이것들은 NetFUNNEL 서버 자체의 유지보수 메트릭입니다.

관리형 서비스 고객의 경우

NetFUNNEL을 관리형 서비스로 사용하는 경우 일반적으로 이러한 메트릭을 모니터링할 필요가 없습니다. 서버 설치를 관리하는 NetFUNNEL 서버 관리자 또는 엔지니어에게 유용합니다.

CPU 점유율 (%)

단위: % (비율)

측정 내용: 측정 순간의 NetFUNNEL 서버 CPU 사용률로, 비율(0-100%)로 표현됩니다.

중요한 이유: 높은 CPU 사용률은 다음을 나타낼 수 있습니다:

• 서버가 무거운 부하 상태
• 성능 문제
• 서버 확장 필요

실제 예시:

00:00:01: CPU 점유율 = 45%
→ 서버가 CPU 용량의 45% 사용 중
→ 55% 용량 사용 가능

00:01:01: CPU 점유율 = 85%
→ 서버가 CPU 용량의 85% 사용 중
→ 15% 용량 사용 가능 (높아지고 있음)

사용 시기:

• 서버 리소스 사용률 모니터링
• 성능 병목 식별
• 서버 용량 계획

전체 요청 수 (NetFUNNEL 수준)

단위: TPS (초당 트랜잭션 수)

측정 내용: ⚠️ 중요한 구분: 이것은 프로젝트/세그먼트 "전체 요청 수" 메트릭과 완전히 다릅니다!

이 메트릭은 NetFUNNEL 서버에 대한 모든 유형의 API 요청을 포함하며, 트래픽 제어 요청만이 아닙니다. 모든 서버 활동의 포괄적인 뷰입니다.

포함되는 내용 (모든 API 요청):

1. 트래픽 제어 API 요청 (프로젝트/세그먼트 수준과 동일한 4가지 유형):
   • 초기 진입 요청
   • 재진입 요청
   • Alive Notice 요청
   • 완료 요청
2. 데이터 쿼리 API 요청: 통계 데이터, 모니터링 대시보드, 보고서 요청
3. 관리 API 요청: 서버 관리, 구성, 관리 작업
4. 기타 API 요청: NetFUNNEL 서버에 대한 기타 모든 유형의 API 호출

주요 차이점:

측면	프로젝트/세그먼트 전체 요청 수	NetFUNNEL 수준 전체 요청 수
범위	트래픽 제어 API 호출만	모든 API 요청
포함	4가지 유형의 트래픽 제어 호출	트래픽 제어 + 데이터 쿼리 + 관리 + 기타
목적	트래픽 제어 부하 이해	총 서버 부하 이해
사용 사례	트래픽 제어 용량 계획	서버 용량 계획

실제 예시:

1분 동안:
트래픽 제어 요청 (프로젝트/세그먼트 수준과 동일):
- 100개의 초기 진입 요청
- 50개의 재진입 요청
- 200개의 Alive Notice 요청
- 100개의 완료 요청
소계: 450개 요청

추가 요청 (프로젝트/세그먼트 수준에 없음):
- 50개의 통계 쿼리 요청 (대시보드 새로고침)
- 10개의 관리 API 요청 (구성 변경)
- 5개의 기타 API 요청

총계: 60초 동안 515개 요청
전체 요청 수 = 515 ÷ 60 = 8.58 TPS

중요한 이유:

• 프로젝트/세그먼트 전체 요청 수: 애플리케이션의 트래픽 제어 활동을 보여줍니다
• NetFUNNEL 수준 전체 요청 수: 관리 작업, 대시보드 쿼리 등을 포함한 총 서버 부하를 보여줍니다

사용 시기:

• 총 서버 부하 이해 (모든 API 유형 결합)
• NetFUNNEL 서버 인프라 용량 계획
• 비정상적인 서버 활동 식별 (관리 작업 포함)
• 서버 리소스 계획 및 확장 결정

세션

단위: - (차원 없는 수, 단순 숫자)

측정 내용: NetFUNNEL 서버에서 완료된 세션 수. 세션은 서버에서 진입(초기 요청)부터 완료(키 반환)까지의 하나의 완전한 사용자 여정을 나타냅니다.

중요한 이유: 이 메트릭은 다음을 이해하는 데 도움이 됩니다:

• 서버가 처리한 총 사용자 세션 수
• 완료된 사용자 상호작용 측면의 서버 작업량
• 전체 서버 활동 수준

계산 방법: 시스템은 측정 기간 동안 완료된 각 세션(진입부터 키 반환까지)을 계산합니다. 통계에서 이 값은 선택한 기간에 따라 집계됩니다:

• 일 보기: 분당 세션 합계
• 월 보기: 시간당 세션 합계
• 년 보기: 일당 세션 합계

실제 예시:

1분 동안 (00:00:00 ~ 00:01:00):
- 사용자 A: 00:00:10에 진입, 00:00:15에 완료 → 1세션
- 사용자 B: 00:00:20에 진입, 00:00:25에 완료 → 1세션
- 사용자 C: 00:00:30에 진입, 00:00:35에 완료 → 1세션

세션 = 3세션 (총 수)

사용 시기:

• 완료된 세션 측면의 총 서버 활동 이해
• 다른 기간 간 서버 작업량 비교
• 세션 볼륨을 기반으로 서버 용량 계획

차단 (NetFUNNEL 수준)

단위: TPS (초당 트랜잭션 수)

측정 내용: ⚠️ 중요: 이것은 프로젝트/세그먼트 수준 차단 메트릭과 다른 NetFUNNEL 서버 인스턴스 수준 차단 메트릭입니다.

NetFUNNEL 서버 수준에서 반복 요청 차단 기능에 의해 초당 차단된 요청의 평균 속도. 이 메트릭은 반복 요청 차단 기능에 의해 차단된 요청을 계산합니다 (예: 시간 내 요청 제한을 초과하는 클라이언트 차단 또는 영구적으로 차단된 클라이언트).

중요한 이유: 이 메트릭은 다음을 이해하는 데 도움이 됩니다:

• 서버 수준에서 반복 요청 차단 기능에 의해 차단되는 요청 수
• 서버 수준 남용 방지 효과
• 차단된 요청으로 인한 서버 부하

계산 방법: 시스템은 측정 기간 동안 반복 요청 차단 기능에 의해 차단된 요청을 계산하고 초당 평균 속도를 계산합니다. 통계에서 이 값은 선택한 기간에 따라 집계됩니다:

• 일 보기: 분당 차단된 요청 합계, 그 다음 TPS로 평균화
• 월 보기: 시간당 차단된 요청 합계, 그 다음 TPS로 평균화
• 년 보기: 일당 차단된 요청 합계, 그 다음 TPS로 평균화

실제 예시:

1분 동안 (00:00:00 ~ 00:01:00):
- 요청 A: 차단됨 (반복 요청 차단) → 계산됨
- 요청 B: 차단됨 (반복 요청 차단) → 계산됨
- 요청 C: 허용됨 (정상) → 계산되지 않음
- 요청 D: 차단됨 (반복 요청 차단) → 계산됨

총계: 60초 동안 3개의 차단된 요청
차단 = 3 ÷ 60 = 0.05 TPS

프로젝트/세그먼트 수준 차단과의 차이:

• 이 메트릭 (NetFUNNEL 수준): 서버 수준에서 반복 요청 차단 기능으로 인한 차단
• 프로젝트/세그먼트 수준 차단: 세그먼트 차단 모드 또는 반복 요청 차단으로 인한 차단

사용 시기:

• 서버 수준 반복 요청 차단 기능 효과 모니터링
• 서버 남용 방지 활동 이해
• 서버 인프라 수준에서 차단된 요청 패턴 검토

메트릭 참조

각 메트릭이 트래픽 흐름 맥락에서 무엇을 나타내는지에 대한 자세한 설명은 메트릭 빠른 참조를 참조하세요. 개념은 동일하지만 통계는 실시간 스냅샷이 아닌 과거 집계 값을 제공합니다.