APM 모범 사례 가이드

Application monitoring tips you need to know

APM을 어떻게 사용하는지 아는 것과 뉴렐릭의 애플리케이션 성능 모니터링 소프트웨어를 잘 사용하는 방법을 아는 것은 또 다른 문제입니다. 다음은 귀하가 APM전문가이자 팀의 핵심 자산이 되는 데 도움이 되도록 고안된 몇 가지 모범 사례입니다.

성능 문제 해결에 대한 단계별 자습서를 원하십니까? my app is slow 튜토리얼을확인하십시오.

1. 애플리케이션 이름 표준화

New Relic 구성 파일에 지정하지 않은 경우 대부분의 New Relic 에이전트는 "My Application" 또는 "PHP Application"과 같은 기본 애플리케이션 이름을 제공합니다. 20개의 동일한 이름의 애플리케이션으로 끝나는 것을 원하지 않습니다. 앱을 배포하는 즉시 앱에 대한 설명 식별자를 선택해야 합니다.

일관성을 유지하고 탐색하기 쉽도록 New Relic은 애플리케이션 이름을 표준화할 것을 권장합니다(예: Staging의 모든 앱은 이름 끝에 [Staging] 등을 추가). 이상적으로는 새 Java 애플리케이션의 이름이 자동으로 지정되어 오타 및 잘못된 이름 지정 가능성을 줄이는 것이 좋습니다.

그것을하는 방법

Java 애플리케이션의 경우 자동 애플리케이션 이름 지정은 다음 소스에서 가져올 수 있습니다.

• 요청 속성
• 서블릿 초기화 매개변수
• 필터 초기화 매개변수
• 웹 앱 컨텍스트 매개변수
• 웹 앱 컨텍스트 이름(표시 이름)
• 웹 앱 컨텍스트 경로

필요에 가장 적합한 방법을 선택하고 다음 단계 를 따르십시오.

Java가 아닌 응용 프로그램의 경우 자동 이름 지정 방법이 없으므로 APM 에이전트 설명서를 참조하십시오.

2. 애플리케이션에 태그 추가

여러 다른 애플리케이션이 동일한 계정을 사용하고 각 애플리케이션이 여러 환경(예: 개발, 테스트, 사전 프로덕션, 프로덕션)에 걸쳐 있는 경우 개요 대시보드에서 특정 애플리케이션을 찾기 어려울 수 있습니다. 그렇기 때문에 논리적 그룹으로 분류할 수 있도록 앱에 태그를 추가하는 것이 좋습니다.

성숙한 APM 고객이 사용하는 가장 일반적인 두 가지 태그는 애플리케이션 이름과 환경입니다. 따라서 예를 들어 테스트에서 결제 애플리케이션을 보려면 "결제 앱"(이름 태그) 및 "테스트"(환경 태그)로 필터링하면 됩니다.

APM은 앱이 의미 있는 태그 범주의 무제한 수로 롤업할 수 있도록 설계되었습니다.

그것을하는 방법

1. 태그에 대해 알아보세요.
2. 태그를 추가하는 방법을 알아보세요.
3. 태그 쿼리 방법을 알아보세요.

3. 경고 정책 생성 및 평가

핵심 성과 지표가 급증하거나 하락하면 조직의 개인과 팀에 알려야 합니다. Alerting in New Relic 은 최종 사용자에게 영향을 미치기 전에 문제를 감지할 수 있는 동적 이상 현상을 포함하는 도구 세트를 제공합니다.

경고 정책은 두 가지 기본 방법으로 설정할 수 있습니다.

• Static threshold alerts

  애플리케이션의 특성을 이미 알고 있고 애플리케이션의 정상적인 동작이 곧 바뀔 가능성이 없을 때 유용합니다. Apdex 점수, 응답 시간, 오류율, 처리량은 정적 노브 값 중 일부이며, 공지 사항을 생성할 수 있습니다.

• Dynamic anomaly alerts

  다양한 계절 패턴과 성장 추세가 있는 동적 공지 값, 릴레이를 쉽게 결정하고 설정할 수 있습니다(이로 인해 정상적인 동작을 정의하는 레버 값을 설정하기가 어렵습니다). 이러한

  알림

  귀하의 역사적 지표 데이터를 바탕으로 모델링된 이상법을 사용합니다.

