다음을 통해 공유

Linux 컨테이너에서 진단 수집

다른 시나리오에서 .NET 문제를 진단하는 데 유용한 동일한 진단 도구도 컨테이너에서 작동합니다. 도구는 대상 프로세스와 동일한 컨테이너, 호스트 또는 사이드카 컨테이너에서 실행할 수 있습니다.

컨테이너에서 .NET CLI 도구 사용

이 문서의 적용 대상: ✔️ .NET Core 3.1 SDK 이상 버전

모든 dotnet-* CLI 진단 도구 는 검사하는 애플리케이션과 동일한 컨테이너 내에서 실행할 때 작동할 수 있지만 다음과 같은 잠재적인 문제 지점을 주의해야 합니다.

  • 컨테이너 내에서 실행되는 도구에는 컨테이너 리소스 제한이 적용됩니다. 리소스 제한이 너무 낮으면 도구가 느리게 실행되거나 실패할 수 있습니다. 대부분의 도구는 요구 사항이 적지만 dotnet-dumpdotnet-gcdump 메모리 공간이 큰 프로세스를 대상으로 할 때 상당한 메모리 및 디스크 공간을 사용할 수 있습니다. dotnet-trace와 dotnet-counters는 많은 양의 추적 이벤트나 메트릭 시계열 데이터를 캡처하도록 구성된 경우 대용량 파일을 생성할 수도 있습니다.
  • dotnet-dump 는 ptrace 권한이 필요한 도우미 프로세스가 실행되도록 합니다. Linux에는 성공 여부에 영향을 줄 수 있는 다양한 보안 구성 옵션이 있으므로 경우에 따라 컨테이너의 보안 구성을 조정해야 할 수 있습니다. 보안 권한 진단에 대한 자세한 지침은 덤프 FAQ 를 참조하세요.
  • 컨테이너 내에서 도구를 실행할 때 컨테이너를 빌드할 때 미리 설치하거나 주문형으로 다운로드할 수 있습니다. 미리 설치하면 필요할 때 더 쉬워지지만 컨테이너의 크기를 늘리고 악의적인 행위자가 악용하려고 할 수 있는 더 큰 공격 표면을 만듭니다.

사이드카 컨테이너 또는 호스트에서 .NET CLI 도구 사용

dotnet-* CLI 진단 도구는 호스트 또는 사이드카 컨테이너에서 실행도 지원합니다. 이렇게 하면 동일한 컨테이너에서 실행되는 크기, 보안 및 리소스 제한이 크게 방지되지만 도구가 성공적으로 통신하기 위한 몇 가지 추가 요구 사항이 있습니다.

--process-id 또는 --name 도구 명령줄 인수를 사용하여 검사할 대상 프로세스를 식별할 때는 다음이 필요합니다.

  1. 컨테이너는 사이드카 컨테이너의 도구가 대상 컨테이너의 프로세스에 액세스할 수 있도록 프로세스 네임스페 이스를 공유해야 합니다.
  2. 도구는 .NET 런타임이 /tmp 디렉터리에 쓰는 진단 포트 Unix Domain Socket에 액세스해야 하므로 /tmp 디렉터리를 볼륨 탑재를 통해 대상 컨테이너와 사이드카 컨테이너 간에 공유해야 합니다. 이것은 예를 들어 컨테이너가 공통 볼륨 또는 Kubernetes emptyDir 볼륨을 공유하도록 하면 가능합니다. /tmp 디렉터리를 공유하지 않고 사이드카 컨테이너에서 진단 도구를 사용하려고 하면 "호환되는 .NET 런타임을 실행하지 않음" 프로세스에 대한 오류가 발생합니다.

프로세스 네임스페이스 및 /tmp 디렉터리를 공유하지 않으려는 경우 많은 도구에서 고급 --diagnostic-port 명령줄 옵션도 지원합니다. 이렇게 하면 호스트 또는 사이드카의 파일 시스템 내에서 대상 프로세스의 진단 포트 경로를 직접 지정할 수 있습니다. 대상 컨테이너의 /tmp 디렉터리가 존재하려면 어딘가에 매핑이 되어야 하지만 호스트 또는 사이드카 /tmp와 공유할 필요는 없습니다.

