Application Signals 설치 문제 해결 - Amazon CloudWatch
Application Signals가 활성화된 후 애플리케이션이 시작되지 않음Application Signals가 활성화된 후 Python 애플리케이션이 시작되지 않음WSGI 서버를 사용하는 Python 애플리케이션에 대한 Application Signals 데이터 없음내 Node.js 애플리케이션이 계측되지 않거나 Application Signals 원격 분석을 생성하지 않습니다.Application Signals 대시보드에 애플리케이션 데이터 없음서비스 지표 또는 종속성 지표에 알 수 없음 값 있음Amazon CloudWatch Observability EKS 추가 기능 관리 시 ConfigurationConflict 처리불필요한 지표와 트레이스를 필터링하고 싶음InternalOperation은 무엇을 의미하나요?.NET 애플리케이션에 대한 로깅은 어떻게 활성화하나요?.NET 애플리케이션의 어셈블리 버전 충돌은 어떻게 해결할 수 있나요?FluentBit를 비활성화할 수 있나요?CloudWatch Logs로 내보내기 전에 컨테이너 로그를 필터링할 수 있나요?

Application Signals 설치 문제 해결

이 섹션에서는 CloudWatch Application Signals 관련 문제 해결 팁을 제공합니다.

Application Signals가 활성화된 후 애플리케이션이 시작되지 않음

클러스터에서 Application Signals를 활성화한 후 Amazon EKS 클러스터의 애플리케이션이 시작되지 않는 경우 다음을 확인합니다.

  • 애플리케이션이 다른 모니터링 솔루션에서 계측되었는지 확인합니다. Application Signals는 다른 계측 솔루션과의 공존을 지원하지 않을 수 있습니다.

  • 애플리케이션이 Application Signals 사용을 위한 호환성 요구 사항을 충족하는지 확인합니다. 자세한 내용은 Application Signals 지원 시스템 단원을 참조하십시오.

  • 애플리케이션이 AWS Distro for OpenTelemetery Java 또는 Python 에이전트 및 CloudWatch 에이전트 이미지와 같은 Application Signals 아티팩트를 가져오지 못한 경우 네트워크 문제일 수 있습니다.

문제를 완화하려면 애플리케이션 배포 매니페스트에서 주석 instrumentation.opentelemetry.io/inject-java: "true" 또는 instrumentation.opentelemetry.io/inject-python: "true"를 제거하고 애플리케이션을 다시 배포합니다. 그런 다음, 애플리케이션이 작동하는지 확인합니다.

Application Signals가 활성화된 후 Python 애플리케이션이 시작되지 않음

누락된 PYTHONPATH 환경 변수로 인해 애플리케이션이 시작되지 않을 수 있다는 것은 OpenTelemetry 자동 계측의 알려진 문제입니다. 이 문제를 해결하려면 PYTHONPATH 환경 변수를 애플리케이션의 작업 디렉터리 위치로 설정해야 합니다. 이 문제에 대한 자세한 내용은 Python autoinstrumentation setting of PYTHONPATH is not compliant with Python's module resolution behavior, breaking Django applications를 참조하세요.

Django 애플리케이션의 경우 추가 필수 구성이 있으며, OpenTelemetry Python 설명서에서 설명합니다.

  • --noreload 플래그를 사용하여 자동 재로드를 방지합니다.

  • DJANGO_SETTINGS_MODULE 환경 변수를 Django 애플리케이션 settings.py 파일의 위치로 설정합니다. 이렇게 하면 OpenTelemetry가 올바르게 액세스하여 Django 설정에 통합할 수 있습니다.

WSGI 서버를 사용하는 Python 애플리케이션에 대한 Application Signals 데이터 없음

Gunicorn 또는 uWSGI와 같은 WSGI 서버를 사용하는 경우 ADOT Python 자동 계측이 작동하도록 추가 변경을 수행해야 합니다.

참고

진행하기 전에 최신 버전의 ADOT Python과 Amazon CloudWatch Observability EKS 추가 기능을 사용하고 있는지 확인하세요.

WSGI 서버로 Application Signals를 활성화하기 위한 추가 단계

  1. 분기된 워커 프로세스에서 자동 계측을 가져옵니다.

    Gunicorn의 경우 post_fork 후크를 사용합니다.

    # gunicorn.conf.py
def post_fork(server, worker):
    from opentelemetry.instrumentation.auto_instrumentation import sitecustomize

    uWSGI의 경우 import 지시문을 사용합니다.

    #  uwsgi.ini
