컨텍스트의 APM 로그인

귀하의 로그인을 뉴켈릭 에 신고하는 방법에는 여러 가지가 있습니다. APM 에이전트를 사용하는 것은 특히 다른 로그 관리도구를 사용할 필요가 없다는 이점을 중요하게 생각하는 소규모 팀과 DevOps 팀에게 널리 사용되는 방법 중 하나입니다.

컨텍스트의 APM 로그인

APM에이전트에는 logs in context 이라는 기능이 있습니다. 이 기능의 이점에 대한 자세한 내용은 컨텍스트 내 로그를 참조하세요.

APM 에이전트의 경우 컨텍스트 로그인 기능은 다음과 같은 몇 가지 작업을 수행합니다.

• 다양한 New Relic UI 환경에서 로그 데이터를 볼 수 있는 중요한 New Relic 메타데이터(예: span.id , trace.id , hostname , entity.guid , entity.name )로 앱 로그를 장식합니다.

• 로그를 New Relic에 직접 전달하므로 타사 도구가 필요하지 않습니다.

• 일부 로그 지표를 보고합니다. 이는 APM

  Summary

  UI 페이지의

  Logs

  차트에 표시됩니다.

현재 APM 에이전트 버전에는 이러한 기능이 기본적으로 활성화되어 있습니다.

APM 에이전트 구성을 통해 이 기능의 모든 측면을 제어할 수 있습니다. 이들 중 하나 이상을 비활성화하려는 이유는 제한 사항 을참조하십시오. 예를 들어 APM 에이전트가 New Relic 메타데이터를 추가하도록 하려면 로그 데코레이션 기능을 사용하는 동시에 로그 전달을 비활성화하고 대신 다른 로깅 에이전트(예: 인프라 에이전트 또는 타사 파티 로깅 에이전트).

구현 세부 정보 및 구성 지침은 에이전트마다 다릅니다( 에이전트 세부 정보 참조 ).

컨텍스트에서 로그의 기능에 대해 자세히 알아보려면 이 사용 사례 예 를 참조하십시오. 이 예에서는 엔지니어링 팀이 컨텍스트에서 로그를 사용하여 앱의 느린 응답 시간과 증가하는 오류율 문제를 해결하는 방법을 설명합니다.

상황에 맞는 로그인이 앱과 호스트에서 문제의 근본 원인을 찾는 데 어떻게 도움이 되는지 보려면 다음 짧은 비디오(약 3분 40초)를 시청하세요.

시작하다

컨텍스트에서 APM로그를 설정하려면 다음 안내를 따르세요.

1. 아직 계정이 없다면 New Relic 계정을 만드 십시오. 영원히 무료입니다.
2. APM 에이전트를 설치하고 최신 APM 에이전트 버전 인지 확인합니다.
3. 최신 버전의 APM 에이전트에는 기본적으로 활성화된 컨텍스트(메타데이터 추가 및 전달)의 로그가 있습니다. 로그가 올바르게 작동하도록 에이전트 구성 파일을 일부 업데이트해야 하는 경우가 있습니다. 이에 대한 자세한 내용은 에이전트에 대한 로그 활성화를 참조하십시오.

그게 다야! APM UI로 이동하고 관련 로그 데이터를 찾아 상황에 맞는 APM 로그로 애플리케이션 문제 해결을 시작하십시오.

APM 에이전트 API

로깅 프레임워크를 컨텍스트 솔루션의 기존 로그에서 사용할 수 없는 경우 로그에 주석을 추가 하는 API 호출을 사용하여 로깅 라이브러리를 구성 할 수 있습니다.

APM 에이전트 로그 구성

최신 APM에이전트에는 기본적으로 컨텍스트 로그(로그 장식 및 로그 포워딩)가 활성화되어 있습니다. 컨텍스트에서 로그인 및 로그인 포워딩을 지원하는 APM 에이전트에 대한 정보는 다음과 같습니다.

