Rozwiązywanie problemów za pomocą Diagnostyki Azure

W tym artykule opisano informacje dotyczące rozwiązywania problemów, które mają zastosowanie do używania Diagnostyka Azure. Aby uzyskać więcej informacji na temat diagnostyki, zobacz Omówienie diagnostyki Azure.

Składniki logiczne

Składniki to:

• Uruchamianie wtyczki diagnostycznej (DiagnosticsPluginLauncher.exe): uruchamia rozszerzenie diagnostyki. Działa jako proces punktu wejścia.
• Wtyczka diagnostyki (DiagnosticsPlugin.exe): konfiguruje, uruchamia i zarządza okresem istnienia agenta monitorowania. Jest to główny proces uruchamiany przez moduł uruchamiający.
• Agent monitorowania (MonAgent*.exe processes): Monitoruje, zbiera i przesyła dane diagnostyczne.

Ścieżki dziennika/artefaktu

Poniższe ścieżki prowadzą do ważnych dzienników i plików. Te informacje znajdują się w tym artykule.

Azure Cloud Services

Artefakt	Ścieżka
plik konfiguracji Azure Diagnostics	%SystemDrive%\Packages\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<wersja>\Config.txt
Pliki dzienników	C:\Logs\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<version>\
Magazyn lokalny dla danych diagnostycznych	C:\Resources\Directory<CloudServiceDeploymentID>.<RoleName>.DiagnosticStore\WAD0107\Tables
Plik konfiguracji agenta monitorowania	C:\Resources\Directory<CloudServiceDeploymentID>.<RoleName>.DiagnosticStore\WAD0107\Configuration\MaConfig.xml
pakiet rozszerzenia Diagnostyka Azure	%SystemDrive%\Packages\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics<wersja>
Ścieżka narzędzia do zbierania dzienników	%SystemDrive%\Packages\GuestAgent\
Plik dziennika MonAgentHost	C:\Resources\Directory<CloudServiceDeploymentID>.<RoleName>.DiagnosticStore\WAD0107\Configuration\MonAgentHost.<seq_num>.log

Maszyny wirtualne

Artefakt	Ścieżka
plik konfiguracji Azure Diagnostics	C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics version<\RuntimeSettings>
Pliki dzienników	C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\
Magazyn lokalny dla danych diagnostycznych	C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\WAD0107\Tables
Plik konfiguracji agenta monitorowania	C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\WAD0107\Configuration\MaConfig.xml
Plik stanu	C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<version>\Status
pakiet rozszerzenia Diagnostyka Azure	C:\Packages\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>
Ścieżka narzędzia do zbierania dzienników	C:\WindowsAzure\Logs\WaAppAgent.log
Plik dziennika MonAgentHost	C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<DiagnosticsVersion>\WAD0107\Configuration\MonAgentHost.<seq_num>.log

Dane metryczne nie wyświetlają się w portalu Azure

Diagnostyka udostępnia dane metryk, które można wyświetlić w witrynie Azure Portal. Jeśli masz problemy z wyświetlaniem danych w portalu, sprawdź tabelę WADMetrics\* w koncie kontroli diagnostycznej, aby upewnić się, że odpowiednie rekordy metryk są tam obecne i że dostawca zasobów Microsoft.Insights jest zarejestrowany.

Tutaj PartitionKey tabeli to identyfikator zasobu, maszyna wirtualna lub zestaw skalowania maszyn wirtualnych. RowKey to nazwa metryki. Jest również znana jako nazwa licznika wydajności.

Jeśli identyfikator zasobu jest niepoprawny, sprawdź konfigurację diagnostyki>metryki>ResourceId, aby sprawdzić, czy identyfikator zasobu jest poprawnie ustawiony.

Jeśli nie ma danych dla określonej metryki, sprawdź Konfigurację diagnostyki>Licznika wydajności, aby sprawdzić, czy metryka (licznik wydajności) jest uwzględniona. Domyślnie włączamy następujące liczniki:

• \Processor(_Total)% czasu procesora
• \Pamięć\Dostępne bajty
• \ASP.NET Applications(Total)\Żądania/sekunde
• \ASP.NET Applications(Total)\Errors Total/Sec
• \ASP.NET\Żądania w kolejce
• \ASP.NET\Żądania odrzucone
• \Processor(w3wp)% czasu procesora
• \Process(w3wp)\Bajty prywatne
• \Process(WaIISHost)% Czas procesora
• \Process(WaIISHost)\Bajty prywatne
• \Process(WaWorkerHost)% Czas Procesora
• \Process(WaWorkerHost)\Bajty prywatne
• \Memory\Page Faults/sek
• Czas pamięci środowiska CLR platformy .NET (globalny)% w GC
• \LogicalDisk(C:)\Zapis bajtów dysku/sek
• \LogicalDisk(C:)\Odczytane bajty dysku/s
• \LogicalDisk(D:)\Zapisywanie bajtów na dysk/sek
• \LogicalDisk(D:)\Odczyt danych z dysku / sek

Jeśli konfiguracja jest ustawiona poprawnie, ale nadal nie widzisz danych metryk, skorzystaj z poniższych wskazówek, aby ułatwić rozwiązywanie problemów.

Diagnostyka Azure nie uruchamia się

Aby uzyskać informacje o tym, dlaczego nie można uruchomić diagnostyki, zobacz pliki DiagnosticsPluginLauncher.log i DiagnosticsPlugin.log w podanej wcześniej lokalizacji plików dziennika.

Jeśli te dzienniki wskazują Monitoring Agent not reporting success after launch, oznacza to, że wystąpił błąd podczas uruchamiania MonAgentHost.exe. Spójrz na dzienniki w lokalizacji wskazanej dla pliku dziennika MonAgentHost w poprzedniej sekcji "Maszyny wirtualne".

Ostatni wiersz plików dziennika zawiera kod zakończenia.

DiagnosticsPluginLauncher.exe Information: 0 : [4/16/2016 6:24:15 AM] DiagnosticPlugin exited with code 0

Jeśli znajdziesz ujemny kod zakończenia, zobacz tabelę kodów zakończenia w sekcji Referencje.

Dane diagnostyczne nie są rejestrowane w usłudze Azure Storage

Ustal, czy żadne z danych nie pojawi się, czy niektóre z nich pojawią się.

Dzienniki infrastruktury diagnostycznej

Diagnostyka rejestruje wszystkie błędy w dziennikach infrastruktury diagnostyki. Upewnij się, że włączono przechwytywanie dzienników infrastruktury diagnostyki w konfiguracji. Następnie możesz szybko wyszukać wszelkie istotne błędy, które pojawiają się w tabeli w skonfigurowanym koncie magazynu DiagnosticInfrastructureLogsTable.

Nie są wyświetlane żadne dane

Najczęstszym powodem, dla którego dane zdarzenia nie pojawiają się wcale, jest to, że informacje dotyczące konta magazynowego są niepoprawnie zdefiniowane.

Rozwiązanie: popraw konfigurację diagnostyki i zainstaluj ponownie diagnostykę.

Jeśli konto magazynu jest poprawnie skonfigurowane, dostęp zdalny do maszyny i sprawdź, czy DiagnosticsPlugin.exe i MonAgentCore.exe są uruchomione. Jeśli nie są uruchomione, wykonaj kroki opisane w Azure Diagnostyka nie jest uruchomiona.

Jeśli procesy są uruchomione, przejdź do strony Czy dane są przechwytywane lokalnie? i postępuj zgodnie z instrukcjami.

Jeśli problem nadal występuje, spróbuj wykonać poniższe próby:

1. Odinstaluj agenta.
2. Usuń katalog C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics.
3. Ponownie zainstaluj agenta.

Brak części danych

Jeśli otrzymujesz pewne dane, ale nie wszystkie, oznacza to, że potok zbierania/transferu danych jest poprawnie ustawiony. Postępuj zgodnie z podsekcjami tutaj, aby zawęzić problem.

Czy kolekcja jest skonfigurowana?

Konfiguracja diagnostyki zawiera instrukcje dotyczące zbierania danych określonego typu. Przejrzyj konfigurację , aby sprawdzić, czy szukasz tylko danych skonfigurowanych dla kolekcji.

Czy host generuje dane?

