Share via

Monitorowanie i telemetria (tworzenie aplikacji Real-World w chmurze za pomocą platformy Azure)

  • Artykuł

Autor : Rick Anderson, Tom Dykstra

Pobierz naprawę projektu lub pobierz książkę elektroniczną

Książka elektroniczna Building Real World Cloud Apps with Azure (Tworzenie rzeczywistych aplikacji w chmurze za pomocą platformy Azure ) jest oparta na prezentacji opracowanej przez Scotta Guthrie. Wyjaśniono w nim 13 wzorców i rozwiązań, które mogą pomóc w pomyślnym tworzeniu aplikacji internetowych dla chmury. Aby uzyskać informacje na temat książki e-book, zobacz pierwszy rozdział.

Wiele osób polega na klientach, aby poinformować ich, kiedy aplikacja nie działa. To nie jest naprawdę najlepsze rozwiązanie w dowolnym miejscu, a zwłaszcza nie w chmurze. Nie ma gwarancji szybkiego powiadamiania, a po otrzymaniu powiadomienia często otrzymujesz minimalne lub mylące dane o tym, co się stało. Dzięki dobrym systemom telemetrii i rejestrowania możesz wiedzieć, co się dzieje z aplikacją, a gdy coś pójdzie nie tak, od razu się dowiesz i masz przydatne informacje dotyczące rozwiązywania problemów do pracy.

Kupowanie lub wynajmowanie rozwiązania telemetrycznego

Uwaga

Ten artykuł został napisany przed wydaniem usługi Application Insights . Usługa Application Insights to preferowane podejście do rozwiązań telemetrycznych na platformie Azure. Aby uzyskać więcej informacji, zobacz Konfigurowanie usługi Application Insights dla witryny internetowej ASP.NET .

Jedną z rzeczy, które doskonale dotyczą środowiska chmury, jest to, że naprawdę łatwo jest kupić lub wynająć drogę do zwycięstwa. Dane telemetryczne są przykładem. Bez dużego nakładu pracy można uzyskać naprawdę dobry system telemetrii, bardzo ekonomiczny. Istnieje kilka wspaniałych partnerów, którzy integrują się z platformą Azure, a niektóre z nich mają bezpłatne warstwy — dzięki czemu możesz uzyskać podstawowe dane telemetryczne za nic. Oto kilka z tych, które są obecnie dostępne na platformie Azure:

Program Microsoft System Center obejmuje również funkcje monitorowania.

Szybko przejdziemy przez proces konfigurowania usługi New Relic, aby pokazać, jak łatwo można użyć systemu telemetrii.

W portalu zarządzania platformy Azure utwórz konto usługi. Kliknij pozycję Nowy, a następnie kliknij pozycję Sklep. Zostanie wyświetlone okno dialogowe Wybieranie dodatku . Przewiń w dół i kliknij pozycję Nowy relikwi.

Wybierz dodatek

Kliknij strzałkę w prawo i wybierz odpowiednią warstwę usługi. W tej wersji demonstracyjnej użyjemy warstwy Bezpłatna.

Personalizowanie dodatku

Kliknij strzałkę w prawo, potwierdź "zakup", a nowy relikwi jest teraz wyświetlany jako dodatek w portalu.

Przeglądanie zakupu

Nowy dodatek Relic w portalu zarządzania

Kliknij pozycję Informacje o połączeniu i skopiuj klucz licencji.

Informacje o połączeniu

Przejdź do karty Konfigurowanie aplikacji internetowej w portalu, ustaw pozycję Monitorowanie wydajności na dodatek, a następnie ustaw listę rozwijaną Wybierz dodatek na nową relic. Następnie kliknij przycisk Zapisz.

Nowa relic na karcie Konfigurowanie

W programie Visual Studio zainstaluj pakiet NuGet New Relic w aplikacji.

Analiza deweloperów na karcie Konfigurowanie

Wdróż aplikację na platformie Azure i zacznij jej używać. Utwórz kilka zadań naprawy, aby zapewnić pewne działanie dla nowego relica do monitorowania.