• 에이전트 v3.17.0 이상 에 대한 컨텍스트 절차에서 Go 로그인
• 에이전트 v7.6.0 이상 에 대한 컨텍스트 절차의 Java 로그인
• 에이전트 v9.8.0 이상 에 대한 컨텍스트 절차의 .NET 로그인
• Node.js 는 에이전트 v8.11.0 이상 에 대한 컨텍스트 절차에 로그인합니다.
• 에이전트 v10.1.0 이상 에 대한 컨텍스트 프로시저의 PHP 로그인
• 에이전트 v7.12.0.176 에 대한 컨텍스트 프로시저의 Python 로그인
• 에이전트 v8.6.0 이상 에 대한 컨텍스트 절차에서 Ruby 로그인

APM 로그 전달을 사용할 수 없거나 사용하지 않으려면 다른 솔루션을 사용하여 로그를 전달할 수 있습니다 .

제한 사항

APM 로그인 컨텍스트 기능은 기본적으로 활성화되어 있습니다. 이는 보안, 규정 준수, 청구 또는 시스템 성능에 부정적인 영향을 미칠 수 있습니다.

다음은 몇 가지 알려진 추가 제한 사항입니다.

• Node.js 에이전트를 제외하고

  APM

  로그 포워딩은 전체 로그를 보내지 않습니다. 로그 포워딩 세부정보에 대해 알아보세요.

• 에이전트가 로드될 때까지 시작 로그를 사용할 수 없습니다.

• Kubernetes를 사용하는 경우 Kubernetes API가 아닌 계측을 통해 로그를 장식한다는 점에 유의하십시오. 이것은 파일 시스템에 로그아웃하는 것과 별개입니다. 로그는 절대 호스트에 닿지 않거나 API를 호출할 수 있는 위치에 존재합니다.

• 애플리케이션에서 예외가 발생하면 현재 Java 또는 .NET 에이전트에 대한 컨텍스트의 관련 로그에 스택 추적이 표시되지 않습니다. 해결 방법으로 드롭 필터 규칙을 변경할 수 있습니다.

• Fluentd는 로그를 생성한 엔티티에서 processID 을 추가할 수 있지만 APM 로그는 이를 볼 수 없습니다. 또한 Kubernetes에서는 메타데이터를 추가하기 위해 API를 호출하지만 이 데이터는 애플리케이션 내에서 볼 수 없습니다. 엔터티 메타데이터가 필요한 경우 컨텍스트에서 자동 로그를 사용하는 것이 좋지만 애플리케이션에서 로그를 전송하지 않는 것이 좋습니다. 대신 Fluentd, Fluent Bit 또는 다른 솔루션을 계속 사용하여 로그 파일을 전달하세요.

기본 설정을 조정해야 하는 경우 자동 로깅 비활성화 를 참조하십시오.

데이터 프라이버시 보장

당사의 로그 수집 파이프라인은 신용 카드, 주민등록번호, 주민등록번호 등을 자동으로 마스킹합니다. 자세한 내용은 로그 관리에 대한 보안 문서 를 참조하십시오.

난독화 기능을 사용하여 로그의 민감한 데이터를 마스킹하거나 해시하는 사용자 지정 규칙을 생성할 수도 있습니다. 이는 민감한 데이터에 대한 액세스를 제한하는 것이 비실용적이거나 불가능한 경우 또는 일부 데이터를 New Relic에 의해 저장해서는 안 되는 경우에 중요합니다. 자세한 내용은 난독화 문서 를 읽어보세요.

로그 전달에 대한 세부 정보

모든 APM에이전트(Node.js 제외)의 경우 로그 포워딩 옵션은 전체 로그를 전달하지 않습니다. 로그 포워딩으로 전송되는 내용에 대한 자세한 내용은 아래 축소기를 참조하세요.

{
  "v": "x",
  "level": "x",
  "name": "x",
  "hostname": "x",
  "pid": 01,
  "timestamp": "x",
  "message": "x",
  "bunches": "of custom stuff"
}

{
  "timestamp": "x",
  "message": "x",
  "span.id": "x",
  "trace.id": "x",
  "hostname": "x",
  "entity.guid": "x",
  "entity.name": "x"
}

