Śledzenie i śledzenie aktywności

Ukończone

Dużą częścią utrzymania baz danych jest dostrajanie wydajności. Te same pliki dziennika, które są używane do przeglądania lokalnych baz danych, są nadal dostępne w usłudze Azure Database for MySQL/PostgreSQL.

W przypadku migrowania baz danych na platformę Azure należy kontynuować przeglądanie plików dziennika, aby zapewnić utrzymanie wydajności baz danych.

W tej lekcji zobaczysz, gdzie są przechowywane pliki dziennika dla baz danych PostgreSQL i MySQL na platformie Azure oraz poziom szczegółowości, które zawierają.

Śledzenie aktywności bazy danych za pomocą dzienników serwera

Usługa Azure Database for MySQL/PostgreSQL rejestruje również informacje diagnostyczne w dziennikach serwera. Dzienniki serwera to pliki dziennika komunikatów natywnych dla programów MySQL i PostgreSQL (nie plików dziennika transakcji, które są niedostępne w usłudze Azure Database for MySQL/PostgreSQL). Te pliki zawierają komunikaty, stan serwera i inne informacje o błędzie używane do debugowania problemów z bazami danych. Dzienniki serwera są zachowywane przez maksymalnie siedem dni (mniej, jeśli całkowity rozmiar plików dziennika serwera przekracza 7 GB).

Usługi Azure Database for MySQL i Azure Database for PostgreSQL rejestrują różne szczegóły w dziennikach serwera. W poniższych sekcjach opisano dzienniki serwera dla każdej usługi oddzielnie.

Dzienniki serwera w usłudze Azure Database for MySQL

W usłudze Azure Database for MySQL dziennik serwera zawiera informacje zwykle dostępne w dzienniku wolnych zapytań i dziennik inspekcji na serwerze MySQL.

Informacje w dzienniku wolnych zapytań służą do identyfikowania wolnych zapytań. Domyślnie dziennik wolnych zapytań jest wyłączony. Należy ją włączyć, ustawiając parametr serwera slow_query_log na WŁ. Dziennik wolnych zapytań konfiguruje się w celu określenia, co ma na myśli powolne zapytanie przy użyciu następujących parametrów serwera:

• log_queries_not_using_indexes. Ten parametr jest włączony lub wyłączony. Ustaw dla niego wartość WŁĄCZONE , aby rejestrować wszystkie zapytania, które mogą wykonać pełne skanowanie tabeli, a nie wyszukiwanie indeksu.
• log_throttle_queries_not_using_indexes. Określa maksymalną liczbę wolnych zapytań, które nie używają indeksów, które można rejestrować na minutę.
• log_slow_admin_queries. Ustaw ten parametr na WŁ. , aby uwzględnić wolno działające zapytania administracyjne w dzienniku.
• long_query_time. Próg (w sekundach) dla zapytania, który ma być uznawany za powolne działanie.

Po włączeniu dziennika wolnych zapytań i dziennika inspekcji pliki dziennika będą wyświetlane na stronie Dzienniki serwera dla serwera. Każdego dnia jest tworzony nowy dziennik wolnych zapytań. Kliknij plik dziennika, aby go pobrać:

Aby włączyć rejestrowanie inspekcji, ustaw parametr serwera audit_log_enabled na WŁ. Rejestrowanie inspekcji można skonfigurować przy użyciu następujących parametrów:

• audit_log_events. Określ zdarzenia do inspekcji. W witrynie Azure Portal ten parametr zawiera listę rozwijaną zdarzeń, takich jak CONNECTION, DDL, DML, ADMIN i inne.
• audit_log_exclude_users. Ten parametr jest rozdzielaną przecinkami listą użytkowników, których działania nie zostaną uwzględnione w dzienniku inspekcji.

Jeśli chcesz zachować dziennik wolnych zapytań i dziennik inspekcji przez ponad siedem dni, należy zaplanować ich transfer do usługi Azure Storage. Użyj strony Ustawienia diagnostyki dla serwera, a następnie wybierz pozycję + Dodaj ustawienie diagnostyczne. Na stronie Ustawienia diagnostyki wybierz pozycję Archiwum na koncie magazynu, wybierz konto magazynu, w którym mają zostać zapisane pliki dziennika (to konto magazynu musi już istnieć), wybierz pozycję MySqlSlowLogs i MySqlAuditLogs i określ okres przechowywania do 365 dni. Pliki dziennika można pobrać z usługi Azure Storage w dowolnym momencie w tym czasie. Wybierz pozycję Zapisz:

