Tworzę aplikacje .NET 4.5, aby emitować zdarzenia ETW za pomocąEventSource klasa. Celem jest umożliwienie przechwytywania niektórych z tych zdarzeń (zdarzeń poziomu błędu) w celu rejestrowania błędów.

Po przeczytaniu i testowaniu obawiam się o niezawodność tego podejścia do rejestrowania błędów, szczególnie w odniesieniu do możliwości upuszczenia lub braku zdarzeń. Jeśli moje rejestrowanie błędów nie działa, potrzebuję zamknięcia aplikacji (w moim przypadku niebezpieczne jest uruchamianie z niezgłoszonymi błędami). Podczas korzystania z ETW iEventSource, jak mogę być pewien, że moje błędy są prawidłowo rejestrowane?

Oczywiście część odpowiedzi będzie zależeć od tego, co słucha się wydarzeń. W moim przypadku planuję użyć „bloku aplikacji rejestrowania semantycznego” z najnowszej biblioteki MS Enterprise.

Oto jedno źródło, w którym Microsoft mówi o możliwych przyczynach pominiętych wydarzeń:O śledzeniu zdarzeń

Tam wymieniają te możliwe przyczyny brakujących zdarzeń

Całkowita wielkość zdarzenia jest większa niż 64 KB. Obejmuje to nagłówek ETW plus dane lub ładunek. Użytkownik nie ma kontroli nad tymi brakującymi zdarzeniami, ponieważ rozmiar zdarzenia jest skonfigurowany przez aplikację.

Rozmiar bufora ETW jest mniejszy niż całkowita wielkość zdarzenia. Użytkownik nie ma kontroli nad brakującymi zdarzeniami, ponieważ rozmiar zdarzenia jest konfigurowany przez aplikację rejestrującą zdarzenia.

W przypadku rejestrowania w czasie rzeczywistym konsument w czasie rzeczywistym nie zajmuje się wystarczająco szybko zdarzeniami lub nie jest w ogóle obecny, a plik kopii zapasowej wypełnia się. Może to wynikać z tego, że usługa Dziennik zdarzeń jest zatrzymywana i uruchamiana podczas rejestrowania zdarzeń. Użytkownik nie ma kontroli nad tymi brakującymi zdarzeniami.

Podczas logowania do pliku dysk jest zbyt wolny, aby nadążyć za szybkością rejestrowania.

Aby sprawdzić, czy obawy te zostały w jakiś sposób złagodzone przy użyciu klasy EventSource (na przykład, czy w jakiś sposób obcina duże ładunki), przeprowadziłem kilka testów. Próbowałem logować długie łańcuchy i dla mnie nie powiodło się między 30 000 a 35 000 znaków (w zgodzie z ładunkiem maksymalnym 64 KB). Po prostu po cichu nie robi nic z tego, co mogę powiedzieć o zbyt dużych łańcuchach, żadnych zdarzeń w moim dzienniku blokowania aplikacji semantycznego rejestrowania. Wydarzenia przed i po zostały napisane jak zwykle.

Więc za każdym razem, gdy w moim ładunku znajduję się ciąg znaków, muszę przekazać go przez jakiś obciskacz? Czy muszę ręcznie unikać generowania zdarzeń „zbyt szybko” (i jak to byłoby możliwe)?

Wzorce i praktyki Microsoft mają doprowadzić nas do dobrych ... wzorców i praktyk ... więc może po prostu czegoś tutaj brakuje.

Aktualizacja:

Widocznie zauważono w aplikacji konsumującej warunek „Zbyt szybkie zdarzenia”. Otrzymałem to dzisiaj po raz pierwszy:

Poziom: Ostrzeżenie, komunikat: Niektóre zdarzenia zostaną utracone z powodu przekroczenia buforu lub opóźnień synchronizacji schematu w sesji śledzenia: Microsoft-SemanticLogging-Etw-svcRuntime

A następnie podczas zamykania sesji:

Poziom: Ostrzeżenie, komunikat: W sesji śledzenia „Microsoft-SemanticLogging-Etw-svcRuntime” wykryto utratę 1 zdarzeń.

Aktualizacja 2:

ThePrzewodnik dla programistów bibliotek korporacyjnych opisuje zachowanie, o którym właśnie wspomniałem.

Należy monitorować komunikaty dziennika generowane przez blok aplikacji semantycznego rejestrowania w poszukiwaniu jakichkolwiek oznak przepełnienia buforów i utraconych wiadomości. Na przykład komunikaty dziennika z identyfikatorami zdarzeń 900 i 901 wskazują, że wewnętrzne bufory zlewu uległy przepełnieniu; w scenariuszu poza procesem identyfikatory zdarzeń 806 i 807 wskazują, że bufory ETW zostały przepełnione. Możesz zmodyfikować opcje konfiguracji buforowania dla zlewów, aby zmniejszyć ryzyko przepełnienia buforów typowymi obciążeniami.

Moje pytanie pozostaje, czy mogę korzystać z rejestrowania semantycznego, upewniając się, że moja aplikacja nie działa, jeśli zostaną usunięte błędy? Normalne zdarzenia śledzenia mogą zostać usunięte ...

Moją obecną myślą jest rejestrowanie „krytycznych” błędów za pomocą oddzielnej klasy przy użyciu staromodnych technik rejestrowania i utrzymywanie mniej krytycznych błędów (a także zdarzeń typu debugowania) przechodzących przez potok ETW. To nie byłoby takie złe ... Mogę zamieścić to jako rozwiązanie, jeśli nie mogę znaleźć lepszej propozycji.

Aktualizacja 3:

Ostrzeżenie „brakujące zdarzenia”, które otrzymałem, nie miało nic wspólnego z przepełnieniem bufora, okazuje się, że jest to komunikat, który otrzymasz po przekazaniu wartości nullstring jako wartość ładunku.