보고된 로그가 더 필요한 경우 옵션은 다음과 같습니다.

• 특정 로그 데이터를 포함하도록 APM 에이전트를 구성합니다.
• 로그 장식 은 그대로 유지하되 APM 에이전트 로그 전달을 비활성화하고 대신 자체 로그 전달 솔루션을 사용하십시오.

이러한 옵션에 대한 자세한 내용은 상담원별 로그인 컨텍스트 문서를 참조하세요.

로그 메트릭

APM에이전트를 설정하면 APM Summary 페이지에 로깅 지표 차트가 자동으로 표시됩니다.

이 차트에는 로그 수가 표시됩니다. APM 로그 포워딩을 비활성화하지 않은 경우 로그 자체로 이동하는 차트 링크를 클릭할 수 있습니다. APM 로그 포워딩을 끄더라도 이 차트에는 APM 로그 포워딩을 활성화한 경우 검사할 수 있는 잠재적인 로그가 계속 표시됩니다.

로깅 측정항목은 다음 쿼리와 같이 apm.service.logging.lines 속성을 통해 보고됩니다.

SELECT count(apm.service.logging.lines) FROM Metric WHERE (entity.guid = 'AN_ENTITY_GUID') LIMIT MAX SINCE 60 seconds AGO TIMESERIES

로깅 지표 차트를 보고 싶지 않다면 끌 수 있습니다. 하지만 계정 수준에서는 끌 수 없습니다. 로깅 지표를 비활성화하려면 에이전트에 대한 전용 APM 설정 문서(예: PHP의 경우 이 logging_metrics 구성 옵션)를 참조하세요.

중복 로그 방지

컨텍스트 기능에서 로그를 사용하면 데이터 수집이 증가합니다. 계정의 가격 모델에 따라 수집 한도 및 청구에 영향을 미칠 수 있습니다.

중복 로그 전송을 방지하는 방법에 대해 자세히 알아보려면 업그레이드 가이드를 확인하세요.

자세한 내용은 절차에 따라 특정 로그 전달자 를 비활성화하십시오.

수집 한도 관리

Example: 귀하의 엔지니어링 팀은 앱의 문제를 해결하고 있으므로 APM 에이전트가 수집하는 로그 볼륨을 일시적으로 늘려 보다 세부적인 로깅을 제공합니다. 그러나 며칠 동안 더 높은 한도를 그대로 두면 불필요한 데이터가 전송되어 청구 금액이 늘어날 수 있습니다.

예상치 못한 상황을 방지하려면 NRQL 쿼리 를 사용하여 수집 제한을 추적하는 경고 조건 을 만드는 것이 좋습니다. 예를 들어:

UI에서 데이터 제한 및 사용량 보기

UI에서 데이터 한도를 검토 하려면 사용자 메뉴 에서 Manage your data > Limits 클릭합니다. 또는 사용량을 보려면 View your usage 클릭하세요.

NRQL 쿼리: 예상 비용 예

비용 관련 쿼리를 참조하십시오.

NRQL 경고: 사용량 임계값 예

사용량이 기가바이트의 데이터에 대해 고정된 월별 임계값을 초과할 때 경고를 생성하려면 경고 조건에 다음 NRQL 쿼리 를 추가합니다.

FROM NrMTDConsumption SELECT latest(GigabytesIngested) WHERE productLine = 'DataPlatform'

카피

예: 컨텍스트에서 로그의 힘

다음은 문제의 근본 원인을 파악하기 위해 컨텍스트에서 APM로그를 사용하는 자세한 사용 사례입니다.

Example scenario: 대기 중인 엔지니어는 앱의 응답 시간이 좋지 않고 오류율이 높아지는 것에 대해 뉴렐릭 공지를 받습니다. 오류 증가와 지연 시간의 근본 원인을 찾아 문제가 있는 호스트를 로드 밸런싱에서 제외할지 아니면 최신 릴리스로 롤백할지 결정할 수 있어야 합니다.

