시간이 부족할 때 우리의 도구는 인시던트 문제를 해결하는 데 도움이 될 수 있습니다. APM 요약 페이지를 사용하면 앱의 잠재적인 오류에 대한 개요를 확인하고 각 서비스에 대한 중요한 지표를 얻을 수 있습니다. 서비스 상태를 확인하고, 더 큰 맥락에서 문제를 이해하고, 문제 해결을 위해 필요한 조치를 취하기 위해 가장 먼저 방문하게 되는 곳입니다.
이 문서는 **뉴렐릭의 APM 도구를 사용하여 서비스 저하의 근본 원인을 파악하는 방법에 대한 가상의 예를 안내합니다. 당신은 신발을 판매하는 가상의 전자상거래 회사에서 일하는 상황을 탐색하게 됩니다. 당신은 결제팀의 엔지니어링 관리자입니다. 고객들은 체크아웃하는 데 너무 오래 기다려야 한다고 불평해 왔습니다.
고객이 장바구니에 신발 한 켤레를 넣고 계산할 시간이라고 결정하면 Pay Now 버튼을 누르게 됩니다. Checkout-service 은 Pay Now 버튼의 기능을 관리하는 엔티티입니다.
고객이 Pay Now 버튼을 클릭할 수 없는 이유를 알아보려면 APM을 열고 Checkout-service) 선택하십시오.
요약 타일로 문제점 식별
구체적인 내용을 살펴보기 전에 먼저 페이지 상단의 요약 타일을 살펴보는 것이 중요합니다. 이러한 타일은 시스템의 모든 문제, 취약성 또는 배포 실패를 즉시 알려줍니다. 페이지 상단의 타일이 빈 상태로 표시되면 Set up now 클릭하여 각 타일을 활성화합니다.
문제
시스템에서 비정상적인 동작을 추적하는 중요한 방법은 경고를 이용하는 것입니다. Checkout-service 의 트랜잭션 오류율이 10%를 초과하는 시기를 알고 싶다고 가정해 보겠습니다. 알림 조건을 생성하고 인시던트를 트리거할 규칙을 설정합니다. 하나 이상의 사건으로 인해 문제가 발생합니다. 이 타일은 서비스의 모든 문제를 표시합니다.
이 예에서는 경고 조건을 이미 설정했으므로 요약 타일을 스캔할 때 시스템에 두 가지 중요한 문제가 있음을 즉시 확인할 수 있습니다. 각 중요한 문제, 포함된 인시던트 및 관련 엔터티에 대한 세부 정보를 보려면 타일을 클릭하십시오.
마지막 배포
배포 마커는 서비스에 대한 모든 업데이트의 결과를 모니터링하는 데 도움이 됩니다. 이 타일은 마지막 배포에 의해 트리거된 오류율 및 응답 시간의 변화를 보여줍니다.
배포 후 15분부터 이 타일에는 배포 전과 후에 수집된 데이터 간의 비교가 표시됩니다. 45분 전에 새 기능을 활성화한 경우 이 타일은 45분 전과 45분 후를 비교하여 표시합니다. 배포 후 처음 3시간 동안 이 타일은 활성화 전 해당 시간과 일치한 활성화 이후 경과된 시간의 비교만 표시합니다. 3시간 후 타일은 표준 3시간 비교를 사용합니다.
사용자 지정 시간 범위의 경우 타일을 클릭하여 기본 배포 페이지로 이동하고 거기에서 시간 선택기를 사용합니다.
이 예의 경우 마지막 배포 에서 오류율이 27% 급증하고 응답 시간이 5% 증가했습니다. 타일을 클릭하여 마지막 배포 및 관련 오류, 로그, 경고 및 추세를 확인합니다.
서비스 수준
서비스 수준은 최종 사용자의 관점에서 서비스 성능을 측정하는 데 사용됩니다. 서비스 수준의 오류 예산이 초과되면 다음 문제 유형이 표시됩니다.
Non-compliant 이는 이 기간 동안 오류 예산을 모두 소비했음을 의미합니다. 따라서 SL을 개선하기 위해 구현하고 배포하고 일부 작업을 계획해야 하는 경우 주의하세요.
At risk 오류 예산이 거의 소진되었음을 의미하며 나머지 기간 동안에는 더욱 주의해야 합니다.
이 예에서는 이미 서비스 수준을 구성했으며 두 가지 경우에서 오류 예산을 초과했습니다. 타일을 클릭하여 어떤 엔터티가 규정을 준수하지 않는지 확인하고 오류 예산에 대해 자세히 알아보세요.
취약점
취약점 관리는 모든 소프트웨어의 취약점에 대한 조감도를 제공합니다. Java, .Net 또는 Github Defendabot 과 같은 각 통합 에이전트 또는 서비스는 추적할 퍼널을 뉴렐릭에 자동으로 알려줍니다.
여기에서 취약성 관리를 활성화했으며 모니터링되는 서비스에 대해 3개의
Critical및 9개의High취약성이 감지되었음을 확인할 수 있습니다. 취약점 영향을 보려면 타일을 클릭하십시오.
주요 측정항목 검토
Checkout-service에 문제가 있습니까? 어떤 시스템이 어떻게 영향을 받습니까?
Apdex
서비스 고장을 조사할 때 가장 먼저 살펴볼 곳은 Apdex 점수입니다. Apdex 점수는 애플리케이션에 대한 전반적인 고객 만족도를 모니터링합니다. 점수는 응답 시간이나 처리량, 오류율과 같은 성능의 조합을 찾습니다.
Apdex는 웹 애플리케이션/서비스의 응답 시간에 대한 사용자 만족도를 측정하는 업계 표준입니다. 0-1의 점수로 표시됩니다. 점수가 1에 가까울수록 앱의 성능이 더 좋습니다. 만족스러운 경험의 기본값은 0.5초이지만 설정에서 다른 목표를 설정할 수 있습니다.
Apdex 점수는 일반적으로 다음 색상으로 나뉩니다.
** < 0.5 - Gray:** 귀하의 애플리케이션 성능이 매우 심각하며 즉각적인 조치가 필요합니다.
0.5-0.7 - Red: 애플리케이션에 심각한 성능 문제가 있으며 즉각적인 조치가 필요합니다.
0.7-0.85 -Orange: 귀하의 로그는 부정적인 방향으로 추세를 보이고 있으며 추가 조사가 필요합니다.
0.85-0.95 - Blue: 이것이 이상적인 Apdex 범위입니다. 이 점수는 귀하가 귀하의 애플리케이션에 맞게 Apdex T를 완벽하게 미세 조정했으며 성능이 양호하다는 것을 의미합니다.
> 0.95 - Blue: Apdex 점수가 이 범위에 있으면 Apdex T가 너무 높게 설정되어 애플리케이션 성능을 정확하게 읽을 수 없다는 의미입니다. Apdex T를 줄이는 것을 고려해야 합니다.
팁
Apdex 점수가 0이면 요청이 오류와 함께 반환되었기 때문일 수 있습니다. 오류가 있는 모든 요청은 Apdex에서 자동으로 0점을 받습니다.
이 예에서는 APM에서
Checkout-service엔터티를 연 후 Apdex 점수가 떨어지고 0.6에서 맴돌고 있는 것을 볼 수 있습니다. 차트가 빨간색입니다.이제 고객의 불만이 옳다는 것을 확실히 알게 되었습니다. 스택 어딘가에 문제가 있습니다.
점수를 이해하는 방법에 대한 자세한 내용은 Apdex: 사용자 만족도 측정을참조하십시오.
웹 트랜잭션
고객 보고서에 따르면 앱에서
Pay now버튼이 실패한다는 것을 알고 있지만 실제 오류의 원인이 무엇인지 확신할 수 없습니다. Apdex를 확인했는데 사용자 만족도가 낮습니다.다음 단계는 앱의 Web-transactions 조사하여 결제 프로세스의 어느 부분이 중단되는지 파악하는 것입니다.
New Relic에서 트랜잭션은 소프트웨어 애플리케이션에서 하나의 논리적 작업 단위로 정의됩니다. 특히 해당 작업 단위를 구성하는 함수 호출 및 메서드 호출을 나타냅니다. APM의 경우 애플리케이션이 웹 요청을 받을 때부터 응답이 전송될 때까지 발생하는 활동을 나타내는 웹 트랜잭션을 가리키는 경우가 많습니다.
웹 트랜잭션 시간은 세 부분으로 나뉩니다.
파란색 세그먼트: 모든 거래
노란색 세그먼트: 데이터베이스 작업
그린 세그먼트: 외부 서비스
팁
비동기 애플리케이션을 모니터링하려는 경우 응답 시간(진한 파란색 선)이 각 개별 세그먼트(트랜잭션, 데이터베이스 및 외부)에 대한 응답 시간보다 낮을 수 있습니다. 이것은 비동기 애플리케이션이 동시에 여러 요청을 처리할 수 있기 때문에 발생할 수 있습니다. 따라서 일부 요청이 아직 "열려 있는" 동안 트랜잭션이 "종료"될 수 있습니다.
느린 트랜잭션은 무언가가 비정상적으로 작동하고 있다는 강력한 지표가 될 수 있으므로 차트를 살펴보고 서비스 영역에서 응답하는 데 평소보다 오래 걸리는 부분이 있는지 확인하세요. 느린 트랜잭션은 차트에서 스파이크처럼 보입니다.
또한 배포 마커 도구를 사용하여 고객이
Pay Now버튼을 로드하는 데 시간이 오래 걸린다고 불평하기 시작한 시점에 팀에서 변경 사항을 릴리스했는지 확인할 수 있습니다.배포 마커는 각 차트에서 회색 핀으로 표시됩니다. 개요 정보를 보려면 핀 위로 마우스를 가져가거나 마커를 클릭하여 배포를 자세히 살펴볼 수 있습니다.
처리량
Checkout-service에 대한 응답 시간을 보면서 처리량도 조사할 수 있습니다. Throughput 애플리케이션이 처리하는 작업량을 측정하는 방법입니다. 처리량은 작업이 호스트와 컨테이너 간에 균등하게 분배되는지 이해하는 데 도움이 됩니다. 성능 문제는 종종 리소스 부족으로 인한 증상일 수 있습니다.이 예제의 목적상 처리량이 평소보다 약간 높은 것을 볼 수 있습니다. 서비스 저하 기간 동안 처리량이 매우 높으면 애플리케이션이 처리할 수 있는 것보다 더 많은 작업을 처리하고 있음을 나타낼 수 있습니다.
반면에 낮은 처리량은 앱이 많은 요청을 처리하지 못하고 있음을 나타낼 수 있습니다. 이는 단순히 많이 사용되지 않거나 애플리케이션을 호출하는 서비스가 손상되어 요청이 처리되지 않음을 의미할 수 있습니다.
오류
느린 트랜잭션을 식별하고 처리량을 분석했으므로 이제 오류를 살펴볼 차례입니다. Errors 차트에는 오류가 발생한 프로세서의 비율이 표시됩니다.
APM 컨텍스트에서 오류는
TransactionError및ErrorTrace이벤트를 나타냅니다.이 경우 웹 트랜잭션 응답 시간이 급증한 것과 거의 같은 시간에
Web errors에 급증이 나타납니다. 팀에서 시스템을 변경했음을 알리는 배포 마커도 표시됩니다.이제 이 최근 배포를 둘러싼 패턴이 표시됩니다. 즉, 사용자 만족도 감소, 응답 시간 증가, 처리량 및 오류입니다.
영향을 받는 사용자 보기로 전환하려면 드롭다운을 사용하세요. 영향을 받는 사용자를 추적하는 방법은 받은 편지함 오류를참조하세요.
오류를 관리하는 방법에 대한 자세한 내용은 오류 관리를참조하세요.
더 큰 맥락에서 문제 찾기
스택의 어느 부분에 문제가 있습니까? 귀하의 서비스를 호출하거나 귀하의 서비스에 의해 호출되는 엔티티의 변경으로 인해 문제가 발생했습니까?
로그
로그 차트는 컨텍스트 내 로그 기능을 통해 보고된 애플리케이션 로그의 요약 보기를 제공합니다. Logs 클릭하면 전체 로그 UI 로 이동됩니다.
이 예에서는 주요 측정항목을 조사한 후 Web-transaction 시간에 영향을 미쳐 오류가 급증하고 사용자 만족도가 낮은 최근 배포에 문제가 있음을 알게 되었습니다. 이제 이것이 나머지 서비스에 어떤 영향을 미쳤는지 알고 싶습니다.
컨텍스트에 따른 로그를 사용하면 개별 로그에 관련된 엔터티 또는 서비스로 태그가 지정됩니다. 로그 차트에서 Log patterns (top 10) 선택하여 고유 문자열 식별자까지 동일한 로그 그룹을 표시할 수 있습니다.
로그 패턴의 작동 방식에 대한 자세한 내용은 로그 패턴을참조하세요.
분산 추적
Distributed tracing insights 차트는 서비스의 응답 시간, 오류율 또는 처리량을 증가시킬 수 있는 업스트림 및 다운스트림 엔터티를 보여줍니다.
예를 들어, 서비스의 응답 시간 증가를 조사하려고 하는데 스파이크가 외부 호출과 관련되어 있다고 가정해 보겠습니다. 귀하의 서비스에 지연 시간을 초래한 다운스트림 엔터티를 기록했다면 이 목록에서 성능의 변화를 볼 수 있습니다. 성능 변화를 보여주는 반전 트레이스를 보려면 View trace 버튼을 클릭하세요.
분산 추적 통찰력 문서 에서 자세히 알아볼 수 있습니다.
하부 구조
이제 APM 요약 페이지의 Infrastructure 섹션까지 아래로 스크롤합니다. 여기서는 Checkout Service 애플리케이션에 연결된 각 호스트와 해당 호스트의 응답 시간, 처리량, 오류율, CPU 비율에 대한 기록을 나열하는 표를 볼 수 있습니다. 그리고 메모리 비율.
이 예의 경우 응답 시간 증가와 높은 오류율을 초래한 동일한 최근 배포 주변의 CPU 비율에 변경 사항이 있는지 확인하는 것이 좋습니다.
APM 요약 페이지 에서인프라 데이터를 조사하는 방법에 대해 자세히 알아보세요.