Activiteit traceren en bijhouden

  • 11 minuten

Een groot deel van het onderhouden van databases is het afstemmen van prestaties. Dezelfde logboekbestanden die u gebruikt om te controleren op uw on-premises databases zijn nog steeds beschikbaar met Azure Database for MySQL/PostgreSQL.

Wanneer uw databases naar Azure zijn gemigreerd, moet u de logboekbestanden blijven controleren om ervoor te zorgen dat de prestaties van de databases behouden blijven.

In deze les ziet u waar de logboekbestanden voor PostgreSQL en MySQL worden opgeslagen in Azure en het detailniveau dat ze bevatten.

Serverlogboeken gebruiken om databaseactiviteit bij te houden

Azure Database for MySQL/PostgreSQL registreert ook diagnostische gegevens in de serverlogboeken. Serverlogboeken zijn de systeemeigen berichtenlogboekbestanden voor MySQL en PostgreSQL (niet de transactielogboekbestanden, die niet toegankelijk zijn in Azure Database for MySQL/PostgreSQL). Deze bestanden bevatten berichten, serverstatus en andere foutinformatie die u gebruikt om problemen met uw databases op te sporen. De serverlogboeken worden maximaal zeven dagen bewaard (minder, als de totale grootte van de serverlogboekbestanden groter is dan 7 GB).

Azure Database for MySQL en Azure Database for PostgreSQL registreren verschillende details in de serverlogboeken. In de volgende secties worden de serverlogboeken voor elke service afzonderlijk beschreven.

Serverlogboeken in Azure Database for MySQL

In Azure Database for MySQL biedt het serverlogboek de informatie die normaal gesproken beschikbaar is in het langzame querylogboek en het auditlogboek op een MySQL-server.

U gebruikt de informatie in het logboek voor langzame query's om trage query's te identificeren. Standaard is het logboek voor langzame query's uitgeschakeld. U schakelt deze in door de slow_query_log serverparameter in te stellen op AAN. U configureert het logboek voor langzame query's om te bepalen wat wordt bedoeld door een langzame query met behulp van de volgende serverparameters:

  • log_queries_not_using_indexes. Deze parameter is AAN of UIT. Stel deze in op AAN om alle query's vast te leggen die waarschijnlijk een volledige tabelscan uitvoeren in plaats van een indexzoekactie.
  • log_throttle_queries_not_using_indexes. Hiermee geeft u het maximum aantal trage query's dat geen indexen gebruikt die per minuut kunnen worden geregistreerd.
  • log_slow_admin_queries. Stel deze parameter in op AAN om trage beheerquery's in het logboek op te nemen.
  • long_query_time. De drempelwaarde (in seconden) voor een query die als traag wordt beschouwd.

Nadat u het logboek voor langzame query's en het auditlogboek hebt ingeschakeld, worden de logboekbestanden weergegeven op de pagina Serverlogboeken voor de server. Er wordt elke dag een nieuw logboek voor langzame query's gemaakt. Klik op een logboekbestand om het te downloaden:

Image of the Server logs page for Azure Database for MySQL.

Als u auditlogboekregistratie wilt inschakelen, stelt u de audit_log_enabled-serverparameter in op AAN. U configureert auditlogboekregistratie met de volgende parameters:

  • audit_log_events. Geef de gebeurtenissen op die moeten worden gecontroleerd. In Azure Portal biedt deze parameter een vervolgkeuzelijst met gebeurtenissen, zoals CONNECTION, DDL, DML, ADMIN en andere.
  • audit_log_exclude_users. Deze parameter is een door komma's gescheiden lijst met gebruikers waarvan de activiteiten niet worden opgenomen in het auditlogboek.

Als u het logboek voor langzame query's en auditlogboeken langer dan zeven dagen wilt behouden, zorgt u ervoor dat ze worden overgedragen naar Azure Storage. Gebruik de pagina Diagnostische instellingen voor uw server en selecteer vervolgens + Diagnostische instelling toevoegen. Selecteer Archief naar een opslagaccount op de pagina Diagnostische instellingen, selecteer een opslagaccount waarin u de logboekbestanden wilt opslaan (dit opslagaccount moet al bestaan), Selecteer MySqlSlowLogs en MySqlAuditLogs en geef een bewaarperiode op van maximaal 365 dagen. U kunt de logboekbestanden op elk gewenst moment downloaden uit Azure Storage. Selecteer Opslaan:

Image of the Diagnostic settings page for Azure Database for MySQL.

Trage querylogboekgegevens worden geschreven in JSON-indeling naar blobs in een container met de naam insights-logs-mysqlslowlogs. Het kan tot 10 minuten duren voordat de logboekbestanden worden weergegeven in Azure Storage. Controlerecords worden opgeslagen in de blobcontainer insights-logs-mysqlslowlogs , opnieuw in JSON-indeling.

Serverlogboeken in Azure Database for PostgreSQL

In Azure Database for PostgreSQL bevat het serverlogboek foutenlogboek en querylogboekbestanden. Gebruik de informatie in deze bestanden om de bronnen van fouten en inefficiënte query's te vinden.

U schakelt logboekregistratie in door de verschillende log_ serverconfiguratieparameters in te stellen op AAN. Deze parameters omvatten:

  • log_checkpoints. Er wordt een controlepunt uitgevoerd wanneer elk gegevensbestand is bijgewerkt met de meest recente informatie uit het transactielogboek. Als er een serverfout opgetreden is, markeert dit punt het tijdstip waarop het herstel moet worden gestart door het transactielogboek vooruit te rollen.
  • log_connection en log_disconnections. Deze instellingen registreren elke geslaagde verbinding en het einde van elke sessie.
  • log_duration. Deze instelling zorgt ervoor dat de duur van elke voltooide SQL-instructie wordt vastgelegd.
  • log_lock_waits. Deze instelling zorgt ervoor dat wachtevenementen voor vergrendelen worden vastgelegd. Vergrendelingswachttijden kunnen worden veroorzaakt door slecht geïmplementeerde transacties in toepassingscode.
  • log_statement_stats. Deze instelling schrijft cumulatieve informatie over de prestaties van de server naar het logboek.

Azure Database for PostgreSQL biedt ook aanvullende parameters voor het verfijnen van de informatie die is vastgelegd:

  • log_error_verbosity. Met deze instelling geeft u het detailniveau op dat is vastgelegd voor elk geregistreerd bericht.
  • log_retention_days. Dit is het aantal dagen dat de server elk logboekbestand bewaart voordat het wordt verwijderd. De standaardwaarde is drie dagen en u kunt deze instellen op maximaal zeven dagen.
  • log_min_messages en log_min_error_statement. Gebruik deze parameters om de waarschuwings- en foutniveaus voor opname-instructies op te geven.

Net als bij Azure Database for MySQL zijn de logboekbestanden die zijn gegenereerd door Azure Database for PostgreSQL beschikbaar op de pagina Serverlogboeken . U kunt ook de pagina Diagnostische instellingen gebruiken om de logboeken naar Azure Storage te kopiëren.

Queryprestaties bijhouden

Query Store is een extra functie van Azure waarmee u slecht uitgevoerde query's kunt identificeren en bijhouden. U gebruikt deze met Azure Database for MySQL en Azure Database for PostgreSQL.

Het bijhouden van queryprestaties inschakelen

Query Store registreert gegevens in het mysql-schema in Azure Database for MySQL en in een database met de naam azure_sys in Azure Database for PostgreSQL. Query Store kan twee soorten informatie vastleggen: gegevens over het uitvoeren van query's en informatie over wachtstatistieken. Query Store is standaard uitgeschakeld. U schakelt dit als volgt in:

  • Als u Azure Database for MySQL gebruikt, stelt u de serverparameters in query_store_capture_mode en query_store_wait_sampling_capture_mode op ALL.
  • Als u Azure Database for PostgreSQL gebruikt, stelt u de serverparameter pg_qs.query_capture_mode in op ALL of TOP en stelt u de parameter pgms_wait_sampling.query_capture_mode in op ALL.

Queryprestaties analyseren

U kunt rechtstreeks query's uitvoeren op de tabellen die door Query Store worden gebruikt. Als u Azure Database for MySQL uitvoert, maakt u verbinding met uw server en voert u de volgende query's uit:

SELECT * FROM mysql.query_store;

SELECT * FROM mysql.query_store_wait_stats;

Als u Azure Database for PostgreSQL gebruikt, voert u in plaats daarvan de volgende query's uit:

SELECT * FROM query_store.qs_view;

SELECT * FROM query_store.pgms_wait_sampling_view;

In beide gevallen geeft de eerste query de tekst weer voor elke onlangs uitgevoerde query en een groot aantal statistieken over hoe lang de query duurde om te compileren en uit te voeren. De tweede query geeft informatie weer over wachtevenementen. Er treedt een wachtgebeurtenis op wanneer een query niet kan worden uitgevoerd omdat hiervoor de resources zijn vereist die door een andere query worden bewaard.

Als u Query Store rechtstreeks bekijkt, kunt u uw eigen aangepaste rapporten genereren en een gedetailleerd inzicht krijgen in de werking van het systeem. De hoeveelheid beschikbare gegevens kan het echter lastig maken om te begrijpen wat er gebeurt. Azure Database for MySQL/PostgreSQL biedt twee extra hulpprogramma's waarmee u door deze gegevens kunt navigeren: Query Performance Insight en Query Aanbevelingen.

Query Performance Insight is een grafisch hulpprogramma dat beschikbaar is op de pagina Query Performance Insight voor uw server. Op het tabblad Langlopende query's worden de statistieken weergegeven voor de meest langlopende query's. U geeft de tijdsperiode op en zoomt binnen enkele minuten in. De legenda toont de tekst van elke query, samen met de duur en het aantal keren dat de query is uitgevoerd. De grafiek geeft een vergelijkende weergave van de duur van elke query. U bekijkt de gegevens op de gemiddelde tijd voor elke query, maar het is ook instructief om de totale tijd (duur * van de uitvoering) voor elke query weer te geven. In de onderstaande afbeelding ziet u een voorbeeld:

Image of the Query Performance Insight page for Azure Database for PostgreSQL, showing the Long running queries tab.

Op het tabblad Wachtstatistieken ziet u de informatie over de wacht gebeurtenis voor elke query. U ziet de hoeveelheid tijd die door een query is besteed aan het wachten op verschillende resources.

Image of the Query Performance Insight page for Azure Database for PostgreSQL, showing the Wait statistics tab.

Wachtgebeurtenissen vallen doorgaans in drie categorieën:

  • Wacht op slot. Deze gebeurtenissen vinden plaats als een query probeert gegevens te lezen of te wijzigen die zijn vergrendeld door een andere query. Als u een groot aantal vergrendelingswachttijden ondervindt, controleert u op langlopende transacties of bewerkingen die gebruikmaken van een zeer beperkend isolatieniveau.
  • IO-wachttijden. Dit type wachttijd treedt op als een query een aanzienlijke hoeveelheid IO uitvoert. Dit kan worden veroorzaakt door een slecht ontworpen query (controleer de WHERE-component ), een inefficiënte joinbewerking of een volledige tabelscan die is gemaakt vanwege een ontbrekende index.
  • Geheugenwachttijden. Er treedt een geheugenwacht op als er onvoldoende geheugen beschikbaar is om een query te verwerken. Mogelijk probeert uw query een grote hoeveelheid gegevens te lezen of wordt deze mogelijk geblokkeerd door andere query's die geheugen opschorten. Ook hier kan worden aangegeven dat er indexen ontbreken, waardoor query's hele tabellen in het geheugen kunnen lezen.

Het is ook zeer waarschijnlijk dat een vorm van wachttriggers een andere trigger, zodat u deze problemen niet noodzakelijkerwijs in isolatie kunt onderzoeken. Een transactie die gegevens in verschillende tabellen leest en bijwerkt, kan bijvoorbeeld worden onderworpen aan een geheugenwachttijd. Op zijn beurt kan deze transactie vergrendelde gegevens bevatten die ertoe leiden dat een andere transactie een vergrendelingswachttijden krijgt.

De pagina Performance Aanbevelingen voor de server gebruikt de gegevens in Query Store en gebruikt deze om aanbevelingen te doen voor het afstemmen van uw database voor de workloads die deze ondervindt.