Aspnetcore: EventSource? DiagnosticSource? 양자 모두?

@rynowak- 우리가 공유 할 수있는 지침이 있습니까?

내부적으로 여러 번 반복 한 몇 가지 빠른 생각이지만 외부 적으로는 확실하지 않습니다.

EventSource

EventSource의 모든 사용은 LTTNG 또는 ETW와 같은 프로세스 외 로깅 메커니즘의 사용을 의미한다고 가정합니다. EventSource는 나중에 볼 충실도가 낮은 일부 데이터 포인트를 실행하고 어떤 종류의 통계 또는 요약으로 컴파일 할 가능성이 더 큰 경우에 유용합니다. EventSource의 일반적인 용도는 이벤트를 파일 (ETW)로 파이프 한 다음 사후 분석을 수행하는 데 사용하기 때문에 충실도가 낮습니다. PerfView와 같은 EventSource의 데이터를 보는 도구는 일부 이벤트 (JIT, GC)에 대한 특별한 지식을 가지고 있지만 작성하는 이벤트에 대해서는 일반보기를 표시합니다. 일반보기 또는 데이터 요약 / 표를 표시하는 것은 모두 단순한 유형이기 때문에 작동합니다. 물론 특수 도구를 만들 수 있지만 일반적인 경우는 PerfView와 같은 것을 사용하는 것입니다.

다음 진술은 분명해 보일 것이지만 그것을 언급하는 이유는 곧 분명해질 것입니다. EventSource를 사용하면 발생하는 이벤트의 해석이 미리 결정됩니다. 기록하려는 모든 데이터는 구성 요소 작성자가 지정하며 일반적으로 이벤트 이름과 관련된 고정 된 의미를 갖습니다. EventSource를 사용하면 "4096 바이트 데이터 읽기"또는 "5.6ms 내에로드 된 파일"과 같은 말을 자주합니다. 이 작은 사실 진술은 "파일 입출력을 수행하는 데 150ms 소요"와 같은 요약으로 컴파일하거나 특이 치인 경우 구체적으로 드릴 할 수 있습니다.

DiagnosticSource

DiagnosticSource의 모든 사용이 '플러그인'또는 데이터를 의미있는 덩어리로 추출 할 다른 로깅 시스템에 의해 프로세스 내에서 수행되고 있다고 가정합니다. DiagnosticSource는 애플리케이션 상태의 전체 컨텍스트 를 리스너에게 전달하고 해당 리스너가 애플리케이션의 상태에 대한 액세스를 기반으로 자체 해석을 추가 할 때 유용합니다. 또한 DiagnosticSource에는 기본 로깅 형식이 없으며 데이터 포인트에 대한 일반적인 이해도 없습니다 (일반적으로 단순한 유형이 아니기 때문에). 사용자가보고 싶은 것을 생성하려면 추가 시스템이 필요합니다.

DiagnosticSource 이벤트는 더 덩어리 져서 "요청을 처리하려고합니다."또는 "미들웨어에서 발생한 예외를 포착했습니다"와 같은 내용을 말합니다. 이것들은 여전히 ​​사실의 진술이지만 범위는 훨씬 더 큽니다. 도구는 풍부한 컨텍스트에 액세스 할 수 있으므로 컨텍스트에 따라 의미있는 정보를 자유롭게 캡처 할 수 있습니다. 궁극적으로 Application Insights와 같은 도구로 캡처 한 정보 집합은 ASP.NET 팀에서 정의하지 않습니다. 우리는 그들에게 우리가 가진 모든 맥락을 제공하고 그들이 중요하다고 생각하는 것을 포착합니다.

브리지를 통해 DiagnosticSource 데이터를 EventSource로 파이프 할 수도 있습니다. 개인적으로이 작업을 수행 한 것은 아니지만 일부 장소에서 필요한 진단 코드의 양을 두 배로 늘리지 않으려 고합니다. https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs#L22 나는 당신이 DiagnosticSource를 모든 EventSource와 동일한 장소. 나는 이것을 활용하는 전략이 어떻게 진행 될지 확신하지 못합니다.

우리에게이 영역은 몇 번 변경되었습니다. 여기에서 Glimpse와 파트너 관계를 맺기 시작했고 결국 Application Insights와 파트너 관계를 맺었습니다. 그 과정에서 진단 소스 위에 몇 가지 다른 것들이 구축되었지만 현재 다른 도구의 상태가 무엇인지 잘 모르겠습니다.

우리의 계획

EventSource 또는 DiagnosticSource에 대한 더 큰 전략에 대해 말할 수는 없지만 제가 생각하는 방식과 대부분의 팀이 우리의 접근 방식을 어떻게 보는지 대답 할 수 있습니다. EventSource의 대체물로 DiagnosticSource를 만들지 않았습니다. 제 생각에는 다른 소비자와 시나리오 세트를 제공합니다.

많은 가치를 추가 할 것으로 생각되는 곳에 진단 소스 이벤트를 추가합니다. 이들 중 일부는 다른 사람 이 진단을 구축 할 수있는 확장 성과 같기 때문에 정말 먼 길을갑니다. 호스팅에는 3 ~ 5 개의 진단 소스 포인트가 있고 MVC는 10 개에 가까워 질 것입니다. 현재 추적중인 장소가 더 있는지 확실하지 않습니다. 누군가가 진정으로 필요하다면 우리는 그것을 고려할 것입니다.

이벤트 소스를 구축하고 있습니다. 이는 현장 지원 엔지니어가 잘 ​​알고있는 것으로, 일반적으로 Microsoft 팀의 성능 분석에서 중요한 부분입니다. 우리는 여전히 성능 카운터 부재로 인한 공백을 해결하기 위해 노력하고 있습니다. .NET 팀은 EventCounters (EventSource 위에 빌드 됨)를 적절한 대체품으로 만들기 위해 노력하고 있습니다. ASP.NET 팀이 EventSource에 더 많은 투자를하는 것이 지연되는 주된 이유는 비 Windows에 대한 전략이 한동안 명확하지 않았기 때문입니다. 우리는 EventSource는 * nix에서 스크립트 플랫폼을 될 수 없습니다 경우 미래에 다른 추가적인 일을 구축하지 않도록하고 싶었다. 그것은 해결되었습니다.

여기에 좋은 문서가 있습니다 : https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md#instrumenting -with-diagnosticsourcediagnosticlistener 이 분야의 전략을 책임지고 있습니다.

당신을 위해

음, 둘 다 또는 둘 다 할 수있는 것 같습니다. 나는 당신이 무엇을하고 있는지 잘 모르기 때문에 다음은 몇 가지 일반적인 조언입니다.

먼저 소비자가 누구인지 생각하십시오. 당신을위한 것입니까? (perf) 애플리케이션 개발자를위한 것입니까? (디버깅 및 문제 해결) 도구 작성자를위한 것입니까? 도구가 사후 분석 또는 앱 내부에서 실행되고 있습니까?

둘째, 계측 할 장소의 수와 의미가 있다고 생각하는 데이터의 종류에 대해 생각해보십시오. 소비자는이 데이터를 어떻게 이해하고 해석합니까? 개별 데이터 포인트가 의미가 있습니까? 아니면 데이터를 집계해야합니까?

장기간 업데이트되지 않은 '토론'이슈는 주기적으로 마감합니다.

불편을 드려 죄송합니다. 여전히 문제가 발생하는 경우 업데이트 된 정보로 새 문제를 기록해 주시면 조사하겠습니다.