사용량 UI 를 사용하여 청구 가능한 사용자 수에 대한 개요를 확인할 수 있습니다. UI가 제공하는 것보다 더 자세한 정보가 필요한 경우 사용 관련 NRQL 쿼리 를 실행할 수도 있습니다.
청구 가능 사용자에 대한 청구는 매월 이루어집니다. 한 달 동안 조직의 청구 가능 사용자 수를 결정하기 위해 해당 달 동안 전체 플랫폼 사용자 또는 핵심 사용자 중 billable user type 보유한 사용자 수를 계산합니다. 사용자의 billable user type (는) 해당 월 동안 사용자가 설정된 가장 높은 사용자 유형으로 정의됩니다. 우리는 UTC 시간대를 사용하여 한 달의 시작과 끝을 정의합니다.
이것이 실제로 어떻게 작동하는지에 대한 예: 사용자가 한 달 중 어느 시점에든 전체 플랫폼 사용자로 설정되면 해당 월에 청구 가능한 사용자 유형은 full platform user이며 다운그레이드하더라도 변경되지 않습니다. 그 달 말에. 이는 해당 사용자가 잠시 동안만 전체 플랫폼 사용자로 변경된 경우에도 마찬가지입니다.
청구 가능한 사용자를 추가하거나 사용자 유형을 변경할 계획이라면 이러한 규칙을 염두에 두어야 합니다. 몇 가지 팁:
청구 가능한 사용자를 추가하거나 사용자를 업그레이드하려는 경우 월초에 수행하는 것이 좋습니다.
사용자를 다운그레이드하려면 월말에 다운그레이드하는 것이 좋습니다.
UTC 시간을 사용하여 한 달의 시작과 끝을 결정합니다. 즉, 예를 들어 태평양 표준시를 기준으로 월말에 사용자를 다운그레이드하려면 태평양 표준시 오후 5시까지 변경해야 합니다.
동일한 이메일 주소를 사용하는 조직 내 사용자는 한 명의 사용자로만 계산됩니다. 자세한 내용은 사용자 추적을 참조하세요.
최신 사용자 모델 의 사용자: 관리자가 청구 가능한 사용자로 추가한 사용자는 청구할 수 있습니다. 청구 가능한 사용자가 New Relic에 로그인한 적이 없고 UI에 Pending invite 태그가 있더라도 여전히 청구 가능합니다. ( 원래 사용자 모델 의 사용자는 Pending invite 명의 사용자에게 청구할 수 없습니다.)
약정 계약이있는 조직의 경우 전체 플랫폼 사용자 다운그레이드 및 업그레이드에 적용되는 규칙은 다음과 같습니다.
If a full platform user is downgraded to a lower user type in a later month and then returned to a full platform user in a later month, and this downgrade/upgrade cycle happens twice in a contract year, that user will be billed as a full platform user for the remainder of the year, regardless of edits to their user type.사용자 청구 방식 으로 인해 한 달 내에 발생하는 사용자 유형 변경을 관리하는 규칙은 없습니다. 한 달 동안 사용자의 청구 가능 사용자 유형은 해당 월에 설정된 가장 높은 사용자 유형입니다.
다음은 이 규칙의 맥락에서 사용되는 용어에 대한 세부 정보입니다.
downgrade 은 한 달 안에 전체 플랫폼 사용자로 요금이 청구되다가 다음 달에 더 낮은 사용자 유형(코어 또는 기본)으로 요금이 청구되거나 삭제됨을 의미합니다.
upgrade 은 한 달 동안 핵심 사용자, 기본 사용자(또는 이전에 삭제된 사용자)로 요금이 청구되다가 다음 달에 전체 플랫폼 사용자로 요금이 청구되는 것을 의미합니다.
contract year 은 계약 시작 시점 또는 해당 시점의 기념일에 시작됩니다. 조직에서 다른 요금제로 시작하여 약정 계약으로 전환한 경우 사용자 유형 다운그레이드 규칙은 선택한 날짜부터 계약 갱신 날짜 또는 약정 기간의 연간 갱신일 중 더 빠른 날짜까지 적용됩니다.
팁
Why do we have rules governing full platform user downgrades/upgrades?
전체 플랫폼 사용자 유형은 장기적인 분류를 목적으로 합니다. 우리는 약정 계약을 생성할 때 청구 가능한 사용자의 추정치를 사용하며 이러한 규칙을 통해 이러한 계약 제한을 일관되게 구현하고 있습니다.
다운그레이드 한도의 예
계약 연도가 3월에 시작한다고 가정해 보겠습니다. 그리고 사용자가 다음 계정 유형을 매월 순환한다고 가정해 보겠습니다.
사용자는 3월에 전체 플랫폼 사용자로 청구됩니다.
사용자는 4월(downgrade)에 기본 사용자로 요금이 청구됩니다.
사용자는 6월(upgrade)에 전체 플랫폼 사용자로 요금이 청구됩니다.
사용자는 7월(downgrade)에 기본 사용자로 요금이 청구됩니다.
해당 사용자가 다음 달에 전체 플랫폼 사용자로 돌아오면 이후 기본 사용자 또는 핵심 사용자로 다시 다운그레이드되더라도 해당 계약 연도의 남은 기간 동안 전체 플랫폼 사용자로 요금이 청구됩니다.
계층형 가격 책정
일부 조직에서는 청구 가능한 사용자에 대한 계층형 가격 책정에 액세스할 수 있습니다. 이에 대한 자세한 내용은 계층형 가격 책정 을 참조하십시오.