문제 해결을 시작하려면 New Relic UI로 이동합니다.

언제 어디서 오류가 시작되었습니까?

엔지니어가 앱의 APM Summary 페이지를 보면 응답 시간 증가로 이어지는 더 많은 오류 로그가 표시됩니다. 그들은 로그가 문제의 근본 원인을 드러낼 수 있는지 확인하고 싶어합니다.

How can they quickly decide what's related to the problem?

그들은 로그 수집을 설정하지 않았습니다. 그러나 앱용 Java 에이전트가 컨텍스트에 APM 로그를 포함하도록 최근 업데이트되었으므로 이제 앱이 자동으로 로그 및 연결 메타데이터를 수신합니다. UI에 표시되는 메트릭은 로그 심각도별로 계수를 패싯합니다. (이는 Java 에이전트의 내장 로그 데코레이션 기능에 의해 설정됩니다.)

What entities are related?

동일한 UI 페이지에서 Logs 차트를 클릭하여 Log summary 뷰를 검토할 수 있습니다. 이 보기에는 계측된 로그가 수집된 시기와 해당 로그의 심각도 수준이 Error 이하인 시기가 표시됩니다. 또한 로그 패턴 목록과 각 패턴에 맞는 전체 로그의 비율도 표시됩니다.

로그에 어떤 패턴이 나타납니까?

Log patterns UI에서는 드물게 발생하는 오류 메시지가 자주 발생하기 시작하여 이제 목록에 표시됩니다. 이를 통해 엔지니어는 시끄러운 모든 상태 업데이트 대신 문제가 있는 로그에 집중할 수 있습니다.

What patterns should they focus on?

엔지니어는 흥미로운 로그 패턴을 발견하고 이 패턴에 맞는 로그만 보려고 합니다. 패턴 값을 표시되는 로그에 필터로 추가하기 위해 클릭합니다. 이것은 초점을 좁힙니다.

더 많은 로그 세부 정보를 통해 무엇을 알 수 있습니까?

엔지니어는 로그 레코드에 포함된 모든 값을 보고 싶어서 Log details 보기를 클릭합니다. 이는 로그 자체가 의미가 있는지 확인하는 데 도움이 됩니다. 또한 앱이 실행되는 Kubernetes 환경을 더 자세히 살펴보거나, 복사 트레이스나 APM로그 기록과 관련된 오류를 직접 조사할 수 있습니다.

엔지니어는 전체 스택 추적을 볼 수 있는 APM 오류를 살펴보기로 결정합니다. 또한 Errors inbox UI에서 로그를 볼 수도 있습니다.

문제 해결에 도움이 되는 추가 테스트 데이터는 무엇입니까?

문제 해결 팀은 원인을 분리하기 위해 테스트를 실행했지만 테스트 트랜잭션에 대한 모든 로그가 수집되지는 않았습니다. Java 에이전트 구성 파일의 기본 로그 수집( application_logging:forwarding:max_samples_stored: 에서 분당 약 10,000개)은 서비스에 문제가 있는지 확인하는 데 유용했습니다. 그러나 이제 더 자세한 문제 해결을 위해 샘플링을 더 높은 숫자로 올려야 합니다.

문제 해결됨. 이제 뭐?

문제 해결 팀은 문제가 최근에 도입된 변경으로 인해 발생했다고 판단하여 해당 코드를 롤백합니다. 리소스를 절약하고 비용을 수집하기 위해 구성 파일에서 application_logging:forwarding:max_samples_stored: 에 대한 로그 수집을 거부하지만 문제가 반복되는 경우에 대비하여 로그 샘플링을 계속 실행합니다.

문제 진단, 해결 팀은 또한 이 앱으로 필터링된 Log patterns 페이지를 가리키도록 Runbook을 업데이트하고 공지 조건에 런북을 추가합니다. 다음에 이 상황과 유사한 공지를 받게 되면 배운 교훈을 활용하여 더 빠른 문제 해결, 해결을 할 수 있습니다.