Następnie wróć do strony New Relic na karcie Dodatki portalu i kliknij pozycję Zarządzaj. Portal wysyła Cię do portalu zarządzania New Relic przy użyciu logowania jednokrotnego do uwierzytelniania, aby nie trzeba było ponownie wprowadzać poświadczeń. Na stronie Przegląd przedstawiono różne statystyki wydajności. (Kliknij obraz, aby wyświetlić pełny rozmiar strony przeglądu).

Nowa karta Monitorowanie relic

Oto kilka statystyk, które można zobaczyć:

  • Średni czas odpowiedzi o różnych porach dnia.

    Czas odpowiedzi

  • Współczynniki przepływności (w żądaniach na minutę) w różnych porach dnia.

    Przepływność

  • Czas procesora CPU serwera poświęcony na obsługę różnych żądań HTTP.

    Czasy transakcji sieci Web

  • Czas procesora CPU spędzony w różnych częściach kodu aplikacji:

    Szczegóły śledzenia

  • Historyczne statystyki wydajności.

    Wydajność historyczna

  • Wywołania usług zewnętrznych, takich jak usługa Blob Service i statystyki dotyczące niezawodności i reakcji usługi.

    Usługi zewnętrzne

    Usługi zewnętrzne 2

    Usługa zewnętrzna

  • Informacje o tym, skąd pochodzi ruch aplikacji internetowej w USA lub gdzie się znajduje na świecie.

    Lokalizacja geograficzna

Można również skonfigurować raporty i zdarzenia. Możesz na przykład powiedzieć, że za każdym razem, gdy zaczniesz widzieć błędy, wyślij wiadomość e-mail do personelu pomocy technicznej w celu wysłania alertu do problemu.

Raporty

New Relic to tylko jeden przykład systemu telemetrii; Wszystkie te czynności można również uzyskać z innych usług. Piękno chmury polega na tym, że bez konieczności pisania kodu i w przypadku minimalnych lub bez wydatków nagle możesz uzyskać o wiele więcej informacji na temat sposobu używania aplikacji i tego, co klienci rzeczywiście doświadczają.

Dziennik na potrzeby szczegółowych informacji

Pakiet telemetrii to dobry pierwszy krok, ale nadal trzeba instrumentować własny kod. Usługa telemetrii informuje o wystąpieniu problemu i informuje o tym, co napotykają klienci, ale może nie dać Ci wglądu w to, co dzieje się w kodzie.

Nie chcesz mieć dostępu zdalnego do serwera produkcyjnego, aby zobaczyć, co robi twoja aplikacja. Może to być praktyczne, gdy masz jeden serwer, ale co z tym, gdy skalowano do setek serwerów i nie wiesz, które z nich trzeba zdalnie połączyć? Rejestrowanie powinno dostarczyć wystarczającej ilości informacji, które nigdy nie muszą być zdalnie na serwerach produkcyjnych do analizowania i debugowania problemów. Należy rejestrować wystarczającą ilość informacji, aby można było odizolować problemy wyłącznie za pośrednictwem dzienników.

Logowanie w środowisku produkcyjnym

Wiele osób włącza śledzenie w środowisku produkcyjnym tylko wtedy, gdy występuje problem i chce debugować. Może to powodować znaczne opóźnienie między czasem, w którym masz świadomość problemu, a czasem, w którym uzyskasz przydatne informacje dotyczące rozwiązywania problemów. A uzyskane informacje mogą nie być przydatne w przypadku sporadycznych błędów.

Co zalecamy w środowisku chmury, w którym magazyn jest tani, jest to, że zawsze pozostawiasz logowanie w środowisku produkcyjnym. W ten sposób, gdy występują już zarejestrowane błędy i masz dane historyczne, które mogą pomóc w analizie problemów, które rozwijają się w czasie lub występują regularnie w różnych momentach. Możesz zautomatyzować proces przeczyszczania w celu usunięcia starych dzienników, ale może się okazać, że skonfigurowanie takiego procesu jest droższe niż przechowywanie dzienników.