각 경고 정책에는 필요한 만큼의 조건이 포함될 수 있으며 각 경고 조건에는 다음 세 가지 구성 요소가 포함됩니다.

• 조건 유형(메트릭, 외부 서비스 등)

• 엔터티는 해당 정책이, 목표(예: APM 앱,

  브라우저 모니터링

  앱 또는 호스트)

• 심각도가 높아짐에 따라 경고 상황으로 확대되는 임계값

알림을 설정했으면 실행 가능한 모든 알림 채널을 활용하고 있는지 확인해야 합니다. 결국 아무도 경고에 대해 알지 못한다면 경고가 무슨 소용이 있겠습니까?

특정 사용자 그룹을 만들고 Slack, PagerDuty, webhook 및 이메일을 포함한 New Relic의 통합 경고 채널을 활용하여 경고를 관리할 수 있습니다. 경고 정책이 항상 유효한지 정기적으로 평가해야 합니다.

그것을하는 방법

자세한 문서를 참조하십시오.

• 동적 이상 경고를 설정하고 애플리케이션을 선택 하려면 표준 절차를 따르십시오 . 예측된 이상과 함께 메트릭의 미리보기가 표시됩니다. 해당 애플리케이션에 대한 메트릭을 선택하고 해당하는 이상을 볼 수 있습니다. 그런 다음 임계값 슬라이더를 사용하여 임계값이 비정상 예측을 얼마나 가깝게 따르기를 원하는지 설정할 수 있습니다.
• Apdex 설정에 대한 정적 임계값 경고를 설정 하려면 표준 절차를 따르십시오 .
• 공지 공지 채널을 설정하려면 표준 절차를 따르세요.

4. 주요 거래 식별 및 설정

애플리케이션의 특성에 따라 일부 트랜잭션은 다른 트랜잭션보다 더 중요할 수 있습니다. New Relic의 주요 트랜잭션 기능은 최종 사용자 또는 앱 응답 시간, 호출 횟수, 오류율 등 앱에서 가장 비즈니스 크리티컬한 트랜잭션으로 간주되는 항목을 면밀히 모니터링할 수 있도록 설계되었습니다. 주요 트랜잭션이 제대로 수행되지 않을 때 알림에 대한 경고 임계값 수준을 설정할 수도 있습니다.

그것을하는 방법

1. one.newrelic.com > All capabilities > Key transactions

   으로 이동한 다음

   Add more

   선택합니다. 그런 다음 앱과 웹 트랜잭션을 선택하거나 선택한 트랜잭션에서

   Track as key transaction

   선택합니다.

2. 주요 프로세서의 이름을 입력하고

   Track key transaction

   선택합니다.

3. 선택 사항: 선택한 앱의 에이전트가 사용자 지정 경고를 지원하는 경우 New Relic이 자동으로 채우는 기본값을 사용하거나 주요 경고 트랜잭션 정책 편집을 선택하여 Apdex 및 경고 임계값을 설정합니다.

4. 삼성전자 콘솔 세부 정보를 보려면

   View new key transaction

   선택하세요.

5. 배포 내역 추적

개발 팀이 가능한 한 자주 새 코드를 푸시할 때 각 배포가 성능에 미치는 영향을 측정하기 어려울 수 있습니다. 이러한 변경 사항이 애플리케이션에 미치는 영향을 파악하는 한 가지 방법은 배포 보고서를 사용하는 것입니다.

이 보고서에는 응답 시간, 처리량 및 오류와 함께 최근 배포 및 최종 사용자 및 앱 서버의 Apdex 점수에 미치는 영향이 나열됩니다. 또한 세부 정보를 보고 드릴다운하여 최근 배포와 관련된 오류를 포착하거나 티켓을 제출하고 팀과 세부 정보를 공유할 수 있습니다.

그것을하는 방법

1. 뉴렐릭 메뉴 표시줄에서

   APM & services > (select an app) > Events > Deployments

   선택합니다.

2. 배포 후 성능을 보려면

   Recent events

   섹션에서 선택한 앱의 개요 대시보드로 이동하세요.

차트의 파란색 세로 막대는 배포를 나타냅니다. 배포에 대한 요약 정보를 보려면 파란색 막대를 가리킵니다.

