dotnet-trace는 어떻게 시작할 때부터 모니터링을 시작합니까

개시하다
dotnet-trace는 v5.0.160202를 시작할 때부터 추적 로그를 수집할 수 있습니다.
이 기사에서 나는 어떻게 그 기능을 실현했는지 설명하고 싶다.
Dotnet-trace 소개
자세한 설명dotnet/diagnostics 문서 참조을 원하지만 주로 외부에서 이벤트소어스의 정보를 수집하는 데 사용되는 도구EventPipe를 사용한 구조입니다.
dotnettracev5.0.152202 이전에는 시작 과정에서 선택하고 수집하는 방법만 사용할 수 있습니다.
사용된 IPC 프로토콜은 연결할 때 PID가 필요하기 때문에 어쨌든 시작하지 않으면 알 수 없기 때문이다.
따라서 Diagnostic Ports라는 개념을 도입하여 시작할 때부터 감시할 수 있도록 했다.
Diagnostic Ports는
Diagnostic IPC Protocol은 PID를 포함하는 명명된 파이프나 유닉스 필드 플러그를 통해 통신하지만 위에서 설명한 바와 같이
기본적으로 사용되는 포트는 런타임 측면에서 PID를 포함하는 형식으로 작성됩니다.
다만 일부 시나리오에서는 이 구성이 불편한 부분이 있어 다음과 같은 동작을 추가했다.

환경 변수가 있는지 여부DOTNET_DiagnosticPorts

존재하면 시작할 때 동작을 멈추고 이름을 만든 파이프

까지 기다립니다

누군가가 지정한 이름의 파이프를 만들고 실행 시간에 연결이 성공하면 Advertise 메시지를 보냅니다

이후 이 연결을 사용하여 일반적인 EventPipe 교환

다음 그림과 같이

그림의 Advertise 메시지는 다음 형식입니다.
오프셋
크기
이름:
개요
0
8
magic
고정 데이터ADVR_V1\08
16
runtimeCookie
IPC ProcessInfo의 runtime Cookie와 동일한 GUID
24
8
PID
프로세스 ID(작은 끝 순서)
32
2
reserved
장래의 예약 구역(현재 항상 0)
ProcessInfodotnet/diagnostics의 IPC 프로토콜 문서 참조 정보
주의점
위의 프로그램은 현재 클라이언트 라이브러리 (Microsoft.Diagnostics.NETcore.Client) 에서 직접 실현할 수 없습니다.
... 때문에
1. 그림에 필요한 ResumeRuntime 메시지를 보내는 API는 인터넷입니다.
*소스https://github.com/dotnet/diagnostics/blob/5734230e3ee516339a4b0e4729def135027aa255/src/Microsoft.Diagnostics.NETCore.Client/DiagnosticsClient/DiagnosticsClient.cs#L155
2. Collector 사이드 파이프의 처리를 기다리는 것도 인터넷이다
* 소스는 https://github.com/dotnet/diagnostics/tree/v5.0.160202/src/Microsoft.Diagnostics.NETCore.Client/ReversedServer 근처
dotnet-trace에서 이 일대를 처리할 수 있는 것은 클라이언트 프로그램 라이브러리에서 인터넷 VisibleTo에 의해 처리되기 때문이다.
1에 관해서는 먼저 파이프 감청 처리에서 ResumeRuntime 메시지를 수동으로 보내는 것을 피하는 방법이 있다.
2에 관해서는 Advertise 메시지에 PID가 포함되어 있기 때문에 이 PID를 얻을 수 있으면 나중에 Diagnostic Client에 맡기면 통신할 수 있다.
이 점이 인터넷의 이유인데, 퍼블릭이 되면 규격 변경이 어려워지기 때문이라고 생각합니다.
dotnet-6.0의 타이밍에 대응하는 모습을 토론하는 거예요.이기 때문에 장래에 실현될 수 있을 것이다.
끝맺다
dotnet trace에서 시작할 때부터 이벤트소스의 로그를 얻을 수 있다는 것은 기쁜 일이다.
클라이언트 라이브러리 측이 이 일대를 처리할 수 있다면 꿈도 커질 것이다.