자주 묻는 질문¶

버전 선택 및 결제 방식¶

세션 리플레이도 로그처럼 3일 또는 7일의 저장 기간을 별도로 설정할 수 있나요?

버전에 따라 다릅니다.

• 상용 플랜: 지원하지 않습니다. 세션 리플레이 데이터 보존 정책은 실제 사용자 모니터링(RUM)과 연동되어 있으며, RUM의 보존 정책(3일/7일/14일)을 통일적으로 사용하므로 개별적으로 조정할 수 없습니다.
• 배포 플랜: 관리 백엔드에서 세션 리플레이의 보존 정책을 개별적으로 구성할 수 있습니다.

주요 비즈니스는 중국 지역에 있지만 일부 사용자가 해외에 있습니다. 결제 시 인민폐와 달러 중 어떤 것을 선택해야 하나요?

Guance에는 두 개의 결제 센터 시스템이 있습니다.

통화 선택은 세금 계산서 유형 및 결제 방식에 영향을 미치며, 워크스페이스 등록 시 결정해야 합니다. 비즈니스가 여러 지역에 걸쳐 있는 경우 각각 다른 지역의 워크스페이스를 생성하여 현지 통화로 결제하는 것이 좋습니다.

이미 인민폐로 한동안 결제를 사용해 왔는데, 달러 결제로 전환할 수 있나요?

직접 셀프 전환은 불가능합니다. 서로 다른 결제 센터 시스템(중국 지역 vs 글로벌 지역) 및 계정 이전과 관련되어 있으므로 다음이 필요합니다.

1. 고객 담당자에게 통화 전환 신청 제출
2. 기존 워크스페이스의 과거 청구는 인민폐 결제 유지
3. 전환 후 새로 발생한 비용은 달러로 결제

전환 전에 인민폐 계정 미납액을 정산하고, 환율 변동이 예산에 미치는 영향을 평가하는 것이 좋습니다.

로그량은 많지만 액세스 빈도는 낮습니다. 상용 플랜과 엔터프라이즈 플랜 중 어떤 것이 더 저렴한가요?

"쓰기 트래픽"과 "저장 용량"의 비율 관계에 따라 다릅니다.

• 상용 플랜: 쓰기량(건수 또는 트래픽) + 저장 기간 구간별 과금. 데이터 액세스 빈도가 높고 장기 저장이 필요하며 빈번한 쿼리가 필요한 시나리오에 적합합니다. 단기 저장(3-7일)만 필요한 경우 상용 플랜이 일반적으로 더 경제적입니다.

• 엔터프라이즈 플랜: 압축 후 쓰기 트래픽 + 저장 용량 기준 과금, 저장 기간과 무관합니다. 로그량이 매우 많지만 쿼리 빈도가 낮고 장기 아카이빙이 필요한 시나리오에 적합합니다. 360일을 저장하더라도 단가는 기간에 따라 구간별로 상승하지 않지만, 저장 용량에 대한 비용을 지속적으로 지불해야 합니다.

데이터 압축률이 높고(예: 텍스트 로그는 20%까지 압축 가능) 저장 기간이 30일인 경우, 고객 담당자에게 연락하여 엔터프라이즈 플랜 방안을 평가받는 것이 좋습니다.

데이터 보존 정책 변경¶

로그 저장 기간을 14일에서 3일로 줄였는데도 청구 비용이 즉시 줄어들지 않는 이유는 무엇인가요?

이는 롤링 과금 메커니즘 때문입니다. 비메트릭 데이터(로그, Trace 등)의 정책을 변경하면 다음과 같습니다.

1. 기존 데이터: 원래 저장 기간(14일)에 도달할 때까지 계속 보존되며, 원래 정책의 높은 단가로 과금됩니다.
2. 신규 데이터: 즉시 새 정책의 낮은 단가로 과금됩니다.

따라서 비용 감소는 14일의 전환 기간이 필요합니다. 즉시 비용을 줄여야 하는 경우 수동으로 기존 데이터를 삭제해야 하지만, 데이터 손실이 발생합니다.

메트릭 데이터의 보존 정책을 변경하면 기존 데이터가 즉시 삭제되고 비용이 즉시 감소하지만, 데이터는 복구할 수 없습니다.

같은 날 저장 정책을 여러 번 수정하면 어떤 기준이 적용되나요?

당일 첫 번째 수정은 즉시 적용되고, 이후 수정은 다음 날 적용됩니다.

시나리오 예:

• 09:00: 로그를 14일에서 7일로 변경 → 즉시 적용, 당일부터 7일 단가로 과금
• 15:00: 로그를 7일에서 3일로 다시 변경 → 다음 날 0시에 적용, 오늘은 여전히 7일로 과금

하루에 여러 번 조정하면 혼란스러운 과금 기록이 발생할 수 있으므로 권장하지 않습니다.

데이터 보존 정책 변경 후 메트릭 데이터와 비메트릭 데이터의 처리가 다른 이유는 무엇인가요?