• Liczniki wydajności: otwórz perfmon i sprawdź licznik.
• Dzienniki śledzenia: zdalny dostęp do maszyny wirtualnej i dodaj element TextWriterTraceListener do pliku konfiguracji aplikacji. Aby skonfigurować odbiornik tekstu, zobacz Tworzenie i inicjowanie odbiorników śledzenia. Upewnij się, że element <trace> ma <trace autoflush="true">. Jeśli nie widzisz generowanych dzienników śledzenia, zobacz sekcję "Więcej informacji na temat brakujących dzienników śledzenia".
• Śledzenie zdarzeń dla systemu Windows (ETW): dostęp zdalny do maszyny wirtualnej i zainstaluj narzędzie PerfView. W PerfView uruchom polecenie Plik>Polecenie użytkownika>Listen etwprovder1>etwprovider2 i tak dalej. Polecenie Listen jest rozróżniane pod względem wielkości liter i nie mogą występować spacje pomiędzy elementami rozdzielanymi przecinkami na liście dostawców ETW. Jeśli uruchomienie polecenia nie powiedzie się, wybierz pozycję Zaloguj w prawym dolnym rogu narzędzia PerfView, aby zobaczyć, co próbowało uruchomić i jaki był wynik. Przy założeniu, że dane wejściowe są poprawne, zostanie otwarte nowe okno. W ciągu kilku sekund zobaczysz ślady ETW.
• Dzienniki zdarzeń: zdalny dostęp do maszyny wirtualnej. Otwórz Podgląd zdarzeń i upewnij się, że istnieją zdarzenia.

Czy dane są przechwytywane lokalnie?

Następnie upewnij się, że dane są przechwytywane lokalnie. Dane są przechowywane lokalnie w plikach *.tsf w magazynie lokalnym na potrzeby danych diagnostycznych. Różne rodzaje dzienników są zbierane w różnych plikach tsf. Nazwy są podobne do nazw tabel w usłudze Azure Storage.

Na przykład liczniki wydajności są zbierane w tabeli PerformanceCountersTable.tsf. Dzienniki zdarzeń są zbierane w pliku WindowsEventLogsTable.tsf. Skorzystaj z instrukcji w sekcji Wyodrębnianie dziennika lokalnego, aby otworzyć lokalne pliki kolekcji i sprawdzić, czy są one zbierane na dysku.

Jeśli nie widzisz, że dzienniki są zbierane lokalnie, oraz już zweryfikowałeś, że host generuje dane, prawdopodobnie masz problem z konfiguracją. Uważnie przejrzyj konfigurację.

Zapoznaj się również z konfiguracją wygenerowaną dla MaConfig.xml MonitoringAgent. Sprawdź, czy istnieje sekcja opisowa odpowiedniego źródła dziennika. Następnie sprawdź, czy nie dochodzi do nieporozumień między konfiguracją diagnostyczną a konfiguracją agenta monitorowania.

Czy dane są przesyłane?

Jeśli sprawdziłeś, że dane są przechwytywane lokalnie, ale nadal nie widzisz ich na swoim koncie magazynowym, wykonaj następujące kroki:

• Sprawdź, czy podano poprawne konto przechowywania i czy nie zmieniono kluczy dla danego konta przechowywania. W przypadku usług Azure Cloud Services czasami użytkownicy nie aktualizują useDevelopmentStorage=trueelementu .
• Sprawdź, czy podane konto magazynowe jest poprawne. Upewnij się, że nie masz ograniczeń sieci, które uniemożliwiają składnikom dotarcie do publicznych punktów końcowych magazynu. Jednym ze sposobów, aby to zrobić, jest zdalny dostęp do maszyny i spróbuj samodzielnie zapisać coś na tym samym koncie magazynu.
• Na koniec możesz sprawdzić, jakie błędy są zgłaszane przez agenta monitorowania. Agent monitorowania zapisuje swoje dzienniki w pliku maeventtable.tsf, który znajduje się w lokalnym magazynie danych diagnostycznych. Postępuj zgodnie z instrukcjami w sekcji Wyodrębnianie dziennika lokalnego, aby otworzyć ten plik. Następnie spróbuj ustalić, czy istnieją errors wskazujące na błędy podczas odczytu plików lokalnych i zapisu w magazynie.

Przechwytywanie i archiwizowanie dzienników

