

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 flussi
<a name="cdc-monitoring"></a>

**Importante**  
Questa funzionalità è fornita come AWS anteprima ed è soggetta a modifiche. Per ulteriori informazioni, consulta la sezione 2, Beta e anteprime, nei Termini di [AWS servizio](https://aws.amazon.com/service-terms/). Per ulteriori informazioni sui prezzi degli stream CDC, consulta la pagina dei prezzi di [Aurora DSQL](https://aws.amazon.com/rds/aurora/dsql/pricing/).  
Prima della disponibilità generale, aggiungeremo nuovi tipi di operazioni (`"op": "u"`per gli aggiornamenti) al payload dello stream. Per garantire che l'applicazione gestisca queste modifiche senza modifiche, considera qualsiasi `op` valore non riconosciuto come un problema, applicando il payload. `after` Per informazioni dettagliate, vedi [Comprensione dei record CDC](cdc-record-format.md).

Quando Aurora DSQL rileva un errore nell'invio di un record CDC, lo stream passa allo stato. `IMPAIRED` Uno stream danneggiato continua a elaborare e fornire altri record: Aurora DSQL riprova solo il record con errore. Aurora DSQL misura il ritardo di replica del record più vecchio non consegnato e il ritardo aumenta fino alla risoluzione del problema. Aurora DSQL conserva internamente le modifiche non consegnate per una settimana.

Se risolvi il problema di fondo in questa finestra, il tentativo successivo ha esito positivo, lo stato di errore si cancella e lo stream ritorna a. `ACTIVE` Risolvi il problema esterno (policy IAM, AWS KMS chiave, capacità di Amazon Kinesis e così via) e Aurora DSQL riprova automaticamente.

Se il ritardo di replica supera la soglia di errore, il flusso passa a. `FAILED`

**Importante**  
Uno stream non riuscito non può essere ripristinato. È necessario eliminare lo stream fallito e crearne uno nuovo.

## Ciclo di vita dello stream
<a name="cdc-lifecycle"></a>

Uno stream passa attraverso i seguenti stati durante il suo ciclo di vita:
+ **`CREATING`**— Aurora DSQL sta configurando lo stream. Aurora DSQL non fornisce ancora record CDC.
+ **`ACTIVE`**— Lo stream è operativo e fornisce i record CDC al bersaglio.
+ **`IMPAIRED`**— Lo stream ha riscontrato un problema che richiede l'intervento dell'utente. Aurora DSQL riprova il record non riuscito con un backoff esponenziale, sebbene altri record possano continuare a fornire. Aurora DSQL misura il ritardo di replica del record più vecchio non consegnato e il ritardo aumenta fino alla risoluzione del problema. Aurora DSQL memorizza internamente le modifiche non consegnate per una settimana. Per informazioni, consulta [Riferimento al codice di errore](#cdc-failure-reasons).
+ **`FAILED`**— Lo stream ha riscontrato un errore persistente e non fornisce più i record CDC. Uno stream non riuscito non può essere ripristinato ed è necessario eliminarlo. Consulta le [Riferimento al codice di errore](#cdc-failure-reasons) condizioni che fanno sì che uno stream entri in questo stato.
+ **`DELETING`**— Aurora DSQL sta rimuovendo le risorse di streaming.
+ **`DELETED`**— Aurora DSQL ha eliminato lo stream. Al termine dell'eliminazione, `GetStream` restituisce un. `ResourceNotFoundException`

Chiama `GetStream` per visualizzare lo stato dello streaming in qualsiasi momento. Quando lo stream è `IMPAIRED` o`FAILED`, la risposta include un `statusReason` oggetto con il codice di errore e il timestamp. Per ulteriori dettagli sui campi di `GetStream` risposta, consulta [GetStream](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetStream.html)Amazon Aurora DSQL API Reference.

## Risoluzione dei problemi relativi a uno stream danneggiato o non riuscito
<a name="cdc-troubleshooting"></a>

Segui questi passaggi quando uno stream CDC si interrompe o fallisce. Se lo stream lo è`FAILED`, non puoi recuperarlo: elimina lo stream, risolvi il problema sottostante e creane uno nuovo.

1. **Visualizza lo stato dello stream.** Chiama `GetStream` e verifica il `status` campo. Se lo stato è`ACTIVE`, lo stream è integro.

   ```
   aws dsql get-stream \
     --cluster-identifier {{cluster-id}} \
     --stream-identifier {{stream-id}} \
     --region {{region}}
   ```

1. **Leggi il codice di errore.** Se lo stato è `IMPAIRED` o`FAILED`, la risposta include un `statusReason` oggetto. Il `error` campo contiene il codice di errore.

   ```
   {
       "status": "IMPAIRED",
       "statusReason": {
           "error": "KINESIS_THROUGHPUT_EXCEEDED",
           "updatedAt": "2025-01-15T14:30:00Z"
       }
   }
   ```

1. **Segui la riparazione.** Se lo stream lo è`IMPAIRED`, cerca il codice di errore nella tabella seguente e applica la correzione consigliata. Aurora DSQL riprova automaticamente dopo aver risolto il problema sottostante. Se lo stream lo è`FAILED`, eliminalo, risolvi il problema e crea un nuovo stream.

## Riferimento al codice di errore
<a name="cdc-failure-reasons"></a>

La tabella seguente descrive ogni codice di errore, la sua causa, se lo stream può essere ripristinato e i passaggi per risolverlo.


| Codice di errore | Causa | Recuperabile? | Come risolvere | 
| --- |--- |--- |--- |
| KINESIS\_THROUGHPUT\_EXCEEDED | Il flusso di dati Kinesis ha superato il limite di velocità effettiva o ha limitato le operazioni di AWS KMS crittografia sul flusso di dati Kinesis e il ritardo di replica è aumentato. | Sì | Aumenta il numero di shard nel flusso di dati Kinesis o passa alla modalità di capacità su richiesta. Se il flusso di dati Kinesis utilizza una chiave gestita AWS KMS dal cliente, verifica che la quota di richiesta della chiave sia sufficientemente ampia. Dopo aver aumentato la capacità, Aurora SQL riprova automaticamente. | 
| KINESIS\_STREAM\_NOT\_FOUND | Il flusso di dati Kinesis di destinazione non esiste più. | No | Lo stream passa direttamente a. FAILED Elimina il flusso CDC e creane uno nuovo che punti a un flusso di dati Kinesis valido. | 
| ROLE\_ACCESS\_DENIED | Aurora DSQL non può assumere il ruolo IAM specificato nella definizione del target. La AWS STS AssumeRole chiamata è tornata. AccessDenied | Sì | Verifica che la politica di attendibilità del ruolo consenta al principale del servizio Aurora DSQL (dsql.amazonaws.com) di assumerlo. Verifica che le aws:SourceArn condizioni aws:SourceAccount and corrispondano al tuo cluster. Per informazioni dettagliate, vedi [Politica di fiducia per i ruoli di servizio](cdc-iam.md#cdc-iam-trust-policy). Dopo aver corretto la politica di attendibilità, Aurora SQL riprova automaticamente. | 
| KINESIS\_ACCESS\_DENIED | Il ruolo assunto non è autorizzato a scrivere nel flusso di dati Kinesis. Kinesis è tornato. AccessDeniedException | Sì | Aggiungi kinesis:PutRecord e kinesis:PutRecords autorizzazioni alla policy del ruolo per il flusso di dati Kinesis di destinazione Amazon Resource Name (ARN). Dopo aver corretto il criterio, Aurora DSQL riprova automaticamente. | 
| KINESIS\_KMS\_ACCESS\_DENIED | Il ruolo assunto non è autorizzato a utilizzare la AWS KMS chiave che crittografa il flusso di dati Kinesis. Questo errore riguarda la negazione dell' AWS KMS accesso e gli stati delle chiavi non validi. | Sì | Verifica che il ruolo disponga dell'kms:GenerateDataKeyautorizzazione sulla AWS KMS chiave utilizzata dal flusso di dati Kinesis. Verifica inoltre che la AWS KMS chiave sia abilitata e valida. Questa chiave è la chiave di crittografia del flusso di dati Kinesis, non la chiave del AWS KMS cluster. Per informazioni dettagliate, vedi [Politica di autorizzazione dei ruoli di servizio](cdc-iam.md#cdc-iam-permissions-policy). Dopo aver corretto le autorizzazioni o lo stato della chiave, Aurora DSQL riprova automaticamente. | 
| KINESIS\_OVERSIZE\_RECORD | Un record CDC ha superato la dimensione massima di record configurata nel flusso di dati Kinesis. | Sì | Aumento MaxRecordSizeInKiB del flusso di dati Kinesis a 10240 (10 MiB). Puoi aggiornare questa impostazione su un flusso di dati Kinesis esistente senza eliminarlo. Dopo aver aumentato il limite, Aurora DSQL riprova automaticamente il record sovradimensionato e lo stream torna a. ACTIVE | 
| CLUSTER\_CMK\_INACCESSIBLE | La chiave gestita AWS KMS dal cliente che crittografa il cluster Aurora DSQL è inaccessibile. | Sì | Verifica la politica e lo stato della AWS KMS chiave. Re-enable o ripristina l'accesso alla chiave. Dopo che la chiave diventa nuovamente accessibile, lo stream torna aACTIVE. | 

La tabella precedente elenca tutti `StreamFailureErrorCode` i valori. Per informazioni dettagliate sul campo di `statusReason` risposta, consulta [GetStream](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetStream.html)[Amazon Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/CHAP_api_reference.html) API Reference.

## Ripristino di uno stream danneggiato
<a name="cdc-how-recovery-works"></a>

La maggior parte degli errori trasferisce innanzitutto lo stream a. `IMPAIRED` Uno stream danneggiato continua a elaborare altri record e riprova automaticamente il record con errore. Uno `FAILED` stream non è recuperabile: devi eliminarlo e crearne uno nuovo.
+ **Per gli errori recuperabili:** risolvi il problema esterno (policy IAM, AWS KMS chiave, capacità Kinesis o limite di dimensione del record Kinesis). Il successivo tentativo riuscito cancella lo stato di errore e riporta lo stream allo stesso. `ACTIVE`
+ **Per`KINESIS_STREAM_NOT_FOUND`:** lo stream passa direttamente a. `FAILED` Elimina lo stream fallito e creane uno nuovo che punti a un flusso di dati Kinesis valido.

Per tutti gli altri codici di errore, se il ritardo di replica supera la soglia di errore prima di risolvere il problema, il flusso passa da a. `IMPAIRED` `FAILED` Uno stream fallito non può tornare a. `ACTIVE` Elimina lo stream non riuscito, risolvi il problema sottostante e creane uno nuovo.

## Monitoraggio dello stato dello stream
<a name="cdc-stream-health"></a>

Utilizza le CloudWatch metriche e l'`GetStream`API per monitorare lo stato dello streaming. CloudWatchle metriche forniscono una visibilità continua sulle prestazioni della pipeline CDC e `GetStream` forniscono il codice di errore specifico quando uno stream è compromesso o fallito.

Per l'elenco completo delle metriche CDC, tra cui,, e`IsImpaired`, `BehindSourceLag` vedi. `PublishedBytes` `PublishedRecords` [CloudWatch metriche per gli stream CDC](#cdc-cloudwatch-metrics) Per ulteriori dettagli sui campi di `GetStream` risposta, consulta [GetStream](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetStream.html)Amazon Aurora DSQL API Reference.

## CloudWatch metriche per gli stream CDC
<a name="cdc-cloudwatch-metrics"></a>

Utilizza le seguenti CloudWatch metriche per monitorare lo stato e la velocità effettiva di ogni stream CDC. Aurora DSQL pubblica queste metriche nello spazio dei `AWS/AuroraDSQL` nomi con le dimensioni e. `ClusterId` `StreamId` L'ultima metrica è una metrica standard di Amazon Kinesis nel namespace che misura `AWS/Kinesis` il ritardo di lettura a valle.

**Nota**  
Aurora DSQL pubblica anche le `StreamDPU` metriche and nel `AWS/AuroraDSQL` namespace per il monitoraggio dell'utilizzo `BytesStreamed` e della fatturazione. Per [Metriche dello stream CDC](cloudwatch-monitoring.md#cdc-stream-metrics) le descrizioni, vedere.


| Nome parametro | Statistica utile | Description | 
| --- |--- |--- |
| IsImpaired | Massimo | Indica se lo streaming è compromesso. Il valore è 1 quando lo stream è nello IMPAIRED stato e 0 quando lo stream è integro. Aurora DSQL emette questa metrica continuamente per ogni stream attivo o compromesso. Usa questa metrica per creare un CloudWatch allarme che ti avvisa quando uno streaming viene interrotto. | 
| BehindSourceLag | Media | Il ritardo, in millisecondi, tra il momento in cui una transazione viene eseguita in Aurora DSQL e il momento in cui il sistema CDC elabora il record risultante. Un valore crescente indica che la pipeline CDC è in ritardo rispetto al carico di lavoro di scrittura. | 
| PublishedBytes | Somma | I byte totali dei record CDC che Aurora DSQL ha scritto sulla destinazione durante il periodo. Usa questa metrica insieme al numero di shard Kinesis per determinare se hai fornito una capacità di scrittura sufficiente. | 
| PublishedRecords | Somma | Il numero totale di record CDC che Aurora DSQL ha scritto sulla destinazione durante il periodo. Ogni modifica di riga confermata produce un record. | 
| GetRecords.IteratorAgeMilliseconds (AWS/Kinesis) | Media | Una metrica Kinesis standard che riporta l'età dell'ultimo record letto dal flusso di dati Kinesis dall'app downstream, in millisecondi. Usa la dimensione. StreamName Un valore crescente indica che l'app downstream non riesce a tenere il passo con la velocità con cui Aurora DSQL scrive i record CDC su Kinesis. | 

La scheda **Monitoraggio** della console Aurora DSQL mostra un valore di latenza **end-to-end medio che combina `BehindSourceLag` (latenza** sorgente CDC) e (ritardo del lettore Kinesis). `GetRecords.IteratorAgeMilliseconds` Questo valore combinato rappresenta il ritardo totale tra il commit del database e la lettura a valle.

## Le migliori pratiche di monitoraggio
<a name="cdc-monitoring-best-practices"></a>

Utilizza le seguenti pratiche per rilevare e risolvere i problemi della pipeline CDC prima che influiscano sui sistemi a valle.

**Attiva gli allarmi `BehindSourceLag`**  
Crea un CloudWatch allarme che si attiva quando `BehindSourceLag` supera una soglia importante per il tuo carico di lavoro. Ad esempio, imposta 60 secondi per un obiettivo di latenza di un minuto. Un aumento costante di questa metrica significa che la pipeline CDC è in ritardo. Se il ritardo raggiunge la soglia di errore, lo stream passa a FAILED. Rilevare la tendenza ti dà il tempo di aumentare la capacità di Kinesis o di analizzare i problemi di throughput prima che lo stream si deteriori.

**Monitor `GetRecords.IteratorAgeMilliseconds`sul lato Kinesis**  
Anche quando Aurora DSQL fornisce i record in tempo, l'app downstream può rimanere indietro. Crea un CloudWatch allarme attivo `GetRecords.IteratorAgeMilliseconds` (nello spazio dei `AWS/Kinesis` nomi, nella dimensione`StreamName`) per rilevare il ritardo a valle in modo indipendente. Se questa metrica aumenta e `BehindSourceLag` rimane invariata, il collo di bottiglia è nell'app downstream, non in Aurora DSQL.

**Monitora `PublishedBytes`la capacità degli shard Kinesis**  
Ogni shard Kinesis supporta fino a 1 MiB al secondo per le scritture. Confrontate la `PublishedBytes` somma al minuto con la capacità totale di scrittura dello shard (numero di shard × 60 MiB al minuto). Se l'utilizzo si avvicina all'80%, aggiungete shard o passate alla modalità di capacità su richiesta prima che venga attivata la limitazione. `KINESIS_THROUGHPUT_EXCEEDED`

**Allarme attivo per il rilevamento istantaneo dei danni `IsImpaired`**  
Crea un CloudWatch allarme che si attiva quando `IsImpaired` Maximum è maggiore o uguale a `1` per un periodo di valutazione. Questo ti dà un segnale diretto quando uno stream entra `IMPAIRED` nello stato, senza eseguire il polling dell'API. Dopo lo scatto dell'allarme, chiama `GetStream` per leggere il `statusReason.error` campo e segui i passaggi di riparazione indicati. [Risoluzione dei problemi relativi a uno stream danneggiato o non riuscito](#cdc-troubleshooting)

**Sondaggio per informazioni dettagliate sullo `GetStream`stato**  
La `IsImpaired` metrica indica che uno stream è compromesso, ma l'`GetStream`API fornisce il codice di errore e il timestamp specifici. Esegui un sondaggio `GetStream` in base a una pianificazione (ad esempio, ogni cinque minuti) o in risposta a un allarme. `IsImpaired` Il `statusReason.error` campo indica cosa è andato storto. Associalo ai passaggi di risoluzione dei problemi indicati [Risoluzione dei problemi relativi a uno stream danneggiato o non riuscito](#cdc-troubleshooting) per una risoluzione rapida.

**Usa i dashboard per correlare le metriche**  
Crea una CloudWatch dashboard che mostri`IsImpaired`,, `BehindSourceLag` `PublishedRecords``PublishedBytes`, e uno `GetRecords.IteratorAgeMilliseconds` accanto all'altro. La correlazione di queste metriche ti aiuta a distinguere tra un problema della pipeline CDC (in aumento`BehindSourceLag`) e un problema di lettura a valle (che aumenta con la stabilità). `IteratorAge` `BehindSourceLag`