• 메트릭 데이터: 변경 후 즉시 적용, 기존 데이터는 즉시 삭제되며 복구할 수 없습니다. 메트릭 데이터는 데이터 양이 많고 업데이트가 빈번하기 때문에 시스템이 즉시 정리 정책을 사용합니다.

• 비메트릭 데이터(로그, Trace, Profile, RUM 등): 변경 후 새 데이터는 새 정책으로 과금되고, 기존 데이터는 원래 저장 기간이 종료될 때까지 보존됩니다. 비메트릭 데이터는 일반적으로 감사 가치가 있어 데이터 연속성을 보장해야 합니다.

메트릭 저장 기간을 단축하면 즉시 비용을 줄일 수 있지만, 비메트릭 저장 기간을 단축하면 전환 기간이 지나야 전체 비용 절감 효과를 볼 수 있습니다.

"사용자 정의 다중 인덱스"를 활성화한 후 저장 정책 변경이 "기본" 인덱스만 변경할 수 있는 이유는 무엇인가요? 다른 인덱스는 어떻게 하나요?

각 인덱스는 독립적으로 보존 정책에 바인딩됩니다. 변경 단계:

1. 로그 > 인덱스 관리로 이동
2. 각 사용자 정의 인덱스에 대해 각각 저장 기간 설정
3. 각 인덱스는 각자의 기간 정책에 따라 과금

특정 사용자 정의 인덱스에 대해 개별적으로 정책을 설정하지 않은 경우 기본적으로 default 인덱스의 정책을 상속합니다. 하지만 과금 시 각 인덱스는 독립적으로 집계되며 합산 계산되지 않습니다.

과금 항목 및 계산 로직¶

상용 플랜에서 로그가 건수 기준 과금과 쓰기 트래픽 기준 과금 중 어떤 것이 더 유리한지 전환 시점은 언제인가요?

핵심은 로그 하나의 평균 크기입니다.

• 1개 < 1KB: 건수 기준 과금이 일반적으로 더 유리합니다(1GB 약 100만 건, 건수 기준 과금 시 1단위일 수 있음).
• 1개 > 10KB(ES) 또는 > 2KB(SLS): 트래픽 기준 과금이 더 유리하며, 큰 로그가 여러 건으로 분할되어 과금되는 것을 방지합니다.

모니터의 감지 간격을 30분으로 설정한 경우, 트리거는 2회(30/15)로 계산되나요? 아니면 6회(기본 5회 + 1회 초과)로 계산되나요?

후자가 맞습니다. 과금 공식은 다음과 같습니다.

총 횟수 = 감지 유형 기본 횟수 + ⌈(감지 간격 - 15분) / 15분⌉

"돌연변이 감지"(기본 5회)의 경우 30분 간격:

• 기본: 5회
• 초과 부분: (30-15)/15 = 1, 올림하여 1회
• 합계: 6회

지능형 모니터링의 "사용자 액세스 지능형 감지"가 "호스트 지능형 감지"보다 10배 더 비싼 이유는 무엇인가요?

과금 계수가 다르기 때문입니다.

• 호스트/로그/애플리케이션 지능형 감지: 10회/실행
• 사용자 액세스 지능형 감지: 100회/실행

이는 사용자 액세스 데이터의 양이 일반적으로 더 많고 계산 복잡도가 더 높기 때문입니다. 예산이 제한된 경우 호스트 지능형 감지를 우선 사용하거나 모니터의 사용자 정의 감지 규칙으로 지능형 감지를 대체하는 것이 좋습니다.

분산 추적 데이터가 때로는 Trace 기준으로, 때로는 Span 기준으로 과금됩니다. 내 청구서를 어떻게 예측할 수 있나요?

시스템이 자동으로 더 유리한 방식을 선택합니다.

• Trace 수 ≥ Span 수/10인 경우 Trace 기준으로 과금(백만 개 Trace당)
• 그렇지 않으면 Span 기준으로 과금(천만 개 Span당)

APM의 서비스 개요를 확인하면 평균 Trace당 포함된 Span 수가 > 10이면 Span 기준으로 과금될 가능성이 높고, < 10이면 Trace 기준으로 과금될 가능성이 높습니다. 샘플링 전략을 조정하여 Trace 수를 제어함으로써 과금 방식에 영향을 줄 수 있습니다.

에스컬레이션 정책 알림이 트리거될 때마다 100회의 트리거가 차감됩니다. 알림을 보낼 때마다 차감되나요?

네, 에스컬레이션 정책이 한 번 적중될 때마다 알림을 보낼 때 100회의 트리거가 기록됩니다.

상용 플랜에서 이벤트 및 자체 호스팅 신서틱 테스트 데이터가 기본적으로 로그 default 인덱스의 보존 정책을 사용하는 이유는 무엇인가요?

이 두 유형의 데이터가 물리적으로 로그의 default 인덱스에 저장되기 때문입니다.

• 이벤트 데이터(모니터, SLO, 지능형 점검에서 생성)는 default 인덱스에 저장됩니다.
• 자체 호스팅 신서틱 테스트 데이터는 DataKit을 통해 보고되며 마찬가지로 default 인덱스에 저장됩니다.