Dodatkowy koszt rejestrowania jest banalny w porównaniu z ilością czasu rozwiązywania problemów i pieniędzy, które można zaoszczędzić, mając wszystkie potrzebne informacje, gdy coś pójdzie nie tak. Następnie, gdy ktoś poinformuje Cię, że miał losowy błąd czasami około 8:00 ostatniej nocy, ale nie pamięta błędu, możesz łatwo dowiedzieć się, co to było problem.

Za mniej niż 4 USD miesięcznie można przechowywać 50 gigabajtów dzienników, a wpływ rejestrowania na wydajność jest banalny, o ile należy pamiętać o jednej rzeczy — aby uniknąć wąskich gardeł wydajności, upewnij się, że biblioteka rejestrowania jest asynchroniczna.

Rozróżnianie dzienników, które informują o dziennikach wymagających akcji

Dzienniki mają na celu informowanie (chcę coś wiedzieć) lub ACT (chcę, aby coś zrobić). Należy zachować ostrożność podczas zapisywania tylko dzienników ACT w przypadku problemów, które naprawdę wymagają od osoby lub zautomatyzowanego procesu podejmowania działań. Zbyt wiele dzienników ACT spowoduje hałas, co wymaga zbyt dużej ilości pracy, aby przesiewać przez to wszystko, aby znaleźć prawdziwe problemy. A jeśli dzienniki ACT automatycznie wyzwalają akcję, taką jak wysyłanie wiadomości e-mail do personelu pomocy technicznej, unikaj zezwalania na wyzwalanie tysięcy takich akcji przez pojedynczy problem.

W funkcji śledzenia .NET System.Diagnostics dzienniki można przypisać do poziomu Błąd, Ostrzeżenie, Informacje i Debugowanie/Pełne. Funkcję ACT można odróżnić od dzienników INFORM, rezerwując poziom błędu dla dzienników ACT i używając niższych poziomów dla dzienników INFORM.

Poziomy rejestrowania

Konfigurowanie poziomów rejestrowania w czasie wykonywania

Chociaż warto mieć zawsze włączone rejestrowanie w środowisku produkcyjnym, innym najlepszym rozwiązaniem jest zaimplementowanie struktury rejestrowania, która umożliwia dostosowanie w czasie wykonywania poziomu szczegółów rejestrowania, bez ponownego wdrażania lub ponownego uruchamiania aplikacji. Na przykład w przypadku korzystania z obiektu śledzenia można System.Diagnostics tworzyć dzienniki błędów, ostrzeżeń, informacji i debugowania/pełne. Zalecamy, aby zawsze rejestrować dzienniki błędów, ostrzeżeń i informacji w środowisku produkcyjnym. W celu rozwiązywania problemów w zależności od przypadku warto dynamicznie dodawać rejestrowanie debugowania/pełne.

Web Apps w Azure App Service mają wbudowaną obsługę zapisywania System.Diagnostics dzienników w systemie plików, usłudze Table Storage lub usłudze Blob Storage. Możesz wybrać różne poziomy rejestrowania dla każdego miejsca docelowego magazynu i zmienić poziom rejestrowania na bieżąco bez ponownego uruchamiania aplikacji. Obsługa usługi Blob Storage ułatwia uruchamianie zadań analizy usługi HDInsight w dziennikach aplikacji, ponieważ usługa HDInsight wie, jak bezpośrednio pracować z usługą Blob Storage.

rejestrowanie wyjątków

Nie należy po prostu umieszczać wyjątku. ToString() w kodzie rejestrowania. To pozostawia kontekstowe informacje. W przypadku błędów SQL pomija on numer błędu SQL. W przypadku wszystkich wyjątków uwzględnij informacje kontekstowe, sam wyjątek i wyjątki wewnętrzne, aby upewnić się, że udostępniasz wszystko, co będzie potrzebne do rozwiązywania problemów. Na przykład informacje kontekstowe mogą zawierać nazwę serwera, identyfikator transakcji i nazwę użytkownika (ale nie hasło lub jakiekolwiek wpisy tajne!).