[uwsgi]
; required for the instrumentation of worker processes
enable-threads = true
lazy-apps = true
import = opentelemetry.instrumentation.auto_instrumentation.sitecustomize

  2. OTEL_AWS_PYTHON_DEFER_TO_WORKERS_ENABLED 환경 변수를 true로 설정하여 주 프로세스를 건너뛰고 워커로 실행을 연기하도록 ADOT Python 자동 계측 구성을 활성화합니다.

내 Node.js 애플리케이션이 계측되지 않거나 Application Signals 원격 분석을 생성하지 않습니다.

Application Signals for Node.js를 활성화하려면 Node.js 애플리케이션이 CommonJS(CJS) 모듈 형식을 사용하는지 확인해야 합니다. 현재 OpenTelemetry JavaScript의 ESM 지원은 실험 중이며 진행 중인 작업이기 때문에 AWS Distro for OpenTelemetry Node.js는 ESM 모듈 형식을 지원하지 않습니다.

애플리케이션이 ESM이 아닌 CJS를 사용하고 있는지 확인하려면 애플리케이션이 ESM 활성화 조건을 충족하지 않는지 확인하세요.

Application Signals 대시보드에 애플리케이션 데이터 없음

Application Signals 대시보드에서 지표나 트레이스가 누락된 경우 다음과 같은 원인이 있을 수 있습니다. 마지막 업데이트 이후 Application Signals가 데이터를 수집하고 표시할 때까지 15분을 기다린 경우에만 이러한 원인을 조사합니다.

  • 사용 중인 라이브러리와 프레임워크가 ADOT Java 에이전트에서 지원되는지 확인합니다. 자세한 내용은 라이브러리/프레임워크를 참조하세요.

  • CloudWatch 에이전트가 실행 중인지 확인합니다. 먼저 CloudWatch 에이전트 포드의 상태를 확인하고 모든 포드가 Running 상태에 있는지 확인합니다.

    kubectl -n amazon-cloudwatch get pods.

    다음을 CloudWatch 에이전트 구성 파일에 추가하고 에이전트를 재시작합니다.

    "agent": {

  "region": "${REGION}",
  "debug": true
},

    그런 다음, CloudWatch 에이전트 포드에 오류가 있는지 확인합니다.

  • CloudWatch 에이전트의 구성 문제를 확인합니다. 다음 내용이 여전히 CloudWatch 에이전트 구성 파일에 있고 에이전트가 추가된 후 에이전트가 다시 시작되었는지 확인합니다.

    "agent": {
  "region": "${REGION}",
  "debug": true
},

    그런 다음, OpenTelemetry 디버깅 로그에서 ERROR io.opentelemetry.exporter.internal.grpc.OkHttpGrpcExporter - Failed to export ...와 같은 오류 메시지가 있는지 확인합니다. 이러한 메시지는 문제를 나타낼 수 있습니다.

    그래도 문제가 해결되지 않으면 kubectl describe pod 명령으로 포드를 설명하여 OTEL_로 시작하는 이름으로 환경 변수를 덤프하고 확인합니다.

  • OpenTelemetry Python 디버그 로깅을 활성화하려면 환경 변수 OTEL_PYTHON_LOG_LEVEL을 debug로 설정하고 애플리케이션을 재배포합니다.

  • CloudWatch 에이전트에서 데이터를 내보낼 수 있는 권한이 잘못되었거나 충분하지 않은지 확인합니다. CloudWatch 에이전트 로그에 Access Denied 메시지가 표시되는 경우 이것이 문제일 수 있습니다. CloudWatch 에이전트를 설치할 때 적용한 권한이 나중에 변경되거나 취소되었을 수 있습니다.

  • 텔레메트리 데이터를 생성할 때 AWS Distro for OpenTelemetry(ADOT) 문제가 있는지 확인합니다.

    계측 주석 instrumentation.opentelemetry.io/inject-java 및 sidecar.opentelemetry.io/inject-java가 애플리케이션 배포에 적용되고 값이 true인지 확인합니다. 이 옵션이 없으면 ADOT 추가 기능이 올바르게 설치되더라도 애플리케이션 포드가 계측되지 않습니다.

    다음으로, init 컨테이너가 애플리케이션에 적용되었고 Ready 상태가 True인지 확인합니다. init 컨테이너가 준비되지 않은 경우 상태를 참조하여 이유를 확인합니다.

    문제가 지속되면 환경 변수 OTEL_JAVAAGENT_DEBUG를 true로 설정하고 애플리케이션을 다시 배포하여 OpenTelemetry Java SDK에서 디버그 로깅을 활성화합니다. 그런 다음, ERROR io.telemetry로 시작하는 메시지를 찾습니다.

  • 지표/범위 내보내기가 데이터를 삭제하고 있을 수 있습니다. 애플리케이션 로그에서 Failed to export...를 포함하는 메시지가 있는지 확인합니다.

  • CloudWatch 에이전트가 지표 또는 범위를 Application Signals로 전송할 때 제한을 받을 수 있습니다. CloudWatch 에이전트 로그에서 제한을 나타내는 메시지가 있는지 확인합니다.

  • 서비스 검색 설정을 활성화했는지 확인합니다. 이 작업은 해당 리전에서 한 번만 수행하면 됩니다.

    이를 확인하려면 CloudWatch 콘솔에서 애플리케이션 신호, 서비스를 선택합니다. 1단계가 완료로 표시되지 않은 경우 서비스 검색 시작을 선택합니다. 5분 내에 데이터가 들어오기 시작해야 합니다.