따라서 이들의 저장 기간 및 과금 단가는 default 인덱스의 구성을 상속합니다. 개별적으로 조정해야 하는 경우 현재로서는 이벤트 또는 자체 호스팅 신서틱 테스트에 대해 독립적인 보존 정책을 직접 설정할 수 없으며, default 인덱스의 기간을 조정하여 간접적으로 영향을 미칠 수만 있습니다.

예외: Guance 노드의 신서틱 테스트 데이터도 default 인덱스에 저장되지만, 신서틱 테스트 실행 자체는 신서틱 테스트 횟수에 따라 별도로 과금되며 저장 과금과는 다른 차원입니다.

데이터 분할 및 압축 과금¶

대용량 로그의 ES와 SLS 저장소 분할 임계값이 다릅니다. 실제 건수는 어떻게 계산되나요?

저장 유형에 따라 각각 계산합니다.

ES 저장소:

• 단일 ≤ 10 KB: 1건으로 계산
• 단일 > 10 KB: 과금 건수 = ⌈실제 크기/10 KB⌉

예: 15 KB 로그는 2건, 25 KB는 3건으로 계산

SLS 저장소:

• 단일 ≤ 2 KB: 1건으로 계산
• 단일 > 2 KB: 과금 건수 = ⌈실제 크기/2 KB⌉

예: 3 KB 로그는 2건, 5 KB는 3건으로 계산

세션 리플레이의 Session이 5시간 지속되어 2개의 과금 단위로 분할되었습니다. 이 두 단위는 연속적으로 과금되나요, 아니면 실제 활성 시간에 따라 할당되나요?

올림하여 정수배로 과금되며, 시간 분포와는 무관합니다.

과금 단위 = ⌈time_spent / 4시간⌉ = ⌈5/4⌉ = 2 단위

이 2 단위는 당일 청구서에 한 번에 포함되며, 시간별로 분할하여 과금되지 않습니다. Session 중간에 1시간 동안 비활성 상태가 있더라도 time_spent 필드에 총 시간이 5시간으로 표시되면 2 단위로 과금됩니다.

Profile 파일이 300KB를 초과하여 분할되는 경우, 분할된 건수로 각각 저장되나요, 아니면 과금만 분할되나요?

과금만 분할되며 저장은 원본 파일 그대로 유지됩니다. 시스템은 큰 Profile 파일을 여러 레코드로 분할하여 인덱싱 및 과금(300KB당 1건)하지만, 저장 계층에서는 여전히 한 번의 Profile 수집으로 연결됩니다. 이는 단일 레코드가 너무 커서 쿼리 성능에 영향을 미치는 것을 방지하는 동시에 과금과 저장 리소스 소비가 비례하도록 하기 위함입니다.

PV 과금에서 "PV와 PV/100 중 큰 값 취함"은 무엇을 의미하나요?

이는 낮은 트래픽 시나리오를 위한 최소 보장 과금 메커니즘입니다.

• 당일 PV 수가 500인 경우 500/100=5, 큰 값인 500을 취하여 500으로 과금
• 당일 PV 수가 50인 경우 50/100=0.5, 큰 값인 50을 취하여 여전히 50으로 과금(0.5 또는 1이 아님)

PV 수가 > 100인 경우에만 "PV/100"이 1보다 커지며, 이때는 PV 수 자체를 취합니다. 이 규칙은 주로 매우 낮은 트래픽 시 계산 정밀도 문제를 방지하기 위한 것이며, 정상적인 비즈니스 트래픽(>100 PV/일)에는 실제 영향이 없습니다.

민감 데이터 스캔에서 동일한 로그의 여러 필드가 마스킹 처리되는데, 왜 여러 번의 비용이 발생하나요?

과금이 필드 수준의 스캔 트래픽을 기반으로 하기 때문입니다.

• 마스킹이 필요한 각 필드는 원본 트래픽을 개별적으로 계산합니다.
• 이러한 필드가 동일한 로그에 속하더라도 각각 별도로 과금됩니다.

예: 1KB 로그에 3개의 민감 필드가 포함된 경우 스캔 과금은 3개 필드의 총 원본 트래픽(필드 내용 크기에 따라 1KB보다 클 수 있음)을 기준으로 계산되며, 단일 로그 1KB를 기준으로 계산되지 않습니다.

버전 전환 및 데이터 전환¶

무료 플랜에서 상용 플랜으로 업그레이드한 후에도 무료 기간의 데이터를 볼 수 없는 이유는 무엇인가요?

무료 플랜 데이터는 독립 인스턴스에 저장됩니다. 업그레이드 후:

• DataKit 구성: 자동으로 상용 플랜 워크스페이스를 가리키며 데이터는 계속 보고됩니다.
• 기존 데이터: 무료 플랜 환경에 남아 있으며 일반적으로 7일 후 자동으로 정리되어 상용 플랜에서 볼 수 없습니다.

무료 플랜의 기존 데이터는 상용 플랜으로 마이그레이션할 수 없습니다. 보관이 필요한 경우 업그레이드 전에 데이터 내보내기 기능을 통해 백업하시기 바랍니다.