2016-02-10 25 views
8

Używam pierwszej próbki ServiceFabric (Preview version 1.4.87): https://azure.microsoft.com/en-us/documentation/articles/service-fabric-create-your-first-application-in-visual-studio/, aby utworzyć usługę stanową i chociaż próbka działa poprawnie, nie widzę Informacje dziennika wyjścia ETW w oknie diagnostyki.Próbki Azure ServiceFabric niezalogowane do ETW

Wywołania do logowania są wykonywane na , ale gdy uruchomiona jest ta metoda (zaimplementowana w ServiceEventSource.cs), wywołanie funkcji this.IsEnabled() zwraca wartość false, więc nie są zapisywane żadne diagnostyki. Jeśli pomijam wywołanie IsEnabled() podczas debugowania, nadal nic nie jest zapisywane w oknie diagnostycznym, które zawiera tylko wiadomości startowe aplikacji.

Dostawców skonfigurowane w diagnostyce są te domyślne:

Microsoft-ServiceFabric-Actors 
Microsoft-ServiceFabric-Services 
cbd93bc2-71e5-4566-b3a7-595d8eeca6e8:5:0x4000000000000000 

Dodałem Microsoft ServiceFabric na tej liście, ale to po prostu staje mi znacznie więcej rejestrowanie ale nadal nie moje wiadomości wyjściowych.

Uruchomiłem również PerfView, a następnie patrząc na dostępnych dostawców, pierwsze dwa wyżej nie istnieją: Microsoft-ServiceFabric-Actors i Microsoft-ServiceFabric-Services.

Każdy pomysł? Wydaje się, że jest to albo czysty błąd ETW, albo jakiś błąd ServiceFabric w konfiguracji, z być może nieprawidłową specyfikacją Providera w oknie diagnostyki.

Używam Win10, VS2015 Enterprise x64.

[Edytuj] Zadzwoń pod numer ServiceEventSource.Current.ServiceTypeRegistered(Process.GetCurrentProcess().Id, typeof(MyStatefulService).Name) w pliku Program.cs również niczego nie zapisuj. Jedyne wiadomości mam to:

Service Created: Service fabric:/MyApplication/MyStatefulService partition 9505f2b3-dee5-4ea7-96b7-c861407b5283 of ServiceType MyStatefulServiceType created in Application fabric:/MyApplication ApplicationType MyApplicationType. 

RunAsync has been invoked for a stateful service replica. Application Type Name: MyApplicationType, Application Name: fabric:/MyApplication, Service Type Name: MyStatefulServiceType, Service Name: fabric:/MyApplication/MyStatefulService, Partition Id: 9505f2b3-dee5-4ea7-96b7-c861407b5283, Replica Id: 130996049833056865", 

The Resource Balancer completed the Creation phase and consequently issued the action -- Add on Service -- fabric:/MyApplication/MyStatefulService Partition -- 9505f2b3-dee5-4ea7-96b7-c861407b5283 with (if relevant) SourceNode -- N/A and TargetNode -- Node.2. 

(powtórz dla pozostałych węzłów)

+2

Czy kiedykolwiek zastanawiałeś się, jak uzyskać je widoczne w PerfView? Też mam tę kwestię w tym wniosku. –

Odpowiedz

14

Aby zobaczyć wydarzenia z EventSource musisz dodać swoją nazwę na liście dostawców w oknie Diagnostics. Spójrz na definicję ServiceEventSource, będzie ona zawierała atrybut [EventSource (Name = "xxx")]. To jest nazwa ("xxx"), którą musisz znaleźć na liście dostawców.

Visual Studio zwykle zadba o automatyczne wykrywanie Źródeł Zdarzeń w Twoim Rozwiązaniu po uruchomieniu Diagnostycznego systemu Windows; nie wiesz, dlaczego to nie działa, ale dodanie go ręcznie powinno załatwić sprawę.

+0

Dzięki, to było to. Podejrzewam, że to jakiś błąd związany z zestawem SDK 2.8.2. Próbowałem go na innym komputerze z 2.8.1 i dostawca jest poprawnie dodany w Visual Studio. –

+0

Upewnij się, że nazwy źródeł zdarzeń są wymienione na liście dostawców zgodnie z sugestią tutaj podczas odsłuchiwania zdarzeń ETW z hostowanej aplikacji usług tekstowych Azure - [Używanie programu Visual Studio do odsłuchiwania zdarzeń ETW usługi Azure Service Fabric] (https: // azure .microsoft.com/pl-us/documentation/articles/service-fabric-diagnostics-how-to-monitor-and-diagnose-services-lokalnie/# comment-2638038977) –

+0

Oprócz ręcznego dodawania naszego własnego dostawcy ETW, należy zamknąć zakładkę Zdarzenia diagnostyczne otwierane przez debugger, a następnie otworzyć nową z menu Windows, a następnie wprowadzić dostawcę (-ów) ETW. –

0

Napotkano ten problem po zreorganizowaniu rozwiązania. Przeniosłem projekty serwisowe do folderu rozwiązania. I wtedy właśnie Przeglądarka zdarzeń diagnostycznych przestała otrzymywać wiadomości z moich usług.

Po przeniesieniu projektów do poziomu podstawowego rozwiązania Visual Studio automatycznie doda nazwy źródeł zdarzeń do listy dostawców ETW.

Ten błąd wydaje się być rozwiązany za pomocą VS 2017 i/lub Azure Service Fabric SDK 2.5.216.0.