Application Signals 구성
이 섹션에는 CloudWatch Application Signals 구성에 대한 정보가 들어 있습니다.
트레이스 샘플링 속도
기본적으로 Application Signals를 활성화하면 reservoir=1/s 및 fixed_rate=5%의 기본 샘플링 속도 설정을 사용하여 X-Ray 중앙 집중식 샘플링이 활성화됩니다. AWS Distro for OpenTelemetry (ADOT) SDK 에이전트의 환경 변수는 다음과 같이 설정됩니다.
| 환경 변수 | 값 | 참고 |
|---|---|---|
|
|
|
|
|
CloudWatch 에이전트의 엔드포인트 |
샘플링 구성 변경에 대한 자세한 내용은 다음을 참조하세요.
X-Ray 샘플링을 변경하려면 Configure sampling rules를 참조하세요.
ADOT 샘플링을 변경하려면 X-Ray 원격 샘플링을 위한 OpenTelemetry 컬렉터 구성
을 참조하세요.
X-Ray 중앙 집중식 샘플링을 비활성화하고 로컬 샘플링을 대신 사용하려면 ADOT SDK Java 에이전트에 대해 다음과 같이 값을 설정합니다. 다음 예제에서는 샘플링 속도를 5%로 설정합니다.
| 환경 변수 | 값 |
|---|---|
|
|
|
|
고급 샘플링 설정에 대한 자세한 내용은 OTEL_TRACES_SAMPLER
로그 상관 관계에 대한 추적 활성화
Application Signals에서 로그 상관 관계 추적을 활성화할 수 있습니다. 그러면 트레이스 ID와 범위 ID가 관련 애플리케이션 로그에 자동으로 삽입됩니다. 그런 다음 Application Signals 콘솔에서 트레이스 세부 정보 페이지를 열면 현재 트레이스와 상관 관계가 있는 관련 로그 항목(있는 경우)이 페이지 하단에 자동으로 표시됩니다.
예를 들어 지연 시간 그래프에서 급증을 발견했다고 가정해 보겠습니다. 그래프에서 특정 시점을 선택하여 해당 시점에 대한 진단 정보를 로드할 수 있습니다. 그런 다음 관련 트레이스를 선택하여 추가 정보를 얻습니다. 트레이스 정보를 볼 때 아래로 스크롤하여 트레이스와 관련된 로그를 볼 수 있습니다. 이러한 로그에는 지연 시간 급증을 일으키는 문제와 관련된 패턴이나 오류 코드가 표시될 수 있습니다.
추적 로그 상관관계를 달성하기 위해 Application Signals는 다음 사항을 사용합니다.
Java용 Logger MDC 자동 계측
. Python용 OpenTelemetry 로깅 계측
.
이러한 계측은 모두 OpenTelemetry 커뮤니티에서 제공됩니다. Application Signals는 이를 사용하여 트레이스 ID 및 범위 ID와 같은 트레이스 컨텍스트를 애플리케이션 로그에 삽입합니다. 이를 활성화하려면 자동 계측을 활성화하도록 로깅 구성을 수동으로 변경해야 합니다.
애플리케이션이 실행되는 아키텍처에 따라 이 섹션의 단계를 따르는 것 외에도 트레이스 로그 상관 관계를 활성화하도록 환경 변수를 설정해야 할 수도 있습니다.
Amazon EKS에서는 추가 단계가 필요하지 않습니다.
Amazon ECS에서는 추가 단계가 필요하지 않습니다.
Amazon EC2에서는 3단계: 애플리케이션 계측 후 시작 절차의 4단계를 참조하세요.
트레이스 로그 상관 관계를 활성화한 후
트레이스 로그 상관 관계 설정 예제
이 섹션에는 여러 환경에서 트레이스 로그 상관 관계를 설정하는 예가 포함되어 있습니다.
Java용 Spring Boot
custom-app이라는 폴더에 Spring Boot 애플리케이션이 있다고 가정해 보겠습니다. 애플리케이션 구성은 일반적으로 다음과 custom-app/src/main/resources/application.yml이라는 YAML 파일입니다.
spring: application: name: custom-app config: import: optional:configserver:${CONFIG_SERVER_URL:http://localhost:8888/} ...
트레이스 로그 상관 관계를 활성화하려면 다음 로깅 구성을 추가하세요.
spring: application: name: custom-app config: import: optional:configserver:${CONFIG_SERVER_URL:http://localhost:8888/} ... logging: pattern: level: trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p
Java용 Logback
로깅 구성(예: logback.xml)에서 트레이스 컨텍스트 trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p를 인코더의 pattern에 삽입합니다. 예를 들어, 다음 구성은 로그 메시지 앞에 트레이스 컨텍스트를 추가합니다.
<appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>app.log</file> <append>true</append> <encoder> <pattern>trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n</pattern> </encoder> </appender>
Logback의 인코더에 대한 자세한 내용은 Logback 설명서의 Encoders
Java용 Log4j2
로깅 구성(예: log4j2.xml)에서 트레이스 컨텍스트 trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p를 PatternLayout에 삽입합니다. 예를 들어, 다음 구성은 로그 메시지 앞에 트레이스 컨텍스트를 추가합니다.
<Appenders> <File name="FILE" fileName="app.log"> <PatternLayout pattern="trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n"/> </File> </Appenders>
Log4j2의 패턴 레이아웃에 대한 자세한 내용은 Log4j2 설명서의 Pattern Layout
Java용 Log4j
로깅 구성(예: log4j.xml)에서 트레이스 컨텍스트 trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p를 PatternLayout에 삽입합니다. 예를 들어, 다음 구성은 로그 메시지 앞에 트레이스 컨텍스트를 추가합니다.
<appender name="FILE" class="org.apache.log4j.FileAppender">; <param name="File" value="app.log"/>; <param name="Append" value="true"/>; <layout class="org.apache.log4j.PatternLayout">; <param name="ConversionPattern" value="trace_id=%mdc{trace_id} span_id=%mdc{span_id} trace_flags=%mdc{trace_flags} %5p - %m%n"/>; </layout>; </appender>;
Log4j의 패턴 레이아웃에 대한 자세한 내용은 Log4j 설명서의 Class Layout
Python
애플리케이션을 실행하는 동안 환경 변수 OTEL_PYTHON_LOG_CORRELATION을 true로 설정합니다. 자세한 내용은 Python OpenTelemetry 설명서의 Enable trace context injection
Node.js
추적 컨텍스트 주입을 지원하는 로깅 라이브러리에 대해 Node.js에서 이를 활성화하는 방법에 대한 자세한 내용은 Node.js용 Pino
로그 상관 관계에 대한 지표 활성화
애플리케이션 로그를 CloudWatch Logs의 로그 그룹에 게시하는 경우 Application Signals에서 지표와 애플리케이션 로그 간의 상관 관계를 활성화할 수 있습니다. 지표 로그 상관 관계를 사용하면 Application Signals 콘솔에서 지표와 관련된 로그 그룹을 자동으로 표시합니다.
예를 들어 지연 시간 그래프에서 급증을 발견했다고 가정해 보겠습니다. 그래프에서 특정 시점을 선택하여 해당 시점에 대한 진단 정보를 로드할 수 있습니다. 진단 정보에는 현재 서비스 및 지표와 관련된 관련 애플리케이션 로그 그룹이 표시됩니다. 그런 다음 버튼을 선택하여 해당 로그 그룹에서 CloudWatch Logs Insights 쿼리를 실행할 수 있습니다. 애플리케이션 로그에 포함된 정보에 따라 지연 시간 스파이크의 원인을 조사하는 데 도움이 될 수 있습니다.
애플리케이션이 실행되는 아키텍처에 따라 지표와 애플리케이션 로그 상관 관계를 활성화하도록 환경 변수를 설정해야 할 수도 있습니다.
-
Amazon EKS에서는 추가 단계가 필요하지 않습니다.
-
Amazon ECS에서는 추가 단계가 필요하지 않습니다.
-
Amazon EC2에서는 3단계: 애플리케이션 계측 후 시작 절차의 4단계를 참조하세요.
카디널리티가 높은 작업 관리
Application Signals에는 작업의 카디널리티를 관리하고 지표 내보내기를 관리하여 비용을 최적화하는 데 사용할 수 있는 CloudWatch 에이전트의 설정이 포함되어 있습니다. 기본적으로 지표 제한 기능은 시간 경과에 따른 서비스의 개별 작업 수가 기본 임계값인 500을 초과할 때 활성 상태가 됩니다. 구성 설정을 조정하여 동작을 미세 조정할 수 있습니다.
지표 제한이 활성화되었는지 확인
다음 방법을 사용하여 기본 지표 제한이 발생하는지 확인할 수 있습니다. 제한이 있는 경우 다음 섹션의 단계에 따라 카디널리티 제어 최적화를 고려해야 합니다.
CloudWatch 콘솔에서 Application Signals, Services를 선택합니다. 이름이 AllOtherOperations인 Operation 또는 AllOtherRemoteOperations인 RemoteOperation이 표시되는 경우 지표 제한이 발생하고 있습니다.
Application Signals에서 수집한 지표의
Operation차원에AllOtherOperations값이 있는 경우 지표 제한이 발생하는 것입니다.Application Signals에서 수집한 지표의
RemoteOperation차원에AllOtherRemoteOperations값이 있는 경우 지표 제한이 발생하는 것입니다.
카디널리티 제어 최적화
카디널리티 제어를 최적화하기 위해 다음을 수행할 수 있습니다.
사용자 지정 규칙을 만들어 작업을 집계합니다.
지표 제한 정책을 구성합니다.
사용자 지정 규칙을 만들어 작업을 집계합니다.
카디널리티가 높은 작업은 컨텍스트에서 추출된 부적절한 고유 값으로 인해 발생할 수 있습니다. 예를 들어 경로에 사용자 ID 또는 세션 ID가 포함된 HTTP/S 요청을 보내면 수백 개의 서로 다른 작업이 발생할 수 있습니다. 이러한 문제를 해결하려면 이러한 작업을 재작성하는 사용자 지정 규칙을 사용하여 CloudWatch 에이전트를 구성하는 것이 좋습니다.
PUT /api/customer/owners/123, PUT /api/customer/owners/456 등과 같은 개별 RemoteOperation 호출과 유사한 요청을 통한 다양한 지표 생성이 급증하는 경우 이러한 작업을 단일 RemoteOperation로 통합하는 것이 좋습니다. 한 가지 접근 방식은 특히 PUT /api/customer/owners/{ownerId}와 같이 PUT /api/customer/owners/로 시작하는 모든 RemoteOperation 호출을 통일된 형식으로 표준화하는 것입니다. 다음 예는 이를 보여 줍니다. 기타 사용자 지정 규칙에 대한 자세한 내용은 CloudWatch Application Signals 활성화 섹션을 참조하세요.
{ "logs":{ "metrics_collected":{ "application_signals":{ "rules":[ { "selectors":[ { "dimension":"RemoteOperation", "match":"PUT /api/customer/owners/*" } ], "replacements":[ { "target_dimension":"RemoteOperation", "value":"PUT /api/customer/owners/{ownerId}" } ], "action":"replace" } ] } } } }
경우에 따라 카디널리티가 높은 지표가 AllOtherRemoteOperations에 집계되고, 어떤 특정 지표가 포함되는지 명확하지 않을 수 있습니다. CloudWatch 에이전트는 중단된 작업을 로깅할 수 있습니다. 중단된 작업을 식별하려면 다음 예시의 구성을 사용하여 문제가 다시 나타날 때까지 로깅을 활성화합니다. 그런 다음 CloudWatch 에이전트 로그(컨테이너 stdout 또는 EC2 로그 파일로 액세스 가능)를 검사하고 drop metric data 키워드를 검색합니다.
{ "agent": { "config": { "agent": { "debug": true }, "traces": { "traces_collected": { "application_signals": { } } }, "logs": { "metrics_collected": { "application_signals": { "limiter": { "log_dropped_metrics": true } } } } } } }
지표 제한 정책 생성
기본 지표 제한 구성으로 서비스의 카디널리티를 해결할 수 없는 경우 지표 제한기 구성을 사용자 지정할 수 있습니다. 이를 위해 CloudWatch 에이전트 구성 파일의 logs/metrics_collected/application_signals 섹션에 limiter 섹션을 추가합니다.
다음 예시에서는 지표 제한 임계값을 500개의 개별 지표에서 100개로 줄입니다.
{ "logs": { "metrics_collected": { "application_signals": { "limiter": { "drop_threshold": 100 } } } } }