Jeśli myślisz o skontaktowaniu się z pomocą techniczną, pierwszą rzeczą, o którą mogą cię poprosić, jest zebranie logów z komputera. Możesz zaoszczędzić czas, robiąc to samodzielnie. Uruchom narzędzie CollectGuestLogs.exe w ścieżce narzędzia do zbierania dzienników. Generuje on plik .zip ze wszystkimi odpowiednimi dziennikami platformy Azure w tym samym folderze.

Nie znaleziono tabel danych diagnostycznych

Tabele w usłudze Azure Storage, które przechowują zdarzenia ETW, są nazwane przy użyciu następującego kodu:

        if (String.IsNullOrEmpty(eventDestination)) {
            if (e == "DefaultEvents")
                tableName = "WADDefault" + MD5(provider);
            else
                tableName = "WADEvent" + MD5(provider) + eventId;
        }
        else
            tableName = "WAD" + eventDestination;

Oto przykład:

        <EtwEventSourceProviderConfiguration provider="prov1">
          <Event id="1" />
          <Event id="2" eventDestination="dest1" />
          <DefaultEvents />
        </EtwEventSourceProviderConfiguration>
        <EtwEventSourceProviderConfiguration provider="prov2">
          <DefaultEvents eventDestination="dest2" />
        </EtwEventSourceProviderConfiguration>

"EtwEventSourceProviderConfiguration": [
    {
        "provider": "prov1",
        "Event": [
            {
                "id": 1
            },
            {
                "id": 2,
                "eventDestination": "dest1"
            }
        ],
        "DefaultEvents": {
            "eventDestination": "DefaultEventDestination",
            "sinks": ""
        }
    },
    {
        "provider": "prov2",
        "DefaultEvents": {
            "eventDestination": "dest2"
        }
    }
]

Ten kod generuje cztery tabele:

Zdarzenie	Nazwa tabeli
provider="prov1" <Event id="1" />	WADEvent+MD5("prov1")+"1"
provider="prov1" <Event id="2" eventDestination="dest1" />	WADdest1
provider="prov1" <DefaultEvents />	WADDefault+MD5("prov1")
provider="prov2" <DefaultEvents eventDestination="dest2" />	WADdest2

Bibliografia

Zapoznaj się z poniższymi odniesieniami

Sprawdzanie konfiguracji rozszerzenia diagnostyki

Najprostszym sposobem sprawdzenia konfiguracji rozszerzenia jest przejście do eksploratora zasobów platformy Azure. Następnie przejdź do maszyny wirtualnej lub usługi w chmurze, w której znajduje się rozszerzenie diagnostyki (IaaSDiagnostics / PaaDiagnostics).

Alternatywnie użyj pulpitu zdalnego, aby połączyć się z maszyną i zapoznać się z plikiem konfiguracyjnym diagnostyki opisanym w sekcji Ścieżka artefaktów dziennika.

W obu przypadkach wyszukaj ciąg Microsoft.Azure.Diagnostics i xmlCfg lub WadCfg.

Jeśli wyszukujesz na maszynie wirtualnej, a pole WadCfg jest obecne, oznacza to, że konfiguracja jest w formacie JSON. Jeśli pole xmlCfg jest obecne, oznacza to, że konfiguracja jest w kodzie XML i jest zakodowana w formacie base64. Należy go zdekodować, aby wyświetlić kod XML załadowany przez diagnostykę.

W przypadku roli usługi w chmurze, jeśli wybierzesz konfigurację z dysku, dane są zakodowane w formacie base64. Należy go zdekodować, aby wyświetlić kod XML załadowany przez diagnostykę.

kody zakończenia wtyczki diagnostycznej Azure

Wtyczka zwraca następujące kody zakończenia:

Kod zakończenia	opis
0	Sukces.
-1	Błąd ogólny.
-2	Nie można załadować pliku rcf. Ten błąd wewnętrzny powinien wystąpić tylko wtedy, gdy wtyczka agenta gościa jest ręcznie wywoływana niepoprawnie na maszynie wirtualnej.
–3	Nie można załadować pliku konfiguracji diagnostyki. Rozwiązanie: spowodowane tym, że plik konfiguracji nie przechodzi weryfikacji schematu. Rozwiązaniem jest udostępnienie pliku konfiguracji zgodnego ze schematem.
-4	Inne wystąpienie diagnostyki agenta monitorowania korzysta już z lokalnego katalogu zasobów. Rozwiązanie: określ inną wartość jako LocalResourceDirectory.
-6	Wtyczka agenta gościa próbowała uruchomić diagnostykę z nieprawidłowym wierszem polecenia. Ten błąd wewnętrzny powinien wystąpić tylko wtedy, gdy wtyczka agenta gościa jest ręcznie wywoływana niepoprawnie na maszynie wirtualnej.
-10	Wtyczka Diagnostics zakończyła działanie z nieobsługiwanym wyjątkiem.
-11	Agent gościnny nie mógł utworzyć procesu odpowiedzialnego za uruchomienie i nadzorowanie agenta nadzorującego. Rozwiązanie: Sprawdź, czy są dostępne wystarczające zasoby systemowe do uruchamiania nowych procesów.
-101	Nieprawidłowe argumenty podczas wywoływania wtyczki Diagnostyka. Ten błąd wewnętrzny powinien wystąpić tylko wtedy, gdy wtyczka agenta gościa jest ręcznie wywoływana niepoprawnie na maszynie wirtualnej.
-102	Proces wtyczki nie może zainicjować się. Rozwiązanie: Sprawdź, czy są dostępne wystarczające zasoby systemowe do uruchamiania nowych procesów.
-103	Proces wtyczki nie może zainicjować się. W szczególności nie można utworzyć obiektu rejestratora. Rozwiązanie: Sprawdź, czy są dostępne wystarczające zasoby systemowe do uruchamiania nowych procesów.
-104	Nie można załadować pliku rcf dostarczonego przez agenta gościa. Ten błąd wewnętrzny powinien wystąpić tylko wtedy, gdy wtyczka agenta gościa jest ręcznie wywoływana niepoprawnie na maszynie wirtualnej.
-105	Wtyczka Diagnostyka nie może otworzyć pliku konfiguracji diagnostyki. Ten błąd wewnętrzny powinien wystąpić tylko wtedy, gdy wtyczka diagnostyki jest wywoływana niepoprawnie na maszynie wirtualnej.
-106	Nie można odczytać pliku konfiguracji diagnostyki. Spowodowane tym, że plik konfiguracji nie przechodzi weryfikacji schematu. Rozwiązanie: podaj plik konfiguracji zgodny ze schematem. Aby uzyskać więcej informacji, zobacz Sprawdzanie konfiguracji rozszerzenia diagnostyki.
-107	Katalog zasobów przekazywany do agenta monitorowania jest nieprawidłowy. Ten błąd wewnętrzny powinien wystąpić tylko wtedy, gdy agent monitorowania jest wywoływany niepoprawnie na maszynie wirtualnej.
-108	Nie można przekonwertować pliku konfiguracji diagnostyki na plik konfiguracji agenta monitorowania. Ten błąd wewnętrzny powinien wystąpić tylko wtedy, gdy wtyczka diagnostyki jest wywoływana ręcznie z nieprawidłowym plikiem konfiguracji.
-110	Błąd konfiguracji ogólnej diagnostyki. Ten błąd wewnętrzny powinien wystąpić tylko wtedy, gdy wtyczka diagnostyki jest wywoływana ręcznie z nieprawidłowym plikiem konfiguracji.
-111	Nie można uruchomić agenta monitorowania. Rozwiązanie: Sprawdź, czy są dostępne wystarczające zasoby systemowe.
-112	Błąd ogólny.

Wyodrębnianie dzienników lokalnych

Agent monitorowania zbiera dzienniki i artefakty jako .tsf pliki. Plik .tsf nie jest czytelny, ale można go przekonwertować na w następujący .csv sposób:

<Azure diagnostics extension package>\Monitor\x64\table2csv.exe <relevantLogFile>.tsf

Nowy plik o nazwie <relevantLogFile>.csv jest tworzony w tej samej ścieżce co odpowiedni .tsf plik.

Uwaga

To narzędzie należy uruchomić tylko względem głównego .tsf pliku (na przykład PerformanceCountersTable.tsf). Pliki towarzyszące (na przykład PerformanceCountersTables_\*\*001.tsf, PerformanceCountersTables_\*\*002.tsf) są przetwarzane automatycznie.

