API는 "유형 \"RootMutationType\".” 에서 \"eventExportRegisterRule\" 필드를 쿼리할 수 없습니다."라는 오류 메시지를 반환합니다.
여러 계정이있는 New Relic 조직의 경우: 서비스 수준은 단일 계정에만 연결할 수 있습니다. 여러 계정에 걸쳐 엔터티가 있는 워크로드에 대한 서비스 수준을 생성하려는 경우 연결된 모든 엔터티가 동일한 계정에 있도록 워크로드를 재구성할 수 있습니다. 계정당 최대 500개의 SLI를 생성할 수 있습니다.
New Relic은 매우 다양한 소스에서 다양한 방식으로 데이터를 수집합니다. 각각은 고유한 특성을 가지고 있어 데이터 소비 방식에 많은 가능성을 제공합니다. 데이터의 특성으로 인해 서비스 수준을 구성할 수 없는 몇 가지 시나리오가 있습니다.
Subqueries
. 하위 쿼리는 지원되지 않습니다.
Addition of sum functions
. SELECT sum(attributeA) 또는 SELECT sum(attributeA + attributeB) 사용할 수 있지만 SELECT sum(attributeA) + sum(attributeB) 표현식은 지원되지 않습니다.
SLI 및 SLO 생성을 위한 주요 개념
SLI 및 SLO를 정의할 때 이러한 개념을 염두에 두십시오.
주요 사용자 경험 정의
팀이 소유한 가장 높은 수준의 주요 사용자 경험을 생각한 다음 더 세분화해도 가치가 없을 때까지 근본적인 주요 사용자 경험에 집중하십시오. 시작할 SL을 선택할 때 하향식 접근 방식을 사용하는 것이 좋습니다. 즉, 가장 세분화되지 않은 것부터 시작하고 필요한 경우에만 더 세분화된 SL을 만드는 것입니다.
먼저 "시스템 경계"를 식별합니다. 이것은 사용자가 기능의 "블랙 박스"로 인식하는 시스템의 일부입니다. 몇 가지 예:
API의 경우 단순히 서비스일 수 있습니다.
데이터 파이프라인의 경우 데이터를 엔드 투 엔드로 처리하는 데 필요한 서비스 체인일 수 있습니다.
이러한 최상위 서비스 수준을 설정한 후에는 서비스의 모든 엔드포인트가 동일한 방식으로 작동하지 않는다는 사실을 발견하고 이를 더 분할할 수 있습니다. 예를 들어:
로그인 트랜잭션은 찾아보기보다 오류에 대해 더 높은 SLO가 필요할 수 있습니다.
일부 작업의 기간이 나머지 작업보다 훨씬 깁니다.
예를 들어 높은 수준에서 New Relic의 주요 사용자 경험은 다음과 같습니다. 고객이 원격 측정 데이터를 보내고 해당 데이터를 나중에 제품 API 또는 UI에서 쿼리할 수 있습니다.
해당 사용자 경험을 위해 다음과 같은 SLO를 만들 수 있습니다.
기간
표적
범주
지시자
지난 28일
99.9%
지연 시간
사용자가 수집한 데이터는 1분 이내에 쿼리할 수 있습니다.
이러한 종류의 사용자 경험은 일반적으로 둘 이상의 서비스를 포함하며 여러 팀 및 조직 경계에 분산되어 있습니다.
기본 사용자 경험의 세분화를 증가시키면서 New Relic의 또 다른 핵심 사용자 경험은 다음과 같습니다. 고객은 맞춤형 대시보드를 사용하여 원격 측정 데이터를 시각화할 수 있습니다.
이 SLO는 다음과 같습니다.
기간
표적
범주
지시자
지난 28일
99.9%
유효성
사용자가 대시보드 UI와 성공적으로 상호 작용합니다.
세분성을 너무 멀리 가져간 예로 대시보드에 차트 위젯을 추가하는 것도 사용자 경험입니다. 그러나 이 작업에 대한 특정 SLO를 생성하는 것은 사용자가 대시보드 UI와 성공적으로 상호 작용하는 것에 대한 이전 SLO에 비해 추가 값을 제공하지 않습니다.
요약하면 하향식 접근 방식을 사용하고 가장 세분화된 서비스 수준부터 시작하십시오. 필요한 경우에만 더 세분화된 서비스 수준을 만드십시오.
관련 기관
New Relic 생태계에서 모든 서비스 수준은 데이터를 당사에 보고하거나 액세스 권한이 있는 데이터를 생성하는 스택의 모든 요소인 다른 엔티티 에 연결됩니다. 서비스 수준이 관련된 엔터티는 SLI/SLO 결과가 표시되는 위치를 결정합니다.
New Relic에 보고되는 모든 NRDB 이벤트 또는 차원 메트릭에 대해 SLI를 정의할 수 있습니다. 대부분의 사용자 지정 이벤트는 단일 New Relic 엔터티와 관련이 없지만 더 높은 수준의 비즈니스 및 사용자 경험 통찰력을 제공합니다. 이 경우에도 SLI를 특정 엔터티 또는 워크로드와 연결할 수 있습니다.
SLI 쿼리는 관련 엔터티가 있는 동일한 계정의 범위에 속해야 합니다.
SLI 쿼리
SLI는 유효한 요청의 총 수에서 좋은 응답의 비율로 정의됩니다. 대부분 유효하고 좋은 부분을 정의하여 SLI를 설정합니다.
valid request
은 SLI에 대해 의미 있는 것으로 간주하려는 요청입니다(예: 상태 확인으로 시작되지 않은 엔드포인트와 관련된 모든 트랜잭션).
good response
은 최종 사용자 또는 클라이언트 서비스에 좋은 출력을 제공하기 위해 고려되는 응답입니다(예: 서비스가 2초 이내에 응답하여 최종 사용자에게 좋은 탐색 환경을 제공함).
또는 잘못된 응답으로 간주되는 항목을 대신 정의할 수 있습니다.
bad response
은 잘못된 출력을 제공하는 것으로 간주되는 응답입니다(예: 서비스가 서버 오류로 응답하여 클라이언트 흐름이 실패하게 됨). 뉴렐릭은 자동으로 좋은 응답 수를 valid - bad 개로 도출합니다.
요청 기반 SLO는 총 요청 수에 대한 양호한 요청 수의 비율로 정의된 SLI를 기반으로 합니다. 요청 기반 SLO는 해당 비율이 규정 준수 기간의 목표를 충족하거나 초과할 때 충족됩니다.
제안된 SLI
이 섹션에서는 일반적으로 서비스 및 브라우저 응용 프로그램의 성능을 측정하는 데 사용되는 몇 가지 SLI를 찾을 수 있습니다.
New Relic 에이전트로 계측된 APM 서비스 및 주요 트랜잭션을 위한 SLI
Transaction 이벤트를 기반으로 하는 다음 SLI는 요청 기반 서비스에 가장 일반적입니다.
서비스 성공은 모든 요청 수에 대한 성공적인 응답 수의 비율입니다. 이것은 사실상 오류율이지만 예상 오류를 제거하는 등 필터링할 수 있습니다.
Valid events fields
FROMTransaction
WHERE entityGuid ='{entityGuid}'
여기서 {entityGuid} 은 서비스의 GUID입니다.
Bad events fields
FROM TransactionError
WHERE entityGuid ='{entityGuid}'AND error.expected !=true
여기서 {entityGuid} 은 서비스의 GUID입니다.
대기 시간 SLI는 좋은 경험으로 설정된 임계값보다 빠르게 제공된 유효한 요청의 비율을 측정합니다.
기간 임계값을 결정하려면 지난 몇 주 동안 서비스가 어떻게 수행되었는지 확인하고 그 결과를 현실적이고 달성 가능한 기준으로 사용하십시오. 그런 다음 SLI 임계값을 반복하고 더 야심찬 성능에 맞출 수 있습니다.
기간 조건에 대한 적절한 값을 선택하기 위해 한 가지 일반적인 방법은 지난 7일 또는 15일 동안 응답의 95 백분위수 기간을 선택하는 것입니다. 쿼리 빌더 를 사용하여 이 기간 임계값을 찾고 이를 사용하여 SLI에 좋은 이벤트로 간주되는 이벤트를 결정합니다.
SELECT percentile(duration,95)FROMTransactionWHERE entityGuid ='{entityGuid}' since 7 days ago limit max
Valid events fields
FROMTransaction
WHERE entityGuid ='{entityGuid}'AND transactionType ='Web'
여기서 {entityGuid} 은 서비스의 GUID입니다.
Good events fields
FROMTransaction
WHERE entityGuid ='{entityGuid}'AND transactionType ='Web'AND duration < {duration}
여기서 {entityGuid} 은 서비스의 GUID입니다.
여기서 {duration} 은 클라이언트 서비스 또는 최종 사용자에게 좋은 경험을 제공한다고 생각하는 응답 시간(초)입니다.
OpenTelemetry로 계측된 APM 서비스 및 주요 트랜잭션용 SLI
OpenTelemetry 범위를 기반으로 하는 이러한 SLI는 요청 기반 서비스에 가장 일반적입니다.
서비스 성공은 모든 요청 수에 대한 성공적인 응답 수의 비율입니다. 이것은 사실상 오류율이지만 예상 오류를 제거하는 등 필터링할 수 있습니다.
Valid events fields
FROM Span
WHERE entity.guid ='{entityGuid}'AND(span.kind IN('server','consumer')OR kind IN('server','consumer'))
여기서 {entityGuid} 은 서비스의 GUID입니다.
Bad events fields
FROM Span
WHERE entity.guid ='{entityGuid}'AND(span.kind IN('server','consumer')OR kind IN('server','consumer'))AND otel.status_code ='ERROR'
여기서 {entityGuid} 은 서비스의 GUID입니다.
대기 시간 SLI는 좋은 경험으로 설정된 임계값보다 빠르게 제공된 유효한 요청의 비율을 측정합니다.
기간 임계값을 결정하려면 지난 몇 주 동안 서비스가 어떻게 수행되었는지 확인하고 그 결과를 현실적이고 달성 가능한 기준으로 사용하십시오. 그런 다음 SLI 임계값을 반복하고 더 야심찬 성능에 맞출 수 있습니다.
기간 조건에 대한 적절한 값을 선택하기 위해 한 가지 일반적인 방법은 지난 7일 또는 15일 동안 응답의 95 백분위수 기간을 선택하는 것입니다. 쿼리 빌더 를 사용하여 이 기간 임계값을 찾고 이를 사용하여 SLI에 좋은 이벤트로 간주되는 이벤트를 결정합니다.
SELECT percentile(duration.ms,95)FROM Span WHERE entityGuid ='{entityGuid}'AND(span.kind IN('server','consumer')OR kind IN('server','consumer')) SINCE 7 days ago LIMIT MAX
Valid events fields
FROM Span
WHERE entity.guid ='{entityGuid}'AND(span.kind IN('server','consumer')OR kind IN('server','consumer'))
여기서 {entityGuid} 은 서비스의 GUID입니다.
Good events fields
FROM Span
WHERE entity.guid ='{entityGuid}'AND(span.kind IN('server','consumer')OR kind IN('server','consumer'))AND duration.ms < {duration}
여기서 {entityGuid} 은 서비스의 GUID입니다.
여기서 {duration} 은 클라이언트 서비스 또는 최종 사용자에게 좋은 경험을 제공한다고 생각하는 응답 시간(초)입니다.
측정항목 타임슬라이스 데이터를 사용하는 APM 서비스용 SLI
APM 지표는 타임슬라이스 데이터 로 보고됩니다. SLI에 대한 타임슬라이스 데이터를 활용할 수도 있습니다.
참고: 이 기능은 아직 베타 버전입니다.
서비스 성공은 전체 요청 수에 대한 성공적인 응답 수의 비율입니다. 이는 사실상 오류율입니다.
WHERE appName ='{appName}'AND metricTimesliceName ='Custom/CrossClusterQuery/DataAvailability/status/success'
여기서 {appName} APM 앱 이름입니다.
브라우저 애플리케이션용 SLI
다음 SLI는 Google의 Browser Core Web Vitals를 기반으로 합니다.
오류 없이 제공되는 페이지뷰의 비율입니다.
Valid events fields
FROM PageView
WHERE entityGuid ='{entityGuid}'
여기서 {entityGuid} 은 브라우저 앱 GUID입니다.
Bad events fields
FROM JavaScriptError
WHERE entityGuid ='{entityGuid}'AND firstErrorInSession IStrue
여기서 {entityGuid} 은 브라우저 앱 GUID입니다.
뷰포트에 표시되는 가장 큰 콘텐츠 요소가 좋은 경험에 해당하는 것으로 간주되는 임계값보다 빠르게 렌더링된 유효한 페이지 뷰의 비율입니다.
Valid events fields
FROM PageViewTiming
WHERE entityGuid ='{entityGuid}'AND largestContentfulPaint ISNOTNULL
여기서 {entityGuid} 은 브라우저 앱 GUID입니다.
Good events fields
FROM PageViewTiming
WHERE entityGuid ='{entityGuid}'AND largestContentfulPaint <'{largestContentfulPaint}'
여기서 {entityGuid} 은 브라우저 앱 GUID입니다.
여기서 {largestContentfulPaint} 은 최종 사용자에게 좋은 경험을 제공한다고 생각하는 표시 영역에 표시되는 가장 큰 콘텐츠 요소를 렌더링하는 데 걸리는 시간(밀리초)입니다. 빈번한 표준은 4000ms입니다.
사용자 환경에서 {largestContentfulPaint} 에 사용할 현실적인 숫자를 결정하기 위해 한 가지 일반적인 방법은 지난 7일 또는 15일 동안 응답의 95 백분위수 기간을 선택하는 것입니다. 쿼리 빌더를 사용하여 찾습니다.
SELECT percentile(largestContentfulPaint,95)FROM PageViewTiming WHERE entityGuid ='{entityGuid}' SINCE 7 days ago LIMIT MAX
사용자가 페이지와 처음 상호작용한 시간과 브라우저가 해당 상호작용에 응답한 시간 사이의 시간이 특정 임계값 미만인 페이지 조회수의 비율입니다.
Valid events fields
FROM PageViewTiming
WHERE entityGuid ='{entityGuid}'AND interactionToNextPaint ISNOTNULL
여기서 {entityGuid} 은 브라우저 앱 GUID입니다.
Good events fields
FROM PageViewTiming
WHERE entityGuid ='{entityGuid}'AND interactionToNextPaint < {interactionToNextPaint}
여기서 {entityGuid} 은 브라우저 앱 GUID입니다.
여기서 {interactionToNextPaint} 은 최종 사용자에게 좋은 경험을 제공하기 위해 브라우저가 응답해야 하는 시간(밀리초)입니다. 빈번한 표준은 300ms입니다.
사용자 환경에서 {interactionToNextPaint} 에 사용할 현실적인 숫자를 결정하기 위해 한 가지 일반적인 방법은 지난 7일 또는 15일 동안 응답의 95 백분위수 기간을 선택하는 것입니다. 쿼리 빌더를 사용하여 찾습니다.
SELECT percentile(interactionToNextPaint,95)FROM PageViewTiming WHERE entityGuid ='{entityGuid}' SINCE 7 days ago LIMIT MAX FACET deviceType
CLS(누적 레이아웃 전환)가 좋은 페이지 보기의 비율입니다. CLS는 페이지의 전체 수명 동안 발생하는 모든 예상치 못한 레이아웃 전환에 대한 모든 개별 레이아웃 전환 점수의 총합으로 설명됩니다. 레이아웃 이동은 보이는 요소가 렌더링된 프레임에서 다음 프레임으로 위치를 변경할 때마다 발생합니다.
Valid events fields
FROM PageViewTiming
WHERE entityGuid ='{entityGuid}'AND cumulativeLayoutShift ISNOTNULL
여기서 {entityGuid} 은 브라우저 앱 GUID입니다.
데스크톱 및 모바일 장치에서 별도로 CLS를 추적하기 위해 별도의 SLI를 만들려면 필드 끝에 다음 절 중 하나를 추가합니다.
and deviceType = 'Mobile'
and deviceType = 'Desktop'
Good events fields
FROM PageViewTiming
WHERE entityGuid ='{entityGuid}'AND cumulativeLayoutShift < {cumulativeLayoutShift}
여기서 {entityGuid} 은 브라우저 앱 GUID입니다.
여기서 {cumulativeLayoutShift} 은 사전 설정 값입니다. 좋은 사용자 경험을 제공하려면 사이트의 CLS 점수가 0.1 이하가 되도록 노력해야 합니다. 0.25점 이상의 CLS 점수는 열악한 사용자 경험으로 간주됩니다.
유효한 이벤트 쿼리를 정의할 때 데스크톱 및 모바일 장치에서 별도로 CLS를 추적하기 위해 별도의 SLI를 만들기로 결정한 경우 필드 끝에 다음 절을 추가합니다.
and deviceType = 'Mobile'
and deviceType = 'Desktop'
환경에서 {cumulativeLayoutShift} 에 대해 선택할 현실적인 숫자를 결정하기 위해 일반적인 방법 중 하나는 모바일 및 데스크톱 기기에 걸쳐 분류된 지난 7일 또는 15일 동안 페이지 로드의 75번째 백분위수를 선택하는 것입니다. 쿼리 빌더를 사용하여 찾습니다.
SELECT percentile(cumulativeLayoutShift,95)FROM PageViewTiming WHERE entityGuid ='{entityGuid}' since 7 days ago limit max facet deviceType
합성 검사용 SLI
성공은 모든 검사 수에 대한 성공적인 종합 검사 수의 비율입니다.
Valid events fields
FROM SyntheticCheck
WHERE entity.guid ='{entityGuid}'
여기서 {entityGuid} 합성 검사의 GUID입니다.
Good events fields
FROM SyntheticCheck
WHERE entity.guid ='{entityGuid}'AND result='SUCCESS'
으)로 이동합니다. 워크로드를 포함하여 계정 전반에 걸쳐 SLI를 모든 구성원과 연결할 수 있습니다.
서비스, 주요 프로세서, 라이브러리 또는 신세틱스 모니터의
Service levels
페이지에서. SLI는 해당 특정 파티션과 연결됩니다. 이 시작점을 사용하면 뉴렐릭은 사용 가능한 최신 데이터를 기반으로 이 유형에 대한 가장 일반적인 전문 서비스 지표를 자동으로 생성합니다.
모든 워크로드의
Service levels
탭에서. SLI를 워크로드의 모든 부분 또는 전체 워크로드와 연결할 수 있습니다.
SLI를 생성한 후 데이터가 바로 표시되지 않습니다. 첫 번째 SLI 달성 결과를 보려면 몇 분 정도 기다려야 합니다. 데이터는 기본적으로 13개월 보존됩니다.
서비스 수준은 단일 계정에만 연결할 수 있습니다. 이에 대한 자세한 내용 은 요구 사항 을 참조하십시오.
서비스 수준을 만들려면 다음 단계를 따르세요.
새 SLI를 정의하려면 다음 세 가지 옵션 중 하나를 선택하십시오.
Entity data
: 에이전트 또는 사용자 정의 대시보드에서 제공되는 표준 데이터를 기반으로 SLI를 기반으로 합니다. 이것이 가장 일반적인 옵션입니다. 이를 선택한 경우 사용하려는 부분(예: APM 서비스)을 선택하세요.
Custom data
: 또는 사용자 정의 NRDB 이벤트 또는 차원 지수를 기반으로 SLI를 기반으로 할 수 있습니다. 서비스 범위 데이터를 특정 부분에 연결할 수 없거나 서비스 범위 데이터를 워크로드에 직접 연결하려는 경우 이 옵션을 사용하세요.
Metric data
: Prometheus, OTel 또는 사용자 정의 차원 지수에서 가져온 데이터를 기반으로 합니다.
이 단계에서는 어떤 이벤트가 유효한지, 좋은지 나쁜지를 결정하는 SLI 쿼리를 구성합니다.
SLI를 APM 서비스 또는 브라우저 앱과 연결하면 New Relic은 몇 가지 일반적인 SLI 및 해당 쿼리를 제안합니다. 최신 데이터를 서비스 수준 목표의 기준으로 사용하며 나중에 SLI 및 SLO를 편집할 수 있습니다.
다른 유형의 엔터티를 사용하거나 차원 메트릭을 쿼리하거나 New Relic에서 제공하는 기준 값을 사용자 지정하려는 경우 필요에 맞게 SLI를 사용자 지정할 수 있습니다. 예를 들어 WHERE 절을 사용하여 상태 확인을 필터링할 수 있습니다. 각 쿼리에 다른 이벤트 유형을 사용할 수도 있습니다. 이 경우 각 유효한 이벤트가 양호 또는 불량 쿼리에 대한 하나 이하의 이벤트에만 해당하는지 확인하십시오.
데이터가 수집된 계정은 SLI가 참조하는 엔터티의 계정과 일치합니다. 각 필드에 무엇이 들어가는지 알아보려면 위의 섹션을 참조하십시오.
오른쪽에는 최종 쿼리가 표시되고 맨 아래에는 지난 며칠 동안 유효하고 좋은/나쁜 이벤트의 수에 대한 미리보기가 표시됩니다.
다음은 차원 메트릭에 대한 백분율 기반 성공률의 예입니다. 이를 SLI에 대한 유효/양호 이벤트로 변환해 보겠습니다.
FROM Metric
SELECT percentage(sum(scrooge_do_expire_count),
WHEREstatus='success')AS'Success Rate'
WHERE env='production'
ANDstatus!='attempt'
유효한 쿼리의 경우 외부 WHERE 절을 복사하면 됩니다.
FROM Metric
SELECTsum(scrooge_do_expire_count))
WHERE env='production'
ANDstatus!='attempt'
좋은 이벤트는 백분율 함수의 외부 WHERE 절과 WHERE 절이지만:
FROM Metric
SELECTsum(scrooge_do_expire_count))
WHERE env='production'
ANDstatus!='attempt'
ANDstatus='success'
현재 지원되는 네 가지 집계 함수는 count(), sum(), getField() 및 getCdfCount() 입니다. Count 및 sum 는 모든 이벤트 유형에 사용할 수 있는 반면, getField 및 getCdfCount 는 Metric 에서 선택할 때만 사용할 수 있습니다.
유효/양호/불량 이벤트의 수를 계산하려면 이벤트 데이터와 함께 count() 함수를 사용하세요.
sum() 함수는 이벤트 데이터 또는 측정기준 측정항목에 미리 집계된 카운터가 있는 경우에 유용합니다. 합계에 사용할 속성인 매개변수가 필요합니다.
getField() 및 getCdfCount() 함수를 사용하여 분포 측정항목 속성이 임계값 미만 또는 임계값에 도달하는 빈도를 확인합니다. 두 함수 모두 속성이 필요하고 getCdfCount()도 값을 측정하기 위한 임계값이 필요합니다.
count() 사용 예:
FROM JavaScriptError
SELECTcount(*)
WHERE entityGuid ='{entityGuid}'AND firstErrorInSession IStrue
sum() 사용 예:
FROM ServerlessSample
SELECTsum(provider.errors.Sum)
WHERE awsAccountId ='XXX'And provider LIKE'LambdaFunction%'