Jeśli polegasz na każdym deweloperze, aby wykonać odpowiednie czynności z rejestrowaniem wyjątków, niektóre z nich nie będą. Aby upewnić się, że odbywa się to prawidłowo za każdym razem, skompiluj obsługę wyjątków bezpośrednio w interfejsie rejestratora: przekaż sam obiekt wyjątku do klasy rejestratora i zarejestruj dane wyjątków prawidłowo w klasie rejestratora.

Rejestrowanie wywołań do usług

Zdecydowanie zalecamy napisanie dziennika za każdym razem, gdy aplikacja wywołuje usługę, niezależnie od tego, czy jest to baza danych, czy interfejs API REST, czy dowolna usługa zewnętrzna. Uwzględnij w dziennikach nie tylko wskazanie powodzenia lub niepowodzenia, ale także czas uwzględnienia każdego żądania. W środowisku chmury często występują problemy związane z spowolnieniem, a nie całkowitymi awariami. Coś, co zwykle zajmuje 10 milisekund, może nagle zacząć brać sekundę. Gdy ktoś poinformuje Cię, że twoja aplikacja działa wolno, chcesz mieć możliwość przyjrzenia się nowemu relicowi lub dowolnej usłudze telemetrii, którą posiadasz i zweryfikujesz ich środowisko, a następnie chcesz mieć możliwość wyszukania własnych dzienników, aby dowiedzieć się więcej o tym, dlaczego działa wolno.

Korzystanie z interfejsu ILogger

Zalecamy wykonanie czynności podczas tworzenia aplikacji produkcyjnej w celu utworzenia prostego interfejsu ILogger i trzymać w nim kilka metod. Dzięki temu można łatwo zmienić implementację rejestrowania później i nie trzeba przechodzić przez cały kod, aby to zrobić. Możemy użyć System.Diagnostics.Trace klasy w całej aplikacji Fix It, ale zamiast tego używamy jej w ramach okładek w klasie rejestrowania, która implementuje protokół ILogger, i tworzymy wywołania metody ILogger w całej aplikacji.

W ten sposób, jeśli kiedykolwiek chcesz, aby rejestrowanie było bogatsze, możesz zastąpić System.Diagnostics.Trace dowolny mechanizm rejestrowania. Na przykład w miarę rozwoju aplikacji możesz zdecydować, że chcesz użyć bardziej kompleksowego pakietu rejestrowania, takiego jak NLog lub Blok aplikacji rejestrowania biblioteki przedsiębiorstwa. (Log4Net to kolejna popularna struktura rejestrowania, ale nie wykonuje asynchronicznego rejestrowania).

Jedną z możliwych przyczyn korzystania z platformy, takiej jak NLog, jest ułatwienie dzielenia danych wyjściowych rejestrowania na oddzielne magazyny danych o dużej wartości i dużej wartości. Pomaga to efektywnie przechowywać duże ilości danych INFORM, które nie muszą wykonywać szybkich zapytań względem, przy jednoczesnym zachowaniu szybkiego dostępu do danych ACT.

Rejestrowanie semantyczne

Aby uzyskać stosunkowo nowy sposób rejestrowania, który może wygenerować bardziej przydatne informacje diagnostyczne, zobacz Semantyczny blok aplikacji rejestrowania biblioteki przedsiębiorstwa (SLAB). Rozwiązanie SLAB używa funkcji śledzenia zdarzeń dla systemu Windows (ETW) i obsługi źródła zdarzeń na platformie .NET 4.5, aby umożliwić tworzenie bardziej ustrukturyzowanych i zapytań dzienników. Definiujesz inną metodę dla każdego typu rejestrowanego zdarzenia, co umożliwia dostosowanie zapisywanych informacji. Aby na przykład zarejestrować błąd SQL Database, możesz wywołać metodęLogSQLDatabaseError. W przypadku tego rodzaju wyjątku wiadomo, że kluczowym elementem informacji jest numer błędu, więc w podpisie metody można uwzględnić parametr numeru błędu i zarejestrować numer błędu jako osobne pole w rekordzie dziennika, który zapisujesz. Ponieważ liczba znajduje się w osobnym polu, można łatwiej i niezawodnie pobierać raporty na podstawie numerów błędów SQL, niż można było połączyć tylko numer błędu w ciągu komunikatu.