Więcej informacji na temat brakujących dzienników śledzenia

Uwaga

Poniższe informacje dotyczą głównie usług Azure Cloud Services, chyba że skonfigurowano DiagnosticsMonitorTraceListener aplikację działającą na maszynie wirtualnej infrastruktura jako usługa (IaaS).

• Upewnij się, że element DiagnosticMonitorTraceListener jest skonfigurowany w pliku web.config lub app.config. Jest ona domyślnie konfigurowana w projektach usług w chmurze. Jednak niektórzy klienci komentują to, co powoduje, że instrukcje śledzenia nie są zbierane przez diagnostykę.
• Jeśli dzienniki nie są zapisywane z metody OnStart lub Run, upewnij się, że element DiagnosticMonitorTraceListener znajduje się w pliku app.config. Domyślnie znajduje się w pliku web.config, ale dotyczy to tylko kodu uruchomionego w w3wp.exe. Musisz umieścić go w pliku app.config, aby przechwytywać ślady uruchomione w WaIISHost.exe.
• Upewnij się, że używasz pliku Diagnostics.Trace.TraceXXX zamiast Diagnostics.Debug.WriteXXX. Instrukcje debugowania są usuwane z kompilacji wydania.
• Upewnij się, że skompilowany kod faktycznie zawiera Diagnostics.Trace lines. Użyj Reflectora, ILDASM lub ILSpy, aby zweryfikować. Polecenia Diagnostics.Trace są usuwane z skompilowanego pliku binarnego, chyba że używasz symbolu kompilacji warunkowej TRACE. Ten typowy problem występuje, gdy używasz programu MSBuild do kompilowania projektu.

Znane problemy i środki zaradcze

Następujące znane problemy mają środki zaradcze.

Zależność platformy .NET 4.5

Rozszerzenie Diagnostyka Azure dla systemu Windows ma zależność środowiska uruchomieniowego od programu .NET Framework 4.5 lub nowszego. W chwili pisania wszystkie maszyny przydzielone dla usług Azure Cloud Services i wszystkie oficjalne obrazy oparte na maszynach wirtualnych platformy Azure mają zainstalowane środowisko .NET 4.5 lub nowsze.

Nadal można napotkać sytuację, w której próbujesz uruchomić rozszerzenie Diagnostyka Azure dla systemu Windows na maszynie, która nie ma platformy .NET 4.5 lub nowszej. Taka sytuacja występuje w przypadku utworzenia maszyny na podstawie starego obrazu lub migawki albo przyniesienia własnego niestandardowego dysku.

Ten problem zazwyczaj objawia się jako kod wyjścia 255 podczas uruchamiania DiagnosticsPluginLauncher.exe. Błąd występuje z powodu następującego nieobsługiwanego wyjątku:

System.IO.FileLoadException: Could not load file or assembly 'System.Threading.Tasks, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies

Środki zaradcze: zainstaluj program .NET 4.5 lub nowszy na maszynie.

Dane liczników wydajności są dostępne w przechowywaniu, ale nie są wyświetlane w portalu.

Środowisko portalu na maszynach wirtualnych domyślnie wyświetla określone liczniki wydajności. Jeśli nie widzisz liczników wydajności i wiesz, że dane są generowane, ponieważ są dostępne w magazynie, upewnij się, że:

• Czy dane w magazynie mają nazwy liczników w języku angielskim. Jeśli nazwy liczników nie są w języku angielskim, wykres metryk portalu nie rozpozna go.

  • Środek zaradczy: Zmień język maszyny na angielski dla kont systemowych. W tym celu wybierz pozycję > Następnie wyczyść ekran powitalny oraz konta systemowe, aby język niestandardowy nie był stosowany do kont systemowych.

• Jeśli używasz symboli wieloznacznych (*) w nazwach liczników wydajności, portal nie może skorelować skonfigurowanego i zebranego licznika, gdy liczniki wydajności są wysyłane do ujścia usługi Azure Storage.

  • Środki zaradcze: aby upewnić się, że możesz używać symboli wieloznacznych i mieć rozszerzenie portalu (*), skierować liczniki wydajności do ujścia usługi Azure Monitor.