고품질 프로덕션 환경을 유지하기 위해 할 수 있는 가장 중요한 일 중 하나는 열악한 사용자 경험을 감지하고 해결하는 데 필요한 웹 원격 측정을 확보하는 것입니다. 이 가이드에서는 브라우저 모니터링을 최적화하는 데 필요한 데이터를 얻고 있는지 확인합니다. 우리는 귀하가 다음을 수행할 수 있도록 도와드립니다:
수집하는 데이터에서 최대한의 가치 얻기
보고된 데이터를 사용하여 서비스를 최적화할 수 있는 기회 확인
문제를 신속하게 분류하고 해결할 수 있습니다.
실시간 비즈니스 KPI 대시보드를 만드는 데 필요한 데이터 얻기
Step 1 of 7
브라우저 애플리케이션 이름 지정 및 하위 계정 배치 조정
먼저, 브라우저 이름 지정 및 데이터 구성이 올바른지 확인해야 합니다. 필요한 경우 이름 바꾸기 가이드 에 따라 브라우저 애플리케이션의 이름을 변경할 수 있습니다. 하나의 브라우저 애플리케이션에 보고하는 여러 환경의 데이터가 있는 경우 새 브라우저 앱을 만들고 페이지의 JavaScript 스니펫을 업데이트하여 올바른 앱을 보고할 수 있습니다.
브라우저 모니터링 조직을 확인할 때 다음 사항에 유의하세요.
다양한 환경(dev/qa/production)의 웹 애플리케이션 계측은 다양한 브라우저 애플리케이션에 보고되어야 합니다.
브라우저 애플리케이션이 지원하는 환경(예: 개발, QA, 프로덕션 환경)
브라우저 애플리케이션의 목적(고객용, 내부용, 웹사이트, 웹사이트 구성 요소, 지역 등).
Step 2 of 7
JavaScript 오류 조정
다음으로 페이지 로드 프로세스를 방해하고 오류를 표시하며 사용자가 작업을 완료하지 못하게 함으로써 사용자 경험과 SEO에 부정적인 영향을 미치는 JavaScript 오류를 해결해야 합니다. 먼저, UI 또는 NRQL을 사용하여 JavaScript 오류가 캡처되고 있는지 확인하세요.
Browser [브라우저] 에서 웹 애플리케이션을 엽니다. 왼쪽 메뉴에서 Errors [오류] 보기를 열고 JavaScript 오류가 표시되는지 확인하세요. 애플리케이션의 트래픽이 많지 않으면 오류를 확인하기 위해 24시간 이상 이전으로 돌아가야 할 수도 있습니다.
다음 쿼리를 실행합니다.
SELECT count(*) FROM JavaScriptError WHERE appName = 'MyApp' SINCE 1 WEEK AGO
0 카운트는 캡처된 JavaScript 오류가 없음을 의미합니다.
다음을 실행하면 서브 계정의 모든 웹 애플리케이션을 확인할 수 있습니다.
SELECT count(*) FROM JavaScriptError FACET appName LIMIT MAX SINCE 1 WEEK AGO
결과에 없는 웹 응용 프로그램은 JavaScript 오류를 보고하지 않았습니다.
브라우저 에이전트가 최신인지 확인하세요. 최신 브라우저 버전에서는 어떤 이유로든 이전에 간과되었던 JavaScript 오류를 포착할 수 있습니다.
브라우저 에이전트가 페이지의 <HEAD/> 태그에 있는지 확인하세요. Chrome 개발자 도구를 사용하여 이를 확인할 수 있습니다.
JS Errors [JS 오류] 탭을 통해 여러 오류를 확인하세요. 오류 이벤트 로그 아래에 스택 추적이 나타납니다.
다음 쿼리를 실행합니다.
SELECT count(*) FROM JavaScriptError WHERE appName = 'MyApp' AND stackTrace IS NOT NULL AND stackTrace NOT LIKE '' SINCE 1 WEEK AGO
0 카운트는 캡처된 JavaScript 오류가 없음을 의미합니다.
다음을 실행하면 서브 계정의 모든 웹 애플리케이션을 확인할 수 있습니다.
SELECT count(*) FROM JavaScriptError WHERE stackTrace IS NOT NULL AND stackTrace NOT LIKE '' FACET appName LIMIT MAX SINCE 1 WEEK AGO
결과에 없는 웹 애플리케이션에는 스택 추적에 JavaScript 오류가 없습니다.
누락된 스택 추적 문제를 해결하려면 다음 지침을 따르세요. 또는 스택 트랙이 표시되지만 확장할 수 없는 경우 다음 지침을 따르세요.
Step 3 of 7
페이지 보기 그룹화 확인
다음으로 페이지 보기 그룹화를 확인하세요. Page views [페이지 보기] UI의 페이지 URL은 페이지 성능을 더 잘 관리하는 데 도움이 되도록 자동으로 그룹화됩니다. 자동 그룹화를 결정하는 알고리즘은 웹앱이 처음으로 계측될 때 실행됩니다. 현재 웹 트래픽이 앱이 처음 계측되었을 때와 많이 다르다면 표시되는 그룹이 너무 적은 것일 수 있습니다.
왼쪽 메뉴에서 선택하여 앱의 Page views [페이지 보기] UI를 확인하세요. 보이는 내용이 아래 스크린샷과 많이 일치하는 경우 메모를 작성하고 문제 해결 방법에 대한 이 가이드의 지침을 따르세요.
다음 쿼리를 실행합니다.
SELECT count(*) from PageView WHERE appName = 'MyApp' AND browserTransactionName LIKE '*.*.*%/%' or browserTransactionName LIKE '%.%.%/*/*/*/%' or browserTransactionName LIKE '%.%.%/*/*/*' or browserTransactionName LIKE '%.%.%/*/*/%' FACET pageUrl limit 100 SINCE 1 WEEK AGO
결과는 앱에 대해 과도하게 그룹화된 페이지 URL을 보여줍니다.
다음을 실행하면 서브 계정의 모든 웹 애플리케이션을 확인할 수 있습니다.
SELECT count(*) from PageView WHERE browserTransactionName LIKE '*.*.*%/%' or browserTransactionName LIKE '%.%.%/*/*/*/%' or browserTransactionName LIKE '%.%.%/*/*/*' or browserTransactionName LIKE '%.%.%/*/*/%' FACET browserTransactionName, pageUrl limit 100 SINCE 1 WEEK AGO
페이지 조회수를 확인한 후 AJAX 호출 그룹화에 대해서도 동일한 작업을 수행해야 합니다. AJAX 호출은 대규모로 더 쉽게 탐색할 수 있도록 그룹화됩니다. 때로는 AJAX 호출이 너무 많아서 개별 요청 URL로 탐색하는 것이 어려워지는 경우도 있습니다. UI 또는 NRQL 쿼리를 사용하여 AJAX 그룹화를 조정해야 하는지 확인하세요.
왼쪽 메뉴에서 앱을 선택하고 groupedRequestUrl 별로 그룹화하여 앱의 AJAX 그룹화를 확인하세요. 보이는 내용이 아래 스크린샷과 많이 일치하는 경우 메모를 작성하고 문제 해결 방법에 대한 이 가이드의 지침을 따르세요.
다음 쿼리를 실행합니다.
SELECT count(*) FROM JavaScriptError WHERE appName = _your app name_ AND stackTrace IS NOT NULL AND stackTrace NOT LIKE '' SINCE 1 WEEK AGO
0 카운트는 캡처된 JavaScript 오류가 없음을 의미합니다.
다음을 실행하면 서브 계정의 모든 웹 애플리케이션을 확인할 수 있습니다.
SELECT count(*) FROM JavaScriptError WHERE stackTrace IS NOT NULL AND stackTrace NOT LIKE '' FACET appName LIMIT MAX SINCE 1 WEEK AGO
다음으로 브라우저에서 분산 추적을 활성화하면 백엔드에 대한 요청을 최종 엔드포인트까지 추적하여 AJAX 성능을 향상하는 데 도움이 됩니다. 추적 정보는 어떤 애플리케이션이 사용자 경험에 영향을 미치는지 이해하는 데 유용합니다. 이 정보를 사용하여 서비스 문제를 직접 해결하거나 담당 팀에 위임할 수 있습니다.
Step 6 of 7
배포 설정
다음으로, NerdGraph를 사용하여 웹 애플리케이션의 변경 사항을 추적 하면 성능 KPI, 전환 및 사용자 참여에 대한 변경 사항의 영향을 확인할 수 있습니다.
Step 7 of 7
사용자 정의 속성 추가
사용자 정의 속성을 사용하여 데이터를 필터링하고 그룹화합니다. 사용자 정의 속성은 선택 사항이지만 이를 사용하면 많은 가치를 얻을 수 있습니다. 다음은 가장 일반적으로 권장되는 속성이지만 더 추가하고 싶을 수도 있습니다.
식별 가능한 사용자가 있는 모든 사이트에 권장됩니다. 오류의 영향을 받는 사용자 수를 식별하고 어떤 사용자인지 알 수 있도록 오류 수신함 문서에 설명된 규칙을 따르십시오.
특정 고객의 경험을 측정하여 SLA를 충족하거나 지원 요청을 분석합니다.
소매업체를 위한 추가 맞춤 속성
전환 수익을 실시간으로 추적합니다. 결제 중 장바구니 포기 또는 문제의 영향을 측정합니다.
실시간으로 구매한 항목을 추적합니다. 결제 중 장바구니 포기 또는 문제의 영향을 측정합니다.
광고 캠페인 또는 프로모션의 결과로 얼마나 많은 사용자가 귀하의 사이트를 방문하는지 파악하십시오. 프로모션이 전환에 미치는 영향을 측정합니다.
클릭 투 콜렉트 성능에 대한 정보를 수집하기 위해 상점을 캡처하십시오. 매장 내 쇼핑 웹 애플리케이션의 성능을 측정합니다.
제품 ID가 페이지 URL에 아직 캡처되지 않은 경우 유용합니다. 이 정보를 사용하여 실적이 좋지 않은 제품 페이지를 알아보세요. 가장 많은 트래픽을 받는 제품 페이지와 가장 적은 트래픽을 받는 제품 페이지를 파악하세요.
가치 실현
서비스 모니터링 프로세스와 마찬가지로, 관찰 가능성 프로그램은 노력에 대한 투자에 대한 기대치를 비판적으로 생각하는 전담 팀 기능을 통해 이점을 얻을 수 있습니다. 다음 섹션에서는 관찰 가능성 실행에 웹 계측을 통합하여 예상해야 하는 비용과 이점을 추정하기 위한 접근 방식을 간략하게 설명합니다.
투자
모든 개발자가 New Relic 에이전트 SDK 및 플랫폼 기능에 익숙해야 합니다.
비용 모델: 회사의 개발자 FTE 모델 및 프로젝트 견적에 따라 다릅니다.
예상: 일반적으로 개발자가 New Relic 계측 기능을 사용하여 효과를 얻는 데 몇 시간이 걸립니다.
초기: 16시간 교육/탐색
반복: 4시간/Q 검토
핵심 기술을 개발하고 New Relic 플랫폼을 위한 기술 통화를 유지하기 위해 개발자당 연간 16-40시간 교육 투자
프로젝트 내에서 계측을 구현하고 유지하는 데 필요한 개발 노력입니다.
비용 모델: 회사의 개발자 FTE 모델 및 프로젝트 견적에 따라 다릅니다.
추정: 이것은 프로젝트의 범위와 필요한 계측 작업의 양에 따라 달라지는 경향이 있습니다.
초기: 서비스당 개발자당 8시간
반복: 4시간/Q 유지 관리
개발자당 웹 계측 개발 및 유지 관리에 16-32시간이 소요되는 프로젝트 추정
혜택
경고 품질 에 관한 당사의 문서는 다양한 시스템 성능으로 인한 경고 알림이 신속하게 처리되도록 보장함으로써 운영 팀에 상당한 이점을 제공합니다. 이를 통해 사고 해결 중 전달 및 리소스 할당이 향상됩니다.
관찰 가능성 프로그램에 통합된 효과적인 계측 방식은 의미 있는 경고를 생성하는 팀의 능력을 크게 향상시킵니다.
KPI:
볼륨: 사건 수
볼륨: 누적 사고 기간
거래량: MTTC(평균 마감 시간)
사용자 참여: 평균 조사 시간
결과:
경고 소음 감소
경보 및 사고 대응성 향상
덜 알려지지 않은 근본 원인
운영 생산성 향상
향상된 서비스 제공
웹 품질을 개선하면 서비스의 주요 재무 지표에 직접적인 영향을 미칩니다. 이를 위해서는 귀하의 지원에 대해 잘 합리화된 재무 모델이 필요합니다. 일반적으로 이 수익은 오류나 apdex 달성과 같은 핵심 웹 품질 측정에 대한 각 백분율 개선에 대한 통화 가치를 연결하여 예측할 수 있습니다.
서비스 계측에 대한 투자가 증가함에 따라 서비스 품질 측정에 대한 달성도가 향상되어야 합니다.
KPI: 서비스 품질(비즈니스 KPI)
결과:
오류에 영향을 미치는 사용자 수 감소
더 강력하고 탄력적인 서비스 구성 요소
웹 서비스 인스턴스에서 더 나은 원격 측정을 제공함으로써 제공 조직은 변동성 또는 가동 중지 시간을 보다 신속하게 감지하고 더 빠르게 해결할 수 있어야 합니다. 이를 통해 전반적인 서비스 제공 KPI가 향상되고 서비스 중단이나 성능 저하가 줄어듭니다.
비용은 사고를 탐지, 조사 및 해결하는 데 걸리는 시간과 관련될 수 있습니다. 이는 이벤트 중에 손실을 입게 되는 웹 서비스가 조직에 제공하는 가치와 관련이 있을 수도 있고 잘못된 행동을 처리하는 데 드는 일반적인 비용과 관련될 수도 있습니다.