서비스 지표 또는 종속성 지표에 알 수 없음 값 있음

Application Signals 대시보드에서 종속성 이름 또는 작업에 대해 UnknownService, UnknownOperation, UnknownRemoteService 또는 UnknownRemoteOperation이 표시되는 경우 알 수 없는 원격 서비스 및 알 수 없는 원격 작업에 대한 데이터 포인트의 발생이 해당 배포와 일치하는지 확인합니다.

  • UnknownService는 계측된 애플리케이션의 이름을 알 수 없음을 의미합니다. OTEL_SERVICE_NAME 환경 변수가 정의되지 않고 OTEL_RESOURCE_ATTRIBUTES에 service.name이 지정되지 않은 경우 서비스 이름은 UnknownService로 설정됩니다. 이 문제를 해결하려면 OTEL_SERVICE_NAME 또는 OTEL_RESOURCE_ATTRIBUTES에 서비스 이름을 지정합니다.

  • UnknownOperation은 간접적으로 호출된 작업의 이름을 알 수 없음을 의미합니다. Application Signals가 원격 직접 호출을 간접적으로 호출하는 작업 이름을 찾을 수 없거나 추출된 작업 이름에 높은 카디널리티 값이 포함된 경우가 여기에 해당합니다.

  • UnknownRemoteService는 대상 서비스의 이름을 알 수 없음을 의미합니다. 시스템에서 원격 직접 호출이 액세스하는 대상 서비스 이름을 추출할 수 없는 경우가 여기에 해당합니다.

    한 가지 해결 방법은 요청을 보내는 함수 주위에 사용자 지정 범위를 생성하고 지정된 값으로 aws.remote.service 속성을 추가하는 것입니다. 또 다른 옵션은 RemoteService의 지표 값을 사용자 지정하도록 CloudWatch 에이전트를 구성하는 것입니다. CloudWatch 에이전트의 사용자 지정에 대한 자세한 내용은 CloudWatch Application Signals 활성화 섹션을 참조하세요.

  • UnknownRemoteOperation은 대상 작업의 이름을 알 수 없음을 의미합니다. 시스템에서 원격 직접 호출이 액세스하는 대상 작업 이름을 추출할 수 없는 경우가 여기에 해당합니다.

    한 가지 해결 방법은 요청을 보내는 함수 주위에 사용자 지정 범위를 생성하고 지정된 값으로 aws.remote.operation 속성을 추가하는 것입니다. 또 다른 옵션은 RemoteOperation의 지표 값을 사용자 지정하도록 CloudWatch 에이전트를 구성하는 것입니다. CloudWatch 에이전트의 사용자 지정에 대한 자세한 내용은 CloudWatch Application Signals 활성화 섹션을 참조하세요.

Amazon CloudWatch Observability EKS 추가 기능 관리 시 ConfigurationConflict 처리

Amazon CloudWatch Observability EKS 추가 기능을 설치하거나 업데이트할 때 Conflicts found when trying to apply. Will not continue due to resolve conflicts mode로 시작하는 설명과 함께 ConfigurationConflict 유형의 Health Issue로 인해 발생한 오류가 발견된 경우, CloudWatch 에이전트와 ServiceAccount, ClusterRole, ClusterRoleBinding 등의 연결된 구성 요소가 클러스터에 이미 설치되어 있기 때문일 수 있습니다. 추가 기능이 CloudWatch 에이전트 및 연결된 구성 요소를 설치하려고 할 때 콘텐츠의 변경 사항이 탐지되면 기본적으로 클러스터의 리소스 상태를 덮어쓰지 않도록 설치 또는 업데이트가 실패합니다.