Rejestrowanie w aplikacji Fix It

Interfejs ILogger

Oto interfejs ILogger w aplikacji Fix It.

public interface ILogger
{
    void Information(string message);
    void Information(string fmt, params object[] vars);
    void Information(Exception exception, string fmt, params object[] vars);

    void Warning(string message);
    void Warning(string fmt, params object[] vars);
    void Warning(Exception exception, string fmt, params object[] vars);

    void Error(string message);
    void Error(string fmt, params object[] vars);
    void Error(Exception exception, string fmt, params object[] vars);

    void TraceApi(string componentName, string method, TimeSpan timespan);
    void TraceApi(string componentName, string method, TimeSpan timespan, string properties);
    void TraceApi(string componentName, string method, TimeSpan timespan, string fmt, params object[] vars);
}

Te metody umożliwiają zapisywanie dzienników na tych samych czterech poziomach obsługiwanych przez system.diagnostics. Metody TraceApi służą do rejestrowania wywołań usług zewnętrznych z informacjami o opóźnieniu. Można również dodać zestaw metod na poziomie Debug/Verbose.

Implementacja rejestratora interfejsu ILogger

Implementacja interfejsu jest naprawdę prosta. Zasadniczo po prostu wywołuje standardowe metody System.Diagnostics . Poniższy fragment kodu przedstawia wszystkie trzy metody Informacji i jedną z pozostałych.

public class Logger : ILogger
{
    public void Information(string message)
    {
        Trace.TraceInformation(message);
    }

    public void Information(string fmt, params object[] vars)
    {
        Trace.TraceInformation(fmt, vars);
    }

    public void Information(Exception exception, string fmt, params object[] vars)
    {
        var msg = String.Format(fmt, vars);
        Trace.TraceInformation(string.Format(fmt, vars) + ";Exception Details={0}", exception.ToString());
    }

    public void Warning(string message)
    {
        Trace.TraceWarning(message);
    }

    public void Error(string message)
    {
        Trace.TraceError(message);
    }

    public void TraceApi(string componentName, string method, TimeSpan timespan, string properties)
    {
        string message = String.Concat("component:", componentName, ";method:", method, ";timespan:", timespan.ToString(), ";properties:", properties);
        Trace.TraceInformation(message);
    }
}

Wywoływanie metod ILogger

Za każdym razem, gdy kod w aplikacji Fix It przechwytuje wyjątek, wywołuje metodę ILogger , aby zarejestrować szczegóły wyjątku. I za każdym razem, gdy wykonuje wywołanie bazy danych, usługi Blob Service lub interfejsu API REST, uruchamia stoper przed wywołaniem, zatrzymuje stoper, gdy usługa zwraca, i rejestruje czas, który upłynął wraz z informacjami o powodzeniu lub niepowodzeniu.

Zwróć uwagę, że komunikat dziennika zawiera nazwę klasy i nazwę metody. Dobrym rozwiązaniem jest upewnienie się, że komunikaty dziennika identyfikują, która część kodu aplikacji je napisała.

public class FixItTaskRepository : IFixItTaskRepository
{
    private MyFixItContext db = new MyFixItContext();
    private ILogger log = null;

    public FixItTaskRepository(ILogger logger)
    {
        log = logger;
    }

