오류가 발생하기 마련입니다. 관측 가능성 도구를 사용하더라도 오류의 원인을 찾는 것은 생각만큼 간단하지 않습니다. 침수된 마당을 생각해 보십시오. 호스 근처에서 물이 흐르는 것을 보았지만 홍수의 원인은 실제로 수도 본관 어딘가의 균열입니다. 새는 호스가 홍수를 일으켰다고 가정하면 호스는 고정되어 있지만 잔디밭은 망가지고 말 것입니다. 비용이 많이 드는 실수입니다.
오류 분석을 통해 문제의 원인을 찾아 홍수가 발생하기 전에 문제를 해결할 수 있습니다. 팀이 새 배포를 수행하거나 서비스가 업스트림에 실패하면 솔루션을 구현하기 전에 더 깊이 파고들어야 합니다. 오류 분석에는 가정의 여지가 없습니다.
목표
이 튜토리얼 시리즈는 심각한 오류를 해결하는 방법을 보여주고 전체 오류 수를 줄이는 방법을 안내합니다. 이 문서에서는 다음 방법을 포함하여 오류 받은 편지함 기능을 탐색하는 방법을 다룹니다.
- 오류 분석을 시작하려면 서비스를 선택하세요.
- 중단을 나타내는 오류 그룹을 선택하세요.
전제 조건
애플리케이션 성능을 모니터링하려면 앱 언어용으로 특별히 생성된 에이전트를 사용합니다. 로고를 클릭하면 에이전트 설치 및 구성 과정을 안내하는 New Relic UI의 설치 안내 프로그램으로 이동됩니다.
에이전트를 설치한 후 one.newrelic.com 으로 이동하여 앱을 선택하세요. 아직 많은 데이터가 표시되지 않으면 잠시 물러나 애플리케이션이 실행될 때 에이전트가 실시간 데이터를 수집하도록 하세요. 또한 이 튜토리얼에서는 귀하가 아직 첫 번째 공지를 작성하지 않았더라도 에 어느 정도 익숙하다고 가정합니다.
애플리케이션의 오류 감지 및 추적
이제 앱이 계측되었으므로 New Relic이 서비스에 대한 데이터를 캡처합니다. 여기에는 앱의 오류 발생에 대한 데이터가 포함됩니다.
최종 사용자에 대해 생각
경고는 문제가 있음을 알려줍니다. 문제는 잔디밭의 물입니다. 그러나 알림이 모든 컨텍스트를 제공하지는 않습니다. 오류 받은 편지함이 들어오는 곳입니다.
전자 상거래 사이트의 일부 앱을 담당하고 있다고 상상해 보십시오. 두 구성 요소에 대해 두 개의 알림을 받았습니다. 하나는 체크 아웃용이고 다른 하나는 인벤토리 검색용입니다. 최종 사용자에 대한 검색 기능이 실패했다는 보고만 받고 있지만 체크아웃 구성요소는 제대로 작동합니다. 체크아웃 기능이 더 중요하다고 생각할 수 있지만 관찰 가능성 관행과 신념을 분리하는 것이 중요합니다.
이 관행은 최종 사용자가 아무 것도 보고하지 않은 경우에도 적용됩니다. 서비스 실패를 발견하면 스스로에게 다음과 같은 질문을 할 수 있습니다.
- 최종 사용자에게 문제가 있습니까?
- 그들의 경험은 어떻게 보여야 합니까?
- 현재 어떤 행동을 경험하고 있습니까?
오류를 보고하는 서비스 확인
이것이 실제로 어떻게 보일 수 있는지 살펴보겠습니다. All entities 페이지를 보면 4개의 서비스가 경고하고 있는 것을 알 수 있습니다.
1단계에서 스스로에게 질문을 해보면 다음과 같은 사실을 알 수 있습니다.
최종 사용자가 구매 작업에 어려움을 겪고 있습니다.
사이트에는 재고가 있는 항목만 표시되어야 합니다.
귀하의 사이트는 모든 제품을 표시하므로 고객은 재고가 없는 품목을 구매할 수 있습니다.
귀하는
api-gateway귀하의 인벤토리에 대한 중요한 종속성임을 확인했습니다. 여기에서 오류 분석을 시작합니다.
변경된 항목 찾기
시스템에 대한 진입점이 있으므로 이제 앱에 영향을 미치는 오류를 조사할 수 있습니다. api-gateway 요약 페이지에서 Triage 아래의 Errors 탭을 클릭합니다. 오류 페이지에서는 데이터를 오류 전용 보기로 필터링합니다.
api-gateway 에 보고되는 오류 그룹이 6개 이상 있습니다. 오류 그룹은 앱에서 수십 번에서 수천 번까지 나타납니다.
처음에는 세분성이 부족한 것처럼 보이지만 시계열은 시간이 지남에 따라 변경된 사항을 가리키는 데 충분한 정보를 제공합니다. 우리는 이것을 분해할 것입니다:
- 발생 횟수만 기준으로 4,000번 발생하므로 첫 번째 직감이
ActivemModel:::ValidationError부터 시작하라고 알려줄 수 있습니다. 하지만 시계열을 보면 고점과 저점이 상대적으로 일정합니다. 이는 예상된 오류일 수 있지만 나머지 5개를 살펴보겠습니다. Net::OpenTimeOut오류 그룹은 유사한 패턴을 가지며 실제로 6개의 보고 그룹 중 4개를 구성합니다. 각 오류 그룹에서 사고 이전에 확장되는 일관된 최고점과 최저점을 볼 수 있습니다. 동일한 이름과 유사한 패턴으로 이 역시 예상되는 오류임을 유추할 수 있습니다.- 마지막 옵션은
JsonapiClient:::Notfound입니다.ActivemModel:::ValidationError과 마찬가지로 뚜렷한 모양을 가지며 지속적으로 보고합니다. 발생 횟수가 많지는 않지만 시계열은 좀 더 깊이 파고들 가치가 있을 만큼 변칙적입니다.
시계열 조정
확실하게 하려면 지난 12시간 동안의 패턴을 표시하도록 시간 매개변수를 조정합니다.
조정을 통해 ActivemModel:::ValidationError의 최고점과 최저점 패턴이 변하지 않지만 지난 한 시간 동안 JsonapiClient:::Notfound 급격히 증가한 것을 확인할 수 있습니다. 이것은 좋은 출발점입니다.
어떤 일이 언제 발생했는지 아는 것은 소스에 더 가까이 다가가기 위한 중요한 부분입니다. 문제 공간을 완전히 이해했다면 이제 소스를 파헤칠 수 있습니다.