Dane dziennika wolnych zapytań będą zapisywane w formacie JSON do obiektów blob w kontenerze o nazwie insights-logs-mysqlslowlogs. Wyświetlenie plików dziennika w usłudze Azure Storage może potrwać do 10 minut. Rekordy inspekcji są przechowywane w kontenerze obiektów blob insights-logs-mysqlslowlogs , ponownie w formacie JSON.

Dzienniki serwera w usłudze Azure Database for PostgreSQL

W usłudze Azure Database for PostgreSQL dziennik serwera zawiera dziennik błędów i pliki dziennika zapytań. Skorzystaj z informacji w tych plikach, aby ułatwić znajdowanie źródeł błędów i niewydajnych zapytań.

Rejestrowanie można włączyć, ustawiając różne parametry konfiguracji serwera log_ na WŁĄCZONE. Te parametry obejmują:

• log_checkpoints. Punkt kontrolny występuje za każdym razem, gdy każdy plik danych został zaktualizowany przy użyciu najnowszych informacji z dziennika transakcji. Jeśli wystąpi awaria serwera, ten punkt oznacza czas, w którym odzyskiwanie musi rozpocząć się przez stopniowe wycofywanie z dziennika transakcji.
• log_connection i log_disconnections. Te ustawienia rejestrują każde pomyślne połączenie i koniec każdej sesji.
• log_duration. To ustawienie powoduje zarejestrowanie czasu trwania każdej ukończonej instrukcji SQL.
• log_lock_waits. To ustawienie powoduje zarejestrowanie zdarzeń oczekiwania na blokadę. Oczekiwanie na blokadę może być spowodowane przez źle zaimplementowane transakcje w kodzie aplikacji.
• log_statement_stats. To ustawienie zapisuje zbiorcze informacje o wydajności serwera w dzienniku.

Usługa Azure Database for PostgreSQL udostępnia również dodatkowe parametry, aby dostroić zarejestrowane informacje:

• log_error_verbosity. To ustawienie określa poziom szczegółów zarejestrowanych dla każdego zarejestrowanego komunikatu.
• log_retention_days. Jest to liczba dni, przez które serwer zachowuje każdy plik dziennika przed jego usunięciem. Wartość domyślna to trzy dni i można ustawić ją na maksymalnie siedem dni.
• log_min_messages i log_min_error_statement. Użyj tych parametrów, aby określić poziomy ostrzeżeń i błędów na potrzeby instrukcji rejestrowania.

Podobnie jak w przypadku usługi Azure Database for MySQL, pliki dziennika generowane przez usługę Azure Database for PostgreSQL są dostępne na stronie Dzienniki serwera. Możesz również użyć strony Ustawienia diagnostyczne, aby skopiować dzienniki do usługi Azure Storage.

Śledzenie wydajności zapytań

Magazyn zapytań to dodatkowa funkcja udostępniana przez platformę Azure, która ułatwia identyfikowanie i śledzenie słabo uruchomionych zapytań. Używasz jej z usługami Azure Database for MySQL i Azure Database for PostgreSQL.

Włączanie śledzenia wydajności zapytań

Magazyn zapytań rejestruje informacje w schemacie mysql w usłudze Azure Database for MySQL i w bazie danych o nazwie azure_sys w usłudze Azure Database for PostgreSQL. Magazyn zapytań może przechwytywać dwa typy informacji — dane dotyczące wykonywania zapytań i informacje na temat statystyk oczekiwania. Magazyn zapytań jest domyślnie wyłączony. Aby ją włączyć:

• Jeśli używasz usługi Azure Database for MySQL, ustaw parametry serwera query_store_capture_mode i query_store_wait_sampling_capture_mode na WSZYSTKIE.
• Jeśli używasz usługi Azure Database for PostgreSQL, ustaw parametr serwera pg_qs.query_capture_mode na ALL lub TOP, a następnie ustaw parametr pgms_wait_sampling.query_capture_mode na ALL.

Analizowanie danych wydajności zapytań