    public async Task<FixItTask> FindTaskByIdAsync(int id)
    {
        FixItTask fixItTask = null;
        Stopwatch timespan = Stopwatch.StartNew();

        try
        {
            fixItTask = await db.FixItTasks.FindAsync(id);
            
            timespan.Stop();
            log.TraceApi("SQL Database", "FixItTaskRepository.FindTaskByIdAsync", timespan.Elapsed, "id={0}", id);
        }
        catch(Exception e)
        {
            log.Error(e, "Error in FixItTaskRepository.FindTaskByIdAsynx(id={0})", id);
        }

        return fixItTask;
    }

Więc teraz za każdym razem, gdy aplikacja Fix It wykonała wywołanie SQL Database, możesz zobaczyć wywołanie, metodę, która ją nazwała, i dokładnie ile czasu zajęło.

zapytanie SQL Database w dziennikach

Zrzut ekranu przedstawiający właściwości jednostki Edytuj i jak powinna wyglądać każda właściwość w celu pomyślnej aktualizacji z upływem czasu.

Jeśli przejdziesz do przeglądania dzienników, zobaczysz, że wywołania bazy danych czasu są zmienne. Te informacje mogą być przydatne: ponieważ aplikacja rejestruje wszystkie te informacje, można analizować historyczne trendy w sposobie działania usługi bazy danych w czasie. Na przykład usługa może być szybka przez większość czasu, ale żądania mogą zakończyć się niepowodzeniem lub odpowiedzi mogą spowolnić w określonych porach dnia.

Możesz to zrobić w usłudze Blob Service — za każdym razem, gdy aplikacja przekaże nowy plik, istnieje dziennik i zobaczysz dokładnie, jak długo trwało przekazywanie każdego pliku.

Dziennik przekazywania obiektów blob

To tylko kilka dodatkowych wierszy kodu do pisania za każdym razem, gdy wywołujesz usługę, a teraz, gdy ktoś mówi, że napotkał problem, wiesz dokładnie, co to było, czy był to błąd, czy nawet jeśli po prostu działa wolno. Możesz wskazać źródło problemu bez konieczności zdalnego na serwerze lub włączać rejestrowanie po wystąpieniu błędu i mieć nadzieję na jego ponowne utworzenie.

Wstrzykiwanie zależności w aplikacji Fix It

Możesz się zastanawiać, jak konstruktor repozytorium w powyższym przykładzie pobiera implementację interfejsu rejestratora:

public class FixItTaskRepository : IFixItTaskRepository
{
    private MyFixItContext db = new MyFixItContext();
    private ILogger log = null;

    public FixItTaskRepository(ILogger logger)
    {
        log = logger;
    }

Aby połączyć interfejs z implementacją, aplikacja używa iniekcji zależności (DI) z funkcją AutoFac. Di umożliwia używanie obiektu opartego na interfejsie w wielu miejscach w całym kodzie i musi określać tylko w jednym miejscu implementację, która jest używana podczas tworzenia wystąpienia interfejsu. Ułatwia to zmianę implementacji: na przykład możesz zastąpić rejestrator System.Diagnostics rejestratorem NLog. Ewentualnie w przypadku testów automatycznych warto zastąpić pozorną wersję rejestratora.

Aplikacja Fix It używa di we wszystkich repozytoriach i wszystkich kontrolerach. Konstruktory klas kontrolerów uzyskują interfejs ITaskRepository w taki sam sposób, w jaki repozytorium pobiera interfejs rejestratora:

public class DashboardController : Controller
{
    private IFixItTaskRepository fixItRepository = null;

    public DashboardController(IFixItTaskRepository repository)
    {
        fixItRepository = repository;
    }

Aplikacja używa biblioteki AutoFac DI do automatycznego udostępniania wystąpień repozytorium zadań i rejestratora dla tych konstruktorów.

public class DependenciesConfig
{
    public static void RegisterDependencies()
    {
        var builder = new ContainerBuilder();

        builder.RegisterControllers(typeof(MvcApplication).Assembly);
        builder.RegisterType<Logger>().As<ILogger>().SingleInstance();

        builder.RegisterType<FixItTaskRepository>().As<IFixItTaskRepository>();
        builder.RegisterType<PhotoService>().As<IPhotoService>().SingleInstance();
        builder.RegisterType<FixItQueueManager>().As<IFixItQueueManager>();

        var container = builder.Build();
        DependencyResolver.SetResolver(new AutofacDependencyResolver(container));
    }
}

Ten kod zasadniczo mówi, że w dowolnym miejscu konstruktor potrzebuje interfejsu ILogger , przekaż wystąpienie klasy Logger i za każdym razem, gdy potrzebuje interfejsu IFixItTaskRepository , przekaż wystąpienie klasy FixItTaskRepository .

AutoFac to jedna z wielu struktur wstrzykiwania zależności, których można użyć. Innym popularnym rozwiązaniem jest unity, które jest zalecane i obsługiwane przez wzorce i praktyki firmy Microsoft.

Wbudowana obsługa rejestrowania na platformie Azure

Platforma Azure obsługuje następujące rodzaje rejestrowania dla Web Apps w Azure App Service:

