Rejestrowanie aplikacji
Instrumentacja kodu jest nie tylko sposobem uzyskiwania szczegółowych informacji o użytkownikach, ale także jedynym sposobem, w jaki możesz wiedzieć, czy coś jest nie tak w aplikacji, i zdiagnozować, co należy naprawić. Chociaż technicznie istnieje możliwość połączenia debugera z usługą produkcyjną, nie jest to powszechna praktyka. Dlatego posiadanie szczegółowych danych instrumentacji jest ważne.
Niektóre produkty automatycznie instrumentuje kod. Chociaż te rozwiązania mogą działać dobrze, instrumentacja ręczna jest prawie zawsze wymagana do konkretnej logiki biznesowej. W końcu musisz mieć wystarczającą ilość informacji, aby śledczo debugować aplikację. Aplikacje usługi Service Fabric można instrumentować przy użyciu dowolnej struktury rejestrowania. W tym dokumencie opisano kilka różnych metod instrumentacji kodu, a kiedy wybrać inne podejście.
Aby zapoznać się z przykładami dotyczącymi używania tych sugestii, zobacz Dodawanie rejestrowania do aplikacji usługi Service Fabric.
Application Insights SDK
Usługa Application Insights oferuje zaawansowaną integrację z usługą Service Fabric. Użytkownicy mogą dodawać pakiety nuget usługi AI Service Fabric i odbierać dane oraz dzienniki utworzone i zbierane w Azure Portal. Ponadto zachęcamy użytkowników do dodawania własnych danych telemetrycznych w celu diagnozowania i debugowania aplikacji oraz śledzenia, które usługi i części aplikacji są najczęściej używane. Klasa TelemetryClient w zestawie SDK udostępnia wiele sposobów śledzenia telemetrii w aplikacjach. Zapoznaj się z przykładem instrumentowania i dodawania usługi Application Insights do aplikacji w naszym samouczku na potrzeby monitorowania i diagnozowania aplikacji .NET
EventSource
Podczas tworzenia rozwiązania usługi Service Fabric na podstawie szablonu w programie Visual Studio jest generowana klasa pochodna eventsource (ServiceEventSource lub ActorEventSource). Zostanie utworzony szablon, w którym można dodawać zdarzenia dla aplikacji lub usługi. Nazwa źródła zdarzeńmusi być unikatowa i powinna zostać zmieniona na domyślny ciąg szablonu MyCompany-solution-project<<>>. Posiadanie wielu definicji źródła zdarzeń , które używają tej samej nazwy, powoduje problem w czasie wykonywania. Każde zdefiniowane zdarzenie musi mieć unikatowy identyfikator. Jeśli identyfikator nie jest unikatowy, wystąpi błąd środowiska uruchomieniowego. Niektóre organizacje wstępnie przypiszą zakresy wartości dla identyfikatorów, aby uniknąć konfliktów między oddzielnymi zespołami deweloperów. Aby uzyskać więcej informacji, zobacz blog Vance lubdokumentację MSDN.
rejestrowanie ASP.NET Core
Ważne jest, aby starannie zaplanować instrumentację kodu. Odpowiedni plan instrumentacji może pomóc uniknąć potencjalnie destabilizacji bazy kodu, a następnie konieczności przywrócenia kodu. Aby zmniejszyć ryzyko, możesz wybrać bibliotekę instrumentacji, na przykład Microsoft.Extensions.Logging, która jest częścią usługi Microsoft ASP.NET Core. ASP.NET Core ma interfejs ILogger, którego można użyć z wybranym dostawcą, jednocześnie minimalizując wpływ na istniejący kod. Możesz użyć kodu w ASP.NET Core w systemach Windows i Linux oraz w pełnej .NET Framework, aby kod instrumentacji był ustandaryzowany.
Następne kroki
Po wybraniu dostawcy rejestrowania do instrumentacji aplikacji i usług dzienniki i zdarzenia muszą zostać zagregowane przed wysłaniem ich do dowolnej platformy analizy. Przeczytaj o usługach Application Insights i EventFlow , aby lepiej zrozumieć niektóre z zalecanych opcji usługi Azure Monitor.