Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Monitoraggio dei file di log di Amazon Aurora Ogni motore di database RDS genera registri cui è possibile accedere per il controllo e la risoluzione dei problemi. Il tipo di registri dipende dal motore di database. È possibile accedere ai log del database per le istanze database utilizzando la Console di gestione AWS, AWS Command Line Interface (AWS CLI) o l’API Amazon RDS. Non puoi visualizzare, controllare o scaricare registri delle transazioni. **Nota** In alcuni casi, i log contengono dati nascosti. Quindi, Console di gestione AWS potrebbe mostrare i contenuti in un file di log, ma questo potrebbe essere vuoto quando lo scarichi. **Topics** + [Visualizzazione ed elenco dei file di log del database](USER_LogAccess.Procedural.Viewing.md) + [Download di un file di log di database](USER_LogAccess.Procedural.Downloading.md) + [Controllo di un file di log di database](USER_LogAccess.Procedural.Watching.md) + [Pubblicazione di log di database su Amazon CloudWatch Logs](USER_LogAccess.Procedural.UploadtoCloudWatch.md) + [Lettura dei contenuti del file di log con REST](DownloadCompleteDBLogFile.md) + [File di registro del database Aurora MySQL](USER_LogAccess.Concepts.MySQL.md) + [](USER_LogAccess.Concepts.PostgreSQL.md) # Visualizzazione ed elenco dei file di log del database Puoi visualizzare i file di log del database per il motore DB Amazon Aurora utilizzando la Console di gestione AWS. Puoi elencare i file di log disponibili per il download o il monitoraggio tramite AWS CLI o l'API di Amazon RDS. **Nota** Non è possibile visualizzare i file di registro per cluster database Aurora Serverless v1 nella console RDS. Tuttavia, puoi visualizzarli nella console Amazon CloudWatch all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). ## Console **Per visualizzare un file di log di database** 1. Apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nel pannello di navigazione, scegliere **Databases (Database)**. 1. Scegliere il nome dell'istanza di database che ha il file di log che si desidera visualizzare. 1. Scegliere la scheda **Logs & events (Log ed eventi)**. 1. Scorrere fino alla sezione **Logs (Log)**. 1. (Opzionale) Inserisci un termine di ricerca per filtrare i risultati. Nell'esempio seguente vengono elencati i registri filtrati dal testo **error**. ![\[Elenco dei log del database\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/ListEventsAMS.png) 1. Scegli il log che desideri visualizzare, quindi seleziona **View (Visualizza)**. ## AWS CLI Per elencare i file di log del database disponibili per un'istanza database, utilizza il comando AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-log-files.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-log-files.html). Il seguente esempio restituisce un elenco di file di log per un'istanza database denominata `my-db-instance`. **Example** ``` 1. aws rds describe-db-log-files --db-instance-identifier my-db-instance ``` ## API RDS Per elencare i file di log del database disponibili per un'istanza database usa l'operazione API Amazon RDS [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBLogFiles.html). # Download di un file di log di database Puoi usare la Console di gestione AWS, AWS CLI o l'API per scaricare un file di log del database. ## Console **Per scaricare un file di log di database** 1. Apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nel pannello di navigazione, scegliere **Databases (Database)**. 1. Scegliere il nome dell'istanza di database che ha il file di log che si desidera visualizzare. 1. Scegliere la scheda **Logs & events (Log ed eventi)**. 1. Scorrere fino alla sezione **Logs (Log)**. 1. Nella sezione **Logs (Log)**, selezionare il pulsante accanto al log che si desidera scaricare, quindi selezionare **Download (Scarica)**. 1. Aprire il menu contestuale (clic con il tasto destro del mouse) per il collegamento fornito, quindi scegliere **Save Link As (Salva collegamento come)**. Immettere l'ubicazione in cui si intende salvare il file di log, quindi scegliere **Save (Salva)**. ![\[Visualizzazione del file di log\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/log_download2.png) ## AWS CLI Per scaricare un file di log del database, utilizzare il comando AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/download-db-log-file-portion.html](https://docs.aws.amazon.com/cli/latest/reference/rds/download-db-log-file-portion.html). Per impostazione predefinita, questo comando scarica la porzione più recente di un file di log. Tuttavia, puoi scaricare un intero file specificando il parametro `--starting-token 0`. L'esempio seguente mostra come scaricare tutto il contenuto di un file di log denominato *log/ERROR.4* e come archiviarlo in un file locale denominato *errorlog.txt*. **Example** Per Linux, macOS o Unix: ``` 1. aws rds download-db-log-file-portion \ 2. --db-instance-identifier myexampledb \ 3. --starting-token 0 --output text \ 4. --log-file-name log/ERROR.4 > errorlog.txt ``` Per Windows: ``` 1. aws rds download-db-log-file-portion ^ 2. --db-instance-identifier myexampledb ^ 3. --starting-token 0 --output text ^ 4. --log-file-name log/ERROR.4 > errorlog.txt ``` ## API RDS Per scaricare un file di log del database, utilizzare l'operazione API Amazon RDS [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DownloadDBLogFilePortion.html). # Controllo di un file di log di database Controllare un file di registro del database equivale a eseguire l'accodamento del file su un sistema UNIX o Linux. Puoi controllare un file di registro usando la Console di gestione AWS. RDS aggiorna la coda del registro ogni 5 secondi. **Per controllare un file di log di database** 1. Aprire la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nel pannello di navigazione, scegliere **Databases (Database)**. 1. Scegliere il nome dell'istanza di database che ha il file di log che si desidera visualizzare. 1. Scegliere la scheda **Logs & events (Log ed eventi)**. ![\[Scelta della scheda Logs & events (Log ed eventi).\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_logsEvents.png) 1. Nella sezione **Logs (Log)**, scegliere un file di log, quindi selezionare **Watch (Controlla)**. ![\[Scelta di un registro\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_LogsEvents_watch.png) RDS mostra la coda del registro, come nel seguente esempio MySQL. ![\[Coda di un file di registro\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/Monitoring_LogsEvents_watch_content.png) # Pubblicazione di log di database su Amazon CloudWatch Logs In un database on-premise, i registri del database risiedono nel file system. Amazon RDS non fornisce accesso host ai registri del database sul file system del cluster database. Per questo motivo, Amazon RDS consente di esportare i registri del database nei [file di log Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html). Con File di log CloudWatch, puoi eseguire analisi in tempo reale dei dati dei registri. Puoi anche archiviare i dati in un archivio estremamente durevole e gestirli con l'agente File di log CloudWatch. **Topics** + [Panoramica dell'integrazione RDS con i file di log CloudWatch](#rds-integration-cw-logs) + [Decidere quali registri pubblicare nei file di log CloudWatch](#engine-specific-logs) + [Specifica dei registri da pubblicare nei file di log CloudWatch](#integrating_cloudwatchlogs.configure) + [Ricerca e filtraggio dei registri nei file di log CloudWatch](#accessing-logs-in-cloudwatch) ## Panoramica dell'integrazione RDS con i file di log CloudWatch Nei file di log CloudWatch, un *flusso di log* è una sequenza di eventi di log che condividono la stessa origine. Ciascuna origine di log in CloudWatch Logs costituisce un flusso di log distinto. Un *gruppo di log* è un gruppo di flussi di log che condividono le stesse impostazioni di conservazione, monitoraggio e controllo degli accessi. Amazon Aurora esegue lo streaming continuo dei record di log del cluster database in un gruppo di log. Ad esempio, disponi di un gruppo di registri `/aws/rds/cluster/cluster_name/log_type` per ogni tipo di registro che pubblichi. Questo gruppo di log si trova nella stessa regione AWS dell'istanza database che genera il log. AWS conserva i dati di registro pubblicati nei file di log CloudWatch per un periodo di tempo indefinito a meno che non venga specificato un periodo di conservazione. Per ulteriori informazioni, consulta la pagina relativa alla [modifica del periodo di conservazione dei dati dei log in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention). ## Decidere quali registri pubblicare nei file di log CloudWatch Ogni motore di database RDS supporta il proprio set di registri. Per informazioni sulle opzioni per il motore di database, consulta i seguenti argomenti: + [Pubblicazione di log Amazon Aurora MySQL in Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md) + [Pubblicazione di log Aurora PostgreSQL in Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md) ## Specifica dei registri da pubblicare nei file di log CloudWatch Puoi specificare quali registri pubblicare nella console. Assicurati di disporre di un ruolo collegato al servizio in AWS Identity and Access Management (IAM). Per ulteriori informazioni sui ruoli collegati al servizio, consulta [Utilizzo di ruoli collegati ai servizi per Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md). **Per specificare i registri da pubblicare** 1. Apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nel pannello di navigazione, scegliere **Databases (Database)**. 1. Esegui una delle operazioni seguenti: + Scegliere **Crea database**. + Scegli un database dall'elenco, quindi scegli **Modify** (Modifica). 1. In **Logs exports** (Esportazioni di log), scegli quali registri pubblicare. L’esempio seguente specifica il log di audit, i log degli errori, il log generale, il log delle istanze, il log degli errori di autenticazione del database IAM e il log delle query lente per un cluster di database Aurora MySQL. ## Ricerca e filtraggio dei registri nei file di log CloudWatch Puoi cercare voci di registro che soddisfino un criterio specificato utilizzando la console File di log CloudWatch. Puoi accedere ai registri tramite la console RDS, che porta alla console File di log CloudWatch, o direttamente dalla console File di log CloudWatch. **Per cercare registri RDS utilizzando la console RDS** 1. Apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nel pannello di navigazione, scegliere **Databases (Database)**. 1. Scegli un cluster database o un'istanza database. 1. Scegliere **Configuration (Configurazione)**. 1. In **Published logs** (Log pubblicati), scegli il registro del database che desideri visualizzare. **Per cercare i registri RDS utilizzando la console File di log CloudWatch** 1. Apri la console CloudWatch all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. Nel pannello di navigazione, seleziona **Log groups** (Gruppi di log). 1. Nella casella del filtro, immetti **/aws/rds**. 1. In **Log Groups** (Gruppi di log), seleziona il nome del gruppo di log contenente il flusso di log da cercare. 1. In **Log Streams** (Flussi di log), seleziona il nome del flusso di log da cercare. 1. In **Eventi di log**, immettere la sintassi del filtro da utilizzare. Per ulteriori informazioni, consulta [Ricerca e filtraggio dei dati di registro](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) nella *Guida per l'utente di File di log Amazon CloudWatch*. Per un blog tutorial su come monitorare i registri RDS, consulta la sezione relativa alla [creazione di un monitoraggio proattivo del database per Amazon RDS con File di log Amazon CloudWatch, AWS Lambda e Amazon SNS](https://aws.amazon.com/blogs/database/build-proactive-database-monitoring-for-amazon-rds-with-amazon-cloudwatch-logs-aws-lambda-and-amazon-sns/). # Lettura dei contenuti del file di log con REST Amazon RDS fornisce un endpoint REST che consente l'accesso ai file di log dell'istanza database. Questo è utile se hai necessità di scrivere un'applicazione per eseguire lo streaming dei contenuti del file di log Amazon RDS. La sintassi è: ``` GET /v13/downloadCompleteLogFile/DBInstanceIdentifier/LogFileName HTTP/1.1 Content-type: application/json host: rds.region.amazonaws.com ``` I parametri seguenti sono obbligatori: + `DBInstanceIdentifier` — Nome dell'istanza database che contiene il file di log che vuoi scaricare. + `LogFileName` — Nome del file di log da scaricare. La risposta contiene i contenuti del file di log richiesto, come stream. L'esempio seguente scarica il file di log denominato *log/ERROR.6* per l'istanza database denominata *sample-sql* nella regione *us-west-2*. ``` GET /v13/downloadCompleteLogFile/sample-sql/log/ERROR.6 HTTP/1.1 host: rds.us-west-2.amazonaws.com X-Amz-Security-Token: AQoDYXdzEIH//////////wEa0AIXLhngC5zp9CyB1R6abwKrXHVR5efnAVN3XvR7IwqKYalFSn6UyJuEFTft9nObglx4QJ+GXV9cpACkETq= X-Amz-Date: 20140903T233749Z X-Amz-Algorithm: AWS4-HMAC-SHA256 X-Amz-Credential: AKIADQKE4SARGYLE/20140903/us-west-2/rds/aws4_request X-Amz-SignedHeaders: host X-Amz-Content-SHA256: e3b0c44298fc1c229afbf4c8996fb92427ae41e4649b934de495991b7852b855 X-Amz-Expires: 86400 X-Amz-Signature: 353a4f14b3f250142d9afc34f9f9948154d46ce7d4ec091d0cdabbcf8b40c558 ``` Se specifichi un'istanza database non esistente, otterrai il seguente errore: + `DBInstanceNotFound`—`DBInstanceIdentifier` non fa riferimento a un'istanza database esistente. (Codice di stato HTTP: 404) # File di registro del database Aurora MySQL Puoi monitorare i log di Aurora MySQL direttamente tramite la console Amazon RDS, l'API Amazon RDS o. AWS CLI AWS SDKs Puoi anche eseguire l'accesso ai log MySQL indirizzando i log a una tabella del database nel database principale e facendo una ricerca in tale tabella. Puoi utilizzare la utility mysqlbinlog per scaricare un log binario. Per ulteriori informazioni sulla visualizzazione, il download e la visione di log di database basati su file, consulta [Monitoraggio dei file di log di Amazon Aurora](USER_LogAccess.md). **Topics** + [Panoramica dei registri di database Aurora MySQL](USER_LogAccess.MySQL.LogFileSize.md) + [Invio dell'output del log di Aurora MySQL alle tabelle](Appendix.MySQL.CommonDBATasks.Logs.md) + [Configurazione di Aurora per database Single-AZ](USER_LogAccess.MySQL.BinaryFormat.md) + [Accesso ai log binari MySQL](USER_LogAccess.MySQL.Binarylog.md) # Panoramica dei registri di database Aurora MySQL Puoi monitorare i seguenti tipi di file di registro Aurora MySQL: + Log di errori + Log delle query lente + Log generale + Log di audit + Log delle istanze + Log degli errori di autenticazione del database IAM Il registro degli errori Aurora MySQL viene generato per impostazione predefinita. È possibile generare la query lenta e i log generali impostando i parametri nel gruppo di parametri di database. **Topics** + [Registri degli errori Aurora MySQL](#USER_LogAccess.MySQL.Errorlog) + [Registri generali e delle query lente di Aurora MySQL](#USER_LogAccess.MySQL.Generallog) + [Registro di verifica di Aurora MySQL](#ams-audit-log) + [Log delle istanze Aurora MySQL](#ams-instance-log) + [Rotazione e conservazione dei registri per Autora MySQL](#USER_LogAccess.AMS.LogFileSize.retention) + [Pubblicazione dei log di Aurora MySQL su Amazon Logs CloudWatch](#USER_LogAccess.MySQLDB.PublishAuroraMySQLtoCloudWatchLogs) ## Registri degli errori Aurora MySQL Aurora MySQL scrive errori nel file `mysql-error.log`. Ogni file di log ha l'ora di creazione (in UTC) accodata al nome. I file di log hanno anche un timestamp che ti aiuta a determinare quando le voci del log sono state scritte. Aurora MySQL scrive nel registro degli errori solo durante l'avvio, l'arresto e quando si verificano errori. Un'istanza database può andare avanti ore senza che ci siano nuove voci scritte nel file di log degli errori. Se non vedi voci recenti, significa che il server non ha riscontrato errori che generano una voce di registro. In base alla progettazione, i registri degli errori vengono filtrati in modo da visualizzare solo eventi imprevisti come errori. Tuttavia, i registri degli errori contengono anche altre informazioni sul database, ad esempio l'avanzamento della query, che non vengono visualizzate. Pertanto, anche senza errori effettivi, la dimensione dei registri degli errori potrebbe aumentare a causa delle attività del database in corso. Anche se potresti vedere una certa dimensione in byte o kilobyte per i log degli errori in Console di gestione AWS, potrebbero avere 0 byte quando li scarichi. Aurora MySQL scrive `mysql-error.log` su disco ogni 5 minuti. Aggiunge il contenuto del registro a `mysql-error-running.log`. Aurora MySQL ruota il file `mysql-error-running.log` ogni ora. **Nota** Il periodo di conservazione dei log è diverso tra Amazon RDS e Aurora. ## Registri generali e delle query lente di Aurora MySQL Il registro delle query lente e il registro generale di Aurora MySQL possono essere scritti in un file o una tabella di database impostando i parametri nel gruppo parametri del database. Per informazioni sulla creazione e la modifica di un gruppo di parametri database, consulta [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md). È necessario impostare questi parametri prima di poter visualizzare il log delle query lente o il registro generale nella console Amazon RDS o utilizzando l'API Amazon RDS, la CLI di Amazon RDS o. AWS SDKs Puoi controllare la registrazione di Aurora MySQL utilizzando i parametri in questo elenco: + `slow_query_log`: per creare il log delle query lente, imposta su 1. Il valore predefinito è 0. + `general_log`: per creare il log generale, imposta su 1. Il valore predefinito è 0. + `long_query_time`: per evitare che le query a esecuzione rapida vengano registrate nel registro delle query lente, specifica in secondi un valore per il runtime di query più breve da registrare. Il valore predefinito è 10 secondi, il minimo è 0 secondi. Se log\$1output = FILE, puoi specificare un valore in virgola mobile con risoluzione al microsecondo. Se log\$1output = TABLE, devi specificare un valore intero con risoluzione al secondo. Vengono registrate solo le query con runtime che supera il valore `long_query_time`. Ad esempio, impostando `long_query_time` su 0,1 si impedisce a tutte le query con tempo di esecuzione inferiore a 100 millisecondi di essere registrate. + `log_queries_not_using_indexes`: per registrare tutte le query che non usano un indice sul log delle query lente, imposta su 1. Le query che non utilizzano un indice vengono registrate anche se il runtime è inferiore al valore del parametro `long_query_time`. Il valore predefinito è 0. + `log_output option`: puoi specificare una delle seguenti opzioni per il parametro `log_output`. + **TABLE** `mysql.general_log` Scrive le query generali nella tabella – e le query lente nella tabella `mysql.slow_log`. + **FILE** – Scrive sia i log generali sia i log delle query lente nel file system. + **NONE** – Disabilita il logging. Per Aurora MySQL versione 2 e 3, il valore predefinito di `log_output` è `FILE`. Affinché i dati delle query lente vengano visualizzati in Amazon CloudWatch Logs, devono essere soddisfatte le seguenti condizioni: + CloudWatch I log devono essere configurati per includere log di query lente. + `slow_query_log` deve essere abilitato. + `log_output` deve essere impostato su `FILE`. + La query deve richiedere più tempo di quanto configurato per `long_query_time`. Per ulteriori informazioni sui log delle query lente e i log generali, consulta i seguenti argomenti nella documentazione di MySQL: + [Log delle query lente](https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html) + [Log delle query generali](https://dev.mysql.com/doc/refman/8.0/en/query-log.html) ## Registro di verifica di Aurora MySQL La registrazione di controllo per Aurora MySQL è denominata Advanced Auditing. Per attivare Advanced Auditing, imposta alcuni parametri del cluster database. Per ulteriori informazioni, consulta [Utilizzo dell'audit avanzato con un cluster di database Amazon Aurora MySQL](AuroraMySQL.Auditing.md). ## Log delle istanze Aurora MySQL Aurora crea un file di log separato per le istanze database con la funzionalità di pausa automatica abilitata. Questo file instance.log registra tutti i motivi per cui le istanze database non possono essere messe in pausa quando previsto. Per ulteriori informazioni sul comportamento dei file di log delle istanze e sulla funzionalità di pausa automatica di Aurora, consulta [Monitoraggio delle attività di pausa e ripresa di Aurora Serverless v2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#autopause-logging-instance-log). ## Rotazione e conservazione dei registri per Autora MySQL Quando la registrazione è abilitata, Amazon Aurora ruota o elimina i file di registro Amazon a intervalli regolari. Questa è una misura preventiva per ridurre l'eventualità che un file di log molto grande comprometta l'uso del database o la performance. Autora MySQL gestisce la rotazione e l'eliminazione come segue: + Le dimensioni del file di registro degli errori di Aurora MySQL sono limitate a un massimo del 15 per cento dello storage locale per un'istanza database. Per mantenere questa soglia, i log vengono ruotati automaticamente ogni ora. Aurora MySQL rimuove i registri dopo 30 giorni o quando è stato occupato il 15% dello spazio su disco. Se le dimensioni del file di log combinato superano tale soglia dopo la rimozione dei file di log più vecchi, i file di log più grandi vengono eliminati fino a che le dimensioni del file di log non rimangono inferiori alla soglia. + Aurora MySQL rimuove i log di audit, generali, di query lente dopo 24 ore o quando è stato occupato il 15% dello spazio di archiviazione. + Quando la registrazione `FILE` è abilitata, i file di registro generale e delle query lente vengono esaminati ogni ora e quelli più vecchi di 24 ore vengono eliminati. In alcuni casi, la dimensione del file di registro combinato restante dopo l'eliminazione supera la soglia del 15 per cento di spazio locale di un'istanza database. In questi casi, i file di log più vecchi vengono eliminati fino a che le dimensioni del file di log non rimangono inferiori alla soglia. + Quando la registrazione `TABLE` è abilitata, le tabelle di registro non vengono ruotate o eliminate. Le tabelle di registro vengono troncate quando la dimensione di tutti i registri combinati è troppo grande. È possibile abbonarsi alla categoria di eventi `low storage` per ricevere una notifica quando le tabelle di log devono essere ruotate o eliminate manualmente per liberare spazio. Per ulteriori informazioni, consulta [Utilizzo della notifica degli eventi di Amazon RDS](USER_Events.md). Puoi ruotare la tabella `mysql.general_log` chiamando manualmente la procedura `mysql.rds_rotate_general_log`. Puoi ruotare la tabella `mysql.slow_log` chiamando la procedura `mysql.rds_rotate_slow_log`. Quando ruoti manualmente le tabelle di registro, la tabella di registro corrente viene copiata in una tabella di registro di backup e le voci nella tabella di registro corrente vengono eliminate. Se esiste già una tabella di log di backup, questa viene eliminata prima che la tabella di log corrente sia copiata nel backup. Puoi eseguire una query sulla tabella di log di backup, se necessario. La tabella di log di backup per la tabella `mysql.general_log` è denominata `mysql.general_log_backup`. La tabella di log di backup per la tabella `mysql.slow_log` è denominata `mysql.slow_log_backup`. + I registri di controllo Aurora MySQL vengono ruotati quando la dimensione del file raggiunge i 100 MB e rimossi dopo 24 ore. + Amazon RDS ruota i file di log degli errori di autenticazione del database IAM di dimensioni superiori a 10 MB. Amazon RDS rimuove i file di log degli errori di autenticazione del database IAM più vecchi di cinque giorni o più grandi di 100 MB. Per utilizzare i log dalla console Amazon RDS, dall'API Amazon RDS, dalla CLI di Amazon RDS oppure AWS SDKs imposta il parametro su FILE. `log_output` Analogamente al registro degli errori di Aurora MySQL, questi file di registro vengono ruotati ogni ora. I file di log che sono stati generati durante le precedenti 24 ore vengono conservati. Il periodo di conservazione è diverso tra Amazon RDS e Aurora. ## Pubblicazione dei log di Aurora MySQL su Amazon Logs CloudWatch Puoi configurare il tuo cluster Aurora MySQL DB per pubblicare i dati di log in un gruppo di log in Amazon Logs. CloudWatch Con CloudWatch Logs, puoi eseguire analisi in tempo reale dei dati di log e utilizzarli CloudWatch per creare allarmi e visualizzare metriche. È possibile utilizzare CloudWatch Logs per archiviare i record di registro in un archivio altamente durevole. Per ulteriori informazioni, consulta [Pubblicazione di log Amazon Aurora MySQL in Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md). # Invio dell'output del log di Aurora MySQL alle tabelle Puoi indirizzare il log generale e il log delle query lente alle tabelle sull'istanza database creando un gruppo di parametri del database e impostando il parametro server `log_output` su `TABLE`. Le query generali vengono quindi registrate sulla tabella `mysql.general_log`, mentre le query lente vengono registrate sulla tabella `mysql.slow_log`. Puoi eseguire query sulle tabelle per avere accesso alle informazioni di log. L'abilitazione di questa registrazione aumenta il numero di dati scritti sul database, il che potrebbe compromettere le performance. Sia il log generale che quello delle query lente sono disattivati per impostazione predefinita. Per abilitare la registrazione sulle tabelle devi impostare anche i parametri server `general_log` e `slow_query_log` su `1`. Le tabelle di log continuano a crescere fino a che le rispettive attività di registrazione non vengono disattivate eseguendo la reimpostazione del parametro appropriato su `0`. Spesso nel corso del tempo si accumulano grandi quantità di dati che possono usare una percentuale considerevole dello spazio di archiviazione assegnato. Amazon Aurora non consente di troncare le tabelle dei registri, ma è possibile spostarne il contenuto. La rotazione delle tabelle ne salva il contenuto in una tabella di backup e crea una nuova tabella di log vuota. Puoi ruotare manualmente le tabelle di log con le seguenti procedure a riga di comando, nelle quali il prompt dei comandi è indicato da `PROMPT>`: ``` PROMPT> CALL mysql.rds_rotate_slow_log; PROMPT> CALL mysql.rds_rotate_general_log; ``` Per rimuovere completamente i dati vecchi e recuperare lo spazio del disco, chiama la procedura adeguata due volte in successione. # Configurazione di Aurora per database Single-AZ Il *log binario* è un insieme di file di log che contengono informazioni sulle modifiche apportate ai dati di un'istanza server Aurora MySQL. Il log binario contiene informazioni come le seguenti: + Eventi che descrivono le modifiche al database come la creazione di tabelle o la modifica di righe + Informazioni sulla durata di ogni istruzione che ha aggiornato i dati + Eventi per istruzioni che avrebbero potuto aggiornare i dati ma non l'hanno fatto Il log binario registra le istruzioni inviate durante la replica. È inoltre necessario per alcune operazioni di ripristino. Per ulteriori informazioni, consulta la pagina relativa al [log binario](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html) nella documentazione di MySQL. I registri binari sono accessibili solo dall'istanza database principale, non dalle repliche. MySQL su Amazon Aurora supporta i formati di logging binario *basati su righe*, *basati su istruzioni* e *misti*. Si consiglia il formato misto a meno che non sia necessario un formato binlog specifico. Per dettagli sui diversi formati di log binari Aurora MySQL, consulta [Binary logging formats](https://dev.mysql.com/doc/refman/8.0/en/binary-log-formats.html) nella documentazione MySQL. Se pianifichi di utilizzare la replica, il formato di logging binario è importante in quanto determina il record delle modifiche dei dati che viene registrato nella sorgente e inviato ai target della replica. Per ulteriori informazioni sui vantaggi e sugli svantaggi dei vari formati di logging binario per la replica, consulta la pagina relativa a [vantaggi e svantaggi della replica basata su istruzioni e basata su riga](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) nella documentazione di MySQL. **Importante** Con MySQL 8.0.34, MySQL ha reso obsoleto il parametro `binlog_format`. Nelle versioni successive di MySQL, MySQL prevede di rimuovere il parametro e supportare solo la replica basata su righe. Di conseguenza, consigliamo di utilizzare la registrazione dei log basata su righe per le nuove configurazioni di replica MySQL. Per ulteriori informazioni, consulta [binlog\$1format](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format) nella documentazione MySQL. Le versioni 8.0 e 8.4 di MySQL accettano il parametro `binlog_format`. Quando si utilizza questo parametro, MySQL emette un avviso che indica che è obsoleto. In una futura versione principale, MySQL rimuoverà il parametro `binlog_format`. La replica basata sulle istruzioni può causare incoerenze tra l'cluster database di origine e una replica di lettura. Per ulteriori informazioni, consulta la pagina relativa alla [ determinazione delle istruzioni sicure e non sicure nel logging binario](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html) nella documentazione MySQL. È possibile monitorare l'utilizzo degli IOPS con la `` `VolumeWriteIOPs` CloudWatch metrica. **Per impostare il formato di registrazione binaria MySQL** 1. Aprire la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nel riquadro di navigazione scegliere **Parameter groups (Gruppi di parametri)**. 1. Scegliere il gruppo di parametri del cluster di database associato al cluster di database da modificare. Non è consentito modificare un gruppo di parametri predefinito. Se l'cluster database è usata da un gruppo di parametri predefinito, creare un nuovo gruppo di parametri e associarlo all'cluster database. Per ulteriori informazioni sui gruppi di parametri, consulta [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md). 1. In **Actions (Operazioni)**, scegliere **Edit (Modifica)**. 1. Imposta il parametro `binlog_format` sul formato di registrazione binaria scelto (`ROW`, `STATEMENT` o `MIXED`). Puoi anche utilizzare il valore `OFF` per disattivare la registrazione binaria. **Nota** L’impostazione di `binlog_format` su `OFF` nel gruppo di parametri del cluster di database disabilita la variabile di sessione `log_bin`. Questo comportamento disabilita la registrazione dei log binari sul cluster di database Aurora MySQL, che a sua volta reimposta la variabile di sessione `binlog_format` sul valore predefinito `ROW` nel database. 1. Scegliere **Salva modifiche** per salvare gli aggiornamenti applicati al gruppo di parametri cluster database. Dopo aver eseguito questi passaggi, è necessario riavviare l'istanza di scrittura nel cluster database per applicare le modifiche. In Aurora MySQL versione 2.09 e precedenti, quando si riavvia l'istanza di scrittura, vengono riavviate anche tutte le istanze di lettura nel cluster database. In Aurora MySQL versione 2.10 e successive, è necessario riavviare tutte le istanze di lettura manualmente. Per ulteriori informazioni, consulta [Riavvio di un cluster Amazon Aurora DB o di un'istanza Amazon Aurora DB](USER_RebootCluster.md). **Importante** La modifica di un gruppo di parametri cluster di database influisce su tutti i cluster di database che utilizzano tale gruppo di parametri. Se si desidera specificare diversi formati di registrazione binaria per diversi cluster Aurora MySQL DB AWS in una regione, i cluster DB devono utilizzare diversi gruppi di parametri del cluster DB. Questi gruppi di parametri identificano diversi formati di logging. Assegnare il gruppo di parametri cluster di database appropriato a ciascun cluster di database. Per ulteriori informazioni sui parametri Aurora MySQL, consulta [Parametri di configurazione Aurora MySQL](AuroraMySQL.Reference.ParameterGroups.md). # Accesso ai log binari MySQL Puoi utilizzare la utility mysqlbinlog per il download o lo streaming di log binari dalle istanze database RDS for MySQL. Il log binario viene scaricato sul computer locale dove è possibile eseguire operazioni come la riproduzione del log tramite utility mysql. Per ulteriori informazioni sull'uso dell'utilità mysqlbinlog, consulta [Utilizzo di mysqlbinlog per il backup di file di log binari](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-backup.html) nella documentazione di MySQL. Per eseguire la utility mysqlbinlog su un'istanza Amazon RDS usa le seguenti opzioni: + `--read-from-remote-server`: obbligatorio + `--host`: il nome DNS dall'endpoint dell'istanza. + `--port`: la porta utilizzata dall'istanza. + `--user`: un utente MySQL al quale è stata concessa l'autorizzazione `REPLICATION SLAVE`. + `--password`: la password dell'utente MySQL oppure ometti un valore di password affinché l'utilità richieda una password. + `--raw`: scarica il file in formato binario. + `--result-file`: il file locale per riceve l'output raw. + `--stop-never`: trasmette in streaming i file di log binari. + `--verbose`: quando utilizzi il formato binlog `ROW`, includi questa opzione per visualizzare gli eventi di riga come istruzioni pseudo-SQL. Per ulteriori informazioni sull'opzione `--verbose`, consulta [Visualizzazione degli eventi di riga di mysqlbinlog](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-row-events.html) nella documentazione di MySQL. + Specifica il nome di uno o più file di log binari. Per ottenere l'elenco dei log disponibili, utilizza il comando SQL `SHOW BINARY LOGS`. Per ulteriori informazioni sulle opzioni di mysqlbinlog, consulta [Utilità mysqlbinlog per l'elaborazione di file di log binari](https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog.html) nella documentazione di MySQL. Gli esempi seguenti mostrano come utilizzare l'utilità mysqlbinlog. Per Linux, macOS o Unix: ``` mysqlbinlog \ --read-from-remote-server \ --host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com \ --port=3306 \ --user ReplUser \ --password \ --raw \ --verbose \ --result-file=/tmp/ \ binlog.00098 ``` Per Windows: ``` mysqlbinlog ^ --read-from-remote-server ^ --host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com ^ --port=3306 ^ --user ReplUser ^ --password ^ --raw ^ --verbose ^ --result-file=/tmp/ ^ binlog.00098 ``` I log binari devono rimanere disponibili sull’istanza database affinché l’utilità mysqlbinlog possa accedervi. Per garantirne la disponibilità, usare la stored procedure [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) e specificare un periodo abbastanza lungo che consenta di scaricare i log. Se questa configurazione non è impostata, Amazon RDS elimina i log binari il prima possibile, causando lacune nei log binari recuperati dall’utilità mysqlbinlog. L'esempio seguente imposta il periodo di conservazione su 1 giorno. ``` call mysql.rds_set_configuration('binlog retention hours', 24); ``` Per visualizzare l'impostazione attuale, utilizza la procedura archiviata [mysql.rds\$1show\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_show_configuration). ``` call mysql.rds_show_configuration; ``` # È possibile monitorare i seguenti tipi di file di log Aurora PostgreSQL: + Log di PostgreSQL + Log delle istanze + Log degli errori di autenticazione del database IAM **Nota** Per abilitare i log degli errori di autenticazione del database IAM, è necessario prima abilitare l’autenticazione del database IAM per il cluster di database Aurora PostgreSQL. Per ulteriori informazioni sull’abilitazione database IAM, consulta [Abilitazione e disabilitazione dell’autenticazione database IAM](UsingWithRDS.IAMDBAuth.Enabling.md). Aurora PostgreSQL registra le attività del database nel file di log PostgreSQL predefinito. Per un'istanza database PostgreSQL on-premise, questi messaggi vengono archiviati localmente in `log/postgresql.log`. Per un cluster database Aurora PostgreSQL, il file di log è disponibile nel cluster Aurora. Questi log sono accessibili anche tramite Console di gestione AWS, dove è possibile visualizzarli o scaricarli. Il livello di registrazione predefinito rileva gli errori di accesso, gli errori irreversibili del server, i deadlock e gli errori delle query. Per ulteriori informazioni su come visualizzare, scaricare e guardare i registri di database basati su file, consulta [Monitoraggio dei file di log di Amazon Aurora](USER_LogAccess.md). Per ulteriori informazioni sui registri PostgreSQL, consulta [Working with Amazon RDS and Aurora PostgreSQL logs: Part 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/) (Utilizzo dei registri RDS e Aurora PostgreSQL: parte 1) e [Working with Amazon RDS and Aurora PostgreSQL logs: Part 2](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-2/) (Utilizzo dei registri RDS e Aurora PostgreSQL: parte 2). Oltre ai log PostgreSQL standard trattati in questo argomento, Aurora PostgreSQL supporta anche l'estensione di audit PostgreSQL (`pgAudit`). La maggior parte dei settori regolamentati e degli enti governativi deve mantenere un log di audit o un audit trail delle modifiche apportate ai dati per conformità ai requisiti legali. Per informazioni sull'installazione e sull'utilizzo di pgAudit, consulta [Utilizzo di pgAudit per registrare l'attività del database](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md). Aurora crea un file di log separato per le istanze database con la funzionalità di pausa automatica abilitata. Questo file instance.log registra tutti i motivi per cui le istanze database non possono essere messe in pausa quando previsto. Per ulteriori informazioni sul comportamento dei file di log delle istanze e sulla funzionalità di pausa automatica di Aurora, consulta [Monitoraggio delle attività di pausa e ripresa di Aurora Serverless v2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-administration.html#autopause-logging-instance-log). **Topics** + [Parametri per la registrazione di log in Aurora PostgreSQL](USER_LogAccess.Concepts.PostgreSQL.overview.parameter-groups.md) + [](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md) # Parametri per la registrazione di log in Aurora PostgreSQL È possibile personalizzare il comportamento di registrazione per il cluster database Aurora PostgreSQL modificando vari parametri. Nella tabella seguente sono riportati, tra le altre impostazioni, i parametri che stabiliscono la durata di archiviazione dei log, quando ruotarli e se l'output del log è in formato CSV (valori separati da virgole). Puoi anche trovare l'output di testo inviato a STDERR, tra le altre impostazioni. Per modificare le impostazioni per i parametri modificabili, utilizza un gruppo di parametri del·cluster database personalizzato per il cluster database Aurora PostgreSQL. Per ulteriori informazioni, consulta [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md). | Parametro | Predefinita | Description | | --- | --- | --- | | log\$1destination | stderr | Imposta il formato di output per il registro. L'impostazione predefinita è `stderr`, ma puoi anche specificare il formato CSV aggiungendo `csvlog` all'impostazione. Per ulteriori informazioni, consulta [Impostazione della destinazione del registro (`stderr`, `csvlog`)](#USER_LogAccess.Concepts.PostgreSQL.Log_Format). | | log\$1filename | postgresql.log.%Y-%m-%d-%H%M | Specifica il modello per il nome del file di log. Oltre al valore predefinito, questo parametro supporta `postgresql.log.%Y-%m-%d` e `postgresql.log.%Y-%m-%d-%H` per il modello del nome del file. Per Aurora PostgreSQL versione 17.4 e successive, non è possibile modificare questo parametro. | | log\$1line\$1prefix | %t:%r:%u@%d:[%p]: | Definisce il prefisso per ogni riga di log che viene scritta in `stderr`, per annotare l'ora (%t), l'host remoto (%r), l'utente (%u), il database (%d) e l'ID del processo (%p). | | log\$1rotation\$1age | 60 | I minuti dopo i quali il file di log viene ruotato automaticamente. È possibile modificarli con un valore compreso tra 1 e 1440 minuti. Per ulteriori informazioni, consulta [Impostazione della rotazione dei file di log](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). | | log\$1rotation\$1size | – | La dimensione (KB) che stabilisce la rotazione automatica del log. È possibile modificare impostando un valore compreso nell’intervallo compreso tra 50.000 e 1.000.000 di kilobyte. Per ulteriori informazioni, consulta [Impostazione della rotazione dei file di log](#USER_LogAccess.Concepts.PostgreSQL.log_rotation). | | rds.log\$1retention\$1period | 4320 | I registri PostgreSQL più vecchi del numero di minuti specificato vengono eliminati. Il valore di default di 4.320 minuti elimina i file di log dopo 3 giorni. Per ulteriori informazioni, consulta [Impostazione del periodo di retention dei log](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period). | Per identificare i problemi dell'applicazione, puoi cercare fallimenti di query, errori di accesso, deadlock ed errori irreversibili del server nel registro. Ad esempio, supponi di convertire un'applicazione legacy da Oracle ad Aurora PostgreSQL, ma non tutte le query sono state convertite correttamente. Queste query formattate in modo errato generano messaggi di errore nei registri che puoi utilizzare per identificare i problemi. Per ulteriori informazioni sulla registrazione delle query, consulta [](USER_LogAccess.Concepts.PostgreSQL.Query_Logging.md). Negli argomenti seguenti sono disponibili informazioni su come impostare vari parametri che controllano i dettagli di base dei log PostgreSQL. **Topics** + [Impostazione del periodo di retention dei log](#USER_LogAccess.Concepts.PostgreSQL.log_retention_period) + [Impostazione della rotazione dei file di log](#USER_LogAccess.Concepts.PostgreSQL.log_rotation) + [Impostazione della destinazione del registro (`stderr`, `csvlog`)](#USER_LogAccess.Concepts.PostgreSQL.Log_Format) + [Informazioni sul parametro log\$1line\$1prefix](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix) ## Impostazione del periodo di retention dei log Il parametro `rds.log_retention_period` specifica per quanto tempo il cluster database Aurora PostgreSQL conserva i file di log. L'impostazione predefinita è 3 giorni (4.320 minuti), ma è possibile impostare qualsiasi valore compreso tra 1 giorno (1.440 minuti) e 7 giorni (10.080 minuti). Assicurati che il cluster database Aurora PostgreSQL abbia spazio di archiviazione sufficiente per contenere i file di log per il periodo di tempo specificato. Ti consigliamo di pubblicare regolarmente i log su Amazon CloudWatch Logs in modo da poter visualizzare e analizzare i dati di sistema molto tempo dopo che i log sono stati rimossi dal cluster Aurora PostgreSQL DB. Per ulteriori informazioni, consulta [Pubblicazione di log Aurora PostgreSQL in Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md). Dopo aver impostato la CloudWatch pubblicazione, Aurora elimina un registro solo dopo la pubblicazione su Logs. CloudWatch Amazon Aurora comprime i log PostgreSQL meno recenti quando lo spazio di archiviazione per l'istanza database raggiunge una determinata soglia. Aurora comprime i file utilizzando l'utilità di compressione gzip. Per ulteriori informazioni, consulta il sito web di [gzip](https://www.gzip.org). Quando lo spazio di archiviazione per l'istanza database si riduce e tutti i log disponibili sono compressi, si riceve un avviso del tipo seguente: ``` Warning: local storage for PostgreSQL log files is critically low for this Aurora PostgreSQL instance, and could lead to a database outage. ``` Se lo spazio di archiviazione non è sufficiente, Aurora potrebbe eliminare i log PostgreSQL compressi prima della fine del periodo di conservazione specificato. Se ciò accade, viene visualizzato un messaggio simile al seguente: ``` The oldest PostgreSQL log files were deleted due to local storage constraints. ``` ## Impostazione della rotazione dei file di log Per impostazione predefinita, nuovi file di log vengono creati da Aurora ogni ora. La tempistica è controllata dal parametro `log_rotation_age`. Questo parametro ha un valore predefinito di 60 (minuti), ma è possibile impostarlo su qualsiasi valore tra 1 minuto e 24 ore (1.440 minuti). Al momento della rotazione, viene creato un nuovo file di log distinto. Il file è denominato in base al modello specificato dal parametro `log_filename`. I file di log possono anche essere ruotati in base alle loro dimensioni, come specificato dal parametro `log_rotation_size`. Questo parametro specifica che il log deve essere ruotato quando raggiunge la dimensione specificata (in kilobyte). Il valore di timeout predefinito per `log_rotation_size` è di 100.000 kB (kilobyte) per un cluster di database Aurora PostgreSQL, ma puoi impostare questo parametro a qualsiasi valore compreso tra 50.000 e 1.000.000 kilobyte. I nomi dei file di registro si basano sul modello di nome di file specificato nel parametro `log_filename`. Le impostazioni disponibili per questo parametro sono le seguenti: + `postgresql.log.%Y-%m-%d` : formato predefinito per il nome del file di registro. Include l'anno, il mese e la data nel nome del file di log. + `postgresql.log.%Y-%m-%d-%H`: include l'ora nel formato del nome del file di registro. + `postgresql.log.%Y-%m-%d-%H%M`: include ora:minuto nel formato del nome del file di log. Se imposti il parametro `log_rotation_age` su un valore inferiore a 60 minuti, imposta il parametro `log_filename` sul formato minuti. Per ulteriori informazioni, consulta [https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-AGE](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-AGE) e [https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-SIZE](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-ROTATION-SIZE) nella documentazione di PostgreSQL. ## Impostazione della destinazione del registro (`stderr`, `csvlog`) Per impostazione predefinita, Aurora PostgreSQL genera i log in formato errore standard (stderr). Questo formato è l'impostazione predefinita per il parametro `log_destination`. Ogni messaggio ha un prefisso che utilizza il modello specificato nel parametro `log_line_prefix`. Per ulteriori informazioni, consulta [Informazioni sul parametro log\$1line\$1prefix](#USER_LogAccess.Concepts.PostgreSQL.Log_Format.log-line-prefix). Aurora PostgreSQL può anche generare log in formato `csvlog`. Il formato `csvlog` è utile per analizzare i dati dei registri in formato CSV. Ad esempio, supponi di utilizzare l'estensione `log_fdw` per lavorare con i log come tabelle esterne. La tabella esterna creata sui file di log di `stderr` contiene una singola colonna con i dati degli eventi di log. Aggiungendo `csvlog` al parametro `log_destination`, ottieni il file di log in formato CSV con le demarcazioni per le diverse colonne della tabella esterna. In tal modo puoi ordinare e analizzare i log più facilmente. Se specifichi `csvlog` per questo parametro, tieni presente che vengono generati entrambi i file `stderr` e `csvlog`. Ti consigliamo di monitorare lo spazio di archiviazione consumato dai registri tenendo conto di `rds.log_retention_period` e delle altre impostazioni che influiscono sull'archiviazione e sulla rotazione dei registri. Utilizzando `stderr` e `csvlog` lo spazio di archiviazione consumato dai registri aumenta più del doppio. Se aggiungi `csvlog` a `log_destination` e vuoi ripristinare solo `stderr`, devi reimpostare il parametro. Per farlo, nella console Amazon RDS apri il gruppo di parametri del·cluster database personalizzato per la tua istanza. Scegli il parametro `log_destination`, seleziona **Edit parameter** (Modifica parametro), quindi **Reset** (Reimposta). Per ulteriori informazioni sulla configurazione dei registri, consulta [Utilizzo dei log Amazon RDS e Aurora PostgreSQL: Parte 1](https://aws.amazon.com/blogs/database/working-with-rds-and-aurora-postgresql-logs-part-1/). ## Informazioni sul parametro log\$1line\$1prefix Il formato di log `stderr` applica il prefisso a ogni messaggio di log con i dettagli specificati dal parametro `log_line_prefix`. Il valore predefinito è: ``` %t:%r:%u@%d:[%p]:t ``` A partire da Aurora PostgreSQL versione 16, è anche possibile scegliere: ``` %m:%r:%u@%d:[%p]:%l:%e:%s:%v:%x:%c:%q%a ``` Ogni voce del log inviata a stderr include le seguenti informazioni in base al valore selezionato: + `%t` - Ora della voce di log senza millisecondi + `%m` - Ora della voce di log con millisecondi + `%r` - Indirizzo dell'host remoto + `%u@%d` - Nome utente @ nome del database + `[%p]` - ID del processo, se disponibile + `%l` - Numero di riga di log per sessione + `%e` - Codice di errore SQL + `%s` - Timestamp di inizio del processo + `%v` - ID della transazione virtuale + `%x` - ID della transazione + `%c` - ID della sessione + `%q` - Terminatore non di sessione + `%a` - Nome dell’applicazione # È possibile raccogliere informazioni più approfondite sulle attività dei database, tra cui query, query in attesa di blocchi, checkpoint e molti altri dettagli impostando alcuni parametri elencati nella tabella seguente. Questo argomento illustra la registrazione delle query. | Parametro | Predefinita | Description | | --- | --- | --- | | log\$1connections | – | Registra ogni connessione riuscita. Per informazioni su come utilizzare questo parametro con `log_disconnections` per rilevare l'abbandono della connessione, consulta [](AuroraPostgreSQL.BestPractices.connection_pooling.md). | | log\$1disconnections | – | Registra il momento in cui termina ciascuna sessione e la relativa durata. Per informazioni su come utilizzare questo parametro con `log_connections` per rilevare l'abbandono della connessione, consulta [](AuroraPostgreSQL.BestPractices.connection_pooling.md). | | log\$1checkpoints | – | Non applicabile per Aurora PostgreSQL | | log\$1lock\$1waits | – | Registra lunghe attese di lock. Per impostazione predefinita, questo parametro non è impostato. | | log\$1min\$1duration\$1sample | – | Imposta il tempo (ms) minimo di esecuzione oltre il quale viene registrato un campione di istruzioni. La dimensione del campione viene impostata utilizzando il parametro log\$1statement\$1sample\$1rate. | | log\$1min\$1duration\$1statement | – | Viene registrata qualsiasi istruzione SQL che viene eseguita per il periodo specificato o per più tempo. Per impostazione predefinita, questo parametro non è impostato. L'attivazione di questo parametro può aiutarti a trovare query non ottimizzate. | | log\$1statement | – | Imposta il tipo di istruzioni registrate. Per impostazione predefinita, questo parametro non è impostato, ma puoi modificarlo in `all`, `ddl` o `mod` per specificare i tipi di istruzioni SQL che vuoi registrare. Se specifichi un valore diverso da `none` per questo parametro, dovrai adottare ulteriori misure per evitare l'esposizione delle password nei file di log. Per ulteriori informazioni, consulta [Riduzione del rischio di esposizione delle password quando si utilizza la registrazione delle queryRiduzione del rischio di esposizione delle password](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk). | | log\$1statement\$1sample\$1rate | – | La percentuale di istruzioni che superano il tempo specificato in `log_min_duration_sample` da registrare, espressa come valore in virgola mobile compreso tra 0,0 e 1,0. | | log\$1statement\$1stats | – | Scrive le statistiche cumulative sulla prestazione nel registro del server. | ## Utilizzo della registrazione per trovare query lente È possibile registrare istruzioni e query SQL per trovare le query con prestazioni lente. Puoi attivare questa funzionalità modificando le impostazioni nei parametri `log_statement` e `log_min_duration` come descritto in questa sezione. Prima di attivare la registrazione delle query per il cluster database Aurora PostgreSQL, è necessario essere consapevoli della possibile esposizione delle password nei registri e di come mitigare i rischi. Per ulteriori informazioni, consulta [Riduzione del rischio di esposizione delle password quando si utilizza la registrazione delle queryRiduzione del rischio di esposizione delle password](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk). Di seguito sono disponibili informazioni di riferimento sui parametri `log_statement` e `log_min_duration`.log\$1statement Questo parametro specifica il tipo di istruzioni SQL che devono essere inviate al registro. Il valore predefinito è `none`. Se modifichi questo parametro in `all`, `ddl` o `mod`, esegui le azioni consigliate per ridurre il rischio di esporre le password nei log. Per ulteriori informazioni, consulta [Riduzione del rischio di esposizione delle password quando si utilizza la registrazione delle queryRiduzione del rischio di esposizione delle password](#USER_LogAccess.Concepts.PostgreSQL.Query_Logging.mitigate-risk). **tutto** Registra tutte le istruzioni. Questa impostazione è consigliata per il debug. **ddl** Registra tutte le istruzioni DDL (Data Definition Language), come CREATE, ALTER, DROP e così via. **mod** Registra tutte le istruzioni DDL e DML (Data Manipulation Language), come INSERT, UPDATE e DELETE, che modificano i dati. **nessuno** Nessuna istruzione SQL viene registrata. Consigliamo questa impostazione per evitare il rischio di esporre le password nei registri.log\$1min\$1duration\$1statement Viene registrata qualsiasi istruzione SQL che viene eseguita per il periodo specificato o per più tempo. Per impostazione predefinita, questo parametro non è impostato. L'attivazione di questo parametro può aiutarti a trovare query non ottimizzate. **–1–2147483647** Il numero di millisecondi (ms) di runtime durante il quale un'istruzione viene registrata. **Per configurare la registrazione delle query** Questi passaggi presuppongono che il cluster database Aurora PostgreSQL utilizzi un gruppo di parametri cluster database personalizzato. 1. Imposta il parametro `log_statement` su `all`. L'esempio seguente mostra le informazioni scritte nel file `postgresql.log` con questa impostazione del parametro. ``` 2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:LOG: statement: SELECT feedback, s.sentiment,s.confidence FROM support,aws_comprehend.detect_sentiment(feedback, 'en') s ORDER BY s.confidence DESC; 2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:LOG: QUERY STATISTICS 2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:DETAIL: ! system usage stats: ! 0.017355 s user, 0.000000 s system, 0.168593 s elapsed ! [0.025146 s user, 0.000000 s system total] ! 36644 kB max resident size ! 0/8 [0/8] filesystem blocks in/out ! 0/733 [0/1364] page faults/reclaims, 0 [0] swaps ! 0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent ! 19/0 [27/0] voluntary/involuntary context switches 2022-10-05 22:05:52 UTC:52.95.4.1(11335):postgres@labdb:[3639]:STATEMENT: SELECT feedback, s.sentiment,s.confidence FROM support,aws_comprehend.detect_sentiment(feedback, 'en') s ORDER BY s.confidence DESC; 2022-10-05 22:05:56 UTC:52.95.4.1(11335):postgres@labdb:[3639]:ERROR: syntax error at or near "ORDER" at character 1 2022-10-05 22:05:56 UTC:52.95.4.1(11335):postgres@labdb:[3639]:STATEMENT: ORDER BY s.confidence DESC; ----------------------- END OF LOG ---------------------- ``` 1. Impostare il parametro `log_min_duration_statement`. L'esempio seguente mostra le informazioni scritte nel file `postgresql.log` quando il parametro è impostato su `1`. Le query che superano la durata specificata nel parametro `log_min_duration_statement` vengono registrate. Di seguito viene riportato un esempio. Puoi visualizzare il file di log per il cluster database Aurora PostgreSQL nella console Amazon RDS. ``` 2022-10-05 19:05:19 UTC:52.95.4.1(6461):postgres@labdb:[6144]:LOG: statement: DROP table comments; 2022-10-05 19:05:19 UTC:52.95.4.1(6461):postgres@labdb:[6144]:LOG: duration: 167.754 ms 2022-10-05 19:08:07 UTC::@:[355]:LOG: checkpoint starting: time 2022-10-05 19:08:08 UTC::@:[355]:LOG: checkpoint complete: wrote 11 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=1.013 s, sync=0.006 s, total=1.033 s; sync files=8, longest=0.004 s, average=0.001 s; distance=131028 kB, estimate=131028 kB ----------------------- END OF LOG ---------------------- ``` ### Riduzione del rischio di esposizione delle password quando si utilizza la registrazione delle query Ti consigliamo di mantenere `log_statement` impostato su `none` per evitare di esporre le password. Se imposti `log_statement` su `all`, `ddl` o `mod`, ti consigliamo di eseguire una o più delle seguenti operazioni. + Per il client, applica la crittografia delle informazioni sensibili. Per ulteriori informazioni, consulta [Encryption Options](https://www.postgresql.org/docs/current/encryption-options.html) (Opzioni di crittografia) nella documentazione di PostgreSQL. Usa le opzioni `ENCRYPTED` (e `UNENCRYPTED`) delle istruzioni `CREATE` e `ALTER`. Per ulteriori informazioni, consulta [CREATE USER](https://www.postgresql.org/docs/current/sql-createuser.html) nella documentazione di PostgreSQL. + Per il cluster database Aurora PostgreSQL, configura e usa l'estensione di audit PostgreSQL (pgAudit). Questa estensione oscura le informazioni sensibili nelle istruzioni CREATE e ALTER inviate al registro. Per ulteriori informazioni, consulta [Utilizzo di pgAudit per registrare l'attività del database](Appendix.PostgreSQL.CommonDBATasks.pgaudit.md). + Limita CloudWatch l'accesso ai log. + Utilizza meccanismi di autenticazione più efficaci come IAM.