6. APM 보고서 검토

SLA, 배포 및 용량에서 확장성, 호스트 사용 보고서 등에 이르기까지 APM은 과거 동향을 표시하는 다운로드 가능한 다양한 보고 도구를 제공합니다. 이 모든 것이 고위 경영진이나 고객에게 보고할 수 있는 좋은 방법입니다. 보고서의 전체 목록을 살펴보고 이점을 활용하십시오.

그것을하는 방법

1. APM 메뉴 표시줄에서

   Applications > (select an app) > Reports

   선택합니다.

2. 보고 싶은 보고서를 선택하십시오.

3. 공유할 보고서를 저장하거나 내보내려면

   Download this report as .csv

   선택하세요. 그러면 쉼표로 구분된 값으로 보고서가 생성됩니다.

7. 서비스 맵으로 환경 검토

APM에 포함된 기능인 New Relic 서비스 맵 을 사용하여 아키텍처의 앱과 서비스가 서로 연결하고 통신하는 방식을 이해하십시오. 서비스 맵은 애플리케이션 아키텍처를 시각적으로 사용자 정의할 수 있는 표현 입니다. 지도는 데이터베이스 및 외부 서비스를 포함하여 앱의 연결 및 종속성 을 자동으로 표시합니다. 상태표시기 및 성능 메트릭 은 아키텍처의 모든 부분에 대한 현재 운영 상태를 보여줍니다.

How to do it

1. one.newrelic.com > All capabilities > More > Service maps

   으)로 이동합니다.

2. 시작하려면 서비스 맵 소개 를 참조하십시오.

8. 최신 상태 유지

New Relic의 SaaS 플랫폼을 사용하면 새 기능을 얻는 것이 에이전트를 업데이트하는 것만큼 쉽습니다. 대부분의 조직에는 애플리케이션 업그레이드를 환경에 배포하기 위한 스크립트 세트가 이미 있습니다. 비슷한 방식으로 New Relic 에이전트 배포를 자동화하여 시스템을 최신 상태로 유지할 수도 있습니다. Ansible , Chef 및 Puppet은 전체 배포 및 관리 프로세스를 자동화할 수 있도록 하여 삶을 더 쉽게 만드는 배포 프레임워크의 좋은 예입니다.

그것을하는 방법

업데이트가 필요한 시기를 알 수 있도록 사용 중인 에이전트 버전을 정기적으로 검토하십시오. 최신 에이전트 릴리스에 필요한 수정 사항이나 추가된 기능이 포함되어 있으면 다운로드하십시오.

구현하다, 배포하다 에이전트는 자동으로 (preferred as a method to avoid errors):

1. 배포를 처리하도록 조정할 수 있는 경우 기존 배포 스크립트를 사용합니다.

   또는

   New Relic 에이전트를 구체적으로 배포 및 구성하는 스크립트를 만들고 유지 관리합니다. 이상적으로는 스크립트가 파일의 버전이 지정된 저장소에서 에이전트 파일을 가져옵니다(롤백 목적으로).

2. 스크립트가 생성되면 응용 프로그램을 종료합니다(스크립트가 이를 처리하지 않는 한).

3. 배포 스크립트를 실행합니다.

4. 응용 프로그램을 시작합니다(스크립트가 이를 처리하지 않는 한).

5. 문제가 발생하면 스크립트를 실행하여 이전 버전으로 롤백하십시오.

에이전트를 수동으로 배포하려면:

1. 현재 에이전트 디렉터리를 백업합니다.

2. 업데이트된 에이전트를 기존 에이전트 디렉터리에 배포합니다.

3. 새 파일을 기존 파일과 비교하여 설정 파일을 수정합니다. 특히,

   라이선스 키

   및 맞춤 확장과 같은 항목이 새 설정에 복사되었는지 확인하세요.

4. 응용 프로그램을 다시 시작합니다.

5. 문제가 발생하면 백업을 사용하여 이전 에이전트를 복원하고 다시 시작하십시오.

9. 사용자 액세스 관리

사용자를 관리하는 방법은 사용자가 속한 사용자 모델 에 따라 다릅니다.

• 원래 사용자 모델에 대한 문서 보기
• 최신 사용자 모델에 대한 문서 보기