Tabele używane przez magazyn zapytań można wykonywać bezpośrednio względem tabel. Jeśli używasz usługi Azure Database for MySQL, połącz się z serwerem i uruchom następujące zapytania:

SELECT * FROM mysql.query_store;

SELECT * FROM mysql.query_store_wait_stats;

Jeśli używasz usługi Azure Database for PostgreSQL, uruchom następujące zapytania:

SELECT * FROM query_store.qs_view;

SELECT * FROM query_store.pgms_wait_sampling_view;

W obu przypadkach pierwsze zapytanie wyświetli tekst dla każdego ostatnio uruchomionego zapytania oraz wiele statystyk dotyczących czasu kompilowania i wykonywania zapytania. Drugie zapytanie wyświetla informacje o zdarzeniach oczekiwania. Zdarzenie oczekiwania występuje, gdy jedno zapytanie nie może działać, ponieważ wymaga zasobów przechowywanych przez inne.

Jeśli zbadasz magazyn zapytań bezpośrednio, możesz wygenerować własne raporty niestandardowe i uzyskać szczegółowy wgląd w działanie systemu. Jednak ilość dostępnych danych może utrudnić zrozumienie, co się dzieje. Usługa Azure Database for MySQL/PostgreSQL udostępnia dwa dodatkowe narzędzia ułatwiające nawigowanie po tych danych — szczegółowe informacje o wydajności zapytań i Rekomendacje zapytań.

Szczegółowe informacje o wydajności zapytań to narzędzie graficzne dostępne na stronie Szczegółowe informacje o wydajności zapytań dla serwera. Na karcie Długotrwałe zapytania są wyświetlane statystyki dla najbardziej długotrwałych zapytań. Należy określić okres i powiększyć go w ciągu kilku minut. Legenda przedstawia tekst każdego zapytania wraz z czasem trwania i liczbą uruchomień zapytania. Wykres przedstawia porównawczy czas trwania każdego zapytania. Dane są wyświetlane według średniego czasu dla każdego zapytania, ale jest również instruktażowe wyświetlanie łącznego czasu (liczba wykonań czasu trwania * ) dla każdego zapytania. Na poniższej ilustracji przedstawiono przykład:

Na karcie Statystyki oczekiwania są wyświetlane informacje o zdarzeniu oczekiwania dla każdego zapytania. Zobaczysz ilość czasu spędzonego przez zapytanie oczekujące na różne zasoby.

Zdarzenia oczekiwania zazwyczaj należą do trzech kategorii:

• Blokada czeka. Te zdarzenia występują, jeśli zapytanie próbuje odczytać lub zmodyfikować dane zablokowane przez inne zapytanie. Jeśli występuje duża liczba oczekujących blokad, sprawdź długotrwałe transakcje lub operacje korzystające z wysoce restrykcyjnego poziomu izolacji.
• Czeka we/wy. Ten typ oczekiwania występuje, jeśli zapytanie wykonuje znaczną ilość operacji we/wy. Może to być spowodowane źle zaprojektowanym zapytaniem (sprawdź klauzulę WHERE ), nieefektywną operacją sprzężenia lub pełnym skanowaniem tabeli spowodowanym brakiem indeksu.
• Oczekiwanie na pamięć. Oczekiwanie na pamięć występuje, jeśli nie ma wystarczającej ilości pamięci do przetworzenia zapytania. Zapytanie może próbować odczytać dużą ilość danych lub może zostać zablokowane przez inne zapytania wywracające pamięć. Ponownie może to oznaczać, że brakuje indeksów, co powoduje, że zapytania odczytują całe tabele do pamięci.

Istnieje również duże prawdopodobieństwo, że jedna forma oczekiwania wyzwala inny, więc niekoniecznie można zbadać te problemy w izolacji. Na przykład transakcja, która odczytuje i aktualizuje dane w różnych tabelach, może podlegać oczekiwaniu na pamięć. Z kolei ta transakcja może zablokować dane, które powodują, że kolejna transakcja spowoduje naliczenie blokady oczekiwania.

Strona Rekomendacje wydajności dla serwera pobiera informacje przechowywane w magazynie zapytań i używa jej do tworzenia zaleceń dotyczących dostrajania bazy danych dla obciążeń, które występują.