  • Śledzenie System.Diagnostics (można włączać i wyłączać i ustawiać poziomy na bieżąco bez ponownego uruchamiania lokacji).
  • Zdarzenia systemu Windows.
  • Dzienniki usług IIS (HTTP/FREB).

Platforma Azure obsługuje następujące rodzaje rejestrowania w Cloud Services:

  • Śledzenie System.Diagnostics.
  • Liczniki wydajności.
  • Zdarzenia systemu Windows.
  • Dzienniki usług IIS (HTTP/FREB).
  • Monitorowanie katalogów niestandardowych.

Aplikacja Fix It używa śledzenia System.Diagnostics. Aby włączyć rejestrowanie System.Diagnostics w aplikacji internetowej, wystarczy przerzucić przełącznik w portalu lub wywołać interfejs API REST. W portalu kliknij kartę Konfiguracja witryny i przewiń w dół, aby wyświetlić sekcję Diagnostyka aplikacji . Możesz włączyć lub wyłączyć rejestrowanie i wybrać odpowiedni poziom rejestrowania. Na platformie Azure można zapisywać dzienniki w systemie plików lub na koncie magazynu.

Diagnostyka aplikacji i diagnostyka lokacji na karcie Konfigurowanie

Po włączeniu logowania na platformie Azure dzienniki będą widoczne w oknie Dane wyjściowe programu Visual Studio podczas ich tworzenia.

Menu dzienników przesyłania strumieniowego

Menu Dzienniki przesyłania strumieniowego2

Możesz również mieć dzienniki zapisywane na koncie magazynu i wyświetlać je za pomocą dowolnego narzędzia, które może uzyskać dostęp do usługi Tabel usługi Azure Storage, takiej jak Eksplorator serwera w programie Visual Studio lub Eksplorator usługi Azure Storage.

Dzienniki w Eksploratorze serwera

Podsumowanie

Naprawdę proste jest zaimplementowanie gotowego systemu telemetrii, instrumentowania rejestrowania we własnym kodzie i konfigurowania rejestrowania na platformie Azure. Jeśli masz problemy z produkcją, połączenie systemu telemetrii i dzienników niestandardowych pomoże ci szybko rozwiązać problemy, zanim staną się poważnymi problemami dla klientów.

W następnym rozdziale przyjrzymy się sposobom obsługi błędów przejściowych, aby nie stały się problemami produkcyjnymi, które należy zbadać.

Zasoby

Więcej informacji zawierają poniższe zasoby.

Dokumentacja dotyczy głównie danych telemetrycznych:

Dokumentacja głównie dotycząca rejestrowania:

Dokumentacja dotyczy głównie rozwiązywania problemów:

Filmy wideo:

  • FailSafe: tworzenie skalowalnych, odpornych Cloud Services. Dziewięć części serii Ulrich Homann, Marc Mercuri i Mark Simms. Przedstawia ogólne koncepcje i zasady architektury w bardzo dostępny i ciekawy sposób, z historiami pochodzącymi z zespołu doradczego klienta firmy Microsoft (CAT) z rzeczywistymi klientami. Odcinki 4 i 9 dotyczą monitorowania i telemetrii. Odcinek 9 zawiera omówienie usług monitorowania MetricsHub, AppDynamics, New Relic i PagerDuty.
  • Tworzenie dużych: wnioski wyciągnięte z klientów platformy Azure — część II. Mark Simms mówi o projektowaniu pod kątem awarii i instrumentacji wszystkiego. Podobnie jak w przypadku serii Failsafe, ale zawiera bardziej szczegółowe instrukcje.

Przykładowy kod:

WsteczDalej