참고 항목

호스트 또는 사이드카에서 진단 도구를 실행하는 경우에도 대상 컨테이너 내에서 리소스 사용량을 늘리는 작업을 수행하도록 대상 프로세스를 요청할 수 있습니다. dotnet-dump는 덤프를 수집할 때 대상 프로세스가 상당한 양의 가상 메모리를 사용할 수 있음을 관찰했습니다. 다른 도구들은 실제로 문제를 일으키는 것을 본 적은 없지만, 다소 작은 영향을 미칠 수 있습니다. 예를 들어 dotnet-trace 대상 프로세스에 이벤트 버퍼 dotnet-counters 를 할당하도록 요청하고 메트릭 데이터가 집계되는 작은 메모리 영역을 요청합니다. 메모리 제한이 너무 타이트하지 않은지 확인하기 위해 테스트하는 것을 권장합니다. 그렇지 않으면 도구를 실행할 때 OS가 컨테이너를 종료할 수 있습니다.

참고 항목

디스크에 덤프 파일을 쓸 때 dotnet-dump 출력 경로는 파일 시스템의 대상 프로세스 뷰 컨텍스트에서 해석됩니다. 호스트 또는 사이드카 컨테이너와 다를 가능성이 있습니다.

컨테이너에 PerfCollect 사용

이 도구의 적용 대상: ✔️ .NET Core 2.1 이상 버전

이 PerfCollect 스크립트는 CPU 샘플 또는 컨텍스트 스위치와 같은 커널 이벤트를 포함하는 성능 추적을 수집하는 데 유용합니다. 컨테이너에서 PerfCollect를 사용하는 경우 다음 요구 사항을 염두에 두세요.

  • PerfCollect에는 perf 도구를 실행하기 위한 추가 기능이 필요합니다. 필요한 최소 기능 집합은 PERFMON 및 SYS_PTRACE입니다. 일부 환경에는 SYS_ADMIN이 필요합니다. 필요한 기능을 갖춘 컨테이너를 시작합니다. 최소 집합이 작동하지 않으면 전체 집합을 사용해 보세요.

  • PerfCollect는 프로파일링하는 앱이 시작하기 전에 일부 환경 변수를 설정해야 합니다. 이러한 변수는 Dockerfile에서 또는 컨테이너를 시작할 때 설정할 수 있습니다. 이러한 변수는 일반적인 프로덕션 환경에서 설정하면 안 되므로 프로파일링될 컨테이너를 시작할 때 추가하는 것이 일반적입니다. PerfCollect에 필요한 두 변수는 다음과 같습니다.

    • DOTNET_PerfMapEnabled=1
    • DOTNET_EnableEventLog=1

참고 항목

.NET 7로 앱을 실행하는 경우 이전 환경 변수 외에 DOTNET_EnableWriteXorExecute=0도 설정해야 합니다.

참고 항목

.NET 6에서는 .NET 런타임 동작을 구성하는 환경 변수에 대해 DOTNET_ 대신 접두사 COMPlus_을 표준화했습니다. 그러나 COMPlus_ 접두사도 계속 작동합니다. 이전 버전의 .NET 런타임을 사용하는 경우에도 환경 변수에 COMPlus_ 접두사를 사용해야 합니다.

사이드카 컨테이너에서 PerfCollect 사용

한 컨테이너에서 PerfCollect을 실행하여 다른 컨테이너의 .NET 프로세스를 프로파일링하려는 경우에도 환경은 거의 동일합니다. 차이점은 다음과 같습니다.

  • 이전에 언급한 환경 변수( DOTNET_PerfMapEnabled, DOTNET_EnableEventLog)는 대상 컨테이너(PerfCollect를 실행하는 컨테이너가 아님)에 대해 설정해야 합니다.
  • PerfCollect를 실행하는 컨테이너에는 SYS_ADMIN 기능이 있어야 합니다(대상 컨테이너가 아님).
  • 두 컨테이너는 프로세스 네임스페이스를 공유해야 합니다.