Amazon CloudWatch Observability EKS 추가 기능에 온보딩하려고 하는데 이 오류가 표시되는 경우 이전에 클러스터에 설치한 기존 CloudWatch 에이전트 설정을 삭제한 다음, EKS 추가 기능을 설치하는 것이 좋습니다. 사용자 지정 에이전트 구성과 같이 원래 CloudWatch 에이전트 설정에 대한 모든 사용자 지정을 백업하고 다음에 설치하거나 업데이트할 때 Amazon CloudWatch Observability EKS 추가 기능에 제공합니다. 이전에 Container Insights 온보딩을 위해 CloudWatch 에이전트를 설치한 경우 자세한 내용은 Container Insights의 CloudWatch 에이전트 및 Fluent Bit 삭제 섹션을 참조하세요.

또는 추가 기능은 OVERWRITE를 지정하는 기능이 있는 충돌 해결 구성 옵션을 지원합니다. 이 옵션을 사용하면 클러스터의 충돌을 덮어써서 추가 기능 설치 또는 업데이트를 진행할 수 있습니다. Amazon EKS 콘솔을 사용하는 경우 추가 기능을 생성하거나 업데이트할 때 선택적 구성 설정을 선택하면 충돌 해결 방법을 찾을 수 있습니다. AWS CLI를 사용하는 경우 명령에 --resolve-conflicts OVERWRITE를 제공하여 추가 기능을 생성하거나 업데이트할 수 있습니다.

불필요한 지표와 트레이스를 필터링하고 싶음

Application Signals가 원하지 않는 트레이스와 지표를 수집하는 경우 카디널리티를 줄이기 위해 사용자 지정 규칙으로 CloudWatch 에이전트를 구성하는 방법에 대한 자세한 내용은 카디널리티가 높은 작업 관리 섹션을 참조하세요.

트레이스 샘플링 규칙 사용자 지정에 대한 자세한 내용은 X-Ray 설명서의 Configure sampling rules를 참조하세요.

InternalOperation은 무엇을 의미하나요?

InternalOperation은 외부 간접 호출이 아니라 내부에서 애플리케이션에 의해 트리거되는 작업입니다. InternalOperation 표시는 예상되는 정상 동작입니다.

다음은 InternalOperation이 표시되는 몇 가지 일반적인 예입니다.

  • 시작 시 사전 로드 - 애플리케이션이 워밍업 단계 동안 데이터베이스에서 메타데이터를 읽는 loadDatafromDB라는 작업을 수행합니다. loadDatafromDB가 서비스 작업으로 관찰되는 대신 InternalOperation으로 분류됨을 확인할 수 있습니다.

  • 백그라운드에서 비동기 실행 - 애플리케이션이 이벤트 대기열을 구독하고 업데이트가 있을 때마다 그에 따라 스트리밍 데이터를 처리합니다. 트리거된 각 작업은 서비스 작업으로 InternalOperation 아래에 있습니다.

  • 서비스 레지스트리에서 호스트 정보 검색 - 애플리케이션은 서비스 검색을 위해 서비스 레지스트리와 통신합니다. 검색 시스템과의 모든 상호 작용은 InternalOperation으로 분류됩니다.

.NET 애플리케이션에 대한 로깅은 어떻게 활성화하나요?

.NET 애플리케이션에 대한 로깅을 활성화하려면 다음과 같은 환경 변수를 구성합니다. 이러한 환경 변수를 구성하는 방법에 대한 자세한 내용은 OpenTelemetry 설명서의 .NET 자동 계측 문제 해결을 참조하세요.

  • OTEL_LOG_LEVEL

  • OTEL_DOTNET_AUTO_LOG_DIRECTORY

  • COREHOST_TRACE

  • COREHOST_TRACEFILE

.NET 애플리케이션의 어셈블리 버전 충돌은 어떻게 해결할 수 있나요?

다음과 같은 오류가 발생하는 경우 해결 단계는 OpenTelemetry 설명서의 어셈블리 버전 충돌을 참조하세요.

Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.

File name: 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'
   at Microsoft.AspNetCore.Builder.WebApplicationBuilder..ctor(WebApplicationOptions options, Action`1 configureDefaults)
   at Microsoft.AspNetCore.Builder.WebApplication.CreateBuilder(String[] args)
   at Program.<Main>$(String[] args) in /Blog.Core/Blog.Core.Api/Program.cs:line 26

FluentBit를 비활성화할 수 있나요?

Amazon CloudWatch Observability EKS 추가 기능을 구성하여 FluentBit를 비활성화할 수 있습니다. 자세한 내용은 (선택 사항) 추가 구성 단원을 참조하십시오.

CloudWatch Logs로 내보내기 전에 컨테이너 로그를 필터링할 수 있나요?

아니요. 컨테이너 로그 필터링은 아직 지원되지 않습니다.