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à.
# Che cos'è MSK Provisioned?
I cluster Amazon MSK Provisioned offrono un'ampia gamma di caratteristiche e funzionalità per aiutarti a ottimizzare le prestazioni del cluster e soddisfare le tue esigenze di streaming. Gli argomenti seguenti descrivono la funzionalità in dettaglio.
MSK Provisioned è un'opzione di implementazione dei cluster MSK che consente di configurare e scalare manualmente i cluster Apache Kafka. Ciò offre diversi livelli di controllo sull'infrastruttura che alimenta l'ambiente Apache Kafka. Con MSK Provisioned, è possibile scegliere i tipi di istanze, i volumi di storage (broker standard) e il numero di nodi broker che costituiscono i cluster Kafka. È inoltre possibile scalare il cluster aggiungendo o rimuovendo broker man mano che le esigenze di elaborazione dei dati si evolvono. Questa flessibilità consente di ottimizzare i cluster per i requisiti specifici del carico di lavoro, sia che si tratti di massimizzare il throughput, la capacità di conservazione o altre caratteristiche prestazionali. Oltre alle opzioni di configurazione dell'infrastruttura, MSK Provisioned offre vantaggi operativi, di monitoraggio e di sicurezza di livello aziendale. Ciò include funzionalità come gli aggiornamenti della versione di Apache Kafka, la sicurezza integrata tramite crittografia e controllo degli accessi e l'integrazione con altre Servizi AWS come Amazon per il monitoraggio. CloudWatch MSK Provisioned offre due tipi principali di broker: Standard ed Express.
Per informazioni sull'API MSK Provisioned, consulta l'[Amazon MSK](https://docs.aws.amazon.com/msk/1.0/apireference/what-is-msk.html) API Reference.
# Inizia a usare Amazon MSK
In questa sezione viene illustrato un esempio di come creare un cluster MSK, produrre e utilizzare dati, nonché monitorare l'integrità del cluster utilizzando i parametri. Questo esempio non rappresenta tutte le opzioni che è possibile scegliere quando si crea un cluster MSK. In diverse parti di questo tutorial verranno scelte opzioni predefinite per semplicità. Ciò non significa che siano le uniche opzioni che funzionano per la configurazione di un cluster MSK o delle istanze client.
**Topics**
+ [Fase 1: creare un cluster MSK Provisioned](create-cluster.md)
+ [Fase 2: creazione di un ruolo IAM che conceda l'accesso alla creazione di argomenti nel cluster Amazon MSK](create-client-iam-role.md)
+ [Passaggio 3: creazione di un computer client](create-client-machine.md)
+ [Fase 4: creare un argomento nel cluster Amazon MSK](create-topic.md)
+ [Passaggio 5: produzione e utilizzo di dati](produce-consume.md)
+ [Fase 6: Usa Amazon CloudWatch per visualizzare i parametri di Amazon MSK](view-metrics.md)
+ [Passaggio 7: Eliminare le AWS risorse create per questo tutorial](delete-cluster.md)
# Fase 1: creare un cluster MSK Provisioned
In questa fase di [Guida introduttiva all'uso di Amazon MSK](getting-started.md), crei un cluster Amazon MSK Provisioned. Per **creare questo cluster, si utilizza l'opzione Quick** create Console di gestione AWS in.
**Per creare un cluster Amazon MSK utilizzando Console di gestione AWS**Crea un cluster utilizzando il Console di gestione AWS
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Scegli **Crea cluster**.
1. Per **Metodo di creazione**, lascia selezionata l'opzione **Creazione rapida**. L'opzione **Creazione rapida** consente di creare un cluster con le impostazioni predefinite.
1. Per **Nome cluster**, inserisci un nome descrittivo per il cluster. Ad esempio, **MSKTutorialCluster**.
1. **Per le proprietà generali del cluster, procedi come segue:**
1. Per il **tipo di cluster**, scegli **Provisioned.**
1. Scegli una **versione di Apache Kafka** da eseguire sui broker. Scegli **Visualizza compatibilità tra le versioni per visualizzare** una tabella di confronto.
1. Per **il tipo di broker**, scegli i broker Standard o Express.
1. Scegli la **dimensione del broker**.
1. Dalla tabella in **Tutte le impostazioni del cluster**, copia i valori delle seguenti impostazioni e salvali perché ti serviranno più avanti in questo tutorial:
+ VPC
+ Sottoreti
+ Gruppi di sicurezza associati al VPC
1. Scegli **Crea cluster**.
1. Verifica lo **Stato** del cluster nella pagina **Riepilogo del cluster**. Quando Amazon MSK assegna il cluster, lo stato passa da **Creazione in corso** ad **Attivo**. Quando lo stato è **Attivo**, puoi connetterti al cluster. Per ulteriori informazioni sugli stati del cluster, consulta la pagina [Comprendi gli stati del cluster MSK Provisioned](msk-cluster-states.md).
**Fase successiva**
[Fase 2: creazione di un ruolo IAM che conceda l'accesso alla creazione di argomenti nel cluster Amazon MSK](create-client-iam-role.md)
# Fase 2: creazione di un ruolo IAM che conceda l'accesso alla creazione di argomenti nel cluster Amazon MSK
In questo passaggio, eseguirai due attività. La prima attività consiste nel creare una policy IAM che consenta l'accesso alla creazione di argomenti nel cluster e all'invio di dati a tali argomenti. La seconda attività consiste nel creare un ruolo IAM e associarvi questa policy. In un passaggio successivo, si crea un computer client che assume questo ruolo e lo utilizza per creare un argomento nel cluster e per inviare dati a quell'argomento.
**Creazione di una policy IAM che consenta di creare argomenti e scrivere su di essi**Creazione di una policy IAM
1. Aprire la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Nel riquadro di navigazione, seleziona **Policy**.
1. Scegli **Crea policy**.
1. In **Policy editor**, scegli **JSON**, quindi sostituisci il JSON nella finestra dell'editor con il seguente JSON.
Nell'esempio seguente, sostituisci quanto segue:
+ *region*con il codice del Regione AWS luogo in cui hai creato il cluster.
+ Esempio di ID dell'account*123456789012*, con il tuo Account AWS ID.
+ *MSKTutorialCluster*e*MSKTutorialCluster*/*7d7131e1-25c5-4e9a-9ac5-ea85bee4da11-14*, con il nome del cluster e il relativo ID.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeCluster"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:cluster/MSKTutorialCluster/7d7131e1-25c5-4e9a-9ac5-ea85bee4da11-14"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/MSKTutorialCluster/*"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:group/MSKTutorialCluster/*"
]
}
]
}
```
------
Per istruzioni su come scrivere policy sicure, vedi[Controllo degli accessi IAM](iam-access-control.md).
1. Scegli **Next (Successivo)**.
1. Nella pagina **Rivedi e crea**, effettua le operazioni seguenti:
1. Per **Nome della politica**, inserisci un nome descrittivo, ad esempio**msk-tutorial-policy**.
1. In **Autorizzazioni definite in questa politica**, rivedi e and/or modifica le autorizzazioni definite nella tua politica.
1. (Facoltativo) Per facilitare l'identificazione, l'organizzazione o la ricerca della politica, scegli **Aggiungi nuovo tag per aggiungere tag** come coppie chiave-valore. Ad esempio, aggiungi un tag alla tua politica con la coppia chiave-valore e. **Environment** **Test**
Per ulteriori informazioni sull'utilizzo dei tag, consulta [Tags for AWS Identity and Access Management resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) nella *IAM User Guide*.
1. Scegli **Crea policy**.
**Creazione di un ruolo IAM e collegamento della policy al ruolo**
1. Nel riquadro di navigazione, scegli **Ruoli**, quindi scegli **Crea ruolo**.
1. Nella pagina **Seleziona un’entità attendibile**, esegui le operazioni seguenti:
1. Per **Tipo di entità attendibile**, seleziona **Servizio AWS**.
1. Per **Servizio o caso d'uso**, scegli **EC2**.
1. Per **Caso d’uso**, seleziona **EC2**.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Add permissions** (Aggiungi autorizzazioni), esegui le operazioni seguenti:
1. Nella casella di ricerca sotto **Politiche di autorizzazione**, inserisci il nome della politica che hai creato in precedenza per questo tutorial. Quindi, scegli la casella a sinistra del nome della politica.
1. (Facoltativo) Impostare un [limite delle autorizzazioni](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html). Questa è una funzionalità avanzata disponibile per i ruoli di servizio, ma non per i ruoli collegati ai servizi. Per informazioni sull'impostazione di un limite di autorizzazioni, consulta [Creating roles and attaching policies (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) nella *IAM* User Guide.
1. Scegli **Next (Successivo)**.
1. Nella pagina **Name, review, and create** (Assegna un nome, rivedi e crea), esegui le operazioni seguenti:
1. Per il **nome del ruolo**, inserisci un nome descrittivo, ad esempio. **msk-tutorial-role**
**Importante**
Quando assegni un nome a un ruolo, tieni presente quanto segue:
I nomi dei ruoli devono essere univoci all'interno del tuo Account AWS account e non possono essere resi unici per caso.
Ad esempio, non creare ruoli denominati **PRODROLE** e **prodrole**. Quando il nome di un ruolo viene utilizzato in una policy o come parte di un ARN, il nome del ruolo fa distinzione tra maiuscole e minuscole, tuttavia quando un nome di ruolo viene visualizzato ai clienti nella console, ad esempio durante il processo di accesso, il nome del ruolo non fa distinzione tra maiuscole e minuscole.
Non è possibile modificare il nome del ruolo dopo averlo creato, in quanto altre entità possono fare riferimento al ruolo.
1. (Facoltativo) In **Descrizione**, inserisci una descrizione per il ruolo.
1. **(Facoltativo) Per modificare i casi d'uso e le autorizzazioni per il ruolo, nel **Passaggio 1: Seleziona le entità attendibili** o nel **Passaggio 2: Aggiungi le sezioni relative alle autorizzazioni**, scegli Modifica.**
1. (Facoltativo) Per facilitare l'identificazione, l'organizzazione o la ricerca del ruolo, scegli **Aggiungi nuovo tag per aggiungere tag** come coppie chiave-valore. Ad esempio, aggiungi un tag al tuo ruolo con la coppia chiave-valore e. **ProductManager** **John**
Per ulteriori informazioni sull'utilizzo dei tag, consulta [Tags for AWS Identity and Access Management resources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) nella *IAM User Guide*.
1. Verificare il ruolo e quindi scegliere **Create role (Crea ruolo)**.
**Fase successiva**
[Passaggio 3: creazione di un computer client](create-client-machine.md)
# Passaggio 3: creazione di un computer client
In questa fase di Guida [introduttiva all'uso di Amazon MSK](getting-started.md), crei una macchina client. Utilizza questo computer client per creare un argomento che produce e consuma dati. Per semplicità, creerai questo computer client nel VPC associato al cluster MSK in modo che il client possa connettersi facilmente al cluster.
**Per creare un computer client**Crea una macchina client
1. Apri la console Amazon EC2 all'indirizzo [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Dal pannello di controllo della console Amazon EC2, scegli **Launch Instance (Avvia istanza)**.
1. In **Nome e tag**, in **Nome**, inserisci un nome descrittivo per la tua macchina client in modo da poterne tenere traccia facilmente. Ad esempio, **MSKTutorialClient**.
1. In **Immagini di applicazioni e sistemi operativi (Amazon Machine Image)**, per **Amazon Machine Image (AMI)**, scegli **Amazon Linux 2 AMI (HVM) - Kernel 5.10, tipo di volume SSD**.
1. **Ad **esempio, mantieni la** selezione predefinita di t2.micro.**
1. In **Coppia di chiavi (login)**, scegli una coppia di chiavi esistente o creane una nuova. Se non hai bisogno di una coppia di chiavi per connetterti alla tua istanza, puoi scegliere **Procedi senza una coppia di chiavi (scelta non consigliata)**.
Per creare una nuova coppia di chiavi, eseguire quanto descritto di seguito:
1. Scegli **Crea una nuova coppia di chiavi**.
1. Per **Key pair name** (Nome coppia di chiavi), inserire **MSKKeyPair**.
1. Per **Tipo di coppia di chiavi** e **Formato di file con chiave privata**, mantieni le selezioni predefinite.
1. Scegliere **Create key pair** (Crea coppia di chiavi).
In alternativa, è possibile utilizzare una coppia di chiavi esistente.
1. Scorri la pagina verso il basso ed espandi la sezione **Dettagli avanzati**, quindi procedi come segue:
1. Per il **profilo dell'istanza** IAM, scegli un ruolo IAM che desideri venga assunto dalla macchina client.
Se non disponi di un ruolo IAM, procedi come segue:
1. Scegli **Crea nuovo profilo IAM**.
1. Esegui i passaggi indicati nella [Fase 2: Crea un ruolo IAM](create-client-iam-role.md).
1. Scegliere **Launch Instance (Avvia istanza)**.
1. Scegliere **View Instances (Vedi istanze)**. Quindi, nella colonna **Gruppi di sicurezza**, scegli il gruppo di sicurezza associato alla nuova istanza. Copia l'ID del gruppo di sicurezza e salvalo per un secondo momento.
1. Apri la console Amazon VPC all'indirizzo [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Fai clic su **Gruppi di sicurezza** nel riquadro di navigazione. Trova il gruppo di sicurezza del quale hai salvato l'ID in [Fase 1: creare un cluster MSK Provisioned](create-cluster.md).
1. Nella scheda **Regole in entrata**, scegli **Modifica le regole in entrata**.
1. Scegli **Aggiungi regola**.
1. Nella nuova regola, scegliere **All traffic (Tutto il traffico)** nella colonna **Type (Tipo)** . Nel secondo campo della colonna **Origine**, inserisci l'ID del gruppo di sicurezza del computer client. Questo è il gruppo il cui nome hai salvato dopo aver avviato l'istanza del computer client.
1. Scegliere **Salva regole**. Ora il gruppo di sicurezza del cluster può accettare il traffico proveniente dal gruppo di sicurezza del computer client.
**Fase successiva**
[Fase 4: creare un argomento nel cluster Amazon MSK](create-topic.md)
# Fase 4: creare un argomento nel cluster Amazon MSK
In questa fase di [Guida introduttiva all'uso di Amazon MSK](getting-started.md), puoi creare un argomento utilizzando uno dei due approcci: utilizzando AWS strumenti nativi con l' CreateTopic API o utilizzando gli strumenti Apache Kafka su un computer AdminClient client.
**avvertimento**
Quando utilizzi AWS strumenti con l' CreateTopic API, verifica che il cluster soddisfi i requisiti. Per i dettagli, consulta l'[argomento Requisiti per l'utilizzo APIs](https://docs.aws.amazon.com/msk/latest/developerguide/msk-topic-operations-information.html#topic-operations-requirements).
**avvertimento**
Quando si utilizza l' AdminClient approccio, i numeri di versione di Apache Kafka utilizzati in questo tutorial sono solo esempi. Ti consigliamo di utilizzare la stessa versione del client della versione del cluster MSK. In una versione precedente del client potrebbero mancare alcune funzionalità e correzioni di bug critici.
**Topics**
+ [Creazione di un argomento utilizzando AWS gli strumenti](#create-topic-aws-tools)
+ [Determinazione della versione del cluster MSK](#find-msk-cluster-version)
+ [Creazione di un argomento sul computer client](#create-topic-client-machine)
## Creazione di un argomento utilizzando AWS gli strumenti
È possibile creare argomenti nel cluster MSK utilizzando AWS strumenti come la AWS CLI o AWS la AWS SDKs console di gestione. Questo approccio offre un modo semplificato per gestire gli argomenti senza richiedere l'accesso diretto agli strumenti client Kafka.
Per informazioni dettagliate sulla creazione di argomenti utilizzando gli AWS strumenti, consulta la guida per sviluppatori di [CreateTopic API](https://docs.aws.amazon.com/msk/latest/developerguide/msk-create-topic.html).
## Determinazione della versione del cluster MSK
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Nella barra di navigazione, scegli la regione in cui hai creato il cluster MSK.
1. Scegliete il cluster MSK.
1. Prendi nota della versione di Apache Kafka utilizzata nel cluster.
1. Sostituisci le istanze dei numeri di versione di Amazon MSK in questo tutorial con la versione ottenuta nel passaggio 3.
## Creazione di un argomento sul computer client
1. **Connect al computer client.**
1. Apri la console Amazon EC2 all'indirizzo [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Nel riquadro di navigazione, scegliere **Instances (Istanze)**. Quindi, seleziona la casella di controllo accanto al nome del computer client in cui hai creato[Passaggio 3: creazione di un computer client](create-client-machine.md).
1. Scegliere **Actions (Operazioni)**, quindi selezionare **Connect (Connetti)**. Segui le istruzioni riportate nella console per connetterti al computer client.
1. **Installa Java e configura la variabile di ambiente della versione Kafka.**
1. Installa Java sul computer client eseguendo il comando seguente.
```
sudo yum -y install java-11
```
1. Memorizza la [versione Kafka](#find-msk-cluster-version) del tuo cluster MSK nella variabile di ambiente`KAFKA_VERSION`, come mostrato nel comando seguente. Avrai bisogno di queste informazioni durante tutta la configurazione.
```
export KAFKA_VERSION={KAFKA VERSION}
```
Ad esempio, se utilizzi la versione 3.6.0, usa il comando seguente.
```
export KAFKA_VERSION=3.6.0
```
1. **Scarica ed estrai Apache Kafka.**
1. Eseguire il seguente comando per scaricare Apache Kafka.
```
wget https://archive.apache.org/dist/kafka/$KAFKA_VERSION/kafka_2.13-$KAFKA_VERSION.tgz
```
**Nota**
L'elenco seguente presenta alcune informazioni alternative per il download di Kafka che è possibile utilizzare in caso di problemi.
Se riscontri problemi di connettività o desideri utilizzare un sito mirror, prova a utilizzare il selettore dei mirror Apache, come mostrato nel comando seguente.
```
wget https://www.apache.org/dyn/closer.cgi?path=/kafka/$KAFKA_VERSION/kafka_2.13-$KAFKA_VERSION.tgz
```
Scaricate una versione appropriata direttamente dal sito Web di [Apache Kafka](https://kafka.apache.org/downloads).
1. Eseguire il comando seguente nella directory in cui è stato scaricato il file TAR nella fase precedente.
```
tar -xzf kafka_2.13-$KAFKA_VERSION.tgz
```
1. Memorizza il percorso completo della directory appena creata all'interno della `KAFKA_ROOT` variabile di ambiente.
```
export KAFKA_ROOT=$(pwd)/kafka_2.13-$KAFKA_VERSION
```
1. **Configura l'autenticazione per il tuo cluster MSK.**
1. [Trova la versione più recente](https://github.com/aws/aws-msk-iam-auth/releases/latest) della libreria client Amazon MSK IAM. Questa libreria consente alla macchina client di accedere al cluster MSK utilizzando l'autenticazione IAM.
1. Utilizzando i seguenti comandi, accedi alla `$KAFKA_ROOT/libs` directory e scarica il JAR Amazon MSK IAM associato che hai trovato nel passaggio precedente. Assicurati di sostituirlo *\$1LATEST VERSION\$1* con il numero di versione effettivo che stai scaricando.
```
cd $KAFKA_ROOT/libs
```
```
wget https://github.com/aws/aws-msk-iam-auth/releases/latest/download/aws-msk-iam-auth-{LATEST VERSION}-all.jar
```
**Nota**
Prima di eseguire qualsiasi comando Kafka che interagisca con il tuo cluster MSK, potresti dover aggiungere il file JAR Amazon MSK IAM al tuo classpath Java. Imposta la variabile di `CLASSPATH` ambiente, come mostrato nell'esempio seguente.
```
export CLASSPATH=$KAFKA_ROOT/libs/aws-msk-iam-auth-{LATEST VERSION}-all.jar
```
Questo imposta la `CLASSPATH` per l'intera sessione, rendendo il JAR disponibile per tutti i comandi Kafka successivi.
1. Vai alla `$KAFKA_ROOT/config` directory per creare il file di configurazione del client.
```
cd $KAFKA_ROOT/config
```
1. Copia le impostazioni delle proprietà seguenti e incollale in un nuovo file. Salva il file con nome **client.properties**.
```
security.protocol=SASL_SSL
sasl.mechanism=AWS_MSK_IAM
sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required;
sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler
```
1. **(Facoltativo) Regola la dimensione dell'heap Java per gli strumenti Kafka.**
Se riscontrate problemi relativi alla memoria o state lavorando con un gran numero di argomenti o partizioni, potete modificare la dimensione dell'heap Java. Per fare ciò, imposta la variabile di `KAFKA_HEAP_OPTS` ambiente prima di eseguire i comandi di Kafka.
L'esempio seguente imposta la dimensione massima e iniziale dell'heap su 512 megabyte. Regola questi valori in base ai requisiti specifici e alle risorse di sistema disponibili.
```
export KAFKA_HEAP_OPTS="-Xmx512M -Xms512M"
```
1. **Ottieni le informazioni sulla connessione al cluster.**
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Attendi che lo stato del cluster diventi **Attivo**. Questo processo potrebbe richiedere diversi minuti. Dopo che lo stato diventa **Attivo**, scegli il nome del cluster. Verrà visualizzata una pagina contenente il riepilogo del cluster.
1. Scegli **Visualizza le informazioni sul client**.
1. Copia la stringa di connessione per l'endpoint privato.
Otterrai tre endpoint per ciascuno dei broker. Memorizza una di queste stringhe di connessione nella variabile di ambiente`BOOTSTRAP_SERVER`, come illustrato nel comando seguente. Sostituire ** con il valore effettivo della stringa di connessione.
```
export BOOTSTRAP_SERVER=
```
1. **Eseguite il comando seguente per creare l'argomento.**
```
$KAFKA_ROOT/bin/kafka-topics.sh --create --bootstrap-server $BOOTSTRAP_SERVER --command-config $KAFKA_ROOT/config/client.properties --replication-factor 3 --partitions 1 --topic MSKTutorialTopic
```
Se ottenete un `NoSuchFileException` `client.properties` file, assicuratevi che questo file esista nella directory di lavoro corrente all'interno della cartella bin di Kafka.
**Nota**
Se preferite non impostare la variabile di `CLASSPATH` ambiente per l'intera sessione, potete in alternativa aggiungere la variabile come prefisso a ogni comando di Kafka. `CLASSPATH` Questo approccio applica il classpath solo a quel comando specifico.
```
CLASSPATH=$KAFKA_ROOT/libs/aws-msk-iam-auth-{LATEST VERSION}-all.jar \
$KAFKA_ROOT/bin/kafka-topics.sh --create \
--bootstrap-server $BOOTSTRAP_SERVER \
--command-config $KAFKA_ROOT/config/client.properties \
--replication-factor 3 \
--partitions 1 \
--topic MSKTutorialTopic
```
1. **(Facoltativo) Verificate che l'argomento sia stato creato correttamente.**
1. Se il comando ha esito positivo, dovrebbe apparire il seguente messaggio: `Created topic MSKTutorialTopic.`
1. Elenca tutti gli argomenti per confermare l'esistenza dell'argomento.
```
$KAFKA_ROOT/bin/kafka-topics.sh --list --bootstrap-server $BOOTSTRAP_SERVER --command-config $KAFKA_ROOT/config/client.properties
```
Se il comando ha esito negativo o si verifica un errore, consulta [Risolvi i problemi del tuo cluster Amazon MSK](troubleshooting.md) per informazioni sulla risoluzione dei problemi.
1. **(Facoltativo) Eliminate le variabili di ambiente utilizzate in questo tutorial.**
Se desideri mantenere le variabili di ambiente per i passaggi successivi di questo tutorial, salta questo passaggio. Altrimenti, potete annullare l'impostazione di queste variabili, come illustrato nell'esempio seguente.
```
unset KAFKA_VERSION KAFKA_ROOT BOOTSTRAP_SERVER CLASSPATH KAFKA_HEAP_OPTS
```
**Fase successiva**
[Passaggio 5: produzione e utilizzo di dati](produce-consume.md)
# Passaggio 5: produzione e utilizzo di dati
In questa fase di [Get Started Using Amazon MSK](getting-started.md), produci e consumi dati.
**Per produrre e consumare messaggi**Produci e consuma messaggi
1. Eseguire il comando seguente per avviare un produttore della console.
```
$KAFKA_ROOT/bin/kafka-console-producer.sh --broker-list $BOOTSTRAP_SERVER --producer.config $KAFKA_ROOT/config/client.properties --topic MSKTutorialTopic
```
1. Immettere qualsiasi messaggio desiderato e premere **Enter (Invio)**. Ripetere questa fase due o tre volte. Ogni volta che si immette una riga e si preme **Enter (Invio)**, tale riga viene inviata al cluster Apache Kafka come un messaggio separato.
1. Mantenere aperta la connessione al computer client, quindi aprire una seconda connessione separata al computer in una nuova finestra. Poiché si tratta di una nuova sessione, imposta nuovamente le variabili `KAFKA_ROOT` e di `BOOTSTRAP_SERVER` ambiente. Per informazioni su come impostare queste variabili di ambiente, consulta[Creazione di un argomento sul computer client](create-topic.md#create-topic-client-machine).
1. Esegui il comando seguente con la tua seconda stringa di connessione al computer client per creare un utente di console.
```
$KAFKA_ROOT/bin/kafka-console-consumer.sh --bootstrap-server $BOOTSTRAP_SERVER --consumer.config $KAFKA_ROOT/config/client.properties --topic MSKTutorialTopic --from-beginning
```
Dovresti iniziare a vedere i messaggi che hai inserito in precedenza quando hai usato il comando console producer.
1. Immettere altri messaggi nella finestra del produttore e guardali apparire nella finestra del consumatore.
**Fase successiva**
[Fase 6: Usa Amazon CloudWatch per visualizzare i parametri di Amazon MSK](view-metrics.md)
# Fase 6: Usa Amazon CloudWatch per visualizzare i parametri di Amazon MSK
In questa fase di [Guida introduttiva all'uso di Amazon MSK](getting-started.md), esamini i parametri di Amazon MSK in Amazon. CloudWatch
**Per visualizzare i parametri di Amazon MSK in CloudWatch**Visualizza i parametri in CloudWatch
1. Apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel riquadro di navigazione, seleziona **Parametri**.
1. Scegliere la scheda **All metrics (Tutti i parametri)**, quindi selezionare **AWS/Kafka**.
1. Per visualizzare i parametri a livello di broker, scegliere **Broker ID, Cluster Name (ID broker, nome cluster)**. Per i parametri a livello di cluster, scegliere **Cluster Name (Nome cluster)**.
1. (Facoltativo) Nel riquadro grafico, selezionate una statistica e un periodo di tempo, quindi create un CloudWatch allarme utilizzando queste impostazioni.
**Fase successiva**
[Passaggio 7: Eliminare le AWS risorse create per questo tutorial](delete-cluster.md)
# Passaggio 7: Eliminare le AWS risorse create per questo tutorial
Nel passaggio finale della [Guida introduttiva all'utilizzo di Amazon MSK](getting-started.md), elimini il cluster MSK e il computer client che hai creato per questo tutorial.
**Per eliminare le risorse utilizzando il Console di gestione AWS**Eliminare le risorse utilizzando il Console di gestione AWS
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Scegli il nome del cluster. Ad esempio, **MSKTutorialCluster**.
1. Selezionare **Actions** (Operazioni), quindi selezionare **Delete** (Elimina).
1. Apri la console Amazon EC2 all'indirizzo [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Scegli l'istanza che hai creato per il computer client, ad esempio **MSKTutorialClient**.
1. Scegli **Stato istanza**, quindi scegli **Termina istanza**.
**Eliminazione del ruolo e della policy IAM**Eliminare la politica e il ruolo IAM
1. Aprire la console IAM all'indirizzo [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Nel riquadro di navigazione, seleziona **Ruoli**.
1. Nella casella di ricerca, inserisci il nome del ruolo IAM creato per questo tutorial.
1. Seleziona il ruolo. Quindi scegli **Elimina ruolo** e conferma l'eliminazione.
1. Nel riquadro di navigazione, seleziona **Policy**.
1. Nella casella di ricerca, inserisci il nome della policy creata per questo tutorial.
1. Scegli la policy per aprirne la pagina di riepilogo. Nella pagina di **Riepilogo** della policy, seleziona **Elimina policy**.
1. Scegli **Delete** (Elimina).
# Amazon MSK: come funziona
Amazon MSK è un servizio Apache Kafka completamente gestito che semplifica la creazione e l'esecuzione di applicazioni che utilizzano Apache Kafka per elaborare dati in streaming. Questa guida fornisce informazioni per aiutare gli sviluppatori a capire come funziona Amazon MSK e come utilizzarlo efficacemente nelle loro applicazioni.
Ad alto livello, Amazon MSK fornisce un cluster Apache Kafka completamente gestito, fornito e gestito da. AWS Ciò significa che non devi preoccuparti del provisioning delle istanze EC2, della configurazione delle impostazioni di rete, della gestione dei broker Kafka o dell'esecuzione di attività di manutenzione continue. Invece, puoi concentrarti sulla creazione della tua applicazione e lasciare che Amazon MSK gestisca l'infrastruttura. Amazon MSK fornisce automaticamente le risorse di calcolo, storage e rete necessarie e fornisce funzionalità come scalabilità automatica, alta disponibilità e failover per garantire che il cluster Kafka sia affidabile e altamente disponibile. Questa guida illustra i componenti chiave di Amazon MSK e come utilizzarli per creare applicazioni di streaming di dati.
## Gestisci il tuo cluster Provisioned
Un cluster Amazon MSK è la risorsa Amazon MSK primaria che puoi creare nel tuo account. Negli argomenti di questa sezione viene descritto come eseguire le operazioni comuni di Amazon MSK. Per un elenco di tutte le operazioni che puoi eseguire su un cluster MSK, consulta le risorse seguenti:
+ La [Console di gestione AWS](https://console.aws.amazon.com/msk)
+ La [documentazione di riferimento all'API di Amazon MSK](https://docs.aws.amazon.com/msk/1.0/apireference)
+ La [documentazione di riferimento ai comandi della CLI di Amazon MSK](https://docs.aws.amazon.com/cli/latest/reference/kafka/index.html)
**Argomenti**
+ [Crea un cluster MSK Provisioned](msk-create-cluster.md)
+ [Elenca i cluster Amazon MSK](msk-list-clusters.md)
+ [Connect a un cluster Amazon MSK Provisioned](client-access.md)
+ [Ottieni i broker bootstrap per un cluster Amazon MSK](msk-get-bootstrap-brokers.md)
+ [Monitora un cluster Amazon MSK Provisioned](monitoring.md)
+ [Aggiornamento delle impostazioni di sicurezza di un cluster Amazon MSK](msk-update-security.md)
+ [Espandi il numero di broker in un cluster Amazon MSK](msk-update-broker-count.md)
+ [Rimuovere un broker da un cluster Amazon MSK](msk-remove-broker.md)
+ [Esegui il provisioning del throughput di storage per i broker Standard in un cluster Amazon MSK](msk-provision-throughput.md)
+ [Aggiornamento delle dimensioni del broker del cluster Amazon MSK](msk-update-broker-type.md)
+ [Usa LinkedIn il Cruise Control per Apache Kafka con Amazon MSK](cruise-control.md)
+ [Aggiornamento della configurazione di un cluster Amazon MSK](msk-update-cluster-config.md)
+ [Riavviare un broker per un cluster Amazon MSK](msk-reboot-broker.md)
+ [Contrassegna un tag a un cluster Amazon MSK](msk-tagging.md)
+ [Esegui la migrazione dei carichi di lavoro Kafka in un cluster Amazon MSK](migration.md)
+ [Eliminare un cluster Amazon MSK Provisioned](msk-delete-cluster.md)
# Crea un cluster MSK Provisioned
**Importante**
Non è possibile modificare il VPC per un cluster MSK Provisioned dopo averlo creato.
Prima di poter creare un cluster MSK Provisioned, è necessario disporre di un ( Amazon Virtual Private Cloud VPC) e configurare le sottoreti all'interno di tale VPC.
Per i broker Standard nella regione Stati Uniti occidentali (California settentrionale), sono necessarie due sottoreti in due zone di disponibilità diverse. Per altre regioni in cui è disponibile Amazon MSK, è possibile specificare due o tre sottoreti. Le sottoreti devono trovarsi tutte in zone di disponibilità differenti. Per i broker Express, sono necessarie tre sottoreti in tre diverse zone di disponibilità. Quando crei un cluster MSK Provisioned, Amazon MSK distribuisce i nodi broker in modo uniforme sulle sottoreti specificate.
**Topics**
+ [Crea un cluster MSK Provisioned utilizzando Console di gestione AWS](create-cluster-console.md)
+ [Crea un cluster Amazon MSK di cui è stato effettuato il provisioning utilizzando il AWS CLI](create-cluster-cli.md)
+ [Crea un cluster MSK Provisioned con una configurazione Amazon MSK personalizzata utilizzando AWS CLI](create-cluster-cli-custom-config.md)
+ [Crea un cluster MSK Provisioned utilizzando l'API Amazon MSK](create-cluster-api.md)
# Crea un cluster MSK Provisioned utilizzando Console di gestione AWS
Le procedure riportate in questo argomento descrivono l'attività comune di creazione di un cluster MSK Provisioned utilizzando l'opzione di **creazione personalizzata** disponibile in. Console di gestione AWS Utilizzando le altre opzioni disponibili in Console di gestione AWS, è inoltre possibile creare quanto segue:
+ [Un cluster senza server](create-serverless-cluster.md)
+ [Un cluster MSK Provisioned che utilizza l'opzione](create-cluster.md) **Quick create**
****Procedure in questo argomento
+ [Fase 1: Configurazione e configurazione iniziali del cluster](#cluster-initial-setup)
+ [Fase 2: Configurare le impostazioni di archiviazione e cluster](#cluster-storage-config)
+ [Fase 3: Configurare le impostazioni di rete](#cluster-network-config)
+ [Fase 4: Configurare le impostazioni di sicurezza](#cluster-security-settings-config)
+ [Passaggio 5: configura le opzioni di monitoraggio](#cluster-monitoring-config)
+ [Fase 6: Rivedere la configurazione del cluster](#review-cluster-custom-create)
## Fase 1: Configurazione e configurazione iniziali del cluster
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Scegli **Crea cluster**.
1. Per il **metodo di creazione del cluster**, scegli **Creazione personalizzata**.
1. Per **Nome cluster**, specifica un nome univoco e contenente non più di 64 caratteri.
1. Per il **tipo di cluster**, scegli **Provisioned.**
1. Per la **versione Apache Kafka**, scegli una versione da eseguire sui broker. **Per visualizzare un confronto tra le funzionalità di Amazon MSK supportate da ciascuna versione di Apache Kafka, scegli Visualizza compatibilità della versione.**
1. Nella sezione **Broker**, procedi come segue:
1. Per **il tipo di broker**, scegli una delle seguenti opzioni:
+ **Broker Express: broker** scalabili e ad alte prestazioni con storage virtuale completamente gestito. Scegli questo tipo di broker per applicazioni impegnative e ad alto rendimento.
+ **Broker standard: broker** Kafka tradizionale con controllo completo della configurazione. Scegli questo tipo di broker per carichi di lavoro generici con requisiti di throughput moderati.
Per ulteriori informazioni su questi tipi di broker, consulta. [Tipi di broker Amazon MSK](broker-instance-types.md)
1. Per **Broker size**, scegli una dimensione da utilizzare per il cluster in base alle esigenze di calcolo, memoria e archiviazione del cluster.
1. Per **Numero di zone**, scegli il numero di aree [AWS Zone di disponibilità](https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-availability-zones.html)in cui sono distribuiti i broker.
I broker Express richiedono tre zone di disponibilità per una maggiore disponibilità.
1. Per **i broker per zona**, specifica il numero di broker che desideri che Amazon MSK crei in ogni zona di disponibilità. [Il minimo è un broker per zona di disponibilità e il massimo è 30 broker per cluster per cluster ZooKeeper basati e 60 broker per cluster per cluster per cluster basati. KRaft](metadata-management.md#kraft-intro)
## Fase 2: Configurare le impostazioni di archiviazione e cluster
Questa procedura descrive come configurare le esigenze di archiviazione dei dati tra tutti i broker e specificare la modalità di archiviazione. Questo ti aiuta a definire i requisiti di archiviazione dei dati in base alle esigenze del carico di lavoro. Inoltre, questa procedura descrive le impostazioni di configurazione del cluster che controllano il funzionamento dei broker. Queste impostazioni includono le configurazioni dei broker, le impostazioni degli argomenti predefinite e le politiche di archiviazione su più livelli.
1. Se hai selezionato il tipo di broker come **Standard, procedi** come segue nella sezione **Archiviazione**:
1. Per **Storage**, scegli la quantità iniziale di spazio di archiviazione che desideri assegnare al cluster. Non è possibile ridurre la capacità di archiviazione dopo aver creato il cluster.
1. (Facoltativo) A seconda della dimensione del broker (dimensione dell'istanza) selezionata, puoi anche specificare il **throughput di storage fornito per** broker. Questa opzione consente di allocare prestazioni di input e output (I/O) dedicate per i volumi Amazon EBS di ciascun broker.
Per abilitare questa opzione, scegli la dimensione del broker (dimensione dell'istanza) kafka.m5.4xlarge o superiore per x86 e kafka.m7g.2xlarge o superiore per le istanze basate su Graviton. Quindi**, seleziona** la casella di controllo Enable provisioned storage throughput. Selezionando questa casella di controllo, è possibile impostare manualmente un minimo di 250 MiB al secondo di throughput. Ciò è utile per carichi di lavoro o applicazioni a uso intensivo di I/O che richiedono prestazioni di storage prevedibili e ad alta velocità. Per ulteriori informazioni, consulta [Esegui il provisioning del throughput di storage per i broker Standard in un cluster Amazon MSK](msk-provision-throughput.md).
1. Per la **modalità di archiviazione Cluster**, specifica in che modo i dati vengono archiviati e gestiti all'interno del cluster. Questa opzione determina il tipo e la configurazione dello storage utilizzato dai broker. Scegli una delle seguenti opzioni:
+ **Solo storage EBS**: archivia tutti i dati relativi agli argomenti localmente sui volumi Amazon Elastic Block Store (Amazon EBS) collegati a ciascun broker. Scegli questa modalità per esigenze prestazionali coerenti e accesso rapido ai messaggi recenti.
+ **Storage su più livelli e storage EBS: combina i dati locali di Amazon EBS con lo** storage remoto ed economico per set di dati di grandi dimensioni in Amazon S3. Questa modalità riduce i costi di storage di Amazon EBS, supporta una conservazione dei dati più lunga e ridimensiona automaticamente lo storage senza intervento manuale. Scegli questa modalità quando desideri conservare i dati per periodi più lunghi a costi inferiori o prevedi che le tue esigenze di storage aumentino in modo significativo.
**Nota**
Non è necessario gestire lo storage per i broker Express.
1. Per la **configurazione del cluster**, specifica una delle seguenti opzioni per definire il comportamento del cluster:
+ **Configurazione predefinita di Amazon MSK**: contiene un set predefinito di configurazioni ottimizzate per casi d'uso generici. Scegli questa opzione per una configurazione e una distribuzione rapide del cluster. Per informazioni sulle configurazioni di Amazon MSK, consulta la sezione [Configurazione Amazon MSK Provisioned](msk-configuration.md).
+ **Configurazione personalizzata**: consente di specificare le impostazioni del broker e dell'argomento. È possibile scegliere una configurazione personalizzata esistente dall'elenco o creare una nuova configurazione personalizzata. Scegli questa opzione per un controllo preciso per i tuoi broker, ad esempio l'ottimizzazione specifica delle prestazioni, le impostazioni di sicurezza e altro ancora.
1. Scegli **Successivo** per continuare.
## Fase 3: Configurare le impostazioni di rete
La configurazione di rete definisce il modo in cui il cluster viene distribuito all'interno AWS dell'infrastruttura. Ciò include VPC, zone di disponibilità e sottoreti e gruppi di sicurezza che controllano la rete, la disponibilità e l'accesso.
1. Per le **reti, procedi** come segue:
1. Scegli il VPC che desideri utilizzare per il cluster.
1. In base al numero di zone di disponibilità selezionate in precedenza, specifica le zone di disponibilità e le sottoreti in cui verranno implementate i broker.
Per i broker standard nella regione Stati Uniti occidentali (California settentrionale), sono necessarie due sottoreti in due zone di disponibilità diverse. Per altre regioni in cui è disponibile Amazon MSK, è possibile specificare due o tre sottoreti. Le sottoreti devono trovarsi tutte in zone di disponibilità differenti.
Per i broker Express, sono necessarie tre sottoreti in tre diverse zone di disponibilità.
Quando si crea un cluster MSK Provisioned, MSK distribuisce i nodi broker in modo uniforme sulle sottoreti specificate.
1. Per **i gruppi di sicurezza in Amazon EC2**, scegli o crea uno o più gruppi di sicurezza a cui desideri consentire l'accesso al tuo cluster. Questi gruppi di sicurezza di Amazon EC2 controllano il traffico in entrata e in uscita verso i tuoi broker. Ad esempio, i gruppi di sicurezza delle macchine client.
Se specificate gruppi di sicurezza condivisi con voi, dovete assicurarvi di disporre delle autorizzazioni per utilizzarli. Nello specifico, è necessaria l'autorizzazione `ec2:DescribeSecurityGroups`. Per ulteriori informazioni, vedere [Connessione a un cluster MSK](https://docs.aws.amazon.com/msk/latest/developerguide/client-access.html#public-access).
1. Scegli **Successivo** per continuare.
## Fase 4: Configurare le impostazioni di sicurezza
1. Nella sezione **Impostazioni di sicurezza**, procedi come segue:
1. Scegli uno o più dei seguenti metodi di autenticazione e autorizzazione per controllare l'accesso dei client ai tuoi cluster Kafka:
+ Accesso **non autenticato: consente ai client di accedere** al cluster senza fornire alcuna credenziale di autenticazione. Questo metodo rappresenta un rischio per la sicurezza e potrebbe non essere conforme alle migliori pratiche di sicurezza. Per ulteriori informazioni, consulta [msk-unrestricted-access-check](https://docs.aws.amazon.com/config/latest/developerguide/msk-unrestricted-access-check.html).
+ **Autenticazione basata sui ruoli IAM: consente l'autenticazione** e l'autorizzazione del client utilizzando utenti/ruoli AWS IAM. Questo metodo fornisce un controllo granulare sull'accesso ai cluster tramite le policy IAM. Abbiamo consigliato questo metodo per le applicazioni già in esecuzione in. AWS
+ **Autenticazione SASL/SCRAM**: richiede ai client di fornire le credenziali di nome utente e password memorizzate per l'autenticazione. Gestione dei segreti AWS Amazon MSK recupera queste credenziali da Secrets Manager e autentica gli utenti in modo sicuro.
Per configurare le credenziali di accesso relative all'autenticazione per un cluster, crea prima una risorsa segreta in Secrets Manager. Quindi, associa le credenziali di accesso a quel segreto. Per ulteriori informazioni su questo metodo di controllo dell'accesso, vedere. [Configurare SASL/SCRAM l'autenticazione per un cluster Amazon MSKConnessione al cluster con credenziali di accesso](msk-password-tutorial.md)
+ **Autenticazione client TLS tramite AWS Certificate Manager (ACM)**: consente l'autenticazione reciproca tra client e broker utilizzando certificati digitali. È necessario configurare un AWS Autorità di certificazione privata (AWS Private CA) nello stesso o in un altro cluster Account AWS .
Consigliamo vivamente di utilizzare AWS Private CA s indipendenti per ogni cluster MSK durante l'implementazione di MTL. Ciò garantisce che i certificati TLS firmati da si autentichino PCAs solo con un singolo cluster MSK, mantenendo così un rigoroso controllo degli accessi.
1. In **Encryption**, scegli il tipo di chiave KMS che desideri utilizzare per crittografare i dati inattivi. Per ulteriori informazioni, consulta [Crittografia Amazon MSK a riposo](msk-encryption.md#msk-encryption-at-rest).
La crittografia dei dati a riposo protegge l’integrità dei dati archiviati, mentre la crittografia in transito protegge la riservatezza dei dati dal monitoraggio della rete durante il trasferimento.
1. Scegli **Successivo** per continuare.
## Passaggio 5: configura le opzioni di monitoraggio
Questa procedura descrive come impostare le metriche del broker e raccogliere e fornire i log del broker. Con queste impostazioni, puoi osservare e analizzare lo stato e le prestazioni del cluster e risolvere i problemi. Per ulteriori informazioni, consulta [Monitora un cluster Amazon MSK Provisioned](monitoring.md).
1. Per i ** CloudWatch parametri Amazon per questo cluster**, scegli uno dei seguenti livelli di monitoraggio. Le metriche raccolte a ciascun livello di monitoraggio sono integrate CloudWatch per la visualizzazione e gli avvisi.
1. **Monitoraggio di base**: fornisce una serie di metriche essenziali a livello di cluster senza costi aggiuntivi. Questo livello è utile per la maggior parte dei casi d'uso con esigenze di monitoraggio generali.
1. **Monitoraggio avanzato a livello di broker**: fornisce metriche dettagliate dei broker a costi aggiuntivi. Questo livello include il monitoraggio di base e parametri più granulari dei broker, come i parametri di storage su più livelli, i byte in/out di altri broker e il tempo totale di utilizzo delle operazioni. read/write Paghi per le metriche di questo livello, mentre le metriche di livello base continuano a essere gratuite.
1. **Monitoraggio avanzato a livello di argomento**: fornisce metriche per singoli argomenti a un costo aggiuntivo. Scegli questo livello per ottenere una visione più granulare delle performance tematiche tra i broker. Include un monitoraggio avanzato a livello di broker e metriche a livello di argomento, come metriche di archiviazione su più livelli per un argomento specifico e il numero di messaggi ricevuti al secondo.
1. **Monitoraggio avanzato a livello di partizione**: fornisce la visualizzazione più granulare delle metriche per partizione a un costo aggiuntivo. Scegli questo livello per ottenere il monitoraggio più dettagliato acquisendo le metriche per ogni partizione all’interno di ogni argomento tra i broker. Include un monitoraggio avanzato a livello di argomento e metriche granulari specifiche per le partizioni, come le metriche di ritardo di offset.
Per ulteriori informazioni sulle metriche disponibili per i tipi di broker Standard ed Express a ciascuno di questi livelli di monitoraggio, consulta e. [CloudWatch metriche per i broker Standard](metrics-details.md) [CloudWatch metriche per i broker Express](metrics-details-express.md)
1. **(Facoltativo) Se desideri esportare le metriche in formato Prometheus utilizzando JMX Exporter, Node Exporter o entrambi, scegli Abilita il monitoraggio aperto con Prometheus.** Per ulteriori informazioni su questa opzione, consulta [Monitora con Prometheus](open-monitoring.md).
1. (Facoltativo) Per configurare il cluster MSK in modo da fornire i log dei broker a vari utenti per la risoluzione dei problemi e il controllo, scegliete una o più delle Servizi AWS seguenti opzioni. Amazon MSK non crea queste risorse di destinazione se non esistono già. Per ulteriori informazioni, consulta [Log di broker](msk-logging.md#broker-logs).
+ **Consegna ad Amazon CloudWatch Logs**: invia i log a CloudWatch con funzionalità di clustering, ricerca e visualizzazione. Puoi interrogare e analizzare i log senza uscire da. Console di gestione AWS
+ **Consegna ad Amazon S3**: archivia i log come file in bucket Amazon S3 per l'archiviazione a lungo termine e l'analisi in batch.
+ **Consegna ad Amazon Data Firehose: invia i log a Firehose** per la consegna automatica ad Amazon OpenSearch Service per la risoluzione dei problemi in tempo reale.
1. (Facoltativo) Per facilitare l'identificazione, l'organizzazione o la ricerca del cluster, scegli **Aggiungi nuovo tag per aggiungere tag** come coppie chiave-valore. Ad esempio, aggiungi un tag al cluster con la coppia chiave-valore e. **Load testing** **Test**
Per ulteriori informazioni sull'utilizzo dei tag nei cluster, consulta. [Contrassegna un tag a un cluster Amazon MSK](msk-tagging.md)
1. Scegli **Successivo** per continuare.
## Fase 6: Rivedere la configurazione del cluster
1. Rivedi le impostazioni del tuo cluster.
Scegli **Modifica** o **Precedente** per modificare le impostazioni specificate in precedenza o tornare alla schermata precedente della console.
1. Scegli **Crea cluster**.
1. Controlla lo stato di questo cluster nella sezione di **riepilogo** del cluster della pagina dei dettagli del cluster. Quando Amazon MSK assegna il cluster, lo stato passa da **Creazione in corso** ad **Attivo**. Quando lo stato è **Attivo**, puoi connetterti al cluster. Per ulteriori informazioni sugli stati del cluster, consulta la pagina [Comprendi gli stati del cluster MSK Provisioned](msk-cluster-states.md).
# Crea un cluster Amazon MSK di cui è stato effettuato il provisioning utilizzando il AWS CLI
****
1. Copiare il JSON seguente e salvarlo in un file. Assegnare un nome al file `brokernodegroupinfo.json`. Sostituisci la sottorete IDs in JSON con i valori che corrispondono alle sottoreti. Le sottoreti devono trovarsi in zone di disponibilità differenti. Sostituisci *"Security-Group-ID"* con l'ID di uno o più gruppi di sicurezza del VPC client. I client associati a questi gruppi di sicurezza ottengono l'accesso al cluster. Se specifichi gruppi di sicurezza condivisi con te, devi verificare di disporre delle autorizzazioni per gli stessi. Nello specifico, è necessaria l'autorizzazione `ec2:DescribeSecurityGroups`. Per un esempio, consulta la pagina [Amazon EC2: Allows Managing Amazon EC2 Security Groups Associated With a Specific VPC, Programmatically and in the Console](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html). Infine, salva il file JSON aggiornato sul computer su cui lo AWS CLI hai installato.
```
{
"InstanceType": "kafka.m5.large",
"ClientSubnets": [
"Subnet-1-ID",
"Subnet-2-ID"
],
"SecurityGroups": [
"Security-Group-ID"
]
}
```
**Importante**
Per i broker Express, sono necessarie tre sottoreti in tre diverse zone di disponibilità. Inoltre, non è necessario definire alcuna proprietà relativa allo storage.
Per i broker standard nella regione Stati Uniti occidentali (California settentrionale), sono necessarie due sottoreti in due diverse zone di disponibilità. Per altre regioni in cui è disponibile Amazon MSK, è possibile specificare due o tre sottoreti. Le sottoreti devono trovarsi tutte in zone di disponibilità differenti. Quando crei un cluster, Amazon MSK distribuisce i nodi dei broker in modo uniforme nelle sottoreti specificate.
1. Eseguite il AWS CLI comando seguente nella directory in cui avete salvato il `brokernodegroupinfo.json` file, sostituendolo *"Your-Cluster-Name"* con un nome a vostra scelta. Infatti*"Monitoring-Level"*, è possibile specificare uno dei tre valori seguenti:`DEFAULT`,`PER_BROKER`, o`PER_TOPIC_PER_BROKER`. Per informazioni su questi tre diversi livelli di monitoraggio, consulta [Monitora un cluster Amazon MSK Provisioned](monitoring.md). Il parametro `enhanced-monitoring` è facoltativo. Se non viene specificato nel comando `create-cluster`, si ottiene il livello di monitoraggio `DEFAULT`.
```
aws kafka create-cluster --cluster-name "Your-Cluster-Name" --broker-node-group-info file://brokernodegroupinfo.json --kafka-version "2.8.1" --number-of-broker-nodes 3 --enhanced-monitoring "Monitoring-Level"
```
L'output del comando è simile al JSON seguente:
```
{
"ClusterArn": "...",
"ClusterName": "AWSKafkaTutorialCluster",
"State": "CREATING"
}
```
**Nota**
Il comando `create-cluster` potrebbe restituire un errore che indica che una o più sottoreti appartengono a zone di disponibilità non supportate. Quando ciò si verifica, l'errore indica quali zone di disponibilità non sono supportate. Crea sottoreti che non utilizzano le zone di disponibilità non supportate e riprova a eseguire nuovamente il comando `create-cluster`.
1. Salvare il valore della chiave `ClusterArn` perché è necessario per eseguire altre operazioni nel cluster.
1. Eseguire il comando seguente per verificare il tuo cluster `STATE`. Il valore `STATE` cambia da `CREATING` a `ACTIVE` quando Amazon EMR assegna il cluster. Quando lo stato è `ACTIVE`, puoi connetterti al cluster. Per ulteriori informazioni sugli stati del cluster, consulta la pagina [Comprendi gli stati del cluster MSK Provisioned](msk-cluster-states.md).
```
aws kafka describe-cluster --cluster-arn
```
# Crea un cluster MSK Provisioned con una configurazione Amazon MSK personalizzata utilizzando AWS CLI
****
Per informazioni sulle configurazioni personalizzate di Amazon MSK e su come crearle, consulta la sezione [Configurazione Amazon MSK Provisioned](msk-configuration.md).
1. Salva il seguente codice JSON in un file, sostituendolo *configuration-arn* con l'ARN della configurazione che desideri utilizzare per creare il cluster.
```
{
"Arn": configuration-arn,
"Revision": 1
}
```
1. Esegui il comando `create-cluster` e utilizza l'opzione `configuration-info` per puntare al file JSON salvato nella fase precedente. Di seguito è riportato un esempio di :
```
aws kafka create-cluster --cluster-name ExampleClusterName --broker-node-group-info file://brokernodegroupinfo.json --kafka-version "2.8.1" --number-of-broker-nodes 3 --enhanced-monitoring PER_TOPIC_PER_BROKER --configuration-info file://configuration.json
```
Di seguito è riportato un esempio di una risposta corretta dopo l'esecuzione di questo comando.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:123456789012:cluster/CustomConfigExampleCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2",
"ClusterName": "CustomConfigExampleCluster",
"State": "CREATING"
}
```
# Crea un cluster MSK Provisioned utilizzando l'API Amazon MSK
L'API Amazon MSK ti consente di creare e gestire in modo programmatico il tuo cluster MSK Provisioned come parte di script di provisioning o distribuzione automatizzati dell'infrastruttura.
Per creare un cluster MSK Provisioned utilizzando l'API, consulta. [CreateCluster](https://docs.aws.amazon.com//msk/1.0/apireference/clusters.html#CreateCluster)
# Elenca i cluster Amazon MSK
Per ottenere un broker di bootstrap per un cluster Amazon MSK, è necessario il cluster Amazon Resource Name (ARN). Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per informazioni, consulta [Ottieni i broker bootstrap per un cluster Amazon MSK](msk-get-bootstrap-brokers.md).
**Topics**
+ [Elenca i cluster utilizzando il Console di gestione AWS](list-clusters-console.md)
+ [Elenca i cluster utilizzando il AWS CLI](list-clusters-cli.md)
+ [Elenca i cluster utilizzando l'API](list-clusters-api.md)
# Elenca i cluster utilizzando il Console di gestione AWS
Per ottenere un broker di bootstrap per un cluster Amazon MSK, è necessario il cluster Amazon Resource Name (ARN). Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per informazioni, consulta [Ottieni i broker bootstrap per un cluster Amazon MSK](msk-get-bootstrap-brokers.md).
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. La tabella mostra tutti i cluster per la regione corrente in questo account. Scegli il nome di un cluster per visualizzarne i dettagli.
# Elenca i cluster utilizzando il AWS CLI
Per ottenere un broker di bootstrap per un cluster Amazon MSK, è necessario il cluster Amazon Resource Name (ARN). Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per informazioni, consulta [Ottieni i broker bootstrap per un cluster Amazon MSK](msk-get-bootstrap-brokers.md).
```
aws kafka list-clusters
```
# Elenca i cluster utilizzando l'API
Per ottenere un broker di bootstrap per un cluster Amazon MSK, è necessario il cluster Amazon Resource Name (ARN). Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per informazioni, consulta [Ottieni i broker bootstrap per un cluster Amazon MSK](msk-get-bootstrap-brokers.md).
Per elencare i cluster che utilizzano l'API, consulta. [ListClusters](https://docs.aws.amazon.com//msk/1.0/apireference/clusters.html#ListClusters)
# Connect a un cluster Amazon MSK Provisioned
Per impostazione predefinita, i client possono accedere a un cluster MSK Provisioned solo se si trovano nello stesso VPC del cluster. Tutte le comunicazioni tra i client Kafka e il cluster MSK Provisioned sono private per impostazione predefinita e i dati di streaming non attraversano mai Internet. Per connetterti al tuo cluster MSK Provisioned da un client che si trova nello stesso VPC del cluster, assicurati che il gruppo di sicurezza del cluster disponga di una regola in entrata che accetti il traffico dal gruppo di sicurezza del client. Per informazioni sull'impostazione di queste regole, consulta [Regole del gruppo di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules). Per un esempio di come accedere a un cluster da un'istanza Amazon EC2 che si trova nello stesso VPC del cluster, consulta la pagina [Inizia a usare Amazon MSK](getting-started.md).
**Nota**
KRaft la modalità metadati e i broker MSK Express non possono avere entrambi abilitati il monitoraggio aperto e l'accesso pubblico.
Per connettersi al cluster MSK Provisioned da un client esterno al VPC del cluster, vedere [Accesso dall'interno AWS ma dall'esterno del VPC del cluster](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access.html).
**Topics**
+ [Attiva l'accesso pubblico a un cluster MSK Provisioned](public-access.md)
+ [Accesso dall'interno AWS ma dall'esterno del VPC del cluster](aws-access.md)
# Attiva l'accesso pubblico a un cluster MSK Provisioned
Amazon MSK ti offre la possibilità di attivare l'accesso pubblico ai broker dei cluster MSK Provisioned che eseguono Apache Kafka 2.6.0 o versioni successive. Per motivi di sicurezza, non è possibile attivare l'accesso pubblico durante la creazione di un cluster MSK. Tuttavia, è possibile aggiornare un cluster esistente per renderlo accessibile al pubblico. È inoltre possibile creare un nuovo cluster e aggiornarlo in modo da renderlo accessibile al pubblico.
Puoi attivare l'accesso pubblico a un cluster MSK senza costi aggiuntivi, ma per il trasferimento dei dati da e verso il cluster si applicano i costi standard di trasferimento AWS dei dati. Per ulteriori informazioni, consulta la pagina [Prezzi di Amazon EC2 on demand](https://aws.amazon.com/ec2/pricing/on-demand/).
I cluster Amazon MSK Provisioned con tipo di rete dual-stack supportano sia IPv4 la connettività per l'accesso pubblico. IPv6 Quando l'accesso pubblico è abilitato sul cluster, le stesse stringhe di IPv6 bootstrap funzioneranno automaticamente sia per la connettività predefinita che per quella ad accesso pubblico. Le stringhe IPv4 bootstrap esistenti continueranno a funzionare per la connettività. IPv4 Tieni presente che se l'accesso pubblico non è abilitato sul tuo cluster, le stringhe di IPv6 bootstrap non avranno funzionalità di accesso pubblico. Per ulteriori informazioni, consulta Configurare il tipo di rete dual-stack per un cluster Amazon MSK.
**Nota**
Se utilizzi i metodi di controllo degli accessi SASL/SCRAM o MTLS, devi prima impostare Apache Kafka per il tuo cluster. ACLs Quindi, aggiorna la configurazione del cluster per impostare la proprietà su false. `allow.everyone.if.no.acl.found` Per informazioni su come aggiornare la configurazione di un cluster, consulta la pagina [Operazioni di configurazione del broker](msk-configuration-operations.md).
Per attivare l'accesso pubblico a un cluster MSK Provisioned, assicuratevi che il cluster soddisfi tutte le seguenti condizioni:
+ Le sottoreti associate al cluster devono essere pubbliche. A ogni sottorete pubblica è associato un IPv4 indirizzo pubblico e il prezzo IPv4 degli indirizzi pubblici è indicato nella pagina dei prezzi di Amazon [VPC](https://aws.amazon.com/vpc/pricing/). Ciò significa che le sottoreti devono avere una tabella di routing associata a un gateway Internet. Per informazioni su come creare e collegare un gateway Internet, consulta [Abilita l'accesso a Internet VPC utilizzando i gateway Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) nella Amazon *VPC* User Guide.
+ Il controllo degli accessi non autenticati deve essere disattivato e almeno uno dei seguenti metodi di controllo degli accessi deve essere attivo:, MTL. SASL/IAM, SASL/SCRAM Per informazioni su come aggiornare il metodo di controllo degli accessi di un cluster, consulta la pagina [Aggiornamento delle impostazioni di sicurezza di un cluster Amazon MSK](msk-update-security.md).
+ La crittografia all'interno del cluster deve essere attiva. Per impostazione predefinita durante la creazione di un cluster, la crittografia è attiva. Non è possibile attivare la crittografia all'interno del cluster se esso è stato creato con questa opzione disattivata. Pertanto, non è possibile attivare l'accesso pubblico per il cluster se esso è stato creato con la crittografia all'interno del cluster disattivata.
+ Il traffico non crittografato tra broker e client deve essere disattivato. Per informazioni su come disattivarlo se è attivato, consulta la pagina [Aggiornamento delle impostazioni di sicurezza di un cluster Amazon MSK](msk-update-security.md).
+ Se utilizzi il controllo degli accessi IAM e desideri applicare politiche di autorizzazione o aggiornare le politiche di autorizzazione, consulta. [Controllo degli accessi IAM](iam-access-control.md) Per informazioni su Apache Kafka ACLs, consulta. [Apache Kafka ACLs](msk-acls.md)
Dopo esserti assicurato che un cluster MSK soddisfi le condizioni sopra elencate Console di gestione AWS, puoi utilizzare l' AWS CLI API Amazon MSK per attivare l'accesso pubblico. Dopo aver attivato l'accesso pubblico a un cluster, puoi recuperare una stringa bootstrap-brokers pubblica relativa al cluster. Per informazioni su come recuperare i broker di bootstrap per un cluster, consulta la pagina [Ottieni i broker bootstrap per un cluster Amazon MSK](msk-get-bootstrap-brokers.md).
**Importante**
Oltre ad attivare l'accesso pubblico, assicurati che i gruppi di sicurezza del cluster dispongano di regole TCP in entrata che consentano l'accesso pubblico dal tuo indirizzo IP. Ti consigliamo di impostare tali regole di modo che siano il più restrittive possibile. Per ulteriori informazioni sui gruppi di sicurezza e le regole in entrata, consulta la pagina [Security groups for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) nella Guida per l'utente di Amazon VPC. Per i numeri di porta, consulta la pagina [Informazioni sulle porte](port-info.md). Per istruzioni su come modificare il gruppo di sicurezza di un cluster, consulta la pagina [Modifica del gruppo di sicurezza di un cluster Amazon MSK](change-security-group.md).
**Nota**
Se dopo avere seguito le istruzioni seguenti per attivare l'accesso pubblico non riesci comunque ad accedere al cluster, consulta la pagina [Impossibile accedere al cluster con accesso pubblico attivato](troubleshooting.md#public-access-issues).
**Attivazione dell'accesso pubblico tramite la console**
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Nell'elenco dei cluster, scegli quello per il quale attivare l'accesso pubblico.
1. Scegli la scheda **Proprietà**, quindi trova la sezione **Impostazioni di rete**.
1. Scegli **Modifica accesso pubblico**.
**Attivazione dell'accesso pubblico tramite AWS CLI**
1. Esegui il AWS CLI comando seguente, sostituendo *ClusterArn* e *Current-Cluster-Version* con l'ARN e la versione corrente del cluster. Per trovare la versione corrente del cluster, usa l'[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)operazione o il comando [AWS CLI describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html). Una versione di esempio è `KTVPDKIKX0DER`.
```
aws kafka update-connectivity --cluster-arn ClusterArn --current-version Current-Cluster-Version --connectivity-info '{"PublicAccess": {"Type": "SERVICE_PROVIDED_EIPS"}}'
```
L'output di questo comando `update-connectivity` è simile all'esempio JSON seguente.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"ClusterOperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef"
}
```
**Nota**
Per disattivare l'accesso pubblico, usa un AWS CLI comando simile, ma con le seguenti informazioni di connettività:
```
'{"PublicAccess": {"Type": "DISABLED"}}'
```
1. Per ottenere il risultato dell'`update-connectivity`operazione, esegui il comando seguente, sostituendolo *ClusterOperationArn* con l'ARN ottenuto nell'output del `update-connectivity` comando.
```
aws kafka describe-cluster-operation --cluster-operation-arn ClusterOperationArn
```
L'output di questo comando `describe-cluster-operation` è simile all'esempio JSON seguente.
```
{
"ClusterOperationInfo": {
"ClientRequestId": "982168a3-939f-11e9-8a62-538df00285db",
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"CreationTime": "2019-06-20T21:08:57.735Z",
"OperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef",
"OperationState": "UPDATE_COMPLETE",
"OperationType": "UPDATE_CONNECTIVITY",
"SourceClusterInfo": {
"ConnectivityInfo": {
"PublicAccess": {
"Type": "DISABLED"
}
}
},
"TargetClusterInfo": {
"ConnectivityInfo": {
"PublicAccess": {
"Type": "SERVICE_PROVIDED_EIPS"
}
}
}
}
}
```
Se il valore di `OperationState` è `UPDATE_IN_PROGRESS`, attendi qualche minuto, quindi esegui nuovamente il comando `describe-cluster-operation`.
**Attivazione dell'accesso pubblico tramite l'API di Amazon MSK**
+ Per utilizzare l'API per attivare o disattivare l'accesso pubblico a un cluster, consulta [UpdateConnectivity](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-connectivity.html#UpdateConnectivity).
**Nota**
Per motivi di sicurezza, Amazon MSK non consente l'accesso pubblico ad Apache ZooKeeper o ai nodi KRaft del controller.
# Accesso dall'interno AWS ma dall'esterno del VPC del cluster
Per connettersi a un cluster MSK dall'interno AWS ma dall'esterno dell'Amazon VPC del cluster, esistono le seguenti opzioni.
## Peering Amazon VPC
Per connetterti al tuo cluster MSK da un VPC diverso dal VPC del cluster, puoi creare una connessione peering tra i due. VPCs Per informazioni sul peering VPC, consulta la [Guida al peering di VPC di Amazon](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html).
## Direct Connect
Direct Connect collega la rete locale a un cavo in fibra ottica AWS Ethernet standard da 1 o 10 gigabit. Un'estremità del cavo è collegata al router, l'altra a un router. Direct Connect Con questa connessione, puoi creare interfacce virtuali direttamente sul AWS cloud e Amazon VPC, aggirando i provider di servizi Internet nel tuo percorso di rete. Per ulteriori informazioni, consulta [Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html).
## AWS Transit Gateway
AWS Transit Gateway è un servizio che ti consente di connettere le tue reti VPCs e quelle locali a un unico gateway. Per informazioni su come utilizzare AWS Transit Gateway, consulta [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html).
## Connessioni VPN
Puoi connettere il VPC del cluster MSK a reti e utenti remoti utilizzando le opzioni di connettività VPN descritte nel seguente argomento: [VPN Connections](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html).
## Proxy REST
Puoi installare un proxy REST in un'istanza in esecuzione all'interno dell'Amazon VPC del cluster. I proxy REST consentono ai produttori e ai consumatori di comunicare con il cluster attraverso richieste API HTTP.
## Connettività multi-VPC per regioni multiple
Il documento seguente descrive le opzioni di connettività per più regioni VPCs che risiedono in regioni diverse: Connettività [multi-VPC a più regioni](https://aws.amazon.com/answers/networking/aws-multiple-region-multi-vpc-connectivity/).
## Connettività privata multi-VPC a regione singola
La connettività privata multi-VPC (con tecnologia [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)) per i cluster Amazon Managed Streaming for Apache Kafka (Amazon MSK) è una funzionalità che consente di connettere più rapidamente i client Kafka ospitati in diversi Virtual VPCs Private Cloud () e account a un cluster Amazon MSK. AWS
Consulta la sezione [Single Region multi-VPC connectivity for cross-account clients](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access-mult-vpc.html).
## La rete EC2-Classic è stata ritirata
Amazon MSK non supporta più le istanze Amazon EC2 in esecuzione con reti Amazon EC2-Classic.
Vedi [EC2-Classic Networking is Retiring](https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-heres-how-to-prepare/): ecco come prepararsi.
# Connettività privata multi-VPC di Amazon MSK in un'unica regione
La connettività privata multi-VPC (con tecnologia [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)) per i cluster Amazon Managed Streaming for Apache Kafka (Amazon MSK) è una funzionalità che consente di connettere più rapidamente i client Kafka ospitati in diversi Virtual VPCs Private Cloud () e account a un cluster Amazon MSK. AWS
La connettività privata multi-VPC è una soluzione gestita che semplifica l’infrastruttura di rete per la connettività multi-VPC e multi-account. I client possono connettersi al cluster Amazon MSK PrivateLink mantenendo tutto il traffico all'interno della AWS rete. La connettività privata multi-VPC per i cluster Amazon MSK è disponibile in tutte le regioni in AWS cui è disponibile Amazon MSK.
**Topics**
+ [Cos'è la connettività privata multi-VPC?](#mvpc-what-is)
+ [Vantaggi della connettività privata multi-VPC](#mvpc-benefits)
+ [Requisiti e limitazioni per la connettività privata multi-VPC](#mvpc-requirements)
+ [Inizia a usare la connettività privata multi-VPC](mvpc-getting-started.md)
+ [Aggiornamento degli schemi di autorizzazione su un cluster](mvpc-cross-account-update-authschemes.md)
+ [Rifiuto di una connessione VPC gestita a un cluster Amazon MSK](mvpc-cross-account-reject-connection.md)
+ [Eliminazione di una connessione VPC gestita a un cluster Amazon MSK](mvpc-cross-account-delete-connection.md)
+ [Autorizzazioni per la connettività privata multi-VPC](mvpc-cross-account-permissions.md)
## Cos'è la connettività privata multi-VPC?
La connettività privata multi-VPC per Amazon MSK è un'opzione di connettività che consente di connettere client Apache Kafka ospitati in diversi account e AWS cloud privati virtuali (VPCs) a un cluster MSK.
Amazon MSK semplifica l'accesso multi-account con le [policy del cluster](mvpc-cluster-owner-action-policy.md). Queste politiche consentono al proprietario del cluster di concedere autorizzazioni ad altri AWS account per stabilire una connettività privata al cluster MSK.
## Vantaggi della connettività privata multi-VPC
La connettività privata multi-VPC presenta diversi vantaggi rispetto ad [altre soluzioni di connettività](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access.html):
+ Automatizza la gestione operativa della soluzione di connettività. AWS PrivateLink
+ Consente la sovrapposizione IPs tra le connessioni VPCs, eliminando la necessità di mantenere tabelle di peering e routing complesse e non sovrapposte IPs associate ad altre soluzioni di connettività VPC.
Si utilizza una politica di cluster per il cluster MSK per definire quali AWS account dispongono delle autorizzazioni per configurare la connettività privata tra account verso il cluster MSK. L'amministratore multi-account può delegare le autorizzazioni ai ruoli o agli utenti appropriati. In combinazione con l'autenticazione del client IAM, puoi utilizzare la policy del cluster anche per definire in modo granulare le autorizzazioni del piano dati Kafka per i client che si connettono.
## Requisiti e limitazioni per la connettività privata multi-VPC
Tieni conto di questi requisiti del cluster MSK per l'esecuzione della connettività privata multi-VPC:
+ La connettività privata multi-VPC è supportata solo su Apache Kafka 2.7.1 o versioni successive. Assicurati che tutti i client utilizzati con il cluster MSK eseguano versioni di Apache Kafka compatibili con il cluster.
+ La connettività privata multi-VPC supporta i tipi di autenticazione IAM, TLS e SASL/SCRAM. I cluster non autenticati non possono utilizzare la connettività privata multi-VPC.
+ Se si utilizzano i metodi di controllo degli accessi SASL/SCRAM o MTLS, è necessario impostare Apache Kafka per il cluster. ACLs Innanzitutto, imposta Apache Kafka per il tuo cluster. ACLs Quindi, aggiorna la configurazione del cluster in modo che la proprietà `allow.everyone.if.no.acl.found` sia impostata su false per il cluster. Per informazioni su come aggiornare la configurazione di un cluster, consulta la pagina [Operazioni di configurazione del broker](msk-configuration-operations.md). Se utilizzi il Controllo degli accessi IAM e desideri applicare policy di autorizzazione o aggiornare le tue policy esistenti, consulta la sezione [Controllo degli accessi IAM](iam-access-control.md). Per informazioni su Apache Kafka, consulta. ACLs [Apache Kafka ACLs](msk-acls.md)
+ La connettività privata multi-VPC non supporta il tipo di istanza t3.small.
+ La connettività privata multi-VPC non è supportata in tutte AWS le regioni, ma solo negli AWS account all'interno della stessa regione.
+ Per configurare la connettività privata multi-VPC, è necessario disporre dello stesso numero di sottoreti client delle sottoreti del cluster. È inoltre necessario assicurarsi che [la zona IDs di disponibilità](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html) sia la stessa per la sottorete client e la sottorete del cluster.
+ Amazon MSK non supporta la connettività privata multi-VPC ai nodi ZooKeeper.
# Inizia a usare la connettività privata multi-VPC
**Topics**
+ [Passaggio 1: sul cluster MSK nell'account A, attiva la connettività multi-VPC per lo schema di autenticazione IAM sul cluster](mvpc-cluster-owner-action-turn-on.md)
+ [Passaggio 2: collegamento di una policy del cluster al cluster MSK](mvpc-cluster-owner-action-policy.md)
+ [Passaggio 3: operazioni dell'utente multi-account per configurare connessioni VPC gestite dal client](mvpc-cross-account-user-action.md)
Questo tutorial utilizza un caso d'uso comune come esempio di come utilizzare la connettività multi-VPC per connettere privatamente un client Apache Kafka a un cluster MSK dall'interno AWS ma dall'esterno del VPC del cluster. Questo processo richiede che l'utente multi-account crei una connessione e una configurazione VPC gestite da MSK per ogni client, comprese le autorizzazioni client richieste. Il processo richiede inoltre che il proprietario del cluster MSK abiliti la PrivateLink connettività sul cluster MSK e selezioni gli schemi di autenticazione per controllare l'accesso al cluster.
In diverse parti di questo tutorial, scegliamo le opzioni che si applicano a questo esempio. Ciò non significa che siano le uniche opzioni che funzionano per la configurazione di un cluster MSK o delle istanze client.
La configurazione di rete per questo caso d'uso è la seguente:
+ Un utente multi-account (client Kafka) e un cluster MSK si trovano nella stessa rete/regione AWS , ma in account diversi:
+ Cluster MSK nell'account A
+ Cliente Kafka nell'account B
+ L'utente multi-account si connetterà privatamente al cluster MSK utilizzando lo schema di autenticazione IAM.
Questo tutorial presuppone che esista un cluster MSK assegnato creato con Apache Kafka versione 2.7.1 o successiva. Il cluster MSK deve essere in uno stato ACTIVE prima di iniziare il processo di configurazione. Per evitare potenziali perdite di dati o tempi di inattività, i client che utilizzeranno una connessione privata multi-VPC per connettersi al cluster devono utilizzare versioni di Apache Kafka compatibili con il cluster.
Il diagramma seguente illustra l'architettura della connettività multi-VPC di Amazon MSK connessa a un client in un account diverso. AWS
![\[Diagramma di rete multi-VPC in una singola regione\]](http://docs.aws.amazon.com/it_it/msk/latest/developerguide/images/mvpc-network.png)
# Passaggio 1: sul cluster MSK nell'account A, attiva la connettività multi-VPC per lo schema di autenticazione IAM sul cluster
Il proprietario del cluster MSK deve configurare le impostazioni di configurazione sul cluster MSK dopo la creazione del cluster e in uno stato ACTIVE.
Il proprietario del cluster attiva la connettività privata multi-VPC sul cluster ACTIVE per tutti gli schemi di autenticazione che saranno attivi sul cluster. Questa operazione può essere eseguita utilizzando l'[UpdateSecurity API o la console](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-security.html) MSK. La connettività privata multi-VPC supporta gli schemi di autenticazione IAM, TLS e SASL/SCRAM. La connettività privata multi-VPC non può essere abilitata per i cluster non autenticati.
In questo caso d'uso, configurerai il cluster per utilizzare lo schema di autenticazione IAM.
**Nota**
Se state configurando il cluster MSK per utilizzare lo schema di SASL/SCRAM autenticazione, la proprietà Apache Kafka ACLs "" è obbligatoria. `allow.everyone.if.no.acl.found=false` [Vedi ACLs](https://docs.aws.amazon.com/msk/latest/developerguide/msk-acls.html) Apache Kafka.
Quando aggiorni le impostazioni di connettività privata multi-VPC, Amazon MSK intraprende un riavvio progressivo dei nodi del broker che aggiorna le configurazioni del broker. Il completamento del processo può richiedere fino a 30 minuti o più. Non è possibile apportare altri aggiornamenti al cluster durante l'aggiornamento della connettività.
**Attivazione del multi-VPC per gli schemi di autenticazione selezionati sul cluster nell'account A tramite la console**
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://docs.aws.amazon.com/msk/latest/developerguide/msk-acls.html)per l'account in cui si trova il cluster.
1. Nel riquadro di navigazione, in **Cluster MSK**, scegli **Cluster** per visualizzare l'elenco dei cluster presenti nell'account.
1. Seleziona il cluster da configurare per la connettività privata multi-VPC. Il cluster deve essere in uno stato ACTIVE.
1. Seleziona la scheda **Proprietà** del cluster, quindi vai a **Impostazioni di rete**.
1. Seleziona il menu a discesa **Modifica** e seleziona **Attiva la connettività multi-VPC**.
1. Seleziona uno o più tipi di autenticazione che desideri attivare per questo cluster. Per questo caso d'uso, seleziona l'**autenticazione basata sui ruoli IAM**.
1. Seleziona **Salva modifiche**.
**Example - UpdateConnectivity API che attiva schemi di autenticazione della connettività privata multi-VPC su un cluster**
In alternativa alla console MSK, è possibile utilizzare l'[UpdateConnectivity API](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-connectivity.html) per attivare la connettività privata multi-VPC e configurare gli schemi di autenticazione su un cluster ACTIVE. L'esempio seguente mostra lo schema di autenticazione IAM attivato per il cluster.
```
{
"currentVersion": "K3T4TT2Z381HKD",
"connectivityInfo": {
"vpcConnectivity": {
"clientAuthentication": {
"sasl": {
"iam": {
"enabled": TRUE
}
}
}
}
}
}
```
Amazon MSK crea l'infrastruttura di rete necessaria per la connettività privata. Amazon MSK crea anche un nuovo set di endpoint broker di bootstrap per ogni tipo di autenticazione che richiede la connettività privata. Tieni presente che lo schema di autenticazione non crittografata non supporta la connettività privata multi-VPC.
# Passaggio 2: collegamento di una policy del cluster al cluster MSK
Il proprietario del cluster può collegare una policy del cluster (nota anche come [policy basata sulle risorse](https://docs.aws.amazon.com/msk/latest/developerguide/security_iam_service-with-iam.html#security_iam_service-with-iam-resource-based-policies)) al cluster MSK in cui verrà attivata la connettività privata multi-VPC. La policy del cluster fornisce ai client l'autorizzazione ad accedere al cluster da un altro account. Prima di poter modificare la policy del cluster, sono necessari gli ID degli account che devono disporre dell'autorizzazione ad accedere al cluster MSK. Consulta la sezione [Funzionamento di Amazon MSK con IAM](https://docs.aws.amazon.com/msk/latest/developerguide/security_iam_service-with-iam.html).
Il proprietario del cluster deve collegare al cluster MSK una policy del cluster che autorizzi l'utente multi-account nell'account B a recuperare i broker di bootstrap per il cluster e ad autorizzare le seguenti operazioni sul cluster MSK nell'account A:
+ CreateVpcConnection
+ GetBootstrapBrokers
+ DescribeCluster
+ DescribeClusterV2
**Example**
A titolo di riferimento, di seguito è riportato un esempio di JSON per una policy di cluster di base, simile alla policy predefinita mostrata nell'editor di policy IAM della console MSK. La seguente politica concede le autorizzazioni per l'accesso a livello di cluster, argomento e gruppo.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "123456789012"
},
"Action": [
"kafka:CreateVpcConnection",
"kafka:GetBootstrapBrokers",
"kafka:DescribeCluster",
"kafka:DescribeClusterV2",
"kafka-cluster:*"
],
"Resource": "arn:aws:kafka:us-east-1:111122223333:cluster/testing/de8982fa-8222-4e87-8b20-9bf3cdfa1521-2"
},
{
"Effect": "Allow",
"Principal": {
"AWS": "123456789012"
},
"Action": "kafka-cluster:*",
"Resource": "arn:aws:kafka:us-east-1:111122223333:topic/testing/*"
},
{
"Effect": "Allow",
"Principal": {
"AWS": "123456789012"
},
"Action": "kafka-cluster:*",
"Resource": "arn:aws:kafka:us-east-1:111122223333:group/testing/*"
}
]
}
```
**Collegamento di una policy del cluster al cluster MSK**
1. Nella console Amazon MSK, in **Cluster MSK**, scegli **Cluster**.
1. Scorri verso il basso fino a **Impostazioni di sicurezza** e seleziona **Modifica policy del cluster**.
1. Nella console, nella schermata **Modifica policy del cluster**, seleziona **Policy di base per la connettività multi-VPC**.
1. Nel campo **ID account**, inserisci l'ID account per ogni account che dovrebbe disporre dell'autorizzazione per accedere a questo cluster. Durante la digitazione, l'ID viene automaticamente copiato nella sintassi JSON della policy visualizzata. Nel nostro esempio di policy del cluster, l'ID account è *111122223333*.
1. Seleziona **Salva modifiche**.
Per informazioni sulla politica dei cluster APIs, consulta le politiche basate sulle [risorse di Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/security_iam_service-with-iam.html#security_iam_service-with-iam-resource-based-policies).
# Passaggio 3: operazioni dell'utente multi-account per configurare connessioni VPC gestite dal client
Per configurare la connettività privata multi-VPC tra un client in un account diverso dal cluster MSK, l'utente multi-account crea una connessione VPC gestita per il client. È possibile connettere più client al cluster MSK ripetendo questa procedura. Ai fini di questo caso d'uso, configurerai un solo client.
I client possono utilizzare gli schemi di autenticazione supportati IAM, SASL/SCRAM o TLS. A ogni connessione VPC gestita può essere associato un solo schema di autenticazione. Lo schema di autenticazione del client deve essere configurato nel cluster MSK a cui il client si connetterà.
In questo caso d'uso, configura lo schema di autenticazione del client in modo che il client nell'account B utilizzi lo schema di autenticazione IAM.
**Prerequisiti**
Questo processo richiede i seguenti elementi:
+ La policy del cluster creata in precedenza che concede al client dell'account B l'autorizzazione a eseguire operazioni sul cluster MSK nell'account A.
+ Una politica di identità allegata al client nell'Account B che concede autorizzazioni e azioni`kafka:CreateVpcConnection`. `ec2:CreateTags` `ec2:CreateVPCEndpoint` `ec2:DescribeVpcAttribute`
**Example**
A titolo di riferimento, di seguito è riportato un esempio di JSON per una policy di identità del client di base.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka:CreateVpcConnection",
"ec2:CreateTags",
"ec2:CreateVPCEndpoint",
"ec2:DescribeVpcAttribute"
],
"Resource": "*"
}
]
}
```
**Creazione di una connessione VPC gestita per un client nell'account B**
1. Dall'amministratore del cluster, ottieni l'**ARN del cluster** MSK nell'account A al quale desideri che il client nell'account B si connetta. Prendi nota dell'ARN del cluster da utilizzare in seguito.
1. Nella console MSK per l'account client B, scegli **Connessioni VPC gestite**, quindi scegli **Crea connessione**.
1. Nel riquadro **Impostazioni di connessione**, incolla l'ARN del cluster nel campo di testo ARN del cluster, quindi scegli **Verifica**.
1. Seleziona **Tipo di autenticazione** per il client nell'account B. Per questo caso d'uso, scegli IAM quando crei la connessione VPC del client.
1. Scegli il **VPC** per il client.
1. Scegli almeno due **zone** di disponibilità e **sottoreti** associate. È possibile ottenere la zona di disponibilità IDs dai dettagli del cluster della Console di AWS gestione o utilizzando l'[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)API o il comando AWS CLI [describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html). La zona specificata per la sottorete client deve corrispondere a IDs quella della sottorete del cluster. Se mancano i valori per una sottorete, crea innanzitutto una sottorete con lo stesso ID di zona del cluster MSK.
1. Scegli un **Gruppo di sicurezza** per questa connessione VPC. È possibile accettare il gruppo di sicurezza predefinito. Per ulteriori informazioni sulla configurazione di un gruppo di sicurezza, consulta la pagina [Control traffic to resources using security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html).
1. Seleziona **Crea connessione**.
1. Per ottenere l'elenco delle nuove stringhe del broker di bootstrap dalla console MSK dell'utente multi-account (Dettagli del **cluster** > **Connessione VPC gestita**), consulta le stringhe del broker di bootstrap mostrate in "**Stringa di connessione al cluster**". Dall'account B del cliente, è possibile visualizzare l'elenco dei broker bootstrap richiamando l'[GetBootstrapBrokers](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-bootstrap-brokers.html#GetBootstrapBrokers)API o visualizzando l'elenco dei broker bootstrap nei dettagli del cluster della console.
1. Aggiorna i gruppi di sicurezza associati alle connessioni VPC come segue:
1. Imposta **le regole in entrata** per il PrivateLink VPC per consentire tutto il traffico per l'intervallo IP dalla rete dell'Account B.
1. [Facoltativo] Imposta la connettività delle **Regole in uscita** al cluster MSK. Scegli il **Gruppo di sicurezza** nella console VPC, **Modifica le regole in uscita** e aggiungi una regola per il **Traffico TCP personalizzato** per gli intervalli di porte 14001-14100. Il Network Load Balancer multi-VPC è in ascolto sugli intervalli di porte 14001-14100. Consulta la pagina [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html).
1. Configura il client nell'account B per utilizzare i nuovi broker di bootstrap per la connettività privata multi-VPC per connettersi al cluster MSK nell'account A. Consulta la sezione [Produzione e utilizzo di dati](https://docs.aws.amazon.com/msk/latest/developerguide/produce-consume.html).
Una volta completata l'autorizzazione, Amazon MSK crea una connessione VPC gestita per ogni VPC e schema di autenticazione specificati. Il gruppo di sicurezza scelto è associato a ciascuna connessione. Questa connessione VPC gestita è configurata da Amazon MSK per connettersi privatamente ai broker. Puoi utilizzare il nuovo set di broker di bootstrap per connetterti privatamente al cluster Amazon MSK.
# Aggiornamento degli schemi di autorizzazione su un cluster
La connettività privata multi-VPC supporta diversi schemi di autorizzazione: connettività SASL/SCRAM, IAM, and TLS. The cluster owner can turn on/off privata per uno o più schemi di autenticazione. Il cluster deve essere in stato ACTIVE per eseguire questa operazione.
**Attivazione di uno schema di autenticazione tramite la console Amazon MSK**
1. Apri la console Amazon MSK all'indirizzo [Console di gestione AWS](https://console.aws.amazon.com/msk) per il cluster che desideri modificare.
1. Nel riquadro di navigazione, in **Cluster MSK**, scegli **Cluster** per visualizzare l'elenco dei cluster presenti nell'account.
1. Seleziona il cluster da modificare. Il cluster deve essere in uno stato ACTIVE.
1. Seleziona la scheda **Proprietà** del cluster, quindi vai a **Impostazioni di rete**.
1. Seleziona il menu a discesa **Modifica** e seleziona **Attiva la connettività multi-VPC** per attivare un nuovo schema di autenticazione.
1. Seleziona uno o più tipi di autenticazione che desideri attivare per questo cluster.
1. Seleziona **Attiva la selezione**.
Quando attivi un nuovo schema di autenticazione, dovresti anche creare nuove connessioni VPC gestite per il nuovo schema di autenticazione e aggiornare i client di modo che utilizzino i broker di bootstrap specifici per il nuovo schema di autenticazione.
**Disattivazione di uno schema di autenticazione tramite la console Amazon MSK**
**Nota**
Quando si disattiva la connettività privata multi-VPC per gli schemi di autenticazione, tutte le infrastrutture relative alla connettività, incluse le connessioni VPC gestite, vengono eliminate.
Quando si disattiva la connettività privata multi-VPC per gli schemi di autenticazione, le connessioni VPC esistenti sul lato client diventano INACTIVE e l'infrastruttura PrivateLink sul lato cluster, incluse le connessioni VPC gestite, viene rimossa. L'utente multi-account può eliminare solo la connessione VPC inattiva. Se sul cluster viene riattivata la connettività privata, l'utente multi-account deve creare una nuova connessione al cluster.
1. Apri la console Amazon MSK all'indirizzo [Console di gestione AWS](https://console.aws.amazon.com/msk).
1. Nel riquadro di navigazione, in **Cluster MSK**, scegli **Cluster** per visualizzare l'elenco dei cluster presenti nell'account.
1. Seleziona il cluster da modificare. Il cluster deve essere in uno stato ACTIVE.
1. Seleziona la scheda **Proprietà** del cluster, quindi vai a **Impostazioni di rete**.
1. Seleziona il menu a discesa **Modifica** e seleziona **Disattiva la connettività multi-VPC** per disattivare uno schema di autenticazione.
1. Seleziona uno o più tipi di autenticazione che desideri disattivare per questo cluster.
1. Seleziona **Disattiva la selezione**.
**Example Per attivare on/off uno schema di autenticazione con l'API**
In alternativa alla console MSK, è possibile utilizzare l'[UpdateConnectivity API](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-connectivity.html) per attivare la connettività privata multi-VPC e configurare gli schemi di autenticazione su un cluster ACTIVE. L'esempio seguente mostra gli SASL/SCRAM schemi di autenticazione IAM attivati per il cluster.
Quando attivi un nuovo schema di autenticazione, dovresti anche creare nuove connessioni VPC gestite per il nuovo schema di autenticazione e aggiornare i client di modo che utilizzino i broker di bootstrap specifici per il nuovo schema di autenticazione.
Quando si disattiva la connettività privata multi-VPC per gli schemi di autenticazione, le connessioni VPC esistenti sul lato client diventano INACTIVE e l'infrastruttura PrivateLink sul lato cluster, incluse le connessioni VPC gestite, viene rimossa. L'utente multi-account può eliminare solo la connessione VPC inattiva. Se sul cluster viene riattivata la connettività privata, l'utente multi-account deve creare una nuova connessione al cluster.
```
Request:
{
"currentVersion": "string",
"connnectivityInfo": {
"publicAccess": {
"type": "string"
},
"vpcConnectivity": {
"clientAuthentication": {
"sasl": {
"scram": {
"enabled": TRUE
},
"iam": {
"enabled": TRUE
}
},
"tls": {
"enabled": FALSE
}
}
}
}
}
Response:
{
"clusterArn": "string",
"clusterOperationArn": "string"
}
```
# Rifiuto di una connessione VPC gestita a un cluster Amazon MSK
Dalla console Amazon MSK sull'account amministratore del cluster, puoi rifiutare una connessione VPC client. La connessione VPC del client deve essere nello stato AVAILABLE per essere rifiutata. Potresti voler rifiutare una connessione VPC gestita da un client che non è più autorizzato a connettersi al tuo cluster. Per evitare che nuove connessioni VPC gestite si connettano a un client, rifiuta l'accesso al client nella policy del cluster. Una connessione rifiutata comporta comunque dei costi fino a quando non viene eliminata dal proprietario della connessione. Consulta la sezione [Eliminazione di una connessione VPC gestita a un cluster Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/mvpc-cross-account-delete-connection.html).
**Rifiuto di una connessione VPC client tramite la console MSK**
1. Apri la console Amazon MSK all'indirizzo [Console di gestione AWS](https://console.aws.amazon.com/msk).
1. Nel riquadro di navigazione, seleziona **Cluster** e scorri fino all'elenco **Impostazioni di rete > Connessioni VPC client**.
1. Seleziona la connessione che desideri rifiutare e seleziona **Rifiuta connessione VPC client**.
1. Conferma il rifiuto della connessione VPC client selezionata.
Per rifiutare una connessione VPC gestita tramite l'API, utilizza l'API `RejectClientVpcConnection`.
# Eliminazione di una connessione VPC gestita a un cluster Amazon MSK
L'utente multi-account può eliminare una connessione VPC gestita per un cluster MSK dalla console dell'account client. Poiché l'utente proprietario del cluster non possiede la connessione VPC gestita, la connessione non può essere eliminata dall'account amministratore del cluster. Una volta eliminata, una connessione VPC non comporta più costi.
**Eliminazione di una connessione VPC tramite la console MSK**
1. Dall'account client, apri la console Amazon MSK all'indirizzo [Console di gestione AWS](https://console.aws.amazon.com/msk).
1. Nel riquadro di navigazione, seleziona **Connessioni VPC gestite**.
1. Dall'elenco delle connessioni, seleziona la connessione VPN da eliminare.
1. Conferma l'eliminazione della connessione VPC.
Per eliminare una connessione VPC gestita tramite l'API, utilizza l'API `DeleteVpcConnection`.
# Autorizzazioni per la connettività privata multi-VPC
Questa sezione riassume le autorizzazioni necessarie per client e cluster che utilizzano la funzionalità di connettività privata multi-VPC. La connettività privata multi-VPC richiede che l'amministratore del client crei le autorizzazioni su ogni client che avrà una connessione VPC gestita al cluster MSK. Richiede inoltre che l'amministratore del cluster MSK abiliti la PrivateLink connettività sul cluster MSK e selezioni gli schemi di autenticazione per controllare l'accesso al cluster.
**Autenticazione del cluster e autorizzazioni di accesso all'argomento**
Attiva la funzionalità di connettività privata multi-VPC per gli schemi di autenticazione abilitati per il tuo cluster MSK. Per informazioni, consulta [Requisiti e limitazioni per la connettività privata multi-VPC](aws-access-mult-vpc.md#mvpc-requirements). Se si sta configurando il cluster MSK per utilizzare lo schema di SASL/SCRAM autenticazione, la proprietà Apache Kafka è obbligatoria. ACLs `allow.everyone.if.no.acl.found=false` Dopo avere impostato le [Apache Kafka ACLs](msk-acls.md) per il cluster, aggiorna la configurazione del cluster in modo che la proprietà `allow.everyone.if.no.acl.found` del cluster sia impostata su false. Per informazioni su come aggiornare la configurazione di un cluster, consulta la pagina [Operazioni di configurazione del broker](msk-configuration-operations.md).
**Autorizzazioni delle policy del cluster multi-account**
Se un client Kafka si trova in un AWS account diverso dal cluster MSK, allega al cluster MSK una policy basata su cluster che autorizzi l'utente root del client per la connettività tra account. È possibile modificare la policy del cluster multi-VPC utilizzando l'editor di policy IAM nella console MSK (**impostazioni di sicurezza** del cluster > **Modifica policy del cluster**) oppure utilizzare quanto segue APIs per gestire la policy del cluster:
**PutClusterPolicy**
Collega la policy del cluster al cluster. È possibile utilizzare questa API per creare o aggiornare la policy del cluster MSK specificata. Se stai aggiornando la policy, il campo CurrentVersion è obbligatorio nel payload della richiesta.
**GetClusterPolicy**
Recupera il testo JSON del documento di policy del cluster collegato al cluster.
**DeleteClusterPolicy**
Elimina la policy del cluster.
Di seguito è riportato un esempio di JSON per una policy di cluster di base, simile a quella mostrata nell'editor di policy IAM della console MSK. La seguente policy concede le autorizzazioni per l'accesso a livello di cluster, argomento e gruppo.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": [
"123456789012"
]
},
"Action": [
"kafka-cluster:*",
"kafka:CreateVpcConnection",
"kafka:GetBootstrapBrokers",
"kafka:DescribeCluster",
"kafka:DescribeClusterV2"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:cluster/testing/de8982fa-8222-4e87-8b20-9bf3cdfa1521-2",
"arn:aws:kafka:us-east-1:123456789012:topic/testing/*",
"arn:aws:kafka:us-east-1:123456789012:group/testing/*"
]
}]
}
```
------
**Autorizzazioni client per la connettività privata multi-VPC a un cluster MSK**
Per configurare la connettività privata multi-VPC tra un client Kafka e un cluster MSK, il client richiede una policy di identità collegata che conceda autorizzazioni per le operazioni `kafka:CreateVpcConnection`, `ec2:CreateTags` e `ec2:CreateVPCEndpoint` sul client. A titolo di riferimento, di seguito è riportato un esempio di JSON per una policy di identità del client di base.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka:CreateVpcConnection",
"ec2:CreateTags",
"ec2:CreateVPCEndpoint"
],
"Resource": "*"
}
]
}
```
------
# Informazioni sulle porte
Utilizza i seguenti numeri di porta in modo che Amazon MSK possa comunicare con i computer client:
+ Per comunicare con i broker con testo non crittografato, utilizza la porta 9092.
+ Per comunicare con i broker con crittografia TLS, utilizza la porta 9094 per l'accesso dall'interno AWS e la porta 9194 per l'accesso pubblico.
+ Per comunicare con i broker con SASL/SCRAM, utilizzate la porta 9096 per l'accesso dall'interno e la porta 9196 per l'accesso pubblico. AWS
+ Per comunicare con i broker in un cluster configurato per l'uso[Controllo degli accessi IAM](iam-access-control.md), utilizzate la porta 9098 per l'accesso dall'interno e la porta 9198 per l'accesso pubblico. AWS
+ Per comunicare con i broker utilizzando il tipo di IPv6 rete in testo semplice, utilizzate la porta 20092
+ Per comunicare con i broker in un cluster configurato per utilizzare il controllo di accesso IAM utilizzando IPv6, utilizza la porta 20098.
+ Per comunicare con i broker SASL/SCRAM utilizzando IPv6, utilizza la porta 20096.
+ Per comunicare con i broker utilizzando la crittografia TLS IPv6, utilizzate la porta 20094.
# Ottieni i broker bootstrap per un cluster Amazon MSK
I *broker bootstrap fanno riferimento all'elenco di broker* che un client Apache Kafka può utilizzare per connettersi a un cluster Amazon MSK. Questo elenco potrebbe non includere tutti i broker del cluster. Puoi ottenere broker bootstrap utilizzando Console di gestione AWS AWS CLI, o l'API Amazon MSK.
**Topics**
+ [Ottieni i broker bootstrap usando il Console di gestione AWS](get-bootstrap-console.md)
+ [Ottieni i broker bootstrap usando il AWS CLI](get-bootstrap-cli.md)
+ [Ottieni i broker bootstrap utilizzando l'API](get-bootstrap-api.md)
# Ottieni i broker bootstrap usando il Console di gestione AWS
Questo processo descrive come ottenere broker bootstrap per un cluster utilizzando il. Console di gestione AWS Il termine *broker di bootstrap* si riferisce a un elenco di broker che un client Apache Kafka può utilizzare come punto di partenza per connettersi al cluster. Questo elenco non include necessariamente tutti i broker di un cluster.
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. La tabella mostra tutti i cluster per la regione corrente in questo account. Scegli il nome di un cluster per visualizzarne la descrizione.
1. Nella pagina **Riepilogo del cluster**, scegli **Visualizza informazioni sul client**. Questo mostra i broker bootstrap e la stringa di connessione Apache. ZooKeeper
# Ottieni i broker bootstrap usando il AWS CLI
Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) che hai ottenuto quando hai creato il cluster. Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per ulteriori informazioni, consulta [Elenca i cluster Amazon MSK](msk-list-clusters.md).
```
aws kafka get-bootstrap-brokers --cluster-arn ClusterArn
```
Per un cluster MSK che utilizza [Controllo degli accessi IAM](iam-access-control.md), l'output di questo comando è simile all'esempio JSON seguente.
```
{
"BootstrapBrokerStringSaslIam": "b-1.myTestCluster.123z8u.c2.kafka.us-west-1.amazonaws.com:9098,b-2.myTestCluster.123z8u.c2.kafka.us-west-1.amazonaws.com:9098"
}
```
L'esempio seguente mostra i broker di bootstrap per un cluster con accesso pubblico attivato. Usa il `BootstrapBrokerStringPublicSaslIam` per l'accesso pubblico e la `BootstrapBrokerStringSaslIam` stringa per l'accesso dall'interno AWS.
```
{
"BootstrapBrokerStringPublicSaslIam": "b-2-public.myTestCluster.v4ni96.c2.kafka-beta.us-east-1.amazonaws.com:9198,b-1-public.myTestCluster.v4ni96.c2.kafka-beta.us-east-1.amazonaws.com:9198,b-3-public.myTestCluster.v4ni96.c2.kafka-beta.us-east-1.amazonaws.com:9198",
"BootstrapBrokerStringSaslIam": "b-2.myTestCluster.v4ni96.c2.kafka-beta.us-east-1.amazonaws.com:9098,b-1.myTestCluster.v4ni96.c2.kafka-beta.us-east-1.amazonaws.com:9098,b-3.myTestCluster.v4ni96.c2.kafka-beta.us-east-1.amazonaws.com:9098"
}
```
La stringa dei broker di bootstrap deve contenere tre broker provenienti da tutte le zone di disponibilità in cui è implementato il cluster MSK (a meno che non siano disponibili solo due broker).
# Ottieni i broker bootstrap utilizzando l'API
Per fare in modo che i broker bootstrap utilizzino l'API, vedi. [GetBootstrapBrokers](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-bootstrap-brokers.html#GetBootstrapBrokers)
# Monitora un cluster Amazon MSK Provisioned
Esistono diversi modi in cui Amazon MSK ti aiuta a monitorare lo stato del tuo cluster Amazon MSK Provisioned.
+ Amazon MSK raccoglie i parametri di Apache Kafka e li invia ad Amazon CloudWatch dove puoi visualizzarli. Per ulteriori informazioni sui parametri Apache Kafka, inclusi quelli esposti da Amazon MSK, consulta la pagina [Monitoring](http://kafka.apache.org/documentation/#monitoring) nella documentazione di Apache Kafka.
+ Puoi anche monitorare il cluster MSK con Prometheus, un'applicazione di monitoraggio open source. Per informazioni su Prometheus, consulta la sezione relativa alla [panoramica](https://prometheus.io/docs/introduction/overview/) nella documentazione di Prometheus. Per informazioni su come monitorare il cluster MSK Provisioned con Prometheus, vedere. [Monitora un cluster MSK Provisioned con Prometheus](open-monitoring.md)
+ (Solo broker standard) Amazon MSK ti aiuta a monitorare la capacità di storage su disco inviandoti automaticamente avvisi sulla capacità di storage quando un cluster Provisioned sta per raggiungere il limite di capacità di storage. Gli avvisi forniscono anche raccomandazioni sulle misure migliori da intraprendere per risolvere i problemi rilevati. Ciò consente di identificare e risolvere rapidamente i problemi relativi alla capacità del disco prima che diventino critici. Amazon MSK invia automaticamente questi avvisi alla [console Amazon MSK](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/), ad Health Dashboard Amazon EventBridge e ai contatti e-mail del tuo account. AWS Per ulteriori informazioni sull'aumento della capacità di archiviazione, consulta [Usa gli avvisi sulla capacità di archiviazione di Amazon MSK](cluster-alerts.md).
**Topics**
+ [Visualizza i parametri di Amazon MSK utilizzando CloudWatch](cloudwatch-metrics.md)
+ [Metriche di Amazon MSK per il monitoraggio dei broker Standard con CloudWatch](metrics-details.md)
+ [Metriche di Amazon MSK per il monitoraggio dei broker Express con CloudWatch](metrics-details-express.md)
+ [Monitora un cluster MSK Provisioned con Prometheus](open-monitoring.md)
+ [Monitora i ritardi dei consumatori](consumer-lag.md)
+ [Usa gli avvisi sulla capacità di archiviazione di Amazon MSK](cluster-alerts.md)
# Visualizza i parametri di Amazon MSK utilizzando CloudWatch
Puoi monitorare i parametri per Amazon MSK utilizzando la CloudWatch console, la riga di comando o l' CloudWatch API. Le procedure seguenti mostrano come accedere ai parametri utilizzando questi diversi metodi.
**Per accedere alle metriche utilizzando la console CloudWatch**
Accedi a Console di gestione AWS e apri la CloudWatch console all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Nel riquadro di navigazione, seleziona **Parametri**.
1. Scegli la scheda **Tutti i parametri**, quindi scegli **AWS/Kafka**.
1. Per visualizzare i parametri a livello di argomento, scegliere **Topic, Broker ID, Cluster Name (Argomento, ID broker, Nome cluster)**; per parametri a livello di broker, scegliere **Broker ID, Cluster Name (ID broker, Nome cluster)**; e per parametri a livello di cluster, scegliere **Cluster Name (Nome cluster)**.
1. (Facoltativo) Nel riquadro grafico, seleziona una statistica e un periodo di tempo, quindi crea un CloudWatch allarme utilizzando queste impostazioni.
**Per accedere alle metriche utilizzando il AWS CLI**
Utilizzate le [metriche e i comandi dell'elenco](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html). [get-metric-statistics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-statistics.html)
**Per accedere alle metriche utilizzando la CLI CloudWatch**
Utilizza i comandi [mon-list-metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/cli/cli-mon-list-metrics.html) e [mon-get-stats](https://docs.aws.amazon.com/AmazonCloudWatch/latest/cli/cli-mon-get-stats.html).
**Per accedere alle metriche utilizzando l'API CloudWatch**
Utilizzare le operazioni [ListMetrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_ListMetrics.html) e [GetMetricStatistics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html).
# Metriche di Amazon MSK per il monitoraggio dei broker Standard con CloudWatch
Amazon MSK si integra con Amazon per CloudWatch consentirti di raccogliere, visualizzare e analizzare i CloudWatch parametri per i tuoi broker MSK Standard. Le metriche configurate per i cluster MSK Provisioned vengono raccolte automaticamente e inserite a intervalli di 1 minuto. CloudWatch È possibile impostare il livello di monitoraggio per un cluster MSK Provisioned su uno dei seguenti:,, o. `DEFAULT` `PER_BROKER` `PER_TOPIC_PER_BROKER` `PER_TOPIC_PER_PARTITION` Le tabelle nelle sezioni seguenti mostrano tutti i parametri resi disponibili a partire da ciascun livello di monitoraggio.
**Nota**
I nomi di alcuni parametri di Amazon MSK per il CloudWatch monitoraggio sono cambiati nella versione 3.6.0 e successive. Usa i nuovi nomi per monitorare questi parametri. Per i parametri con nomi modificati, la tabella seguente mostra il nome utilizzato nella versione 3.6.0 e successive, seguito dal nome nella versione 2.8.2.tiered.
I parametri del livello `DEFAULT` sono gratuiti. I prezzi per altre metriche sono descritti nella pagina [ CloudWatchdei prezzi di Amazon](https://aws.amazon.com/cloudwatch/pricing/).
## Monitoraggio del livello `DEFAULT`
I parametri descritti nella tabella seguente sono disponibili a livello di monitoraggio `DEFAULT` e sono gratuiti.
| Nome | Quando visibile | Dimensioni | Description |
| --- | --- | --- | --- |
| ActiveControllerCount | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome del cluster | Solo un controller per cluster deve essere attivo in qualsiasi momento. |
| BurstBalance | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il saldo residuo dei crediti di espansione input-output per i volumi EBS nel cluster. Utilizzalo per analizzare la latenza o la riduzione della velocità di trasmissione effettiva. `BurstBalance` non viene riportato per i volumi EBS quando le prestazioni di base di un volume sono maggiori delle prestazioni massime di espansione. Per ulteriori informazioni, consulta la pagina [I/O Credits and burst performance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html#IOcredit). |
| BytesInPerSec | Dopo aver creato un argomento. | Nome cluster, ID broker, argomento | Il numero di byte al secondo ricevuti dai client. Questo parametro è disponibile per broker e anche per argomento. |
| BytesOutPerSec | Dopo aver creato un argomento. | Nome cluster, ID broker, argomento | Il numero di byte al secondo inviati ai client. Questo parametro è disponibile per broker e anche per argomento. |
| ClientConnectionCount | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome del cluster, ID broker, autenticazione client | Il numero di connessioni client autenticate attive. |
| ConnectionCount | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di connessioni attive autenticate, non autenticate e tra broker. |
| CPUCreditBalance | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di crediti CPU ottenuti da un broker da quando è stato lanciato. I crediti vengono accumulati nel saldo del credito dopo che sono stati ottenuti e rimossi dal saldo del credito una volta spesi. L'esaurimento del credito della CPU può avere un impatto negativo sulle prestazioni del cluster. È possibile adottare delle misure per ridurre il carico della CPU. Ad esempio, puoi ridurre il numero di richieste dei client o aggiornare il tipo di broker a un tipo di broker M5. |
| CpuIdle | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La percentuale di tempo di inattività della CPU. |
| CpuIoWait | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La percentuale di inattività della CPU durante un'operazione su disco in sospeso. |
| CpuSystem | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La percentuale di CPU nello spazio del kernel. |
| CpuUser | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La percentuale di CPU nello spazio utente. |
| GlobalPartitionCount | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome del cluster | Il numero di partizioni in tutti gli argomenti del cluster, escluse le repliche. Poiché GlobalPartitionCount non include le repliche, la somma dei PartitionCount valori può essere superiore a quella che si otterrebbe GlobalPartitionCount se il fattore di replica per un argomento fosse maggiore di 1. |
| GlobalTopicCount | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome del cluster | Numero totale di argomenti in tutti i broker nel cluster. |
| EstimatedMaxTimeLag\$1 | Dopo che un gruppo di consumatori ha utilizzato un argomento. | Nome del cluster, gruppo di consumatori, argomento | Tempo stimato (in secondi) per lo svuotamento di MaxOffsetLag. |
| KafkaAppLogsDiskUsed | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La percentuale di spazio su disco utilizzata per i log delle applicazioni. |
| KafkaDataLogsDiskUsed (dimensione Cluster Name, Broker ID) | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La percentuale di spazio su disco utilizzato per i log dei dati. |
| LeaderCount | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero totale di leader delle partizioni per broker, escluse le repliche. |
| MaxOffsetLag\$1 | Dopo che un gruppo di consumatori ha utilizzato un argomento. | Nome del cluster, gruppo di consumatori, argomento | Il ritardo massimo di offset su tutte le partizioni di un argomento. |
| MemoryBuffered | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La dimensione in byte di memoria nel buffer per il broker. |
| MemoryCached | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La dimensione in byte di memoria nella cache per il broker. |
| MemoryFree | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La dimensione in byte di memoria libera e disponibile per il broker. |
| HeapMemoryAfterGC | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La percentuale di memoria heap totale in uso dopo la rimozione di oggetti inutili. |
| MemoryUsed | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La dimensione in byte di memoria utilizzata per il broker. |
| MessagesInPerSec | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di messaggi in entrata al secondo per il broker. |
| NetworkRxDropped | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di pacchetti ricezione eliminati. |
| NetworkRxErrors | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di errori ricezione di rete per il broker. |
| NetworkRxPackets | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di pacchetti ricevuti dal broker. |
| NetworkTxDropped | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di pacchetti trasmissione eliminati. |
| NetworkTxErrors | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di errori trasmissione di rete per il broker. |
| NetworkTxPackets | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di pacchetti trasmessi dal broker. |
| OfflinePartitionsCount | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome del cluster | Numero totale di partizioni che sono offline nel cluster. |
| PartitionCount | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero totale di partizioni di argomento per broker, incluse le repliche. |
| ProduceTotalTimeMsMean | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il tempo di produzione medio in millisecondi. |
| RequestBytesMean | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero medio di byte della richiesta per il broker. |
| RequestTime | Dopo l'applicazione del throttling della richiesta. | Nome cluster, ID broker | Il tempo medio in millisecondi trascorso nella rete di broker e nei thread I/O per elaborare le richieste. |
| RootDiskUsed | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La percentuale del disco radice utilizzato dal broker. |
| RollingEstimatedTimeLagMax\$1 | Dopo che un gruppo di consumatori ha utilizzato un argomento. | Nome del cluster, gruppo di consumatori, argomento | Stima del tempo massimo (in secondi) necessario per ridurre il ritardo di offset della partizione su tutte le partizioni di un argomento. |
| SumOffsetLag\$1 | Dopo che un gruppo di consumatori ha utilizzato un argomento. | Nome del cluster, gruppo di consumatori, argomento | Il ritardo di offset aggregato per tutte le partizioni di un argomento. |
| SwapFree | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La dimensione in byte della memoria swap disponibile per il broker. |
| SwapUsed | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La dimensione in byte della memoria swap utilizzata dal broker. |
| TrafficShaping | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Parametri di alto livello che indicano il numero di pacchetti formati (abbandonati o messi in coda) a causa di un eccesso di allocazioni di rete. Maggiori dettagli sono disponibili con i parametri PER\$1BROKER. |
| UnderMinIsrPartitionCount | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di partizioni minIsr under per il broker. |
| UnderReplicatedPartitions | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di partizioni replicate per il broker. |
| UserPartitionExists | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Una metrica booleana che indica la presenza di una partizione di proprietà dell'utente su un broker. Il valore 1 indica la presenza di partizioni sul broker. |
| ZooKeeperRequestLatencyMsMean | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Per cluster ZooKeeper basato. La latenza media in millisecondi per le richieste ZooKeeper Apache al broker. |
| ZooKeeperSessionState | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Per cluster basato. ZooKeeper Stato della connessione della ZooKeeper sessione del broker che può essere una delle seguenti: NOT\$1CONNECTED: '0.0', ASSOCIATING: '0.1', CONNECTING: '0.5', CONNECTEDREADONLY: '0.8', CONNECTED: '1.0', CLOSED: '5.0', AUTH\$1FAILED: '10.0'. |
\$1 Le metriche relative al ritardo dei consumatori richiedono solo nomi di gruppi di consumatori in formato ASCII e hanno requisiti di emissione specifici. Per ulteriori informazioni, consulta [Monitora i ritardi dei consumatori](consumer-lag.md).
## Monitoraggio del livello `PER_BROKER`
Quando imposti il livello di monitoraggio su `PER_BROKER`, ottieni i parametri descritti nella tabella seguente oltre a tutti i parametri del livello `DEFAULT`. Paghi per i parametri nella tabella seguente, mentre i parametri del livello `DEFAULT` continuano a essere gratuiti. I parametri contenuti in questa tabella hanno le seguenti dimensioni: Nome cluster, ID broker.
| Nome | Quando visibile | Description |
| --- | --- | --- |
| BwInAllowanceExceeded | Dopo che il cluster raggiunge lo stato ACTIVE. | Numero di pacchetti modellati perché la larghezza di banda aggregata in entrata ha superato il valore massimo per l'istanza. |
| BwOutAllowanceExceeded | Dopo che il cluster raggiunge lo stato ACTIVE. | Numero di pacchetti modellati perché la larghezza di banda aggregata in uscita ha superato il valore massimo per l'istanza. |
| ConntrackAllowanceExceeded | Dopo che il cluster raggiunge lo stato ACTIVE. | Numero di pacchetti modellati perché il tracciamento della connessione ha superato il valore massimo per il broker. Il tracciamento della connessione è legato ai gruppi di sicurezza che tengono traccia di ogni connessione stabilita per garantire che i pacchetti restituiti vengano consegnati come previsto. |
| ConnectionCloseRate | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero di connessioni chiuse al secondo per ascoltatore. Questo numero viene aggregato per ascoltatore e filtrato per gli ascoltatori client. |
| ConnectionCreationRate | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero di nuove connessioni stabilite al secondo per ascoltatore. Questo numero viene aggregato per ascoltatore e filtrato per gli ascoltatori client. |
| CpuCreditUsage | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero di crediti CPU utilizzati dal broker. L'esaurimento del credito della CPU può avere un impatto negativo sulle prestazioni del cluster. È possibile adottare delle misure per ridurre il carico della CPU. Ad esempio, puoi ridurre il numero di richieste dei client o aggiornare il tipo di broker a un tipo di broker M5. |
| FetchConsumerLocalTimeMsMean | Dopo che c'è un produttore/consumatore. | Tempo medio in millisecondi di elaborazione della richiesta del consumatore presso il leader. |
| FetchConsumerRequestQueueTimeMsMean | Dopo che c'è un produttore/consumatore. | Tempo medio in millisecondi di attesa della richiesta del consumatore nella coda delle richieste. |
| FetchConsumerResponseQueueTimeMsMean | Dopo che c'è un produttore/consumatore. | Tempo medio in millisecondi di attesa della richiesta del consumatore nella coda delle risposte. |
| FetchConsumerResponseSendTimeMsMean | Dopo che c'è un produttore/consumatore. | Tempo medio in millisecondi impiegato dal consumatore per inviare una risposta. |
| FetchConsumerTotalTimeMsMean | Dopo che c'è un produttore/consumatore. | Il tempo totale medio in millisecondi impiegato dai consumatori per recuperare i dati dal broker. |
| FetchFollowerLocalTimeMsMean | Dopo che c'è un produttore/consumatore. | Tempo medio in millisecondi impiegato a livello di leader per elaborare la richiesta follower. |
| FetchFollowerRequestQueueTimeMsMean | Dopo che c'è un produttore/consumatore. | Tempo medio in millisecondi di attesa della richiesta follower nella coda delle richieste. |
| FetchFollowerResponseQueueTimeMsMean | Dopo che c'è un produttore/consumatore. | Tempo medio in millisecondi di attesa della richiesta follower nella coda delle risposte. |
| FetchFollowerResponseSendTimeMsMean | Dopo che c'è un produttore/consumatore. | Tempo medio in millisecondi impiegato dal follower per inviare una risposta. |
| FetchFollowerTotalTimeMsMean | Dopo che c'è un produttore/consumatore. | Il tempo totale medio in millisecondi impiegato dai follower per recuperare i dati dal broker. |
| FetchMessageConversionsPerSec | Dopo aver creato un argomento. | Il numero di conversioni dei messaggi di recupero al secondo per il broker. |
| FetchThrottleByteRate | Dopo l'applicazione del throttling della larghezza di banda. | Il numero di byte sottoposti a throttling al secondo. |
| FetchThrottleQueueSize | Dopo l'applicazione del throttling della larghezza di banda. | Il numero di messaggi nella coda di throttling. |
| FetchThrottleTime | Dopo l'applicazione del throttling della larghezza di banda. | Il tempo medio del throttling di recupero in millisecondi. |
| IAMNumberOfConnectionRequests | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero di richieste di autenticazione IAM al secondo. |
| IAMTooManyConnections | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero di connessioni tentate è superiore a 100. 0 indica che il numero di connessioni rientra nel limite. Se >0, il limite di accelerazione viene superato ed è necessario ridurre il numero di connessioni. |
| LinklocalAllowanceExceeded | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero di pacchetti accodati o rilasciati perché il PPS del traffico verso i servizi proxy locali ha superato il valore massimo per l'interfaccia di rete. Ciò influisce sul traffico verso il servizio DNS, il servizio di metadati dell'istanza e il servizio Amazon Time Sync. |
| NetworkProcessorAvgIdlePercent | Dopo che il cluster raggiunge lo stato ACTIVE. | La percentuale media del tempo di inattività dei processori di rete. |
| PpsAllowanceExceeded | Dopo che il cluster raggiunge lo stato ACTIVE. | Numero di pacchetti modellati perché il PPS bidirezionale ha superato il valore massimo per il broker. |
| ProduceLocalTimeMsMean | Dopo che il cluster raggiunge lo stato ACTIVE. | Tempo medio in millisecondi impiegato a livello di leader per elaborare la richiesta. |
| ProduceMessageConversionsPerSec | Dopo aver creato un argomento. | Il numero di conversioni di messaggi di produzione al secondo per il broker. |
| ProduceMessageConversionsTimeMsMean | Dopo che il cluster raggiunge lo stato ACTIVE. | Il tempo medio in millisecondi impiegato per le conversioni di formato dei messaggi. |
| ProduceRequestQueueTimeMsMean | Dopo che il cluster raggiunge lo stato ACTIVE. | Il tempo medio in millisecondi che i messaggi di richiesta rimangono nella coda. |
| ProduceResponseQueueTimeMsMean | Dopo che il cluster raggiunge lo stato ACTIVE. | Il tempo medio in millisecondi che messaggi di risposta rimangono nella coda. |
| ProduceResponseSendTimeMsMean | Dopo che il cluster raggiunge lo stato ACTIVE. | Il tempo medio in millisecondi impiegato per l'invio di messaggi di risposta. |
| ProduceThrottleByteRate | Dopo l'applicazione del throttling della larghezza di banda. | Il numero di byte sottoposti a throttling al secondo. |
| ProduceThrottleQueueSize | Dopo l'applicazione del throttling della larghezza di banda. | Il numero di messaggi nella coda di throttling. |
| ProduceThrottleTime | Dopo l'applicazione del throttling della larghezza di banda. | Il tempo di throttling di produzione medio in millisecondi. |
| ProduceTotalTimeMsMean | Dopo che il cluster raggiunge lo stato ACTIVE. | Il tempo di produzione medio in millisecondi. |
| `RemoteFetchBytesPerSec (RemoteBytesInPerSec in v2.8.2.tiered)` | Dopo che è presente un produttore/consumatore. | Il numero totale di byte trasferiti dall'archiviazione a più livelli in risposta alle richieste dei consumatori. Questo parametro include tutte le partizioni di argomento che contribuiscono al traffico di trasferimento dati a valle. Categoria: traffico e tassi di errore. Questo è un parametro [KIP-405](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage). |
| RemoteCopyBytesPerSec (RemoteBytesOutPerSec in v2.8.2.tiered) | Dopo che è presente un produttore/consumatore. | Il numero totale di byte trasferiti nell'archiviazione a più livelli, inclusi i dati provenienti da segmenti di log, indici e altri file ausiliari. Questo parametro include tutte le partizioni di argomento che contribuiscono al traffico di trasferimento dati a monte. Categoria: traffico e tassi di errore. Questo è un parametro [KIP-405](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage). |
| RemoteLogManagerTasksAvgIdlePercent | Dopo che il cluster raggiunge lo stato ACTIVE. | La percentuale media di tempo che il gestore di log remoto ha trascorso inattivo. Il gestore remoto dei log trasferisce i dati dal broker all'archiviazione a più livelli. Categoria: attività interna. Questo è un parametro [KIP-405](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage). |
| RemoteLogReaderAvgIdlePercent | Dopo che il cluster raggiunge lo stato ACTIVE. | La percentuale media di tempo che il lettore di log remoto ha trascorso inattivo. Il lettore di log remoto trasferisce i dati dall'archiviazione remota al broker in risposta alle richieste dei consumatori. Categoria: attività interna. Questo è un parametro [KIP-405](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage). |
| RemoteLogReaderTaskQueueSize | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero di attività responsabili delle letture dall'archiviazione a più livelli in attesa di essere pianificate. Categoria: attività interna. Questo è un parametro [KIP-405](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage). |
| RemoteFetchErrorsPerSec (RemoteReadErrorPerSec in v2.8.2.tiered) | Dopo che il cluster raggiunge lo stato ACTIVE. | La percentuale totale di errori in risposta alle richieste di lettura che il broker specificato ha inviato all'archiviazione a più livelli per recuperare i dati in risposta alle richieste dei consumatori. Questo parametro include tutte le partizioni di argomento che contribuiscono al traffico di trasferimento dati a valle. Categoria: traffico e tassi di errore. Questo è un parametro [KIP-405](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage). |
| RemoteFetchRequestsPerSec (RemoteReadRequestsPerSec in v2.8.2.tiered) | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero totale di richieste di lettura che il broker specificato ha inviato all'archiviazione a più livelli per recuperare i dati in risposta alle richieste dei consumatori. Questo parametro include tutte le partizioni di argomento che contribuiscono al traffico di trasferimento dati a valle. Categoria: traffico e tassi di errore. Questo è un parametro [KIP-405](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage). |
| RemoteCopyErrorsPerSec (RemoteWriteErrorPerSec in v2.8.2.tiered) | Dopo che il cluster raggiunge lo stato ACTIVE. | La percentuale totale di errori in risposta alle richieste di scrittura che il broker specificato ha inviato all'archiviazione a più livelli per trasferire i dati a monte. Questo parametro include tutte le partizioni di argomento che contribuiscono al traffico di trasferimento dati a monte. Categoria: traffico e tassi di errore. Questo è un parametro [KIP-405](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage). |
| RemoteLogSizeBytes | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero di byte archiviati sul livello remoto. Questa metrica è disponibile per i cluster di storage su più livelli di Apache Kafka versione 3.7.x su Amazon MSK. |
| ReplicationBytesInPerSec | Dopo aver creato un argomento. | Il numero di byte al secondo ricevuti da altri broker. |
| ReplicationBytesOutPerSec | Dopo aver creato un argomento. | Il numero di byte al secondo inviati ad altri broker. |
| RequestExemptFromThrottleTime | Dopo l'applicazione del throttling della richiesta. | Il tempo medio in millisecondi trascorso nella rete di broker e nei thread I/O per elaborare le richieste esenti da throttling. |
| RequestHandlerAvgIdlePercent | Dopo che il cluster raggiunge lo stato ACTIVE. | La percentuale media del tempo di inattività dei thread del gestore di richieste. |
| RequestThrottleQueueSize | Dopo l'applicazione del throttling della richiesta. | Il numero di messaggi nella coda di throttling. |
| RequestThrottleTime | Dopo l'applicazione del throttling della richiesta. | Il tempo di throttling della richiesta medio in millisecondi. |
| TcpConnections | Dopo che il cluster raggiunge lo stato ACTIVE. | Mostra il numero di segmenti TCP in entrata e in uscita con il flag SYN impostato. |
| RemoteCopyLagBytes (TotalTierBytesLag in v2.8.2.tiered) | Dopo aver creato un argomento. | Il numero totale di byte dei dati idonei per l'archiviazione a più livelli sul broker ma che non sono ancora stati trasferiti in tale archiviazione. Questi parametri mostrano l'efficienza del trasferimento dati a monte. Con l'aumentare del ritardo, aumenta la quantità di dati che non persistono nell'archiviazione a più livelli. Categoria: ritardo di archiviazione. Questo non è un parametro KIP-405. |
| TrafficBytes | Dopo che il cluster raggiunge lo stato ACTIVE. | Mostra il traffico di rete in byte complessivi tra client (produttori e consumatori) e broker. Il traffico tra i broker non viene segnalato. |
| VolumeQueueLength | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero di richieste di operazioni di lettura e scrittura in attesa di completamento nel periodo di tempo specificato. |
| VolumeReadBytes | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero di byte letti durante il periodo di tempo specificato. |
| VolumeReadOps | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero totale di operazioni di lettura nel periodo di tempo specificato. |
| VolumeTotalReadTime | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero totale di secondi impiegato da tutte le operazioni di lettura completate nel periodo di tempo specificato. |
| VolumeTotalWriteTime | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero totale di secondi impiegato da tutte le operazioni di scrittura completate nel periodo di tempo specificato. |
| VolumeWriteBytes | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero di byte scritti durante il periodo di tempo specificato. |
| VolumeWriteOps | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero totale di operazioni di scrittura durante il periodo di tempo specificato. |
## Monitoraggio del livello `PER_TOPIC_PER_BROKER`
Quando imposti il livello di monitoraggio su `PER_TOPIC_PER_BROKER`, ottieni i parametri descritti nella tabella seguente, oltre a tutti i parametri dei livelli `PER_BROKER` e DEFAULT. Solo i parametri del livello `DEFAULT` sono gratuiti. I parametri contenuti in questa tabella hanno le seguenti dimensioni: Nome cluster, ID broker, Argomento.
**Importante**
Per un cluster Amazon MSK che utilizza Apache Kafka 2.4.1 o una versione più recente, i parametri nella tabella seguente vengono visualizzati solo dopo che i loro valori diventano diversi da zero per la prima volta. Ad esempio, per visualizzare `BytesInPerSec`, uno o più produttori devono prima inviare i dati al cluster.
| Nome | Quando visibile | Description |
| --- | --- | --- |
| FetchMessageConversionsPerSec | Dopo aver creato un argomento. | Il numero di messaggi recuperati convertiti al secondo. |
| MessagesInPerSec | Dopo aver creato un argomento. | Il numero di messaggi ricevuti al secondo. |
| ProduceMessageConversionsPerSec | Dopo aver creato un argomento. | Il numero di conversioni al secondo per i messaggi prodotti. |
| RemoteFetchBytesPerSec (RemoteBytesInPerSec in v2.8.2.tiered) | Dopo aver creato un argomento, l'argomento è in fase di produzione/utilizzo. | Il numero di byte trasferiti nell'archiviazione a più livelli in risposta alle richieste dei consumatori per l'argomento e il broker specificati. Questo parametro include tutte le partizioni dell'argomento che contribuiscono al traffico di trasferimento dati a valle sul broker specificato. Categoria: traffico e tassi di errore. Questo è un parametro [KIP-405](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage). |
| RemoteCopyBytesPerSec (RemoteBytesOutPerSec in v2.8.2.tiered) | Dopo aver creato un argomento, l'argomento è in fase di produzione/utilizzo. | Il numero di byte trasferiti nell'archiviazione a più livelli per l'argomento e il broker specificati. Questo parametro include tutte le partizioni dell'argomento che contribuiscono al traffico di trasferimento dati a monte sul broker specificato. Categoria: traffico e tassi di errore. Questo è un parametro [KIP-405](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage). |
| RemoteFetchErrorsPerSec (RemoteReadErrorPerSec in v2.8.2.tiered) | Dopo aver creato un argomento, l'argomento è in fase di produzione/utilizzo. | La percentuale di errori in risposta alle richieste di lettura che il broker specificato invia all'archiviazione a più livelli per recuperare i dati in risposta alle richieste dei consumatori in relazione all'argomento specificato. Questo parametro include tutte le partizioni dell'argomento che contribuiscono al traffico di trasferimento dati a valle sul broker specificato. Categoria: traffico e tassi di errore. Questo è un parametro [KIP-405](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage). |
| RemoteFetchRequestsPerSec (RemoteReadRequestsPerSec in v2.8.2.tiered) | Dopo aver creato un argomento, l'argomento è in fase di produzione/utilizzo. | Il numero di richieste di lettura che il broker specificato invia all'archiviazione a più livelli per recuperare i dati in risposta alle richieste dei consumatori in relazione all'argomento specificato. Questo parametro include tutte le partizioni dell'argomento che contribuiscono al traffico di trasferimento dati a valle sul broker specificato. Categoria: traffico e tassi di errore. Questo è un parametro [KIP-405](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage). |
| RemoteCopyErrorsPerSec (RemoteWriteErrorPerSec in v2.8.2.tiered) | Dopo aver creato un argomento, l'argomento è in fase di produzione/utilizzo. | La percentuale di errori in risposta alle richieste di scrittura che il broker specificato invia all'archiviazione a più livelli per trasferire i dati a monte. Questo parametro include tutte le partizioni dell'argomento che contribuiscono al traffico di trasferimento dati a monte sul broker specificato. Categoria: traffico e tassi di errore. Questo è un parametro [KIP-405](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage). |
| RemoteLogSizeBytes | Dopo aver creato un argomento. | Il numero di byte archiviati sul livello remoto. Questa metrica è disponibile per i cluster di storage su più livelli di Apache Kafka versione 3.7.x su Amazon MSK. |
## Monitoraggio del livello `PER_TOPIC_PER_PARTITION`
Quando imposti il livello di monitoraggio su `PER_TOPIC_PER_PARTITION`, ottieni i parametri descritti nella tabella seguente, oltre a tutti i parametri dei livelli `PER_TOPIC_PER_BROKER`, `PER_BROKER` e DEFAULT. Solo i parametri del livello `DEFAULT` sono gratuiti. I parametri in questa tabella hanno le seguenti dimensioni: gruppo di consumatori, argomento, partizione.
| Nome | Quando visibile | Description |
| --- | --- | --- |
| EstimatedTimeLag\$1 | Dopo che un gruppo di consumatori ha utilizzato un argomento. | Tempo stimato (in secondi) per eliminare il ritardo di offset della partizione. |
| OffsetLag\$1 | Dopo che un gruppo di consumatori ha utilizzato un argomento. | Ritardo del consumatore a livello di partizione nel numero di offset. |
| RollingEstimatedTimeLag\$1 | Dopo che un gruppo di consumatori ha utilizzato un argomento. | Stima del tempo di rolling (in secondi) per ridurre il ritardo di offset della partizione. |
\$1 Le metriche relative al ritardo dei consumatori richiedono solo nomi di gruppi di consumatori in formato ASCII e hanno requisiti di emissione specifici. Per ulteriori informazioni, consulta [Monitora i ritardi dei consumatori](consumer-lag.md).
# Comprendi gli stati del cluster MSK Provisioned
La tabella seguente mostra i possibili stati di un cluster MSK Provisioned e ne descrive il significato. Se non diversamente specificato, gli stati del cluster MSK Provisioned si applicano sia ai tipi di broker Standard che Express. Questa tabella descrive anche le azioni che è possibile e non è possibile eseguire quando un cluster MSK Provisioned si trova in uno di questi stati. Per scoprire lo stato di un cluster, consulta la Console di gestione AWS. È inoltre possibile utilizzare il comando [describe-cluster-v2](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster-v2.html) o l'operazione [DescribeClusterV2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters-clusterarn.html#DescribeClusterV2) per descrivere il cluster Provisioned. La descrizione di un cluster include il relativo stato.
****
| Stato del cluster MSK Provisioned | Significato e operazioni possibili |
| --- | --- |
| ACTIVE | Puoi produrre e utilizzare dati. Puoi anche eseguire l'API e AWS CLI le operazioni di Amazon MSK sul cluster. |
| CREAZIONE IN CORSO | Amazon MSK sta configurando il cluster Provisioned. È necessario attendere che il cluster raggiunga lo stato ATTIVO prima di poterlo utilizzare per produrre o consumare dati o per eseguire l'API o AWS CLI le operazioni di Amazon MSK su di esso. |
| ELIMINAZIONE IN CORSO | Il cluster Provisioned viene eliminato. Non è possibile utilizzarlo per produrre o utilizzare dati. Inoltre, non è possibile eseguire l'API o AWS CLI le operazioni di Amazon MSK su di essa. |
| NON RIUSCITO | Il processo di creazione o eliminazione del cluster Provisioned non è riuscito. Non è possibile utilizzare il cluster per produrre o utilizzare dati. È possibile eliminare il cluster ma non è possibile eseguire operazioni di API Amazon MSK o di AWS CLI aggiornamento su di esso. |
| HEALING | Amazon MSK sta eseguendo un'operazione interna, ad esempio la sostituzione di un broker non funzionante. Ad esempio, il broker potrebbe non rispondere. Puoi comunque utilizzare il cluster Provisioned per produrre e consumare dati. Tuttavia, non è possibile eseguire l'API di Amazon MSK o AWS CLI aggiornare le operazioni sul cluster finché non torna allo stato ACTIVE. |
| MAINTENANCE | (Solo broker standard) Amazon MSK esegue operazioni di manutenzione ordinaria sul cluster. Tali operazioni di manutenzione includono l'applicazione di patch di sicurezza. È ancora possibile utilizzare il cluster per produrre e utilizzare dati. Tuttavia, non è possibile eseguire operazioni di aggiornamento dell'API o della AWS CLI di Amazon MSK sul cluster finché non torna allo stato ACTIVE. Lo stato del cluster rimane ATTIVO durante la manutenzione sui broker Express. Per informazioni, consulta [Applicazione di patch sui cluster MSK Provisioned](patching-impact.md). |
| REBOOTING\$1BROKER | Amazon MSK sta riavviando un broker. È ancora possibile utilizzare il cluster Provisioned per produrre e consumare dati. Tuttavia, non è possibile eseguire l'API di Amazon MSK o AWS CLI aggiornare le operazioni sul cluster finché non torna allo stato ACTIVE. |
| AGGIORNAMENTO IN CORSO | Un'API o un' AWS CLI operazione Amazon MSK avviata dall'utente sta aggiornando il cluster Provisioned. Puoi comunque utilizzare il cluster Provisioned per produrre e consumare dati. Tuttavia, non è possibile eseguire alcuna API Amazon MSK aggiuntiva o eseguire operazioni di AWS CLI aggiornamento sul cluster finché non torna allo stato ATTIVO. |
# Metriche di Amazon MSK per il monitoraggio dei broker Express con CloudWatch
Amazon MSK si integra per CloudWatch consentirti di raccogliere, visualizzare e analizzare i CloudWatch parametri per i tuoi broker MSK Express. Le metriche configurate per i cluster MSK Provisioned vengono raccolte automaticamente e inserite a intervalli di 1 minuto. CloudWatch È possibile impostare il livello di monitoraggio per un cluster MSK Provisioned su uno dei seguenti:,, o. `DEFAULT` `PER_BROKER` `PER_TOPIC_PER_BROKER` `PER_TOPIC_PER_PARTITION` Le tabelle nelle sezioni seguenti mostrano le metriche disponibili a partire da ogni livello di monitoraggio.
I parametri del livello `DEFAULT` sono gratuiti. I prezzi per altre metriche sono descritti nella pagina [ CloudWatchdei prezzi di Amazon](https://aws.amazon.com/cloudwatch/pricing/).
## `DEFAULT`Monitoraggio dei livelli per i broker Express
Le metriche descritte nella tabella seguente sono disponibili gratuitamente a livello di `DEFAULT` monitoraggio.
| Nome | Quando visibile | Dimensioni | Description |
| --- | --- | --- | --- |
| ActiveControllerCount | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome del cluster | Solo un controller per cluster deve essere attivo in qualsiasi momento. |
| BytesInPerSec | Dopo aver creato un argomento. | Nome cluster, ID broker, argomento | Il numero di byte al secondo ricevuti dai client. Questo parametro è disponibile per broker e anche per argomento. |
| BytesOutPerSec | Dopo aver creato un argomento. | Nome cluster, ID broker, argomento | Il numero di byte al secondo inviati ai client. Questo parametro è disponibile per broker e anche per argomento. |
| ClientConnectionCount | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome del cluster, ID broker, autenticazione client | Il numero di connessioni client autenticate attive. |
| ConnectionCount | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di connessioni attive autenticate, non autenticate e tra broker. |
| CpuIdle | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La percentuale di tempo di inattività della CPU. |
| CpuSystem | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La percentuale di CPU nello spazio del kernel. |
| CpuUser | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La percentuale di CPU nello spazio utente. |
| GlobalPartitionCount | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome del cluster | Il numero di partizioni in tutti gli argomenti del cluster, escluse le repliche. Poiché `GlobalPartitionCount` non include le repliche, la somma dei `PartitionCount` valori può essere superiore a quella che si otterrebbe `GlobalPartitionCount` se il fattore di replica per un argomento fosse maggiore di. `1` |
| GlobalTopicCount | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome del cluster | Numero totale di argomenti in tutti i broker nel cluster. |
| EstimatedMaxTimeLag\$1 | Dopo che un gruppo di consumatori ha utilizzato un argomento. | Gruppo di consumatori, argomento | Tempo stimato (in secondi) per lo svuotamento di `MaxOffsetLag`. |
| LeaderCount | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero totale di leader delle partizioni per broker, escluse le repliche. |
| MaxOffsetLag\$1 | Dopo che un gruppo di consumatori ha utilizzato un argomento. | Gruppo di consumatori, argomento | Il ritardo massimo di offset su tutte le partizioni di un argomento. |
| MemoryBuffered | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La dimensione in byte di memoria nel buffer per il broker. |
| MemoryCached | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La dimensione in byte di memoria nella cache per il broker. |
| MemoryFree | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La dimensione in byte di memoria libera e disponibile per il broker. |
| MemoryUsed | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | La dimensione in byte di memoria utilizzata per il broker. |
| MessagesInPerSec | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di messaggi in entrata al secondo per il broker. |
| NetworkRxDropped | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di pacchetti ricezione eliminati. |
| NetworkRxErrors | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di errori ricezione di rete per il broker. |
| NetworkRxPackets | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di pacchetti ricevuti dal broker. |
| NetworkTxDropped | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di pacchetti trasmissione eliminati. |
| NetworkTxErrors | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di errori trasmissione di rete per il broker. |
| NetworkTxPackets | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero di pacchetti trasmessi dal broker. |
| PartitionCount | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero totale di partizioni di argomento per broker, incluse le repliche. |
| ProduceTotalTimeMsMean | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il tempo di produzione medio in millisecondi. |
| RequestBytesMean | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Il numero medio di byte della richiesta per il broker. |
| RequestTime | Dopo l'applicazione del throttling della richiesta. | Nome cluster, ID broker | Il tempo medio, in millisecondi, impiegato nella rete di broker e I/O nei thread per elaborare le richieste. |
| RollingEstimatedTimeLagMax\$1 | Dopo che un gruppo di consumatori ha utilizzato un argomento. | Gruppo di consumatori, argomento | Stima progressiva del tempo massimo (in secondi) per ridurre il ritardo di offset della partizione su tutte le partizioni di un argomento. |
| StorageUsed | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome del cluster | Lo storage totale utilizzato in tutte le partizioni del cluster, escluse le repliche. |
| SumOffsetLag\$1 | Dopo che un gruppo di consumatori ha utilizzato un argomento. | Gruppo di consumatori, argomento | Il ritardo di offset aggregato per tutte le partizioni di un argomento. |
| UserPartitionExists | Dopo che il cluster raggiunge lo stato ACTIVE. | Nome cluster, ID broker | Metrica booleana che indica la presenza di una partizione di proprietà dell'utente su un broker. Il valore 1 indica la presenza di partizioni sul broker. |
\$1 Le metriche relative al ritardo dei consumatori richiedono solo nomi di gruppi di consumatori in formato ASCII e hanno requisiti di emissione specifici. Per ulteriori informazioni, consulta [Monitora i ritardi dei consumatori](consumer-lag.md).
## `PER_BROKER`Monitoraggio del livello per i broker Express
Quando imposti il livello di monitoraggio su `PER_BROKER`, ottieni i parametri descritti nella tabella seguente oltre a tutti i parametri del livello `DEFAULT`. Paghi in base alle metriche riportate nella tabella seguente, mentre le metriche di `DEFAULT` livello continuano a essere gratuite. I parametri contenuti in questa tabella hanno le seguenti dimensioni: Nome cluster, ID broker.
| Nome | Quando visibile | Description |
| --- | --- | --- |
| ConnectionCloseRate | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero di connessioni chiuse al secondo per ascoltatore. Questo numero viene aggregato per ascoltatore e filtrato per gli ascoltatori client. |
| ConnectionCreationRate | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero di nuove connessioni stabilite al secondo per ascoltatore. Questo numero viene aggregato per ascoltatore e filtrato per gli ascoltatori client. |
| FetchConsumerLocalTimeMsMean | Dopo che c'è un produttore/consumatore. | Tempo medio in millisecondi di elaborazione della richiesta del consumatore presso il leader. |
| FetchConsumerRequestQueueTimeMsMean | Dopo che c'è un produttore/consumatore. | Tempo medio in millisecondi di attesa della richiesta del consumatore nella coda delle richieste. |
| FetchConsumerResponseQueueTimeMsMean | Dopo che c'è un produttore/consumatore. | Tempo medio in millisecondi di attesa della richiesta del consumatore nella coda delle risposte. |
| FetchConsumerResponseSendTimeMsMean | Dopo che c'è un produttore/consumatore. | Tempo medio in millisecondi impiegato dal consumatore per inviare una risposta. |
| FetchConsumerTotalTimeMsMean | Dopo che c'è un produttore/consumatore. | Il tempo totale medio in millisecondi impiegato dai consumatori per recuperare i dati dal broker. |
| FetchFollowerLocalTimeMsMean | Dopo che c'è un produttore/consumatore. | Tempo medio in millisecondi impiegato a livello di leader per elaborare la richiesta follower. |
| FetchFollowerRequestQueueTimeMsMean | Dopo che c'è un produttore/consumatore. | Tempo medio in millisecondi di attesa della richiesta follower nella coda delle richieste. |
| FetchFollowerResponseQueueTimeMsMean | Dopo che c'è un produttore/consumatore. | Tempo medio in millisecondi di attesa della richiesta follower nella coda delle risposte. |
| FetchFollowerResponseSendTimeMsMean | Dopo che c'è un produttore/consumatore. | Tempo medio in millisecondi impiegato dal follower per inviare una risposta. |
| FetchFollowerTotalTimeMsMean | Dopo che c'è un produttore/consumatore. | Il tempo totale medio in millisecondi impiegato dai follower per recuperare i dati dal broker. |
| FetchThrottleByteRate | Dopo l'applicazione del throttling della larghezza di banda. | Il numero di byte sottoposti a throttling al secondo. |
| FetchThrottleQueueSize | Dopo l'applicazione del throttling della larghezza di banda. | Il numero di messaggi nella coda di throttling. |
| FetchThrottleTime | Dopo l'applicazione del throttling della larghezza di banda. | Il tempo medio del throttling di recupero in millisecondi. |
| IAMNumberOfConnectionRequests | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero di richieste di autenticazione IAM al secondo. |
| IAMTooManyConnections | Dopo che il cluster raggiunge lo stato ACTIVE. | Il numero di connessioni tentate è superiore a 100. `0`significa che il numero di connessioni rientra nel limite. Se`>0`, il limite di accelerazione viene superato ed è necessario ridurre il numero di connessioni. |
| NetworkProcessorAvgIdlePercent | Dopo che il cluster raggiunge lo stato ACTIVE. | La percentuale media del tempo di inattività dei processori di rete. |
| ProduceLocalTimeMsMean | Dopo che il cluster raggiunge lo stato ACTIVE. | Tempo medio in millisecondi impiegato a livello di leader per elaborare la richiesta. |
| ProduceRequestQueueTimeMsMean | Dopo che il cluster raggiunge lo stato ACTIVE. | Il tempo medio in millisecondi che i messaggi di richiesta rimangono nella coda. |
| ProduceResponseQueueTimeMsMean | Dopo che il cluster raggiunge lo stato ACTIVE. | Il tempo medio in millisecondi che messaggi di risposta rimangono nella coda. |
| ProduceResponseSendTimeMsMean | Dopo che il cluster raggiunge lo stato ACTIVE. | Il tempo medio in millisecondi impiegato per l'invio di messaggi di risposta. |
| ProduceThrottleByteRate | Dopo l'applicazione del throttling della larghezza di banda. | Il numero di byte sottoposti a throttling al secondo. |
| ProduceThrottleQueueSize | Dopo l'applicazione del throttling della larghezza di banda. | Il numero di messaggi nella coda di throttling. |
| ProduceThrottleTime | Dopo l'applicazione del throttling della larghezza di banda. | Il tempo di throttling di produzione medio in millisecondi. |
| ProduceTotalTimeMsMean | Dopo che il cluster raggiunge lo stato ACTIVE. | Il tempo di produzione medio in millisecondi. |
| ReplicationBytesInPerSec | Dopo aver creato un argomento. | Il numero di byte al secondo ricevuti da altri broker. |
| ReplicationBytesOutPerSec | Dopo aver creato un argomento. | Il numero di byte al secondo inviati ad altri broker. |
| RequestExemptFromThrottleTime | Dopo l'applicazione del throttling della richiesta. | Il tempo medio, in millisecondi, impiegato nella rete di broker e nei I/O thread per elaborare le richieste esenti dal throttling. |
| RequestHandlerAvgIdlePercent | Dopo che il cluster raggiunge lo stato ACTIVE. | La percentuale media del tempo di inattività dei thread del gestore di richieste. |
| RequestThrottleQueueSize | Dopo l'applicazione del throttling della richiesta. | Il numero di messaggi nella coda di throttling. |
| RequestThrottleTime | Dopo l'applicazione del throttling della richiesta. | Il tempo di throttling della richiesta medio in millisecondi. |
| TcpConnections | Dopo che il cluster raggiunge lo stato ACTIVE. | Mostra il numero di segmenti TCP in entrata e in uscita con il flag SYN impostato. |
| TrafficBytes | Dopo che il cluster raggiunge lo stato ACTIVE. | Mostra il traffico di rete in byte complessivi tra client (produttori e consumatori) e broker. Il traffico tra i broker non viene segnalato. |
## `PER_TOPIC_PER_PARTITION`monitoraggio del livello per i broker Express
Quando si imposta il livello di monitoraggio su`PER_TOPIC_PER_PARTITION`, si ottengono le metriche descritte nella tabella seguente, oltre a tutte le metriche dei livelli `PER_TOPIC_PER_BROKER``PER_BROKER`, e. `DEFAULT` Solo le metriche `DEFAULT` di livello sono gratuite. I parametri in questa tabella hanno le seguenti dimensioni: gruppo di consumatori, argomento, partizione.
| Nome | Quando visibile | Description |
| --- | --- | --- |
| EstimatedTimeLag\$1 | Dopo che un gruppo di consumatori ha utilizzato un argomento. | Tempo stimato (in secondi) per eliminare il ritardo di offset della partizione. |
| OffsetLag\$1 | Dopo che un gruppo di consumatori ha utilizzato un argomento. | Ritardo del consumatore a livello di partizione nel numero di offset. |
| RollingEstimatedTimeLag\$1 | Dopo che un gruppo di consumatori ha utilizzato un argomento. | Stima del tempo di rotazione (in secondi) per ridurre il ritardo di offset della partizione. |
\$1 Le metriche relative al ritardo dei consumatori richiedono solo nomi di gruppi di consumatori in formato ASCII e hanno requisiti di emissione specifici. Per ulteriori informazioni, consulta [Monitora i ritardi dei consumatori](consumer-lag.md).
## `PER_TOPIC_PER_BROKER`monitoraggio del livello per i broker Express
Quando si imposta il livello di monitoraggio su`PER_TOPIC_PER_BROKER`, si ottengono le metriche descritte nella tabella seguente, oltre a tutte le metriche dei `PER_BROKER` livelli and. `DEFAULT` Solo le metriche `DEFAULT` di livello sono gratuite. I parametri contenuti in questa tabella hanno le seguenti dimensioni: Nome cluster, ID broker, Argomento.
**Importante**
Le metriche nella tabella seguente vengono visualizzate solo dopo che i relativi valori diventano diversi da zero per la prima volta. Ad esempio, per visualizzare BytesInPerSec, uno o più produttori devono prima inviare dati al cluster.
| Nome | Quando visibile | Description |
| --- | --- | --- |
| MessagesInPerSec | Dopo aver creato un argomento. | Il numero di messaggi ricevuti al secondo. |
# Monitora un cluster MSK Provisioned con Prometheus
È possibile monitorare il cluster MSK Provisioned con Prometheus, un sistema di monitoraggio open source per dati metrici di serie temporali. Puoi pubblicare questi dati su Servizio gestito da Amazon per Prometheus utilizzando la funzione di scrittura remota di Prometheus. [https://docs.lenses.io/latest/deployment/configuration/agent/automation/kafka/aws-msk](https://docs.lenses.io/latest/deployment/configuration/agent/automation/kafka/aws-msk) Il monitoraggio aperto è disponibile gratuitamente, ma per il trasferimento dei dati tra le zone di disponibilità vengono addebitati dei costi.
Per informazioni su Prometheus, consulta la [documentazione di Prometheus](https://prometheus.io/docs).
Per informazioni sull'uso di Prometheus, consulta [Migliora le informazioni operative per Amazon MSK usando Amazon Managed Service for Prometheus e Amazon Managed Grafana](https://aws.amazon.com/blogs//big-data/enhance-operational-insights-for-amazon-msk-using-amazon-managed-service-for-prometheus-and-amazon-managed-grafana/).
**Nota**
KRaft la modalità metadati e i broker MSK Express non possono avere entrambi abilitati il monitoraggio aperto e l'accesso pubblico.
# Abilita il monitoraggio aperto sui nuovi cluster MSK Provisioned
Questa procedura descrive come abilitare il monitoraggio aperto su un nuovo cluster MSK utilizzando AWS CLI l' Console di gestione AWS API Amazon MSK.
**Usando il Console di gestione AWS**
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Nella sezione **Monitoring (Monitoraggio)**, selezionare la casella di controllo accanto a **Enable open monitoring with Prometheus (Abilita monitoraggio aperto con Prometheus)**.
1. Fornire le informazioni richieste in tutte le sezioni della pagina e rivedere tutte le opzioni disponibili.
1. Scegli **Crea cluster**.
**Usando il AWS CLI**
+ Richiamare il comando [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/kafka/create-cluster.html) e specificarne l'opzione `open-monitoring`. Abilitare `JmxExporter`, `NodeExporter` o entrambi. Se si specifica `open-monitoring`, non è possibile disabilitare i due esportatori contemporaneamente.
**Utilizzo dell’API**
+ Richiama l'[CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)operazione e specifica`OpenMonitoring`. Abilitare `jmxExporter`, `nodeExporter` o entrambi. Se si specifica `OpenMonitoring`, non è possibile disabilitare i due esportatori contemporaneamente.
# Abilita il monitoraggio aperto sul cluster MSK Provisioned esistente
Per abilitare il monitoraggio aperto, assicuratevi che il cluster MSK Provisioned sia nello stato. `ACTIVE`
**Usando il Console di gestione AWS**
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Scegliere il nome del cluster da aggiornare. In questo modo si accede alla pagina dei dettagli del cluster.
1. Nella scheda **Proprietà**, scorri verso il basso per trovare la sezione **Monitoraggio**.
1. Scegli **Modifica**.
1. Selezionare la casella di controllo accanto a **Enable open monitoring with Prometheus (Abilita monitoraggio aperto con Prometheus)**.
1. Scegli **Save changes** (Salva modifiche).
**Usando il AWS CLI**
+ Richiama il comando [update-monitoring](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-monitoring.html) e specifica l'opzione `open-monitoring`. Abilitare `JmxExporter`, `NodeExporter` o entrambi. Se si specifica `open-monitoring`, non è possibile disabilitare i due esportatori contemporaneamente.
**Utilizzo dell’API**
+ Richiama l'[UpdateMonitoring](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-monitoring.html#UpdateMonitoring)operazione e specifica`OpenMonitoring`. Abilitare `jmxExporter`, `nodeExporter` o entrambi. Se si specifica `OpenMonitoring`, non è possibile disabilitare i due esportatori contemporaneamente.
# Configura un host Prometheus su un'istanza Amazon EC2
Questa procedura descrive come configurare un host Prometheus utilizzando un file prometheus.yml.
1. Scaricare il server Prometheus da [https://prometheus.io/download/#prometheus](https://prometheus.io/download/#prometheus) nell'istanza Amazon EC2.
1. Estrarre il file scaricato in una directory e passare a tale directory.
1. Creare un file denominato `prometheus.yml` con i seguenti contenuti:
```
# file: prometheus.yml
# my global config
global:
scrape_interval: 60s
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
# The job name is added as a label `job=` to any timeseries scraped from this config.
- job_name: 'prometheus'
static_configs:
# 9090 is the prometheus server port
- targets: ['localhost:9090']
- job_name: 'broker'
file_sd_configs:
- files:
- 'targets.json'
```
1. Usa l'[ListNodes](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-nodes.html#ListNodes)operazione per ottenere un elenco dei broker del tuo cluster.
1. Creare un file denominato `targets.json` con il seguente JSON. Sostituisci *broker\$1dns\$11**broker\$1dns\$12*, e il resto dei nomi DNS dei broker con i nomi DNS che hai ottenuto per i tuoi broker nel passaggio precedente. Includi tutti i broker ottenuti nel passaggio precedente. Amazon MSK utilizza la porta 11001 per JMX Exporter e la porta 11002 per Node Exporter.
------
#### [ ZooKeeper mode targets.json ]
```
[
{
"labels": {
"job": "jmx"
},
"targets": [
"broker_dns_1:11001",
"broker_dns_2:11001",
.
.
.
"broker_dns_N:11001"
]
},
{
"labels": {
"job": "node"
},
"targets": [
"broker_dns_1:11002",
"broker_dns_2:11002",
.
.
.
"broker_dns_N:11002"
]
}
]
```
------
#### [ KRaft mode targets.json ]
```
[
{
"labels": {
"job": "jmx"
},
"targets": [
"broker_dns_1:11001",
"broker_dns_2:11001",
.
.
.
"broker_dns_N:11001",
"controller_dns_1:11001",
"controller_dns_2:11001",
"controller_dns_3:11001"
]
},
{
"labels": {
"job": "node"
},
"targets": [
"broker_dns_1:11002",
"broker_dns_2:11002",
.
.
.
"broker_dns_N:11002"
]
}
]
```
------
**Nota**
Per estrarre le metriche JMX dai KRaft controller, aggiungi i nomi DNS dei controller come destinazioni nel file JSON. Ad esempio: sostituendo `controller_dns_1` con il nome `controller_dns_1:11001` DNS effettivo del controller.
1. Per avviare il server Prometheus sull'istanza Amazon EC2, esegui il seguente comando nella directory in cui sono stati estratti i file Prometheus e salvati `prometheus.yml` e `targets.json`.
```
./prometheus
```
1. Individua l'indirizzo IP pubblico IPv4 dell'istanza Amazon EC2 in cui è stato eseguito Prometheus nel passaggio precedente. Questo indirizzo IP pubblico è necessario nella fase seguente.
1. Per accedere all'interfaccia utente web di Prometheus, apri un browser in grado di accedere alla tua istanza Amazon EC2 e vai `Prometheus-Instance-Public-IP:9090` a, *Prometheus-Instance-Public-IP* dov'è l'indirizzo IP pubblico che hai ottenuto nel passaggio precedente.
# Usa le metriche di Prometheus
Tutti i parametri inviati da Apache Kafka a JMX sono accessibili tramite il monitoraggio aperto con Prometheus. Per informazioni sui parametri Apache Kafka, consulta la sezione relativa al [monitoraggio](https://kafka.apache.org/documentation/#monitoring) nella documentazione di Apache Kafka. Oltre alle metriche di Apache Kafka, le metriche del consumer-lag sono disponibili anche sulla porta 11001 con il nome JMX. MBean `kafka.consumer.group:type=ConsumerLagMetrics` Puoi anche utilizzare Prometheus Node Exporter per ottenere i parametri della CPU e del disco per i tuoi broker sulla porta 11002.
# Archivia i parametri di Prometheus in Amazon Managed Service for Prometheus
Servizio gestito da Amazon per Prometheus è un servizio di monitoraggio e avviso compatibile con Prometheus che puoi utilizzare per monitorare i cluster Amazon MSK. È un servizio completamente gestito che dimensiona automaticamente l'importazione, l'archiviazione, le query e gli avvisi dei parametri. Si integra inoltre con i servizi AWS di sicurezza per offrirti un accesso rapido e sicuro ai tuoi dati. È possibile utilizzare il linguaggio di query open source ProMQL per fare una query e creare avvisi relativi ai parametri.
Per ulteriori informazioni, consultare [Guida introduttiva ad Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-getting-started.html).
# Monitora i ritardi dei consumatori
Il monitoraggio del ritardo dei consumatori consente di identificare i consumatori lenti o bloccati che non tengono il passo con i dati più recenti disponibili su un argomento. Se necessario, puoi quindi intraprendere operazioni correttive, come il dimensionamento o il riavvio di tali consumatori. Per monitorare il ritardo dei consumatori, puoi utilizzare Amazon CloudWatch o open monitoring with Prometheus.
I parametri relativi al ritardo dei consumatori quantificano la differenza tra i dati più recenti scritti sui tuoi argomenti e i dati letti dalle tue applicazioni. Amazon MSK fornisce le seguenti metriche relative al ritardo dei consumatori, che puoi ottenere tramite Amazon CloudWatch o tramite il monitoraggio aperto con Prometheus:,,, e. `EstimatedMaxTimeLag` `EstimatedTimeLag` `MaxOffsetLag` `OffsetLag` `SumOffsetLag` Per ulteriori informazioni su questi parametri, consulta [Metriche di Amazon MSK per il monitoraggio dei broker Standard con CloudWatch](metrics-details.md).
Amazon MSK supporta i parametri di ritardo dei consumatori per i cluster con Apache Kafka 2.2.1 o una versione successiva. Quando lavori con Kafka e le metriche, considera i seguenti punti: CloudWatch
+ Le metriche relative al ritardo dei consumatori vengono emesse solo se un gruppo di consumatori si trova in uno stato STABILE o VUOTO. Un gruppo di consumatori è STABILE dopo il completamento con successo del riequilibrio, garantendo che le partizioni siano distribuite uniformemente tra i consumatori.
+ Le metriche relative al ritardo dei consumatori sono assenti nei seguenti scenari:
+ Se il gruppo di consumatori è instabile.
+ Il nome del gruppo di consumatori contiene i due punti (:).
+ Non hai impostato l'offset di consumo per il gruppo di consumatori.
+ I nomi dei gruppi di consumatori vengono utilizzati come dimensioni per le metriche relative al ritardo dei consumatori in. CloudWatch [Sebbene Kafka supporti i caratteri UTF-8 nei nomi dei gruppi di consumatori, CloudWatch supporta solo caratteri ASCII per i valori delle dimensioni.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_Dimension.html) Se si utilizzano caratteri non ASCII nei nomi dei gruppi di consumatori, elimina le metriche relative al ritardo dei consumatori. CloudWatch Per assicurarti che le metriche relative al ritardo dei consumatori vengano acquisite correttamente CloudWatch, devi utilizzare solo caratteri ASCII nei nomi dei gruppi di consumatori.
# Usa gli avvisi sulla capacità di archiviazione di Amazon MSK
Nei cluster con provisioning di Amazon MSK, scegli la capacità di archiviazione principale del cluster. L'esaurimento della capacità di archiviazione di un broker nel cluster con provisioning può influire sulla sua capacità di produrre e consumare dati, causando costosi tempi di inattività. Amazon MSK offre CloudWatch parametri per aiutarti a monitorare la capacità di storage del tuo cluster. Inoltre, Amazon MSK invia automaticamente avvisi dinamici sulla capacità di archiviazione del cluster in modo da semplificare il rilevamento e la risoluzione dei problemi correlati. Gli avvisi sulla capacità di archiviazione includono raccomandazioni sulle misure a breve e a lungo termine necessarie per gestire la capacità di archiviazione del cluster. Dalla [console Amazon MSK](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/), puoi utilizzare i collegamenti rapidi all'interno degli avvisi per intraprendere immediatamente le operazioni consigliate.
Esistono due tipi di avvisi MSK sulla capacità di archiviazione: proattivi e correttivi.
+ Gli avvisi proattivi sulla capacità di archiviazione ("Operazione richiesta") segnalano i potenziali problemi di archiviazione del cluster. Quando un broker in un cluster MSK ha utilizzato oltre il 60% o l'80% della sua capacità di archiviazione su disco, riceverai avvisi proattivi per il broker interessato.
+ Gli avvisi correttivi relativi alla capacità di archiviazione ("Operazione critica richiesta") prevedono l'adozione di misure correttive per risolvere un problema critico del cluster quando uno dei broker del cluster MSK ha esaurito la capacità di archiviazione su disco.
Amazon MSK invia automaticamente questi avvisi alla console [Amazon MSK,AWS](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/) [Health Dashboard EventBridge,](https://aws.amazon.com/premiumsupport/technology/aws-health/) [Amazon](https://aws.amazon.com/pm/eventbridge/) e ai contatti e-mail del tuo account. AWS Puoi anche [configurare Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-api-destination-partners.html) per inviare questi avvisi a Slack o a strumenti come New Relic e Datadog.
Gli avvisi sulla capacità di archiviazione sono abilitati per impostazione predefinita per tutti i cluster MSK con provisioning e non possono essere disattivati. Questa funzionalità è supportata in tutte le regioni in cui è disponibile MSK.
## Monitora gli avvisi sulla capacità di archiviazione
Puoi verificare la presenza di avvisi sulla capacità di archiviazione in diversi modi:
+ Accedi alla [console Amazon MSK](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/). Gli avvisi sulla capacità di archiviazione vengono visualizzati nel riquadro degli avvisi del cluster per 90 giorni. Gli avvisi contengono raccomandazioni e operazioni da eseguire con un solo clic per risolvere i problemi di capacità di archiviazione su disco.
+ Usa [ListClusters](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#ListClusters), [ListClustersV2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#ListClustersV2) o [DescribeClusterV2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters-clusterarn.html#DescribeClusterV2) APIs per visualizzare `CustomerActionStatus` tutti gli avvisi relativi a un cluster. [DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)
+ Vai ad [AWS Health Dashboard](https://aws.amazon.com/premiumsupport/technology/aws-health/) per visualizzare gli avvisi di MSK e di altri servizi AWS .
+ Configura [AWS Health API](https://docs.aws.amazon.com/health/latest/ug/health-api.html) e [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-api-destination-partners.html) per indirizzare le notifiche di avviso a piattaforme di terze parti come Datadog e NewRelic Slack.
# Aggiornamento delle impostazioni di sicurezza di un cluster Amazon MSK
Utilizza l'operazione [UpdateSecurity](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-security.html#UpdateSecurity)Amazon MSK per aggiornare le impostazioni di autenticazione e crittografia client-broker del tuo cluster MSK. Puoi anche aggiornare la Private Security Authority utilizzata per firmare i certificati per l'autenticazione TLS reciproca. Non puoi modificare l'impostazione di crittografia in-cluster (). broker-to-broker
Per poter aggiornare le impostazioni di sicurezza, il cluster deve essere nello stato `ACTIVE`.
Se attivi l'autenticazione tramite IAM, SASL o TLS, devi attivare anche la crittografia tra client e broker. La tabella di seguito riporta le possibili combinazioni.
****
| Autenticazione | Opzioni di crittografia client-broker | Crittografia broker-broker |
| --- | --- | --- |
| Unauthenticated | TLS, PLAINTEXT, TLS\$1PLAINTEXT | Può essere attiva o non attiva. |
| mTLS | TLS, TLS\$1PLAINTEXT | Deve essere attiva. |
| SASL/SCRAM | TLS | Deve essere attiva. |
| SASL/IAM | TLS | Deve essere attiva. |
Quando la crittografia client-broker è impostata su `TLS_PLAINTEXT` e l'autenticazione client è impostata su `mTLS`, Amazon MSK crea due tipi di ascoltatore a cui i client possono connettersi: un ascoltatore a cui i client possono connettersi utilizzando l'autenticazione mTLS con crittografia TLS e un altro a cui i client possono connettersi senza autenticazione o crittografia (non crittografato).
Per ulteriori informazioni sulle impostazioni di sicurezza, consulta la sezione [Sicurezza in Amazon MSK](security.md).
# Aggiorna le impostazioni di sicurezza del cluster Amazon MSK utilizzando Console di gestione AWS
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Seleziona il cluster MSK che desideri aggiornare.
1. Nella sezione **Impostazioni di sicurezza**, scegli **Modifica**.
1. Scegli le impostazioni di autenticazione e crittografia che desideri per il cluster, quindi seleziona **Salva modifiche**.
# Aggiornamento delle impostazioni di sicurezza del cluster Amazon MSK utilizzando AWS CLI
1. Crea un file JSON contenente le impostazioni di crittografia che desideri assegnare al cluster. Di seguito è riportato un esempio di :
**Nota**
È possibile aggiornare solo l'impostazione di crittografia client-broker. Non puoi aggiornare l'impostazione di crittografia in-cluster (broker-to-broker).
```
{"EncryptionInTransit":{"ClientBroker": "TLS"}}
```
1. Crea un file JSON contenente le impostazioni di autenticazione che desideri che il cluster utilizzi. Di seguito è riportato un esempio di :
```
{"Sasl":{"Scram":{"Enabled":true}}}
```
1. Esegui il AWS CLI comando seguente:
```
aws kafka update-security --cluster-arn ClusterArn --current-version Current-Cluster-Version --client-authentication file://Path-to-Authentication-Settings-JSON-File --encryption-info file://Path-to-Encryption-Settings-JSON-File
```
L'output di questa operazione `update-security` è simile al seguente JSON.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"ClusterOperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef"
}
```
1. Per visualizzare lo stato dell'`update-security`operazione, esegui il comando seguente, sostituendolo *ClusterOperationArn* con l'ARN ottenuto nell'output del `update-security` comando.
```
aws kafka describe-cluster-operation --cluster-operation-arn ClusterOperationArn
```
L'output di questo comando `describe-cluster-operation` è simile all'esempio JSON seguente.
```
{
"ClusterOperationInfo": {
"ClientRequestId": "c0b7af47-8591-45b5-9c0c-909a1a2c99ea",
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"CreationTime": "2021-09-17T02:35:47.753000+00:00",
"OperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef",
"OperationState": "PENDING",
"OperationType": "UPDATE_SECURITY",
"SourceClusterInfo": {},
"TargetClusterInfo": {}
}
}
```
Se il valore di `OperationState` è `PENDING` oppure `UPDATE_IN_PROGRESS`, attendi qualche minuto, quindi esegui nuovamente il comando `describe-cluster-operation`.
**Nota**
Le operazioni AWS CLI e le API per l'aggiornamento delle impostazioni di sicurezza di un cluster sono idempotenti. Ciò significa che se si richiama l'operazione di aggiornamento della sicurezza e si specifica un'impostazione di autenticazione o crittografia uguale a quella attualmente utilizzata dal cluster, tale impostazione non verrà modificata.
# Aggiornamento delle impostazioni di sicurezza di un cluster tramite l'API
Per aggiornare le impostazioni di sicurezza per un cluster Amazon MSK utilizzando l'API, consulta [UpdateSecurity](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-security.html#UpdateSecurity).
**Nota**
Le operazioni AWS CLI e le API per l'aggiornamento delle impostazioni di sicurezza di un cluster MSK sono idempotenti. Ciò significa che se si richiama l'operazione di aggiornamento della sicurezza e si specifica un'impostazione di autenticazione o crittografia uguale a quella attualmente utilizzata dal cluster, tale impostazione non verrà modificata.
# Espandi il numero di broker in un cluster Amazon MSK
Utilizza questa operazione di Amazon MSK quando desideri incrementare il numero di broker nel cluster MSK. Per espandere un cluster, assicurati che il suo stato sia `ACTIVE`.
**Importante**
Se desideri espandere un cluster MSK, assicurati di utilizzare questa operazione di Amazon MSK. Non provare ad aggiungere broker a un cluster senza utilizzare questa operazione.
Per informazioni su come ribilanciare le partizioni dopo aver aggiunto broker a un cluster, consulta [Riassegnazione delle partizioni](bestpractices.md#bestpractices-balance-cluster).
## Espandi un cluster Amazon MSK utilizzando Console di gestione AWS
Questo processo descrive come aumentare il numero di broker in un cluster Amazon MSK utilizzando il. Console di gestione AWS
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Scegli il cluster MSK di cui desideri aumentare numero di broker.
1. ****Dal menu a discesa Azioni, scegli Modifica numero di broker.****
1. Inserisci il numero di broker di cui deve disporre il cluster per zona di disponibilità, quindi scegli **Salva modifiche**.
## Espandi un cluster Amazon MSK utilizzando AWS CLI
Questo processo descrive come aumentare il numero di broker in un cluster Amazon MSK utilizzando il. AWS CLI
1. Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) che hai ottenuto quando hai creato il cluster. Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per ulteriori informazioni, consulta [Elenca i cluster Amazon MSK](msk-list-clusters.md).
Sostituiscilo *Current-Cluster-Version* con la versione corrente del cluster.
**Importante**
Le versioni del cluster non sono interi semplici. Per trovare la versione corrente del cluster, usa l'[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)operazione o il comando [AWS CLI describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html). Una versione di esempio è `KTVPDKIKX0DER`.
Il *Target-Number-of-Brokers* parametro rappresenta il numero totale di nodi broker che si desidera che il cluster disponga quando l'operazione viene completata correttamente. Il valore specificato *Target-Number-of-Brokers* deve essere un numero intero maggiore del numero corrente di broker nel cluster. Deve anche essere un multiplo del numero di zone di disponibilità.
```
aws kafka update-broker-count --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-number-of-broker-nodes Target-Number-of-Brokers
```
L'output di questa operazione `update-broker-count` è simile al seguente JSON.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"ClusterOperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef"
}
```
1. Per ottenere il risultato dell'`update-broker-count`operazione, esegui il comando seguente, sostituendolo *ClusterOperationArn* con l'ARN ottenuto nell'output del `update-broker-count` comando.
```
aws kafka describe-cluster-operation --cluster-operation-arn ClusterOperationArn
```
L'output di questo comando `describe-cluster-operation` è simile all'esempio JSON seguente.
```
{
"ClusterOperationInfo": {
"ClientRequestId": "c0b7af47-8591-45b5-9c0c-909a1a2c99ea",
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"CreationTime": "2019-09-25T23:48:04.794Z",
"OperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef",
"OperationState": "UPDATE_COMPLETE",
"OperationType": "INCREASE_BROKER_COUNT",
"SourceClusterInfo": {
"NumberOfBrokerNodes": 9
},
"TargetClusterInfo": {
"NumberOfBrokerNodes": 12
}
}
}
```
In questo output, `OperationType` è `INCREASE_BROKER_COUNT`. Se il valore di `OperationState` è `UPDATE_IN_PROGRESS`, attendi qualche minuto, quindi esegui nuovamente il comando `describe-cluster-operation`.
## Espandi un cluster Amazon MSK utilizzando l'API
Per aumentare il numero di broker in un cluster utilizzando l'API, consulta. [UpdateBrokerCount](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-nodes-count.html#UpdateBrokerCount)
# Rimuovere un broker da un cluster Amazon MSK
Usa questa operazione Amazon MSK quando desideri rimuovere broker dai cluster con provisioning di Amazon Managed Streaming for Apache Kafka (MSK). Puoi ridurre la capacità di storage e di elaborazione del cluster rimuovendo set di broker, senza alcun impatto sulla disponibilità, rischio di durabilità dei dati o interruzione delle applicazioni di streaming di dati.
Puoi aggiungere altri broker al cluster per gestire l'aumento del traffico e rimuovere i broker quando il traffico diminuisce. Grazie alla funzionalità di aggiunta e rimozione dei broker, è possibile utilizzare al meglio la capacità del cluster e ottimizzare i costi dell'infrastruttura MSK. La rimozione dei broker offre il controllo a livello di broker sulla capacità del cluster esistente per soddisfare le esigenze di carico di lavoro ed evitare la migrazione verso un altro cluster.
Utilizza la AWS console, l'interfaccia a riga di comando (CLI), l'SDK o CloudFormation per ridurre il numero di broker del cluster fornito. MSK seleziona i broker che non dispongono di alcuna partizione (ad eccezione degli argomenti Canary) e impedisce alle applicazioni di produrre dati per tali broker, rimuovendo al contempo in modo sicuro tali broker dal cluster.
È necessario rimuovere un broker per zona di disponibilità, se si desidera ridurre lo storage e l'elaborazione di un cluster. Ad esempio, è possibile rimuovere due broker da un cluster con due zone di disponibilità o tre broker da un cluster con tre zone di disponibilità in un'unica operazione di rimozione dei broker.
Per informazioni su come ribilanciare le partizioni dopo aver rimosso i broker da un cluster, vedere. [Riassegnazione delle partizioni](bestpractices.md#bestpractices-balance-cluster)
È possibile rimuovere i broker da tutti i cluster con provisioning MSK basati su M5 e M7g, indipendentemente dalla dimensione dell'istanza.
La rimozione dei broker è supportata nelle versioni di Kafka 2.8.1 e successive, inclusi i cluster modali. KRaft
**Topics**
+ [Rimuovi le partizioni del broker](#msk-remove-broker-partitions)
+ [Rimuovi un broker con console](#msk-remove-broker-console)
+ [Rimuovi un broker con CLI](#msk-remove-broker-cli)
+ [Rimuovi un broker con API](#msk-remove-broker-api)
## Preparati a rimuovere i broker rimuovendo tutte le partizioni
Prima di iniziare il processo di rimozione del broker, sposta innanzitutto tutte le partizioni, tranne quelle relative agli argomenti `__amazon_msk_canary` e ai broker che `__amazon_msk_canary_state` intendi rimuovere. Si tratta di argomenti interni creati da Amazon MSK per i parametri diagnostici e di salute dei cluster.
Puoi utilizzare Kafka admin APIs o Cruise Control per spostare le partizioni su altri broker che intendi mantenere nel cluster. [Vedi Riassegnare le partizioni.](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html#bestpractices-balance-cluster)
### Procedura di esempio per rimuovere le partizioni
Questa sezione è un esempio di come rimuovere le partizioni dal broker che intendi rimuovere. Supponiamo di avere un cluster con 6 broker, 2 broker in ogni AZ e che abbia quattro argomenti:
+ `__amazon_msk_canary`
+ `__consumer_offsets`
+ `__amazon_msk_connect_offsets_my-mskc-connector_12345678-09e7-c657f7e4ff32-2`
+ `msk-brk-rmv`
1. Crea una macchina client come descritto in [Creare una macchina client](https://docs.aws.amazon.com/msk/latest/developerguide/create-client-machine.html).
1. Dopo aver configurato il computer client, esegui il comando seguente per elencare tutti gli argomenti disponibili nel cluster.
```
./bin/kafka-topics.sh --bootstrap-server “CLUSTER_BOOTSTRAP_STRING” --list
```
In questo esempio, vediamo quattro nomi di argomenti,`__amazon_msk_canary`, `__consumer_offsets``__amazon_msk_connect_offsets_my-mskc-connector_12345678-09e7-c657f7e4ff32-2`, e`msk-brk-rmv`.
1. Crea un file json chiamato `topics.json` sul computer client e aggiungi tutti i nomi degli argomenti utente come nel seguente esempio di codice. Non è necessario includere il nome dell'`__amazon_msk_canary`argomento in quanto si tratta di un argomento gestito dal servizio che verrà spostato automaticamente quando necessario.
```
{
"topics": [
{"topic": "msk-brk-rmv"},
{"topic": "__consumer_offsets"},
{"topic": "__amazon_msk_connect_offsets_my-mskc-connector_12345678-09e7-c657f7e4ff32-2"}
],
"version":1
}
```
1. Esegui il comando seguente per generare una proposta per spostare le partizioni su soli 3 broker su 6 broker del cluster.
```
./bin/kafka-reassign-partitions.sh --bootstrap-server “CLUSTER_BOOTSTRAP_STRING” --topics-to-move-json-file topics.json --broker-list 1,2,3 --generate
```
1. Crea un file chiamato `reassignment-file.json` e copia il comando `proposed partition reassignment configuration` che hai ottenuto dal precedente comando.
1. Esegui il seguente comando per spostare le partizioni specificate in. `reassignment-file.json`
```
./bin/kafka-reassign-partitions.sh --bootstrap-server “CLUSTER_BOOTSTRAP_STRING” --reassignment-json-file reassignment-file.json --execute
```
L'esito si presenta in maniera analoga all'immagine riportata di seguito.
```
Successfully started partition reassignments for morpheus-test-topic-1-0,test-topic-1-0
```
1. Esegui il comando seguente per verificare che tutte le partizioni siano state spostate.
```
./bin/kafka-reassign-partitions.sh --bootstrap-server “CLUSTER_BOOTSTRAP_STRING” --reassignment-json-file reassignment-file.json --verify
```
L'output è simile al seguente. Monitora lo stato fino a quando tutte le partizioni negli argomenti richiesti non sono state riassegnate correttamente:
```
Status of partition reassignment:
Reassignment of partition msk-brk-rmv-0 is completed.
Reassignment of partition msk-brk-rmv-1 is completed.
Reassignment of partition __consumer_offsets-0 is completed.
Reassignment of partition __consumer_offsets-1 is completed.
```
1. Quando lo stato indica che la riassegnazione delle partizioni per ogni partizione è stata completata, monitora le `UserPartitionExists` metriche per 5 minuti per assicurarti che vengano visualizzate dai broker da cui hai spostato le `0` partizioni. Dopo averlo confermato, puoi procedere alla rimozione del broker dal cluster.
## Rimuovi un broker con la console di AWS gestione
**Per rimuovere i broker con la console di gestione AWS**
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Scegli il cluster MSK che contiene i broker che desideri rimuovere.
1. Nella pagina dei dettagli del cluster, scegli il pulsante **Azioni** e seleziona l'opzione **Modifica numero di broker**.
1. Inserisci il numero di broker che desideri che il cluster abbia per zona di disponibilità. La console riepiloga il numero di broker nelle zone di disponibilità che verranno rimossi. Assicurati che sia quello che vuoi.
1. Scegli **Save changes** (Salva modifiche).
Per evitare la rimozione accidentale del broker, la console ti chiede di confermare che desideri eliminare i broker.
## Rimuovi un broker con la AWS CLI
Esegui il comando seguente, sostituendolo `ClusterArn` con l'Amazon Resource Name (ARN) che hai ottenuto quando hai creato il cluster. Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per ulteriori informazioni, consulta [Listing Amazon MSK clusters](https://docs.aws.amazon.com/msk/latest/developerguide/msk-list-clusters.html). Sostituisci `Current-Cluster-Version` con la versione corrente del cluster.
**Importante**
Le versioni del cluster non sono interi semplici. Per trovare la versione corrente del cluster, usa l'[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)operazione o il comando [AWS CLI describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html). Una versione di esempio è `KTVPDKIKX0DER`.
Il *Target-Number-of-Brokers* parametro rappresenta il numero totale di nodi broker che si desidera che il cluster disponga quando l'operazione viene completata correttamente. Il valore specificato *Target-Number-of-Brokers* deve essere un numero intero inferiore al numero corrente di broker nel cluster. Deve anche essere un multiplo del numero di zone di disponibilità.
```
aws kafka update-broker-count --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-number-of-broker-nodes Target-Number-of-Brokers
```
L'output di questa operazione `update-broker-count` è simile al seguente JSON.
```
{
"ClusterOperationInfo": {
"ClientRequestId": "c0b7af47-8591-45b5-9c0c-909a1a2c99ea",
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"CreationTime": "2019-09-25T23:48:04.794Z",
"OperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef",
"OperationState": "UPDATE_COMPLETE",
"OperationType": "DECREASE_BROKER_COUNT",
"SourceClusterInfo": {
"NumberOfBrokerNodes": 12
},
"TargetClusterInfo": {
"NumberOfBrokerNodes": 9
}
}
}
```
In questo output, `OperationType` è `DECREASE_BROKER_COUNT`. Se il valore di `OperationState` è `UPDATE_IN_PROGRESS`, attendi qualche minuto, quindi esegui nuovamente il comando `describe-cluster-operation`.
## Rimuovi un broker con l'API AWS
Per rimuovere i broker in un cluster utilizzando l'API, consulta [UpdateBrokerCount](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes-count.html#clusters-clusterarn-nodes-count-url)*Amazon Managed Streaming for Apache Kafka API Reference*.
# Aggiornamento delle dimensioni del broker del cluster Amazon MSK
Puoi scalare il tuo cluster MSK su richiesta modificando le dimensioni dei broker senza riassegnare le partizioni Apache Kafka. La modifica delle dimensioni dei broker offre la flessibilità necessaria per adattare la capacità di calcolo del cluster MSK in base alle variazioni dei carichi di lavoro, senza interrompere l'I/O del cluster. Amazon MSK utilizza le stesse dimensioni di broker per tutti i broker di un determinato cluster.
Per i broker standard, puoi aggiornare le dimensioni del broker del cluster da M5 o T3 a M7g, da T3 a M5 o da M7g a M5.
**Nota**
Non è possibile migrare da un broker di dimensioni maggiori a un broker di dimensioni inferiori. Ad esempio, da M7g.large a T3.small.
Per i broker Express, puoi utilizzare solo le dimensioni dei broker M7g.
Questo argomento descrive come aggiornare le dimensioni del broker per il cluster MSK.
Tieni presente che la migrazione a un broker di dimensioni inferiori può ridurre le prestazioni e ridurre il throughput massimo raggiungibile per broker. La migrazione a un broker di dimensioni maggiori può aumentare le prestazioni ma potrebbe costare di più.
L'aggiornamento delle dimensioni di un broker avviene in modo continuativo mentre il cluster è attivo e funzionante. Ciò significa che Amazon MSK disattiva un broker alla volta per eseguire l'aggiornamento delle dimensioni del broker. Per informazioni su come rendere altamente disponibile un cluster durante un aggiornamento delle dimensioni di un broker, consulta. [Creazione di cluster a disponibilità elevata](bestpractices.md#ensure-high-availability) Per ridurre ulteriormente il potenziale impatto sulla produttività, è possibile eseguire l'aggiornamento delle dimensioni del broker durante un periodo di traffico ridotto.
Durante un aggiornamento delle dimensioni di un broker, puoi continuare a produrre e consumare dati. Tuttavia, è necessario attendere il completamento dell'aggiornamento prima di poter riavviare i broker o richiamare una delle operazioni di aggiornamento elencate nelle [operazioni di Amazon MSK](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html).
Se desideri aggiornare il cluster a un broker di dimensioni inferiori, ti consigliamo di provare prima l'aggiornamento su un cluster di test per vedere come influisce sullo scenario.
**Importante**
Non puoi aggiornare un cluster a un broker di dimensioni inferiori se il numero di partizioni per broker supera il numero massimo specificato in. [Dimensioni corrette del cluster: numero di partizioni per broker Standard](bestpractices.md#partitions-per-broker)
**Topics**
+ [Aggiorna le dimensioni del broker del cluster Amazon MSK utilizzando il Console di gestione AWS](#update-broker-type-console)
+ [Aggiorna le dimensioni del broker del cluster Amazon MSK utilizzando il AWS CLI](#update-broker-type-cli)
+ [Aggiornamento delle dimensioni del broker tramite l'API](#update-broker-type-api)
## Aggiorna le dimensioni del broker del cluster Amazon MSK utilizzando il Console di gestione AWS
Questo processo mostra come aggiornare le dimensioni del broker del cluster Amazon MSK utilizzando Console di gestione AWS
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Scegliete il cluster MSK per il quale desiderate aggiornare le dimensioni del broker.
1. Nella pagina dei dettagli del cluster, trova la sezione di **riepilogo dei broker** e scegli **Modifica le dimensioni del broker**.
1. Scegli la dimensione del broker che desideri dall'elenco.
1. Salva le modifiche.
## Aggiorna le dimensioni del broker del cluster Amazon MSK utilizzando il AWS CLI
Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) che hai ottenuto quando hai creato il cluster. Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per ulteriori informazioni, consulta [Elenca i cluster Amazon MSK](msk-list-clusters.md).
1. Sostituiscilo *Current-Cluster-Version* con la versione corrente del cluster e *TargetType* con la nuova dimensione che desideri che abbiano i broker. Per ulteriori informazioni sulle dimensioni dei broker, consulta[Tipi di broker Amazon MSK](broker-instance-types.md).
```
aws kafka update-broker-type --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-instance-type TargetType
```
Di seguito è riportato un esempio di come utilizzare questo comando:
```
aws kafka update-broker-type --cluster-arn "arn:aws:kafka:us-east-1:0123456789012:cluster/exampleName/abcd1234-0123-abcd-5678-1234abcd-1" --current-version "K1X5R6FKA87" --target-instance-type kafka.m5.large
```
L'output di questo comando è simile all'esempio JSON seguente.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:0123456789012:cluster/exampleName/abcd1234-0123-abcd-5678-1234abcd-1",
"ClusterOperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef"
}
```
1. Per ottenere il risultato dell'`update-broker-type`operazione, esegui il comando seguente, sostituendolo *ClusterOperationArn* con l'ARN ottenuto nell'output del `update-broker-type` comando.
```
aws kafka describe-cluster-operation --cluster-operation-arn ClusterOperationArn
```
L'output di questo comando `describe-cluster-operation` è simile all'esempio JSON seguente.
```
{
"ClusterOperationInfo": {
"ClientRequestId": "982168a3-939f-11e9-8a62-538df00285db",
"ClusterArn": "arn:aws:kafka:us-east-1:0123456789012:cluster/exampleName/abcd1234-0123-abcd-5678-1234abcd-1",
"CreationTime": "2021-01-09T02:24:22.198000+00:00",
"OperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef",
"OperationState": "UPDATE_COMPLETE",
"OperationType": "UPDATE_BROKER_TYPE",
"SourceClusterInfo": {
"InstanceType": "t3.small"
},
"TargetClusterInfo": {
"InstanceType": "m5.large"
}
}
}
```
Se il valore di `OperationState` è `UPDATE_IN_PROGRESS`, attendi qualche minuto, quindi esegui nuovamente il comando `describe-cluster-operation`.
## Aggiornamento delle dimensioni del broker tramite l'API
Per aggiornare le dimensioni del broker utilizzando l'API, consulta [UpdateBrokerType](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes-type.html#UpdateBrokerType).
Puoi utilizzarla `UpdateBrokerType` per aggiornare le dimensioni del broker del cluster da M5 o T3 a M7g o da M7g a M5.
# Usa LinkedIn il Cruise Control per Apache Kafka con Amazon MSK
Puoi utilizzare LinkedIn Cruise Control per ribilanciare il cluster Amazon MSK, rilevare e correggere anomalie e monitorare lo stato e l'integrità del cluster.
**Nota**
Se il [ribilanciamento intelligente](intelligent-rebalancing.md) è attivato per i cluster basati su Express appena creati, non potrai utilizzare strumenti di terze parti, come Cruise Control, per il ribilanciamento delle partizioni. Devi prima mettere in pausa il ribilanciamento intelligente per utilizzare l'API di riassegnazione delle partizioni fornita da questi strumenti di terze parti.
**Download e compilazione di Cruise Control**
1. Crea un'istanza Amazon EC2 nello stesso Amazon VPC del cluster Amazon MSK.
1. Installa Prometheus sull'istanza Amazon EC2 che hai creato nel passaggio precedente. Prendi nota dell'IP privato e della porta. Il numero di porta predefinito è 9090. Per informazioni su come configurare Prometheus per aggregare i parametri per un cluster, consulta la pagina [Monitora un cluster MSK Provisioned con Prometheus](open-monitoring.md).
1. Scarica [Cruise Control](https://github.com/linkedin/cruise-control/releases) sull'istanza Amazon EC2. In alternativa, se preferisci, puoi utilizzare un'istanza Amazon EC2 separata per Cruise Control. Per un cluster con Apache Kafka versione 2.4.\$1, usa la versione 2.4.\$1 di Cruise Control più recente. Se il tuo cluster ha una versione di Apache Kafka precedente alla 2.4.\$1, utilizza la versione 2.0.\$1 di Cruise Control più recente.
1. Decomprimi il file Cruise Control, quindi vai alla cartella decompressa.
1. Esegui il comando seguente per installare git.
```
sudo yum -y install git
```
1. Esegui il comando seguente per inizializzare il repository locale. *Your-Cruise-Control-Folder*Sostituiscila con il nome della cartella attuale (la cartella che hai ottenuto quando hai decompresso il download di Cruise Control).
```
git init && git add . && git commit -m "Init local repo." && git tag -a Your-Cruise-Control-Folder -m "Init local version."
```
1. Esegui il comando seguente per creare il codice sorgente.
```
./gradlew jar copyDependantLibs
```
**Configurazione ed esecuzione di Cruise Control**
1. Apporta le seguenti modifiche al file `config/cruisecontrol.properties`. Sostituisci la stringa bootstrap servers e bootstrap-brokers di esempio con i valori del tuo cluster. Per recuperare queste stringhe per il cluster, puoi consultare i dettagli del cluster nella console. In alternativa, puoi utilizzare le operazioni [GetBootstrapBrokers](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-bootstrap-brokers.html#GetBootstrapBrokers)e [DescribeCluster](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)API o i loro equivalenti CLI.
```
# If using TLS encryption, use 9094; use 9092 if using plaintext
bootstrap.servers=b-1.test-cluster.2skv42.c1.kafka.us-east-1.amazonaws.com:9094,b-2.test-cluster.2skv42.c1.kafka.us-east-1.amazonaws.com:9094,b-3.test-cluster.2skv42.c1.kafka.us-east-1.amazonaws.com:9094
# SSL properties, needed if cluster is using TLS encryption
security.protocol=SSL
ssl.truststore.location=/home/ec2-user/kafka.client.truststore.jks
# Use the Prometheus Metric Sampler
metric.sampler.class=com.linkedin.kafka.cruisecontrol.monitor.sampling.prometheus.PrometheusMetricSampler
# Prometheus Metric Sampler specific configuration
prometheus.server.endpoint=1.2.3.4:9090 # Replace with your Prometheus IP and port
# Change the capacity config file and specify its path; details below
capacity.config.file=config/capacityCores.json
```
[Per i broker express, consigliamo di non utilizzarlo `DiskCapacityGoal` in nessuno degli obiettivi configurati nelle configurazioni degli analizzatori.](https://github.com/linkedin/cruise-control/wiki/Configurations#analyzer-configurations)
1. Modifica il `config/capacityCores.json` file per specificare la dimensione del disco, i core della CPU e i limiti di rete corretti. in/out Per i broker Express, l'inserimento della `DISK` capacità è necessario solo per configurare Cruise Control. Poiché MSK gestisce tutto lo spazio di archiviazione per i broker Express, è necessario impostare questo valore su un numero estremamente alto, ad esempio. `Integer.MAX_VALUE (2147483647)` Per i broker Standard, è possibile utilizzare l'operazione [DescribeCluster](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)API (o [describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html) CLI) per ottenere la dimensione del disco. Per i core della CPU e i in/out limiti di rete, consulta Tipi di istanze di [Amazon EC2](https://aws.amazon.com/ec2/instance-types/).
------
#### [ Standard broker config/capacityCores.json ]
```
{
"brokerCapacities": [
{
"brokerId": "-1",
"capacity": {
"DISK": "10000",
"CPU": {
"num.cores": "2"
},
"NW_IN": "5000000",
"NW_OUT": "5000000"
},
"doc": "This is the default capacity. Capacity unit used for disk is in MB, cpu is in number of cores, network throughput is in KB."
}
]
}
```
------
#### [ Express broker config/capacityCores.json ]
```
{
"brokerCapacities":[
{
"brokerId": "-1",
"capacity": {
"DISK": "2147483647",
"CPU": {"num.cores": "16"},
"NW_IN": "1073741824",
"NW_OUT": "1073741824"
},
"doc": "This is the default capacity. Capacity unit used for disk is in MB, cpu is in number of cores, network throughput is in KB."
}
]
}
```
------
1. Facoltativamente, puoi installare l'interfaccia utente di Cruise Control. Per scaricarla, consulta la pagina [Setting Up Cruise Control Frontend](https://github.com/linkedin/cruise-control-ui/wiki/Single-Kafka-Cluster#setting-up-cruise-control-frontend).
1. Esegui il comando seguente per avviar Cruise Control. Prendi in considerazione l'utilizzo di uno strumento come `screen` o `tmux` per mantenere aperta una sessione di lunga durata.
```
/bin/kafka-cruise-control-start.sh config/cruisecontrol.properties 9091
```
1. Usa Cruise Control APIs o l'interfaccia utente per assicurarti che Cruise Control disponga dei dati di carico del cluster e che fornisca suggerimenti per il ribilanciamento. Potrebbero trascorrere alcuni minuti prima di ottenere una finestra di parametri valida.
**Importante**
Solo le versioni di Cruise Control 2.5.60 e successive sono compatibili con i broker Express, poiché i broker Express non espongono gli endpoint Zookeeper.
## Usa il modello di distribuzione automatizzata di Cruise Control per Amazon MSK
Puoi anche utilizzare questo [CloudFormation modello](https://github.com/aws-samples/cruise-control-for-msk) per implementare facilmente Cruise Control e Prometheus per ottenere informazioni più approfondite sulle prestazioni del tuo cluster Amazon MSK e ottimizzare l'utilizzo delle risorse.
**Caratteristiche principali:**
+ Provisioning automatico di un'istanza Amazon EC2 con Cruise Control e Prometheus preconfigurati.
+ Support per il cluster con provisioning di Amazon MSK.
+ Autenticazione flessibile con [PlainText e](kafka_apis_iam.md) IAM.
+ Nessuna dipendenza da Zookeeper per Cruise Control.
+ Personalizza facilmente gli obiettivi Prometheus, le impostazioni della capacità del Cruise Control e altre configurazioni fornendo i tuoi file di configurazione memorizzati in un bucket Amazon S3.
## Linee guida per il ribilanciamento delle partizioni
### Linee guida per la riassegnazione delle partizioni Kafka
La riassegnazione delle partizioni in Kafka può richiedere molte risorse, in quanto comporta il trasferimento di dati significativi tra broker, causando potenzialmente la congestione della rete e influendo sulle operazioni dei client. Le seguenti best practice consentono di gestire in modo efficace la riassegnazione delle partizioni ottimizzando i tassi di accelerazione, sfruttando i controlli di concorrenza e comprendendo i tipi di riassegnazione per ridurre al minimo le interruzioni delle operazioni del cluster.
**Nota**
Se disponi di un cluster basato su Express appena creato, utilizza il [ribilanciamento intelligente](intelligent-rebalancing.md) per la distribuzione automatica delle partizioni man mano che aumenti o riduci i cluster.
#### Gestione della concorrenza in Cruise Control
Il Cruise Control fornisce parametri di regolazione automatica per controllare la concomitanza dei movimenti di partizione e di leadership. I seguenti parametri aiutano a mantenere un carico accettabile durante le riassegnazioni:
+ Movimenti di **partizione simultanei massimi: definisci il limite massimo `num.concurrent.partition.movements.per.broker` per i movimenti** simultanei delle partizioni tra broker, evitando un utilizzo eccessivo della rete.
**Example Esempio**
```
num.concurrent.partition.movements.per.broker = 5
```
Questa impostazione limita ogni broker a spostare non più di 10 partizioni alla volta, bilanciando il carico tra i broker.
#### Usa la limitazione per controllare la larghezza di banda
+ **Parametro Throttle**: quando si esegue la riassegnazione delle partizioni con`kafka-reassign-partitions.sh`, utilizzare `--throttle parameter` per impostare una velocità di trasferimento massima (in byte al secondo) per lo spostamento dei dati tra i broker.
**Example Esempio**
```
--throttle 5000000
```
Questo imposta una larghezza di banda massima di 5 MB/s.
+ **Balance Throttle Settings**: La scelta di una frequenza di accelerazione appropriata è fondamentale:
Se impostato su un valore troppo basso, la riassegnazione potrebbe richiedere molto più tempo.
Se impostato su un valore troppo alto, i client potrebbero riscontrare un aumento della latenza.
+ Inizia con una frequenza di accelerazione conservativa e regola in base al monitoraggio delle prestazioni del cluster. Testa l'acceleratore che hai scelto prima di passare a un ambiente di produzione per trovare l'equilibrio ottimale.
#### Esegui test e convalida in un ambiente di staging
Prima di implementare le riassegnazioni in produzione, esegui test di carico in un ambiente di staging con configurazioni simili. Ciò consente di ottimizzare i parametri e ridurre al minimo gli impatti imprevisti nella produzione live.
# Aggiornamento della configurazione di un cluster Amazon MSK
Per aggiornare la configurazione di un cluster, assicurati che lo stato del cluster sia `ACTIVE`. Inoltre, devi assicurarti che il numero di partizioni per broker sul cluster MSK sia inferiore ai limiti descritti nella sezione [Dimensioni corrette del cluster: numero di partizioni per broker Standard](bestpractices.md#partitions-per-broker). Non è possibile aggiornare la configurazione di un cluster che supera questi limiti.
Per informazioni sulla configurazione MSK, incluso come creare una configurazione personalizzata, quali proprietà è possibile aggiornare e cosa accade quando si aggiorna la configurazione di un cluster esistente, consulta [Configurazione Amazon MSK Provisioned](msk-configuration.md).
**Topics**
+ [Disponibilità del broker durante gli aggiornamenti della configurazione](#update-config-cluster-availability)
+ [Aggiornamento della configurazione di un cluster utilizzando il AWS CLI](#update-config-cli)
+ [Aggiorna la configurazione di un cluster Amazon MSK utilizzando l'API](#update-config-api)
## Disponibilità del broker durante gli aggiornamenti della configurazione
Amazon MSK mantiene un'elevata disponibilità durante la maggior parte degli aggiornamenti della configurazione del cluster. Amazon MSK esegue un aggiornamento progressivo in cui aggiorna un broker alla volta. Durante questo processo, il cluster rimane disponibile, anche se i singoli broker verranno riavviati man mano che le relative configurazioni vengono aggiornate. Tuttavia, alcune modifiche alla configurazione potrebbero richiedere l'aggiornamento simultaneo di tutti i broker, il che può causare una breve interruzione a livello di cluster. Per ulteriori informazioni sull'impatto della disponibilità dei broker durante gli aggiornamenti, consulta. [Configurazione Amazon MSK Provisioned](msk-configuration.md)
Prima di aggiornare i cluster di produzione, ti consigliamo di testare le modifiche alla configurazione in un ambiente non di produzione e di pianificare gli aggiornamenti durante le finestre di manutenzione.
In caso di problemi durante l'aggiornamento del cluster MSK, vedi [Come posso risolvere i problemi quando aggiorno il mio](https://repost.aws/knowledge-center/msk-upgrade-cluster-issues) cluster Amazon MSK?
## Aggiornamento della configurazione di un cluster utilizzando il AWS CLI
1. Copiare il JSON seguente e salvarlo in un file. Assegnare un nome al file `configuration-info.json`. Sostituisci *ConfigurationArn* con l'Amazon Resource Name (ARN) della configurazione che desideri utilizzare per aggiornare il cluster. La stringa ARN deve essere racchiusa tra virgolette nel seguente JSON.
Sostituisci *Configuration-Revision* con la revisione della configurazione che desideri utilizzare. Le revisioni di configurazione sono interi (numeri interi) che iniziano da `1`. Questo intero non deve essere racchiuso tra virgolette nel seguente JSON.
```
{
"Arn": ConfigurationArn,
"Revision": Configuration-Revision
}
```
1. Esegui il comando seguente, sostituendolo *ClusterArn* con l'ARN ottenuto quando hai creato il cluster. Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per ulteriori informazioni, consulta [Elenca i cluster Amazon MSK](msk-list-clusters.md).
Sostituiscilo *Path-to-Config-Info-File* con il percorso del file di informazioni di configurazione. Se hai dato un nome al file creato nel passaggio precedente `configuration-info.json` e lo hai salvato nella directory corrente, allora *Path-to-Config-Info-File* è`configuration-info.json`.
Sostituiscilo *Current-Cluster-Version* con la versione corrente del cluster.
**Importante**
Le versioni del cluster non sono interi semplici. Per trovare la versione corrente del cluster, usa l'[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)operazione o il comando [AWS CLI describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html). Una versione di esempio è `KTVPDKIKX0DER`.
```
aws kafka update-cluster-configuration --cluster-arn ClusterArn --configuration-info file://Path-to-Config-Info-File --current-version Current-Cluster-Version
```
Di seguito è riportato un esempio di come utilizzare questo comando:
```
aws kafka update-cluster-configuration --cluster-arn "arn:aws:kafka:us-east-1:0123456789012:cluster/exampleName/abcd1234-0123-abcd-5678-1234abcd-1" --configuration-info file://c:\users\tester\msk\configuration-info.json --current-version "K1X5R6FKA87"
```
L'output di questo comando `update-cluster-configuration` è simile all'esempio JSON seguente.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"ClusterOperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef"
}
```
1. Per ottenere il risultato dell'`update-cluster-configuration`operazione, esegui il comando seguente, sostituendolo *ClusterOperationArn* con l'ARN ottenuto nell'output del `update-cluster-configuration` comando.
```
aws kafka describe-cluster-operation --cluster-operation-arn ClusterOperationArn
```
L'output di questo comando `describe-cluster-operation` è simile all'esempio JSON seguente.
```
{
"ClusterOperationInfo": {
"ClientRequestId": "982168a3-939f-11e9-8a62-538df00285db",
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"CreationTime": "2019-06-20T21:08:57.735Z",
"OperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef",
"OperationState": "UPDATE_COMPLETE",
"OperationType": "UPDATE_CLUSTER_CONFIGURATION",
"SourceClusterInfo": {},
"TargetClusterInfo": {
"ConfigurationInfo": {
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/ExampleConfigurationName/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"Revision": 1
}
}
}
}
```
In questo output, `OperationType` è `UPDATE_CLUSTER_CONFIGURATION`. Se il valore di `OperationState` è `UPDATE_IN_PROGRESS`, attendi qualche minuto, quindi esegui nuovamente il comando `describe-cluster-operation`.
## Aggiorna la configurazione di un cluster Amazon MSK utilizzando l'API
Per utilizzare l'API per aggiornare la configurazione di un cluster Amazon MSK, consulta [UpdateClusterConfiguration](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-configuration.html#UpdateClusterConfiguration).
# Configurazione del tipo di rete dual-stack per un cluster Amazon MSK
Amazon MSK supporta il tipo di rete dual-stack per i cluster MSK Provisioned esistenti che utilizzano Kafka versione 3.6.0 o successiva senza costi aggiuntivi. Con la rete dual-stack, i cluster possono utilizzare sia gli indirizzi che gli indirizzi. IPv4 IPv6 Gli endpoint dual-stack supportano inoltre il mantenimento della compatibilità con le versioni precedenti. IPv4 Amazon MSK fornisce IPv6 supporto tramite un tipo di rete dual-stack, non solo come -only. IPv6
Per impostazione predefinita, i client si connettono ai cluster Amazon MSK utilizzando il tipo di IPv4 rete. Tutti i nuovi cluster che crei vengono utilizzati IPv4 anche per impostazione predefinita. Per aggiornare il tipo di rete di un cluster al dual-stack, assicurati di aver soddisfatto i prerequisiti descritti nella sezione seguente. Quindi, utilizza l'[UpdateConnectivity](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-connectivity.html#UpdateConnectivity)API per aggiornare la connettività al dual-stack.
Quando abiliti la rete dual-stack sul tuo cluster, riceverai due tipi di stringhe di bootstrap: una per la connettività e una per la connettività. IPv4 IPv6 Sebbene il cluster stesso supporti entrambi IPv4 e IPv6 contemporaneamente (dual-stack), ogni stringa di bootstrap è specifica del protocollo: dovrai utilizzare stringhe bootstrap per le connessioni e stringhe bootstrap per le connessioni. IPv4 IPv4 IPv6 IPv6 Non esiste un'unica stringa di bootstrap che supporti entrambi i protocolli. Le stringhe IPv4 bootstrap esistenti continueranno a funzionare come prima, mentre le nuove stringhe IPv6 bootstrap verranno identificate dal prefisso 'bi6- '. Tieni presente che la IPv6 connettività è disponibile solo per i nodi broker: è possibile accedere ai nodi solo utilizzando ZooKeeper stringhe bootstrap. IPv4 Assicurati di configurare le porte appropriate per il protocollo che intendi utilizzare, poiché IPv4 le IPv6 connessioni utilizzano porte diverse. Per ulteriori informazioni sulle porte richieste, consulta [Informazioni sulle porte](https://docs.aws.amazon.com/msk/latest/developerguide/port-info.html).
Tutti i cluster MSK Provisioned esistenti che supportano il tipo di rete dual-stack utilizzeranno le stesse stringhe di IPv6 bootstrap sia per la connettività predefinita che per quella ad accesso pubblico. Se hai abilitato l'accesso pubblico sul tuo cluster, le stringhe di IPv6 bootstrap avranno automaticamente la funzionalità di accesso pubblico. Tieni presente che se l'accesso pubblico non è abilitato sul tuo cluster, queste stringhe di IPv6 bootstrap non avranno funzionalità di accesso pubblico. Le stringhe IPv4 bootstrap esistenti continueranno a funzionare come prima per quanto riguarda la connettività. IPv4
**Nota**
Dopo aver aggiornato il cluster per utilizzare il tipo di rete dual-stack, non è possibile tornare al tipo di rete. IPv4
**Topics**
+ [Prerequisiti per l'utilizzo del tipo di rete dual-stack](#mskp-ipv6-prerequisites)
+ [Autorizzazioni IAM per configurare il tipo di rete dual-stack](#mskp-ipv6-iam-permissions)
+ [Configura il tipo di rete dual-stack per un cluster esistente](#update-mskp-network-type)
+ [Considerazioni sull'utilizzo del tipo di rete dual-stack](#mskp-dual-stack-considerations)
## Prerequisiti per l'utilizzo del tipo di rete dual-stack
Prima di configurare il tipo di rete dual-stack per i cluster, assicurati di disporre di quanto segue:
+ Kafka versione 3.6.0 o successiva per i cluster MSK Provisioned esistenti.
+ A tutte le sottoreti fornite durante la creazione del cluster devono essere assegnati entrambi i blocchi CIDR IPv4 e IPv6 supportare il tipo di rete dual-stack. Se anche a una sola sottorete del cluster non sono assegnati blocchi IPv6 CIDR, non sarà possibile utilizzare il tipo di rete dual-stack per il cluster.
+ La connettività dual-stack non è supportata sui tipi di istanza kafka.t3.small. Se disponi di questo tipo di istanza e desideri utilizzare la connettività dual-stack, devi prima eseguire l'aggiornamento a un altro tipo di istanza supportato.
+ Le porte richieste devono essere aperte per la connettività. IPv6 Per informazioni sulle porte richieste, vedere [Informazioni sulle porte.](https://docs.aws.amazon.com/msk/latest/developerguide/port-info.html)
+ La connettività dual-stack non è supportata per i nodi. ZooKeeper È possibile connettersi ai nodi solo utilizzando. ZooKeeper IPv4
## Autorizzazioni IAM per configurare il tipo di rete dual-stack
Bisogna possedere le seguenti autorizzazioni IAM:
+ `ec2:CreateTags`
+ `ec2:DescribeSubnets`
+ `kafka:UpdateConnectivity`
Per un elenco completo delle autorizzazioni necessarie per eseguire tutte le azioni di Amazon MSK, consulta la policy AWS gestita: [Amazon MSKFull](https://docs.aws.amazon.com/msk/latest/developerguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonMSKFullAccess) Access.
## Configura il tipo di rete dual-stack per un cluster esistente
È possibile aggiornare il tipo di rete per un cluster MSK Provisioned esistente utilizzando, o SDK. Console di gestione AWS AWS CLI AWS
------
#### [ Using Console di gestione AWS ]
1. Aprire la console Amazon MSK a [https://console.aws.amazon.com/msk/casa? region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Scegliete il cluster MSK Provisioned per il quale desiderate configurare il tipo di rete dual-stack.
1. **Nella pagina dei dettagli del cluster, scegli Proprietà.**
1. In **Impostazioni di rete** scegli **Modifica**. Quindi, scegli **Modifica tipo di rete**.
**Nota**
Se il cluster non utilizza la versione 3.6.0 o successiva di Kafka e le relative sottoreti non supportano la configurazione dual-stack, l'opzione per modificare il tipo di rete non sarà disponibile. Per cambiare il tipo di rete, aggiorna la tua versione di Kafka e usa sottoreti che supportano la configurazione dual-stack.
1. ****Per Tipo di rete, scegli Dual stack.****
1. Scegli **Save changes** (Salva modifiche).
------
#### [ Using AWS CLI ]
È possibile utilizzare l'API [update-connectivity](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-connectivity.html) per aggiornare il tipo di rete del cluster MSK Provisioned esistente a dual-stack. L'esempio seguente utilizza il ` update-connectivity` comando per impostare il tipo di rete del cluster su dual-stack.
Nell'esempio seguente, sostituite l'ARN del cluster di esempio, arn:aws:kafka: ::cluster/, con l'ARN effettivo del *us-east-1* cluster * 123456789012* MSK. *myCluster* *12345678-1234-1234-1234-123456789012 -1* [Per ottenere la versione corrente del cluster, utilizzare il comando describe-cluster.](https://docs.aws.amazon.com/cli/latest/reference/kafka/describe-cluster.html)
```
aws kafka update-connectivity \
--cluster-arn "arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/12345678-1234-1234-1234-123456789012-1" \
--current-version "KTVPDKIKX0DER" \
--connectivity-info '{
"networkType": "DUAL"
}
```
------
#### [ Using AWS SDK ]
L'esempio seguente utilizza l'[ UpdateConnectivity](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-connectivity.html#UpdateConnectivity)API per impostare il tipo di rete del cluster su dual-stack.
Nell'esempio seguente, sostituite l'ARN del cluster di esempio, arn:aws:kafka: ::cluster/, con l'ARN effettivo del *us-east-1* cluster * 123456789012* MSK. *myCluster* *12345678-1234-1234-1234-123456789012 -1* Per ottenere la [ DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)versione corrente del cluster, usa l'API.
```
import boto3
client = boto3.client("kafka")
response = client.update_connectivity(
ClusterArn="arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/12345678-1234-1234-1234-123456789012-1",
CurrentVersion="KTVPDKIKX0DER",
ConnectivityInfo={
"NetworkType": "DUAL"
}
)
print("Connectivity update initiated:", response)
```
------
## Considerazioni sull'utilizzo del tipo di rete dual-stack
+ IPv6 il supporto è attualmente disponibile solo in modalità dual-stack (IPv4 \$1), non come -only. IPv6 IPv6
+ Per utilizzare un tipo di rete dual-stack per i cluster Amazon MSK Provisioned, è richiesta la versione 3.6.0 o successiva di Kafka.
+ Il tipo di rete dual-stack non è disponibile per la connettività privata multi-VPC.
+ IPv6 la connettività per i nodi Zookeeper non è disponibile. Puoi connetterti ai ZooKeeper nodi solo utilizzando. IPv4
+ È possibile modificare il tipo di rete da IPv4 dual-stack per un cluster esistente solo se tutte le relative sottoreti supportano il tipo di rete dual-stack.
+ Non è possibile tornare al tipo di rete dopo aver abilitato il dual-stack. IPv4 Per tornare indietro, è necessario eliminare e ricreare il cluster.
+ Bisogna possedere le seguenti autorizzazioni IAM:
+ `ec2:CreateTags`, `ec2:DescribeSubnets` e `kafka:UpdateConnectivity`
# Riavviare un broker per un cluster Amazon MSK
Utilizza questa operazione di Amazon MSK quando desideri riavviare un broker per un cluster MSK. Per riavviare un broker per un cluster, assicurati che il cluster si trovi nello stato `ACTIVE`.
Il servizio Amazon MSK può riavviare i broker del cluster MSK durante la manutenzione del sistema, ad esempio durante l'applicazione di patch o gli aggiornamenti di versione. Il riavvio manuale di un broker consente di testare la resilienza dei client Kafka per determinare come rispondono alla manutenzione del sistema.
## Riavviare un broker per un cluster Amazon MSK utilizzando il Console di gestione AWS
Questo processo descrive come riavviare un broker per un cluster Amazon MSK utilizzando. Console di gestione AWS
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Scegli il cluster MSK di cui desideri riavviare il broker.
1. Scorri verso il basso fino alla sezione **Dettagli del broker** e scegli il broker che desideri riavviare.
1. Scegli il pulsante **Riavvia broker**.
## Riavviare un broker per un cluster Amazon MSK utilizzando il AWS CLI
Questo processo descrive come riavviare un broker per un cluster Amazon MSK utilizzando. AWS CLI
1. Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) che hai ottenuto quando hai creato il cluster e *BrokerId* poi con l'ID del broker che desideri riavviare.
**Nota**
L'operazione `reboot-broker` supporta il riavvio di un singolo broker alla volta.
Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per ulteriori informazioni, consulta [Elenca i cluster Amazon MSK](msk-list-clusters.md).
Se non disponi del broker IDs per il tuo cluster, puoi trovarlo elencando i nodi del broker. Per ulteriori informazioni, consulta la sezione [list-nodes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/list-nodes.html).
```
aws kafka reboot-broker --cluster-arn ClusterArn --broker-ids BrokerId
```
L'output di questa operazione `reboot-broker` è simile al seguente JSON.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"ClusterOperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef"
}
```
1. Per ottenere il risultato dell'`reboot-broker`operazione, esegui il comando seguente, sostituendolo *ClusterOperationArn* con l'ARN ottenuto nell'output del `reboot-broker` comando.
```
aws kafka describe-cluster-operation --cluster-operation-arn ClusterOperationArn
```
L'output di questo comando `describe-cluster-operation` è simile all'esempio JSON seguente.
```
{
"ClusterOperationInfo": {
"ClientRequestId": "c0b7af47-8591-45b5-9c0c-909a1a2c99ea",
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"CreationTime": "2019-09-25T23:48:04.794Z",
"OperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef",
"OperationState": "REBOOT_IN_PROGRESS",
"OperationType": "REBOOT_NODE",
"SourceClusterInfo": {},
"TargetClusterInfo": {}
}
}
```
Quando l'operazione di riavvio è completa, il valore di `OperationState` è `REBOOT_COMPLETE`.
## Riavviare un broker per un cluster Amazon MSK utilizzando l'API
Per riavviare un broker in un cluster utilizzando l'API, consulta. [RebootBroker](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-reboot-broker.html#RebootBroker)
# Contrassegna un tag a un cluster Amazon MSK
Puoi assegnare i tuoi metadati sotto forma di *tag* a una risorsa Amazon MSK, ad esempio un cluster MSK. Un tag è una coppia chiave-valore che definisci per la flusso. L'utilizzo dei tag è un modo semplice ma efficace per gestire AWS le risorse e organizzare i dati, inclusi i dati di fatturazione.
**Topics**
+ [Nozioni di base sui tag per i cluster Amazon MSK](msk-tagging-basics.md)
+ [Tieni traccia dei costi dei cluster Amazon MSK utilizzando i tag](msk-tagging-billing.md)
+ [Limitazioni applicate ai tag](msk-tagging-restrictions.md)
+ [Contrassegna le risorse utilizzando l'API Amazon MSK](msk-tagging-howto.md)
# Nozioni di base sui tag per i cluster Amazon MSK
Puoi utilizzare l'API di Amazon MSK per completare le attività seguenti:
+ Aggiunta di tag a una risorsa Amazon MSK.
+ Elenco dei tag per una risorsa Amazon MSK.
+ Rimozione dei tag da una risorsa Amazon MSK.
Puoi utilizzare i tag per categorizzare le risorse Amazon MSK. Ad esempio, puoi categorizzare i cluster Amazon MSK in base a scopo, proprietario o ambiente. Poiché definisci una chiave e un valore per ogni tag, puoi creare un set di categorie personalizzate per soddisfare esigenze specifiche. Ad esempio, puoi definire un set di tag che consente di monitorare i cluster in base al proprietario e all'applicazione associata.
Di seguito sono illustrati alcuni esempi di tag:
+ `Project: Project name`
+ `Owner: Name`
+ `Purpose: Load testing`
+ `Environment: Production`
# Tieni traccia dei costi dei cluster Amazon MSK utilizzando i tag
Puoi utilizzare i tag per classificare e tenere traccia dei costi. AWS Quando applichi tag alle tue AWS risorse, inclusi i cluster Amazon MSK, il report sull'allocazione dei AWS costi include l'utilizzo e i costi aggregati per tag. Puoi organizzare i costi tra più servizi applicando tag che rappresentano categorie di business (come centri di costo, nomi di applicazioni o proprietari). Per ulteriori informazioni, consulta [Utilizzo dei tag per l'allocazione dei costi ai fini dei report di fatturazione personalizzati](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) nella *AWS Billing User Guide (Guida per l'utente di Amazon API Gateway)*.
# Limitazioni applicate ai tag
Ai tag in Amazon MSK si applicano le limitazioni seguenti.
**Limitazioni di base**
+ Il numero massimo di tag per risorsa è 50.
+ Per le chiavi e i valori dei tag viene fatta la distinzione tra maiuscole e minuscole.
+ Non è possibile cambiare o modificare i tag di una risorsa eliminata.
**Limitazioni applicate alle chiavi di tag**
+ Ogni chiave di tag deve essere univoca. Se aggiungi un tag con una chiave già in uso, il nuovo tag sovrascrive la coppia chiave-valore esistente.
+ Una chiave di tag non può iniziare con `aws:` perché questo prefisso è riservato per l'utilizzo da parte di AWS. AWS crea tag con questo prefisso per tuo conto, ma non puoi modificarli o eliminarli.
+ Le chiavi di tag devono avere una lunghezza compresa tra 1 e 128 caratteri Unicode.
+ Le chiavi di tag devono contenere i seguenti caratteri: lettere Unicode, cifre, spazio e i seguenti caratteri speciali: `_ . / = + - @`.
**Limitazioni applicate ai valori dei tag**
+ I valori dei tag devono avere una lunghezza compresa tra 0 e 255 caratteri Unicode.
+ I valori dei tag possono essere vuoti. In caso contrario, devono contenere i seguenti caratteri: lettere Unicode, cifre, spazio e i seguenti caratteri speciali: `_ . / = + - @`.
# Contrassegna le risorse utilizzando l'API Amazon MSK
Puoi utilizzare le operazioni seguenti per assegnare o rimuovere i tag da una risorsa Amazon MSK o per elencare il set di tag corrente per una risorsa:
+ [ListTagsForResource](https://docs.aws.amazon.com//msk/1.0/apireference/tags-resourcearn.html#ListTagsForResource)
+ [TagResource](https://docs.aws.amazon.com//msk/1.0/apireference/tags-resourcearn.html#TagResource)
+ [UntagResource](https://docs.aws.amazon.com//msk/1.0/apireference/tags-resourcearn.html#UntagResource)
# Esegui la migrazione dei carichi di lavoro Kafka in un cluster Amazon MSK
Amazon MSK Replicator supporta le migrazioni tra cluster Amazon MSK nello stesso ambiente. Account AWS Per le migrazioni da cluster non MSK, come i carichi di lavoro Apache Kafka, o tra cluster Amazon MSK multiaccount, devi usare Apache 2.0. MirrorMaker
[MSK Replicator](msk-replicator.md) è una soluzione serverless completamente gestita che automatizza la migrazione dei dati verso Amazon MSK. MSK Replicator gestisce le attività di scalabilità, monitoraggio e manutenzione senza richiedere la gestione dell'infrastruttura. Inoltre, mantiene le configurazioni degli argomenti e gli offset dei gruppi di consumatori durante la migrazione e si integra con altri. Servizi AWS
[Apache MirrorMaker 2.0](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=27846330) è uno strumento open source che richiede configurazione e gestione manuali, ma fornisce un controllo dettagliato sul processo di migrazione. È possibile definire regole di replica personalizzate e migrare tra qualsiasi cluster Apache Kafka indipendentemente dalla piattaforma di hosting o tra diversi cluster. Account AWS[Per informazioni sull'utilizzo per la migrazione dei cluster, MirrorMaker consulta Geo-Replication (Cross-Cluster Data Mirroring).](https://kafka.apache.org/40/documentation.html#georeplication) Consigliamo di eseguire la configurazione in una configurazione ad alta disponibilità. MirrorMaker
Per ulteriori informazioni su come scegliere la strategia di replica giusta per il tuo carico di lavoro, [consulta Amazon MSK Replicator e MirrorMaker 2: Choosing the right replication strategy for Apache Kafka](https://aws.amazon.com/blogs/big-data/amazon-msk-replicator-and-mirrormaker2-choosing-the-right-replication-strategy-for-apache-kafka-disaster-recovery-and-migrations/) disaster recovery e migrazioni.
# Eliminare un cluster Amazon MSK Provisioned
**Nota**
Se il cluster Amazon MSK di cui hai effettuato il provisioning ha una politica di auto-scaling, ti consigliamo di rimuovere la policy prima di eliminare il cluster. Per ulteriori informazioni, consulta [Scalabilità automatica per i cluster Amazon MSK](msk-autoexpand.md).
**Topics**
+ [Eliminare un cluster Amazon MSK Provisioned utilizzando il Console di gestione AWS](delete-cluster-console.md)
+ [Eliminare un cluster Amazon MSK Provisioned utilizzando il AWS CLI](delete-cluster-cli.md)
+ [Eliminare un cluster Amazon MSK Provisioned utilizzando l'API](delete-cluster-api.md)
# Eliminare un cluster Amazon MSK Provisioned utilizzando il Console di gestione AWS
Questo processo descrive come eliminare un cluster Amazon MSK Provisioned utilizzando il. Console di gestione AWS Prima di eliminare un cluster MSK, assicurati di disporre di un backup di tutti i dati importanti memorizzati nel cluster e che non vi siano attività pianificate dipendenti dal cluster. Non è possibile annullare l'eliminazione di un cluster MSK.
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Scegli il cluster MSK da eliminare selezionando la casella di controllo accanto ad esso.
1. Scegli **Elimina** e conferma l'eliminazione.
# Eliminare un cluster Amazon MSK Provisioned utilizzando il AWS CLI
Questo processo descrive come eliminare un cluster MSK Provisioned utilizzando. AWS CLI Prima di eliminare un cluster MSK, assicurati di disporre di un backup di tutti i dati importanti memorizzati nel cluster e che non vi siano attività pianificate dipendenti dal cluster. Non è possibile annullare l'eliminazione di un cluster MSK.
Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) che hai ottenuto quando hai creato il cluster. Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per ulteriori informazioni, consulta [Elenca i cluster Amazon MSK](msk-list-clusters.md).
```
aws kafka delete-cluster --cluster-arn ClusterArn
```
# Eliminare un cluster Amazon MSK Provisioned utilizzando l'API
L'API Amazon MSK ti consente di creare e gestire in modo programmatico il tuo cluster MSK Provisioned come parte di script di provisioning o distribuzione automatizzati dell'infrastruttura. Questo processo descrive come eliminare un cluster Amazon MSK Provisioned utilizzando l'API Amazon MSK. Prima di eliminare un cluster Amazon MSK, assicurati di disporre di un backup di tutti i dati importanti memorizzati nel cluster e che non vi siano attività pianificate dipendenti dal cluster. Non è possibile annullare l'eliminazione di un cluster MSK.
Per eliminare un cluster utilizzando l'API, vedi. [DeleteCluster](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn.html#DeleteCluster)
# Caratteristiche e concetti chiave di Amazon MSK
I cluster Amazon MSK Provisioned offrono un'ampia gamma di caratteristiche e funzionalità per aiutarti a ottimizzare le prestazioni del cluster e soddisfare le tue esigenze di streaming. Gli argomenti seguenti descrivono queste funzionalità in dettaglio.
+ La [Console di gestione AWS](https://console.aws.amazon.com/msk)
+ La [documentazione di riferimento all'API di Amazon MSK](https://docs.aws.amazon.com/msk/1.0/apireference)
+ La [documentazione di riferimento ai comandi della CLI di Amazon MSK](https://docs.aws.amazon.com/cli/latest/reference/kafka/index.html)
**Topics**
+ [Tipi di broker Amazon MSK](broker-instance-types.md)
+ [Dimensioni dei broker Amazon MSK](broker-instance-sizes.md)
+ [Gestione dello storage per broker Standard](msk-storage-management.md)
+ [Configurazione Amazon MSK Provisioned](msk-configuration.md)
+ [Ribilanciamento intelligente per i cluster](intelligent-rebalancing.md)
+ [Applicazione di patch sui cluster MSK Provisioned](patching-impact.md)
+ [Broker offline e failover del client](troubleshooting-offlinebroker-clientfailover.md)
+ [Sicurezza in Amazon MSK](security.md)
+ [Registrazione Amazon MSK](msk-logging.md)
+ [Gestione dei metadati](metadata-management.md)
+ [Argomento Operazioni](msk-topic-operations-information.md)
+ [Risorse Amazon MSK](resources.md)
+ [Versioni di Apache Kafka](kafka-versions.md)
+ [Risolvi i problemi del tuo cluster Amazon MSK](troubleshooting.md)
# Tipi di broker Amazon MSK
MSK Provisioned offre due tipi di broker: Standard ed Express. I broker standard offrono la massima flessibilità per configurare i cluster, mentre i broker Express offrono maggiore elasticità, velocità effettiva e resilienza e ease-of-use per l'esecuzione di applicazioni di streaming ad alte prestazioni.
Per ulteriori dettagli su ciascuna offerta, consulta i seguenti argomenti. La tabella seguente evidenzia anche il confronto delle funzionalità chiave tra i broker Standard ed Express.
| Funzionalità | Broker standard | Broker espresso |
| --- | --- | --- |
| [Gestione dello storage](msk-storage-management.md) | Gestita dal cliente (le funzionalità includono storage EBS, storage su più livelli, throughput di storage fornito, scalabilità automatica, avvisi sulla capacità di storage) | Completamente gestito da MSK |
| [Istanze supportate](broker-instance-sizes.md) | T3, M5, M7g | M7g |
| [Considerazioni sul dimensionamento e sulla scalabilità](bestpractices-intro.md) | Velocità effettiva, connessioni, partizioni, archiviazione | Velocità effettiva, connessioni, partizioni |
| [Scalabilità dei broker](msk-update-broker-count.md) | Scalabilità verticale e orizzontale | Ridimensionamento verticale e orizzontale |
| [Versioni Kafka](kafka-versions.md) | Per informazioni, consultare [Versioni di Apache Kafka](kafka-versions.md). | Inizia dalla versione 3.6 |
| [Configurazione di Apache Kafka](msk-configuration.md) | Più configurabile | Principalmente MSK è gestito per una maggiore resilienza |
| [Sicurezza](security.md) | Crittografia, Private/Public accesso, autenticazione e autorizzazione: IAM, SASL/SCRAM, mTLS, testo in chiaro, Kafka ACLs | Crittografia, Private/Public accesso, autenticazione e autorizzazione: IAM, SASL/SCRAM, mTLS, testo in chiaro, Kafka ACLs |
| [Monitoraggio](monitoring.md) | CloudWatch, Monitoraggio aperto | CloudWatch, Monitoraggio aperto |
**Nota**
Non è possibile modificare un cluster MSK Provisioned da un tipo di broker Standard a un tipo di broker Express cambiando il tipo di broker utilizzando l'API MSK. È necessario creare un nuovo cluster con il tipo di broker desiderato (Standard o Express).
**Topics**
+ [Broker Amazon MSK Standard](msk-broker-types-standard.md)
+ [Broker Amazon MSK Express](msk-broker-types-express.md)
# Broker Amazon MSK Standard
I broker standard per MSK Provisioned offrono la massima flessibilità per configurare le prestazioni del cluster. È possibile scegliere tra un'ampia gamma di configurazioni di cluster per ottenere le caratteristiche di disponibilità, durabilità, velocità effettiva e latenza richieste per le applicazioni. È inoltre possibile fornire la capacità di storage e aumentarla in base alle esigenze. Amazon MSK gestisce la manutenzione hardware dei broker Standard e delle risorse di storage collegate, riparando automaticamente i problemi hardware che possono insorgere. [[Puoi trovare maggiori dettagli in questo documento su vari argomenti relativi ai broker Standard, inclusi argomenti sulla [gestione dello storage](msk-storage-management.md), le configurazioni e la manutenzione.](patching-impact.md#patching-standard-brokers)](msk-configuration-standard.md)
# Broker Amazon MSK Express
I broker Express per MSK Provisioned rendono Apache Kafka più semplice da gestire, più conveniente da eseguire su larga scala e più elastico grazie alla bassa latenza prevista. I broker includono uno pay-as-you-go storage scalabile automaticamente e che non richiede dimensionamento, provisioning o monitoraggio proattivo. A seconda della dimensione dell'istanza selezionata, ogni nodo del broker può fornire un throughput fino a 3 volte superiore per broker, scalare fino a 20 volte più velocemente e ripristinare il 90% più velocemente rispetto ai broker Apache Kafka standard. I broker Express sono preconfigurati con le best practice predefinite di Amazon MSK e applicano le quote di throughput dei clienti per ridurre al minimo la contesa di risorse tra i clienti e le operazioni in background di Kafka.
Ecco alcuni fattori e funzionalità chiave da considerare quando si utilizzano i broker Express.
+ **Nessuna gestione dello storage**: i broker Express eliminano la necessità di [fornire o gestire qualsiasi risorsa di storage](msk-storage-management.md). Ottieni uno storage elastico pay-as-you-go, praticamente illimitato e completamente gestito. Per i casi d'uso con throughput elevato, non è necessario ragionare sulle interazioni tra istanze di elaborazione e volumi di storage e sui relativi colli di bottiglia in termini di throughput. Queste funzionalità semplificano la gestione dei cluster ed eliminano il sovraccarico operativo della gestione dello storage.
+ **Scalabilità più rapida**: i broker Express consentono di scalare il cluster e spostare le partizioni fino a 20 volte più velocemente rispetto ai broker Standard. Questa funzionalità è fondamentale quando è necessario scalare il cluster per gestire i picchi di carico imminenti o scalare il cluster per ridurre i costi. Per maggiori dettagli sulla scalabilità del [cluster, consulta le sezioni sull'espansione](msk-update-broker-count.md) del cluster, la [rimozione dei broker](msk-remove-broker.md), la [riassegnazione delle partizioni](msk-update-broker-type.md) e [ LinkedInla configurazione del Cruise Control per il ribilanciamento](cruise-control.md).
+ **Throughput più elevato**: i broker Express offrono un throughput fino a 3 volte superiore per broker rispetto ai broker Standard. Ad esempio, è possibile scrivere in sicurezza fino a 500 dati MBps con ogni broker Express di dimensioni pari a m7g.16xlarge rispetto ai 153,8 MBps del broker Standard equivalente (entrambi i numeri presuppongono un'allocazione della larghezza di banda sufficiente per le operazioni in background, come la replica e il ribilanciamento).
+ **Configurato per un'elevata resilienza: i broker Express offrono automaticamente diverse best practice per migliorare la resilienza** del cluster. Queste includono protezioni sulle configurazioni critiche di Apache Kafka, quote di throughput e prenotazioni di capacità per operazioni in background e riparazioni non pianificate. Queste funzionalità rendono più sicura e semplice l'esecuzione di applicazioni Apache Kafka su larga scala. Consulta le sezioni relative [Configurazioni del broker Express](msk-configuration-express.md) e [Quota del broker Amazon MSK Express](limits.md#msk-express-quota) per maggiori dettagli.
+ **Nessuna finestra di manutenzione**: non ci sono finestre di manutenzione per i broker Express. Amazon MSK aggiorna automaticamente l'hardware del cluster su base continuativa. Per maggiori dettagli, consulta [Patching for Express brokers](https://docs.aws.amazon.com/msk/latest/developerguide/patching-impact.html#patching-express-brokers).
## Informazioni aggiuntive sui broker Express
+ I broker Express funzionano con Apache Kafka APIs, ma non supportano ancora completamente le API. KStreams
+ I broker Express sono disponibili solo in una configurazione a 3. AZs
+ I broker Express sono disponibili solo su istanze di dimensioni selezionate. Consulta i [prezzi di Amazon MSK](https://aws.amazon.com/msk/pricing/) per l'elenco aggiornato.
+ I broker Express sono supportati nelle seguenti versioni di Apache Kafka: 3.6, 3.8 e 3.9.
+ I broker Express possono essere creati con KRaft modalità a partire dalla versione 3.9 di Apache Kafka.
**Vedi questi blog**
Per ulteriori informazioni sui broker MSK Express e per vedere un esempio reale di utilizzo dei broker Express, leggi i seguenti blog:
[Ti presentiamo Express Brokers for Amazon MSK per offrire un throughput elevato e una scalabilità più rapida per i tuoi cluster Kafka](https://aws.amazon.com/blogs/aws/introducing-express-brokers-for-amazon-msk-to-deliver-high-throughput-and-faster-scaling-for-your-kafka-clusters/)
[Express Brokers per Amazon MSK: scalabilità Kafka potenziata con prestazioni fino a 20 volte più veloci](https://aws.amazon.com/blogs/big-data/express-brokers-for-amazon-msk-turbo-charged-kafka-scaling-with-up-to-20-times-faster-performance/)
Questo blog dimostra come i broker Express:
Offrono un throughput più rapido, una scalabilità rapida e tempi di ripristino migliorati in caso di guasti
Elimina le complessità di gestione dello storage
# Dimensioni dei broker Amazon MSK
Quando crei un cluster Amazon MSK Provisioned, specifichi la dimensione dei broker che desideri che abbia. A seconda del [tipo di broker](broker-instance-types.md), Amazon MSK supporta le seguenti dimensioni di broker.
**Dimensioni standard dei broker**
+ kafka.t3.small
+ kafka.m5.large, kafka.m5.xlarge, kafka.m5.2xlarge, kafka.m5.4xlarge, kafka.m5.8xlarge, kafka.m5.12xlarge, kafka.m5.16xlarge, kafka.m5.24xlarge
+ kafka.m7g.large, kafka.m7g.xlarge, kafka.m7g.2xlarge, kafka.m7g.4xlarge, kafka.m7g.8xlarge, kafka.m7g.12xlarge, kafka.m7g.16xlarge, kafka.m7g.16xlarge
**Dimensioni dei broker Express**
+ express.m7g.large, express.m7g.xlarge, express.m7g.2xlarge, express.m7g.4xlarge, express.m7g.8xlarge, express.m7g.12xlarge, express.m7g.16xlarge, express.m7g.16xlarge
**Nota**
Alcune dimensioni di broker potrebbero non essere disponibili in alcune regioni. AWS Consulta le tabelle dei prezzi aggiornate delle istanze Broker nella [pagina dei prezzi di Amazon MSK](https://aws.amazon.com/msk/pricing/) per l'elenco più recente delle istanze disponibili per regione.
## Altre note sulle dimensioni dei broker
+ I broker M7g utilizzano processori AWS Graviton (processori personalizzati basati su ARM creati da Amazon Web Services). I broker M7g offrono un rapporto prezzo/prestazioni migliorato rispetto alle istanze M5 comparabili. I broker M7g consumano meno energia rispetto alle istanze M5 comparabili.
+ Amazon MSK supporta i broker M7g su cluster MSK Provisioned con versioni 2.8.2 e 3.3.2 e successive di Kafka.
+ I broker M7g e M5 offrono prestazioni di throughput di base più elevate rispetto ai broker T3 e sono consigliati per carichi di lavoro di produzione. I broker M7g e M5 possono anche avere più partizioni per broker rispetto ai broker T3. Usa i broker M7g o M5 se esegui carichi di lavoro di livello di produzione più grandi o richiedi un numero maggiore di partizioni. Per ulteriori informazioni sulle dimensioni delle istanze M7g e M5, consulta [Amazon EC2 General](https://aws.amazon.com/ec2/instance-types/) Purpose Instances.
+ I broker T3 possono utilizzare i crediti della CPU per incrementare temporaneamente le prestazioni. Utilizza i broker T3 per lo sviluppo a basso costo, se stai provando carichi di lavoro di streaming di piccole e medie dimensioni o se disponi di carichi di lavoro di streaming a throughput basso con picchi temporanei di throughput. Ti consigliamo di eseguire un proof-of-concept test per determinare se i broker T3 sono sufficienti per la produzione o per un carico di lavoro critico. Per ulteriori informazioni sulle dimensioni dei broker T3, consulta [Amazon EC2 T3 Instances](https://aws.amazon.com/ec2/instance-types/t3/).
Per ulteriori informazioni su come scegliere le dimensioni dei broker, consulta. [Le migliori pratiche per i broker Standard ed Express](bestpractices-intro.md)
# Gestione dello storage per broker Standard
Amazon MSK offre funzionalità per aiutarti con la gestione dell'archiviazione sui tuoi cluster MSK.
**Nota**
Con [i broker Express](msk-broker-types-express.md), non è necessario fornire o gestire le risorse di archiviazione utilizzate per i dati. Ciò semplifica la gestione dei cluster ed elimina una delle cause più comuni dei problemi operativi con i cluster Apache Kafka. Inoltre, spendi meno in quanto non devi fornire capacità di storage inattiva e paghi solo per ciò che utilizzi.
**Tipo di broker standard**
Con [i broker Standard](msk-broker-types-standard.md) puoi scegliere tra una varietà di opzioni e funzionalità di archiviazione. Amazon MSK offre funzionalità per aiutarti con la gestione dell'archiviazione sui tuoi cluster MSK.
Per informazioni sulla gestione del throughput, consulta. [Esegui il provisioning del throughput di storage per i broker Standard in un cluster Amazon MSK](msk-provision-throughput.md)
**Topics**
+ [Storage su più livelli per broker Standard](msk-tiered-storage.md)
+ [Espandi lo storage dei broker Amazon MSK Standard](msk-update-storage.md)
+ [Gestisci il throughput di storage per i broker Standard in un cluster Amazon MSK](msk-provision-throughput-management.md)
# Storage su più livelli per broker Standard
L'archiviazione a più livelli è un livello di archiviazione a basso costo per Amazon MSK che si dimensiona fino a una capacità praticamente illimitata, rendendo conveniente la creazione di applicazioni di streaming di dati.
È possibile creare un cluster Amazon MSK configurato con un'archiviazione a più livelli che bilancia prestazioni e costi. Amazon MSK archivia i dati in streaming in un livello di archiviazione primario ottimizzato per le prestazioni fino a raggiungere i limiti di conservazione degli argomenti di Apache Kafka. Quindi, Amazon MSK sposta automaticamente i dati nel nuovo livello di archiviazione a basso costo.
Quando l'applicazione inizia a leggere i dati dall'archiviazione a più livelli, è possibile che i primi byte siano soggetti a un aumento della latenza di lettura. Quando inizi a leggere i dati rimanenti in sequenza dal livello a basso costo, le latenze dovrebbero essere simili a quelle del livello di archiviazione primario. Non è necessario effettuare il provisioning di alcun tipo di archiviazione per l'archiviazione più livelli a basso costo o per gestire l'infrastruttura. È possibile archiviare qualsiasi quantità di dati e pagare solo per le risorse utilizzate. Questa funzionalità è compatibile con la funzionalità APIs introdotta in [KIP-405: Kafka Tiered Storage](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage).
Per informazioni sul dimensionamento, il monitoraggio e l'ottimizzazione del cluster di storage su più livelli MSK, consulta [Best practice per l'esecuzione di carichi di lavoro di produzione utilizzando lo storage su più livelli Amazon](https://aws.amazon.com/blogs/big-data/best-practices-for-running-production-workloads-using-amazon-msk-tiered-storage/) MSK.
Di seguito sono elencate alcune caratteristiche dell'archiviazione a più livelli:
+ È possibile dimensionare fino a una capacità di archiviazione praticamente illimitata. Non è necessario fare supposizioni su come dimensionare la propria infrastruttura Apache Kafka.
+ È possibile mantenere i dati più a lungo negli argomenti di Apache Kafka o aumentare lo spazio di archiviazione degli argomenti senza la necessità di aumentare il numero di broker.
+ Fornisce un buffer di sicurezza di maggiore durata per gestire ritardi imprevisti nell'elaborazione.
+ Puoi rielaborare i vecchi dati nel loro esatto ordine di produzione con il codice di elaborazione dello stream esistente e Kafka. APIs
+ Le partizioni si ribilanciano più velocemente perché i dati nell'archiviazione secondaria non richiedono la replica tra i dischi del broker.
+ I dati tra i broker e l'archiviazione a più livelli si spostano all'interno del VPC e non viaggiano su Internet.
+ Per connettersi a nuovi cluster con l'archiviazione a più livelli abilitata, un computer client può utilizzare lo stesso processo che utilizza per connettersi a un cluster senza l'archiviazione a più livelli abilitata. Consulta la sezione [Creazione di un computer client](https://docs.aws.amazon.com/msk/latest/developerguide/create-client-machine.html).
## Requisiti di storage su più livelli per i cluster Amazon MSK
+ È necessario utilizzare la versione 3.0.0 o successiva del client Apache Kafka per creare un nuovo argomento con l'archiviazione a più livelli abilitata. Per trasferire un argomento esistente all'archiviazione a più livelli, puoi riconfigurare un computer client che utilizza una versione del client Kafka precedente alla 3.0.0 (la versione minima supportata di Apache Kafka è 2.8.2.tiered) per abilitare l'archiviazione a più livelli. Per informazioni, consulta [Fase 4: creare un argomento nel cluster Amazon MSK](create-topic.md).
+ Il cluster Amazon MSK con storage su più livelli abilitato deve utilizzare la versione 3.6.0 o successiva o 2.8.2.tiered.
## Vincoli e limitazioni dello storage su più livelli per i cluster Amazon MSK
L'archiviazione a più livelli presenta i seguenti vincoli e limitazioni:
+ Assicurati che i client non siano configurati per `read_committed` la lettura da remote\$1tier in Amazon MSK, a meno che l'applicazione non utilizzi attivamente la funzionalità delle transazioni.
+ Lo storage su più livelli non è disponibile nelle regioni AWS GovCloud (Stati Uniti).
+ L'archiviazione a più livelli si applica solo ai cluster in modalità assegnata.
+ Lo storage su più livelli non supporta la dimensione del broker t3.small.
+ Il periodo di conservazione minimo nell'archiviazione a basso costo è di 3 giorni. Non è previsto un periodo minimo di conservazione per l'archiviazione primaria.
+ L'archiviazione a più livelli non supporta le directory di log multipli su un broker (funzionalità relative a JBOD).
+ Lo storage su più livelli non supporta argomenti compatti. Assicurati che cleanup.policy sia configurato solo su «DELETE» per tutti gli argomenti per cui è attivato lo storage su più livelli.
+ Il cluster di archiviazione a più livelli non supporta la modifica della politica log.cleanup.policy per un argomento dopo la sua creazione.
+ Lo storage su più livelli può essere disabilitato per singoli argomenti ma non per l'intero cluster. Una volta disattivata, l'archiviazione a più livelli non può essere riattivata per un argomento.
+ Se utilizzi la versione 2.8.2.tiered di Amazon MSK, puoi migrare solo a un'altra versione di Apache Kafka supportata dallo storage su più livelli. Se non desideri continuare a utilizzare una versione supportata dallo storage su più livelli, crea un nuovo cluster MSK e migra i tuoi dati su di esso.
+ Lo kafka-log-dirs strumento non è in grado di riportare le dimensioni dei dati di storage su più livelli. Lo strumento riporta solo la dimensione dei segmenti di log nell'archiviazione primaria.
Per informazioni sulle impostazioni e sui vincoli predefiniti, è necessario prestare attenzione quando si configura lo storage su più livelli a livello di argomento, vedere. [Linee guida per la configurazione a livello di argomento dello storage su più livelli di Amazon MSK](msk-guidelines-tiered-storage-topic-level-config.md)
# Come vengono copiati i segmenti di log nello storage su più livelli per un argomento di Amazon MSK
Quando abiliti l'archiviazione a più livelli per un argomento nuovo o esistente, Apache Kafka copia i segmenti di log chiusi dall'archiviazione primaria all'archiviazione a più livelli.
+ Apache Kafka copia solo i segmenti di log chiusi. Copia tutti i messaggi all'interno del segmento di log in un'archiviazione a più livelli.
+ I segmenti attivi non sono idonei per l'archiviazione a più livelli. La dimensione del segmento di log (segment.bytes) o il tempo di distribuzione del segmento (segment.ms) controllano la velocità di chiusura dei segmenti e la velocità con cui, successivamente, Apache Kafka li copia nell'archiviazione a più livelli.
Le impostazioni di conservazione per un argomento con l'archiviazione a più livelli abilitata sono diverse dalle impostazioni per un argomento senza l'archiviazione a più livelli abilitata. Le seguenti regole disciplinano la conservazione dei messaggi negli argomenti con l'archiviazione a più livelli abilitata:
+ È possibile definire la conservazione in Apache Kafka con due impostazioni: log.retention.ms (durata) e log.retention.bytes (dimensioni). Queste impostazioni determinano la durata e le dimensioni totali dei dati che Apache Kafka conserva nel cluster. Indipendentemente dal fatto che si abiliti o meno la modalità di archiviazione a più livelli, queste configurazioni vengono impostate a livello di cluster. È possibile sovrascrivere le impostazioni a livello di argomento con le configurazioni degli argomenti.
+ Quando si abilita l'archiviazione a più livelli, è possibile specificare anche per quanto tempo il livello di archiviazione primaria ad alte prestazioni archivia i dati. Ad esempio, se un argomento ha un'impostazione di conservazione complessiva (log.retention.ms) di 7 giorni e una conservazione locale (local.retention.ms) di 12 ore, l'archiviazione primaria del cluster conserva i dati solo per le prime 12 ore. Il livello di archiviazione a basso costo conserva i dati per tutti i 7 giorni.
+ Al log completo si applicano le normali impostazioni di conservazione. Ciò include le parti primarie e a più livelli.
+ Le impostazioni local.retention.ms o local.retention.bytes controllano la conservazione dei messaggi nell'archiviazione primaria. Apache Kafka copia i segmenti di log chiusi nello storage su più livelli non appena vengono chiusi (in base a segment.bytes o segment.ms), indipendentemente dalle impostazioni di conservazione locali. Dopo che i segmenti sono stati copiati nello storage su più livelli, rimangono nello storage principale fino al raggiungimento delle soglie local.retention.ms o local.retention.bytes. A quel punto, i dati vengono eliminati dallo storage principale ma rimangono disponibili nello storage su più livelli. Ciò consente di conservare i dati recenti su uno storage primario ad alte prestazioni per un accesso rapido, mentre i dati più vecchi vengono serviti dallo storage su più livelli a basso costo.
+ Quando Apache Kafka copia un messaggio in un segmento di log a più livelli, lo rimuove dal cluster in base alle impostazioni retention.ms o retention.bytes.
## Esempio di scenario di storage su più livelli di Amazon MSK
Questo scenario illustra il comportamento di un argomento esistente che contiene messaggi nell'archiviazione primaria quando è abilitata l'archiviazione a più livelli. L'archiviazione a più livelli su questo argomento viene abilitata quando si imposta remote.storage.enable su `true`. In questo esempio, retention.ms è impostato su 5 giorni e local.retention.ms è impostato su 2 giorni. Di seguito è riportata la sequenza di eventi alla scadenza di un segmento.
**Ora T0: prima di abilitare l'archiviazione a più livelli.**
Prima di abilitare l'archiviazione a più livelli per questo argomento, esistono due segmenti di log. Uno dei segmenti è attivo per una partizione di argomenti esistente 0.
![\[Ora T0: prima di abilitare l'archiviazione a più livelli.\]](http://docs.aws.amazon.com/it_it/msk/latest/developerguide/images/tiered-storage-segments-1.png)
**Ora T1 (< 2 giorni): archiviazione a più livelli abilitata. Segmento 0 copiato nell'archiviazione a più livelli.**
Dopo aver abilitato lo storage su più livelli per questo argomento, Apache Kafka copia il segmento di log chiuso 0 nello storage su più livelli non appena viene chiuso. Il segmento si chiude in base alle impostazioni segment.bytes o segment.ms, non in base alle impostazioni di conservazione. Apache Kafka conserva una copia anche nella memoria principale. Il segmento 1 attivo non è ancora idoneo alla copia su uno storage su più livelli perché è ancora attivo e non è stato chiuso. In questa sequenza temporale, Amazon MSK non applica ancora nessuna delle impostazioni di conservazione per nessuno dei messaggi nel segmento 0 e nel segmento 1. (conservazione locale). bytes/ms, retention.ms/bytes)
![\[Ora T1 (< 2 giorni): archiviazione a più livelli abilitata. Segmento 0 copiato nell'archiviazione a più livelli.\]](http://docs.aws.amazon.com/it_it/msk/latest/developerguide/images/tiered-storage-segments-2.png)
**Ora T2: conservazione locale in vigore.**
Dopo 2 giorni, viene raggiunta la soglia di conservazione locale per il segmento 0. Ciò è determinato dall'impostazione di local.retention.ms su 2 giorni. Il segmento 0 viene ora eliminato dallo storage principale, ma rimane disponibile nello storage su più livelli. Si noti che il segmento 0 era già stato copiato nello storage su più livelli al momento T1 alla chiusura, non al momento T2 alla scadenza della conservazione locale. Il segmento attivo 1 non è ancora idoneo per l'eliminazione né per la copia su uno storage su più livelli perché è ancora attivo.
![\[Ora T2: conservazione locale in vigore.\]](http://docs.aws.amazon.com/it_it/msk/latest/developerguide/images/tiered-storage-segments-3.png)
**Ora T3: conservazione complessiva in vigore.**
Dopo 5 giorni, le impostazioni di conservazione hanno effetto e Kafka cancella il segmento di log 0 e i messaggi associati dall'archiviazione a più livelli. Il segmento 1 non è ancora idoneo alla scadenza né può essere copiato nell'archiviazione a più livelli perché è attivo. Il segmento 1 non è ancora chiuso, quindi non è idoneo per la distribuzione dei segmenti.
![\[Ora T3: conservazione complessiva in vigore.\]](http://docs.aws.amazon.com/it_it/msk/latest/developerguide/images/tiered-storage-segments-4.png)
# Crea un cluster Amazon MSK con storage su più livelli con Console di gestione AWS
Questo processo descrive come creare un cluster Amazon MSK di storage su più livelli utilizzando. Console di gestione AWS
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Scegli **Crea cluster**.
1. Scegli **Creazione personalizzata** per l'archiviazione a più livelli.
1. Specificare un nome per il cluster.
1. In **Tipo di cluster**, seleziona **Assegnato**.
1. Scegli la versione di Amazon Kafka che supporti l'archiviazione a più livelli e che desideri che Amazon MSK utilizzi per creare il cluster.
1. **Specificate una dimensione del broker diversa da kafka.t3.small.**
1. Specifica il numero di broker che devono essere creati da Amazon MSK in ogni zona di disponibilità. Il valore minimo è un broker per zona di disponibilità e il valore massimo è 30 broker per cluster.
1. Specifica il numero di zone in cui sono distribuiti i broker.
1. Specifica il numero di broker Apache Kafka implementati per zona.
1. Seleziona **Opzioni di archiviazione**. Ciò include l'**archiviazione a più livelli e l'archiviazione EBS** per abilitare la modalità di archiviazione a più livelli.
1. Segui i restanti passaggi nella procedura guidata di creazione dei cluster. Al termine, **Archiviazione a più livelli e archiviazione EBS** viene visualizzata come modalità di archiviazione del cluster nella vista **Rivedi e crea**.
1. Selezionare **Creazione di un cluster**.
# Crea un cluster Amazon MSK con storage su più livelli con AWS CLI
Per abilitare l'archiviazione a più livelli su un cluster, crea il cluster con la versione e l'attributo di Apache Kafka corretti per l'archiviazione a più livelli. Segui l'esempio di codice sottostante. Inoltre, completa la procedura descritta nella sezione successiva per [Crea un argomento su Kafka con lo storage su più livelli abilitato con AWS CLI](#msk-create-topic-tiered-storage-cli).
Per un elenco completo degli attributi supportati per la creazione di cluster, consulta la sezione [create-cluster](https://docs.aws.amazon.com//cli/latest/reference/kafka/create-cluster.html).
```
aws kafka create-cluster \
—cluster-name "MessagingCluster" \
—broker-node-group-info file://brokernodegroupinfo.json \
—number-of-broker-nodes 3 \
--kafka-version "3.6.0" \
--storage-mode "TIERED"
```
## Crea un argomento su Kafka con lo storage su più livelli abilitato con AWS CLI
Per completare il processo avviato quando hai creato un cluster con l'archiviazione a più livelli abilitata, crea anche un argomento con l'archiviazione a più livelli abilitata con gli attributi dell'esempio di codice successivo. Gli attributi specifici per l'archiviazione a più livelli sono i seguenti:
+ `local.retention.ms` (ad esempio, 10 minuti) per le impostazioni di conservazione basate sul tempo o `local.retention.bytes` per i limiti delle dimensioni dei segmenti di log.
+ `remote.storage.enable` impostato su `true` per abilitare l'archiviazione a più livelli.
La configurazione seguente utilizza local.retention.ms, ma è possibile sostituire questo attributo con local.retention.bytes. Questo attributo controlla la quantità di tempo che può trascorrere o il numero di byte che Apache Kafka può copiare prima che il servizio copi i dati dall'archiviazione primaria a quella a più livelli. Per maggiori dettagli sugli attributi di configurazione supportati, consulta la sezione [Configurazione a livello di argomento](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration).
**Nota**
È necessario utilizzare la versione 3.0.0 o successiva del client Apache Kafka. Queste versioni supportano un'impostazione chiamata `remote.storage.enable` solo in tali versioni client di `kafka-topics.sh`. Per abilitare l'archiviazione a più livelli su un argomento esistente che utilizza una versione precedente di Apache Kafka, consulta la sezione [Abilitazione dello storage su più livelli su un argomento esistente di Amazon MSK](msk-enable-disable-topic-tiered-storage-cli.md#msk-enable-topic-tiered-storage-cli).
```
bin/kafka-topics.sh --create --bootstrap-server $bs --replication-factor 2 --partitions 6 --topic MSKTutorialTopic --config remote.storage.enable=true --config local.retention.ms=100000 --config retention.ms=604800000 --config segment.bytes=134217728
```
# Abilitare e disabilitare lo storage su più livelli su un argomento esistente di Amazon MSK
Queste sezioni spiegano come abilitare e disabilitare l'archiviazione a più livelli su un argomento che hai già creato. Per creare un nuovo cluster e un argomento con l'archiviazione a più livelli abilitata, consulta la sezione [Creazione di un cluster con archiviazione a più livelli tramite la Console di gestione AWS](https://docs.aws.amazon.com//msk/latest/developerguide/msk-create-cluster-tiered-storage-console).
## Abilitazione dello storage su più livelli su un argomento esistente di Amazon MSK
Per abilitare l'archiviazione a più livelli su un argomento esistente, utilizza la sintassi del comando `alter` nell'esempio seguente. Quando abiliti l'archiviazione a più livelli su un argomento esistente, non è necessario utilizzare una determinata versione del client Apache Kafka.
```
bin/kafka-configs.sh --bootstrap-server $bsrv --alter --entity-type topics --entity-name msk-ts-topic --add-config 'remote.storage.enable=true, local.retention.ms=604800000, retention.ms=15550000000'
```
## Disabilitare lo storage su più livelli su un argomento esistente di Amazon MSK
Per disabilitare l'archiviazione a più livelli su un argomento esistente, utilizza la sintassi del comando `alter` nello stesso ordine con cui hai abilitato l'archiviazione a più livelli.
```
bin/kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name MSKTutorialTopic --add-config 'remote.log.msk.disable.policy=Delete, remote.storage.enable=false'
```
**Nota**
Quando si disabilita l'archiviazione a più livelli, si eliminano completamente i dati relativi all'argomento nell'archiviazione a più livelli. Apache Kafka conserva i dati dell'archiviazione primaria, ma applica comunque le regole di conservazione dell'archiviazione primaria in base a `local.retention.ms`. Una volta disabilitata l'archiviazione a più livelli su un argomento, non sarà possibile riabilitarla. Se desideri disabilitare l'archiviazione a più livelli su un argomento esistente, non è necessario utilizzare una determinata versione del client Apache Kafka.
# Abilita lo storage su più livelli su un cluster Amazon MSK esistente tramite CLI AWS
**Nota**
È possibile abilitare l'archiviazione a più livelli solo se la policy del cluster log.cleanup.policy è impostata su `delete`, poiché gli argomenti compatti non sono supportati nell'archiviazione a più livelli. Successivamente, puoi configurare la policy log.cleanup.policy di un singolo argomento su `compact` in modo che l'archiviazione a più livelli non sia abilitata su quel particolare argomento. Per maggiori dettagli sugli attributi di configurazione supportati, consulta la sezione [Configurazione a livello di argomento](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration).
1. **Aggiorna la versione di Kafka**: le versioni dei cluster non sono semplici numeri interi. Per trovare la versione corrente del cluster, utilizzare l'`DescribeCluster`operazione o il comando `describe-cluster` AWS CLI. Una versione di esempio è `KTVPDKIKX0DER`.
```
aws kafka update-cluster-kafka-version --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-kafka-version 3.6.0
```
1. Modifica la modalità di archiviazione del cluster. Nel seguente esempio di codice viene illustrato come modificare la modalità di archiviazione del cluster in `TIERED` tramite l'API [https://docs.aws.amazon.com/cli/latest/reference/kafka/update-storage.html](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-storage.html).
```
aws kafka update-storage --current-version Current-Cluster-Version --cluster-arn Cluster-arn --storage-mode TIERED
```
# Aggiorna lo storage su più livelli su un cluster Amazon MSK esistente utilizzando la console
Questo processo descrive come aggiornare un cluster Amazon MSK di storage su più livelli utilizzando il. Console di gestione AWS
Assicurati che la versione corrente di Apache Kafka del tuo cluster MSK sia la versione 2.8.2.tiered. Fai riferimento all'[aggiornamento della versione di Apache Kafka](https://docs.aws.amazon.com/msk/latest/developerguide/version-upgrades.html) se è necessario aggiornare il cluster MSK alla versione 2.8.2.tiered.
**Nota**
È possibile abilitare l'archiviazione a più livelli solo se la policy del cluster log.cleanup.policy è impostata su `delete`, poiché gli argomenti compatti non sono supportati nell'archiviazione a più livelli. Successivamente, puoi configurare la policy log.cleanup.policy di un singolo argomento su `compact` in modo che l'archiviazione a più livelli non sia abilitata su quel particolare argomento. Per maggiori dettagli sugli attributi di configurazione supportati, consulta la sezione [Configurazione a livello di argomento](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration).
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Vai alla pagina di riepilogo del cluster e scegli **Proprietà**.
1. Vai alla sezione **Archiviazione** e scegli **Modifica modalità di archiviazione del cluster**.
1. Scegli **Archiviazione a più livelli e archiviazione EBS** e **Salva modifiche**.
# Espandi lo storage dei broker Amazon MSK Standard
È possibile aumentare la quantità di storage EBS per broker. Non è possibile ridurre lo storage.
I volumi di storage rimangono disponibili durante questa operazione di dimensionamento.
**Importante**
Quando l'archiviazione viene dimensionata per un cluster MSK, l'archiviazione aggiuntiva viene resa disponibile immediatamente. Tuttavia, il cluster richiede un periodo di raffreddamento dopo ogni evento di dimensionamento dell'archiviazione. Amazon MSK utilizza questo periodo di raffreddamento per ottimizzare il cluster prima di un successivo nuovo dimensionamento. Questo periodo può variare da un minimo di 6 ore a più di 24 ore, a seconda delle dimensioni e dell'utilizzo dell'archiviazione del cluster e del traffico. Ciò è applicabile sia agli eventi di ridimensionamento automatico che al ridimensionamento manuale utilizzando l'[UpdateBrokerStorage](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes-storage.html#UpdateBrokerStorage)operazione. Per informazioni sul corretto dimensionamento dell'archiviazione, consulta la sezione [Le migliori pratiche per i broker standard](bestpractices.md).
Puoi utilizzare l'archiviazione a più livelli per aumentare fino a quantità illimitate lo spazio di archiviazione per il broker. Per informazioni, consultare [Storage su più livelli per broker Standard](msk-tiered-storage.md).
**Topics**
+ [Scalabilità automatica per i cluster Amazon MSK](msk-autoexpand.md)
+ [Ridimensionamento manuale per broker Standard](manually-expand-storage.md)
# Scalabilità automatica per i cluster Amazon MSK
Per espandere automaticamente l'archiviazione del cluster in risposta a un maggiore utilizzo, puoi configurare una policy di dimensionamento automatico dell'applicazione per Amazon MSK. In una policy di dimensionamento automatico, si imposta l'utilizzo del disco di destinazione e la capacità di dimensionamento massima.
Prima di utilizzare il dimensionamento automatico per Amazon MSK, è consigliabile tenere in considerazione quanto segue:
+
**Importante**
Un'operazione di dimensionamento dell'archiviazione può avvenire solo una volta ogni sei ore.
Ti consigliamo di iniziare con un volume di archiviazione della dimensione giusta per le tue esigenze di archiviazione. Per indicazioni sul corretto dimensionamento del cluster, consulta la pagina [Dimensiona correttamente il tuo cluster: numero di broker Standard per cluster](bestpractices.md#brokers-per-cluster).
+ Amazon MSK non riduce lo spazio di archiviazione del cluster in risposta a un utilizzo ridotto. Amazon MSK non supporta la riduzione delle dimensioni dei volumi di archiviazione. Se è necessario ridurre le dimensioni dell'archiviazione del cluster, è necessario migrare il cluster esistente in un cluster con un'archiviazione più piccola. Per ulteriori informazioni sulla migrazione di un cluster, consulta la pagina [Esegui la migrazione al cluster MSK](migration.md).
+ Amazon MSK non supporta la scalabilità automatica nelle regioni Asia Pacifico (Osaka), Africa (Città del Capo) e Asia Pacifico (Malesia).
+ Quando associ una politica di auto-scaling al tuo cluster, Amazon EC2 Auto Scaling crea automaticamente un allarme Amazon per il tracciamento degli obiettivi. CloudWatch Se si elimina un cluster con una politica di auto-scaling, CloudWatch questo allarme persiste. Per eliminare l' CloudWatch allarme, è necessario rimuovere una politica di auto-scaling da un cluster prima di eliminare il cluster. Per ulteriori informazioni sul monitoraggio degli obiettivi, consulta la pagina [Target tracking scaling policies for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html) nella *Guida per l'utente di Dimensionamento automatico Amazon EC2*.
**Topics**
+ [Dettagli della politica di ridimensionamento automatico per Amazon MSK](msk-autoexpand-details.md)
+ [Configura il ridimensionamento automatico per il tuo cluster Amazon MSK](msk-autoexpand-setup.md)
# Dettagli della politica di ridimensionamento automatico per Amazon MSK
Una policy di dimensionamento automatico definisce i seguenti parametri predefiniti per il cluster:
+ **Obiettivo di utilizzo dell'archiviazione**: la soglia di utilizzo dell'archiviazione utilizzata da Amazon MSK per attivare un'operazione di dimensionamento automatico. È possibile impostare l'obiettivo di utilizzo tra il 10% e l'80% della capacità di archiviazione corrente. Consigliamo di impostare l'obiettivo di utilizzo dell'archiviazione tra il 50% e il 60%.
+ **Capacità massima di archiviazione**: il limite di scalabilità massimo che Amazon MSK può impostare per l'archiviazione del broker. È possibile impostare la capacità di archiviazione massima fino a 16 TiB per broker. Per ulteriori informazioni, consulta [Quota di Amazon MSK](limits.md).
Quando Amazon MSK rileva che il parametro `Maximum Disk Utilization` è uguale o superiore all'impostazione `Storage Utilization Target`, aumenta la capacità di archiviazione di una quantità pari al più grande tra due numeri: 10 GiB o il 10% dell'archiviazione corrente. Ad esempio, se hai 1.000 GiB, tale quantità è 100 GiB. Il servizio verifica l'utilizzo dell'archiviazione ogni minuto. Ulteriori operazioni di dimensionamento continuano ad aumentare l'archiviazione di una quantità pari al più grande tra due numeri: 10 GiB o il 10% dell'archiviazione corrente.
Per determinare se sono state eseguite operazioni di auto-scaling, utilizzare l'operazione. [ ListClusterOperations](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-operations.html#ListClusterOperations)
# Configura il ridimensionamento automatico per il tuo cluster Amazon MSK
Puoi utilizzare la console Amazon MSK, l'API Amazon MSK o implementare il ridimensionamento automatico CloudFormation per lo storage. CloudFormation il supporto è disponibile tramite. [Application Auto Scaling](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html)
**Nota**
Non è possibile implementare il dimensionamento automatico al momento della creazione di un cluster. È necessario innanzitutto creare il cluster, quindi creare e abilitare una policy di dimensionamento automatico per il cluster. Tuttavia, puoi creare la policy mentre il servizio Amazon MSK crea il tuo cluster.
**Topics**
+ [Configura il ridimensionamento automatico utilizzando Amazon MSK Console di gestione AWS](msk-autoexpand-setup-console.md)
+ [Configura il ridimensionamento automatico utilizzando la CLI](msk-autoexpand-setup-cli.md)
+ [Configura la scalabilità automatica per Amazon MSK utilizzando l'API](msk-autoexpand-setup-api.md)
# Configura il ridimensionamento automatico utilizzando Amazon MSK Console di gestione AWS
Questo processo descrive come utilizzare la console Amazon MSK per implementare la scalabilità automatica per lo storage.
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Nell'elenco di cluster, scegli il tuo cluster. Questa operazione ti reindirizzerà a una pagina che elenca i dettagli sul cluster.
1. Nella sezione **Dimensionamento automatico per l'archiviazione**, scegli **Configura**.
1. Crea e assegna un nome a una policy di dimensionamento automatico. Specifica l'obiettivo di utilizzo dell'archiviazione, la capacità massima di archiviazione e il parametro obiettivo.
1. Scegli `Save changes`.
Quando salvi e abiliti la nuova policy, la policy diventa attiva per il cluster. Quando viene raggiunto l'obiettivo di utilizzo dell'archiviazione, Amazon MSK espande l'archiviazione del cluster.
# Configura il ridimensionamento automatico utilizzando la CLI
Questo processo descrive come utilizzare la CLI di Amazon MSK per implementare la scalabilità automatica per lo storage.
1. Usa il [ RegisterScalableTarget](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/#available-commands)comando per registrare un obiettivo di utilizzo dello storage.
1. Usa il [ PutScalingPolicy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/#available-commands)comando per creare una politica di espansione automatica.
# Configura la scalabilità automatica per Amazon MSK utilizzando l'API
Questo processo descrive come utilizzare l'API Amazon MSK per implementare la scalabilità automatica per lo storage.
1. Utilizza l'[ RegisterScalableTarget](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_RegisterScalableTarget.html)API per registrare un obiettivo di utilizzo dello storage.
1. Utilizza l'[ PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html)API per creare una politica di espansione automatica.
# Ridimensionamento manuale per broker Standard
Per incrementare lo storage, attendere che lo stato del cluster diventi `ACTIVE`. Il dimensionamento dell'archiviazione prevede un periodo di raffreddamento di almeno sei ore tra un evento e l'altro. Anche se l'operazione rende immediatamente disponibile spazio di archiviazione aggiuntivo, il servizio esegue ottimizzazioni sul cluster che possono richiedere fino a 24 ore o più. La durata di queste ottimizzazioni è proporzionale alla dimensione dell'archiviazione.
## Scalabilità dello spazio di archiviazione dei broker utilizzando il Console di gestione AWS
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Scegli il cluster MSK per cui desideri aggiornare lo spazio di archiviazione del broker.
1. Nella sezione **Archiviazione**, scegli **Modifica**.
1. Specifica il volume di storage desiderato. La quantità di storage può essere solo aumentata, non diminuita.
1. Scegli **Save changes** (Salva modifiche).
## Scalabilità dello storage dei broker utilizzando il AWS CLI
Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) che hai ottenuto quando hai creato il cluster. Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per ulteriori informazioni, consulta [Elenca i cluster Amazon MSK](msk-list-clusters.md).
Sostituiscilo *Current-Cluster-Version* con la versione corrente del cluster.
**Importante**
Le versioni del cluster non sono interi semplici. Per trovare la versione corrente del cluster, usa l'[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)operazione o il comando [AWS CLI describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html). Una versione di esempio è `KTVPDKIKX0DER`.
Il *Target-Volume-in-GiB* parametro rappresenta la quantità di spazio di archiviazione che desideri assegnare a ciascun broker. È consentito aggiornare lo storage solo per tutti i broker. Non è possibile specificare singoli broker per i quali aggiornare lo storage. Il valore specificato *Target-Volume-in-GiB* deve essere un numero intero maggiore di 100 GiB. Lo storage per broker dopo l'operazione di aggiornamento non può superare 16384 GiB.
```
aws kafka update-broker-storage --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-broker-ebs-volume-info '{"KafkaBrokerNodeId": "All", "VolumeSizeGB": Target-Volume-in-GiB}'
```
## Aumento delle dimensioni dello spazio di archiviazione del broker tramite l'API
Per aggiornare lo storage di un broker utilizzando l'API, consulta [UpdateBrokerStorage](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-nodes-storage.html#UpdateBrokerStorage).
# Gestisci il throughput di storage per i broker Standard in un cluster Amazon MSK
Per informazioni su come fornire la velocità effettiva utilizzando la console, la CLI e l'API di Amazon MSK, consulta. [Esegui il provisioning del throughput di storage per i broker Standard in un cluster Amazon MSK](msk-provision-throughput.md)
**Topics**
+ [Problemi di throughput del broker Amazon MSK e impostazioni di throughput massimo](#throughput-bottlenecks)
+ [Misura il throughput di storage di un cluster Amazon MSK](#throughput-metrics)
+ [Valori di aggiornamento della configurazione per lo storage assegnato in un cluster Amazon MSK](#provisioned-throughput-config)
+ [Esegui il provisioning del throughput di storage per i broker Standard in un cluster Amazon MSK](msk-provision-throughput.md)
## Problemi di throughput del broker Amazon MSK e impostazioni di throughput massimo
I colli di bottiglia nella velocità di trasmissione effettiva dei broker sono dovuti a molteplici cause: velocità di trasmissione effettiva del volume, velocità di trasmissione effettiva della rete da Amazon EC2 ad Amazon EBS e velocità di trasmissione effettiva in uscita di Amazon EC2. È possibile abilitare la velocità di trasmissione effettiva assegnata per regolare la velocità di trasmissione effettiva del volume. Tuttavia, le limitazioni della velocità di trasmissione effettiva del broker possono essere causate dalla velocità di trasmissione effettiva della rete da Amazon EC2 ad Amazon EBS e dalla velocità di trasmissione effettiva in uscita di Amazon EC2.
La velocità di trasmissione effettiva in uscita di Amazon EC2 è influenzata dal numero di gruppi di consumatori e dal numero di consumatori per ciascun gruppo. Inoltre, sia il throughput di rete da Amazon EC2 ad Amazon EBS che il throughput di uscita di Amazon EC2 sono più elevati per broker di grandi dimensioni.
Per volumi di dimensioni pari o superiori a 10 GiB, è possibile assegnare una velocità di trasmissione effettiva dell'archiviazione pari o superiore a 250 MiB al secondo. L'impostazione predefinita è 250 MiB al secondo. Per effettuare il provisioning del throughput di storage, devi scegliere la dimensione del broker kafka.m5.4xlarge o superiore (oppure kafka.m7g.2xlarge o superiore) e puoi specificare il throughput massimo come mostrato nella tabella seguente.
****
| dimensione del broker | Velocità di trasmissione effettiva massima (MiB/secondo) |
| --- | --- |
| kafka.m5.4xlarge | 593 |
| kafka.m5.8xlarge | 850 |
| kafka.m5.12xlarge | 1000 |
| kafka.m5.16xlarge | 1000 |
| kafka.m5.24xlarge | 1000 |
| kafka.m7 g. 2 x grande | 312,5 |
| kafka.m7g.4xlarge | 625 |
| kafka.m7g.8xlarge | 1000 |
| kafka.m7g. 12 x grande | 1000 |
| kafka.m7g. 16 x grande | 1000 |
## Misura il throughput di storage di un cluster Amazon MSK
È possibile utilizzare i parametri `VolumeReadBytes` e `VolumeWriteBytes` per misurare la velocità di trasmissione effettiva media di archiviazione di un cluster. La somma di questi due parametri fornisce la velocità di trasmissione effettiva media dell'archiviazione espressa in byte. Per ottenere la velocità di trasmissione effettiva media dell'archiviazione per un cluster, imposta questi due parametri su SUM e il periodo su 1 minuto, quindi utilizza la formula seguente.
```
Average storage throughput in MiB/s = (Sum(VolumeReadBytes) + Sum(VolumeWriteBytes)) / (60 * 1024 * 1024)
```
Per ulteriori informazioni sui parametri `VolumeReadBytes` e `VolumeWriteBytes`, consulta la sezione [Monitoraggio del livello `PER_BROKER`](metrics-details.md#broker-metrics).
## Valori di aggiornamento della configurazione per lo storage assegnato in un cluster Amazon MSK
Puoi aggiornare la configurazione di Amazon MSK prima o dopo aver attivato la velocità di trasmissione effettiva assegnata. Tuttavia, non vedrai la velocità di trasmissione effettiva desiderata finché non eseguirai entrambe le operazioni: aggiornare il parametro di configurazione `num.replica.fetchers` e attivare la velocità di trasmissione effettiva assegnata.
Nella configurazione predefinita di Amazon MSK, `num.replica.fetchers` ha un valore di 2. Per aggiornare il `num.replica.fetchers`, puoi utilizzare i valori suggeriti dalla tabella seguente. Questi valori sono forniti a scopo indicativo. Si consiglia di modificare questi valori in base al proprio caso d'uso.
****
| dimensione del broker | num.replica.fetchers |
| --- | --- |
| kafka.m5.4xlarge | 4 |
| kafka.m5.8xlarge | 8 |
| kafka.m5.12xlarge | 14 |
| kafka.m5.16xlarge | 16 |
| kafka.m5.24xlarge | 16 |
La configurazione aggiornata potrebbe non avere effetto per un massimo di 24 ore e potrebbe richiedere più tempo quando un volume sorgente non è completamente utilizzato. Tuttavia, le prestazioni dei volumi di transizione sono almeno uguali a quelle dei volumi di archiviazione di origine durante il periodo di migrazione. Un volume da 1 TiB completamente utilizzato richiede in genere circa sei ore per migrare a una configurazione aggiornata.
# Esegui il provisioning del throughput di storage per i broker Standard in un cluster Amazon MSK
I broker Amazon MSK mantengono i dati sui volumi di archiviazione. Lo storage I/O viene utilizzato quando i produttori scrivono nel cluster, quando i dati vengono replicati tra broker e quando i consumatori leggono dati che non sono in memoria. La velocità di trasmissione effettiva dell'archiviazione del volume è la velocità con cui i dati possono essere scritti e letti da un volume di archiviazione. La velocità di trasmissione effettiva dell'archiviazione assegnata è la capacità di specificare tale velocità per i broker del cluster.
È possibile specificare la velocità di throughput assegnata in MiB al secondo per i cluster i cui broker sono di dimensioni `kafka.m5.4xlarge` o superiori e se il volume di storage è pari o superiore a 10 GiB. È possibile specificare la velocità di trasmissione effettiva assegnata durante la creazione del cluster. Inoltre, è possibile abilitare o disabilitare la velocità di trasmissione effettiva assegnata per un cluster che si trova nello stato `ACTIVE`.
Per informazioni sulla gestione della velocità effettiva, vedere. [Gestisci il throughput di storage per i broker Standard in un cluster Amazon MSK](msk-provision-throughput-management.md)
**Topics**
+ [Effettua il provisioning del throughput di storage del cluster Amazon MSK utilizzando Console di gestione AWS](#provisioned-throughput-console)
+ [Effettua il provisioning del throughput di storage del cluster Amazon MSK utilizzando AWS CLI](#provisioned-throughput-cli)
+ [Esegui il provisioning del throughput di storage durante la creazione di un cluster Amazon MSK utilizzando l'API](#provisioned-throughput-api)
## Effettua il provisioning del throughput di storage del cluster Amazon MSK utilizzando Console di gestione AWS
Questo processo mostra un esempio di come è possibile utilizzare il Console di gestione AWS per creare un cluster Amazon MSK con throughput assegnato abilitato.
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Scegli **Crea cluster**.
1. Scegli **Creazione personalizzata**.
1. Specificare un nome per il cluster.
1. Nella sezione **Archiviazione**, scegli **Abilita**.
1. Scegli un valore per la velocità di trasmissione effettiva dell'archiviazione per broker.
1. Scegli un VPC, zone e sottoreti, nonché un gruppo di sicurezza.
1. Scegli **Next (Successivo)**.
1. Nella parte inferiore del passaggio **Sicurezza**, scegli **Avanti**.
1. Nella parte inferiore del passaggio **Monitoraggio e tag**, scegli **Avanti**.
1. Verifica le impostazioni del cluster, quindi scegli **Crea cluster**.
## Effettua il provisioning del throughput di storage del cluster Amazon MSK utilizzando AWS CLI
Questo processo mostra un esempio di come è possibile utilizzare il AWS CLI per creare un cluster con il throughput assegnato abilitato.
1. Copia il codice JSON seguente e incollalo in un file. Sostituisci i segnaposto dell'ID della sottorete IDs e del gruppo di sicurezza con i valori del tuo account. Assegna al file il nome `cluster-creation.json` e salvalo.
```
{
"Provisioned": {
"BrokerNodeGroupInfo":{
"InstanceType":"kafka.m5.4xlarge",
"ClientSubnets":[
"Subnet-1-ID",
"Subnet-2-ID"
],
"SecurityGroups":[
"Security-Group-ID"
],
"StorageInfo": {
"EbsStorageInfo": {
"VolumeSize": 10,
"ProvisionedThroughput": {
"Enabled": true,
"VolumeThroughput": 250
}
}
}
},
"EncryptionInfo": {
"EncryptionInTransit": {
"InCluster": false,
"ClientBroker": "PLAINTEXT"
}
},
"KafkaVersion":"2.8.1",
"NumberOfBrokerNodes": 2
},
"ClusterName": "provisioned-throughput-example"
}
```
1. Esegui il AWS CLI comando seguente dalla directory in cui hai salvato il file JSON nel passaggio precedente.
```
aws kafka create-cluster-v2 --cli-input-json file://cluster-creation.json
```
## Esegui il provisioning del throughput di storage durante la creazione di un cluster Amazon MSK utilizzando l'API
[Per configurare il throughput di storage assegnato durante la creazione di un cluster, usa V2. CreateCluster](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2)
# Configurazione Amazon MSK Provisioned
Amazon MSK fornisce configurazioni predefinite per broker, argomenti e nodi di metadati. Puoi inoltre creare configurazioni personalizzate e utilizzarle per creare nuovi cluster MSK o per aggiornare cluster esistenti. Una configurazione MSK è costituita da un insieme di proprietà e dai relativi valori corrispondenti. A seconda del tipo di broker utilizzato nel cluster, esistono diversi set di impostazioni predefinite di configurazione e un diverso set di configurazioni che è possibile modificare. Consulta le sezioni seguenti per maggiori dettagli su come configurare i broker Standard ed Express.
**Topics**
+ [Configurazioni standard del broker](msk-configuration-standard.md)
+ [Configurazioni del broker Express](msk-configuration-express.md)
+ [Operazioni di configurazione del broker](msk-configuration-operations.md)
# Configurazioni standard del broker
Questa sezione descrive le proprietà di configurazione per i broker Standard.
**Topics**
+ [Configurazioni Amazon MSK personalizzate](msk-configuration-properties.md)
+ [Configurazione Amazon MSK predefinita](msk-default-configuration.md)
+ [Linee guida per la configurazione a livello di argomento dello storage su più livelli di Amazon MSK](msk-guidelines-tiered-storage-topic-level-config.md)
# Configurazioni Amazon MSK personalizzate
Puoi usare Amazon MSK per creare una configurazione MSK personalizzata in cui impostare le seguenti proprietà di configurazione di Apache Kafka. Le proprietà che non vengono impostate in modo esplicito ricevono i valori che hanno in [Configurazione Amazon MSK predefinita](msk-default-configuration.md). Per ulteriori informazioni sulle proprietà di configurazione, consulta la pagina relativa alla [configurazione di Apache Kafka](https://kafka.apache.org/documentation/#configuration).
| Nome | Description |
| --- | --- |
| allow.everyone.if.no.acl.found | Se desideri impostare questa proprietà sufalse, assicurati innanzitutto di definire Apache Kafka per il tuo cluster. ACLs Se imposti questa proprietà su false e non definisci prima Apache Kafka ACLs, perdi l'accesso al cluster. In tal caso, puoi aggiornare nuovamente la configurazione e impostare questa proprietà su true per ottenere nuovamente l'accesso al cluster. |
| auto.create.topics.enable | Abilita la creazione automatica di argomenti sul server. |
| compression.type | Il tipo di compressione finale per un determinato argomento. Puoi impostare questa proprietà sui codec di compressione standard (gzip, snappy, lz4 e zstd). Inoltre, accetta uncompressed. Questo valore equivale a nessuna compressione. Se imposti il valore su producer, significa mantenere il codec di compressione originale impostato dal produttore. |
| connections.max.idle.ms | Timeout delle connessioni inattive in millisecondi. I thread del processore dei socket del server chiudono le connessioni inattive per un periodo superiore al valore impostato per questa proprietà. |
| default.replication.factor | Il fattore di replica predefinito per argomenti creati automaticamente. |
| delete.topic.enable | Abilita l'operazione di eliminazione argomento. Se questa configurazione è disattivata, non è possibile eliminare un argomento tramite lo strumento di amministrazione. |
| group.initial.rebalance.delay.ms | Il tempo durante il quale il coordinatore del gruppo attende che altri consumatori si uniscano a un nuovo gruppo prima di eseguire il primo ribilanciamento. Un ritardo più lungo significa potenzialmente meno ribilanciamenti, ma aumenta il tempo prima dell'inizio dell'elaborazione. |
| group.max.session.timeout.ms | Timeout sessione massimo per i consumatori registrati. Timeout più lunghi offrono ai consumatori più tempo per elaborare i messaggi tra heartbeat, ma implicano un aumento del tempo richiesto per rilevare gli errori. |
| group.min.session.timeout.ms | Timeout sessione minimo per consumatori registrati. Timeout più brevi comportano un rilevamento più rapido degli errori, ma implicano un heartbeat dei consumatori più frequente. Ciò può sovraccaricare le risorse del broker. |
| leader.imbalance.per.broker.percentage | Il rapporto di squilibrio leader consentito per broker. Il controller attiva un bilanciamento dei leader se supera questo valore per broker. Questo valore è specificato in percentuale. |
| log.cleaner.delete.retention.ms | Quantità di tempo per cui Apache Kafka deve conservare i record eliminati. Il valore minimo è 0. |
| log.cleaner.min.cleanable.ratio | Questa proprietà di configurazione può avere valori compresi tra 0 e 1. Questo valore determina la frequenza con cui il compattatore di log tenta di pulire il log (se la compattazione dei log è abilitata). Per impostazione predefinita, Apache Kafka evita di pulire un log se più del 50% del log è stato compattato. Questo rapporto limita lo spazio massimo che il log spreca con i duplicati (al 50%, ciò significa che al massimo il 50% del log potrebbe essere duplicato). Un rapporto più elevato significa un numero inferiore, pulizie più efficienti, ma anche più spreco di spazio nel log. |
| log.cleanup.policy | La policy di pulizia predefinita per i segmenti oltre la finestra di conservazione. Un elenco separato da virgole di policy valide. Policy valide sono delete e compact. Per i cluster abilitati all'archiviazione a più livelli, è valida solo la policy delete. |
| log.flush.interval.messages | Numero di messaggi che si accumulano in una partizione di log prima che i messaggi vengano scaricati su disco. |
| log.flush.interval.ms | Tempo massimo, in millisecondi, di mantenimento in memoria di un messaggio in un argomento prima che venga scaricato su disco. Se questo valore non viene impostato, viene utilizzato il valore in log.flush.scheduler.interval.ms. Il valore minimo è 0. |
| log.message.timestamp.difference.max.ms | Questa configurazione è obsoleta in Kafka 3.6.0. Sono state aggiunte due configurazioni, e. log.message.timestamp.before.max.ms log.message.timestamp.after.max.ms La differenza massima consentita tra il timestamp del momento in cui un broker riceve un messaggio e il timestamp specificato nel messaggio. Se log.message.timestamp.type=CreateTime, un messaggio viene rifiutato se la differenza di timestamp supera questa soglia. Questa LogAppendTime configurazione viene ignorata se log.message.timestamp.type=. |
| log.message.timestamp.type | Specifica se il timestamp nel messaggio è l'ora di creazione del messaggio o l'ora di aggiunta del log. I valori consentiti sono CreateTime e LogAppendTime. |
| log.retention.bytes | Dimensione massima del log prima dell'eliminazione. |
| log.retention.hours | Numero di ore per cui mantenere un file di log prima di eliminarlo, terziario alla proprietà log.retention.ms. |
| log.retention.minutes | Numero di minuti per cui mantenere un file di log prima di eliminarlo, secondario alla proprietà log.retention.ms. Se questo valore non viene impostato, viene utilizzato il valore in log.retention.hours. |
| log.retention.ms | Numero di millisecondi per cui mantenere un file di log prima di eliminarlo. Se non è impostato, viene utilizzato il valore in log.retention.minutes. |
| log.roll.ms | Tempo massimo prima che un nuovo segmento di log venga distribuito (in millisecondi). Se questo valore non viene impostato, viene utilizzato il valore in log.roll.hours. Il valore minimo possibile per questa proprietà è 1. |
| log.segment.bytes | Dimensione massima di un singolo file di log. |
| max.incremental.fetch.session.cache.slots | Numero massimo di sessioni di recupero incrementali che vengono mantenute. |
| message.max.bytes | Dimensione massima del batch di record consentita da Kafka. Se aumenti questo valore e sono presenti consumatori più vecchi di 0.10.2, anche le dimensioni di recupero dei consumatori devono essere incrementate in modo che possano recuperare batch di record di queste dimensioni. Nella versione più recente del formato del messaggio, i messaggi vengono sempre raggruppati in batch per maggiore efficienza. Nelle versioni precedenti del formato del messaggio, i record non compressi non sono raggruppati in batch; in tal caso, questo limite si applica solo a un singolo record. Questo valore può essere impostato a livello di argomento con la configurazione max.message.bytes. |
| min.insync.replicas | Quando un produttore imposta le ACK su `"all"` (o `"-1"`), il valore in min.insync.replicas specifica il numero minimo di repliche che devono riconoscere una scrittura affinché questa sia considerata correttamente completata. Se questo minimo non può essere raggiunto, il produttore solleva un'eccezione (o). NotEnoughReplicas NotEnoughReplicasAfterAppend È possibile utilizzare i valori in min.insync.replicas e ACK per applicare maggiori garanzie di durabilità. Ad esempio, è possibile creare un argomento con un fattore di replica di 3, impostare min.insync.replicas su 2 e produrre con ACK di `"all"`. Ciò garantisce che il produttore generi un'eccezione se la maggior parte delle repliche non riceve una scrittura. |
| num.io.thread | Il numero di thread utilizzati dal server per elaborare le richieste, che possono includere I/O del disco. |
| num.network.threads | Il numero di thread utilizzati dal server per ricevere richieste dalla rete e inviarle le risposte. |
| num.partitions | Numero predefinito di partizioni di log per argomento. |
| num.recovery.threads.per.data.dir | Il numero di thread per directory di dati da utilizzare per il ripristino dei log all'avvio e per lo scaricamento all'arresto. |
| num.replica.fetchers | Il numero di thread fetcher utilizzati per rispondere ai messaggi da un broker di origine. Se aumenti questo valore, puoi aumentare il grado di I/O parallelismo nel broker di follower. |
| offsets.retention.minutes | Dopo che un gruppo di consumatori perde tutti i suoi consumatori (ovvero, diventa vuoto) i suoi offset vengono mantenuti per questo periodo di conservazione prima di essere scartati. Per i consumatori autonomi (ossia che utilizzano l'assegnazione manuale), gli offset scadono dopo l'ora dell'ultimo commit più questo periodo di conservazione. |
| offsets.topic.replication.factor | Il fattore di replica per l'argomento di offset. La selezione di un valore più alto garantisce la disponibilità. La creazione di argomenti interni non riesce fino a quando la dimensione del cluster non soddisfa questo requisito del fattore di replica. |
| replica.fetch.max.bytes | Numero di byte di messaggi da recuperare per ogni partizione. Questo valore non è un massimo assoluto. Se il primo batch di record nella prima partizione non vuota del recupero è più grande di questo valore, viene restituito il batch di record per garantire l'avanzamento. La proprietà message.max.bytes (configurazione broker) o max.message.bytes (configurazione argomento) specifica la dimensione massima del batch di record accettata dal broker. |
| replica.fetch.response.max.bytes | Il numero massimo di byte previsto per l'intera risposta di recupero. I record vengono recuperati in batch. Se il primo batch di record nella prima partizione non vuota del recupero è più grande di questo valore, il batch di record verrà comunque restituito per garantire l'avanzamento. Questo non è un massimo assoluto. Le proprietà message.max.bytes (configurazione broker) o max.message.bytes (configurazione argomento) specificano la dimensione massima del batch di record accettata dal broker. |
| replica.lag.time.max.ms | Se un follower non ha inviato richieste di fetch o non ha consumato fino all'offset di fine log del leader per almeno questo numero di millisecondi, il leader rimuove il follower dall'ISR.MinValue: 10000MaxValue = 30000 |
| replica.selector.class | Il nome completo della classe che implementa. ReplicaSelector Il broker utilizza questo valore per trovare la replica di lettura preferita. Se utilizzi Apache Kafka versione 2.4.1 o superiore e desideri consentire ai consumatori di recuperare dati dalla replica più vicina, imposta questa proprietà su org.apache.kafka.common.replica.RackAwareReplicaSelector. Per ulteriori informazioni, consulta [Apache Kafka versione 2.4.1 (usa invece 2.4.1.1)](supported-kafka-versions.md#2.4.1). |
| replica.socket.receive.buffer.bytes | Il buffer di ricezione socket per le richieste di rete. |
| socket.receive.buffer.bytes | Buffer SO\$1RCVBUF dei socket del server dei socket. Il valore minimo che è possibile impostare per questa proprietà è -1. Se il valore è -1, Amazon MSK utilizza il sistema operativo predefinito. |
| socket.request.max.bytes | Il numero massimo di byte in una richiesta socket. |
| socket.send.buffer.bytes | Buffer SO\$1SNDBUF dei socket del server dei socket. Il valore minimo che è possibile impostare per questa proprietà è -1. Se il valore è -1, Amazon MSK utilizza il sistema operativo predefinito. |
| transaction.max.timeout.ms | Timeout massimo per transazioni. Se il tempo di transazione richiesto da un cliente supera questo valore, il broker restituisce un errore in. InitProducerIdRequest Ciò evita un timeout troppo elevato per un client, che può rallentare i consumatori che leggono dagli argomenti inclusi nella transazione. |
| transaction.state.log.min.isr | Configurazione min.insync.replicas ignorata per l'argomento di transazione. |
| transaction.state.log.replication.factor | Il fattore di replica per l'argomento di transazione. La selezione di un valore più alto per questa proprietà aumenta la disponibilità. La creazione di argomenti interni non riesce fino a quando la dimensione del cluster non soddisfa questo requisito del fattore di replica. |
| transactional.id.expiration.ms | Il tempo in millisecondi durante il quale il coordinatore della transazione attende di ricevere eventuali aggiornamenti sullo stato delle transazioni per la transazione corrente prima che il coordinatore faccia scadere il proprio ID transazionale. Questa impostazione influenza anche la scadenza dell'ID del produttore perché fa IDs scadere il produttore quando questo tempo trascorre dopo l'ultima scrittura con l'ID produttore specificato. Producer IDs potrebbe scadere prima se l'ultima scrittura dall'ID produttore viene eliminata a causa delle impostazioni di conservazione dell'argomento. Il valore minimo per questa proprietà è 1 millisecondo. |
| unclean.leader.election.enable | Indica se le repliche non incluse nel set ISR devono fungere da leader come ultima risorsa, anche se ciò potrebbe comportare la perdita di dati. |
| zookeeper.connection.timeout.ms | ZooKeeper cluster di modalità. Tempo massimo di attesa del client per stabilire una connessione. ZooKeeper Se questo valore non viene impostato, viene utilizzato il valore fornito in zookeeper.session.timeout.ms. MinValue = 6000 MaxValue (incluso) = 18000 Ti consigliamo di impostare questo valore su 10.000 su T3.small per evitare tempi di inattività del cluster. |
| zookeeper.session.timeout.ms | ZooKeeper cluster di modalità. Il timeout della ZooKeeper sessione Apache in millisecondi. MinValue = 6000 MaxValue (incluso) = 18000 |
Per informazioni su come creare una configurazione MSK personalizzata, elencare tutte le configurazioni o descriverle, consulta [Operazioni di configurazione del broker](msk-configuration-operations.md). Per creare un cluster MSK utilizzando una configurazione MSK personalizzata o per aggiornare un cluster con una nuova configurazione personalizzata, consulta la pagina [Caratteristiche e concetti chiave di Amazon MSK](operations.md).
Quando si aggiorna il cluster MSK esistente con una configurazione MSK personalizzata, Amazon MSK esegue riavvii in sequenza quando necessario e utilizza le best practice per ridurre al minimo i tempi di inattività del cliente. Ad esempio, dopo aver riavviato ogni broker, Amazon MSK prova a lasciare che il broker recuperi i dati che potrebbe aver perso durante l'aggiornamento della configurazione prima di passare al broker successivo.
## Configurazione dinamica di Amazon MSK
Oltre alle proprietà di configurazione fornite da Amazon MSK, puoi impostare dinamicamente le proprietà di configurazione a livello di cluster e broker che non richiedono un riavvio del broker. È possibile impostare dinamicamente alcune proprietà di configurazione. Si tratta delle proprietà che non sono contrassegnate come di sola lettura nella tabella in [Broker Configs](https://kafka.apache.org/documentation/#brokerconfigs) nella documentazione di Apache Kafka. Per informazioni sulla configurazione dinamica e sui comandi di esempio, consulta la pagina [Updating Broker Configs](https://kafka.apache.org/documentation/#dynamicbrokerconfigs) nella documentazione di Apache Kafka.
**Nota**
Puoi impostare la proprietà `advertised.listeners`, ma non la proprietà `listeners`.
## Configurazione Amazon MSK a livello di argomento
Puoi utilizzare i comandi Apache Kafka per impostare o modificare le proprietà di configurazione a livello dell'argomento per argomenti nuovi ed esistenti. Per ulteriori informazioni sulle proprietà di configurazione a livello di argomento ed esempi di come impostarle, consulta la pagina [Topic-Level Configs](https://kafka.apache.org/documentation/#topicconfigs) nella documentazione ufficiale di Apache Kafka.
# Configurazione Amazon MSK predefinita
Quando crei un cluster MSK senza specificare una configurazione MSK personalizzata, Amazon MSK crea e utilizza una configurazione predefinita con i valori visualizzati nella tabella seguente. Per le proprietà non presenti in questa tabella, Amazon MSK utilizza i valori predefiniti associati alla versione di Apache Kafka. Per un elenco di questi valori predefiniti, consulta la pagina relativa alla [configurazione di Apache Kafka](https://kafka.apache.org/documentation/#configuration).
| Nome | Description | Valore predefinito per il cluster con l'archiviazione non a più livelli | Valore predefinito per il cluster abilitato all'archiviazione a più livelli |
| --- | --- | --- | --- |
| allow.everyone.if.no.acl.found | Se nessun modello di risorsa corrisponde a una risorsa specifica, la risorsa non è associata ACLs. In questo caso, se questa proprietà è impostata su true, tutti possono accedere alla risorsa, non solo i superutenti. | true | true |
| auto.create.topics.enable | Abilita la creazione automatica di un argomento sul server. | false | false |
| auto.leader.rebalance.enable | Consente il bilanciamento leader automatico. Un thread in background controlla e attiva il bilanciamento del leader a intervalli regolari, se necessario. | true | true |
| default.replication.factor | Fattori di replica predefiniti per argomenti creati automaticamente. | 3 per i cluster in 3 zone di disponibilità e 2 per i cluster in 2 zone di disponibilità. | 3 per i cluster in 3 zone di disponibilità e 2 per i cluster in 2 zone di disponibilità. |
| local.retention.bytes | La dimensione massima dei segmenti di log locali per una partizione prima dell'eliminazione dei vecchi segmenti. Se questo valore non viene impostato, viene utilizzato il valore in log.retention.bytes. Il valore effettivo deve essere sempre minore o uguale al valore di log.retention.bytes. Il valore predefinito -2 indica che non è previsto un limite alla conservazione locale. Ciò corrisponde all'impostazione retention.ms/bytes di -1. Le proprietà local.retention.ms e local.retention.bytes sono simili a log.retention, in quanto vengono utilizzate per determinare per quanto tempo i segmenti di log devono rimanere nell'archiviazione locale. Le configurazioni log.retention.\$1 esistenti sono configurazioni di conservazione per la partizione degli argomenti. Ciò include l'archiviazione locale e remota. Valori validi: numeri interi in [-2; \$1Inf] | -2 per illimitato | -2 per illimitato |
| local.retention.ms | Numero di millisecondi di conservazione del segmento di log locale prima dell'eliminazione. Se questo valore non viene impostato, Amazon MSK utilizza il valore in log.retention.ms. Il valore effettivo deve essere sempre minore o uguale al valore di log.retention.bytes. Il valore predefinito -2 indica che non è previsto un limite alla conservazione locale. Ciò corrisponde all'impostazione retention.ms/bytes di -1.I valori local.retention.ms e local.retention.bytes sono simili a log.retention. MSK utilizza questa configurazione per determinare per quanto tempo i segmenti di log devono rimanere nell'archiviazione locale. Le configurazioni log.retention.\$1 esistenti sono configurazioni di conservazione per la partizione degli argomenti. Ciò include l'archiviazione locale e remota. I valori validi sono numeri interi maggiori di 0. | -2 per illimitato | -2 per illimitato |
| log.message.timestamp.difference.max.ms | Questa configurazione è obsoleta in Kafka 3.6.0. Sono state aggiunte due configurazioni, e. log.message.timestamp.before.max.ms log.message.timestamp.after.max.ms La differenza massima consentita tra il timestamp quando un broker riceve un messaggio e il timestamp specificato nel messaggio. Se log.message.timestamp.type=CreateTime, un messaggio verrà rifiutato se la differenza di timestamp supera questa soglia. Questa configurazione viene ignorata se log.message.timestamp.type=. LogAppendTime La differenza di timestamp massima consentita non deve essere maggiore di log.retention.ms per evitare una distribuzione dei log inutilmente frequente. | 9223372036854775807 | 86400000 per Kafka 2.8.2.tiered e Kafka 3.7.x a più livelli. |
| log.segment.bytes | Dimensione massima di un singolo file di log. | 1073741824 | 134217728 |
| min.insync.replicas | Quando un produttore imposta il valore delle ACK (il riconoscimento che il produttore riceve dal broker Kafka) su `"all"` (o `"-1"`), il valore in min.insync.replicas specifica il numero minimo di repliche che devono riconoscere una scrittura affinché questa sia considerata correttamente completata. Se questo valore non soddisfa questo minimo, il produttore solleva un'eccezione (o). NotEnoughReplicas NotEnoughReplicasAfterAppend Se usati insieme, i valori min.insync.replicas e ACK consentono di imporre maggiori garanzie di durata. Ad esempio, è possibile creare un argomento con un fattore di replica di 3, impostare min.insync.replicas su 2 e produrre con ACK di `"all"`. Ciò garantisce che il produttore generi un'eccezione se la maggior parte delle repliche non riceve una scrittura. | 2 per i cluster in 3 zone di disponibilità e 1 per i cluster in 2 zone di disponibilità. | 2 per i cluster in 3 zone di disponibilità e 1 per i cluster in 2 zone di disponibilità. |
| num.io.thread | Numero di thread utilizzati dal server per produrre le richieste, che possono includere l'I/O del disco. | 8 | max (8, vCPUs) dove v CPUs dipende dalla dimensione dell'istanza del broker |
| num.network.threads | Numero di thread utilizzati dal server per ricevere richieste dalla rete e inviare risposte alla rete. | 5 | max (5, vCPUs /2) dove v CPUs dipende dalla dimensione dell'istanza del broker |
| num.partitions | Numero predefinito di partizioni di log per argomento. | 1 | 1 |
| num.replica.fetchers | Numero di thread fetcher utilizzati per replicare i messaggi da un broker di origine. Se si aumenta questo valore, è possibile aumentare il grado di parallelismo nel broker di I/O follower. | 2 | max (2, vCPUs /4) dove v dipende dalla dimensione dell'istanza del broker CPUs |
| remote.log.msk.disable.policy | Utilizzato con remote.storage.enable per disabilitare l'archiviazione a più livelli. Imposta questa policy su Elimina per indicare che i dati nell'archiviazione a più livelli vengono eliminati quando si imposta remote.storage.enable su false. | N/D | Nessuno |
| remote.log.reader.threads | La dimensione del pool di thread del lettore di log remoto, utilizzato nella pianificazione delle attività per recuperare dati dall'archiviazione remota. | N/D | max (10, v CPUs \$1 0.67) dove v CPUs dipende dalla dimensione dell'istanza del broker |
| remote.storage.enable | Abilita l'archiviazione a più livelli (remota) per un argomento, se impostato su true. Disabilita l'archiviazione a più livelli a livello di argomento se impostato su false e remote.log.msk.disable.policy è impostato su Delete. Quando si disabilita l'archiviazione a più livelli, si eliminano i dati dall'archiviazione remota. Una volta disabilitata l'archiviazione a più livelli su un argomento, non sarà possibile riabilitarla. | false | false |
| replica.lag.time.max.ms | Se un follower non ha inviato richieste di fetch o non ha consumato fino all'offset di fine log del leader per almeno questo numero di millisecondi, il leader rimuove il follower dall'ISR. | 30000 | 30000 |
| retention.ms | Campo obbligatorio. Il tempo minimo è 3 giorni. Non esiste un'impostazione predefinita perché l'impostazione è obbligatoria. Amazon MSK utilizza il valore retention.ms con local.retention.ms per determinare quando i dati vengono spostati dall'archiviazione locale a quella a più livelli. Il valore local.retention.ms specifica quando spostare i dati dall'archiviazione locale a quella a più livelli. Il valore retention.ms specifica quando rimuovere i dati dallo storage su più livelli (ovvero, rimossi dal cluster). Valori validi: numeri interi in [-1; \$1Inf] | Minimo 259.200.000 millisecondi (3 giorni). -1 per una conservazione infinita. | Minimo 259.200.000 millisecondi (3 giorni). -1 per una conservazione infinita. |
| socket.receive.buffer.bytes | Buffer SO\$1RCVBUF dei socket del server dei socket. Se il valore è -1, viene utilizzato il sistema operativo predefinito. | 102400 | 102400 |
| socket.request.max.bytes | Numero massimo di byte in una richiesta socket. | 104857600 | 104857600 |
| socket.send.buffer.bytes | Buffer SO\$1SNDBUF dei socket del server dei socket. Se il valore è -1, viene utilizzato il sistema operativo predefinito. | 102400 | 102400 |
| unclean.leader.election.enable | Indica se desideri che le repliche non incluse nel set ISR fungano da leader come ultima risorsa, anche se ciò potrebbe comportare la perdita di dati. | true | false |
| zookeeper.session.timeout.ms | Il timeout della sessione Apache in millisecondi. ZooKeeper | 18000 | 18000 |
| zookeeper.set.acl | Il client impostato da usare secure. ACLs | false | false |
Per informazioni su come specificare valori di configurazione personalizzati, vedere[Configurazioni Amazon MSK personalizzate](msk-configuration-properties.md).
# Linee guida per la configurazione a livello di argomento dello storage su più livelli di Amazon MSK
Di seguito sono riportate le impostazioni e le limitazioni predefinite per la configurazione dell'archiviazione a più livelli a livello di argomento.
+ Amazon MSK non supporta segmenti di log di dimensioni inferiori per argomenti con l'archiviazione a più livelli attivata. Se si desidera creare un segmento, è prevista una dimensione minima del segmento di log di 48 MiB o un tempo minimo di distribuzione del segmento di 10 minuti. Questi valori sono mappati alle proprietà segment.bytes e segment.ms.
+ Il valore di local.retention. ms/bytes can't equal or exceed the retention.ms/bytes. Questa è l'impostazione di conservazione dell'archiviazione a più livelli.
+ Il valore predefinito per local.retention. ms/bytes is -2. This means that the retention.ms value is used for local.retention.ms/bytes. In questo caso, i dati rimangono sia nell'archiviazione locale sia nell'archiviazione a più livelli (una copia per ciascuna) e scadono insieme. Con questa opzione, una copia dei dati locali viene memorizzata nell'archiviazione remota. In questo caso, i dati letti dal traffico di utilizzo provengono dall'archiviazione locale.
+ Il valore predefinito per retention.ms è 7 giorni. Non esiste un limite di dimensione predefinito per retention.bytes.
+ Il valore minimo per retention.ms/bytes è -1. Ciò significa una conservazione infinita.
+ Il valore minimo per local.retention. ms/bytes is -2. This means infinite retention for local storage. It matches with the retention.ms/bytesimpostazione come -1.
+ La configurazione a livello di argomento retention.ms è obbligatoria per gli argomenti con lo storage su più livelli attivato. Il valore minimo per retention.ms è 3 giorni.
Per ulteriori informazioni sui vincoli di storage su più livelli, vedere. [Vincoli e limitazioni dello storage su più livelli per i cluster Amazon MSK](msk-tiered-storage.md#msk-tiered-storage-constraints)
# Configurazioni del broker Express
Apache Kafka dispone di centinaia di configurazioni di broker che puoi utilizzare per ottimizzare le prestazioni del tuo cluster MSK Provisioned. L'impostazione di valori errati o non ottimali può influire sull'affidabilità e sulle prestazioni del cluster. I broker Express migliorano la disponibilità e la durata dei cluster MSK Provisioned impostando valori ottimali per le configurazioni critiche e proteggendole dai comuni errori di configurazione. [Esistono tre categorie di configurazioni basate sull'accesso in lettura e scrittura: configurazioni di lettura/scrittura [(modificabili), di sola lettura e non di lettura/scrittura](msk-configuration-express-read-write.md).](msk-configuration-express-read-only.md) Alcune configurazioni utilizzano ancora il valore predefinito di Apache Kafka per la versione di Apache Kafka in esecuzione sul cluster. Le contrassegniamo come Apache Kafka Default.
**Topics**
+ [Configurazioni personalizzate del broker MSK Express (accesso in lettura/scrittura)](msk-configuration-express-read-write.md)
+ [Configurazioni di sola lettura di Express Brokers](msk-configuration-express-read-only.md)
# Configurazioni personalizzate del broker MSK Express (accesso in lettura/scrittura)
Puoi aggiornare le configurazioni dei read/write broker utilizzando la [funzionalità di aggiornamento della configurazione](msk-update-cluster-config.md) di Amazon MSK o l'API di Apache Kafka. AlterConfig Le configurazioni del broker Apache Kafka sono statiche o dinamiche. Le configurazioni statiche richiedono il riavvio del broker per poter applicare la configurazione, mentre le configurazioni dinamiche non richiedono il riavvio del broker. Per ulteriori informazioni sulle proprietà di configurazione e sulle modalità di aggiornamento, vedere [Aggiornamento delle configurazioni del broker](https://kafka.apache.org/documentation/#dynamicbrokerconfigs).
**Topics**
+ [Configurazioni statiche sui broker MSK Express](#msk-configuration-express-static-configuration)
+ [Configurazioni dinamiche su Express Brokers](#msk-configuration-express-dynamic-configuration)
+ [Configurazioni a livello di argomento su Express Brokers](#msk-configuration-express-topic-configuration)
## Configurazioni statiche sui broker MSK Express
Puoi usare Amazon MSK per creare un file di configurazione MSK personalizzato per impostare le seguenti proprietà statiche. Amazon MSK imposta e gestisce tutte le altre proprietà che non hai impostato. È possibile creare e aggiornare file di configurazione statici dalla console MSK o utilizzando il comando [configurations](msk-configuration-operations-create.md).
| Proprietà | Description | Valore predefinito |
| --- | --- | --- |
| allow.everyone.if.no.acl.found | Se vuoi impostare questa proprietà su false, assicurati innanzitutto di definire Apache Kafka ACLs per il tuo cluster. Se impostate questa proprietà su false e non definite prima Apache Kafka ACLs, perderete l'accesso al cluster. In tal caso, puoi aggiornare nuovamente la configurazione e impostare questa proprietà su true per riottenere l'accesso al cluster. | true |
| auto.create.topics.enable | Abilita la creazione automatica di un argomento sul server. | false |
| compression.type | Specificate il tipo di compressione finale per un determinato argomento. Questa configurazione accetta i codec di compressione standard: gzip, snappy, lz4, zstd. Questa configurazione accetta inoltre`uncompressed`, il che equivale a non comprimere nulla`producer`, e ciò significa mantenere il codec di compressione originale impostato dal produttore. | Apache Kafka (impostazione predefinita) |
| connections.max.idle.ms | Timeout delle connessioni inattive in millisecondi. I thread del processore dei socket del server chiudono le connessioni inattive per un periodo superiore al valore impostato per questa proprietà. | Apache Kafka predefinito |
| delete.topic.enable | Abilita l'operazione di eliminazione argomento. Se questa configurazione è disattivata, non è possibile eliminare un argomento tramite lo strumento di amministrazione. | Apache Kafka predefinito |
| group.initial.rebalance.delay.ms | Il tempo durante il quale il coordinatore del gruppo attende che altri consumatori si uniscano a un nuovo gruppo prima di eseguire il primo ribilanciamento. Un ritardo più lungo significa potenzialmente meno ribilanciamenti, ma aumenta il tempo prima dell'inizio dell'elaborazione. | Apache Kafka predefinito |
| group.max.session.timeout.ms | Timeout sessione massimo per i consumatori registrati. Timeout più lunghi offrono ai consumatori più tempo per elaborare i messaggi tra heartbeat, ma implicano un aumento del tempo richiesto per rilevare gli errori. | Apache Kafka predefinito |
| leader.imbalance.per.broker.percentage | Il rapporto di squilibrio leader consentito per broker. Il controller attiva un bilanciamento dei leader se supera questo valore per broker. Questo valore è specificato in percentuale. | Apache Kafka predefinito |
| log.cleanup.policy | La policy di pulizia predefinita per i segmenti oltre la finestra di conservazione. Un elenco separato da virgole di policy valide. Policy valide sono delete e compact. Per i cluster abilitati allo storage su più livelli, è valida solo la policy. delete | Apache Kafka (impostazione predefinita) |
| log.message.timestamp.after.max.ms | La differenza di timestamp consentita tra il timestamp del messaggio e il timestamp del broker. Il timestamp del messaggio può essere successivo o uguale al timestamp del broker, con la differenza massima consentita determinata dal valore impostato in questa configurazione. Se`log.message.timestamp.type=CreateTime`, il messaggio verrà rifiutato se la differenza nei timestamp supera la soglia specificata. Questa configurazione viene ignorata se. `log.message.timestamp.type=LogAppendTime` | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, ovvero 1 giorno) |
| log.message.timestamp.before.max.ms | La differenza di timestamp consentita tra il timestamp del broker e il timestamp del messaggio. Il timestamp del messaggio può essere precedente o uguale al timestamp del broker, con la differenza massima consentita determinata dal valore impostato in questa configurazione. Se`log.message.timestamp.type=CreateTime`, il messaggio verrà rifiutato se la differenza nei timestamp supera la soglia specificata. Questa configurazione viene ignorata se. `log.message.timestamp.type=LogAppendTime` | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, ovvero 1 giorno) |
| log.message.timestamp.type | Specifica se il timestamp nel messaggio è l'ora di creazione del messaggio o l'ora di aggiunta del log. I valori consentiti sono CreateTime e LogAppendTime. | Apache Kafka predefinito |
| log.retention.bytes | Dimensione massima del log prima dell'eliminazione. | Apache Kafka predefinito |
| log.retention.ms | Numero di millisecondi per conservare un file di registro prima di eliminarlo. | Apache Kafka (impostazione predefinita) |
| numero massimo di connessioni per ip | Il numero massimo di connessioni consentite da ogni indirizzo IP. Questo valore può essere impostato su 0 se sono presenti sostituzioni configurate utilizzando la max.connections.per.ip.overrides proprietà. Le nuove connessioni dall'indirizzo IP vengono interrotte se viene raggiunto il limite. | Apache Kafka (impostazione predefinita) |
| max.incremental.fetch.session.cache.slots | Numero massimo di sessioni di recupero incrementali che vengono mantenute. | Apache Kafka predefinito |
| message.max.bytes | Dimensione massima del batch di record consentita da Kafka. Se aumenti questo valore e sono presenti consumatori più vecchi di 0.10.2, anche le dimensioni di recupero dei consumatori devono essere incrementate in modo che possano recuperare batch di record di queste dimensioni. Nella versione più recente del formato del messaggio, i messaggi vengono sempre raggruppati in batch per maggiore efficienza. Nelle versioni precedenti del formato del messaggio, i record non compressi non sono raggruppati in batch; in tal caso, questo limite si applica solo a un singolo record. Puoi impostare questo valore per argomento con la configurazione a livello di argomento. `max.message.bytes` | Apache Kafka predefinito |
| num.partitions | Numero predefinito di partizioni per argomento. | 1 |
| offsets.retention.minutes | Dopo che un gruppo di consumatori perde tutti i suoi consumatori (ovvero, diventa vuoto) i suoi offset vengono mantenuti per questo periodo di conservazione prima di essere scartati. Per i consumatori autonomi (ovvero quelli che utilizzano l'assegnazione manuale), gli offset scadono dopo l'ultimo commit più questo periodo di conservazione. | Apache Kafka predefinito |
| replica.fetch.max.bytes | Numero di byte di messaggi da recuperare per ogni partizione. Questo valore non è un massimo assoluto. Se il primo batch di record nella prima partizione non vuota del recupero è più grande di questo valore, viene restituito il batch di record per garantire l'avanzamento. La proprietà message.max.bytes (configurazione broker) o max.message.bytes (configurazione argomento) specifica la dimensione massima del batch di record accettata dal broker. | Apache Kafka predefinito |
| replica.selector.class | Il nome completo della classe che implementa. ReplicaSelector Il broker utilizza questo valore per trovare la replica di lettura preferita. Se desideri consentire ai consumatori di eseguire il recupero dalla replica più vicina, imposta questa proprietà su. `org.apache.kafka.common.replica.RackAwareReplicaSelector` | Apache Kafka (impostazione predefinita) |
| socket.receive.buffer.bytes | Buffer SO\$1RCVBUF dei socket del server dei socket. Se il valore è -1, viene utilizzato il sistema operativo predefinito. | 102400 |
| socket.request.max.bytes | Numero massimo di byte in una richiesta socket. | 104857600 |
| socket.send.buffer.bytes | Buffer SO\$1SNDBUF dei socket del server dei socket. Se il valore è -1, viene utilizzato il sistema operativo predefinito. | 102400 |
| transaction.max.timeout.ms | Timeout massimo per transazioni. Se il tempo di transazione richiesto da un cliente supera questo valore, il broker restituisce un errore in. InitProducerIdRequest Ciò evita un timeout troppo elevato per un client, che può rallentare i consumatori che leggono dagli argomenti inclusi nella transazione. | Apache Kafka (impostazione predefinita) |
| transactional.id.expiration.ms | Il tempo in millisecondi durante il quale il coordinatore della transazione attende di ricevere eventuali aggiornamenti sullo stato delle transazioni per la transazione corrente prima che il coordinatore faccia scadere il proprio ID transazionale. Questa impostazione influenza anche la scadenza dell'ID del produttore perché fa scadere IDs il produttore quando questo tempo è trascorso dall'ultima scrittura con l'ID produttore specificato. Producer IDs potrebbe scadere prima se l'ultima scrittura dall'ID produttore viene eliminata a causa delle impostazioni di conservazione dell'argomento. Il valore minimo per questa proprietà è 1 millisecondo. | Apache Kafka (impostazione predefinita) |
## Configurazioni dinamiche su Express Brokers
Puoi utilizzare l' AlterConfig API Apache Kafka o lo strumento Kafka-configs.sh per modificare le seguenti configurazioni dinamiche. Amazon MSK imposta e gestisce tutte le altre proprietà che non hai impostato. Puoi impostare dinamicamente proprietà di configurazione a livello di cluster e di broker che non richiedono il riavvio del broker.
| Proprietà | Description | Valore predefinito |
| --- | --- | --- |
| advertised.listeners | Listener da pubblicare per l'utilizzo da parte dei client, se diversi dalla proprietà config. `listeners` Negli ambienti IaaS, potrebbe essere necessario che questa sia diversa dall'interfaccia a cui si collega il broker. Se questo non è impostato, verrà utilizzato il valore per gli ascoltatori. A differenza degli ascoltatori, non è valido pubblicizzare il meta-indirizzo 0.0.0.0. Inoltre`listeners`, a differenza di questa proprietà, possono esserci porte duplicate, in modo che un listener possa essere configurato per annunciare l'indirizzo di un altro listener. Ciò può essere utile in alcuni casi in cui vengono utilizzati sistemi di bilanciamento del carico esterni. Questa proprietà è impostata a livello di broker. | null |
| compression.type | Il tipo di compressione finale per un determinato argomento. Puoi impostare questa proprietà sui codec di compressione standard (`gzip`, `snappy`, `lz4` e `zstd`). Inoltre, accetta `uncompressed`. Questo valore equivale a nessuna compressione. Se imposti il valore su `producer`, significa mantenere il codec di compressione originale impostato dal produttore. | Apache Kafka predefinito |
| log.cleaner.delete.retention.ms | Il periodo di tempo necessario per conservare i marker di eliminazione di tombstone per gli argomenti con log compattati. Questa impostazione stabilisce anche un limite al tempo in cui un consumatore deve completare una lettura se inizia dall'offset 0 per assicurarsi di ottenere un'istantanea valida della fase finale. Altrimenti, le lapidi eliminate potrebbero essere raccolte prima che completino la scansione. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, ovvero 1 giorno), Apache Kafka Default |
| log.cleaner.min.compaction.lag.ms | Il periodo minimo di tempo in cui un messaggio rimarrà non compattato nel registro. Questa impostazione è applicabile solo ai log che vengono compattati. | 0, Apache Kafka predefinito |
| log.cleaner.max.compaction.lag.ms | Il periodo massimo di tempo in cui un messaggio rimarrà non idoneo per la compattazione nel registro. Questa impostazione è applicabile solo ai log che vengono compattati. Questa configurazione sarebbe limitata all'intervallo di [7 giorni, Long.Max]. | 9223372036854775807, impostazione predefinita di Apache Kafka |
| log.cleanup.policy | La policy di pulizia predefinita per i segmenti oltre la finestra di conservazione. Un elenco separato da virgole di policy valide. Policy valide sono `delete` e `compact`. Per i cluster abilitati allo storage su più livelli, è valida solo la policy. `delete` | Apache Kafka (impostazione predefinita) |
| log.message.timestamp.after.max.ms | La differenza di timestamp consentita tra il timestamp del messaggio e il timestamp del broker. Il timestamp del messaggio può essere successivo o uguale al timestamp del broker, con la differenza massima consentita determinata dal valore impostato in questa configurazione. Se`log.message.timestamp.type=CreateTime`, il messaggio verrà rifiutato se la differenza nei timestamp supera la soglia specificata. Questa configurazione viene ignorata se. `log.message.timestamp.type=LogAppendTime` | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, ovvero 1 giorno) |
| log.message.timestamp.before.max.ms | La differenza di timestamp consentita tra il timestamp del broker e il timestamp del messaggio. Il timestamp del messaggio può essere precedente o uguale al timestamp del broker, con la differenza massima consentita determinata dal valore impostato in questa configurazione. Se`log.message.timestamp.type=CreateTime`, il messaggio verrà rifiutato se la differenza nei timestamp supera la soglia specificata. Questa configurazione viene ignorata se. `log.message.timestamp.type=LogAppendTime` | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, ovvero 1 giorno) |
| log.message.timestamp.type | Specifica se il timestamp nel messaggio è l'ora di creazione del messaggio o l'ora di aggiunta del log. I valori consentiti sono `CreateTime` e `LogAppendTime`. | Apache Kafka predefinito |
| log.retention.bytes | Dimensione massima del log prima dell'eliminazione. | Apache Kafka predefinito |
| log.retention.ms | Numero di millisecondi per conservare un file di registro prima di eliminarlo. | Apache Kafka (impostazione predefinita) |
| max.connection.creation.rate | La velocità massima di creazione della connessione consentita nel broker in qualsiasi momento. | Apache Kafka (impostazione predefinita) |
| numero massimo di connessioni | Il numero massimo di connessioni consentite nel broker in qualsiasi momento. Questo limite viene applicato in aggiunta a qualsiasi limite per IP configurato utilizzando. `max.connections.per.ip` | Apache Kafka (impostazione predefinita) |
| numero massimo di connessioni per ip | Il numero massimo di connessioni consentite da ogni indirizzo IP. Questo valore può essere impostato su `0` se sono presenti sostituzioni configurate utilizzando la proprietà max.connections.per.ip.overrides. Le nuove connessioni dall'indirizzo IP vengono interrotte se viene raggiunto il limite. | Apache Kafka (impostazione predefinita) |
| max.connections.per.ip.overrides | Un elenco separato da virgole di per-ip o nome host sostituisce il numero massimo predefinito di connessioni. Un valore di esempio è `hostName:100,127.0.0.1:200` | Apache Kafka predefinito |
| message.max.bytes | Dimensione massima del batch di record consentita da Kafka. Se aumenti questo valore e sono presenti consumatori più vecchi di 0.10.2, anche le dimensioni di recupero dei consumatori devono essere incrementate in modo che possano recuperare batch di record di queste dimensioni. Nella versione più recente del formato del messaggio, i messaggi vengono sempre raggruppati in batch per maggiore efficienza. Nelle versioni precedenti del formato del messaggio, i record non compressi non sono raggruppati in batch; in tal caso, questo limite si applica solo a un singolo record. Puoi impostare questo valore per argomento con la configurazione a livello di argomento. `max.message.bytes` | Apache Kafka predefinito |
| producer.id.expiration.ms | Il tempo in ms che il leader della partizione di un argomento aspetterà prima che il produttore scada. IDs Il produttore non IDs scadrà finché una transazione ad esso associata è ancora in corso. Tieni presente che producer IDs potrebbe scadere prima se l'ultima scrittura dall'ID del produttore viene eliminata a causa delle impostazioni di conservazione dell'argomento. L'impostazione di questo valore uguale o superiore a `delivery.timeout.ms` può aiutare a prevenire la scadenza durante i nuovi tentativi e a proteggere dalla duplicazione dei messaggi, ma l'impostazione predefinita dovrebbe essere ragionevole per la maggior parte dei casi d'uso. | Apache Kafka predefinito |
## Configurazioni a livello di argomento su Express Brokers
Puoi utilizzare i comandi Apache Kafka per impostare o modificare le proprietà di configurazione a livello dell'argomento per argomenti nuovi ed esistenti. Se non puoi fornire alcuna configurazione a livello di argomento, Amazon MSK utilizza il broker predefinito. Come per le configurazioni a livello di broker, Amazon MSK protegge alcune proprietà di configurazione a livello di argomento da eventuali modifiche. Gli esempi includono il fattore di replica e. `min.insync.replicas` `unclean.leader.election.enable` Se tenti di creare un argomento con un valore del fattore di replica diverso da`3`, Amazon MSK creerà l'argomento con un fattore di replica di `3` default. Per ulteriori informazioni sulle proprietà di configurazione a livello di argomento ed esempi di come impostarle, consulta la pagina [Topic-Level Configs](https://kafka.apache.org/documentation/#topicconfigs) nella documentazione ufficiale di Apache Kafka.
| Proprietà | Description |
| --- | --- |
| cleanup.policy | Questa configurazione indica la politica di conservazione da utilizzare sui segmenti di log. La politica di «eliminazione» (che è l'impostazione predefinita) eliminerà i vecchi segmenti una volta raggiunto il tempo di conservazione o il limite di dimensione. La politica «compatta» consentirà la compattazione dei log, che conserva il valore più recente per ogni chiave. È anche possibile specificare entrambe le politiche in un elenco separato da virgole (ad esempio, «delete, compact»). In questo caso, i vecchi segmenti verranno eliminati in base alla configurazione del tempo di conservazione e delle dimensioni, mentre i segmenti mantenuti verranno compattati. La compattazione sui broker Express viene attivata dopo che i dati in una partizione raggiungono i 256 MB. |
| compression.type | Specificate il tipo di compressione finale per un determinato argomento. Questa configurazione accetta i codec di compressione standard (`gzip`,, `snappy``lz4`,`zstd`). Accetta inoltre ciò `uncompressed` che equivale a nessuna compressione; il `producer` che significa mantenere il codec di compressione originale impostato dal produttore. |
| delete.retention.ms | Il periodo di tempo necessario per conservare i marker di eliminazione di tombstone per gli argomenti con log compattati. Questa impostazione stabilisce anche un limite al tempo in cui un consumatore deve completare una lettura se inizia dall'offset 0 per assicurarsi di ottenere un'istantanea valida della fase finale. Altrimenti, le lapidi eliminate potrebbero essere raccolte prima che completino la scansione. Il valore predefinito per questa impostazione è 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, ovvero 1 giorno), Apache Kafka Default |
| max.message.bytes | La dimensione massima del batch di record consentita da Kafka (dopo la compressione, se la compressione è abilitata). Se questa cifra aumenta e ci sono consumatori più vecchi di età`0.10.2`, è necessario aumentare anche la dimensione di recupero dei consumatori in modo che possano recuperare batch di dischi di dimensioni così grandi. Nella versione più recente del tipo di formato, i record vengono sempre raggruppati in batch ai fini dell'efficienza. Nelle versioni precedenti del tipo di formato, i record non compressi non sono raggruppati in batch e questo limite si applica solo a un singolo record in quel caso. Questo può essere impostato per argomento con il livello dell'argomento. `max.message.bytes config` |
| messaggio.timestamp.after.max.ms | Questa configurazione imposta la differenza di timestamp consentita tra il timestamp del messaggio e il timestamp del broker. Il timestamp del messaggio può essere successivo o uguale al timestamp del broker, con la differenza massima consentita determinata dal valore impostato in questa configurazione. Se`message.timestamp.type=CreateTime`, il messaggio verrà rifiutato se la differenza nei timestamp supera la soglia specificata. Questa configurazione viene ignorata se. `message.timestamp.type=LogAppendTime` |
| message.timestamp.before.max.ms | Questa configurazione imposta la differenza di timestamp consentita tra il timestamp del broker e il timestamp del messaggio. Il timestamp del messaggio può essere precedente o uguale al timestamp del broker, con la differenza massima consentita determinata dal valore impostato in questa configurazione. Se`message.timestamp.type=CreateTime`, il messaggio verrà rifiutato se la differenza nei timestamp supera la soglia specificata. Questa configurazione viene ignorata se. `message.timestamp.type=LogAppendTime` |
| message.timestamp.type | Definisce se il timestamp nel messaggio è l'ora di creazione del messaggio o l'ora di aggiunta del registro. Il valore deve essere o `CreateTime` `LogAppendTime` |
| min.compaction.lag.ms | Il periodo minimo di tempo in cui un messaggio rimarrà non compattato nel registro. Questa impostazione è applicabile solo ai log che vengono compattati. Il valore predefinito per questa impostazione è 0, Apache Kafka Default |
| max.compaction.lag.ms | Il periodo massimo di tempo in cui un messaggio rimarrà non idoneo per la compattazione nel registro. Questa impostazione è applicabile solo ai log che vengono compattati. Questa configurazione sarebbe limitata all'intervallo di [7 giorni, Long.Max]. Il valore predefinito per questa impostazione è 9223372036854775807, Apache Kafka Default. |
| retention.bytes | Questa configurazione controlla la dimensione massima che una partizione (composta da segmenti di log) può raggiungere prima di eliminare i vecchi segmenti di registro per liberare spazio se utilizziamo la politica di conservazione «elimina». Per impostazione predefinita, non esiste un limite di dimensione, ma solo un limite di tempo. Poiché questo limite viene applicato a livello di partizione, moltiplicalo per il numero di partizioni per calcolare la conservazione dell'argomento in byte. Inoltre, funziona indipendentemente dalle configurazioni e dalle `retention.bytes configuration` configurazioni. `segment.ms` `segment.bytes` Inoltre, attiva il lancio di un nuovo segmento se `retention.bytes` è configurato a zero. |
| retention.ms | Questa configurazione controlla il tempo massimo di conservazione di un registro prima di eliminare i vecchi segmenti di registro per liberare spazio se utilizziamo la politica di conservazione «elimina». Ciò rappresenta uno SLA sulla tempistica con cui i consumatori devono leggere i propri dati. Se impostato su`-1`, non viene applicato alcun limite di tempo. Inoltre, la `retention.ms` configurazione funziona indipendentemente dalle `segment.bytes` configurazioni `segment.ms` e. Inoltre, attiva il lancio di un nuovo segmento se la `retention.ms` condizione è soddisfatta. |
# Configurazioni di sola lettura di Express Brokers
Amazon MSK imposta i valori per queste configurazioni e le protegge da modifiche che potrebbero influire sulla disponibilità del cluster. Questi valori possono cambiare a seconda della versione di Apache Kafka in esecuzione sul cluster, quindi ricordati di controllare i valori del tuo cluster specifico.
La tabella seguente elenca le configurazioni di sola lettura per i broker Express.
| Proprietà | Description | Valore di Express Broker |
| --- | --- | --- |
| broker.id | L'id del broker per questo server. | 1,2,3... |
| broker.rack | Rack del broker. Questo verrà utilizzato nell'assegnazione della replica in base al rack per la tolleranza ai guasti. Esempi: ``, RACK1 `us-east-1d` | ID AZ o ID di sottorete |
| default.replication.factor | Fattori di replica predefiniti per tutti gli argomenti. | 3 |
| fetch.max.bytes | Il numero massimo di byte che restituiremo per una richiesta di recupero. | Apache Kafka (impostazione predefinita) |
| dimensione massima del gruppo | Il numero massimo di consumatori che un singolo gruppo di consumatori può ospitare. | Apache Kafka (impostazione predefinita) |
| inter.broker.listener.name | Nome dell'ascoltatore utilizzato per la comunicazione tra i broker. | REPLICATION\$1SECURE o REPLICATION |
| inter.broker.protocol. version | Speciifica quale versione del protocollo inter-broker viene utilizzata. | Apache Kafka (impostazione predefinita) |
| listener | Elenco degli ascoltatori - Elenco separato da virgole dei nomi degli ascoltatori su cui URIs ascolteremo. È possibile impostare iladvertised.listeners property, ma non la proprietà. listeners | Generato da MSK |
| log.message.format.version | Specificare la versione del formato del messaggio che il broker utilizzerà per aggiungere messaggi ai log. | Apache Kafka predefinito |
| min.insync.replicas | Quando un produttore imposta acks su `all` (or`-1`), il valore in `min.insync.replicas` specifica il numero minimo di repliche che devono confermare una scrittura affinché la scrittura sia considerata riuscita. Se questo minimo non può essere raggiunto, il produttore solleva un'eccezione (o`NotEnoughReplicas`). `NotEnoughReplicasAfterAppend` Puoi utilizzare il valore degli ack del tuo produttore per far valere maggiori garanzie di durabilità. Impostando acks su «all». Ciò garantisce che il produttore generi un'eccezione se la maggior parte delle repliche non riceve una scrittura. | 2 |
| num.io.thread | Numero di thread utilizzati dal server per produrre richieste, che possono includere l'I/O del disco. (m7g.large, 8), (m7g.xlarge, 8), (m7g.2xlarge, 16), (m7g.4xlarge, 32), (m7g.8xlarge, 64), (m7g.12xlarge, 96), (m7g.16xlarge, 128) | In base al tipo di istanza. =Math.max (8, 2\$1 v) CPUs |
| num.network.threads | Numero di thread utilizzati dal server per ricevere richieste dalla rete e inviare risposte alla rete. (m7g.large, 8), (m7g.xlarge, 8), (m7g.2xlarge, 8), (m7g.4xlarge, 16), (m7g.8xlarge, 32), (m7g.12xlarge, 48), (m7g.16xlarge, 64) | In base al tipo di istanza. =Math.max (8, v) CPUs |
| replica.fetch.response.max.bytes | Il numero massimo di byte previsto per l'intera risposta di recupero. I record vengono recuperati in batch. Se il primo batch di record nella prima partizione non vuota del recupero è più grande di questo valore, il batch di record verrà comunque restituito per garantire l'avanzamento. Questo non è un massimo assoluto. Le proprietà message.max.bytes (broker config) o max.message.bytes (topic config) specificano la dimensione massima del batch di record che il broker accetta. | Apache Kafka (impostazione predefinita) |
| request.timeout.ms | La configurazione controlla il tempo massimo di attesa del client per la risposta di una richiesta. Se la risposta non viene ricevuta prima dello scadere del timeout, il client invierà nuovamente la richiesta se necessario o fallirà la richiesta se i nuovi tentativi sono esauriti. | Apache Kafka predefinito |
| transaction.state.log.min.isr | min.insync.replicasConfigurazione sostituita per l'argomento della transazione. | 2 |
| transaction.state.log.replication.factor | Il fattore di replica per l'argomento di transazione. | Apache Kafka (impostazione predefinita) |
| unclean.leader.election.enable | Consente alle repliche non incluse nel set ISR di fungere da leader come ultima risorsa, anche se ciò potrebbe comportare la perdita di dati. | FALSE |
# Operazioni di configurazione del broker
Le configurazioni del broker Apache Kafka sono statiche o dinamiche. Le configurazioni statiche richiedono il riavvio del broker per poter applicare la configurazione. Le configurazioni dinamiche non richiedono il riavvio del broker per aggiornare la configurazione. Per ulteriori informazioni sulle proprietà di configurazione e sulle modalità di aggiornamento, consulta Configurazione di Apache Kafka.
In questo argomento viene descritto come creare configurazioni MSK personalizzate e come eseguire operazioni su di esse. Per informazioni su come utilizzare configurazioni MSK per creare o aggiornare cluster, consulta [Caratteristiche e concetti chiave di Amazon MSK](operations.md).
**Topics**
+ [Creazione di una configurazione](msk-configuration-operations-create.md)
+ [Aggiornamento della configurazione](msk-configuration-operations-update.md)
+ [Eliminare la configurazione](msk-configuration-operations-delete.md)
+ [Ottieni i metadati di configurazione](msk-configuration-operations-describe.md)
+ [Ottieni dettagli sulla revisione della configurazione](msk-configuration-operations-describe-revision.md)
+ [Elenca le configurazioni presenti nel tuo account per la regione corrente](msk-configuration-operations-list.md)
+ [Stati di configurazione di Amazon MSK](msk-configuration-states.md)
# Creazione di una configurazione
Questo processo descrive come creare una configurazione Amazon MSK personalizzata e come eseguire operazioni su di essa.
1. Creare un file in cui specificare le proprietà di configurazione che si desidera impostare e i valori da assegnare alle stesse. Di seguito sono riportati i contenuti di un file di configurazione di esempio.
```
auto.create.topics.enable = true
log.roll.ms = 604800000
```
1. Esegui il AWS CLI comando seguente e sostituiscilo *config-file-path* con il percorso del file in cui hai salvato la configurazione nel passaggio precedente.
**Nota**
Il nome scelto per la configurazione deve corrispondere alla seguente espressione regolare: "^[0-9A-Za-z][0-9A-Za-z-]\$10,\$1\$1".
```
aws kafka create-configuration --name "ExampleConfigurationName" --description "Example configuration description." --kafka-versions "1.1.1" --server-properties fileb://config-file-path
```
Di seguito è riportato un esempio di una risposta corretta dopo l'esecuzione di questo comando.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"CreationTime": "2019-05-21T19:37:40.626Z",
"LatestRevision": {
"CreationTime": "2019-05-21T19:37:40.626Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "ExampleConfigurationName"
}
```
1. Il comando precedente restituisce un nome della risorsa Amazon (ARN) per la configurazione appena creata. Salvare questo ARN perché occorre per fare riferimento a questa configurazione in altri comandi. Se l'ARN della configurazione viene perso, è possibile trovarlo nuovamente elencando tutte le configurazioni presenti nell'account.
# Aggiornamento della configurazione
Questo processo descrive come aggiornare una configurazione Amazon MSK personalizzata.
1. Crea un file in cui specificare le proprietà di configurazione che desideri aggiornare e i valori da assegnare alle stesse. Di seguito sono riportati i contenuti di un file di configurazione di esempio.
```
auto.create.topics.enable = true
min.insync.replicas = 2
```
1. Esegui il AWS CLI comando seguente e sostituiscilo *config-file-path* con il percorso del file in cui hai salvato la configurazione nel passaggio precedente.
Sostituisci *configuration-arn* con l'ARN che hai ottenuto quando hai creato la configurazione. Se l'ARN non è stato salvato al momento della creazione della configurazione, è possibile utilizzare il comando `list-configurations` per elencare tutte le configurazioni presenti nell'account. La configurazione desiderata viene visualizzata nell'elenco di risposta. L'ARN della configurazione viene visualizzato anche in tale elenco.
```
aws kafka update-configuration --arn configuration-arn --description "Example configuration revision description." --server-properties fileb://config-file-path
```
1. Di seguito è riportato un esempio di una risposta corretta dopo l'esecuzione di questo comando.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"LatestRevision": {
"CreationTime": "2020-08-27T19:37:40.626Z",
"Description": "Example configuration revision description.",
"Revision": 2
}
}
```
# Eliminare la configurazione
Nella procedura seguente viene illustrato come eliminare una configurazione non collegata a un cluster. Non è possibile eliminare una configurazione collegata a un cluster.
1. Per eseguire questo esempio, sostituiscilo *configuration-arn* con l'ARN che hai ottenuto quando hai creato la configurazione. Se l'ARN non è stato salvato al momento della creazione della configurazione, è possibile utilizzare il comando `list-configurations` per elencare tutte le configurazioni presenti nell'account. La configurazione desiderata viene visualizzata nell'elenco di risposta. L'ARN della configurazione viene visualizzato anche in tale elenco.
```
aws kafka delete-configuration --arn configuration-arn
```
1. Di seguito è riportato un esempio di una risposta corretta dopo l'esecuzione di questo comando.
```
{
"arn": " arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"state": "DELETING"
}
```
# Ottieni i metadati di configurazione
La procedura seguente mostra come descrivere una configurazione Amazon MSK per ottenere i metadati relativi alla configurazione.
1. Il comando seguente restituisce i metadati relativi alla configurazione. Per ottenere una descrizione dettagliata della configurazione, eseguire `describe-configuration-revision`.
Per eseguire questo esempio, sostituiscilo *configuration-arn* con l'ARN che hai ottenuto quando hai creato la configurazione. Se l'ARN non è stato salvato al momento della creazione della configurazione, è possibile utilizzare il comando `list-configurations` per elencare tutte le configurazioni presenti nell'account. La configurazione desiderata viene visualizzata nell'elenco di risposta. L'ARN della configurazione viene visualizzato anche in tale elenco.
```
aws kafka describe-configuration --arn configuration-arn
```
1. Di seguito è riportato un esempio di una risposta corretta dopo l'esecuzione di questo comando.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "SomeTest"
}
```
# Ottieni dettagli sulla revisione della configurazione
Questo processo consente di ottenere una descrizione dettagliata della revisione della configurazione di Amazon MSK.
Se utilizzi il comando `describe-configuration` per descrivere una configurazione MSK, visualizzerai i metadati della configurazione. Per ottenere una descrizione dettagliata della configurazione, utilizza il comando `describe-configuration-revision`.
+ Esegui il comando seguente e sostituiscilo *configuration-arn* con l'ARN ottenuto quando hai creato la configurazione. Se l'ARN non è stato salvato al momento della creazione della configurazione, è possibile utilizzare il comando `list-configurations` per elencare tutte le configurazioni presenti nell'account. La configurazione desiderata viene visualizzata nell'elenco di risposta. L'ARN della configurazione viene visualizzato anche in tale elenco.
```
aws kafka describe-configuration-revision --arn configuration-arn --revision 1
```
Di seguito è riportato un esempio di una risposta corretta dopo l'esecuzione di questo comando.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1,
"ServerProperties": "YXV0by5jcmVhdGUudG9waWNzLmVuYWJsZSA9IHRydWUKCgp6b29rZWVwZXIuY29ubmVjdGlvbi50aW1lb3V0Lm1zID0gMTAwMAoKCmxvZy5yb2xsLm1zID0gNjA0ODAwMDAw"
}
```
Il valore di `ServerProperties` è codificato con base64. Se si utilizza un decodificatore base64 (ad esempio, https://www.base64decode.org/) per decodificarlo manualmente, si ottiene il contenuto del file di configurazione originale utilizzato per creare la configurazione personalizzata. In questo caso, si ottiene quanto segue:
```
auto.create.topics.enable = true
log.roll.ms = 604800000
```
# Elenca le configurazioni presenti nel tuo account per la regione corrente
Questo processo descrive come elencare tutte le configurazioni Amazon MSK nel tuo account per la regione corrente AWS .
+ Eseguire il seguente comando seguente.
```
aws kafka list-configurations
```
Di seguito è riportato un esempio di una risposta corretta dopo l'esecuzione di questo comando.
```
{
"Configurations": [
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "SomeTest"
},
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"CreationTime": "2019-05-03T23:08:29.446Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-03T23:08:29.446Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "ExampleConfigurationName"
}
]
}
```
# Stati di configurazione di Amazon MSK
Una configurazione Amazon MSK può trovarsi in uno dei seguenti stati. Per eseguire un'operazione su una configurazione, la configurazione deve trovarsi nello stato `ACTIVE` o `DELETE_FAILED`:
+ `ACTIVE`
+ `DELETING`
+ `DELETE_FAILED`
# Ribilanciamento intelligente per i cluster
Amazon MSK fornisce un ribilanciamento intelligente per tutti i nuovi cluster MSK Provisioned con broker Express. Questa funzionalità gestisce automaticamente la distribuzione delle partizioni e le operazioni di scalabilità del cluster, eliminando la necessità di strumenti di terze parti. Il ribilanciamento intelligente riequilibra automaticamente le partizioni quando si aumentano o diminuiscono i cluster. Inoltre, monitora continuamente lo stato del cluster per rilevare eventuali squilibri o sovraccarichi delle risorse e ridistribuisce il carico di lavoro.
Il ribilanciamento intelligente fornisce operazioni di scalabilità rapide che vengono completate entro 30 minuti e non influisce sulla disponibilità del cluster durante la scalabilità. È attivato per impostazione predefinita per tutti i nuovi cluster Provisioned basati su MSK Express e funziona con il limite massimo di partizioni consigliato di 20.000 partizioni per broker. Inoltre, questa funzionalità è disponibile senza costi aggiuntivi e non richiede alcuna configurazione.
A partire dal 20 novembre 2025, Intelligent Rebalancing è disponibile in tutte le regioni in AWS cui sono supportati i broker Amazon MSK Express.
**Topics**
+ [Come funziona il ribilanciamento intelligente](#how-intelligent-rebalancing-works)
+ [Monitoraggio delle metriche di ribilanciamento intelligente](#intelligent-rebalancing-metrics)
+ [Considerazioni sull'utilizzo del ribilanciamento intelligente](#intelligent-rebalancing-considerations)
+ [Scalabilità verso l'alto e verso il basso dei cluster Amazon MSK con un'unica operazione](intelligent-rebalancing-scaling-clusters.md)
+ [Ribilanciamento dello stato stazionario per i cluster Amazon MSK](intelligent-rebalancing-self-balancing-paritions.md)
## Come funziona il ribilanciamento intelligente
Il ribilanciamento intelligente è attivato per impostazione predefinita per tutti i nuovi cluster MSK Provisioned con broker Express. Include il supporto per le seguenti situazioni:
+ **Scalabilità verso l'alto e verso il basso**: consente di aggiungere o rimuovere broker ai cluster basati su MSK Express con un solo clic. Una volta specificati i broker da aggiungere o rimuovere, il ribilanciamento intelligente ridistribuisce automaticamente le partizioni nella nuova configurazione del cluster in base alle best practice interne. AWS
+ **Ribilanciamento allo stato stazionario: allo stato stazionario, questa funzionalità monitora continuamente lo stato del cluster e ribilancia** automaticamente le partizioni quando:
+ L'utilizzo delle risorse diventa distorto tra i broker.
+ I broker vengono sovraforniti o sottoutilizzati.
+ Vengono aggiunti nuovi broker o rimossi i broker esistenti.
**Nota**
Se il ribilanciamento intelligente è attivato, non potrai utilizzare strumenti di terze parti, come Cruise Control, per il ribilanciamento delle partizioni. Devi prima mettere in pausa il ribilanciamento intelligente per utilizzare l'API di riassegnazione delle partizioni fornita da questi strumenti di terze parti.
Puoi utilizzare questa funzionalità nella console Amazon MSK. Puoi utilizzare questa funzionalità anche utilizzando Amazon MSK APIs o AWS SDK e. AWS CLI AWS CloudFormation Per ulteriori informazioni, consultare [Scalabilità dei cluster Amazon MSK](intelligent-rebalancing-scaling-clusters.md) e [Ribilanciamento allo stato stazionario](intelligent-rebalancing-self-balancing-paritions.md).
## Monitoraggio delle metriche di ribilanciamento intelligente
Puoi monitorare lo stato delle operazioni di ribilanciamento intelligente in corso e storiche utilizzando i seguenti parametri di Amazon CloudWatch :
+ `RebalanceInProgress`: Questa metrica viene pubblicata ogni minuto con il valore 1 quando il ribilanciamento è in corso e 0 in caso contrario.
+ `UnderProvisioned`: indica che il provisioning di un cluster è attualmente insufficiente e che non è possibile eseguire alcun ribilanciamento delle partizioni. È necessario aggiungere altri broker o aumentare il tipo di istanza del cluster.
Per informazioni sul monitoraggio di un cluster MSK Provisioned, vedere e. [](monitoring.md) [](cloudwatch-metrics.md)
## Considerazioni sull'utilizzo del ribilanciamento intelligente
+ Il supporto per il ribilanciamento intelligente è disponibile solo per i nuovi cluster MSK Provisioned con broker Express.
+ Per la riassegnazione automatica delle partizioni, è disponibile il supporto massimo per un massimo di 20.000 partizioni per broker.
+ Non è possibile utilizzare strumenti di riassegnazione delle partizioni APIs o strumenti di ribilanciamento di terze parti quando è abilitato il ribilanciamento intelligente. Per utilizzare questi strumenti APIs o quelli di terze parti, è necessario prima sospendere il ribilanciamento intelligente per il cluster basato su MSK Express.
# Scalabilità verso l'alto e verso il basso dei cluster Amazon MSK con un'unica operazione
Con il ribilanciamento intelligente, puoi aumentare o ridurre i cluster modificando il numero di broker presenti nei cluster con un'unica azione. Puoi eseguire questa operazione nella console Amazon MSK o utilizzando Amazon MSK APIs o AWS SDK e. AWS CLI AWS CloudFormation Quando modifichi il numero di broker, Amazon MSK effettua le seguenti operazioni:
+ Distribuisce automaticamente le partizioni ai nuovi broker.
+ Sposta le partizioni dai broker che vengono rimossi.
Aumentando o diminuendo i cluster, la disponibilità dei cluster per i clienti per la produzione e l'utilizzo dei dati rimane inalterata.
**Topics**
------
#### [ Scaling clusters using Console di gestione AWS ]
1. Aprire la console Amazon MSK a [https://console.aws.amazon.com/msk/casa? region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Nella pagina Cluster, scegli un **cluster basato su Express appena creato**. Per informazioni sulla creazione di un cluster basato su Express con provisioning, vedere. [Fase 1: creare un cluster MSK Provisioned](create-cluster.md)
1. Nell'elenco a discesa **Azioni**, scegli **Modifica il numero di broker**.
1. Nella pagina **Modifica il numero di broker per zona**, esegui una delle seguenti operazioni:
+ Per aggiungere altri broker al cluster, scegli **Aggiungi broker a ciascuna zona di disponibilità**, quindi inserisci il numero di broker che desideri aggiungere.
+ Per rimuovere i broker dal tuo cluster, scegli **Rimuovi un broker da** ogni zona di disponibilità.
1. Scegli **Save changes** (Salva modifiche).
------
#### [ Scaling clusters using AWS CLI ]
Puoi aumentare o diminuire i cluster modificando il numero di broker. A tale scopo AWS CLI, utilizzate il [update-broker-count](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-broker-count.html)comando, come illustrato nell'esempio seguente. In questo comando, specificate nel `target-broker-count` parametro il numero di broker che desiderate inserire nel cluster.
```
aws msk update-broker-count --cluster-arn arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1 --current-version ABCDEF1GHIJK0L --target-broker-count 6
```
------
#### [ Scaling clusters using AWS SDK ]
Puoi aumentare o ridurre i cluster modificando in modo programmatico il numero di broker. Per eseguire questa operazione utilizzando l' AWS SDK, utilizzate l'[UpdateBrokerCount](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes-count.html#UpdateBrokerCount)API, come illustrato nell'esempio seguente. Per il `TargetNumberOfBrokerNodes` parametro, specifica il numero di broker che desideri inserire nel cluster.
```
update_broker_count_response = client.update_broker_count(
ClusterArn='arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1',
CurrentVersion='ABCDEF1GHIJK0L',
TargetNumberOfBrokerNodes=6
)
```
------
# Ribilanciamento dello stato stazionario per i cluster Amazon MSK
Il ribilanciamento allo stato stazionario fa parte della funzionalità di ribilanciamento intelligente, che è attivata per impostazione predefinita per tutti i nuovi cluster MSK Provisioned con broker Express. Man mano che aumenti o riduci i cluster, Amazon MSK gestisce automaticamente la gestione delle partizioni distribuendo le partizioni a nuovi broker e spostando le partizioni dai broker da rimuovere. Per garantire una distribuzione ottimale del carico di lavoro tra i broker, il ribilanciamento intelligente utilizza le best practice di Amazon MSK per determinare le soglie per l'avvio automatico del ribilanciamento per i broker.
Puoi mettere in pausa e riprendere il riequilibrio allo stato stazionario quando necessario. Il ribilanciamento dello stato stazionario monitora continuamente il cluster ed esegue le seguenti operazioni:
+ Tiene traccia dell'utilizzo delle risorse del broker (CPU, rete, storage).
+ Regola automaticamente il posizionamento delle partizioni senza alcun impatto sulla disponibilità dei dati.
+ Completa le operazioni di ribilanciamento fino a 180 volte più velocemente per i broker Express rispetto ai broker Standard.
+ Mantiene le prestazioni del cluster.
**Topics**
------
#### [ Pause and resume steady state rebalancing in Console di gestione AWS ]
1. Aprire la console Amazon MSK a [https://console.aws.amazon.com/msk/casa? region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. **Nella pagina Cluster, scegli un cluster basato su Express.** Per informazioni sulla creazione di un cluster basato su Express con provisioning, vedere. [Fase 1: creare un cluster MSK Provisioned](create-cluster.md)
1. **Nella pagina dei dettagli del cluster, verifica che lo stato di **ribilanciamento intelligente** sia Attivo.** Se il ribilanciamento intelligente non è disponibile o lo stato è **Sospeso**, crea un nuovo cluster basato su Express.
1. **Nell'elenco a discesa **Azioni**, scegli Modifica ribilanciamento intelligente.**
1. Nella pagina **Modifica ribilanciamento intelligente, procedi** come segue:
1. **Scegli In pausa.**
1. Scegli **Save changes** (Salva modifiche).
------
#### [ Pause and resume steady state rebalancing using AWS CLI ]
Per impostare lo stato di ribilanciamento di un cluster sull'**ACTIVE**utilizzo di AWS CLI, utilizzate il comando [update-rebalancing](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-rebalancing.html), come illustrato nell'esempio seguente. In questo comando, specificate lo stato con il parametro. `rebalancing`
```
aws msk update-rebalancing --cluster-arn arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1 --current-version ABCDEF1GHIJK0L --rebalancing "{\"Rebalancing\":{\"Status\":\"ACTIVE\"}}"
```
------
#### [ Pause and resume steady state rebalancing using AWS SDK ]
È inoltre possibile impostare lo stato di ribilanciamento di un cluster utilizzando l'[UpdateRebalancingRequest](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-rebalancing.html#UpdateRebalancing)API per modificare a livello di codice il conteggio dei broker. Gli esempi seguenti mostrano come impostare lo stato di ribilanciamento su e. **ACTIVE** **PAUSED**
```
final UpdateRebalancingRequest updateRebalancingRequest = new UpdateRebalancingRequest()
.withClusterArn(arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1)
.withCurrentVersion(ABCDEF1GHIJK0L)
.withRebalancing(new Rebalancing().withStatus("ACTIVE"));
```
```
final UpdateRebalancingRequest updateRebalancingRequest = new UpdateRebalancingRequest()
.withClusterArn(arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1)
.withCurrentVersion(ABCDEF1GHIJK0L)
.withRebalancing(new Rebalancing().withStatus("PAUSED"));
```
------
# Applicazione di patch sui cluster MSK Provisioned
Periodicamente, Amazon MSK aggiorna il software sui broker del tuo cluster. La manutenzione include aggiornamenti pianificati o riparazioni non pianificate. La manutenzione pianificata include aggiornamenti del sistema operativo, aggiornamenti di sicurezza e altri aggiornamenti software necessari per mantenere l'integrità, la sicurezza e le prestazioni del cluster. Eseguiamo una manutenzione non pianificata per risolvere il degrado improvviso dell'infrastruttura. Eseguiamo la manutenzione su broker Standard ed Express, ma le esperienze sono diverse.
## Applicazione di patch per broker Standard
[Gli aggiornamenti ai broker Standard non hanno alcun impatto sulle scritture e sulle letture delle applicazioni se segui le best practice.](bestpractices.md)
Amazon MSK utilizza aggiornamenti periodici per il software per mantenere un'elevata disponibilità dei cluster. Durante questo processo, i broker vengono riavviati uno alla volta e Kafka trasferisce automaticamente la leadership a un altro broker online. Quando si visualizzano le operazioni del cluster in modalità Console di gestione AWS o in modalità wireless `ListClusterOperations` APIs, queste operazioni di manutenzione vengono visualizzate con un tipo di operazione di. `DescribeClusterOperation` `SECURITY_PATCHING` I client Kafka dispongono di meccanismi integrati per rilevare automaticamente il cambio di leadership per le partizioni e continuare a scrivere e leggere dati in un cluster MSK. Segui le istruzioni [Le migliori pratiche per i client Apache Kafka](bestpractices-kafka-client.md) per garantire il corretto funzionamento del cluster in ogni momento, anche durante l'applicazione delle patch.
In seguito alla disconnessione di un broker, è normale riscontrare errori di disconnessione transitori sui clienti. Inoltre, per una breve finestra (fino a 2 minuti, in genere meno), osserverete alcuni picchi nella latenza di lettura e scrittura di p99 (in genere alti millisecondi, fino a \$12 secondi). Questi picchi sono previsti e sono causati dalla riconnessione del client a un nuovo broker leader; non influiscono sulla produzione o sul consumo e si risolveranno dopo la riconnessione. Per ulteriori informazioni, consulta [Broker offline](https://docs.aws.amazon.com/msk/latest/developerguide/troubleshooting-offlinebroker-clientfailover.html) e client failover.
Noterai anche un aumento della metrica`UnderReplicatedPartitions`, previsto poiché le partizioni del broker che è stato chiuso non replicano più i dati. Ciò non ha alcun impatto sulle scritture e le letture delle applicazioni, poiché le repliche di queste partizioni ospitate su altri broker ora soddisfano le richieste.
Dopo l'aggiornamento del software, quando il broker torna online, deve «recuperare il ritardo» sui messaggi prodotti mentre era offline. Durante il catch up, si può anche osservare un aumento dell'utilizzo del volume, del throughput e della CPU. Questi non dovrebbero avere alcun impatto sulle scritture e le letture nel cluster se i broker dispongono di risorse sufficienti di CPU, memoria, rete e volume.
## Applicazione di patch per i broker Express
Non ci sono finestre di manutenzione per i broker Express. Amazon MSK aggiorna automaticamente il cluster su base continuativa in modo distribuito nel tempo, il che significa che puoi aspettarti riavvii occasionali e singolari del broker nel corso del mese. In questo modo non è necessario elaborare piani o adattamenti in base a finestre di manutenzione una tantum a livello di cluster. Come sempre, il traffico rimarrà ininterrotto durante il riavvio del broker poiché la leadership passerà ad altri broker che continueranno a soddisfare le richieste. Quando si visualizzano le operazioni del cluster in modalità diretta Console di gestione AWS o diretta `ListClusterOperations` APIs, queste operazioni di manutenzione vengono visualizzate con un tipo di operazione di. `DescribeClusterOperation` `BROKER_UPDATE`
I broker Express sono configurati con impostazioni e protezioni basate sulle best practice che rendono il cluster resiliente alle variazioni di carico che possono verificarsi durante la manutenzione. Amazon MSK imposta quote di throughput sui broker Express per mitigare l'impatto del sovraccarico del cluster, che può causare problemi durante il riavvio del broker. Questi miglioramenti eliminano la necessità di notifiche anticipate, pianificazione e finestre di manutenzione quando si utilizzano i broker Express.
I broker Express replicano sempre i dati in tre modi, in modo che i client effettuino automaticamente il failover durante i riavvii. Non devi preoccuparti che gli argomenti diventino non disponibili a causa del fattore di replica impostato su 1 o 2. Inoltre, il catch up per un broker Express riavviato è più veloce rispetto ai broker Standard. La maggiore velocità di applicazione delle patch sui broker Express significa che le interruzioni della pianificazione di tutte le attività del piano di controllo che potresti aver pianificato per il tuo cluster saranno minime.
Come per tutte le applicazioni Apache Kafka, esiste ancora un contratto client-server condiviso per i clienti che si connettono ai broker Express. È ancora fondamentale configurare i clienti per gestire il failover della leadership tra i broker. Segui le istruzioni [Le migliori pratiche per i client Apache Kafka](bestpractices-kafka-client.md) per un funzionamento senza intoppi del cluster in ogni momento, anche durante l'applicazione delle patch. Dopo il riavvio del broker, è normale che si verifichino [errori di disconnessione](troubleshooting-offlinebroker-clientfailover.md) transitori sui client. Ciò non influirà sulla produzione e sul consumo, in quanto i broker follower assumeranno la leadership della partizione. I vostri client Apache Kafka eseguiranno automaticamente il failover e inizieranno a inviare richieste ai nuovi broker leader.
# Broker offline e failover del client
Kafka consente l'utilizzo di un broker offline; un unico broker offline in un cluster sano ed equilibrato che segue le migliori pratiche non avrà alcun impatto né causerà l'interruzione della produzione o del consumo. Questo perché un altro broker assumerà la guida delle partizioni e perché la libreria dei client di Kafka eseguirà automaticamente il failover e inizierà a inviare richieste ai nuovi broker leader.
**Contratto client-server**
Ciò si traduce in un contratto condiviso tra la libreria client e il comportamento lato server; il server deve assegnare correttamente uno o più nuovi leader e il client deve cambiare broker per inviare le richieste ai nuovi leader in modo tempestivo.
Kafka utilizza le eccezioni per controllare questo flusso:
**Un esempio di procedura**
1. Il broker A entra in uno stato offline.
1. Il client Kafka riceve un'eccezione (in genere la disconnessione della rete o not\$1leader\$1for\$1partition).
1. Queste eccezioni fanno sì che il client Kafka aggiorni i propri metadati in modo da conoscere i leader più recenti.
1. Il client Kafka riprende a inviare richieste ai nuovi responsabili delle partizioni su altri broker.
Questo processo richiede in genere meno di 2 secondi con il client Java fornito e le configurazioni predefinite. Gli errori lato client sono dettagliati e ripetitivi, ma non sono motivo di preoccupazione, come indicato dal livello «WARN».
**Esempio: eccezione 1**
`10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Got error produce response with correlation id 864845 on topic-partition msk-test-topic-1-0, retrying (2147483646 attempts left). Error: NETWORK_EXCEPTION. Error Message: Disconnected from node 2`
**Esempio: eccezione 2**
`10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Received invalid metadata error in produce request on partition msk-test-topic-1-41 due to org.apache.kafka.common.errors.NotLeaderOrFollowerException: For requests intended only for the leader, this error indicates that the broker is not the current leader. For requests intended for any replica, this error indicates that the broker is not a replica of the topic partition.. Going to request metadata update now"`
I client Kafka risolveranno automaticamente questi errori in genere entro 1 secondo e al massimo 3 secondi. Ciò si presenta come produce/consume una latenza a p99 nelle metriche lato client (in genere millisecondi elevati negli anni 100). Un periodo superiore a questo valore indica in genere un problema con la configurazione client o il carico del controller sul lato server. Consulta la sezione relativa alla risoluzione dei problemi.
Un failover riuscito può essere verificato controllando l'`BytesInPerSec`aumento delle `LeaderCount` metriche su altri broker, il che dimostra che il traffico e la leadership si sono mossi come previsto. Noterai anche un aumento della `UnderReplicatedPartitions` metrica, previsto quando le repliche sono offline con il broker di shutdown.
**Risoluzione dei problemi**
Il flusso di cui sopra può essere interrotto interrompendo il contratto client-server. I motivi più comuni del problema includono:
+ Configurazione errata o utilizzo errato delle librerie dei client Kafka.
+ Comportamenti e bug predefiniti imprevisti con librerie di client di terze parti.
+ Controller sovraccarico con conseguente rallentamento dell'assegnazione del leader di partizione.
+ Viene eletto un nuovo controller, con conseguente rallentamento dell'assegnazione del leader di partizione.
Per garantire un comportamento corretto in caso di fallimento della leadership, consigliamo di:
+ È necessario seguire [le migliori pratiche](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html) lato server per garantire che il controller broker sia dimensionato in modo appropriato per evitare rallentamenti nell'assegnazione dei dirigenti.
+ Le librerie client devono avere i nuovi tentativi abilitati per garantire che il client gestisca il failover.
+ Le librerie client devono avere retry.backoff.ms configurato (impostazione predefinita 100) per evitare tempeste. connection/request
+ Le librerie client devono impostare request.timeout.ms e delivery.timeout.ms su valori in linea con lo SLA delle applicazioni. Valori più elevati comporteranno un failover più lento per determinati tipi di errore.
+ Le librerie client devono garantire che bootstrap.servers contenga almeno 3 broker casuali per evitare un impatto sulla disponibilità sulla scoperta iniziale.
+ Alcune librerie client sono di livello inferiore rispetto ad altre e si aspettano che lo sviluppatore dell'applicazione implementi autonomamente la logica dei tentativi e la gestione delle eccezioni. Fate riferimento alla documentazione specifica di Client Lib, ad esempio sull'utilizzo, e assicuratevi che venga seguita la reconnect/retry logica corretta.
+ Consigliamo di monitorare la latenza lato client per verificare la produzione, il conteggio delle richieste riuscite e il conteggio degli errori per errori non ripetibili.
+ Abbiamo osservato che le vecchie librerie golang e ruby di terze parti rimangono dettagliate durante l'intero periodo di tempo offline del broker, nonostante le richieste di produzione e consumo non ne risentano. Ti consigliamo di monitorare sempre le metriche a livello aziendale, oltre a quelle relative alle richieste di successo e agli errori, per determinare se i log registrano un impatto reale rispetto al rumore.
+ I clienti non devono allarmarsi per le eccezioni transitorie per network/not\$1leader, in quanto sono normali, ininfluenti e previste dal protocollo kafka.
+ I clienti non devono attivare gli allarmi in UnderReplicatedPartitions quanto sono normali, ininfluenti e previsti da un singolo broker offline.
# Sicurezza in Amazon MSK
La sicurezza del cloud AWS è la massima priorità. In qualità di AWS cliente, puoi beneficiare di un data center e di un'architettura di rete progettati per soddisfare i requisiti delle organizzazioni più sensibili alla sicurezza.
La sicurezza è una responsabilità condivisa tra AWS te e te. Il [modello di responsabilità condivisa](https://aws.amazon.com/compliance/shared-responsibility-model/) descrive questo aspetto come sicurezza *del* cloud e sicurezza *nel* cloud:
+ **Sicurezza del cloud**: AWS è responsabile della protezione dell'infrastruttura che gestisce AWS i servizi nel AWS cloud. AWS ti fornisce anche servizi che puoi utilizzare in modo sicuro. I revisori esterni testano e verificano regolarmente l'efficacia della nostra sicurezza nell'ambito dei [AWS Programmi di AWS conformità dei Programmi di conformità](https://aws.amazon.com/compliance/programs/) dei di . Per ulteriori informazioni sui programmi di conformità applicabili a Streaming gestito da Amazon per Apache Kafka, consulta la pagina [Amazon Web Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sicurezza nel cloud**: la responsabilità dell'utente è determinata dal AWS servizio che utilizza. Inoltre, sei responsabile anche di altri fattori, tra cui la riservatezza dei dati, i requisiti dell’azienda e le leggi e le normative applicabili.
La presente documentazione aiuta a comprendere come applicare il modello di responsabilità condivisa quando si utilizza Amazon MSK. Gli argomenti seguenti descrivono come configurare Amazon MSK per soddisfare gli obiettivi di sicurezza e conformità. Vengono inoltre fornite informazioni su come utilizzare altri servizi di Amazon Web Services che consentono di monitorare e proteggere le risorse Amazon MSK.
**Topics**
+ [Protezione dei dati in Streaming gestito da Amazon per Apache Kafka](data-protection.md)
+ [Autenticazione e autorizzazione per Amazon MSK APIs](security-iam.md)
+ [Autenticazione e autorizzazione per Apache Kafka APIs](kafka_apis_iam.md)
+ [Modifica del gruppo di sicurezza di un cluster Amazon MSK](change-security-group.md)
+ [Controlla l'accesso ai ZooKeeper nodi Apache nel tuo cluster Amazon MSK](zookeeper-security.md)
+ [Convalida della conformità per Streaming gestito da Amazon per Apache Kafka](MSK-compliance.md)
+ [Resilienza in Streaming gestito da Amazon per Apache Kafka](disaster-recovery-resiliency.md)
+ [Sicurezza dell'infrastruttura in Streaming gestito da Amazon per Apache Kafka](infrastructure-security.md)
# Protezione dei dati in Streaming gestito da Amazon per Apache Kafka
Il modello di [responsabilità AWS condivisa modello](https://aws.amazon.com/compliance/shared-responsibility-model/) si applica alla protezione dei dati in Amazon Managed Streaming for Apache Kafka. Come descritto in questo modello, AWS è responsabile della protezione dell'infrastruttura globale che gestisce tutti i. Cloud AWS L’utente è responsabile del controllo dei contenuti ospitati su questa infrastruttura. L’utente è inoltre responsabile della configurazione della protezione e delle attività di gestione per i Servizi AWS utilizzati. Per maggiori informazioni sulla privacy dei dati, consulta le [Domande frequenti sulla privacy dei dati](https://aws.amazon.com/compliance/data-privacy-faq/). Per informazioni sulla protezione dei dati in Europa, consulta il post del blog relativo al [AWS Modello di responsabilità condivisa e GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) nel *AWS Blog sulla sicurezza*.
Ai fini della protezione dei dati, consigliamo di proteggere Account AWS le credenziali e configurare i singoli utenti con AWS IAM Identity Center or AWS Identity and Access Management (IAM). In tal modo, a ogni utente verranno assegnate solo le autorizzazioni necessarie per svolgere i suoi compiti. Suggeriamo, inoltre, di proteggere i dati nei seguenti modi:
+ Utilizza l’autenticazione a più fattori (MFA) con ogni account.
+ SSL/TLS Da utilizzare per comunicare con AWS le risorse. È richiesto TLS 1.2 ed è consigliato TLS 1.3.
+ Configura l'API e la registrazione delle attività degli utenti con AWS CloudTrail. Per informazioni sull'utilizzo dei CloudTrail percorsi per acquisire AWS le attività, consulta [Lavorare con i CloudTrail percorsi](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) nella *Guida per l'AWS CloudTrail utente*.
+ Utilizza soluzioni di AWS crittografia, insieme a tutti i controlli di sicurezza predefiniti all'interno Servizi AWS.
+ Utilizza i servizi di sicurezza gestiti avanzati, come Amazon Macie, che aiutano a individuare e proteggere i dati sensibili archiviati in Amazon S3.
+ Se hai bisogno di moduli crittografici convalidati FIPS 140-3 per accedere AWS tramite un'interfaccia a riga di comando o un'API, usa un endpoint FIPS. Per ulteriori informazioni sugli endpoint FIPS disponibili, consulta il [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
Ti consigliamo di non inserire mai informazioni riservate o sensibili, ad esempio gli indirizzi e-mail dei clienti, nei tag o nei campi di testo in formato libero, ad esempio nel campo **Nome**. Ciò include quando lavori con Amazon MSK o altro Servizi AWS utilizzando la console, l'API o AWS SDKs. AWS CLI I dati inseriti nei tag o nei campi di testo in formato libero utilizzati per i nomi possono essere utilizzati per i la fatturazione o i log di diagnostica. Quando si fornisce un URL a un server esterno, suggeriamo vivamente di non includere informazioni sulle credenziali nell’URL per convalidare la richiesta al server.
**Topics**
+ [Crittografia di Amazon MSK](msk-encryption.md)
+ [Inizia a usare la crittografia Amazon MSK](msk-working-with-encryption.md)
+ [Usa Amazon MSK APIs con endpoint VPC di interfaccia](privatelink-vpc-endpoints.md)
# Crittografia di Amazon MSK
Amazon MSK fornisce opzioni di crittografia dei dati che puoi utilizzare per soddisfare rigidi requisiti di gestione dei dati. I certificati utilizzati da Amazon MSK per la crittografia devono essere rinnovati ogni 13 mesi. Amazon MSK rinnova automaticamente questi certificati per tutti i cluster. I cluster Express broker rimangono attivi quando Amazon MSK avvia l'operazione di aggiornamento dei certificati. `ACTIVE` Per i cluster di broker standard, Amazon MSK imposta lo stato del cluster su `MAINTENANCE` quando avvia l'operazione di aggiornamento dei certificati. MSK lo riporta a quando l'aggiornamento è terminato. `ACTIVE` Mentre un cluster è in corso l'operazione di aggiornamento dei certificati, è possibile continuare a produrre e consumare dati, ma non è possibile eseguire alcuna operazione di aggiornamento su di esso.
## Crittografia Amazon MSK a riposo
Amazon MSK si integra con [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/) (KMS) per offrire una crittografia lato server trasparente. Amazon MSK esegue sempre la crittografia dei dati a riposo. Quando crei un cluster Amazon MSK, puoi specificare la AWS KMS key che desideri far utilizzare ad Amazon MSK per crittografare i dati a riposo. Se non specifichi una chiave KMS, Amazon MSK crea una chiave KMS gestita da [Chiave gestita da AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) e la utilizza per tuo conto. Per ulteriori informazioni sulle chiavi KMS, consulta [AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys) nella *Guida per gli sviluppatori di AWS Key Management Service *.
## Crittografia Amazon MSK in transito
Amazon MSK utilizza TLS 1.2. Per impostazione predefinita, effettua la crittografia dei dati in transito tra i broker del cluster MSK. Puoi ignorare questa impostazione predefinita al momento della creazione del cluster.
Per la comunicazione tra client e broker, è necessario specificare una delle tre impostazioni seguenti:
+ Consenti solo dati crittografati TLS. Questa è l'impostazione predefinita.
+ Consenti dati non crittografati e dati crittografati TLS.
+ Consenti solo dati non crittografati.
I broker Amazon MSK utilizzano certificati pubblici AWS Certificate Manager . Pertanto, qualsiasi truststore che considera attendibili gli Amazon Trust Services considera attendibili anche i certificati dei broker Amazon MSK.
Anche se consigliamo vivamente di abilitare la crittografia dei dati in transito, questa potrebbe aggiungere un sovraccarico aggiuntivo della CPU e alcuni millisecondi di latenza. Tuttavia, la maggior parte dei casi d'uso non è sensibile a queste differenze e l'entità dell'impatto dipende dalla configurazione del cluster, dei client e del profilo di utilizzo.
# Inizia a usare la crittografia Amazon MSK
Durante la creazione di un cluster MSK, puoi specificare le impostazioni di crittografia in formato JSON. Di seguito è riportato un esempio di :
```
{
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "arn:aws:kms:us-east-1:123456789012:key/abcdabcd-1234-abcd-1234-abcd123e8e8e"
},
"EncryptionInTransit": {
"InCluster": true,
"ClientBroker": "TLS"
}
}
```
Per `DataVolumeKMSKeyId`, puoi specificare una [chiave gestita dal cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) o la Chiave gestita da AWS per MSK nel tuo account (`alias/aws/kafka`). Se non lo specifichi`EncryptionAtRest`, Amazon MSK crittografa comunque i tuoi dati inattivi in base a. Chiave gestita da AWS Per determinare la chiave utilizzata dal cluster, invia una richiesta `GET` o richiama l'operazione API `DescribeCluster`.
Per `EncryptionInTransit`, il valore predefinito di `InCluster` è true, ma puoi impostarlo su false se Amazon MSK non deve crittografare i dati durante il passaggio tra i broker.
Per specificare la modalità di crittografia per i dati in transito tra client e broker, imposta `ClientBroker` su uno di tre valori: `TLS`, `TLS_PLAINTEXT` o `PLAINTEXT`.
**Topics**
+ [Specificare le impostazioni di crittografia durante la creazione di un cluster Amazon MSK](msk-working-with-encryption-cluster-create.md)
+ [Prova la crittografia TLS di Amazon MSK](msk-working-with-encryption-test-tls.md)
# Specificare le impostazioni di crittografia durante la creazione di un cluster Amazon MSK
Questo processo descrive come specificare le impostazioni di crittografia durante la creazione di un cluster Amazon MSK.
**Specificare le impostazioni di crittografia durante la creazione di un cluster**
1. Salvare il contenuto dell'esempio precedente in un file e assegnare al file il nome desiderato. Ad esempio, chiamarlo `encryption-settings.json`.
1. Eseguire il comando `create-cluster` e utilizzare l'opzione `encryption-info` per puntare al file in cui il JSON di configurazione è stato salvato. Di seguito è riportato un esempio di : Sostituisci *\$1YOUR MSK VERSION\$1* con una versione che corrisponda alla versione del client Apache Kafka. Per informazioni su come trovare la versione del cluster MSK in uso, consulta la pagina [Determinazione della versione del cluster MSK](create-topic.md#find-msk-cluster-version). Tieni presente che l'utilizzo di una versione del client Apache Kafka diversa da quella del cluster MSK può causare il danneggiamento, la perdita dei dati e tempi di inattività di Apache Kafka.
```
aws kafka create-cluster --cluster-name "ExampleClusterName" --broker-node-group-info file://brokernodegroupinfo.json --encryption-info file://encryptioninfo.json --kafka-version "{YOUR MSK VERSION}" --number-of-broker-nodes 3
```
Di seguito è riportato un esempio di una risposta corretta dopo l'esecuzione di questo comando.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:123456789012:cluster/SecondTLSTest/abcdabcd-1234-abcd-1234-abcd123e8e8e",
"ClusterName": "ExampleClusterName",
"State": "CREATING"
}
```
# Prova la crittografia TLS di Amazon MSK
Questo processo descrive come testare la crittografia TLS su Amazon MSK.
**Per testare la crittografia TLS**
1. Creare un computer client seguendo le linee guida in [Passaggio 3: creazione di un computer client](create-client-machine.md).
1. Installare Apache Kafka sul computer client.
1. In questo esempio, utilizziamo il truststore JVM per comunicare con il cluster MSK. A tale scopo, creare innanzitutto una cartella denominata `/tmp` sul computer client. Quindi, passare alla cartella `bin` dell'installazione di Apache Kafka ed eseguire il seguente comando. (Il percorso JVM potrebbe essere diverso.)
```
cp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64/jre/lib/security/cacerts /tmp/kafka.client.truststore.jks
```
1. Sempre nella cartella `bin` dell'installazione di Apache Kafka sul computer client, creare un file di testo denominato `client.properties` con il seguente contenuto.
```
security.protocol=SSL
ssl.truststore.location=/tmp/kafka.client.truststore.jks
```
1. Esegui il comando seguente su un computer su cui è AWS CLI installato, sostituendolo *clusterARN* con l'ARN del tuo cluster.
```
aws kafka get-bootstrap-brokers --cluster-arn clusterARN
```
Se l'operazione riesce, il risultato sarà simile al seguente. Salvare questo risultato perché è necessario per la fase successiva.
```
{
"BootstrapBrokerStringTls": "a-1.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123,a-3.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123,a-2.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123"
}
```
1. Esegui il comando seguente, sostituendolo *BootstrapBrokerStringTls* con uno degli endpoint del broker ottenuti nel passaggio precedente.
```
/bin/kafka-console-producer.sh --broker-list BootstrapBrokerStringTls --producer.config client.properties --topic TLSTestTopic
```
1. Apri una nuova finestra di comando e connettiti allo stesso computer client. Quindi, esegui il comando seguente per creare un utente della console.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringTls --consumer.config client.properties --topic TLSTestTopic
```
1. Nella finestra del produttore, digita un messaggio di testo seguito da un invio e cerca lo stesso messaggio nella finestra del consumatore. Amazon MSK ha crittografato questo messaggio in transito.
Per ulteriori informazioni sulla configurazione dei client Apache Kafka per l'utilizzo di dati crittografati, consulta [Configuring Kafka Clients](https://kafka.apache.org/documentation/#security_configclients).
# Usa Amazon MSK APIs con endpoint VPC di interfaccia
Puoi utilizzare un endpoint VPC di interfaccia, alimentato da AWS PrivateLink, per impedire che il traffico tra Amazon VPC e Amazon MSK APIs lasci la rete Amazon. Gli endpoint VPC di interfaccia non richiedono un gateway Internet, un dispositivo NAT, una connessione VPN o una connessione Direct Connect AWS . [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)è una AWS tecnologia che consente la comunicazione privata tra AWS i servizi utilizzando un'interfaccia di rete elastica con private IPs nel tuo Amazon VPC. Per ulteriori informazioni, consulta [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) and [Interface VPC Endpoints ()](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint).AWS PrivateLink
Le tue applicazioni possono connettersi con Amazon MSK Provisioned e MSK Connect APIs utilizzando. AWS PrivateLink Per iniziare, crea un endpoint VPC di interfaccia per la tua API Amazon MSK per avviare il flusso di traffico da e verso le tue risorse Amazon VPC tramite l'endpoint VPC di interfaccia. Gli endpoint VPC con interfaccia FIPS sono disponibili per le regioni degli Stati Uniti. [Per ulteriori informazioni, consulta Create an Interface Endpoint.](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint)
Utilizzando questa funzionalità, i client Apache Kafka possono recuperare dinamicamente le stringhe di connessione per connettersi alle risorse MSK Provisioned o MSK Connect senza dover attraversare Internet per recuperare le stringhe di connessione.
Quando crei un endpoint VPC di interfaccia, scegli uno dei seguenti endpoint con nome di servizio:
**Per MSK Provisioned:**
+ I seguenti endpoint con nomi di servizio non sono più supportati per le nuove connessioni:
+ com.amazonaws.region.kafka
+ com.amazonaws.region.kafka-fips (compatibile con FIPS)
+ I servizi endpoint Dualstack che supportano entrambi e il traffico sono i seguenti: IPv4 IPv6
+ aws.api.region.kafka-api
+ aws.api.region. kafka-api-fips (abilitato per FIPS)
[Per configurare gli endpoint dualstack è necessario seguire le linee guida sugli endpoint Dual-stack e FIPS.](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html)
Dove region è il nome della tua regione. Scegliete questo nome di servizio per utilizzare MSK Provisioned APIs Compatible. *Per ulteriori informazioni, vedere [Operazioni](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html) nella versione 1.0/apireference/. https://docs.aws.amazon.com/msk/*
**Per MSK Connect:**
+ com.amazonaws.region.kafkaconnect
Dove regione è il nome della tua regione. Scegliete questo nome di servizio per lavorare con MSK Connect compatibile. APIs Per ulteriori informazioni, consulta [Azioni](https://docs.aws.amazon.com/MSKC/latest/mskc/API_Operations.html) nel *riferimento all'API Amazon MSK Connect*.
*Per ulteriori informazioni, incluse step-by-step le istruzioni per creare un endpoint VPC di interfaccia, vedere [Creazione di un endpoint di interfaccia nella Guida](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint).AWS PrivateLink *
## Controlla l'accesso agli endpoint VPC per Amazon MSK Provisioned o MSK Connect APIs
Le policy degli endpoint VPC consentono di controllare l'accesso allegando una policy a un endpoint VPC o utilizzando campi aggiuntivi in una policy allegata a un utente, gruppo o ruolo IAM per limitare l'accesso solo tramite l'endpoint VPC specificato. Utilizzare la politica di esempio appropriata per definire le autorizzazioni di accesso per il servizio MSK Provisioned o MSK Connect.
Se non colleghi una policy durante la creazione di un endpoint, Amazon VPC collega una policy predefinita che consente l'accesso completo al servizio. Una policy endpoint non esclude né sostituisce policy IAM basate sull'identità o policy specifiche del servizio. Si tratta di una policy separata per controllare l'accesso dall'endpoint al servizio specificato.
*Per ulteriori informazioni, consulta [Controllare l'accesso ai servizi con gli endpoint VPC nella Guida](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html).AWS PrivateLink *
------
#### [ MSK Provisioned — VPC policy example ]
**Accesso in sola lettura**
Questa policy di esempio può essere associata a un endpoint VPC. Per ulteriori informazioni, consulta Controllo dell'accesso alle risorse VPC di Amazon. Limita le azioni solo a elencare e descrivere le operazioni tramite l'endpoint VPC a cui è collegato.
```
{
"Statement": [
{
"Sid": "MSKReadOnly",
"Principal": "*",
"Action": [
"kafka:List*",
"kafka:Describe*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
**MSK Provisioned — Esempio di policy per gli endpoint VPC**
Limita l'accesso a un cluster MSK specifico
Questa policy di esempio può essere associata a un endpoint VPC. Limita l'accesso a uno specifico cluster Kafka tramite l'endpoint VPC a cui è collegato.
```
{
"Statement": [
{
"Sid": "AccessToSpecificCluster",
"Principal": "*",
"Action": "kafka:*",
"Effect": "Allow",
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster"
}
]
}
```
------
#### [ MSK Connect — VPC endpoint policy example ]
**Elenca i connettori e crea un nuovo connettore**
Di seguito è riportato un esempio di policy sugli endpoint per MSK Connect. Questa politica consente al ruolo specificato di elencare i connettori e creare un nuovo connettore.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "MSKConnectPermissions",
"Effect": "Allow",
"Action": [
"kafkaconnect:ListConnectors",
"kafkaconnect:CreateConnector"
],
"Resource": "*",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/MyMSKConnectExecutionRole"
]
}
}
]
}
```
**MSK Connect — Esempio di policy per gli endpoint VPC**
Consente solo le richieste provenienti da un indirizzo IP specifico nel VPC specificato
L'esempio seguente mostra una policy che consente l'esito positivo solo delle richieste provenienti da un indirizzo IP specificato nel VPC specificato. Le richieste provenienti da altri indirizzi IP avranno esito negativo.
```
{
"Statement": [
{
"Action": "kafkaconnect:*",
"Effect": "Allow",
"Principal": "*",
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:VpcSourceIp": "192.0.2.123"
},
"StringEquals": {
"aws:SourceVpc": "vpc-555555555555"
}
}
}
]
}
```
------
# Autenticazione e autorizzazione per Amazon MSK APIs
AWS Identity and Access Management (IAM) è uno strumento Servizio AWS che aiuta un amministratore a controllare in modo sicuro l'accesso alle risorse. AWS Gli amministratori IAM controllano chi può essere *autenticato* (accesso effettuato) e *autorizzato* (dotato di autorizzazioni) per utilizzare le risorse Amazon MSK. IAM è un software Servizio AWS che puoi utilizzare senza costi aggiuntivi.
**Topics**
+ [Funzionamento di Amazon MSK con IAM](security_iam_service-with-iam.md)
+ [Esempi di policy basate sull'identità per Amazon MSK](security_iam_id-based-policy-examples.md)
+ [Ruoli collegati ai servizi per Amazon MSK](using-service-linked-roles.md)
+ [AWS politiche gestite per Amazon MSK](security-iam-awsmanpol.md)
+ [Risolvi i problemi relativi all'identità e all'accesso ad Amazon MSK](security_iam_troubleshoot.md)
# Funzionamento di Amazon MSK con IAM
Prima di utilizzare IAM per gestire l'accesso ad Amazon MSK, è necessario comprendere quali funzioni IAM sono disponibili per l'uso con Amazon MSK. Per avere una visione di alto livello di come Amazon MSK e altri AWS servizi funzionano con IAM, consulta [AWS Services That Work with IAM nella IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) *User Guide*.
**Topics**
+ [Policy basate sull'identità di Amazon MSK](security_iam_service-with-iam-id-based-policies.md)
+ [Policy basate sulle risorse di Amazon MSK](security_iam_service-with-iam-resource-based-policies.md)
+ [Autorizzazione basata sui tag Amazon MSK](security_iam_service-with-iam-tags.md)
+ [Ruoli IAM di Amazon MSK](security_iam_service-with-iam-roles.md)
# Policy basate sull'identità di Amazon MSK
Con le policy basate sull’identità di IAM, è possibile specificare quali operazioni e risorse sono consentite o respinte, nonché le condizioni in base alle quali le operazioni sono consentite o respinte. Amazon MSK supporta operazioni, risorse e chiavi di condizione specifiche. Per informazioni su tutti gli elementi utilizzati in una policy JSON, consulta [Documentazione di riferimento degli elementi delle policy JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) nella *Guida per l'utente IAM*.
## Azioni per le politiche basate sull'identità di Amazon MSK
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L'elemento `Action` di una policy JSON descrive le operazioni che è possibile utilizzare per consentire o negare l'accesso in una policy. Includere le operazioni in una policy per concedere le autorizzazioni a eseguire l’operazione associata.
Le operazioni delle policy in Amazon MSK utilizzano il seguente prefisso prima dell'operazione: `kafka:`. Ad esempio, per concedere a qualcuno l'autorizzazione per descrivere un cluster MSK con l'operazione API `DescribeCluster` di Amazon MSK, includi l'operazione `kafka:DescribeCluster` nella policy. Le istruzioni della policy devono includere un elemento `Action` o `NotAction`. Amazon MSK definisce un proprio set di operazioni che descrivono le attività che puoi eseguire con quel servizio.
Tieni presente che le azioni politiche per l'argomento MSK APIs utilizzano il `kafka-cluster` prefisso prima dell'azione, consulta. [Semantica delle azioni e delle risorse della politica di autorizzazione IAM](kafka-actions.md)
Per specificare più azioni in una sola istruzione, separa ciascuna di esse con una virgola come mostrato di seguito:
```
"Action": ["kafka:action1", "kafka:action2"]
```
È possibile specificare più azioni tramite caratteri jolly (\$1). Ad esempio, per specificare tutte le azioni che iniziano con la parola `Describe`, includi la seguente azione:
```
"Action": "kafka:Describe*"
```
Per visualizzare un elenco delle operazioni di Amazon MSK, consulta la pagina [Actions, resources, and condition keys for Amazon Managed Streaming for Apache Kafka](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonmanagedstreamingforapachekafka.html) nella *Guida per l'utente di IAM*.
## Risorse per le politiche basate sull'identità di Amazon MSK
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L’elemento JSON `Resource` della policy specifica l’oggetto o gli oggetti ai quali si applica l’operazione. Come best practice, specifica una risorsa utilizzando il suo [nome della risorsa Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Per le azioni che non supportano le autorizzazioni a livello di risorsa, si utilizza un carattere jolly (\$1) per indicare che l’istruzione si applica a tutte le risorse.
```
"Resource": "*"
```
La risorsa istanza di Amazon MSK dispone del seguente ARN:
```
arn:${Partition}:kafka:${Region}:${Account}:cluster/${ClusterName}/${UUID}
```
Per ulteriori informazioni sul formato di ARNs, consulta [Amazon Resource Names (ARNs) e AWS Service Namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
Ad esempio, per specificare l'istanza `CustomerMessages` nell'istruzione, utilizza il seguente ARN:
```
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/CustomerMessages/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2"
```
Per specificare tutti le istanze che appartengono ad un account specifico, utilizza il carattere jolly (\$1):
```
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/*"
```
Alcune operazioni di Amazon MSK, ad esempio quelle per la creazione delle risorse, non possono essere eseguite su una risorsa specifica. In questi casi, è necessario utilizzare il carattere jolly (\$1).
```
"Resource": "*"
```
Per specificare più risorse in una singola istruzione, separale con virgole. ARNs
```
"Resource": ["resource1", "resource2"]
```
*Per visualizzare un elenco dei tipi di risorse Amazon MSK e relativi ARNs, consulta [Resources Defined by Amazon Managed Streaming for Apache](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-resources-for-iam-policies) Kafka nella IAM User Guide.* Per informazioni sulle operazioni con cui è possibile specificare l'ARN di ogni risorsa, consulta la pagina [Actions Defined by Amazon Managed Service for Apache Kafka](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-actions-as-permissions).
## Chiavi di condizione per le politiche basate sull'identità di Amazon MSK
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L’elemento `Condition` specifica quando le istruzioni vengono eseguite in base a criteri definiti. È possibile compilare espressioni condizionali che utilizzano [operatori di condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), ad esempio uguale a o minore di, per soddisfare la condizione nella policy con i valori nella richiesta. Per visualizzare tutte le chiavi di condizione AWS globali, consulta le chiavi di [contesto delle condizioni AWS globali nella Guida](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) per l'*utente IAM*.
Amazon MSK definisce il proprio set di chiavi di condizione e supporta anche l'utilizzo di alcune chiavi di condizione globali. Per vedere tutte le chiavi di condizione AWS globali, consulta [AWS Global Condition Context Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) nella *Guida per l'utente IAM*.
Per visualizzare un elenco delle chiavi di condizione di Amazon MSK, consulta la pagina [Condition Keys for Amazon Managed Streaming for Apache Kafka](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-policy-keys) nella *Guida per l'utente di IAM*. Per informazioni sulle operazioni e le risorse con le quali è possibile utilizzare una chiave di condizione, consulta la pagina [Actions Defined by Amazon Managed Service for Apache Kafka](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-actions-as-permissions).
## Esempi di policy basate sull'identità di Amazon MSK
Per visualizzare degli esempi di policy basate sull'identità di Amazon MSK, consulta la pagina [Esempi di policy basate sull'identità per Amazon MSK](security_iam_id-based-policy-examples.md).
# Policy basate sulle risorse di Amazon MSK
Amazon MSK supporta una policy del cluster (nota anche come policy basata sulle risorse) da utilizzare con i cluster Amazon MSK. Puoi utilizzare una policy del cluster per definire quali principali IAM dispongono delle autorizzazioni multi-account per configurare la connettività privata al tuo cluster Amazon MSK. In combinazione con l'autenticazione del client IAM, puoi utilizzare la policy del cluster anche per definire in modo granulare le autorizzazioni del piano dati Kafka per i client che si connettono.
La dimensione massima supportata per una policy di cluster è di 20 KB.
Per visualizzare un esempio di come configurare una policy del cluster, consulta la sezione [Passaggio 2: collegamento di una policy del cluster al cluster MSK](mvpc-cluster-owner-action-policy.md).
# Autorizzazione basata sui tag Amazon MSK
È possibile associare tag ai cluster Amazon MSK. Per controllare l’accesso basato su tag, fornire informazioni sui tag nell’[elemento condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) di una policy utilizzando le chiavi di condizione `kafka:ResourceTag/key-name`, `aws:RequestTag/key-name` o `aws:TagKeys`. Per informazioni sull'etichettatura delle risorse Amazon MSK, consulta. [Contrassegna un tag a un cluster Amazon MSK](msk-tagging.md)
Puoi controllare l'accesso al cluster solo con l'aiuto dei tag. Per etichettare argomenti e gruppi di consumatori, devi aggiungere una dichiarazione separata nelle tue politiche senza tag.
Per visualizzare un esempio di politica basata sull'identità per limitare l'accesso a un cluster in base ai tag di quel cluster, vedi. [Accesso ai cluster Amazon MSK in base ai tag](security_iam_id-based-policy-examples-view-widget-tags.md)
Nella policy basata sull'identità, puoi utilizzare le condizioni per controllare l'accesso alle risorse Amazon MSK in base ai tag. L'esempio seguente mostra una policy che consente a un utente di descrivere il cluster, ottenere i relativi broker bootstrap, elencare i relativi nodi broker, aggiornarlo ed eliminarlo. Tuttavia, questa politica concede l'autorizzazione solo se il tag del cluster `Owner` ha il valore di quell'utente. `username` La seconda dichiarazione della seguente politica consente l'accesso agli argomenti del cluster. La prima dichiarazione di questa politica non autorizza l'accesso ad alcun argomento.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessClusterIfOwner",
"Effect": "Allow",
"Action": [
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*",
"kafka:Delete*"
],
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/*"
]
}
]
}
```
------
# Ruoli IAM di Amazon MSK
Un [ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) è un'entità all'interno dell'account Amazon Web Services che dispone di autorizzazioni specifiche.
## Utilizzo delle credenziali temporanee con Amazon MSK
È possibile utilizzare credenziali temporanee per effettuare l'accesso con la federazione, assumere un ruolo IAM o un ruolo multi-account. È possibile ottenere credenziali di sicurezza temporanee chiamando operazioni AWS STS API come [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)o. [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)
Amazon MSK supporta l'uso delle credenziali temporanee.
## Ruoli collegati ai servizi
I [ruoli collegati ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) permettono ad Amazon Web Services di accedere a risorse in altri servizi per completare un'operazione a tuo nome. I ruoli collegati ai servizi sono visualizzati nell'account IAM e sono di proprietà del servizio. Un amministratore può visualizzare, ma non modificare le autorizzazioni dei ruoli collegati ai servizi.
Amazon MSK supporta i ruoli collegati ai servizi. Per maggiori dettagli su come creare e gestire i ruoli collegati ai servizi di Amazon MSK, consulta la pagina [Ruoli collegati ai servizi per Amazon MSK](using-service-linked-roles.md).
# Esempi di policy basate sull'identità per Amazon MSK
Per impostazione predefinita, gli utenti e i ruoli IAM non sono autorizzati a eseguire le operazioni API di Amazon MSK. Un amministratore deve creare le policy IAM che concedono a utenti e ruoli l'autorizzazione per eseguire operazioni API specifiche sulle risorse specificate di cui hanno bisogno. L'amministratore deve quindi allegare queste policy a utenti o IAM che richiedono tali autorizzazioni.
Per informazioni su come creare una policy basata su identità IAM utilizzando questi documenti di policy JSON di esempio, consulta [Creazione di policy nella scheda JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) nella *Guida per l'utente IAM*.
**Topics**
+ [Best practice delle policy](security_iam_service-with-iam-policy-best-practices.md)
+ [Consentire agli utenti di visualizzare le loro autorizzazioni](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [Accesso a un cluster Amazon MSK](security_iam_id-based-policy-examples-access-one-cluster.md)
+ [Accesso ai cluster Amazon MSK in base ai tag](security_iam_id-based-policy-examples-view-widget-tags.md)
# Best practice delle policy
Le policy basate sull'identità determinano se qualcuno può creare, accedere o eliminare risorse Amazon MSK all'interno dell'account. Queste azioni possono comportare costi aggiuntivi per l’ Account AWS. Quando si creano o modificano policy basate sull’identità, seguire queste linee guida e raccomandazioni:
+ **Inizia con le policy AWS gestite e passa alle autorizzazioni con privilegi minimi: per iniziare a concedere autorizzazioni** a utenti e carichi di lavoro, utilizza le *politiche AWS gestite* che concedono le autorizzazioni per molti casi d'uso comuni. Sono disponibili nel tuo. Account AWS Ti consigliamo di ridurre ulteriormente le autorizzazioni definendo politiche gestite dai AWS clienti specifiche per i tuoi casi d'uso. Per maggiori informazioni, consulta [Policy gestite da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) o [Policy gestite da AWS per le funzioni dei processi](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) nella *Guida per l’utente di IAM*.
+ **Applicazione delle autorizzazioni con privilegio minimo** - Quando si impostano le autorizzazioni con le policy IAM, concedere solo le autorizzazioni richieste per eseguire un’attività. È possibile farlo definendo le azioni che possono essere intraprese su risorse specifiche in condizioni specifiche, note anche come *autorizzazioni con privilegio minimo*. Per maggiori informazioni sull’utilizzo di IAM per applicare le autorizzazioni, consulta [Policy e autorizzazioni in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) nella *Guida per l’utente di IAM*.
+ **Condizioni d’uso nelle policy IAM per limitare ulteriormente l’accesso** - Per limitare l’accesso ad azioni e risorse è possibile aggiungere una condizione alle policy. Ad esempio, è possibile scrivere una condizione di policy per specificare che tutte le richieste devono essere inviate utilizzando SSL. Puoi anche utilizzare le condizioni per concedere l'accesso alle azioni del servizio se vengono utilizzate tramite uno specifico Servizio AWS, ad esempio CloudFormation. Per maggiori informazioni, consultare la sezione [Elementi delle policy JSON di IAM: condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) nella *Guida per l’utente di IAM*.
+ **Utilizzo dello strumento di analisi degli accessi IAM per convalidare le policy IAM e garantire autorizzazioni sicure e funzionali** - Lo strumento di analisi degli accessi IAM convalida le policy nuove ed esistenti in modo che aderiscano al linguaggio (JSON) della policy IAM e alle best practice di IAM. Lo strumento di analisi degli accessi IAM offre oltre 100 controlli delle policy e consigli utili per creare policy sicure e funzionali. Per maggiori informazioni, consultare [Convalida delle policy per il Sistema di analisi degli accessi IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) nella *Guida per l’utente di IAM*.
+ **Richiedi l'autenticazione a più fattori (MFA**): se hai uno scenario che richiede utenti IAM o un utente root nel Account AWS tuo, attiva l'MFA per una maggiore sicurezza. Per richiedere la MFA quando vengono chiamate le operazioni API, aggiungere le condizioni MFA alle policy. Per maggiori informazioni, consultare [Protezione dell’accesso API con MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) nella *Guida per l’utente di IAM*.
Per maggiori informazioni sulle best practice in IAM, consulta [Best practice di sicurezza in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) nella *Guida per l’utente di IAM*.
# Consentire agli utenti di visualizzare le loro autorizzazioni
Questo esempio mostra in che modo è possibile creare una policy che consente agli utenti IAM di visualizzare le policy inline e gestite che sono collegate alla relativa identità utente. Questa policy include le autorizzazioni per completare questa azione sulla console o utilizzando programmaticamente l'API o. AWS CLI AWS
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# Accesso a un cluster Amazon MSK
In questo esempio, si desidera concedere a un utente IAM nell'account Amazon Web Services l'accesso a uno dei cluster, `purchaseQueriesCluster`. Questa policy consente all'utente di descrivere il cluster, ottenere i broker bootstrap, elencare i nodi broker e aggiornarlo.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"UpdateCluster",
"Effect":"Allow",
"Action":[
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*"
],
"Resource":"arn:aws:kafka:us-east-1:012345678012:cluster/purchaseQueriesCluster/abcdefab-1234-abcd-5678-cdef0123ab01-2"
}
]
}
```
------
# Accesso ai cluster Amazon MSK in base ai tag
Nella policy basata sull'identità, puoi utilizzare le condizioni per controllare l'accesso alle risorse Amazon MSK in base ai tag. In questo esempio viene illustrato come creare una policy che consente all'utente di descrivere il cluster, ottenere i broker bootstrap, elencare i nodi broker, aggiornarlo ed eliminarlo. Tuttavia, l'autorizzazione viene concessa solo se il valore del tag di cluster `Owner` è quello del nome utente.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessClusterIfOwner",
"Effect": "Allow",
"Action": [
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*",
"kafka:Delete*"
],
"Resource": "arn:aws:kafka:us-east-1:012345678012:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
}
]
}
```
------
Puoi allegare questa policy agli utenti IAM nel tuo account. Se un utente denominato `richard-roe` tenta di aggiornare un cluster MSK, al cluster deve essere applicato il tag `Owner=richard-roe` o `owner=richard-roe`. In caso contrario, gli viene negato l'accesso. La chiave di tag di condizione `Owner` corrisponde a `Owner` e `owner` perché i nomi delle chiavi di condizione non effettuano la distinzione tra maiuscole e minuscole. Per ulteriori informazioni, consulta la sezione [Elementi delle policy JSON di IAM: condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) nella *Guida per l'utente di IAM*.
# Ruoli collegati ai servizi per Amazon MSK
Amazon MSK utilizza ruoli collegati ai [servizi AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Un ruolo collegato ai servizi è un tipo di ruolo IAM univoco collegato direttamente ad Amazon MSK. I ruoli collegati ai servizi sono predefiniti da Amazon MSK e includono tutte le autorizzazioni richieste dal servizio per chiamare altri AWS servizi per tuo conto.
Un ruolo collegato ai servizi semplifica la configurazione di Amazon MSK perché consente di evitare l'aggiunta manuale delle autorizzazioni necessarie. Amazon MSK definisce le autorizzazioni dei ruoli collegati ai servizi. Se non diversamente definito, solo Amazon MSK può assumere i suoi ruoli. Le autorizzazioni definite includono la policy di attendibilità e la policy delle autorizzazioni. Una policy delle autorizzazioni specifica non può essere collegata a un'altra entità IAM.
Per informazioni sugli altri servizi che supportano i ruoli collegati ai servizi, consulta la pagina [Amazon Web Services That Work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e cerca i servizi che riportano **Sì **nella colonna **Ruolo collegato ai servizi**. Scegliere **Sì** in corrispondenza di un link per visualizzare la documentazione relativa al ruolo collegato al servizio per tale servizio.
**Topics**
+ [Autorizzazioni del ruolo collegato ai servizi](slr-permissions.md)
+ [Crea un ruolo collegato al servizio](create-slr.md)
+ [Modifica di un ruolo collegato al servizio](edit-slr.md)
+ [Regioni supportate per i ruoli collegati ai servizi](slr-regions.md)
# Autorizzazioni del ruolo collegato ai servizi per Amazon MSK
Amazon MSK usa il ruolo collegato ai servizi denominato **AWSServiceRoleForKafka**. Amazon MSK utilizza questo ruolo per accedere alle risorse ed eseguire operazioni come:
+ `*NetworkInterface`: crea e gestisci interfacce di rete nell'account cliente che rendano i broker del cluster accessibili ai client nel VPC del cliente.
+ `*VpcEndpoints`— gestire gli endpoint VPC nell'account cliente che rendono i broker di cluster accessibili ai clienti nel VPC del cliente utilizzando. AWS PrivateLink Amazon MSK utilizza le autorizzazioni per `DescribeVpcEndpoints`, `ModifyVpcEndpoint` e `DeleteVpcEndpoints`.
+ `secretsmanager`— gestisci le credenziali dei clienti con. Gestione dei segreti AWS
+ `GetCertificateAuthorityCertificate`: recupera il certificato per la tua autorità di certificazione privata.
+ `*Ipv6Addresses`— assegna e annulla l'assegnazione di IPv6 indirizzi alle interfacce di rete nell'account cliente per abilitare la connettività per i cluster MSK. IPv6
+ `ModifyNetworkInterfaceAttribute`— modifica gli attributi dell'interfaccia di rete nell'account cliente per configurare IPv6 le impostazioni per la connettività del cluster MSK.
Questo ruolo collegato ai servizi è collegato alle seguenti policy gestite: `KafkaServiceRolePolicy`. Per gli aggiornamenti a questa policy, consulta [KafkaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/KafkaServiceRolePolicy.html).
Ai fini dell’assunzione del ruolo, il ruolo collegato al servizio AWSServiceRoleForKafka considera attendibili i seguenti servizi:
+ `kafka.amazonaws.com`
La policy delle autorizzazioni del ruolo consente ad Amazon MSK di completare le seguenti operazioni sulle risorse.
Per consentire a un'entità IAM (come un utente, un gruppo o un ruolo) di creare, modificare o eliminare un ruolo collegato al servizio è necessario configurare le relative autorizzazioni. Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) nella *Guida per l'utente di IAM*.
# Crea un ruolo collegato ai servizi per Amazon MSK
Non è necessario creare manualmente un ruolo collegato ai servizi. Quando crei un cluster Amazon MSK nell'API Console di gestione AWS, nell'o nell' AWS API AWS CLI, Amazon MSK crea automaticamente il ruolo collegato al servizio.
Se elimini questo ruolo collegato al servizio, è possibile ricrearlo seguendo lo stesso processo utilizzato per ricreare il ruolo nell’account. Quando si crea un cluster Amazon MSK, Amazon MSK crea di nuovo automaticamente il ruolo collegato ai servizi per conto dell'utente.
# Modificare un ruolo collegato al servizio per Amazon MSK
Amazon MSK non consente di modificare il ruolo collegato al servizio AWSServiceRoleForKafka. Dopo avere creato un ruolo collegato al servizio, non sarà possibile modificarne il nome perché varie entità potrebbero farvi riferimento. È possibile tuttavia modificarne la descrizione utilizzando IAM. Per ulteriori informazioni, consulta la sezione [Modifica di un ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) nella *Guida per l'utente di IAM*.
# Regioni supportate per i ruoli collegati ai servizi di Amazon MSK
Amazon MSK supporta l'utilizzo di ruoli collegati ai servizi in tutte le regioni in cui il servizio è disponibile. Per ulteriori informazioni, consulta [AWS Regioni ed endpoint](https://docs.aws.amazon.com/general/latest/gr/rande.html).
# AWS politiche gestite per Amazon MSK
Una politica AWS gestita è una politica autonoma creata e amministrata da. AWS AWS le politiche gestite sono progettate per fornire autorizzazioni per molti casi d'uso comuni, in modo da poter iniziare ad assegnare autorizzazioni a utenti, gruppi e ruoli.
Tieni presente che le policy AWS gestite potrebbero non concedere le autorizzazioni con il privilegio minimo per i tuoi casi d'uso specifici, poiché sono disponibili per tutti i clienti. AWS Si consiglia pertanto di ridurre ulteriormente le autorizzazioni definendo [policy gestite dal cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) specifiche per i propri casi d'uso.
Non è possibile modificare le autorizzazioni definite nelle politiche gestite. AWS Se AWS aggiorna le autorizzazioni definite in una politica AWS gestita, l'aggiornamento ha effetto su tutte le identità principali (utenti, gruppi e ruoli) a cui è associata la politica. AWS è più probabile che aggiorni una policy AWS gestita quando ne Servizio AWS viene lanciata una nuova o quando diventano disponibili nuove operazioni API per i servizi esistenti.
Per ulteriori informazioni, consultare [Policy gestite da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) nella *Guida per l'utente di IAM*.
# AWS politica gestita: Amazon MSKFull Access
Questa policy concede autorizzazioni amministrative che consentono a un principale l'accesso completo a tutte le operazioni di Amazon MSK. Le autorizzazioni in questa policy sono raggruppate come segue:
+ Le autorizzazioni Amazon MSK consentono tutte le operazioni di Amazon MSK.
+ **`Amazon EC2`autorizzazioni**: in questa politica sono necessarie per convalidare le risorse passate in una richiesta API. Questo serve a garantire che Amazon MSK sia in grado di utilizzare correttamente le risorse di un cluster. Le altre autorizzazioni di Amazon EC2 incluse in questa policy consentono ad Amazon MSK di creare AWS le risorse necessarie per consentirti di connetterti ai tuoi cluster.
+ **`AWS KMS`autorizzazioni**: vengono utilizzate durante le chiamate API per convalidare le risorse passate in una richiesta. Sono necessarie per consentire ad Amazon MSK di utilizzare la chiave passata con il cluster Amazon MSK.
+ **`CloudWatch Logs, Amazon S3, and Amazon Data Firehose`autorizzazioni**: sono necessarie per consentire ad Amazon MSK di garantire che le destinazioni di consegna dei log siano raggiungibili e che siano valide per l'utilizzo dei log da parte dei broker.
+ **`IAM`autorizzazioni**: sono necessarie per consentire ad Amazon MSK di creare un ruolo collegato al servizio nel tuo account e per consentirti di passare un ruolo di esecuzione del servizio ad Amazon MSK.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"kafka:*",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeSecurityGroups",
"ec2:DescribeRouteTables",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcAttribute",
"kms:DescribeKey",
"kms:CreateGrant",
"logs:CreateLogDelivery",
"logs:GetLogDelivery",
"logs:UpdateLogDelivery",
"logs:DeleteLogDelivery",
"logs:ListLogDeliveries",
"logs:PutResourcePolicy",
"logs:DescribeResourcePolicies",
"logs:DescribeLogGroups",
"S3:GetBucketPolicy",
"firehose:TagDeliveryStream"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:*:ec2:*:*:vpc/*",
"arn:*:ec2:*:*:subnet/*",
"arn:*:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:*:ec2:*:*:vpc-endpoint/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/AWSMSKManaged": "true"
},
"StringLike": {
"aws:RequestTag/ClusterArn": "*"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:*:ec2:*:*:vpc-endpoint/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateVpcEndpoint"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteVpcEndpoints"
],
"Resource": "arn:*:ec2:*:*:vpc-endpoint/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AWSMSKManaged": "true"
},
"StringLike": {
"ec2:ResourceTag/ClusterArn": "*"
}
}
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "kafka.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/kafka.amazonaws.com/AWSServiceRoleForKafka*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "kafka.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/kafka.amazonaws.com/AWSServiceRoleForKafka*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/delivery.logs.amazonaws.com/AWSServiceRoleForLogDelivery*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "delivery.logs.amazonaws.com"
}
}
}
]
}
```
------
# AWS politica gestita: Amazon MSKRead OnlyAccess
Questa policy concede autorizzazioni di sola lettura che consentono agli utenti di visualizzare informazioni in Amazon MSK. I principali ai quali è collegata questa policy non possono effettuare aggiornamenti o eliminare risorse esistenti, né possono creare nuove risorse Amazon MSK. Ad esempio, i principali con queste autorizzazioni possono visualizzare l'elenco dei cluster e delle configurazioni associati al proprio account, ma non possono modificare la configurazione o le impostazioni di alcun cluster. Le autorizzazioni in questa policy sono raggruppate come segue:
+ **`Amazon MSK`autorizzazioni**: consentono di elencare le risorse Amazon MSK, descriverle e ottenere informazioni su di esse.
+ **`Amazon EC2`autorizzazioni**: vengono utilizzate per descrivere Amazon VPC, le sottoreti, i gruppi di sicurezza ENIs e sono associati a un cluster.
+ **`AWS KMS`autorizzazione**: viene utilizzata per descrivere la chiave associata al cluster.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"kafka:Describe*",
"kafka:List*",
"kafka:Get*",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"kms:DescribeKey"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
# AWS politica gestita: KafkaServiceRolePolicy
Non puoi collegarti KafkaServiceRolePolicy alle tue entità IAM. Questa policy è collegata a un ruolo collegato ai servizi che consente ad Amazon MSK di eseguire operazioni come la gestione degli endpoint VPC (connettori) nei cluster MSK, la gestione delle interfacce di rete e la gestione delle credenziali del cluster con Gestione dei segreti AWS. Per ulteriori informazioni, consulta [Ruoli collegati ai servizi per Amazon MSK](using-service-linked-roles.md).
La tabella seguente descrive gli aggiornamenti alla policy KafkaServiceRolePolicy gestita da quando Amazon MSK ha iniziato a tracciare le modifiche.
| Modifica | Descrizione | Data |
| --- | --- | --- |
| [IPv6 supporto per la connettività aggiunto a KafkaServiceRolePolicy](#security-iam-awsmanpol-KafkaServiceRolePolicy): aggiornamento di una policy esistente | Amazon MSK ha aggiunto le autorizzazioni per KafkaServiceRolePolicy abilitare la IPv6 connettività per i cluster MSK. Queste autorizzazioni consentono ad Amazon MSK di assegnare e annullare l'assegnazione di IPv6 indirizzi alle interfacce di rete e di modificare gli attributi dell'interfaccia di rete nell'account del cliente. | 17 novembre 2025 |
| [KafkaServiceRolePolicy](#security-iam-awsmanpol-KafkaServiceRolePolicy): aggiornamento di una policy esistente | Amazon MSK ha aggiunto le autorizzazioni per supportare la connettività privata multi-VPC. | 8 marzo 2023 |
| Amazon MSK ha iniziato a tenere traccia delle modifiche | Amazon MSK ha iniziato a tracciare le modifiche per le policy KafkaServiceRolePolicy gestite. | 8 marzo 2023 |
# AWS politica gestita: AWSMSKReplicator ExecutionRole
La `AWSMSKReplicatorExecutionRole` policy concede le autorizzazioni al replicatore Amazon MSK per replicare i dati tra cluster MSK. Le autorizzazioni in questa policy sono raggruppate come segue:
+ **`cluster`**— Concede ad Amazon MSK Replicator le autorizzazioni per connettersi al cluster utilizzando l'autenticazione IAM. Concede inoltre le autorizzazioni per descrivere e modificare il cluster.
+ **`topic`**— Concede ad Amazon MSK Replicator le autorizzazioni per descrivere, creare e modificare un argomento e per modificare la configurazione dinamica dell'argomento.
+ **`consumer group`**— Concede ad Amazon MSK Replicator le autorizzazioni per descrivere e modificare gruppi di consumatori, leggere e scrivere dati da un cluster MSK e eliminare argomenti interni creati dal replicatore.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ClusterPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:DescribeCluster",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeTopic",
"kafka-cluster:CreateTopic",
"kafka-cluster:AlterTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData",
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup",
"kafka-cluster:DescribeTopicDynamicConfiguration",
"kafka-cluster:AlterTopicDynamicConfiguration",
"kafka-cluster:WriteDataIdempotently"
],
"Resource": [
"arn:aws:kafka:*:*:cluster/*"
]
},
{
"Sid": "TopicPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:DescribeTopic",
"kafka-cluster:CreateTopic",
"kafka-cluster:AlterTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData",
"kafka-cluster:DescribeTopicDynamicConfiguration",
"kafka-cluster:AlterTopicDynamicConfiguration",
"kafka-cluster:AlterCluster"
],
"Resource": [
"arn:aws:kafka:*:*:topic/*/*"
]
},
{
"Sid": "GroupPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup"
],
"Resource": [
"arn:aws:kafka:*:*:group/*/*"
]
}
]
}
```
------
# Amazon MSK aggiorna le politiche AWS gestite
Visualizza i dettagli sugli aggiornamenti delle politiche AWS gestite per Amazon MSK da quando questo servizio ha iniziato a tracciare queste modifiche.
| Modifica | Descrizione | Data |
| --- | --- | --- |
| [WriteDataIdempotently autorizzazione aggiunta a AWSMSKReplicator ExecutionRole](security-iam-awsmanpol-AWSMSKReplicatorExecutionRole.md): aggiornamento a una politica esistente | Amazon MSK ha aggiunto WriteDataIdempotently l'autorizzazione alla AWSMSKReplicator ExecutionRole policy per supportare la replica dei dati tra cluster MSK. | 12 marzo 2024 |
| [AWSMSKReplicatorExecutionRole](security-iam-awsmanpol-AWSMSKReplicatorExecutionRole.md): nuova policy | Amazon MSK ha aggiunto una AWSMSKReplicator ExecutionRole policy per supportare Amazon MSK Replicator. | 04 dicembre 2023 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md): aggiornamento a una politica esistente | Amazon MSK ha aggiunto le autorizzazioni per supportare il replicatore Amazon MSK. | 28 settembre 2023 |
| [KafkaServiceRolePolicy](security-iam-awsmanpol-KafkaServiceRolePolicy.md): aggiornamento di una policy esistente | Amazon MSK ha aggiunto le autorizzazioni per supportare la connettività privata multi-VPC. | 8 marzo 2023 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md): aggiornamento a una politica esistente | Amazon MSK ha aggiunto nuove autorizzazioni Amazon EC2 per consentire la connessione a un cluster. | 30 novembre 2021 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md): aggiornamento a una politica esistente | Amazon MSK ha aggiunto una nuova autorizzazione per consentirgli di descrivere le tabelle di routing di Amazon EC2. | 19 novembre 2021 |
| Amazon MSK ha iniziato a tenere traccia delle modifiche | Amazon MSK ha iniziato a tracciare le modifiche per le sue politiche AWS gestite. | 19 novembre 2021 |
# Risolvi i problemi relativi all'identità e all'accesso ad Amazon MSK
Utilizza le informazioni seguenti per eseguire la diagnosi e risolvere i problemi comuni che possono verificarsi durante l'utilizzo di Amazon MSK e IAM.
**Topics**
+ [Non dispongo dell'autorizzazione per eseguire un'operazione in Amazon MSK](#security_iam_troubleshoot-no-permissions)
## Non dispongo dell'autorizzazione per eseguire un'operazione in Amazon MSK
Se ti Console di gestione AWS dice che non sei autorizzato a eseguire un'azione, devi contattare l'amministratore per ricevere assistenza. L’amministratore è colui che ti ha fornito le credenziali di accesso.
L'errore di esempio seguente si verifica quando l'utente IAM `mateojackson` cerca di utilizzare la console per eliminare un cluster senza disporre delle autorizzazioni `kafka:DeleteCluster`.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: kafka:DeleteCluster on resource: purchaseQueriesCluster
```
In questo caso, Mateo chiede al suo amministratore di aggiornare le policy per poter accedere alla risorsa `purchaseQueriesCluster` mediante l'operazione `kafka:DeleteCluster`.
# Autenticazione e autorizzazione per Apache Kafka APIs
Puoi utilizzare IAM per autenticare i client e consentire o rifiutare le operazioni di Apache Kafka. In alternativa, puoi utilizzare TLS o SASL/SCRAM per autenticare i client e Apache ACLs Kafka per consentire o negare azioni.
Per informazioni su come controllare chi può eseguire le [operazioni di Amazon MSK](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html) sul tuo cluster, consulta la pagina [Autenticazione e autorizzazione per Amazon MSK APIs](security-iam.md).
**Topics**
+ [Controllo degli accessi IAM](iam-access-control.md)
+ [Autenticazione client TLS reciproca per Amazon MSK](msk-authentication.md)
+ [Autenticazione delle credenziali di accesso con Secrets Manager AWS](msk-password.md)
+ [Apache Kafka ACLs](msk-acls.md)
# Controllo degli accessi IAM
Il Controllo degli accessi IAM per Amazon MSK ti consente di gestire sia l'autenticazione sia l'autorizzazione per il cluster MSK. Ciò elimina la necessità di utilizzare meccanismi separati per l'autenticazione e l'autorizzazione. Ad esempio, quando un client tenta di scrivere sul cluster, Amazon MSK utilizza IAM per verificare se tale client è un'identità autenticata e se è autorizzato a produrre nel cluster.
Il controllo degli accessi IAM funziona per client Java e non Java, inclusi i client Kafka scritti in Python, Go e.NET. JavaScript Il controllo degli accessi IAM per client non Java è disponibile per i cluster MSK con Kafka versione 2.7.1 o successiva.
Per rendere possibile il Controllo degli accessi IAM, Amazon MSK apporta piccole modifiche al codice sorgente di Apache Kafka. Queste modifiche non causeranno differenze evidenti nella tua esperienza con Apache Kafka. Amazon MSK registra gli eventi di accesso in modo da poterli controllare.
È possibile richiamare Apache Kafka ACL per un cluster MSK che utilizza il controllo degli accessi IAM. APIs Tuttavia, Apache Kafka ACLs non ha alcun effetto sull'autorizzazione per le identità IAM. È necessario utilizzare le policy IAM per controllare l'accesso alle identità IAM.
**Considerazioni importanti**
Quando utilizzi il controllo degli accessi IAM con il tuo cluster MSK, tieni presenti le seguenti importanti considerazioni:
Il controllo degli accessi IAM non si applica ai nodi ZooKeeper Apache. Per ulteriori informazioni sul controllo degli accessi a tali nodi, consulta la pagina [Controlla l'accesso ai ZooKeeper nodi Apache nel tuo cluster Amazon MSK](zookeeper-security.md).
L'impostazione `allow.everyone.if.no.acl.found` di Apache Kafka non ha effetto se il cluster utilizza il Controllo degli accessi IAM.
Puoi richiamare Apache Kafka ACL APIs per un cluster MSK che utilizza il controllo degli accessi IAM. Tuttavia, Apache Kafka ACLs non ha alcun effetto sull'autorizzazione per le identità IAM. È necessario utilizzare le policy IAM per controllare l'accesso alle identità IAM.
# Come funziona il Controllo degli accessi IAM per Amazon MSK
Per utilizzare il controllo degli accessi IAM per Amazon MSK, esegui i seguenti passaggi, descritti in dettaglio in questi argomenti:
+ [Crea un cluster Amazon MSK che utilizza il controllo degli accessi IAM](create-iam-access-control-cluster-in-console.md)
+ [Configurazione dei client per il Controllo degli accessi IAM](configure-clients-for-iam-access-control.md)
+ [Crea politiche di autorizzazione per il ruolo IAM](create-iam-access-control-policies.md)
+ [Recupero dei broker di bootstrap per il Controllo degli accessi IAM](get-bootstrap-brokers-for-iam.md)
# Crea un cluster Amazon MSK che utilizza il controllo degli accessi IAM
Questa sezione spiega come utilizzare Console di gestione AWS, l'API o il AWS CLI per creare un cluster Amazon MSK che utilizza il controllo degli accessi IAM. Per informazioni su come attivare il Controllo degli accessi IAM per un cluster esistente, consulta la pagina [Aggiornamento delle impostazioni di sicurezza di un cluster Amazon MSK](msk-update-security.md).
**Utilizza il Console di gestione AWS per creare un cluster che utilizza il controllo degli accessi IAM**
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Scegli **Crea cluster**.
1. Scegli **Crea cluster con impostazioni personalizzate**.
1. Nella sezione **Autenticazione**, scegli **Controllo degli accessi IAM**.
1. Completa il resto del flusso di lavoro per creare un cluster.
**Utilizza l'API o il AWS CLI per creare un cluster che utilizza il controllo degli accessi IAM**
+ Per creare un cluster con il controllo degli accessi IAM abilitato, utilizza l'[CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)API o il comando [CLI create-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/create-cluster.html) e passa il seguente JSON per il parametro:. `ClientAuthentication` `"ClientAuthentication": { "Sasl": { "Iam": { "Enabled": true } }`
# Configurazione dei client per il Controllo degli accessi IAM
Per consentire ai client di comunicare con un cluster MSK che utilizza il controllo degli accessi IAM, è possibile utilizzare uno di questi meccanismi:
+ Configurazione client non Java tramite meccanismo SASL\$1OAUTHBEARER
+ Configurazione del client Java mediante SASL\$1OAUTHBEARER meccanismo o AWS\$1MSK\$1IAM meccanismo
## Usa il SASL\$1OAUTHBEARER meccanismo per configurare IAM
1. Modifica il tuo file di configurazione client.properties usando il seguente esempio di client Python Kafka. Le modifiche alla configurazione sono simili in altri linguaggi.
```
from kafka import KafkaProducer
from kafka.errors import KafkaError
from kafka.sasl.oauth import AbstractTokenProvider
import socket
import time
from aws_msk_iam_sasl_signer import MSKAuthTokenProvider
class MSKTokenProvider():
def token(self):
token, _ = MSKAuthTokenProvider.generate_auth_token('')
return token
tp = MSKTokenProvider()
producer = KafkaProducer(
bootstrap_servers='',
security_protocol='SASL_SSL',
sasl_mechanism='OAUTHBEARER',
sasl_oauth_token_provider=tp,
client_id=socket.gethostname(),
)
topic = ""
while True:
try:
inp=input(">")
producer.send(topic, inp.encode())
producer.flush()
print("Produced!")
except Exception:
print("Failed to send message:", e)
producer.close()
```
1. Scarica la libreria di supporto per la lingua di configurazione scelta e segui le istruzioni nella sezione *Guida introduttiva* della home page della libreria di lingue in questione.
+ JavaScript: [https://github.com/aws/aws-msk-iam-sasl-signer-js \$1getting -started](https://github.com/aws/aws-msk-iam-sasl-signer-js#getting-started)
+ Python: [https://github.com/aws/aws-msk-iam-sasl-signer-python \$1get -avviato](https://github.com/aws/aws-msk-iam-sasl-signer-python#get-started)
+ Vai: [https://github.com/aws/aws-msk-iam-sasl-signer-go \$1getting -started](https://github.com/aws/aws-msk-iam-sasl-signer-go#getting-started)
+ [.NET: -signer-net \$1getting -iniziato https://github.com/aws/ aws-msk-iam-sasl](https://github.com/aws/aws-msk-iam-sasl-signer-net#getting-started)
+ JAVA: SASL\$1OAUTHBEARER il supporto per Java è disponibile tramite il file jar [https://github.com/aws/aws-msk-iam-auth/releases](https://github.com/aws/aws-msk-iam-auth/releases)
## Utilizza il AWS\$1MSK\$1IAM meccanismo personalizzato MSK per configurare IAM
1. Aggiungi quanto segue al file `client.properties`. Sostituisci ** con il percorso completo del file di trust store sul client.
**Nota**
Se non desideri utilizzare un certificato specifico, puoi rimuovere `ssl.truststore.location=` dal tuo file `client.properties`. Se non specifichi un valore per `ssl.truststore.location`, il processo Java utilizza il certificato predefinito.
```
ssl.truststore.location=
security.protocol=SASL_SSL
sasl.mechanism=AWS_MSK_IAM
sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required;
sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler
```
Per utilizzare un profilo denominato creato per AWS le credenziali, includilo `awsProfileName="your profile name";` nel file di configurazione del client. Per informazioni sui profili denominati, consulta [Profili denominati](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html) nella AWS CLI documentazione.
1. Scaricate l'ultimo file [aws-msk-iam-auth](https://github.com/aws/aws-msk-iam-auth/releases)JAR stabile e inseritelo nel percorso della classe. Se utilizzi Maven, aggiungi la seguente dipendenza, modificando il numero di versione secondo necessità:
```
software.amazon.msk
aws-msk-iam-auth
1.0.0
```
Il plug-in client di Amazon MSK è open source con licenza Apache 2.0.
# Crea politiche di autorizzazione per il ruolo IAM
Collega una policy di autorizzazione al ruolo IAM corrispondente al client. In una policy di autorizzazione, specifichi quali operazioni consentire o rifiutare per il ruolo. Se il tuo client è su un'istanza Amazon EC2, associa la policy di autorizzazione al ruolo IAM per quell'istanza Amazon EC2. In alternativa, puoi configurare il client per utilizzare un profilo denominato e quindi associare la policy di autorizzazione al ruolo per quel profilo denominato. [Configurazione dei client per il Controllo degli accessi IAM](configure-clients-for-iam-access-control.md) descrive come configurare un client per utilizzare un profilo denominato.
Per informazioni sulla creazione di una policy IAM, consulta la pagina [Creating IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html).
Di seguito è riportato un esempio di politica di autorizzazione per un cluster denominato MyTestCluster. Per comprendere la semantica degli elementi `Action` e `Resource`, consulta la pagina [Semantica delle azioni e delle risorse della politica di autorizzazione IAM](kafka-actions.md).
**Importante**
Le modifiche apportate a una policy IAM si riflettono nell'IAM APIs e nell' AWS CLI immediatezza. Tuttavia, può trascorrere molto tempo prima che la modifica della policy abbia effetto. Nella maggior parte dei casi, le modifiche alle policy entrano in vigore in meno di un minuto. A volte le condizioni della rete possono aumentare il ritardo.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeCluster"
],
"Resource": [
"arn:aws:kafka:us-east-1:111122223333:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/*"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:group/MyTestCluster/*"
]
}
]
}
```
------
Per informazioni su come creare una policy con elementi di operazione che corrispondano ai casi d'uso comuni di Apache Kafka, come la produzione e l'utilizzo di dati, consulta la pagina [Casi d'uso comuni per la politica di autorizzazione dei client](iam-access-control-use-cases.md).
[Per le versioni di Kafka 2.8.0 e successive, l'**WriteDataIdempotently**autorizzazione è obsoleta (KIP-679).](https://cwiki.apache.org/confluence/display/KAFKA/KIP-679%3A+Producer+will+enable+the+strongest+delivery+guarantee+by+default) Per impostazione predefinita, viene utilizzato `enable.idempotence = true`. Pertanto, per le versioni di Kafka 2.8.0 e successive, IAM non offre le stesse funzionalità di Kafka. ACLs Non è possibile accedere a un argomento fornendo solo `WriteDataIdempotently` l'accesso a quell'argomento. `WriteData` Ciò non influisce sul caso in cui `WriteData` venga fornito a **TUTTI gli** argomenti. In tal caso, l'operazione `WriteDataIdempotently` è consentita. Ciò è dovuto alle differenze nell'implementazione della logica IAM e nel modo in cui ACLs vengono implementati i Kafka. Inoltre, scrivere su un argomento in modo idempotente richiede anche l'accesso a. `transactional-ids`
Per ovviare a questo problema, consigliamo di utilizzare una politica simile alla seguente politica.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeCluster",
"kafka-cluster:WriteDataIdempotently"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/TestTopic",
"arn:aws:kafka:us-east-1:123456789012:transactional-id/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*"
]
}
]
}
```
------
In questo caso, `WriteData` consente le scritture sul `TestTopic`, mentre `WriteDataIdempotently` consente le scritture idempotenti sul cluster. Questa politica aggiunge anche l'accesso alle `transactional-id` risorse che saranno necessarie.
Poiché `WriteDataIdempotently` si tratta di un'autorizzazione a livello di cluster, non è possibile utilizzarla a livello di argomento. Se `WriteDataIdempotently` è limitato al livello di argomento, questo criterio non funzionerà.
# Recupero dei broker di bootstrap per il Controllo degli accessi IAM
Per informazioni, consulta [Ottieni i broker bootstrap per un cluster Amazon MSK](msk-get-bootstrap-brokers.md).
# Semantica delle azioni e delle risorse della politica di autorizzazione IAM
**Nota**
Per i cluster che eseguono Apache Kafka versione 3.8 o successiva, il controllo degli accessi IAM supporta l'API per terminare le transazioni. WriteTxnMarkers Per i cluster che eseguono versioni di Kafka precedenti alla 3.8, il controllo degli accessi IAM non supporta le azioni interne del cluster, tra cui. WriteTxnMarkers Per queste versioni precedenti, per terminare le transazioni, utilizza l'autenticazione SCRAM o MTLS con l'autenticazione appropriata anziché l'autenticazione IAM. ACLs
In questa sezione viene illustrata la semantica degli elementi di operazione e risorsa che è possibile utilizzare in una policy di autorizzazione IAM. Per un esempio di policy, consulta [Crea politiche di autorizzazione per il ruolo IAM](create-iam-access-control-policies.md).
## Azioni relative alla politica di autorizzazione
La tabella seguente elenca le operazioni che è possibile includere in una policy di autorizzazione quando si utilizza il Controllo degli accessi IAM per Amazon MSK. Quando includi nella tua policy di autorizzazione un'operazione dalla colonna *Operazione* della tabella, devi includere anche le operazioni corrispondenti dalla colonna *Operazioni richieste*.
| Azione | Description | Operazioni necessarie | Risorse obbligatorie | Applicabile ai cluster serverless |
| --- | --- | --- | --- | --- |
| kafka-cluster:Connect | Concede l'autorizzazione per connettersi e autenticarsi al cluster. | Nessuno | cluster | Sì |
| kafka-cluster:DescribeCluster | Concede l'autorizzazione per descrivere vari aspetti del cluster, equivalente all'ACL DESCRIBE CLUSTER di Apache Kafka. | `kafka-cluster:Connect` | cluster | Sì |
| kafka-cluster:AlterCluster | Concede l'autorizzazione per modificare vari aspetti del cluster, equivalente all'ACL ALTER CLUSTER di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeCluster` | cluster | No |
| kafka-cluster:DescribeClusterDynamicConfiguration | Concede l'autorizzazione per descrivere la configurazione dinamica di un cluster, equivalente all'ACL DESCRIBE\$1CONFIGS CLUSTER di Apache Kafka. | `kafka-cluster:Connect` | cluster | No |
| kafka-cluster:AlterClusterDynamicConfiguration | Concede l'autorizzazione per modificare la configurazione dinamica di un cluster, equivalente all'ACL ALTER\$1CONFIGS CLUSTER di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` | cluster | No |
| kafka-cluster:WriteDataIdempotently | Concede l'autorizzazione per scrivere dati in modo idempotente su un cluster, equivalente all'ACL IDEMPOTENT\$1WRITE CLUSTER di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:WriteData` | cluster | Sì |
| kafka-cluster:CreateTopic | Concede l'autorizzazione a creare argomenti su un cluster, equivalente all'ACL CREATE di Apache Kafka. CLUSTER/TOPIC | `kafka-cluster:Connect` | topic | Sì |
| kafka-cluster:DescribeTopic | Concede l'autorizzazione per descrivere gli argomenti in un cluster, equivalente all'ACL DESCRIBE TOPIC di Apache Kafka. | `kafka-cluster:Connect` | topic | Sì |
| kafka-cluster:AlterTopic | Concede l'autorizzazione per modificare gli argomenti in un cluster, equivalente all'ACL ALTER TOPIC di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | topic | Sì |
| kafka-cluster:DeleteTopic | Concede l'autorizzazione per eliminare gli argomenti in un cluster, equivalente all'ACL DELETE TOPIC di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | topic | Sì |
| kafka-cluster:DescribeTopicDynamicConfiguration | Concede l'autorizzazione per descrivere la configurazione dinamica degli argomenti in un cluster, equivalente all'ACL DESCRIBE\$1CONFIGS TOPIC di Apache Kafka. | `kafka-cluster:Connect` | topic | Sì |
| kafka-cluster:AlterTopicDynamicConfiguration | Concede l'autorizzazione per modificare la configurazione dinamica degli argomenti in un cluster, equivalente all'ACL ALTER\$1CONFIGS TOPIC di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` | topic | Sì |
| kafka-cluster:ReadData | Concede l'autorizzazione per leggere i dati da argomenti in un cluster, equivalente all'ACL READ TOPIC di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterGroup` | topic | Sì |
| kafka-cluster:WriteData | Concede l'autorizzazione per scrivere dati su argomenti in un cluster, equivalente all'ACL WRITE TOPIC di Apache Kafka | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | topic | Sì |
| kafka-cluster:DescribeGroup | Concede l'autorizzazione per descrivere i gruppi in un cluster, equivalente all'ACL DESCRIBE GROUP di Apache Kafka. | `kafka-cluster:Connect` | gruppo | Sì |
| kafka-cluster:AlterGroup | Concede l'autorizzazione per unire dei gruppi all'interno di un cluster, equivalente all'ACL READ GROUP di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeGroup` | gruppo | Sì |
| kafka-cluster:DeleteGroup | Concede l'autorizzazione per eliminare gruppi all'interno di un cluster, equivalente all'ACL DELETE GROUP di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeGroup` | gruppo | Sì |
| kafka-cluster:DescribeTransactionalId | Concede l'autorizzazione a descrivere le transazioni IDs su un cluster, equivalente all'ACL DESCRIBE TRANSACTIONAL\$1ID di Apache Kafka. | `kafka-cluster:Connect` | transactional-id | Sì |
| kafka-cluster:AlterTransactionalId | Concede l'autorizzazione a modificare le transazioni su un cluster, equivalente all'ACL WRITE IDs TRANSACTIONAL\$1ID di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTransactionalId` `kafka-cluster:WriteData` | transactional-id | Sì |
In un'operazione, dopo i due punti, è possibile utilizzare qualsiasi quantità di caratteri jolly asterisco (\$1). Di seguito vengono mostrati gli esempi.
+ `kafka-cluster:*Topic` sta per `kafka-cluster:CreateTopic`, `kafka-cluster:DescribeTopic`, `kafka-cluster:AlterTopic` e `kafka-cluster:DeleteTopic`. Non include `kafka-cluster:DescribeTopicDynamicConfiguration` o `kafka-cluster:AlterTopicDynamicConfiguration`.
+ `kafka-cluster:*` indica tutte le autorizzazioni.
## Risorse relative alla politica di autorizzazione
La tabella seguente mostra i quattro tipi di risorse che è possibile utilizzare in una policy di autorizzazione quando si utilizza il Controllo degli accessi IAM per Amazon MSK. Puoi ottenere il cluster Amazon Resource Name (ARN) da o utilizzando l'[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)API Console di gestione AWS o il comando [AWS CLI describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html). È quindi possibile utilizzare l'ARN del cluster per creare un argomento, un gruppo e un ID transazionale. ARNs Per specificare una risorsa nella policy di autorizzazione, utilizza l'ARN della risorsa.
| Risorsa | Formato ARN |
| --- | --- |
| Cluster | arn:aws:kafka: :cluster//regionaccount-idcluster-namecluster-uuid |
| Topic | arn:aws:kafka: region ::argomento///account-idcluster-namecluster-uuidtopic-name |
| Gruppo | arn:aws:kafka: region :group///account-idcluster-namecluster-uuidgroup-name |
| ID transazionale | arn:aws:kafka: region ::identificativo-transazione///account-idcluster-namecluster-uuidtransactional-id |
È possibile utilizzare qualsiasi quantità di caratteri jolly asterisco (\$1) in qualsiasi punto dell'ARN successivo a `:cluster/`, `:topic/`, `:group/` e `:transactional-id/`. Di seguito sono riportati alcuni esempi di come utilizzare il carattere jolly asterisco (\$1) per fare riferimento a più risorse:
+ `arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/*`: tutti gli argomenti di qualsiasi cluster denominato, indipendentemente dall'UUID del cluster. MyTestCluster
+ `arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*_test`: tutti gli argomenti il cui nome termina con «\$1test» nel cluster il cui nome è MyTestCluster e il cui UUID è abcd1234-0123-abcd-5678-1234abcd-1.
+ `arn:aws:kafka:us-east-1:0123456789012:transactional-id/MyTestCluster/*/5555abcd-1111-abcd-1234-abcd1234-1`: tutte le transazioni il cui ID transazionale è MyTestCluster 5555abcd-1111-abcd-1234-abcd1234-1, in tutte le incarnazioni di un cluster denominato nel tuo account. Ciò significa che se si crea un cluster denominato MyTestCluster, quindi lo si elimina e quindi si crea un altro cluster con lo stesso nome, è possibile utilizzare questa risorsa ARN per rappresentare lo stesso ID delle transazioni su entrambi i cluster. Tuttavia, il cluster eliminato non è accessibile.
# Casi d'uso comuni per la politica di autorizzazione dei client
La prima colonna della tabella seguente mostra alcuni casi d'uso comuni. Per autorizzare un client a eseguire un determinato caso d'uso, includi le operazioni richieste per tale caso d'uso nella policy di autorizzazione del client e imposta `Effect` su `Allow`.
Per informazioni su tutte le operazioni che fanno parte del Controllo degli accessi IAM per Amazon MSK, consulta la pagina [Semantica delle azioni e delle risorse della politica di autorizzazione IAM](kafka-actions.md).
**Nota**
Le operazioni non sono consentite per impostazione predefinita. È necessario consentire esplicitamente ogni operazione che si desidera autorizzare il client a eseguire.
****
| Caso d’uso | Operazioni necessarie |
| --- | --- |
| Admin | `kafka-cluster:*` |
| Crea un argomento | `kafka-cluster:Connect` `kafka-cluster:CreateTopic` |
| Produzione di dati | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` |
| Utilizzo di dati | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeGroup` `kafka-cluster:AlterGroup` `kafka-cluster:ReadData` |
| Produzione di dati in modo idempotente | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` `kafka-cluster:WriteDataIdempotently` |
| Produzione di dati in modo transazionale | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` `kafka-cluster:DescribeTransactionalId` `kafka-cluster:AlterTransactionalId` |
| Descrizione della configurazione di un cluster | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` |
| Aggiornamento della configurazione di un cluster | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` `kafka-cluster:AlterClusterDynamicConfiguration` |
| Descrizione della configurazione di un argomento | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` |
| Aggiornamento della configurazione di un argomento | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` `kafka-cluster:AlterTopicDynamicConfiguration` |
| Modifica di un argomento | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterTopic` |
# Autenticazione client TLS reciproca per Amazon MSK
Puoi abilitare l'autenticazione client con TLS per le connessioni dalle tue applicazioni ai broker Amazon MSK. Per utilizzare l'autenticazione client, è necessario un CA privata AWS. CA privata AWS Possono appartenere allo Account AWS stesso cluster o a un account diverso. Per informazioni su CA privata AWS s, vedere [Creazione e gestione di un CA privata AWS](https://docs.aws.amazon.com/acm-pca/latest/userguide/create-CA.html).
Amazon MSK non supporta gli elenchi di revoca dei certificati ()CRLs. Per controllare l'accesso agli argomenti del cluster o bloccare i certificati compromessi, usa Apache ACLs Kafka e i gruppi di sicurezza. AWS Per informazioni sull'uso di Apache Kafka, consulta. ACLs [Apache Kafka ACLs](msk-acls.md)
**Topics**
+ [Crea un cluster Amazon MSK che supporti l'autenticazione dei client](msk-authentication-cluster.md)
+ [Configura un client per utilizzare l'autenticazione](msk-authentication-client.md)
+ [Produci e consuma messaggi utilizzando l'autenticazione](msk-authentication-messages.md)
# Crea un cluster Amazon MSK che supporti l'autenticazione dei client
Questa procedura mostra come abilitare l'autenticazione del client utilizzando un CA privata AWS.
**Nota**
Si consiglia vivamente di utilizzare Independent CA privata AWS per ogni cluster MSK quando si utilizza il TLS reciproco per controllare l'accesso. In questo modo assicurerai che i certificati TLS firmati da si autentichino PCAs solo con un singolo cluster MSK.
1. Crea un file denominato `clientauthinfo.json` con i seguenti contenuti. Sostituisci *Private-CA-ARN* con l'ARN del tuo PCA.
```
{
"Tls": {
"CertificateAuthorityArnList": ["Private-CA-ARN"]
}
}
```
1. Crea un file denominato `brokernodegroupinfo.json` come descritto in [Crea un cluster Amazon MSK di cui è stato effettuato il provisioning utilizzando il AWS CLI](create-cluster-cli.md).
1. L'autenticazione client richiede di abilitare anche la crittografia dei dati in transito tra client e broker. Crea un file denominato `encryptioninfo.json` con i seguenti contenuti. Sostituisci *KMS-Key-ARN* con l'ARN della tua chiave KMS. Puoi impostare `ClientBroker` su `TLS` o `TLS_PLAINTEXT`.
```
{
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "KMS-Key-ARN"
},
"EncryptionInTransit": {
"InCluster": true,
"ClientBroker": "TLS"
}
}
```
Per ulteriori informazioni sulla crittografia, consulta [Crittografia di Amazon MSK](msk-encryption.md).
1. Su una macchina su cui è AWS CLI installata, esegui il comando seguente per creare un cluster con l'autenticazione e la crittografia in transito abilitate. Salva l'ARN del cluster fornito nella risposta.
```
aws kafka create-cluster --cluster-name "AuthenticationTest" --broker-node-group-info file://brokernodegroupinfo.json --encryption-info file://encryptioninfo.json --client-authentication file://clientauthinfo.json --kafka-version "{YOUR KAFKA VERSION}" --number-of-broker-nodes 3
```
# Configura un client per utilizzare l'autenticazione
Questo processo descrive come configurare un'istanza Amazon EC2 da utilizzare come client per utilizzare l'autenticazione.
Questo processo descrive come produrre e utilizzare messaggi utilizzando l'autenticazione creando una macchina client, creando un argomento e configurando le impostazioni di sicurezza richieste.
1. Crea un'istanza Amazon EC2 da utilizzare come un computer client. Per semplicità, creare questa istanza nello stesso VPC utilizzato per il cluster. Consulta [Passaggio 3: creazione di un computer client](create-client-machine.md) per un esempio di come creare un computer client di questo tipo.
1. Creazione di un argomento. Per un esempio, consulta le istruzioni in [Fase 4: creare un argomento nel cluster Amazon MSK](create-topic.md).
1. Su una macchina su cui è AWS CLI installato, esegui il comando seguente per ottenere i broker bootstrap del cluster. Sostituisci *Cluster-ARN* con l'ARN del tuo cluster.
```
aws kafka get-bootstrap-brokers --cluster-arn Cluster-ARN
```
Salvare la stringa associata a `BootstrapBrokerStringTls` nella risposta.
1. Sul computer client, eseguire il comando seguente per utilizzare il truststore JVM per creare il truststore client. Se il percorso JVM è diverso, modificare il comando di conseguenza.
```
cp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64/jre/lib/security/cacerts kafka.client.truststore.jks
```
1. Sul computer client, eseguire il comando seguente per creare una chiave privata per il client. Sostituisci *Distinguished-Name**Example-Alias*,*Your-Store-Pass*, e *Your-Key-Pass* con stringhe a tua scelta.
```
keytool -genkey -keystore kafka.client.keystore.jks -validity 300 -storepass Your-Store-Pass -keypass Your-Key-Pass -dname "CN=Distinguished-Name" -alias Example-Alias -storetype pkcs12 -keyalg rsa
```
1. Sul computer client, eseguire il comando seguente per creare una richiesta di certificato con la chiave privata creata nella fase precedente.
```
keytool -keystore kafka.client.keystore.jks -certreq -file client-cert-sign-request -alias Example-Alias -storepass Your-Store-Pass -keypass Your-Key-Pass
```
1. Aprire il file `client-cert-sign-request` e accertarsi che inizi con `-----BEGIN CERTIFICATE REQUEST-----` e termini con `-----END CERTIFICATE REQUEST-----`. Se inizia con `-----BEGIN NEW CERTIFICATE REQUEST-----`, eliminare la parola `NEW` (e il singolo spazio che la segue) dall'inizio e dalla fine del file.
1. Su un computer in cui è AWS CLI installato, esegui il comando seguente per firmare la richiesta di certificato. Sostituisci *Private-CA-ARN* con l'ARN del tuo PCA. Se lo si desidera, è possibile modificare il valore di validità. In questo esempio viene utilizzato 300.
```
aws acm-pca issue-certificate --certificate-authority-arn Private-CA-ARN --csr fileb://client-cert-sign-request --signing-algorithm "SHA256WITHRSA" --validity Value=300,Type="DAYS"
```
Salvare il certificato ARN fornito nella risposta.
**Nota**
Per recuperare il certificato client, utilizza il comando `acm-pca get-certificate` e specifica l'ARN del certificato. Per ulteriori informazioni, consulta la sezione [get-certificate](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm-pca/get-certificate.html) nella *documentazione di riferimento alla AWS CLI *.
1. Esegui il comando seguente per ottenere il certificato CA privata AWS firmato per te. Sostituisci *Certificate-ARN* con l'ARN ottenuto dalla risposta al comando precedente.
```
aws acm-pca get-certificate --certificate-authority-arn Private-CA-ARN --certificate-arn Certificate-ARN
```
1. Dal risultato JSON dell'esecuzione del comando precedente, copiare le stringhe associate a `Certificate` e `CertificateChain`. Incolla queste due stringhe in un nuovo file denominato. signed-certificate-from-acm Incollare innanzitutto la stringa associata a `Certificate`, seguita dalla stringa associata a `CertificateChain`. Sostituire i caratteri `\n` con nuove righe. Di seguito è riportata la struttura del file dopo aver incollato al suo interno il certificato e la catena di certificati.
```
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
```
1. Eseguire il comando seguente sul computer client per aggiungere questo certificato al keystore in modo da poterlo presentare quando si parla con i broker MSK.
```
keytool -keystore kafka.client.keystore.jks -import -file signed-certificate-from-acm -alias Example-Alias -storepass Your-Store-Pass -keypass Your-Key-Pass
```
1. Crea un file denominato `client.properties` con i seguenti contenuti. Regolare le posizioni del truststore e del keystore sui percorsi in cui è stato salvato `kafka.client.truststore.jks`. Sostituisci i segnaposto con la versione del tuo client Kafka. *\$1YOUR KAFKA VERSION\$1*
```
security.protocol=SSL
ssl.truststore.location=/tmp/kafka_2.12-{YOUR KAFKA VERSION}/kafka.client.truststore.jks
ssl.keystore.location=/tmp/kafka_2.12-{YOUR KAFKA VERSION}/kafka.client.keystore.jks
ssl.keystore.password=Your-Store-Pass
ssl.key.password=Your-Key-Pass
```
# Produci e consuma messaggi utilizzando l'autenticazione
Questo processo descrive come produrre e utilizzare messaggi utilizzando l'autenticazione.
1. Eseguire il comando seguente per creare un argomento. Il file denominato `client.properties` è quello creato nella procedura precedente.
```
/bin/kafka-topics.sh --create --bootstrap-server BootstrapBroker-String --replication-factor 3 --partitions 1 --topic ExampleTopic --command-config client.properties
```
1. Eseguire il comando seguente per avviare un produttore della console. Il file denominato `client.properties` è quello creato nella procedura precedente.
```
/bin/kafka-console-producer.sh --bootstrap-server BootstrapBroker-String --topic ExampleTopic --producer.config client.properties
```
1. In una nuova finestra di comando sul computer client, eseguire il comando seguente per avviare un consumatore della console.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBroker-String --topic ExampleTopic --consumer.config client.properties
```
1. Digitare i messaggi nella finestra del produttore e guardarli apparire nella finestra del consumatore.
# Autenticazione delle credenziali di accesso con Secrets Manager AWS
Puoi controllare l'accesso ai tuoi cluster Amazon MSK utilizzando credenziali di accesso archiviate e protette tramite Secrets Manager. AWS L'archiviazione delle credenziali utente in Secrets Manager riduce il sovraccarico dell'autenticazione del cluster, ad esempio il controllo, l'aggiornamento e la rotazione delle credenziali. Secrets Manager consente inoltre di condividere le credenziali utente tra i cluster.
Dopo aver associato un segreto a un cluster MSK, MSK sincronizza periodicamente i dati delle credenziali.
**Topics**
+ [Come funziona l'autenticazione delle credenziali di accesso](msk-password-howitworks.md)
+ [Configurare SASL/SCRAM l'autenticazione per un cluster Amazon MSK](msk-password-tutorial.md)
+ [Operazioni con gli utenti](msk-password-users.md)
+ [Limitazioni nell'uso dei segreti SCRAM](msk-password-limitations.md)
# Come funziona l'autenticazione delle credenziali di accesso
L'autenticazione delle credenziali di accesso per Amazon MSK utilizza l'autenticazione SASL/SCRAM (Simple Authentication and Security Layer/ Salted Challenge Response Mechanism). Per configurare l'autenticazione delle credenziali di accesso per un cluster, crea una risorsa segreta in [AWS Secrets Manager](https://docs.aws.amazon.com//secretsmanager/?id=docs_gateway) e associa le credenziali di accesso a quel segreto.
SASL/SCRAM è definito in [RFC 5802](https://tools.ietf.org/html/rfc5802). SCRAM utilizza algoritmi di hashing protetti e non trasmette credenziali di accesso non crittografate tra client e server.
**Nota**
Quando configuri SASL/SCRAM l'autenticazione per il tuo cluster, Amazon MSK attiva la crittografia TLS per tutto il traffico tra clienti e broker.
# Configurare SASL/SCRAM l'autenticazione per un cluster Amazon MSK
Per impostare un segreto in AWS Secrets Manager, segui il tutorial [Creazione e recupero di un segreto](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) nella Guida per l'[utente di AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html).
Tieni presente i seguenti requisiti quando crei un segreto per un cluster Amazon MSK:
+ Per il tipo di segreto, scegli **Altro tipo di segreto (es. chiave API)**.
+ Il nome del segreto deve iniziare con il prefisso **AmazonMSK\$1**.
+ È necessario utilizzare una AWS KMS chiave personalizzata esistente o creare una nuova AWS KMS chiave personalizzata per il segreto. Secrets Manager utilizza la AWS KMS chiave predefinita per un segreto per impostazione predefinita.
**Importante**
Un segreto creato con la AWS KMS chiave predefinita non può essere utilizzato con un cluster Amazon MSK.
+ I dati delle credenziali di accesso devono essere nel seguente formato per inserire coppie chiave-valore utilizzando l'opzione **Non crittografato**.
```
{
"username": "alice",
"password": "alice-secret"
}
```
+ Prendi nota del valore del nome della risorsa Amazon (ARN) del segreto.
+
**Importante**
Non è possibile associare un segreto di Secrets Manager a un cluster che supera i limiti descritti in [Dimensioni corrette del cluster: numero di partizioni per broker Standard](bestpractices.md#partitions-per-broker).
+ Se si utilizza il AWS CLI per creare il segreto, specificare un ID chiave o un ARN per il `kms-key-id` parametro. Non specificare un alias.
+ Per associare il segreto al cluster, utilizza la console Amazon MSK o l'[ BatchAssociateScramSecret](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html#BatchAssociateScramSecret)operazione.
**Importante**
Quando associ un segreto a un cluster, Amazon MSK collega al segreto una policy delle risorse che consente al cluster di accedere e leggere i valori del segreto che hai definito. Questa policy delle risorse non dovrebbe essere modificata. In questo modo, è possibile impedire al cluster di accedere al segreto. Se apporti modifiche alla policy delle risorse Secrets e/o alla chiave KMS utilizzata per la crittografia segreta, assicurati di riassociare i segreti al tuo cluster MSK. In questo modo il cluster potrà continuare ad accedere al segreto.
L'esempio seguente di input JSON per l'operazione `BatchAssociateScramSecret` associa un segreto a un cluster:
```
{
"clusterArn" : "arn:aws:kafka:us-west-2:0123456789019:cluster/SalesCluster/abcd1234-abcd-cafe-abab-9876543210ab-4",
"secretArnList": [
"arn:aws:secretsmanager:us-west-2:0123456789019:secret:AmazonMSK_MyClusterSecret"
]
}
```
# Connessione al cluster con credenziali di accesso
Dopo aver creato un segreto e averlo collegato al cluster, è possibile collegare il client al cluster. La procedura seguente mostra come connettere un client a un cluster che utilizza SASL/SCRAM l'autenticazione. Viene inoltre illustrato come produrre e consumare partendo da un argomento di esempio.
**Topics**
+ [Connessione di un client al cluster tramite SASL/SCRAM l'autenticazione](#w2aab9c13c29c17c13c11b9b7)
+ [Risoluzione dei problemi di connessione](#msk-password-tutorial-connect-troubleshooting)
## Connessione di un client al cluster tramite SASL/SCRAM l'autenticazione
1. Esegui il comando seguente su un computer che è stato AWS CLI installato. Sostituisci *clusterARN* con l'ARN del tuo cluster.
```
aws kafka get-bootstrap-brokers --cluster-arn clusterARN
```
Dal risultato JSON di questo comando, salva il valore associato alla stringa denominata. `BootstrapBrokerStringSaslScram` Utilizzerai questo valore nei passaggi successivi.
1. Sul tuo computer client, crea un file di configurazione JAAS che contenga le credenziali utente archiviate nel tuo segreto. Ad esempio, per l'utente **alice**, crea un file chiamato `users_jaas.conf` con il seguente contenuto.
```
KafkaClient {
org.apache.kafka.common.security.scram.ScramLoginModule required
username="alice"
password="alice-secret";
};
```
1. Utilizza il seguente comando per esportare il file di configurazione JAAS come parametro di ambiente `KAFKA_OPTS`.
```
export KAFKA_OPTS=-Djava.security.auth.login.config=/users_jaas.conf
```
1. Nella directory `/tmp`, crea un file denominato `kafka.client.truststore.jks`.
1. (Facoltativo) Utilizzate il seguente comando per copiare il file dell'archivio chiavi JDK dalla `cacerts` cartella JVM nel `kafka.client.truststore.jks` file creato nel passaggio precedente. *JDKFolder*Sostituiscilo con il nome della cartella JDK sull'istanza. Ad esempio, la tua cartella JDK potrebbe avere il nome `java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64`.
```
cp /usr/lib/jvm/JDKFolder/lib/security/cacerts /tmp/kafka.client.truststore.jks
```
1. Nella directory `bin` di installazione di Apache Kafka, crea un file delle proprietà del client chiamato `client_sasl.properties` con il seguente contenuto. Questo file definisce il meccanismo e il protocollo SASL.
```
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
```
1. Per creare un argomento di esempio, esegui il comando seguente. Sostituisci *BootstrapBrokerStringSaslScram* con la stringa del broker bootstrap ottenuta nel passaggio 1 di questo argomento.
```
/bin/kafka-topics.sh --create --bootstrap-server BootstrapBrokerStringSaslScram --command-config /client_sasl.properties --replication-factor 3 --partitions 1 --topic ExampleTopicName
```
1. Per produrre l'argomento di esempio che hai creato, esegui il comando seguente sul computer client. Sostituiscila *BootstrapBrokerStringSaslScram* con la stringa del broker bootstrap recuperata nel passaggio 1 di questo argomento.
```
/bin/kafka-console-producer.sh --broker-list BootstrapBrokerStringSaslScram --topic ExampleTopicName --producer.config client_sasl.properties
```
1. Per utilizzare l'argomento che hai creato, esegui il comando seguente sul tuo computer client. Sostituiscila *BootstrapBrokerStringSaslScram* con la stringa del broker bootstrap ottenuta nel passaggio 1 di questo argomento.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringSaslScram --topic ExampleTopicName --from-beginning --consumer.config client_sasl.properties
```
## Risoluzione dei problemi di connessione
Quando si eseguono i comandi del client Kafka, è possibile riscontrare errori nella memoria heap di Java, specialmente quando si lavora con argomenti o set di dati di grandi dimensioni. Questi errori si verificano perché gli strumenti Kafka vengono eseguiti come applicazioni Java con impostazioni di memoria predefinite che potrebbero essere insufficienti per il carico di lavoro.
Per risolvere `Out of Memory Java Heap` gli errori, è possibile aumentare la dimensione dell'heap Java modificando la variabile di `KAFKA_OPTS` ambiente per includere le impostazioni di memoria.
L'esempio seguente imposta la dimensione massima dell'heap su 1 GB (). `-Xmx1G` È possibile regolare questo valore in base alla memoria di sistema disponibile e ai requisiti.
```
export KAFKA_OPTS="-Djava.security.auth.login.config=/users_jaas.conf -Xmx1G"
```
Per approfondire argomenti di grandi dimensioni, prendi in considerazione l'utilizzo di parametri basati sul tempo o sull'offset anziché `--from-beginning` limitare l'utilizzo della memoria:
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringSaslScram --topic ExampleTopicName --max-messages 1000 --consumer.config client_sasl.properties
```
# Operazioni con gli utenti
**Creazione di utenti:** crea utenti nel tuo segreto come coppie chiave-valore. Quando si utilizza l'opzione **Non crittografato** nella console Secrets Manager, è necessario specificare i dati delle credenziali di accesso nel formato seguente.
```
{
"username": "alice",
"password": "alice-secret"
}
```
**Revoca dell'accesso utente:** per revocare le credenziali di accesso a un cluster di un utente, si consiglia di rimuovere o applicare un'ACL al cluster e successivamente annullare l'associazione del segreto. Ciò può essere dovuto ai motivi seguenti:
+ La rimozione di un utente non chiude le connessioni esistenti.
+ La propagazione delle modifiche al segreto richiede fino a 10 minuti.
Per ulteriori informazioni sull'utilizzo delle ACL con Amazon MSK, consulta la pagina [Apache Kafka ACLs](msk-acls.md).
Per i cluster che utilizzano ZooKeeper la modalità, si consiglia di limitare l'accesso ai ZooKeeper nodi per impedire agli utenti di apportare modifiche. ACLs Per ulteriori informazioni, consulta [Controlla l'accesso ai ZooKeeper nodi Apache nel tuo cluster Amazon MSK](zookeeper-security.md).
# Limitazioni nell'uso dei segreti SCRAM
Quando utilizzi i segreti SCRAM, tieni presente le limitazioni seguenti:
+ Amazon MSK supporta solo l'autenticazione SCRAM-SHA-512.
+ Un cluster Amazon MSK può avere fino a 1.000 utenti.
+ Devi usare un AWS KMS key con il tuo segreto. Non è possibile utilizzare un segreto che utilizza la chiave di crittografia Secrets Manager predefinita con Amazon MSK. Per ulteriori informazioni sulla creazione di una chiave KMS, consulta la pagina [Creating symmetric encryption KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk).
+ Non è possibile utilizzare una chiave KMS asimmetrica con Secrets Manager.
+ È possibile associare fino a 10 segreti a un cluster alla volta utilizzando l'[ BatchAssociateScramSecret](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html#BatchAssociateScramSecret)operazione.
+ Il nome dei segreti associati a un cluster Amazon MSK deve avere il prefisso **AmazonMSK\$1.**
+ I segreti associati a un cluster Amazon MSK devono trovarsi nello stesso account e nella stessa AWS regione Amazon Web Services del cluster.
# Apache Kafka ACLs
Apache Kafka dispone di un autorizzatore collegabile e viene fornito con un'implementazione di autorizzazione. out-of-box Amazon MSK abilita questo provider di autorizzazioni nel file `server.properties` sui broker.
Apache Kafka ACLs ha il formato «Principal P è [Consentita/Negata] Operazione O dall'host H su qualsiasi risorsa R corrispondente a RP». ResourcePattern Se RP non corrisponde a una risorsa specifica R, allora R non ha alcuna risorsa associata ACLs e quindi solo gli utenti privilegiati possono accedere a R. Per modificare questo comportamento di Apache Kafka, impostate la proprietà su true. `allow.everyone.if.no.acl.found` In Amazon MSK è impostata su true per impostazione predefinita. Ciò significa che con i cluster Amazon MSK, se non ACLs imposti esplicitamente una risorsa, tutti i principali possono accedere a tale risorsa. Se abiliti una ACLs risorsa, solo i responsabili autorizzati possono accedervi. Se desideri limitare l'accesso a un argomento e autorizzare un client utilizzando l'autenticazione reciproca TLS, aggiungi ACLs utilizzando la CLI di autorizzazione Apache Kafka. [Per ulteriori informazioni sull'aggiunta, la rimozione e l'elenco, consulta Kafka Authorization Command Line ACLs Interface.](https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Authorization+Command+Line+Interface)
Poiché Amazon MSK configura i broker come utenti privilegiati, possono accedere a tutti gli argomenti. Questo aiuta i broker a replicare i messaggi dalla partizione primaria indipendentemente dal fatto che la `allow.everyone.if.no.acl.found` proprietà sia definita o meno per la configurazione del cluster.
**Per aggiungere o rimuovere l'accesso in lettura e scrittura a un argomento**
1. Aggiungi i tuoi broker alla tabella ACL per consentire loro di leggere tutti gli argomenti esistenti. ACLs Per concedere ai broker l'accesso in lettura a un argomento, esegui il comando seguente su un computer client in grado di comunicare con il cluster MSK.
Sostituiscila *Distinguished-Name* con il DNS di uno qualsiasi dei broker bootstrap del tuo cluster, quindi sostituisci la stringa prima del primo punto di questo nome distinto con un asterisco (). `*` Ad esempio, se uno dei broker di bootstrap del tuo cluster dispone del DNS`b-6.mytestcluster.67281x.c4.kafka.us-east-1.amazonaws.com`, sostituiscilo nel comando seguente con. *Distinguished-Name* `*.mytestcluster.67281x.c4.kafka.us-east-1.amazonaws.com` Per informazioni su come ottenere i broker bootstrap, consulta [Ottieni i broker bootstrap per un cluster Amazon MSK](msk-get-bootstrap-brokers.md).
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Read --group=* --topic Topic-Name
```
1. Per concedere a un'applicazione client l'accesso in lettura a un argomento, esegui il comando seguente sul computer client. Se utilizzi l'autenticazione TLS reciproca, utilizza la stessa *Distinguished-Name* che hai usato quando hai creato la chiave privata.
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Read --group=* --topic Topic-Name
```
Per rimuovere l'accesso in lettura, è possibile eseguire lo stesso comando, sostituendo `--add` con `--remove`.
1. Per concedere l'accesso in scrittura a un argomento, eseguire il comando seguente sul computer client. Se utilizzi l'autenticazione TLS reciproca, utilizza la stessa *Distinguished-Name* che hai usato per creare la chiave privata.
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Write --topic Topic-Name
```
Per rimuovere l'accesso in scrittura, è possibile eseguire lo stesso comando, sostituendo `--add` con `--remove`.
# Modifica del gruppo di sicurezza di un cluster Amazon MSK
Questa pagina spiega come modificare il gruppo di sicurezza di un cluster MSK esistente. Potrebbe essere necessario modificare il gruppo di sicurezza di un cluster per fornire l'accesso a un determinato gruppo di utenti o per limitare l'accesso al cluster. Per ulteriori informazioni sui gruppi di sicurezza, consulta la pagina [Security groups for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) nella Guida per l'utente di Amazon VPC.
1. Usa l'[ListNodes](https://docs.amazonaws.cn/en_us/msk/1.0/apireference/clusters-clusterarn-nodes.html#ListNodes)API o il comando [list-nodes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/list-nodes.html) in AWS CLI per ottenere un elenco dei broker del tuo cluster. I risultati di questa operazione includono le interfacce IDs di rete elastiche (ENIs) associate ai broker.
1. Accedi Console di gestione AWS e apri la console Amazon EC2 all'indirizzo. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)
1. Utilizzando l'elenco a discesa nell'angolo in alto a destra della schermata, seleziona la regione in cui è implementato il cluster.
1. Nel riquadro a sinistra, in **Rete e sicurezza**, scegli **Interfacce di rete**.
1. Seleziona il primo ENI che hai ottenuto nel primo passaggio. Scegli il menu **Operazioni** nella parte superiore dello schermo, quindi scegli **Modifica gruppi di sicurezza**. Assegna il nuovo gruppo di sicurezza a questo ENI. Ripeti questo passaggio per ognuno dei ENIs passaggi ottenuti nel primo passaggio.
**Nota**
Le modifiche apportate al gruppo di sicurezza di un cluster utilizzando la console Amazon EC2 non si riflettono nelle **Impostazioni di rete** della console MSK.
1. Configura le regole del nuovo gruppo di sicurezza per garantire che i tuoi client abbiano accesso ai broker. Per informazioni sull'impostazione delle regole del gruppi di sicurezza, consulta la pagina [Adding, Removing, and Updating Rules](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#AddRemoveRules) nella guida per l'utente di Amazon VPC.
**Importante**
Se modifichi il gruppo di sicurezza associato ai broker di un cluster e poi aggiungi nuovi broker a tale cluster, Amazon MSK associa i nuovi broker al gruppo di sicurezza originale associato al cluster al momento della creazione dello stesso. Tuttavia, affinché un cluster funzioni correttamente, tutti i relativi broker devono essere associati allo stesso gruppo di sicurezza. Pertanto, se si aggiungono nuovi broker dopo aver modificato il gruppo di sicurezza, è necessario seguire nuovamente la procedura precedente e aggiornare i ENIs nuovi broker.
# Controlla l'accesso ai ZooKeeper nodi Apache nel tuo cluster Amazon MSK
Per motivi di sicurezza, puoi limitare l'accesso ai ZooKeeper nodi Apache che fanno parte del tuo cluster Amazon MSK. Per limitare l'accesso ai nodi, puoi assegnare loro un gruppo di sicurezza separato. Puoi quindi stabilire chi ottiene l'accesso a tale gruppo di sicurezza.
**Importante**
Questa sezione non si applica ai cluster in esecuzione in modalità. KRaft Per informazioni, consulta [KRaft modalità](metadata-management.md#kraft-intro).
**Topics**
+ [Per collocare i ZooKeeper nodi Apache in un gruppo di sicurezza separato](zookeeper-security-group.md)
+ [Utilizzo della sicurezza TLS con Apache ZooKeeper](zookeeper-security-tls.md)
# Per collocare i ZooKeeper nodi Apache in un gruppo di sicurezza separato
Per limitare l'accesso ai ZooKeeper nodi Apache, puoi assegnare loro un gruppo di sicurezza separato. Puoi scegliere chi ha accesso a questo nuovo gruppo di sicurezza impostando le regole del gruppo di sicurezza.
1. Ottieni la stringa di ZooKeeper connessione Apache per il tuo cluster. Per scoprire come, consulta [ZooKeeper modalità](metadata-management.md#msk-get-connection-string). La stringa di connessione contiene i nomi DNS dei tuoi nodi ZooKeeper Apache.
1. Utilizzare uno strumento simile a `host` o `ping` per convertire i nomi DNS ottenuti nel passaggio precedente in indirizzi IP. Salvare questi indirizzi IP perché saranno necessari più avanti in questa procedura.
1. Accedi Console di gestione AWS e apri la console Amazon EC2 all'indirizzo. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)
1. Nel riquadro di navigazione, in **NETWORK & SECURITY (Rete e sicurezza)**, scegliere **Network Interfaces (Interfacce di rete)**.
1. Nel campo di ricerca sopra la tabella delle interfacce di rete, digitare il nome del cluster, quindi premere Invio. Questo limita il numero di interfacce di rete visualizzate nella tabella a quelle associate al cluster.
1. Selezionare la casella di controllo all'inizio della riga corrispondente alla prima interfaccia di rete nell'elenco.
1. Nel riquadro dei dettagli in fondo alla pagina, cerca l'** IPv4 IP privato primario**. Se questo indirizzo IP corrisponde a uno degli indirizzi IP ottenuti nel primo passaggio di questa procedura, significa che questa interfaccia di rete è assegnata a un ZooKeeper nodo Apache che fa parte del cluster. In caso contrario, deselezionare la casella di controllo accanto a questa interfaccia di rete e selezionare l'interfaccia di rete successiva nell'elenco. L'ordine di selezione delle interfacce di rete non ha importanza. Nei passaggi successivi, eseguirai le stesse operazioni su tutte le interfacce di rete assegnate ai ZooKeeper nodi Apache, una per una.
1. Quando selezioni un'interfaccia di rete che corrisponde a un ZooKeeper nodo Apache, scegli il menu **Azioni** nella parte superiore della pagina, quindi scegli **Cambia** gruppi di sicurezza. Assegnare un nuovo gruppo di sicurezza a questa interfaccia di rete. Per ulteriori informazioni sulla creazione dei gruppi di sicurezza, consulta la pagina [Creating a Security Group](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#CreatingSecurityGroups) nella documentazione di Amazon VPC.
1. Ripeti il passaggio precedente per assegnare lo stesso nuovo gruppo di sicurezza a tutte le interfacce di rete associate ai ZooKeeper nodi Apache del cluster.
1. È ora possibile scegliere chi dispone dell'accesso a questo nuovo gruppo di sicurezza. Per informazioni sull'impostazione delle regole dei gruppi di sicurezza, consulta la pagina [Adding, Removing, and Updating Rules](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#AddRemoveRules) nella documentazione di Amazon VPC.
# Utilizzo della sicurezza TLS con Apache ZooKeeper
Puoi utilizzare la sicurezza TLS per la crittografia in transito tra i tuoi client e i tuoi nodi Apache. ZooKeeper Per implementare la sicurezza TLS con i tuoi ZooKeeper nodi Apache, procedi come segue:
+ I cluster devono utilizzare Apache Kafka versione 2.5.1 o successiva per utilizzare la sicurezza TLS con Apache. ZooKeeper
+ Abilita la sicurezza TLS quando crei o configuri il cluster. I cluster creati con Apache Kafka versione 2.5.1 o successiva con TLS abilitato utilizzano automaticamente la sicurezza TLS con gli endpoint Apache. ZooKeeper Per informazioni sulla configurazione della sicurezza TLS, consulta la pagina [Inizia a usare la crittografia Amazon MSK](msk-working-with-encryption.md).
+ Recupera gli endpoint TLS Apache utilizzando l'operazione. ZooKeeper [DescribeCluster ](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)
+ Crea un file di ZooKeeper configurazione Apache da utilizzare con [https://kafka.apache.org/documentation/#security_authz_cli](https://kafka.apache.org/documentation/#security_authz_cli)gli strumenti `kafka-configs.sh` and o con la shell. ZooKeeper Con ogni strumento, si utilizza il `--zk-tls-config-file` parametro per specificare la configurazione di Apache ZooKeeper .
L'esempio seguente mostra un tipico file di configurazione di Apache ZooKeeper :
```
zookeeper.ssl.client.enable=true
zookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
zookeeper.ssl.keystore.location=kafka.jks
zookeeper.ssl.keystore.password=test1234
zookeeper.ssl.truststore.location=truststore.jks
zookeeper.ssl.truststore.password=test1234
```
+ Per altri comandi (come`kafka-topics`), è necessario utilizzare la variabile di `KAFKA_OPTS` ambiente per configurare i parametri di Apache ZooKeeper. L'esempio seguente mostra come configurare la variabile di `KAFKA_OPTS` ambiente per passare i ZooKeeper parametri Apache ad altri comandi:
```
export KAFKA_OPTS="
-Dzookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
-Dzookeeper.client.secure=true
-Dzookeeper.ssl.trustStore.location=/home/ec2-user/kafka.client.truststore.jks
-Dzookeeper.ssl.trustStore.password=changeit"
```
Dopo aver configurato la variabile di ambiente `KAFKA_OPTS`, è possibile utilizzare normalmente i comandi della CLI. L'esempio seguente crea un argomento di Apache Kafka utilizzando la ZooKeeper configurazione di Apache dalla variabile di ambiente: `KAFKA_OPTS`
```
/bin/kafka-topics.sh --create --zookeeper ZooKeeperTLSConnectString --replication-factor 3 --partitions 1 --topic AWSKafkaTutorialTopic
```
**Nota**
I nomi dei parametri utilizzati nel file di ZooKeeper configurazione di Apache e quelli utilizzati nella variabile di `KAFKA_OPTS` ambiente non sono coerenti. Presta attenzione ai nomi che usi con ciascun parametri nel file di configurazione e nella variabile di ambiente `KAFKA_OPTS`.
Per ulteriori informazioni sull'accesso ai ZooKeeper nodi Apache con TLS, vedi [KIP-515: Abilita il client ZK a usare la nuova autenticazione supportata da](https://cwiki.apache.org/confluence/display/KAFKA/KIP-515%3A+Enable+ZK+client+to+use+the+new+TLS+supported+authentication) TLS.
# Convalida della conformità per Streaming gestito da Amazon per Apache Kafka
Revisori di terze parti valutano la sicurezza e la conformità di Streaming gestito da Amazon per Apache Kafka nell'ambito dei programmi di conformità di AWS . Questi includono PCI e HIPAA BAA.
Per un elenco di AWS servizi nell'ambito di programmi di conformità specifici, consulta [Amazon Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/) . Per informazioni generali, consulta Programmi di [AWS conformità Programmi](https://aws.amazon.com/compliance/programs/) di di .
È possibile scaricare report di audit di terze parti utilizzando AWS Artifact. Per ulteriori informazioni, consulta [Scaricamento dei report in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) .
La tua responsabilità di conformità quando usi Amazon MSK è determinata dalla sensibilità dei tuoi dati, dagli obiettivi di conformità della tua azienda e dalle leggi e dai regolamenti applicabili. AWS fornisce le seguenti risorse per contribuire alla conformità:
+ [Le guide rapide per la sicurezza e la conformità](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance): queste guide all'implementazione illustrano considerazioni architettoniche e forniscono i passaggi per l'implementazione di ambienti di base incentrati sulla sicurezza e sulla conformità su AWS.
+ [Whitepaper sull'architettura per la sicurezza e la conformità HIPAA: questo white paper](https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.html) descrive come le aziende possono utilizzare per creare applicazioni conformi allo standard HIPAA. AWS
+ AWS Risorse per [la conformità Risorse per la conformità](https://aws.amazon.com/compliance/resources/): questa raccolta di potrebbe riguardare il settore e la località in cui operate.
+ [Valutazione delle risorse con le regole](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) nella *Guida per gli AWS Config sviluppatori*: il AWS Config servizio valuta la conformità delle configurazioni delle risorse alle pratiche interne, alle linee guida del settore e alle normative.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)— Questo AWS servizio offre una visione completa dello stato di sicurezza dell'utente, AWS che consente di verificare la conformità agli standard e alle best practice del settore della sicurezza.
# Resilienza in Streaming gestito da Amazon per Apache Kafka
L'infrastruttura AWS globale è costruita attorno a regioni e zone di disponibilità. AWS AWS Le regioni forniscono più zone di disponibilità fisicamente separate e isolate, collegate con reti a bassa latenza, ad alto throughput e altamente ridondanti. Con le zone di disponibilità è possibile progettare e gestire applicazioni e database che eseguono automaticamente il failover tra zone di disponibilità senza interruzioni. Le zone di disponibilità sono più disponibili, tolleranti ai guasti e scalabili rispetto alle infrastrutture a data center singolo o multiplo tradizionali.
[Per ulteriori informazioni su AWS regioni e zone di disponibilità, consulta Global Infrastructure.AWS](https://aws.amazon.com/about-aws/global-infrastructure/)
# Sicurezza dell'infrastruttura in Streaming gestito da Amazon per Apache Kafka
In quanto servizio gestito, Amazon Managed Streaming for Apache Kafka è protetto AWS dalle procedure di sicurezza di rete globali descritte nel white paper di [Amazon Web Services:](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf) Overview of Security Processes.
Utilizzi chiamate API AWS pubblicate per accedere ad Amazon MSK attraverso la rete. I client devono supportare Transport Layer Security (TLS) 1.0 o versioni successive. È consigliabile TLS 1.2 o versioni successive. I client devono, inoltre, supportare le suite di cifratura con PFS (Perfect Forward Secrecy), ad esempio Ephemeral Diffie-Hellman (DHE) o Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). La maggior parte dei sistemi moderni, come Java 7 e versioni successive, supporta tali modalità.
Inoltre, le richieste devono essere firmate utilizzando un ID chiave di accesso e una chiave di accesso segreta associata a un principale IAM. In alternativa è possibile utilizzare [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) per generare credenziali di sicurezza temporanee per sottoscrivere le richieste.
# Registrazione Amazon MSK
Puoi inviare i log del broker Apache Kafka a uno o più dei seguenti tipi di destinazione: Amazon Logs, Amazon S3 CloudWatch , Amazon Data Firehose. Puoi anche registrare le chiamate API Amazon MSK con AWS CloudTrail.
**Nota**
I log dei broker sono disponibili sia sui broker MSK Standard che Express.
## Log di broker
I log di broker consentono di risolvere i problemi delle applicazioni Apache Kafka e di analizzare le comunicazioni con il cluster MSK. È possibile configurare il cluster MSK nuovo o esistente per fornire i log dei broker a livello Info a uno o più dei seguenti tipi di risorse di destinazione: un gruppo di CloudWatch log, un bucket S3, un flusso di distribuzione Firehose. Tramite Firehose è quindi possibile inviare i dati di registro dal flusso di distribuzione a OpenSearch Service.
È necessario creare una risorsa di destinazione prima di configurare il cluster per consegnargli i log del broker. Amazon MSK non crea queste risorse di destinazione se non esistono già. Per informazioni su questi tre tipi di risorse di destinazione e su come crearle, consultare la documentazione seguente:
+ [ CloudWatch Registri Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html)
+ [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)
### Autorizzazioni richieste
Per configurare una destinazione per i log del broker Amazon MSK, l'identità IAM che utilizzi per le operazioni Amazon MSK deve disporre delle autorizzazioni descritte nella policy [AWS politica gestita: Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md).
Per eseguire lo streaming dei log di broker a un bucket S3, è richiesta anche l'autorizzazione `s3:PutBucketPolicy`. Per informazioni sulle policy dei bucket S3, consulta la pagina [How Do I Add an S3 Bucket Policy?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/add-bucket-policy.html) nella Guida per l'utente di Amazon S3. Per informazioni sulle policy IAM in generale, consulta la pagina [Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) nella Guida per l'utente di IAM.
### Policy della chiave KMS necessaria per l'utilizzo con i bucket SSE-KMS
Se hai abilitato la crittografia lato server per il tuo bucket S3 utilizzando chiavi AWS KMS gestite (SSE-KMS) con una chiave gestita dal cliente, aggiungi quanto segue alla policy chiave per la tua chiave KMS in modo che Amazon MSK possa scrivere i file del broker nel bucket.
```
{
"Sid": "Allow Amazon MSK to use the key.",
"Effect": "Allow",
"Principal": {
"Service": [
"delivery.logs.amazonaws.com"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
}
```
### Configura i log del broker utilizzando Console di gestione AWS
Se stai creando un nuovo cluster, cerca l'intestazione **Broker log delivery (Recapito del log del broker)** nella sezione **Monitoring (Monitoraggio)** . Puoi specificare le destinazioni a cui Amazon MSK deve consegnare i log del broker.
Per un cluster esistente, scegli il cluster dall'elenco di cluster, quindi seleziona la scheda **Proprietà**. Scorri verso il basso fino alla sezione **Consegna dei log** e scegli il relativo pulsante **Modifica**. Puoi specificare le destinazioni a cui Amazon MSK deve consegnare i log del broker.
### Configurare i log del broker utilizzando il AWS CLI
Quando utilizzi i comandi `create-cluster` o `update-monitoring`, puoi specificare facoltativamente il parametro `logging-info` e passarlo a una struttura JSON come nell'esempio seguente. In questo JSON, tutti e tre i tipi di destinazione sono facoltativi.
**Nota**
È necessario impostare il `LogDeliveryEnabled` tag `true` su Firehose Streams per configurare la consegna dei log. Il ruolo collegato al servizio che AWS crea per CloudWatch i log utilizza questo tag per concedere l'autorizzazione per tutti i flussi di distribuzione Firehose. Se rimuovi questo tag, il ruolo collegato al servizio non sarà in grado di inviare i log allo stream Firehose. *Per vedere un esempio di policy IAM che mostra le autorizzazioni incluse nel ruolo collegato al servizio, consulta i [ruoli IAM usati per le autorizzazioni delle risorse nella](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-Firehose.html) Amazon User Guide. CloudWatch *
```
{
"BrokerLogs": {
"S3": {
"Bucket": "amzn-s3-demo-bucket",
"Prefix": "ExamplePrefix",
"Enabled": true
},
"Firehose": {
"DeliveryStream": "ExampleDeliveryStreamName",
"Enabled": true
},
"CloudWatchLogs": {
"Enabled": true,
"LogGroup": "ExampleLogGroupName"
}
}
}
```
### Configura i log del broker utilizzando l'API
È possibile specificare la `loggingInfo` struttura opzionale nel file JSON che si passa alle operazioni [CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)or [UpdateMonitoring](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-monitoring.html#UpdateMonitoring).
**Nota**
Per impostazione predefinita, quando la registrazione del broker è abilitata, Amazon MSK registra i log di livello `INFO` nelle destinazioni specificate. [Tuttavia, per i broker Standard, gli utenti di Apache Kafka 2.4.X e versioni successive possono impostare dinamicamente il livello di log del broker su uno qualsiasi dei livelli di log log4j.](https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html) Per informazioni sull'impostazione dinamica del livello di log del broker, consulta la pagina [KIP-412: Extend Admin API to support dynamic application log levels](https://cwiki.apache.org/confluence/display/KAFKA/KIP-412%3A+Extend+Admin+API+to+support+dynamic+application+log+levels). Se imposti dinamicamente il livello di registro su `DEBUG` o`TRACE`, ti consigliamo di utilizzare Amazon S3 o Firehose come destinazione del registro. Se utilizzi CloudWatch Logs come destinazione di log e abiliti `DEBUG` o `TRACE` livelli dinamicamente la registrazione, Amazon MSK può fornire continuamente un campione di log. Ciò può influire in modo significativo sulle prestazioni del broker e deve essere utilizzato solo quando il livello di log `INFO` non è sufficientemente dettagliato da consentire di determinare la causa principale di un problema.
# Registra le chiamate API con AWS CloudTrail
**Nota**
AWS CloudTrail i log sono disponibili per Amazon MSK solo quando li usi. [Controllo degli accessi IAM](iam-access-control.md)
Amazon MSK è integrato con AWS CloudTrail, un servizio che fornisce un registro delle azioni intraprese da un utente, un ruolo o un AWS servizio in Amazon MSK. CloudTrail acquisisce le chiamate API come eventi. Le chiamate acquisite includono le chiamate dalla console Amazon MSK e le chiamate di codice alle operazioni API di Amazon MSK. Registra anche le operazioni di Apache Kafka come la creazione e la modifica di argomenti e gruppi.
Se crei un trail, puoi abilitare la distribuzione continua di CloudTrail eventi a un bucket Amazon S3, inclusi gli eventi per Amazon MSK. **Se non configuri un percorso, puoi comunque visualizzare gli eventi più recenti nella CloudTrail console nella cronologia degli eventi.** Utilizzando le informazioni raccolte da CloudTrail, puoi determinare la richiesta effettuata ad Amazon MSK o l'azione Apache Kafka, l'indirizzo IP da cui è stata effettuata la richiesta, chi ha effettuato la richiesta, quando è stata effettuata e dettagli aggiuntivi.
[Per ulteriori informazioni CloudTrail, incluso come configurarlo e abilitarlo, consulta la Guida per l'utente.AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)
## Informazioni su Amazon MSK in CloudTrail
CloudTrail è abilitato sul tuo account Amazon Web Services al momento della creazione dell'account. Quando si verifica un'attività di evento supportata in un cluster MSK, tale attività viene registrata in un CloudTrail evento insieme ad altri eventi di AWS servizio nella **cronologia** degli eventi. Puoi visualizzare, cercare e scaricare gli eventi recenti nell'account Amazon Web Services. Per ulteriori informazioni, consulta [Visualizzazione di eventi mediante la cronologia eventi di CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
Per una registrazione continua degli eventi nell'account Amazon Web Services che includa gli eventi per Amazon MSK, crea un percorso. Un *trail* consente di CloudTrail inviare file di log a un bucket Amazon S3. Per impostazione predefinita, quando si crea un trail nella console, il trail sarà valido in tutte le Regioni . Il trail registra gli eventi di tutte le Regioni nella partizione AWS e distribuisce i file di log nel bucket Amazon S3 specificato. Inoltre, puoi configurare altri servizi Amazon per analizzare ulteriormente e agire in base ai dati sugli eventi raccolti nei CloudTrail log. Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Panoramica della creazione di un trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail Servizi e integrazioni supportati](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Configurazione delle notifiche Amazon SNS per CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Ricezione di file di CloudTrail registro da più regioni](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) e [ricezione di file di CloudTrail registro da](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html) più account
Amazon MSK registra tutte le [operazioni di Amazon MSK](https://docs.aws.amazon.com/MSK/2.0/APIReference/operations.html) come eventi nei CloudTrail file di registro. Inoltre, registra le seguenti operazioni di Apache Kafka.
+ cluster kafka: DescribeClusterDynamicConfiguration
+ ammasso kafka: AlterClusterDynamicConfiguration
+ ammasso kafka: CreateTopic
+ ammasso kafka: DescribeTopicDynamicConfiguration
+ ammasso kafka: AlterTopic
+ ammasso kafka: AlterTopicDynamicConfiguration
+ ammasso kafka: DeleteTopic
Ogni evento o voce di log contiene informazioni sull’utente che ha generato la richiesta. Le informazioni di identità consentono di determinare quanto segue:
+ Se la richiesta è stata effettuata con credenziali utente root o utente AWS Identity and Access Management (IAM).
+ Se la richiesta è stata effettuata con le credenziali di sicurezza temporanee per un ruolo o un utente federato.
+ Se la richiesta è stata effettuata da un altro AWS servizio.
Per ulteriori informazioni, consulta [Elemento CloudTrail userIdentity](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
## Esempio: voci del file di log di Amazon MSK
Un trail è una configurazione che consente la distribuzione di eventi come file di log in un bucket Amazon S3 specificato dall'utente. CloudTrail i file di registro contengono una o più voci di registro. Un evento rappresenta una singola richiesta proveniente da qualsiasi fonte e include informazioni sull'azione richiesta, la data e l'ora dell'azione, i parametri della richiesta e così via. CloudTrail i file di registro non sono una traccia stack ordinata delle chiamate API pubbliche e delle azioni di Apache Kafka, quindi non vengono visualizzati in un ordine specifico.
L'esempio seguente mostra le voci di CloudTrail registro che illustrano le azioni `DescribeCluster` e `DeleteCluster` Amazon MSK.
```
{
"Records": [
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEF0123456789ABCDE",
"arn": "arn:aws:iam::012345678901:user/Joe",
"accountId": "012345678901",
"accessKeyId": "AIDACKCEVSQ6C2EXAMPLE",
"userName": "Joe"
},
"eventTime": "2018-12-12T02:29:24Z",
"eventSource": "kafka.amazonaws.com",
"eventName": "DescribeCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.0",
"userAgent": "aws-cli/1.14.67 Python/3.6.0 Windows/10 botocore/1.9.20",
"requestParameters": {
"clusterArn": "arn%3Aaws%3Akafka%3Aus-east-1%3A012345678901%3Acluster%2Fexamplecluster%2F01234567-abcd-0123-abcd-abcd0123efa-2"
},
"responseElements": null,
"requestID": "bd83f636-fdb5-abcd-0123-157e2fbf2bde",
"eventID": "60052aba-0123-4511-bcde-3e18dbd42aa4",
"readOnly": true,
"eventType": "AwsApiCall",
"recipientAccountId": "012345678901"
},
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEF0123456789ABCDE",
"arn": "arn:aws:iam::012345678901:user/Joe",
"accountId": "012345678901",
"accessKeyId": "AIDACKCEVSQ6C2EXAMPLE",
"userName": "Joe"
},
"eventTime": "2018-12-12T02:29:40Z",
"eventSource": "kafka.amazonaws.com",
"eventName": "DeleteCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.0",
"userAgent": "aws-cli/1.14.67 Python/3.6.0 Windows/10 botocore/1.9.20",
"requestParameters": {
"clusterArn": "arn%3Aaws%3Akafka%3Aus-east-1%3A012345678901%3Acluster%2Fexamplecluster%2F01234567-abcd-0123-abcd-abcd0123efa-2"
},
"responseElements": {
"clusterArn": "arn:aws:kafka:us-east-1:012345678901:cluster/examplecluster/01234567-abcd-0123-abcd-abcd0123efa-2",
"state": "DELETING"
},
"requestID": "c6bfb3f7-abcd-0123-afa5-293519897703",
"eventID": "8a7f1fcf-0123-abcd-9bdb-1ebf0663a75c",
"readOnly": false,
"eventType": "AwsApiCall",
"recipientAccountId": "012345678901"
}
]
}
```
L'esempio seguente mostra una voce di CloudTrail registro che illustra l'`kafka-cluster:CreateTopic`azione.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEFGH1IJKLMN2P34Q5",
"arn": "arn:aws:iam::111122223333:user/Admin",
"accountId": "111122223333",
"accessKeyId": "CDEFAB1C2UUUUU3AB4TT",
"userName": "Admin"
},
"eventTime": "2021-03-01T12:51:19Z",
"eventSource": "kafka-cluster.amazonaws.com",
"eventName": "CreateTopic",
"awsRegion": "us-east-1",
"sourceIPAddress": "198.51.100.0/24",
"userAgent": "aws-msk-iam-auth/unknown-version/aws-internal/3 aws-sdk-java/1.11.970 Linux/4.14.214-160.339.amzn2.x86_64 OpenJDK_64-Bit_Server_VM/25.272-b10 java/1.8.0_272 scala/2.12.8 vendor/Red_Hat,_Inc.",
"requestParameters": {
"kafkaAPI": "CreateTopics",
"resourceARN": "arn:aws:kafka:us-east-1:111122223333:topic/IamAuthCluster/3ebafd8e-dae9-440d-85db-4ef52679674d-1/Topic9"
},
"responseElements": null,
"requestID": "e7c5e49f-6aac-4c9a-a1d1-c2c46599f5e4",
"eventID": "be1f93fd-4f14-4634-ab02-b5a79cb833d2",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "111122223333"
}
```
# Gestione dei metadati
Amazon MSK supporta Apache ZooKeeper o le modalità di gestione KRaft dei metadati.
Dalla versione 3.7.x di Apache Kafka su Amazon MSK, puoi creare cluster che utilizzano la modalità anziché la modalità. KRaft ZooKeeper KRafti cluster basati su controller all'interno di Kafka per gestire i metadati.
**Topics**
+ [ZooKeeper modalità](#msk-get-connection-string)
+ [KRaft modalità](#kraft-intro)
## ZooKeeper modalità
[Apache ZooKeeper](https://zookeeper.apache.org/) è «un servizio centralizzato per la gestione delle informazioni di configurazione, la denominazione, la sincronizzazione distribuita e la fornitura di servizi di gruppo. Tutti questi tipi di servizi vengono utilizzati in una forma o nell'altra da applicazioni distribuite», incluso Apache Kafka.
Se il tuo cluster utilizza la ZooKeeper modalità, puoi utilizzare i passaggi seguenti per ottenere la stringa di connessione ZooKeeper Apache. Tuttavia, ti consigliamo di utilizzare il `BootstrapServerString` per connetterti al tuo cluster ed eseguire operazioni di amministrazione poiché il `--zookeeper` flag è stato reso obsoleto in Kafka 2.5 ed è stato rimosso da Kafka 3.0.
### ZooKeeper Ottenere la stringa di connessione di Apache utilizzando il Console di gestione AWS
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. La tabella mostra tutti i cluster per la regione corrente in questo account. Scegli il nome di un cluster per visualizzarne la descrizione.
1. Nella pagina **Riepilogo del cluster**, scegli **Visualizza informazioni sul client**. Questo mostra i broker bootstrap e la stringa di connessione ZooKeeper Apache.
### Ottenere la stringa di connessione Apache usando ZooKeeper il AWS CLI
1. Se l'Amazon Resource Name (ARN) del cluster non è noto, puoi trovarlo elencando tutti i cluster nell'account. Per ulteriori informazioni, consulta [Elenca i cluster Amazon MSK](msk-list-clusters.md).
1. Per ottenere la stringa di ZooKeeper connessione Apache, insieme ad altre informazioni sul cluster, esegui il comando seguente, sostituendolo *ClusterArn* con l'ARN del cluster.
```
aws kafka describe-cluster --cluster-arn ClusterArn
```
L'output di questo comando `describe-cluster` è simile all'esempio JSON seguente.
```
{
"ClusterInfo": {
"BrokerNodeGroupInfo": {
"BrokerAZDistribution": "DEFAULT",
"ClientSubnets": [
"subnet-0123456789abcdef0",
"subnet-2468013579abcdef1",
"subnet-1357902468abcdef2"
],
"InstanceType": "kafka.m5.large",
"StorageInfo": {
"EbsStorageInfo": {
"VolumeSize": 1000
}
}
},
"ClusterArn": "arn:aws:kafka:us-east-1:111122223333:cluster/testcluster/12345678-abcd-4567-2345-abcdef123456-2",
"ClusterName": "testcluster",
"CreationTime": "2018-12-02T17:38:36.75Z",
"CurrentBrokerSoftwareInfo": {
"KafkaVersion": "2.2.1"
},
"CurrentVersion": "K13V1IB3VIYZZH",
"EncryptionInfo": {
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "arn:aws:kms:us-east-1:555555555555:key/12345678-abcd-2345-ef01-abcdef123456"
}
},
"EnhancedMonitoring": "DEFAULT",
"NumberOfBrokerNodes": 3,
"State": "ACTIVE",
"ZookeeperConnectString": "10.0.1.101:2018,10.0.2.101:2018,10.0.3.101:2018"
}
}
```
L'esempio JSON precedente mostra la chiave `ZookeeperConnectString` nell'output del comando `describe-cluster`. Copia il valore corrispondente a questa chiave e salvalo per utilizzarlo quando è necessario creare un argomento nel cluster.
**Importante**
Il cluster Amazon MSK deve trovarsi nello `ACTIVE` stato in cui è possibile ottenere la stringa di ZooKeeper connessione Apache. Quando un cluster è ancora nello stato `CREATING`, l'output del comando `describe-cluster` non include `ZookeeperConnectString`. In questo caso, occorre attendere alcuni minuti ed eseguire nuovamente `describe-cluster` dopo che il cluster raggiunge lo stato `ACTIVE`.
### Ottenere la stringa di ZooKeeper connessione Apache tramite l'API
Per ottenere la stringa di ZooKeeper connessione Apache utilizzando l'API, vedi. [DescribeCluster](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)
## KRaft modalità
Amazon MSK ha introdotto il supporto per KRaft (Apache Kafka Raft) nella versione 3.7.x di Kafka. [La community Apache Kafka si è sviluppata KRaft per sostituire Apache per la gestione dei metadati nei cluster Apache Kafka. ZooKeeper](#msk-get-connection-string) In KRaft modalità, i metadati del cluster vengono propagati all'interno di un gruppo di controller Kafka, che fanno parte del cluster Kafka, anziché tra i nodi. ZooKeeper KRafti controller sono inclusi senza costi aggiuntivi per l'utente e non richiedono alcuna configurazione o gestione aggiuntiva da parte dell'utente. Vedi [KIP-500](https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum) per ulteriori informazioni su. KRaft
Ecco alcuni punti da tenere in considerazione sulla KRaft modalità su MSK:
+ KRaft la modalità è disponibile solo per i nuovi cluster. Non è possibile cambiare modalità di metadati una volta creato il cluster.
+ Sulla console MSK, è possibile creare un cluster basato su Kraft scegliendo la versione 3.7.x di Kafka e selezionando la casella di controllo nella finestra di creazione del cluster. KRaft
+ Per creare un cluster in KRaft modalità utilizzando l'API [https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)o le operazioni MSK, è necessario utilizzare come versione. [https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2)`3.7.x.kraft` Utilizza `3.7.x` come versione per creare un cluster in ZooKeeper modalità.
+ Il numero di partizioni per broker è lo stesso su KRaft e per i cluster ZooKeeper basati. Tuttavia, KRaft consente di ospitare più partizioni per cluster fornendo [più broker](https://docs.aws.amazon.com/msk/latest/developerguide/limits.html) in un cluster.
+ Non sono necessarie modifiche all'API per utilizzare la KRaft modalità su Amazon MSK. Tuttavia, se i tuoi client utilizzano ancora la stringa di `--zookeeper` connessione oggi, dovresti aggiornarli in modo che utilizzino la stringa di `--bootstrap-server` connessione per connettersi al cluster. Il `--zookeeper` flag è obsoleto nella versione 2.5 di Apache Kafka e viene rimosso a partire dalla versione 3.0 di Kafka. Ti consigliamo quindi di utilizzare le versioni recenti del client Apache Kafka e la stringa di connessione per tutte le connessioni al tuo cluster. `--bootstrap-server`
+ ZooKeeper la modalità continua a essere disponibile per tutte le versioni rilasciate in cui zookeeper è supportato anche da Apache Kafka. Vedi [Versioni di Apache Kafka supportate](supported-kafka-versions.md) i dettagli sulla fine del supporto per le versioni di Apache Kafka e gli aggiornamenti futuri.
+ È necessario verificare che tutti gli strumenti utilizzati siano in grado di utilizzare Kafka Admin senza connessioni. APIs ZooKeeper Consulta la procedura aggiornata [Usa LinkedIn il Cruise Control per Apache Kafka con Amazon MSK](cruise-control.md) per connettere il cluster a Cruise Control. Cruise Control fornisce anche istruzioni per utilizzare [il Cruise Control senza ZooKeeper](https://github.com/linkedin/cruise-control/wiki/Run-without-ZooKeeper).
+ Non è necessario accedere direttamente ai KRaft controller del cluster per eventuali azioni amministrative. Tuttavia, se si utilizza il monitoraggio aperto per raccogliere le metriche, sono necessari anche gli endpoint DNS dei controller per raccogliere alcune metriche non correlate ai controller sul cluster. È possibile ottenere questi endpoint DNS dalla console MSK o utilizzando l'operazione API. [ListNodes](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes.html#ListNodes) Vedi [Monitora un cluster MSK Provisioned con Prometheus](open-monitoring.md) i passaggi aggiornati per configurare il monitoraggio aperto per i cluster basati. KRaft
+ Non sono necessarie [CloudWatch metriche](https://docs.aws.amazon.com/msk/latest/developerguide/metrics-details.html) aggiuntive per monitorare i cluster modali rispetto ai cluster KRaft modali. ZooKeeper MSK gestisce i KRaft controller utilizzati nei cluster.
+ È possibile continuare a gestire ACLs utilizzando i cluster in KRaft modalità utilizzando la stringa di connessione. `--bootstrap-server` Non è necessario utilizzare la stringa di `--zookeeper` connessione per gestire ACLs. Per informazioni, consulta [Apache Kafka ACLs](msk-acls.md).
+ In KRaft modalità, i metadati del cluster vengono archiviati su KRaft controller all'interno di Kafka e non su nodi esterni. ZooKeeper Pertanto, non è necessario controllare l'accesso ai nodi del controller separatamente [come si fa](https://docs.aws.amazon.com/msk/latest/developerguide/zookeeper-security.html) con i nodi. ZooKeeper
# Argomento Operazioni
Puoi usare Amazon MSK APIs per gestire argomenti nel tuo cluster MSK Provisioned senza la necessità di configurare e gestire i client di amministrazione Kafka. Con questi APIs, puoi definire o leggere le proprietà degli argomenti come il fattore di replica e il numero di partizioni, oltre a impostazioni di configurazione come le politiche di conservazione e pulizia. Puoi gestire in modo programmatico gli argomenti di Kafka utilizzando le tue interfacce familiari, tra cui AWS CLI e. AWS SDKs AWS CloudFormation Questi APIs sono inoltre integrati nella console Amazon MSK, riunendo tutte le operazioni tematiche in un unico posto. Ora puoi creare o aggiornare argomenti con pochi clic utilizzando impostazioni predefinite guidate, ottenendo al contempo una visibilità completa sulle configurazioni degli argomenti, sulle informazioni a livello di partizione e sulle metriche.
**Importante**
Le risposte API di questi argomenti riflettono i dati che si aggiornano all'incirca ogni minuto. Per conoscere lo stato più recente dell'argomento dopo aver apportato le modifiche, attendi circa un minuto prima di eseguire l'interrogazione.
## Requisiti per l'utilizzo dell'argomento APIs
+ Il cluster deve essere un cluster MSK Provisioned. Questi non APIs sono disponibili per i cluster MSK Serverless.
+ Il cluster deve eseguire Apache Kafka versione 3.6.0 o successiva. Per ulteriori informazioni sulle versioni supportate, consulta. [Versioni di Apache Kafka supportate](supported-kafka-versions.md)
+ Il cluster deve trovarsi nello `ACTIVE` stato. Per ulteriori informazioni sugli stati del cluster, consulta [Comprendi gli stati del cluster MSK Provisioned](msk-cluster-states.md).
+ È necessario disporre delle autorizzazioni IAM appropriate. Per ulteriori informazioni, consulta [Autorizzazioni IAM per le operazioni tematiche APIs](#topic-operations-permissions).
## Autorizzazioni IAM per le operazioni tematiche APIs
Per chiamarle APIs, devi disporre delle autorizzazioni IAM appropriate. La tabella seguente elenca le autorizzazioni richieste per ogni API.
**Autorizzazioni richieste per le operazioni sugli argomenti APIs**
| "Hello, World\$1" | Autorizzazioni richieste | Risorsa |
| --- | --- | --- |
| ListTopics | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | ARN del cluster, Argomento ARN |
| DescribeTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeTopicDynamicConfiguration` | ARN del cluster, Argomento ARN |
| DescribeTopicPartitions | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeTopicDynamicConfiguration` | ARN del cluster, Argomento ARN |
| CreateTopic | `kafka-cluster:Connect` `kafka-cluster:CreateTopic` | ARN del cluster, Argomento ARN |
| DeleteTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DeleteTopic` | ARN del cluster, Argomento ARN |
| UpdateTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterTopic` `kafka-cluster:AlterTopicDynamicConfiguration` | ARN del cluster, Argomento ARN |
**Nota**
Per`kafka-cluster:Connect`, specifica l'ARN del cluster nella tua policy IAM. Per tutte le altre azioni, specifica l'argomento ARN nella tua policy IAM.
**Nota**
Infatti`ListTopics`, puoi usare un carattere jolly (\$1) per abbinare tutti gli argomenti di un cluster. Ad esempio: `arn:aws:kafka:us-east-1:123456789012:topic/my-cluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/*`.
Per ulteriori informazioni sul controllo degli accessi IAM per Amazon MSK, consulta[Controllo degli accessi IAM](iam-access-control.md).
**Topics**
+ [Requisiti per l'utilizzo dell'argomento APIs](#topic-operations-requirements)
+ [Autorizzazioni IAM per le operazioni tematiche APIs](#topic-operations-permissions)
+ [Elenca gli argomenti in un cluster Amazon MSK](msk-list-topics.md)
+ [Ottieni informazioni dettagliate su un argomento](msk-describe-topic.md)
+ [Visualizzare le informazioni sulla partizione per un argomento](msk-describe-topic-partitions.md)
+ [Crea argomenti in un cluster Amazon MSK](msk-create-topic.md)
+ [Aggiornare un argomento in un cluster Amazon MSK](msk-update-topic.md)
+ [Eliminare un argomento in un cluster Amazon MSK](msk-delete-topic.md)
# Elenca gli argomenti in un cluster Amazon MSK
È possibile elencare tutti gli argomenti del cluster MSK Provisioned per visualizzare i metadati di base come il numero di partizioni e i fattori di replica. Ciò è utile per monitorare gli argomenti del cluster, eseguire controlli di inventario o identificare argomenti per ulteriori approfondimenti.
**Nota**
L'`ListTopics`API fornisce metadati tematici di base. Per ottenere informazioni dettagliate su un argomento specifico, inclusi lo stato e la configurazione correnti, utilizza l'`DescribeTopic`API. Per ulteriori informazioni, consulta [Ottieni informazioni dettagliate su un argomento](msk-describe-topic.md).
**Nota**
Questa risposta API riflette i dati che si aggiornano all'incirca ogni minuto. Per conoscere lo stato più recente dell'argomento dopo aver apportato le modifiche, attendi circa un minuto prima di eseguire la query.
**Topics**
+ [Elenca gli argomenti utilizzando il Console di gestione AWS](list-topics-console.md)
+ [Elenca gli argomenti utilizzando il AWS CLI](list-topics-cli.md)
+ [Elenca gli argomenti utilizzando l'API](list-topics-api.md)
# Elenca gli argomenti utilizzando il Console di gestione AWS
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Nell'elenco dei cluster, scegli il nome del cluster per il quale desideri elencare gli argomenti.
1. Nella pagina dei dettagli del cluster, scegli la scheda **Argomenti**.
1. La tabella mostra tutti gli argomenti del cluster, inclusi il nome dell'argomento, il numero di partizioni, il fattore di replica e il numero di out-of-sync repliche.
# Elenca gli argomenti utilizzando il AWS CLI
Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) del cluster. Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per ulteriori informazioni, consulta [Elenca i cluster Amazon MSK](msk-list-clusters.md).
```
aws kafka list-topics --cluster-arn ClusterArn
```
L'output di questo comando è simile all'esempio JSON seguente.
```
{
"topics": [
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"partitionCount": 3,
"replicationFactor": 3,
"outOfSyncReplicaCount": 0
},
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/AnotherTopic",
"topicName": "AnotherTopic",
"partitionCount": 6,
"replicationFactor": 3,
"outOfSyncReplicaCount": 1
}
]
}
```
## Impaginazione dei risultati
Se il tuo cluster ha molti argomenti, puoi utilizzare l'impaginazione per recuperare i risultati in batch più piccoli. Utilizzate il `--max-results` parametro per specificare il numero massimo di argomenti da restituire e utilizzate il `--next-token` parametro per recuperare la pagina successiva di risultati.
```
aws kafka list-topics --cluster-arn ClusterArn --max-results 10
```
Se sono disponibili più risultati, la risposta include un `nextToken` valore. Usa questo token per recuperare la pagina successiva di risultati.
```
aws kafka list-topics --cluster-arn ClusterArn --max-results 10 --next-token NextToken
```
## Filtrare gli argomenti per nome
È possibile filtrare l'elenco degli argomenti specificando un prefisso utilizzando il parametro. `--topic-name-filter` Ciò restituisce solo gli argomenti i cui nomi iniziano con il prefisso specificato.
```
aws kafka list-topics --cluster-arn ClusterArn --topic-name-filter "prod-"
```
Questo comando restituisce solo gli argomenti i cui nomi iniziano con`prod-`, ad esempio `prod-orders` o`prod-inventory`.
# Elenca gli argomenti utilizzando l'API
Per elencare gli argomenti che utilizzano l'API, consulta [ListTopics](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics.html#ListTopics).
# Ottieni informazioni dettagliate su un argomento
È possibile recuperare informazioni dettagliate su un argomento specifico nel cluster MSK Provisioned, tra cui lo stato corrente, il numero di partizioni, il fattore di replica e la configurazione. Ciò è utile per la risoluzione dei problemi, la convalida delle impostazioni degli argomenti o il monitoraggio dello stato degli argomenti durante le operazioni.
**Nota**
Questa risposta API riflette i dati che si aggiornano all'incirca ogni minuto. Per conoscere lo stato più recente dell'argomento dopo aver apportato le modifiche, attendi circa un minuto prima di eseguire la query.
**Topics**
+ [Descrivi un argomento utilizzando il Console di gestione AWS](describe-topic-console.md)
+ [Descrivere un argomento utilizzando il AWS CLI](describe-topic-cli.md)
+ [Descrivi un argomento utilizzando l'API](describe-topic-api.md)
# Descrivi un argomento utilizzando il Console di gestione AWS
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Nell'elenco dei cluster, scegli il nome del cluster che contiene l'argomento che desideri descrivere.
1. Nella pagina dei dettagli del cluster, scegli la scheda **Argomenti**.
1. Nell'elenco degli argomenti, scegli il nome dell'argomento che desideri visualizzare.
1. La pagina dei dettagli dell'argomento mostra informazioni sull'argomento, tra cui lo stato, il numero di partizioni, il fattore di replica e le impostazioni di configurazione.
# Descrivere un argomento utilizzando il AWS CLI
Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) del cluster e *TopicName* con il nome dell'argomento che desideri descrivere.
```
aws kafka describe-topic --cluster-arn ClusterArn --topic-name TopicName
```
L'output di questo comando è simile all'esempio JSON seguente.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"partitionCount": 3,
"replicationFactor": 3,
"configs": "Y29tcHJlc3Npb24udHlwZT1wcm9kdWNlcgpyZXRlbnRpb24ubXM9NjA0ODAwMDAw",
"status": "ACTIVE"
}
```
## Comprendere lo stato dell'argomento
Il `status` campo indica lo stato attuale dell'argomento. La tabella seguente descrive i possibili valori di stato.
**Valori di stato dell'argomento**
| Status | Description |
| --- | --- |
| CREAZIONE IN CORSO | L'argomento è in fase di creazione. |
| ACTIVE | L'argomento è attivo e pronto per l'uso. |
| AGGIORNAMENTO IN CORSO | La configurazione dell'argomento è in fase di aggiornamento. |
| ELIMINAZIONE IN CORSO | L'argomento viene eliminato. |
## Comprendere le configurazioni degli argomenti
Il `configs` campo contiene le proprietà di configurazione Kafka dell'argomento, codificate in formato Base64. Per visualizzare la configurazione in un formato leggibile, è necessario decodificare la stringa Base64.
L'esempio seguente mostra come decodificare la configurazione utilizzando il `base64` comando su Linux o macOS.
```
echo "Y29tcHJlc3Npb24udHlwZT1wcm9kdWNlcgpyZXRlbnRpb24ubXM9NjA0ODAwMDAw" | base64 --decode
```
L'output decodificato mostra le proprietà di configurazione dell'argomento in formato chiave-valore.
```
compression.type=producer
retention.ms=604800000
```
Per ulteriori informazioni sulle proprietà di configurazione a livello di argomento, vedere. [Configurazione Amazon MSK a livello di argomento](msk-configuration-properties.md#msk-topic-confinguration)
# Descrivi un argomento utilizzando l'API
Per descrivere un argomento utilizzando l'API, vedi [DescribeTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#DescribeTopic).
# Visualizzare le informazioni sulla partizione per un argomento
È possibile recuperare informazioni dettagliate sulle partizioni di un argomento specifico nel cluster MSK Provisioned. Queste informazioni includono il numero di partizione, il broker leader, i broker di replica e le repliche in-sync (ISR). Ciò è utile per monitorare la distribuzione delle partizioni, identificare partizioni sottoreplicate o risolvere problemi di replica.
**Nota**
Questa risposta API riflette i dati che si aggiornano all'incirca ogni minuto. Per conoscere lo stato più recente dell'argomento dopo aver apportato le modifiche, attendi circa un minuto prima di eseguire l'interrogazione.
**Topics**
+ [Visualizzate le informazioni sulla partizione utilizzando il Console di gestione AWS](describe-topic-partitions-console.md)
+ [Visualizza le informazioni sulla partizione utilizzando il AWS CLI](describe-topic-partitions-cli.md)
+ [Visualizza le informazioni sulle partizioni utilizzando l'API](describe-topic-partitions-api.md)
# Visualizzate le informazioni sulla partizione utilizzando il Console di gestione AWS
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Nell'elenco dei cluster, scegli il nome del cluster che contiene l'argomento.
1. Nella pagina dei dettagli del cluster, scegli la scheda **Argomenti**.
1. Nell'elenco degli argomenti, scegli il nome dell'argomento per il quale desideri visualizzare le informazioni sulla partizione.
1. Nella pagina dei dettagli dell'argomento, vengono visualizzate le informazioni sulla partizione, che mostrano il numero di partizione, il leader broker, le repliche e le repliche sincronizzate per ogni partizione.
# Visualizza le informazioni sulla partizione utilizzando il AWS CLI
Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) del cluster e *TopicName* con il nome dell'argomento.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName
```
L'output di questo comando è simile all'esempio JSON seguente.
```
{
"partitions": [
{
"partition": 0,
"leader": 1,
"replicas": [1, 2, 3],
"isr": [1, 2, 3]
},
{
"partition": 1,
"leader": 2,
"replicas": [2, 3, 1],
"isr": [2, 3, 1]
},
{
"partition": 2,
"leader": 3,
"replicas": [3, 1, 2],
"isr": [3, 1]
}
]
}
```
## Comprensione delle informazioni sulla partizione
La risposta include le seguenti informazioni per ogni partizione:
+ **partizione**: il numero della partizione. Le partizioni sono numerate a partire da 0.
+ **leader**: l'ID del broker del leader per questa partizione. Il leader gestisce tutte le richieste di lettura e scrittura per la partizione.
+ **repliche**: l'elenco dei broker IDs che dispongono di repliche di questa partizione. Ciò include sia le repliche in-sync che quelle in-sync. out-of-sync
+ **isr**: l'elenco dei broker IDs che sono repliche sincronizzate. Queste repliche sono pienamente in contatto con il leader e possono subentrare come leader, se necessario.
Nell'esempio precedente, la partizione 2 ha una out-of-sync replica. L'`replicas`elenco include il broker 2, ma l'`isr`elenco no. Ciò indica che il broker 2 non è completamente al passo con il leader di questa partizione.
## Impaginazione dei risultati
Se l'argomento ha molte partizioni, puoi utilizzare l'impaginazione per recuperare i risultati in batch più piccoli. Utilizzate il `--max-results` parametro per specificare il numero massimo di partizioni da restituire e utilizzate il `--next-token` parametro per recuperare la pagina successiva di risultati.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName --max-results 10
```
Se sono disponibili più risultati, la risposta include un `nextToken` valore. Usa questo token per recuperare la pagina successiva di risultati.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName --max-results 10 --next-token NextToken
```
## Casi di utilizzo comune
La visualizzazione delle informazioni sulle partizioni è utile per diversi scenari:
+ **Identificazione delle partizioni poco replicate**: confronta `isr` gli elenchi `replicas` and per identificare le partizioni in cui alcune repliche non sono sincronizzate. Ciò può indicare problemi di prestazioni o problemi di broker.
+ **Monitoraggio della distribuzione delle partizioni**: verifica che i leader delle partizioni siano distribuiti uniformemente tra i broker per garantire un carico bilanciato.
+ **Risoluzione dei problemi di replica: identifica quali broker hanno problemi** a tenere il passo con la replica esaminando l'elenco ISR.
+ **Pianificazione del ribilanciamento delle partizioni**: utilizzate queste informazioni per comprendere il layout corrente delle partizioni prima di eseguire le operazioni di ribilanciamento.
# Visualizza le informazioni sulle partizioni utilizzando l'API
Per visualizzare le informazioni sulla partizione utilizzando l'API, vedere. [DescribeTopicPartitions](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname-partitions.html#DescribeTopicPartitions)
# Crea argomenti in un cluster Amazon MSK
È possibile creare argomenti nel cluster MSK Provisioned utilizzando direttamente questa API senza configurare alcun Kafka personalizzato. AdminClient Quando si crea un argomento, si specificano il nome dell'argomento, il numero di partizioni, il fattore di replica e, facoltativamente, le configurazioni dell'argomento.
**Topics**
+ [Crea argomenti utilizzando il Console di gestione AWS](create-topic-console.md)
+ [Crea un argomento utilizzando il AWS CLI](create-topic-cli.md)
+ [Crea un argomento utilizzando l'API](create-topic-api.md)
# Crea argomenti utilizzando il Console di gestione AWS
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Nell'elenco dei cluster, scegli il nome del cluster in cui desideri creare gli argomenti.
1. Nella pagina dei dettagli del cluster, scegli la scheda **Argomenti**.
1. Scegli **Create topic** (Crea argomento).
1. Inserisci il nome dell'argomento, il numero di partizioni e il fattore di replica. Facoltativamente, aggiungi configurazioni. Puoi creare più argomenti contemporaneamente.
1. Scegli **Create topic** (Crea argomento).
# Crea un argomento utilizzando il AWS CLI
Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) del cluster. Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per ulteriori informazioni, consulta [Elenca i cluster Amazon MSK](msk-list-clusters.md).
```
aws kafka create-topic --cluster-arn ClusterArn --topic-name MyTopic --partition-count 3 --replication-factor 3
```
L'output di questo comando è simile all'esempio JSON seguente.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "CREATING"
}
```
# Crea un argomento utilizzando l'API
Per creare un argomento utilizzando l'API, consulta [CreateTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics.html#CreateTopic).
# Aggiornare un argomento in un cluster Amazon MSK
Aggiornate il conteggio delle partizioni o le configurazioni a livello di argomento per un argomento esistente. Questa operazione modifica l'argomento senza richiedere attività ricreative.
**Nota**
È possibile aggiornare il conteggio delle partizioni o le configurazioni degli argomenti in una singola chiamata API, ma non entrambi contemporaneamente. Per aggiornare entrambi, effettua chiamate API separate.
**Topics**
+ [Aggiorna un argomento utilizzando il Console di gestione AWS](update-topic-console.md)
+ [Aggiornare un argomento utilizzando il AWS CLI](update-topic-cli.md)
+ [Aggiorna un argomento utilizzando l'API](update-topic-api.md)
# Aggiorna un argomento utilizzando il Console di gestione AWS
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Nell'elenco dei cluster, scegli il nome del cluster contenente l'argomento che desideri aggiornare.
1. Nella pagina dei dettagli del cluster, scegli la scheda **Argomenti**.
1. **Seleziona l'argomento che desideri aggiornare, quindi scegli **Modifica impostazioni delle partizioni** o **Modifica configurazioni** da Azioni.**
1. Aggiorna il numero di partizioni o le configurazioni in base alle esigenze.
1. Scegli **Save** (Salva).
# Aggiornare un argomento utilizzando il AWS CLI
Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) del cluster e *TopicName* con il nome dell'argomento che desideri aggiornare.
```
aws kafka update-topic --cluster-arn ClusterArn --topic-name TopicName --partition-count 6
```
L'output di questo comando è simile all'esempio JSON seguente.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "UPDATING"
}
```
# Aggiorna un argomento utilizzando l'API
Per aggiornare un argomento utilizzando l'API, consulta [UpdateTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#UpdateTopic).
# Eliminare un argomento in un cluster Amazon MSK
L'eliminazione di un argomento rimuove definitivamente tutti i dati, i metadati e le informazioni sulla partizione. Questa operazione non può essere annullata.
**Topics**
+ [Eliminare un argomento utilizzando il Console di gestione AWS](delete-topic-console.md)
+ [Eliminare un argomento utilizzando il AWS CLI](delete-topic-cli.md)
+ [Elimina un argomento utilizzando l'API](delete-topic-api.md)
# Eliminare un argomento utilizzando il Console di gestione AWS
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Nell'elenco dei cluster, scegli il nome del cluster contenente l'argomento che desideri eliminare.
1. Nella pagina dei dettagli del cluster, scegli la scheda **Argomenti**.
1. Seleziona gli argomenti che desideri eliminare, quindi scegli **Elimina** da **Azioni**.
1. Conferma l'eliminazione, quindi scegli **Elimina**.
# Eliminare un argomento utilizzando il AWS CLI
Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) del cluster e *TopicName* con il nome dell'argomento che desideri eliminare.
```
aws kafka delete-topic --cluster-arn ClusterArn --topic-name TopicName
```
L'output di questo comando è simile all'esempio JSON seguente.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "DELETING"
}
```
# Elimina un argomento utilizzando l'API
Per eliminare un argomento utilizzando l'API, consulta [DeleteTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#DeleteTopic).
# Risorse Amazon MSK
Il termine *risorse* ha due significati in Amazon MSK, a seconda del contesto. Nel contesto di APIs una risorsa c'è una struttura sulla quale è possibile richiamare un'operazione. Per un elenco di queste risorse e delle operazioni che è possibile richiamare su di esse, consulta la sezione [Resources](https://docs.aws.amazon.com/msk/1.0/apireference/resources.html) nella documentazione di riferimento dell'API di Amazon MSK. Nel contesto di [Controllo degli accessi IAM](iam-access-control.md), una risorsa è un'entità a cui è possibile consentire o rifiutare l'accesso, come definito nella sezione [Risorse relative alla politica di autorizzazione](kafka-actions.md#msk-iam-resources).
# Versioni di Apache Kafka
Quando si crea un cluster Amazon MSK, specifica quale versione di Apache Kafka desideri utilizzare. Puoi inoltre aggiornare la versione di Apache Kafka di un cluster esistente. Gli argomenti del capitolo aiutano a comprendere le tempistiche per il supporto delle versioni di Kafka e i suggerimenti per le migliori pratiche.
**Topics**
+ [Versioni di Apache Kafka supportate](supported-kafka-versions.md)
+ [Supporto per la versione di Amazon MSK](version-support.md)
# Versioni di Apache Kafka supportate
Streaming gestito da Amazon per Apache Kafka (Amazon MSK) supporta le seguenti versioni di Apache Kafka e Amazon MSK. La community di Apache Kafka fornisce circa 12 mesi di supporto per una versione successiva alla data di rilascio. Per ulteriori dettagli, consulta la politica [EOL (end of life) di Apache Kafka](https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan#TimeBasedReleasePlan-WhatIsOurEOLPolicy?).
La tabella seguente elenca le versioni di Apache Kafka supportate da Amazon MSK.
| Versione Apache Kafka | Data di rilascio di MSK | Data di fine supporto |
| --- | --- | --- |
| [1.1.1](https://archive.apache.org/dist/kafka/1.1.1/RELEASE_NOTES.html) | -- | 2024-06-05 |
| [2.1.0](https://archive.apache.org/dist/kafka/2.1.0/RELEASE_NOTES.html) | -- | 2024-06-05 |
| [2.2.1](https://archive.apache.org/dist/kafka/2.2.1/RELEASE_NOTES.html) | 31-07-2019 | 2024-06-08 |
| [2.3.1](https://archive.apache.org/dist/kafka/2.3.1/RELEASE_NOTES.html) | 19-12-2019 | 2024-06-08 |
| [24.1](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) | 2020-04-02 | 2024-06-08 |
| [2,41.1](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) | 2020-09-09 | 2024-06-08 |
| [2.5.1](https://archive.apache.org/dist/kafka/2.5.1/RELEASE_NOTES.html) | 2020-09-30 | 2024-06-08 |
| [2,6,0](https://archive.apache.org/dist/kafka/2.6.0/RELEASE_NOTES.html) | 2020-10-21 | 2024-09-11 |
| [2,6,1](https://archive.apache.org/dist/kafka/2.6.1/RELEASE_NOTES.html) | 2021-01-19 | 2024-09-11 |
| [2,6,2](https://archive.apache.org/dist/kafka/2.6.2/RELEASE_NOTES.html) | 2021-04-29 | 2024-09-11 |
| [2,6,3](https://archive.apache.org/dist/kafka/2.6.3/RELEASE_NOTES.html) | 2021-12-21 | 2024-09-11 |
| [2,7,0](https://archive.apache.org/dist/kafka/2.7.0/RELEASE_NOTES.html) | 2020-12-29 | 2024-09-11 |
| [2,7,1](https://archive.apache.org/dist/kafka/2.7.1/RELEASE_NOTES.html) | 2021-05-25 | 2024-09-11 |
| [2,7,2](https://archive.apache.org/dist/kafka/2.7.2/RELEASE_NOTES.html) | 2021-12-21 | 2024-09-11 |
| [2,80](https://archive.apache.org/dist/kafka/2.8.0/RELEASE_NOTES.html) | 2021-05-19 | 2024-09-11 |
| [28,1](https://archive.apache.org/dist/kafka/2.8.1/RELEASE_NOTES.html) | 2022-10-28 | 2024-09-11 |
| [2.8.2 livelli](https://archive.apache.org/dist/kafka/2.8.2/RELEASE_NOTES.html) | 2022-10-28 | 2025-01-14 |
| [3.1.1](https://archive.apache.org/dist/kafka/3.1.1/RELEASE_NOTES.html) | 2022-06-22 | 2024-09-11 |
| [32,0](https://archive.apache.org/dist/kafka/3.2.0/RELEASE_NOTES.html) | 2022-06-22 | 2024-09-11 |
| [3,31](https://archive.apache.org/dist/kafka/3.3.1/RELEASE_NOTES.html) | 2022-10-26 | 2024-09-11 |
| [3,32](https://archive.apache.org/dist/kafka/3.3.2/RELEASE_NOTES.html) | -02 | 2024-09-11 |
| [3,40](https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html) | 2023-05-04 | 2025-08-04 |
| [3,5,1](https://archive.apache.org/dist/kafka/3.5.1/RELEASE_NOTES.html) | 2023-09-26 | 2025-10-23 |
| [3,6,0](https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html) | 2023-11-16 | 2026-06-01 |
| [3.7. x](https://archive.apache.org/dist/kafka/3.7.0/RELEASE_NOTES.html) | 2024-05-29 | -- |
| [3.8.x](https://downloads.apache.org/kafka/3.8.0/RELEASE_NOTES.html) | 2025-02-20 | -- |
| [3.9.x (consigliato)](https://downloads.apache.org/kafka/3.9.0/RELEASE_NOTES.html) | 2025-04-21 | -- |
| [4,0x](https://downloads.apache.org/kafka/4.0.0/RELEASE_NOTES.html) | 2025-05-16 | -- |
| [4.1.x](https://downloads.apache.org/kafka/4.1.0/RELEASE_NOTES.html) | 2025-10-15 | -- |
Per ulteriori informazioni sulla politica di supporto delle versioni di Amazon MSK, consulta[Politica di supporto delle versioni di Amazon MSK](version-support.md#version-support-policy).
## Amazon MSK versione 4.1.x
Amazon Managed Streaming for Apache Kafka (Amazon MSK) ora supporta Apache Kafka versione 4.1, che introduce Queues come funzionalità di anteprima, un nuovo Streams Rebalance Protocol in accesso anticipato e Eligible Leader Replicas (ELR). Oltre a queste funzionalità, la versione 4.1 di Apache Kafka include varie correzioni di bug e miglioramenti.
Uno dei punti salienti di Kafka 4.1 è l'introduzione di Queues come funzionalità di anteprima. È possibile utilizzare più utenti per elaborare i messaggi dalle partizioni dello stesso argomento, migliorando il parallelismo e la velocità effettiva per i carichi di lavoro che richiedono il recapito dei messaggi. point-to-point Il nuovo Streams Rebalance Protocol si basa sul protocollo di ribilanciamento dei consumatori di Kafka 4.0, estendendo le funzionalità di coordinamento dei broker a Kafka Streams per l'assegnazione delle attività e il ribilanciamento ottimizzati. Inoltre, ELR è ora abilitato di default per rafforzare la disponibilità.
Per maggiori dettagli e un elenco completo dei miglioramenti e delle correzioni di bug, consulta le note di [rilascio di Apache Kafka](https://downloads.apache.org/kafka/4.1.0/RELEASE_NOTES.html) per la versione 4.1.
Per iniziare a utilizzare Apache Kafka 4.1 su Amazon MSK, scegli la versione 4.1.x quando crei un nuovo cluster tramite, o. Console di gestione AWS AWS CLI AWS SDKs Puoi anche aggiornare i cluster con provisioning MSK esistenti con un aggiornamento continuo sul posto. Amazon MSK orchestra i riavvii del broker per mantenere la disponibilità e proteggere i dati durante l'aggiornamento. Il supporto per la versione 4.1 di Kafka è disponibile ovunque sia offerto Regioni AWS Amazon MSK.
## Amazon MSK versione 4.0.x
Amazon Managed Streaming for Apache Kafka (Amazon MSK) ora supporta Apache Kafka versione 4.0. Questa versione apporta i più recenti progressi nella gestione e nelle prestazioni dei cluster a MSK Provisioned. Kafka 4.0 introduce un nuovo protocollo di ribilanciamento per i consumatori, ora disponibile a tutti, che aiuta a garantire ribilanciamenti di gruppo più fluidi e rapidi. Inoltre, Kafka 4.0 richiede broker e strumenti per utilizzare Java 17, che offre sicurezza e prestazioni migliorate, include varie correzioni di bug e miglioramenti e rende obsoleta la gestione dei metadati tramite Apache. ZooKeeper
[Per maggiori dettagli e un elenco completo di miglioramenti e correzioni di bug, consulta le note di rilascio di Apache Kafka per la versione 4.0.](https://downloads.apache.org/kafka/4.0.0/RELEASE_NOTES.html)
## Amazon MSK versione 3.9.x (consigliata)
Amazon Managed Streaming for Apache Kafka (Amazon MSK) ora supporta Apache Kafka versione 3.9. Questa versione migliora la funzionalità di storage su più livelli consentendoti di conservare i dati su più livelli quando disabiliti lo storage su più livelli a livello di argomento. Le applicazioni consumer possono leggere i dati storici dal Remote Log Start Offset (Rx) mantenendo al contempo gli offset di log continui sullo storage locale e remoto.
La versione 3.9 è l'ultima versione a supportare entrambi i sistemi di gestione dei ZooKeeper metadati KRaft . Amazon MSK fornirà il supporto esteso per la versione 3.9 per un minimo di due anni dalla data di rilascio.
Per ulteriori dettagli e un elenco completo di miglioramenti e correzioni di bug, consulta le note di rilascio di [Apache Kafka](https://downloads.apache.org/kafka/3.9.0/RELEASE_NOTES.html) per la versione 3.9.x.
## Amazon MSK versione 3.8.x
Amazon Managed Streaming for Apache Kafka (Amazon MSK) ora supporta Apache Kafka versione 3.8. Ora puoi creare nuovi cluster utilizzando la versione 3.8 con KRAFT o la ZooKeeper modalità per la gestione dei metadati o aggiornare i cluster basati esistenti per utilizzare la versione 3.8. ZooKeeper La versione 3.8 di Apache Kafka include diverse correzioni di bug e nuove funzionalità che migliorano le prestazioni. Le nuove funzionalità chiave includono il supporto per la configurazione del livello di compressione. Ciò consente di ottimizzare ulteriormente le prestazioni quando si utilizzano tipi di compressione come lz4, zstd e gzip, modificando il livello di compressione predefinito.
Per maggiori dettagli e un elenco completo dei miglioramenti e delle correzioni di bug, consulta le note di rilascio di [Apache Kafka per la versione 3.8.x](https://downloads.apache.org/kafka/3.8.0/RELEASE_NOTES.html).
## Apache Kafka versione 3.7.x (con storage su più livelli pronto per la produzione)
La versione 3.7.x di Apache Kafka su MSK include il supporto per Apache Kafka versione 3.7.0. È possibile creare cluster o aggiornare i cluster esistenti per utilizzare la nuova versione 3.7.x. Con questa modifica nella denominazione delle versioni, non è più necessario adottare versioni di patch fix più recenti come la 3.7.1 quando vengono rilasciate dalla community di Apache Kafka. Amazon MSK aggiornerà automaticamente la versione 3.7.x per supportare le future versioni delle patch non appena saranno disponibili. In questo modo puoi beneficiare della sicurezza e delle correzioni di bug disponibili tramite le versioni di patch fix senza attivare un aggiornamento della versione. Queste versioni di patch fix rilasciate da Apache Kafka non compromettono la compatibilità delle versioni e puoi trarre vantaggio dalle nuove versioni di patch fix senza preoccuparti degli errori di lettura o scrittura delle applicazioni client. Assicurati che gli strumenti di automazione dell'infrastruttura, ad esempio CloudFormation, siano aggiornati per tenere conto di questa modifica nella denominazione delle versioni.
Amazon MSK ora supporta la KRaft modalità (Apache Kafka Raft) nella versione 3.7.x di Apache Kafka. Su Amazon MSK, come per i ZooKeeper nodi, KRaft i controller sono inclusi senza costi aggiuntivi e non richiedono alcuna configurazione o gestione aggiuntiva da parte dell'utente. Ora puoi creare cluster in entrambe le KRaft modalità o ZooKeeper modalità su Apache Kafka versione 3.7.x. In modalità Kraft, puoi aggiungere fino a 60 broker per ospitare più partizioni per cluster, senza richiedere un aumento del limite, rispetto alla quota di 30 broker sui cluster basati su ZooKeeper. [KRaft modalità](metadata-management.md#kraft-intro)Per ulteriori informazioni su MSK, consulta. KRaft
La versione 3.7.x di Apache Kafka include anche diverse correzioni di bug e nuove funzionalità che migliorano le prestazioni. I miglioramenti principali includono le ottimizzazioni di Leader Discovery per i client e le opzioni di ottimizzazione del log Segment Flush. [Per un elenco completo dei miglioramenti e delle correzioni di bug, consultate le note di rilascio di Apache Kafka per la versione 3.7.0.](https://archive.apache.org/dist/kafka/3.7.0/RELEASE_NOTES.html)
## Apache Kafka versione 3.6.0 (con archiviazione a più livelli pronta per la produzione)
Per informazioni su Apache Kafka versione 3.6.0 (con archiviazione a più livelli pronta per la produzione), consulta le relative [note di rilascio](https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html) sul sito dei download di Apache Kafka.
Per motivi di stabilità, Amazon MSK continuerà a utilizzare e gestire ZooKeeper per la gestione del quorum in questa versione.
## Amazon MSK versione 3.5.1
Amazon Managed Streaming for Apache Kafka (Amazon MSK) ora supporta la versione 3.5.1 di Apache Kafka per cluster nuovi ed esistenti. Apache Kafka 3.5.1 include diverse correzioni di bug e nuove funzionalità che migliorano le prestazioni. Le caratteristiche principali includono l'introduzione di una nuova assegnazione delle partizioni compatibile con i rack per i consumatori. Amazon MSK continuerà a utilizzare e gestire Zookeeper per la gestione del quorum in questa versione. Per un elenco completo dei miglioramenti e delle correzioni di bug, consulta le note di rilascio di Apache Kafka per la versione 3.5.1.
Per informazioni su Apache Kafka versione 3.5.1, consulta le relative [note di rilascio](https://archive.apache.org/dist/kafka/3.5.1/RELEASE_NOTES.html) sul sito dei download di Apache Kafka.
## Amazon MSK versione 3.4.0
Amazon Managed Streaming for Apache Kafka (Amazon MSK) ora supporta Apache Kafka versione 3.4.0 per cluster nuovi ed esistenti. Apache Kafka 3.4.0 include diverse correzioni di bug e nuove funzionalità che migliorano le prestazioni. Le funzionalità principali includono una correzione per migliorare la stabilità da recuperare dalla replica più vicina. Amazon MSK continuerà a utilizzare e gestire Zookeeper per la gestione del quorum in questa versione. Per un elenco completo dei miglioramenti e delle correzioni di bug, consulta le note di rilascio di Apache Kafka per la versione 3.4.0.
Per informazioni su Apache Kafka versione 3.4.0, consulta le relative [note di rilascio](https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html) sul sito dei download di Apache Kafka.
## Amazon MSK versione 3.3.2
Amazon Managed Streaming for Apache Kafka (Amazon MSK) ora supporta la versione 3.3.2 di Apache Kafka per cluster nuovi ed esistenti. Apache Kafka 3.3.2 include diverse correzioni di bug e nuove funzionalità che migliorano le prestazioni. Le funzionalità principali includono una correzione per migliorare la stabilità da recuperare dalla replica più vicina. Amazon MSK continuerà a utilizzare e gestire Zookeeper per la gestione del quorum in questa versione. Per un elenco completo dei miglioramenti e delle correzioni di bug, consulta le note di rilascio di Apache Kafka per la versione 3.3.2.
Per informazioni su Apache Kafka versione 3.3.2, consulta le relative [note di rilascio](https://archive.apache.org/dist/kafka/3.3.2/RELEASE_NOTES.html) sul sito dei download di Apache Kafka.
## Amazon MSK versione 3.3.1
Amazon Managed Streaming for Apache Kafka (Amazon MSK) ora supporta la versione 3.3.1 di Apache Kafka per cluster nuovi ed esistenti. Apache Kafka 3.3.1 include diverse correzioni di bug e nuove funzionalità che migliorano le prestazioni. Alcune delle funzionalità principali includono miglioramenti alle metriche e al partizionatore. Per motivi di stabilità, Amazon MSK continuerà a utilizzare e gestire ZooKeeper per la gestione del quorum in questa versione. Per un elenco completo dei miglioramenti e delle correzioni di bug, consultate le note di rilascio di Apache Kafka per la versione 3.3.1.
Per informazioni su Apache Kafka versione 3.3.1, consulta le relative [note di rilascio](https://archive.apache.org/dist/kafka/3.3.1/RELEASE_NOTES.html) sul sito dei download di Apache Kafka.
## Amazon MSK versione 3.1.1
Amazon Managed Streaming for Apache Kafka (Amazon MSK) ora supporta le versioni 3.1.1 e 3.2.0 di Apache Kafka per cluster nuovi ed esistenti. Apache Kafka 3.1.1 e Apache Kafka 3.2.0 includono diverse correzioni di bug e nuove funzionalità che migliorano le prestazioni. Alcune delle funzionalità principali includono miglioramenti alle metriche e l'uso dell'argomento. IDs MSK continuerà a utilizzare e gestire Zookeeper per la gestione del quorum in questa versione per motivi di stabilità. Per un elenco completo dei miglioramenti e delle correzioni di bug, consultate le note di rilascio di Apache Kafka per 3.1.1 e 3.2.0.
[Per informazioni sulle versioni 3.1.1 e 3.2.0 di Apache Kafka, consultate le relative note di rilascio 3.2.0 e le note di [rilascio](https://archive.apache.org/dist/kafka/3.2.0/RELEASE_NOTES.html) 3.1.1 sul sito di download di Apache Kafka.](https://archive.apache.org/dist/kafka/3.1.1/RELEASE_NOTES.html)
## Archiviazione a più livelli Amazon MSK versione 2.8.2.tiered
Questa versione è una versione solo per Amazon MSK di Apache Kafka versione 2.8.2 ed è compatibile con i client open source Apache Kafka.
[La versione 2.8.2.tiered contiene funzionalità di storage su più livelli compatibili con quelle introdotte in KIP-405 per Apache Kafka. APIs ](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage) Per ulteriori informazioni sulla funzionalità di archiviazione a più livelli di Amazon MSK, consulta la sezione [Storage su più livelli per broker Standard](msk-tiered-storage.md).
## Apache Kafka versione 2.5.1
La versione 2.5.1 di Apache Kafka include diverse correzioni di bug e nuove funzionalità, tra cui la crittografia in transito per Apache e i client di amministrazione. ZooKeeper Amazon MSK fornisce ZooKeeper endpoint TLS, che possono essere interrogati durante l'operazione. [DescribeCluster ](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)
L'output dell'[ DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)operazione include il `ZookeeperConnectStringTls` nodo, che elenca gli endpoint TLS zookeeper.
L'esempio seguente mostra il nodo `ZookeeperConnectStringTls` della risposta per l'operazione `DescribeCluster`:
```
"ZookeeperConnectStringTls": "z-3.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182,z-2.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182,z-1.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182"
```
Per informazioni sull'utilizzo della crittografia TLS con ZooKeeper, consulta la sezione [Utilizzo della sicurezza TLS con Apache ZooKeeper](zookeeper-security-tls.md).
Per ulteriori informazioni su Apache Kafka versione 2.5.1, consulta le relative [note di rilascio](https://archive.apache.org/dist/kafka/2.5.1/RELEASE_NOTES.html) sul sito dei download di Apache Kafka.
## Versione di correzione dei bug Amazon MSK 2.4.1.1
Questa versione è una versione di correzione dei bug di Apache Kafka 2.4.1 disponibile solo per Amazon MSK. Questa versione di correzione contiene una correzione per [KAFKA-9752](https://issues.apache.org/jira/browse/KAFKA-9752), un problema raro che causa il continuo ribilanciamento dei gruppi di consumatori e la permanenza nello stato `PreparingRebalance`. Questo problema riguarda i cluster che eseguono Apache Kafka versioni 2.3.1 e 2.4.1. Questa versione contiene una correzione prodotta dalla comunità disponibile nella versione 2.5.0 di Apache Kafka.
**Nota**
I cluster Amazon MSK che eseguono la versione 2.4.1.1 sono compatibili con qualsiasi client Apache Kafka compatibile con la versione 2.4.1 di Apache Kafka.
Se preferisci usare Apache Kafka 2.4.1, ti consigliamo di utilizzare la versione 2.4.1.1 di correzione dei bug MSK per i nuovi cluster Amazon MSK. Per incorporare questa correzione, puoi aggiornare i cluster esistenti che eseguono Apache Kafka versione 2.4.1 a questa versione. Per informazioni sull'aggiornamento di un cluster esistente, consulta la sezione [Aggiorna la versione di Apache Kafka](version-upgrades.md).
Per risolvere questo problema senza aggiornare il cluster alla versione 2.4.1.1, consulta la sezione [Gruppo di consumatori bloccato nello stato `PreparingRebalance`](troubleshooting.md#consumer-group-rebalance) della guida [Risolvi i problemi del tuo cluster Amazon MSK](troubleshooting.md).
## Apache Kafka versione 2.4.1 (usa invece 2.4.1.1)
**Nota**
Non è più possibile creare un cluster MSK con la versione 2.4.1 di Apache Kafka. In alternativa, è possibile utilizzare [Versione di correzione dei bug Amazon MSK 2.4.1.1](#2.4.1.1) con client compatibili con la versione 2.4.1 di Apache Kafka. Se disponi già di un cluster MSK con Apache Kafka versione 2.4.1, ti consigliamo di aggiornarlo per utilizzare invece la versione 2.4.1.1 di Apache Kafka.
KIP-392 è una delle principali proposte di miglioramento di Kafka incluse nella versione 2.4.1 di Apache Kafka. Questo miglioramento consente ai consumatori di recuperare dati dalla replica più vicina. Per utilizzare questa caratteristica, imposta `client.rack` nelle proprietà consumatore sull'ID della zona di disponibilità del consumatore. Un esempio di ID di zona di disponibilità è `use1-az1`. Amazon MSK imposta `broker.rack` le zone IDs di disponibilità dei broker. Inoltre, devi impostare la proprietà di configurazione `replica.selector.class` su `org.apache.kafka.common.replica.RackAwareReplicaSelector`, che è un'implementazione di consapevolezza rack fornita da Apache Kafka.
Quando utilizzi questa versione di Apache Kafka, i parametri nel livello di monitoraggio `PER_TOPIC_PER_BROKER` vengono visualizzati solo dopo che i valori diventano diversi da zero per la prima volta. Per ulteriori informazioni, consulta [Monitoraggio del livello `PER_TOPIC_PER_BROKER`](metrics-details.md#broker-topic-metrics).
Per informazioni su come trovare la zona di disponibilità IDs, consulta [AZ IDs for Your Resource nella guida](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html) per l' AWS Resource Access Manager utente.
Per informazioni sull'impostazione delle proprietà di configurazione, consulta [Configurazione Amazon MSK Provisioned](msk-configuration.md).
Per ulteriori informazioni su KIP-392, consulta [Allow Consumers to Fetch from Closest Replica](https://cwiki.apache.org/confluence/display/KAFKA/KIP-392:+Allow+consumers+to+fetch+from+closest+replica) nelle pagine di Confluence.
Per ulteriori informazioni su Apache Kafka versione 2.4.1, consulta le relative [note di rilascio](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) sul sito dei download di Apache Kafka.
# Supporto per la versione di Amazon MSK
Questo argomento descrive [Politica di supporto delle versioni di Amazon MSK](#version-support-policy) e la procedura per[Aggiorna la versione di Apache Kafka](version-upgrades.md). Se stai aggiornando la tua versione di Kafka, segui le migliori pratiche descritte in. [Best practice per gli aggiornamenti delle versioni](version-upgrades-best-practices.md)
**Topics**
+ [Politica di supporto delle versioni di Amazon MSK](#version-support-policy)
+ [Aggiorna la versione di Apache Kafka](version-upgrades.md)
+ [Best practice per gli aggiornamenti delle versioni](version-upgrades-best-practices.md)
## Politica di supporto delle versioni di Amazon MSK
Questa sezione descrive la politica di supporto per le versioni di Kafka supportate da Amazon MSK.
+ Tutte le versioni di Kafka sono supportate fino al raggiungimento della data di fine del supporto. Per informazioni dettagliate sulle date di fine del supporto, consulta. [Versioni di Apache Kafka supportate](supported-kafka-versions.md) Aggiorna il tuo cluster MSK alla versione di Kafka consigliata o alla versione successiva prima della data di fine del supporto. Per dettagli sull'aggiornamento della versione di Apache Kafka, consulta. [Aggiorna la versione di Apache Kafka](version-upgrades.md) Un cluster che utilizza una versione di Kafka dopo la data di fine del supporto viene aggiornato automaticamente alla versione Kafka consigliata. Gli aggiornamenti automatici possono avvenire in qualsiasi momento dopo la data di fine del supporto. Non riceverai alcuna notifica prima dell'aggiornamento.
+ MSK eliminerà gradualmente il supporto per i cluster di nuova creazione che utilizzano versioni di Kafka con date di fine supporto pubblicate.
# Aggiorna la versione di Apache Kafka
È possibile aggiornare un cluster MSK esistente a una versione più recente di Apache Kafka. Prima di aggiornare la versione di Kafka del cluster, verificate che la versione del software lato client supporti le funzionalità della nuova versione di Kafka.
Per informazioni su come rendere un cluster altamente disponibile durante un aggiornamento, consulta. [Creazione di cluster a disponibilità elevata](bestpractices.md#ensure-high-availability)
**Aggiornare la versione di Apache Kafka utilizzando il Console di gestione AWS**
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Nella barra di navigazione, scegli la regione in cui hai creato il cluster MSK.
1. Scegli il cluster MSK che desideri aggiornare.
1. Nella scheda **Proprietà**, scegli **Aggiorna** nella sezione relativa alla versione di **Apache Kafka**.
1. Nella sezione relativa alla **versione di Apache Kafka**, procedi come segue:
1. Nell'elenco a discesa *Scegli la versione di Apache Kafka, scegli la versione* di destinazione a cui desideri eseguire l'aggiornamento. Ad esempio, scegli **3.9.x**.
1. (Facoltativo) Scegliete **Visualizza compatibilità delle versioni** per verificare la compatibilità tra la versione corrente del cluster e le versioni di aggiornamento disponibili. Quindi, seleziona **Scegli** per procedere.
**Nota**
Amazon MSK supporta gli aggiornamenti in loco alla maggior parte delle versioni di Apache Kafka. Tuttavia, quando si esegue l'aggiornamento da una versione basata su Kafka ZooKeeper a una versione basata su Kafka, è necessario creare un nuovo cluster KRaft. Quindi, copia i dati nel nuovo cluster e sposta i client nel nuovo cluster.
1. (Facoltativo) Seleziona la casella di controllo **Aggiorna la configurazione del cluster** per applicare gli aggiornamenti di configurazione compatibili con la nuova versione. Ciò abilita le funzionalità e i miglioramenti della nuova versione.
Puoi saltare questo passaggio se devi mantenere le configurazioni personalizzate esistenti.
**Nota**
Gli aggiornamenti lato server non aggiornano automaticamente le applicazioni client.
Per mantenere la stabilità del cluster, i downgrade di versione non sono supportati.
1. Scegli **Aggiorna** per avviare il processo.
**Aggiorna la versione di Apache Kafka usando il AWS CLI**
1. Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) che hai ottenuto quando hai creato il cluster. Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per ulteriori informazioni, consulta [Elenca i cluster Amazon MSK](msk-list-clusters.md).
```
aws kafka get-compatible-kafka-versions --cluster-arn ClusterArn
```
L'output di questo comando include un elenco delle versioni di Apache Kafka a cui è possibile aggiornare il cluster. Il risultato sembra l'esempio seguente.
```
{
"CompatibleKafkaVersions": [
{
"SourceVersion": "2.2.1",
"TargetVersions": [
"2.3.1",
"2.4.1",
"2.4.1.1",
"2.5.1"
]
}
]
}
```
1. Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) che hai ottenuto quando hai creato il cluster. Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per ulteriori informazioni, consulta [Elenca i cluster Amazon MSK](msk-list-clusters.md).
Sostituiscilo *Current-Cluster-Version* con la versione corrente del cluster. Perché *TargetVersion* è possibile specificare una qualsiasi delle versioni di destinazione dall'output del comando precedente.
**Importante**
Le versioni del cluster non sono interi semplici. Per trovare la versione corrente del cluster, usa l'[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)operazione o il comando [AWS CLI describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html). Una versione di esempio è `KTVPDKIKX0DER`.
```
aws kafka update-cluster-kafka-version --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-kafka-version TargetVersion
```
L'output del comando precedente è simile al JSON seguente.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"ClusterOperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef"
}
```
1. Per ottenere il risultato dell'`update-cluster-kafka-version`operazione, esegui il comando seguente, sostituendolo *ClusterOperationArn* con l'ARN ottenuto nell'output del `update-cluster-kafka-version` comando.
```
aws kafka describe-cluster-operation --cluster-operation-arn ClusterOperationArn
```
L'output di questo comando `describe-cluster-operation` è simile all'esempio JSON seguente.
```
{
"ClusterOperationInfo": {
"ClientRequestId": "62cd41d2-1206-4ebf-85a8-dbb2ba0fe259",
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"CreationTime": "2021-03-11T20:34:59.648000+00:00",
"OperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef",
"OperationState": "UPDATE_IN_PROGRESS",
"OperationSteps": [
{
"StepInfo": {
"StepStatus": "IN_PROGRESS"
},
"StepName": "INITIALIZE_UPDATE"
},
{
"StepInfo": {
"StepStatus": "PENDING"
},
"StepName": "UPDATE_APACHE_KAFKA_BINARIES"
},
{
"StepInfo": {
"StepStatus": "PENDING"
},
"StepName": "FINALIZE_UPDATE"
}
],
"OperationType": "UPDATE_CLUSTER_KAFKA_VERSION",
"SourceClusterInfo": {
"KafkaVersion": "2.4.1"
},
"TargetClusterInfo": {
"KafkaVersion": "2.6.1"
}
}
}
```
Se il valore di `OperationState` è `UPDATE_IN_PROGRESS`, attendi qualche minuto, quindi esegui nuovamente il comando `describe-cluster-operation`. Al termine dell'operazione, il valore di `OperationState` diventa `UPDATE_COMPLETE`. Poiché il tempo necessario ad Amazon MSK per completare l'operazione varia, potrebbe essere necessario eseguire ripetutamente il controllo fino al completamento dell'operazione.
**Aggiorna la versione di Apache Kafka utilizzando l'API**
1. Richiama l'[GetCompatibleKafkaVersions](https://docs.aws.amazon.com//msk/1.0/apireference/compatible-kafka-versions.html#GetCompatibleKafkaVersions)operazione per ottenere un elenco delle versioni di Apache Kafka a cui è possibile aggiornare il cluster.
1. Richiama l'[UpdateClusterKafkaVersion](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-version.html#UpdateClusterKafkaVersion)operazione per aggiornare il cluster a una delle versioni compatibili di Apache Kafka.
# Best practice per gli aggiornamenti delle versioni
Per garantire la continuità del client durante l'aggiornamento progressivo eseguito come parte del processo di aggiornamento della versione di Kafka, esamina la configurazione dei client e gli argomenti di Apache Kafka come segue:
+ Imposta il fattore di replica dell'argomento (RF) su un valore minimo di per i cluster Two-AZ e un valore minimo di `2` per i cluster Three-AZ. `3` Un valore RF di `2` può portare a partizioni offline durante l'applicazione delle patch.
+ Imposta il numero minimo di repliche in-sync (miniSR) su un valore massimo di 1 in meno rispetto al tuo Replication Factor (RF), che è. `miniISR = (RF) - 1` Ciò garantisce che il set di repliche delle partizioni possa tollerare che una replica sia offline o poco replicata.
+ Configura i client per utilizzare più stringhe di connessione del broker. La presenza di più broker nella stringa di connessione di un client consente il failover se uno specifico broker che supporta il client I/O inizia a ricevere le patch. Per informazioni su come ottenere una stringa di connessione con più broker, consulta [Ottenere i broker bootstrap per un cluster Amazon MSK](https://docs.aws.amazon.com//msk/latest/developerguide/msk-get-bootstrap-brokers.html).
+ Ti consigliamo di aggiornare i client che si connettono alla versione consigliata o superiore per beneficiare delle funzionalità disponibili nella nuova versione. Gli upgrade dei client non sono soggetti alle date di fine del ciclo di vita (EOL) della versione Kafka del cluster MSK e non è necessario che vengano completati entro la data di fine del ciclo di vita. Apache Kafka fornisce una [politica di compatibilità dei client bidirezionale che consente ai client](https://kafka.apache.org/protocol#protocol_compatibility) più vecchi di lavorare con cluster più recenti e viceversa.
+ È probabile che i client Kafka che utilizzano le versioni 3.x.x abbiano le seguenti impostazioni predefinite: e. `acks=all` `enable.idempotence=true` `acks=all`è diverso dall'impostazione predefinita precedente di `acks=1` e offre una maggiore durabilità assicurando che tutte le repliche sincronizzate riconoscano la richiesta di produzione. Analogamente, l'impostazione predefinita per `enable.idempotence` era precedente. `false` La modifica all'`enable.idempotence=true`impostazione predefinita riduce la probabilità di messaggi duplicati. Queste modifiche sono considerate impostazioni di best practice e possono introdurre una piccola quantità di latenza aggiuntiva che rientra nei normali parametri di prestazione.
+ Utilizzate la versione consigliata di Kafka per creare nuovi cluster MSK. L'utilizzo della versione consigliata di Kafka consente di sfruttare le funzionalità più recenti di Kafka e MSK.
# Risolvi i problemi del tuo cluster Amazon MSK
Le seguenti informazioni consentono di semplificare la risoluzione dei problemi che si potrebbero verificare con il cluster Amazon MSK. Puoi anche pubblicare il problema in [AWS re:Post](https://repost.aws/). Per la risoluzione dei problemi di Amazon MSK Replicator, consulta. [Risolvete i problemi relativi a MSK Replicator](msk-replicator-troubleshooting.md)
**Topics**
+ [La sostituzione del volume causa la saturazione del disco a causa del sovraccarico della replica](#replication-overload-disk-saturation)
+ [Gruppo di consumatori bloccato nello stato `PreparingRebalance`](#consumer-group-rebalance)
+ [Errore nell'invio dei log del broker ad Amazon CloudWatch Logs](#cw-broker-logs-error)
+ [Nessun gruppo di sicurezza predefinito](#troubleshooting-shared-vpc)
+ [I cluster sono bloccati nello stato CREATING](#troubleshooting-cluster-stuck)
+ [Lo stato del cluster passa da CREATING a FAILED](#troubleshooting-cluster-failed)
+ [Lo stato del cluster è ACTIVE ma i produttori non possono inviare dati o i consumatori non possono ricevere dati](#troubleshooting-nodata)
+ [AWS CLI non riconosce Amazon MSK](#troubleshooting-nocli)
+ [Le partizioni vengono messe offline o le repliche non sono sincronizzate](#troubleshooting-offlinepartition-outofsyncreplicas)
+ [Lo spazio su disco è insufficiente](#troubleshooting-lowdiskspace)
+ [La memoria è insufficiente](#troubleshooting-lowmemory)
+ [Il produttore ottiene NotLeaderForPartitionException](#troubleshooting-NotLeaderForPartitionException)
+ [Partizioni sottoreplicate (URP) superiori a zero](#troubleshooting-urp)
+ [Il cluster ha argomenti chiamati \$1\$1amazon\$1msk\$1canary e \$1\$1amazon\$1msk\$1canary\$1state](#amazon_msk_canary)
+ [La replica delle partizioni ha esito negativo](#partition_replication_fails)
+ [Impossibile accedere al cluster con accesso pubblico attivato](#public-access-issues)
+ [Impossibile accedere al cluster tramite bootstrap IPv6](#dualstack-issues)
+ [Impossibile accedere al cluster dall'interno AWS: problemi di rete](#networking-trouble)
+ [Autenticazione non riuscita: troppe connessioni](#troubleshoot-too-many-connects)
+ [Autenticazione fallita: sessione troppo breve](#troubleshoot-session-too-short)
+ [MSK Serverless: la creazione del cluster ha esito negativo](#troubleshoot-serverless-create-cluster-failure)
+ [Impossibile eseguire l'aggiornamento KafkaVersionsList nella configurazione MSK](#troubleshoot-kafkaversionslist-cfn-update-failure)
## La sostituzione del volume causa la saturazione del disco a causa del sovraccarico della replica
In caso di guasto hardware non pianificato del volume, Amazon MSK può sostituire il volume con una nuova istanza. Kafka ripopola il nuovo volume replicando le partizioni di altri broker del cluster. Una volta che le partizioni sono state replicate e recuperate, sono idonee per l'iscrizione alla leadership e all'In-Sync Replica (ISR).
**Problema**
In un broker che si sta riprendendo dalla sostituzione dei volumi, alcune partizioni di dimensioni diverse potrebbero tornare online prima di altre. Ciò può essere problematico in quanto tali partizioni possono servire il traffico proveniente dallo stesso broker che sta ancora recuperando (replicando) altre partizioni. Questo traffico di replica a volte può saturare i limiti di throughput del volume sottostanti, che nel caso predefinito sono 250 MiB al secondo. Quando si verifica questa saturazione, tutte le partizioni già interessate ne risentono, con conseguente latenza all'interno del cluster per tutti i broker che condividono ISR con quelle partizioni interessate (non solo le partizioni leader dovute agli ack remoti). `acks=all` Questo problema è più comune nei cluster più grandi che hanno un numero maggiore di partizioni di dimensioni variabili.
**Raccomandazione**
+ Per migliorare la I/O postura di replica, assicuratevi che siano state adottate le [migliori impostazioni dei thread.](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html#optimize-broker-threads)
+ Per ridurre la probabilità di saturazione del volume sottostante, abilita lo storage fornito con un throughput più elevato. Un valore minimo di throughput pari a 500 MiB/s è consigliato per i casi di replica con throughput elevato, ma il valore effettivo necessario varia a seconda del throughput e del caso d'uso. [Esegui il provisioning del throughput di storage per i broker Standard in un cluster Amazon MSK](msk-provision-throughput.md).
+ Per ridurre al minimo la pressione di replica, `num.replica.fetchers` abbassare al valore predefinito di`2`.
## Gruppo di consumatori bloccato nello stato `PreparingRebalance`
Se uno o più gruppi di consumatori sono bloccati in uno stato di ribilanciamento perpetuo, la causa potrebbe essere il problema [KAFKA-9752](https://issues.apache.org/jira/browse/KAFKA-9752) di Apache Kafka, che riguarda le versioni 2.3.1 e 2.4.1 di Apache Kafka.
Per risolvere questo problema, ti consigliamo di aggiornare il cluster alla versione [Versione di correzione dei bug Amazon MSK 2.4.1.1](supported-kafka-versions.md#2.4.1.1), che contiene una correzione per questo problema. Per informazioni sull'aggiornamento di un cluster esistente alla versione 2.4.1.1 di correzione dei bug di Amazon MSK, consulta la pagina [Aggiorna la versione di Apache Kafka](version-upgrades.md).
Le soluzioni alternative per risolvere questo problema senza aggiornare il cluster alla versione di correzione del bug Amazon MSK 2.4.1.1 consistono nell'impostare i client Kafka in modo da utilizzare [Protocollo di iscrizione statico](#consumer-group-rebalance-static) oppure [Identificazione e riavvio](#consumer-group-rebalance-reboot) il nodo dei broker di coordinamento del gruppo di consumatori bloccato.
### Implementazione del protocollo di iscrizione statico
Per implementare il protocollo di iscrizione statico nei client, procedi come indicato di seguito:
1. Imposta la proprietà `group.instance.id` della configurazione dei [consumatori Kafka](https://kafka.apache.org/26/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaConsumer.html) su una stringa statica che identifica il consumatore nel gruppo.
1. Assicurati che le altre istanze della configurazione siano aggiornate in modo da utilizzare la stringa statica.
1. Implementa le modifiche ai tuoi consumatori Kafka.
L'utilizzo del protocollo di iscrizione statico è più efficace se il timeout della sessione nella configurazione client è impostato su una durata che consenta al consumatore di ripristinare il sistema senza innescare prematuramente un ribilanciamento del gruppo di consumatori. Ad esempio, se l'applicazione consumatore può tollerare 5 minuti di indisponibilità, un valore ragionevole per il timeout della sessione sarebbe 4 minuti anziché il valore predefinito di 10 secondi.
**Nota**
L'utilizzo del protocollo di iscrizione statico riduce solamente la probabilità di riscontrare questo problema. È possibile che questo problema si verifichi ancora anche quando si utilizza il protocollo di iscrizione statico.
### Riavvio del nodo dei broker di coordinamento
Per riavviare il nodo dei broker di coordinamento, procedi come segue:
1. Identifica il coordinatore del gruppo utilizzando il comando `kafka-consumer-groups.sh`.
1. Riavvia il coordinatore del gruppo di consumatori bloccato utilizzando l'azione [ RebootBroker](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-reboot-broker.html#RebootBroker)API.
## Errore nell'invio dei log del broker ad Amazon CloudWatch Logs
Quando provi a configurare il tuo cluster per inviare i log del broker ad Amazon CloudWatch Logs, potresti ottenere una delle due eccezioni.
Se viene restituita un'eccezione `InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded`, riprova utilizzando i gruppi di log che iniziano con `/aws/vendedlogs/`. Per ulteriori informazioni, consulta la pagina [Enabling Logging from Certain Amazon Web Services](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html).
Se ricevi un'`InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded`eccezione, scegli una policy Amazon CloudWatch Logs esistente nel tuo account e aggiungi il seguente codice JSON.
```
{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}
```
Se provi ad aggiungere il codice JSON sopra riportato a una policy esistente ma ricevi un errore che indica che hai raggiunto la lunghezza massima per la policy che hai scelto, prova ad aggiungere il codice JSON a un'altra delle tue politiche Amazon Logs. CloudWatch Dopo aver aggiunto il codice JSON a una policy esistente, prova ancora una volta a configurare la distribuzione dei log del broker ad Amazon Logs. CloudWatch
## Nessun gruppo di sicurezza predefinito
Se cerchi di creare un cluster e ricevi un errore che indica che non esiste un gruppo di sicurezza predefinito, è possibile che il VPC che stai utilizzando sia stato condiviso con te. Chiedi all'amministratore di concedere l'autorizzazione per descrivere i gruppi di sicurezza in questo VPC e riprova. Per un esempio di una policy che consente questa operazione, consulta [Amazon EC2: consente la gestione dei gruppi di sicurezza EC2 associati a uno specifico VPC, in modo programmatico e nella console ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html).
## I cluster sono bloccati nello stato CREATING
A volte la creazione del cluster può richiedere fino a 30 minuti. Attendi 30 minuti e controlla nuovamente lo stato del cluster.
## Lo stato del cluster passa da CREATING a FAILED
Prova a creare nuovamente il cluster.
## Lo stato del cluster è ACTIVE ma i produttori non possono inviare dati o i consumatori non possono ricevere dati
+ Se la creazione del cluster va a buon fine (lo stato del cluster è `ACTIVE`), ma non è possibile inviare o ricevere dati, assicurati che le applicazioni produttore e consumatore dispongano dell'accesso al cluster. Per ulteriori informazioni, consulta le linee guida in [Passaggio 3: creazione di un computer client](create-client-machine.md).
+ Se i produttori e i consumatori dispongono dell'accesso al cluster ma si verificano ancora problemi nella produzione e nel consumo di dati, è possibile che la causa sia riconducibile a [KAFKA-7697](https://issues.apache.org/jira/browse/KAFKA-7697), che influenza Apache Kafka versione 2.1.0 e può condurre a un deadlock in uno o più broker. Valuta la possibilità di eseguire la migrazione ad Apache Kafka 2.2.1, che non è influenzato da questo bug. Per informazioni sulla migrazione, consulta [Esegui la migrazione dei carichi di lavoro Kafka in un cluster Amazon MSK](migration.md).
## AWS CLI non riconosce Amazon MSK
Se lo hai AWS CLI installato, ma non riconosce i comandi di Amazon MSK, esegui l'upgrade AWS CLI alla versione più recente. Per istruzioni dettagliate su come aggiornare AWS CLI, consulta [Installazione di AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html). Per informazioni su come utilizzare per AWS CLI eseguire i comandi Amazon MSK, consulta[Caratteristiche e concetti chiave di Amazon MSK](operations.md).
## Le partizioni vengono messe offline o le repliche non sono sincronizzate
Questi sintomi possono essere causati da spazio su disco insufficiente. Per informazioni, consulta [Lo spazio su disco è insufficiente](#troubleshooting-lowdiskspace).
## Lo spazio su disco è insufficiente
Vedere le best practice seguenti per gestire lo spazio su disco: [Monitoraggio dello spazio su disco](bestpractices.md#bestpractices-monitor-disk-space) e [Regolazione dei parametri di conservazione dei dati](bestpractices.md#bestpractices-retention-period).
## La memoria è insufficiente
Se il parametro `MemoryUsed` diventa alto o il parametro `MemoryFree` diventa basso, ciò non significa che ci sia un problema. Apache Kafka è progettato per utilizzare e gestire in maniera ottimale la massima quantità di memoria.
## Il produttore ottiene NotLeaderForPartitionException
Questo è spesso un errore temporaneo. Impostare il parametro di configurazione `retries` del produttore su un valore più alto del valore corrente.
## Partizioni sottoreplicate (URP) superiori a zero
Il parametro `UnderReplicatedPartitions` è importante da monitorare. In un cluster MSK integro, il valore di questo parametro è 0. Se è maggiore di zero, il motivo potrebbe essere uno dei seguenti.
+ Se `UnderReplicatedPartitions` presenta un picco, è possibile che non sia stato effettuato il provisioning del cluster alle dimensioni corrette per gestire il traffico in entrata e in uscita. Per informazioni, consulta [Le migliori pratiche per i broker standard](bestpractices.md).
+ Se `UnderReplicatedPartitions` è costantemente maggiore di 0, anche durante i periodi di traffico limitato, il problema potrebbe essere dovuto al fatto che hai impostato delle restrizioni ACLs che non garantiscono l'accesso all'argomento ai broker. Per replicare le partizioni, i broker devono disporre dell'autorizzazione per gli argomenti READ e DESCRIBE. L'argomento DESCRIBE viene concesso per impostazione predefinita con l'autorizzazione READ. Per informazioni sull'impostazione ACLs, consulta [Autorizzazione e ACLs](https://kafka.apache.org/documentation/#security_authz) nella documentazione di Apache Kafka.
## Il cluster ha argomenti chiamati \$1\$1amazon\$1msk\$1canary e \$1\$1amazon\$1msk\$1canary\$1state
Potresti notare che il tuo cluster MSK ha un argomento con il nome `__amazon_msk_canary` e un altro con il nome `__amazon_msk_canary_state`. Si tratta di argomenti interni che Amazon MSK crea e utilizza per i parametri diagnostici e di salute dei cluster. Questi argomenti sono di dimensioni trascurabili e non possono essere eliminati.
## La replica delle partizioni ha esito negativo
Assicurati di non aver impostato ACLs CLUSTER\$1ACTIONS.
## Impossibile accedere al cluster con accesso pubblico attivato
Se il cluster ha attivato l'accesso pubblico, ma non riesci ancora ad accedervi da Internet, esegui i passaggi seguenti:
1. Assicurati che le regole in entrata del gruppo di sicurezza del cluster consentano il tuo indirizzo IP e la porta del cluster. Per un elenco dei numeri di porta del cluster, consulta la pagina [Informazioni sulle porte](port-info.md). Assicurati inoltre che le regole in uscita del gruppo di sicurezza consentano le comunicazioni in uscita. Per ulteriori informazioni sui gruppi di sicurezza e le rispettive regole in entrata e in uscita, consulta la pagina [Security groups for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) nella Guida per l'utente di Amazon VPC.
1. Assicurati che il tuo indirizzo IP e la porta del cluster siano consentiti nelle regole in entrata dell'ACL della rete VPC del cluster. A differenza dei gruppi di sicurezza, le reti sono prive di ACLs stato. Ciò significa che è necessario configurarne le regole in entrata e in uscita. Nelle regole in uscita, consenti tutto il traffico (intervallo di porte: 0-65535) verso il tuo indirizzo IP. Per ulteriori informazioni, consulta la pagina [Add and delete rules](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#Rules) nella Guida per l'utente di Amazon VPC.
1. Assicurati di utilizzare la stringa bootstrap-brokers ad accesso pubblico per accedere al cluster. Un cluster MSK con accesso pubblico attivato ha due diverse stringhe bootstrap-brokers, una per l'accesso pubblico e una per l'accesso dall'interno di AWS. Per ulteriori informazioni, consulta [Ottieni i broker bootstrap usando il Console di gestione AWS](get-bootstrap-console.md).
## Impossibile accedere al cluster tramite bootstrap IPv6
Se hai problemi a connetterti a un cluster utilizzando le stringhe di IPv6 bootstrap fornite, segui questi passaggi:
1. Assicurati che al tuo client siano assegnati sia gli indirizzi IPv4 che IPv6. L'applicazione client deve essere in esecuzione in una sottorete con indirizzi IPv4 e IPv6 abilitati e configurati correttamente. Verifica se il tuo VPC ha sia il blocco CIDR IPv4 che un blocco CIDR IPv6 associato, conferma che la sottorete abbia entrambi gli indirizzi IPv4 e IPv6 abilitati e verifica che l'istanza EC2 o l'ambiente client abbiano entrambi gli indirizzi assegnati. IPv4 IPv6 Per ulteriori informazioni, consulta la sezione [Indirizzamento IP per le tue sottoreti VPCs e subnet](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html) nella Amazon VPC User Guide.
1. Assicurati che le IPv6 porte pertinenti siano presenti nelle regole in entrata e in uscita del gruppo di sicurezza. Aggiungi regole in entrata per consentire il traffico sulle porte del cluster dai tuoi IPv6 indirizzi e configura le regole in uscita per consentire il traffico. IPv6 Per numeri di porta specifici, consultate [Informazioni sulle porte](https://docs.aws.amazon.com/msk/latest/developerguide/port-info.html) nella documentazione MSK. Ricordatevi di aggiornare sia le regole che IPv4 le IPv6 regole se eseguite in modalità dual-stack. Per ulteriori informazioni sui gruppi di sicurezza e le rispettive regole in entrata e in uscita, consulta la pagina [Security groups for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) nella Guida per l'utente di Amazon VPC.
1. Assicurati che la configurazione delle proprietà JVM sia corretta per il supporto. IPv6 Nell'applicazione client, imposta su `true` e `java.net.preferIPv6Addresses` `java.net.preferIPv4Stack` su. `false` Queste impostazioni possono essere configurate come proprietà di sistema o argomenti JVM. Riavvia l'applicazione dopo aver apportato queste modifiche per renderle effettive.
## Impossibile accedere al cluster dall'interno AWS: problemi di rete
Se disponi di un'applicazione Apache Kafka che non è in grado di comunicare correttamente con un cluster MSK, inizia eseguendo il seguente test di connettività.
1. Utilizzare uno dei metodi descritti in [Ottieni i broker bootstrap per un cluster Amazon MSK](msk-get-bootstrap-brokers.md) per ottenere gli indirizzi dei broker bootstrap.
1. Nel comando seguente *bootstrap-broker* sostituiscilo con uno degli indirizzi del broker che hai ottenuto nel passaggio precedente. Sostituire *port-number* con 9094 se il cluster è configurato per utilizzare l'autenticazione TLS. Se il cluster non utilizza l'autenticazione TLS, *port-number* sostituiscila con 9092. Eseguire il comando dal computer client.
```
telnet bootstrap-broker port-number
```
Dove il numero di porta è:
+ 9094 se il cluster è configurato per utilizzare l'autenticazione TLS.
+ 9092 Se il cluster non utilizza l'autenticazione TLS.
+ È necessario un numero di porta diverso se l'accesso pubblico è abilitato.
Eseguire il comando dal computer client.
1. Ripetere il comando precedente per tutti i broker bootstrap.
Se la macchina client è in grado di accedere ai broker, significa che non ci sono problemi di connettività. In questo caso, eseguire il comando seguente per verificare se il client Apache Kafka è configurato correttamente. Per ottenerlo*bootstrap-brokers*, usa uno dei metodi descritti in[Ottieni i broker bootstrap per un cluster Amazon MSK](msk-get-bootstrap-brokers.md). Sostituiscilo *topic* con il nome del tuo argomento.
```
/bin/kafka-console-producer.sh --broker-list bootstrap-brokers --producer.config client.properties --topic topic
```
Se il comando precedente va a buon fine, significa che il client è configurato correttamente. Se non è ancora possibile produrre e consumare da un'applicazione, eseguire il debug del problema a livello di applicazione.
Se il computer client non è in grado di accedere ai broker, consulta le seguenti sottosezioni per una guida basata sulla configurazione del computer client.
### Client Amazon EC2 e cluster MSK nello stesso VPC
Se il computer client si trova nello stesso VPC del cluster MSK, assicurati che il gruppo di sicurezza del cluster disponga di una regola in entrata che accetta il traffico dal gruppo di sicurezza del computer client. Per informazioni sull'impostazione di queste regole, consulta [Regole del gruppo di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules). Per un esempio di come accedere a un cluster da un'istanza Amazon EC2 che si trova nello stesso VPC del cluster, consulta la pagina [Inizia a usare Amazon MSK](getting-started.md).
### Client Amazon EC2 e cluster MSK in diversi VPCs
Se il computer client e il cluster si trovano in due ambienti diversi VPCs, verifica quanto segue:
+ I due VPCs sono peer-to-peer.
+ Lo stato della connessione peering è attivo.
+ Le tabelle dei percorsi delle due VPCs sono impostate correttamente.
Per informazioni sul peering VPC, consulta [Utilizzo di connessioni peering VPC](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html).
### Client locale
Nel caso di un client locale configurato per connettersi al cluster MSK utilizzando Site-to-Site VPN, assicurati quanto segue:
+ Lo stato della connessione VPN è `UP`. Per informazioni su come verificare lo stato della connessione VPN, consulta [How do I check the current status of my VPN tunnel?](https://aws.amazon.com/premiumsupport/knowledge-center/check-vpn-tunnel-status/).
+ La tabella di routing del VPC del cluster contiene la route per un CIDR locale la cui destinazione ha il formato `Virtual private gateway(vgw-xxxxxxxx)`.
+ Il gruppo di sicurezza del cluster MSK consente il traffico sulla porta 2181, sulla porta 9092 (se il cluster accetta traffico non crittografato) e sulla porta 9094 (se il cluster accetta traffico crittografato TLS).
Per ulteriori indicazioni Site-to-Site VPN sulla risoluzione dei problemi, consulta [Troubleshooting Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/troubleshooting.html).
### Direct Connect
Se il client utilizza Direct Connect, consulta [Risoluzione dei problemi Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Troubleshooting.html).
Se le linee guida per risoluzione dei problemi precedenti non consentono di risolvere il problema, assicurarsi che il traffico di rete non sia bloccato da un firewall. Per ulteriori operazioni di debug, utilizza strumenti come `tcpdump` e `Wireshark` per analizzare il traffico e assicurarti che raggiunga il cluster MSK.
## Autenticazione non riuscita: troppe connessioni
L'errore `Failed authentication ... Too many connects` indica che un broker si sta proteggendo perché uno o più client IAM stanno tentando di connettersi ad esso a una velocità aggressiva. Per aiutare i broker ad accettare nuove connessioni IAM a una velocità più elevata, puoi aumentare il parametro di configurazione [https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms](https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms).
Per ulteriori informazioni sui limiti di velocità per le nuove connessioni per broker, consulta la pagina [Quota di Amazon MSK](limits.md).
## Autenticazione fallita: sessione troppo breve
L'`Failed authentication ... Session too short`errore si verifica quando il client tenta di connettersi a un cluster utilizzando credenziali IAM che stanno per scadere. Assicurati di controllare come vengono aggiornate le tue credenziali IAM. Molto probabilmente, le credenziali vengono sostituite troppo vicino alla scadenza della sessione, il che comporta problemi sul lato server e errori di autenticazione.
## MSK Serverless: la creazione del cluster ha esito negativo
Se si tenta di creare un cluster MSK Serverless e il flusso di lavoro ha esito negativo, è possibile che non si disponga dell'autorizzazione per creare un endpoint VPC. Verifica che l'amministratore ti abbia concesso l'autorizzazione a creare un endpoint VPC consentendo l'operazione `ec2:CreateVpcEndpoint`.
Per un elenco completo delle autorizzazioni necessarie per eseguire tutte le operazioni di Amazon MSK, consulta la pagina [AWS politica gestita: Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md).
## Impossibile eseguire l'aggiornamento KafkaVersionsList nella configurazione MSK
Quando si aggiorna la [KafkaVersionsList](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-kafkaversionslist)proprietà nella [AWS::MSK::Configuration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html)risorsa, l'aggiornamento ha esito negativo e viene visualizzato il seguente errore.
```
Resource of type 'AWS::MSK::Configuration' with identifier '' already exists.
```
Quando si aggiorna la `KafkaVersionsList` proprietà, AWS CloudFormation ricrea una nuova configurazione con la proprietà aggiornata prima di eliminare la configurazione precedente. L'aggiornamento CloudFormation dello stack non riesce perché la nuova configurazione utilizza lo stesso nome della configurazione esistente. Tale aggiornamento richiede la [sostituzione di una risorsa](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-update-behaviors.html#update-replacement). Per eseguire correttamente l'aggiornamento`KafkaVersionsList`, è necessario aggiornare anche la proprietà [Name](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-name) nella stessa operazione.
Inoltre, se la configurazione è associata a qualsiasi cluster creato utilizzando Console di gestione AWS o AWS CLI, aggiungete quanto segue alla risorsa di configurazione per evitare [tentativi falliti di eliminazione delle risorse](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted).
```
UpdateReplacePolicy: Retain
```
Una volta completato l'aggiornamento, vai alla console Amazon MSK ed elimina la vecchia configurazione. Per informazioni sulle configurazioni MSK, consulta [Configurazione Amazon MSK Provisioned](msk-configuration.md).
# Le migliori pratiche per i broker Standard ed Express
Questa sezione descrive le migliori pratiche da seguire per i broker Standard e i broker Express. Per informazioni sulle best practice di Amazon MSK Replicator, consulta. [Best practice per l'utilizzo del replicatore MSK](msk-replicator-best-practices.md)
**Topics**
+ [Le migliori pratiche per i broker standard](bestpractices.md)
+ [Le migliori pratiche per i broker Express](bestpractices-express.md)
+ [Le migliori pratiche per i client Apache Kafka](bestpractices-kafka-client.md)
# Le migliori pratiche per i broker standard
In questo argomento vengono illustrate alcune best practice da seguire quando si utilizza Amazon MSK. Per informazioni sulle best practice di Amazon MSK Replicator, consulta. [Best practice per l'utilizzo del replicatore MSK](msk-replicator-best-practices.md)
## Considerazioni sul lato client
La disponibilità e le prestazioni dell'applicazione dipendono non solo dalle impostazioni lato server ma anche dalle impostazioni client.
+ Configura i tuoi client per un'elevata disponibilità. In un sistema distribuito come Apache Kafka, garantire un'elevata disponibilità è fondamentale per mantenere un'infrastruttura di messaggistica affidabile e tollerante ai guasti. I broker andranno offline per eventi pianificati e non pianificati, ad esempio aggiornamenti, patch, guasti hardware e problemi di rete. Un cluster Kafka è tollerante nei confronti di un broker offline, pertanto i clienti Kafka devono anche gestire il failover dei broker con garbo. Vedi i dettagli completi su. [Le migliori pratiche per i client Apache Kafka](bestpractices-kafka-client.md)
+ Assicurati che le stringhe di connessione del client includano almeno un broker per ogni zona di disponibilità. La presenza di più broker nella stringa di connessione di un client consente il failover quando un broker specifico è offline a seguito di un aggiornamento. Per informazioni su come ottenere una stringa di connessione con più broker, consulta [Ottieni i broker bootstrap per un cluster Amazon MSK](msk-get-bootstrap-brokers.md).
+ Esegui test delle prestazioni per verificare che le configurazioni dei tuoi client ti consentano di raggiungere i tuoi obiettivi prestazionali.
## Considerazioni sul lato server
### Dimensioni corrette del cluster: numero di partizioni per broker Standard
La tabella seguente mostra il numero consigliato di partizioni (incluse le repliche leader e follower) per broker Standard. Il numero consigliato di partizioni non viene applicato e rappresenta una procedura ottimale per gli scenari in cui si invia traffico su tutte le partizioni tematiche assegnate.
| Dimensione del broker | Numero consigliato di partizioni (incluse le repliche leader e follower) per broker | Numero massimo di partizioni che supportano le operazioni di aggiornamento |
| --- | --- | --- |
| kafka.t3.small | 300 | 300 |
| kafka.m5.large o kafka.m5.xlarge | 1000 | 1500 |
| kafka.m5.2xlarge | 2000 | 3000 |
| kafka.m5.4xlarge, kafka.m5.8xlarge, kafka.m5.12xlarge, kafka.m5.16xlarge oppure kafka.m5.24xlarge | 4000 | 6000 |
| kafka.m7g.large o kafka.m7g.xlarge | 1000 | 1500 |
| kafka.m7g.2xlarge | 2000 | 3000 |
| kafka.m7g.4xlarge, kafka.m7g.8xlargekafka.m7g.12xlarge, o kafka.m7g.16xlarge | 4000 | 6000 |
Se si utilizzano partizioni elevate e un throughput ridotto in cui il numero di partizioni è più elevato, ma non si invia traffico su tutte le partizioni, è possibile comprimere più partizioni per broker, purché siano stati eseguiti test e test delle prestazioni sufficienti per verificare che il cluster rimanga integro con un numero di partizioni più elevato. Se il numero di partizioni per broker supera il valore massimo consentito e il cluster si sovraccarica, ti verrà impedito di eseguire le seguenti operazioni:
+ Aggiornamento della configurazione del cluster
+ Aggiorna il cluster a un broker di dimensioni inferiori
+ Associa un Gestione dei segreti AWS segreto a un cluster con autenticazione SASL/SCRAM
Un numero elevato di partizioni può inoltre comportare la mancanza delle metriche di Kafka CloudWatch su e sullo scraping di Prometheus.
Per informazioni sulla scelta del numero di partizioni, consulta [Apache Kafka Supports 200K Partitions Per Cluster](https://blogs.apache.org/kafka/entry/apache-kafka-supports-more-partitions). Ti consigliamo inoltre di eseguire i tuoi test per determinare la dimensione giusta per i tuoi broker. Per ulteriori informazioni sulle diverse dimensioni dei broker, consulta[Tipi di broker Amazon MSK](broker-instance-types.md).
### Dimensiona correttamente il tuo cluster: numero di broker Standard per cluster
[Per determinare il numero corretto di broker Standard per il cluster MSK Provisioned e comprendere i costi, consultate il foglio di calcolo MSK Sizing and Pricing.](https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Fdy7oqpxkwhskb.cloudfront.net%2FMSK_Sizing_Pricing.xlsx&wdOrigin=BROWSELINK) Questo foglio di calcolo fornisce una stima del dimensionamento di un cluster MSK Provisioned e dei costi associati di Amazon MSK rispetto a un cluster Apache Kafka simile, autogestito e basato su EC2. Per ulteriori informazioni sui parametri di input nel foglio di calcolo, passare il mouse sulle descrizioni dei parametri. Le stime fornite da questo foglio sono conservative e forniscono un punto di partenza per un nuovo cluster MSK Provisioned. Le prestazioni, le dimensioni e i costi del cluster dipendono dal caso d'uso e consigliamo di verificarli con test ad hoc.
Per comprendere in che modo l'infrastruttura sottostante influisce sulle prestazioni di Apache Kafka, consulta le [migliori pratiche per il corretto dimensionamento dei cluster Apache Kafka per ottimizzare](https://aws.amazon.com/blogs/big-data/best-practices-for-right-sizing-your-apache-kafka-clusters-to-optimize-performance-and-cost/) prestazioni e costi nel Big Data Blog. AWS Il post del blog fornisce informazioni su come dimensionare i cluster per soddisfare i requisiti di velocità di trasmissione effettiva, disponibilità e latenza. Fornisce inoltre risposte a domande, ad esempio quando è necessario scalare verso l'alto o verso l'*alto*, e indicazioni su come verificare *continuamente le* dimensioni dei cluster di produzione. Per informazioni sui cluster basati sullo storage su più livelli, consulta [Best practice per l'esecuzione di carichi di lavoro di produzione utilizzando lo storage su più livelli Amazon MSK](https://aws.amazon.com/blogs/big-data/best-practices-for-running-production-workloads-using-amazon-msk-tiered-storage/).
### Ottimizza il throughput del cluster per istanze m5.4xl, m7g.4xl o più grandi
Quando si utilizzano istanze m5.4xl, m7g.4xl o più grandi, è possibile ottimizzare il throughput del cluster MSK Provisioned ottimizzando le configurazioni num.io.threads e num.network.threads.
num.io.Threads è il numero di thread utilizzati da un broker Standard per l'elaborazione delle richieste. L'aggiunta di più thread, fino al numero di core CPU supportati per la dimensione dell'istanza, può aiutare a migliorare il throughput del cluster.
num.network.threads è il numero di thread utilizzati dal broker Standard per ricevere tutte le richieste in arrivo e restituire le risposte. I thread di rete inseriscono le richieste in entrata in una coda di richieste per l'elaborazione da parte di io.threads. L'impostazione di num.network.threads sulla metà del numero di core CPU supportati per la dimensione dell'istanza consente l'utilizzo completo della nuova dimensione dell'istanza.
**Importante**
Non aumentare num.network.threads senza prima aumentare num.io.threads, in quanto ciò può causare una congestione legata alla saturazione della coda.
La tabella seguente descrive le impostazioni consigliate per ogni dimensione dell'istanza.
| Dimensioni istanza | Valore consigliato per num.io.threads | Valore consigliato per num.network.threads |
| --- | --- | --- |
| m5.4xl | 16 | 8 |
| m5.8xl | 32 | 16 |
| m5.12xl | 48 | 24 |
| m5.16xl | 64 | 32 |
| m5.24xl | 96 | 48 |
| m7g.4xlarge | 16 | 8 |
| m7g.8xlarge | 32 | 16 |
| m7g.12xlarge | 48 | 24 |
| m7g.16xlarge | 64 | 32 |
### Usa la versione più recente di Kafka AdminClient per evitare problemi di mancata corrispondenza tra gli ID degli argomenti
L'ID di un argomento viene perso (Errore: non corrisponde all'ID dell'argomento per la partizione) quando si utilizza una versione di Kafka AdminClient precedente alla 2.8.0 con il flag per aumentare o riassegnare le partizioni degli argomenti per un cluster MSK `--zookeeper` Provisioned utilizzando la versione 2.8.0 o successiva di Kafka. Nota che il flag `--zookeeper` è obsoleto in Kafka 2.5 ed è stato rimosso a partire da Kafka 3.0. Consulta la pagina [Upgrading to 2.5.0 from any version 0.8.x through 2.4.x](https://kafka.apache.org/documentation.html#upgrade_2_5_0).
Per evitare la mancata corrispondenza degli ID degli argomenti, utilizza una versione del client Kafka 2.8.0 o successiva per le operazioni di amministrazione di Kafka. In alternativa, i client 2.5 e versioni successive possono utilizzare il flag `--bootstrap-servers` al posto del flag `--zookeeper`.
### Creazione di cluster a disponibilità elevata
Utilizza i seguenti consigli in modo che i tuoi cluster MSK Provisioned possano essere altamente disponibili durante un aggiornamento (ad esempio quando aggiorni le dimensioni del broker o la versione di Apache Kafka, ad esempio) o quando Amazon MSK sostituisce un broker.
+ Configura un cluster con tre zone di disponibilità.
+ Assicurati che il fattore di replica (RF) sia almeno 3. Tieni presente che un valore di RF pari a 1 può portare a partizioni offline durante un aggiornamento in sequenza, mentre un RF pari a 2 può causare la perdita di dati.
+ Impostare le repliche in sinc minime (minISR) su al massimo RF - 1. Un minISR uguale a RF può impedire la produzione nel cluster durante un aggiornamento in sequenza. Un minISR di 2 consente di rendere disponibili argomenti replicati a tre vie quando una replica è offline.
### Monitoraggio dell'utilizzo della CPU
Amazon MSK consiglia vivamente di mantenere l'utilizzo della CPU per i broker (definito come`CPU User + CPU System`) inferiore al 60%. Ciò garantisce che il cluster mantenga un margine di crescita della CPU sufficiente per gestire eventi operativi, come guasti dei broker, applicazione di patch e aggiornamenti continui.
Apache Kafka può ridistribuire il carico della CPU tra i broker del cluster quando necessario. Ad esempio, quando Amazon MSK rileva e ripristina un errore del broker, esegue una manutenzione automatica, ad esempio l'applicazione di patch. Allo stesso modo, quando un utente richiede una modifica delle dimensioni del broker o un aggiornamento di versione, Amazon MSK avvia flussi di lavoro continui che portano offline un broker alla volta. Quando i broker con partizioni leader vanno offline, Apache Kafka riassegna la leadership delle partizioni per ridistribuire il lavoro agli altri broker del cluster. Seguendo questa best practice, garantisci un margine di crescita della CPU sufficiente per tollerare questi eventi operativi.
**Nota**
Durante il monitoraggio dell'utilizzo della CPU, tenete presente che l'utilizzo totale della CPU include più di e. `CPU User` `CPU System` Anche altre categorie, ad esempio `iowait` `irq``softirq`, e`steal`, contribuiscono all'attività complessiva della CPU. Di conseguenza, CPU Idle *non è sempre uguale* a`100% - CPU User - CPU System`.
Puoi utilizzare [Amazon CloudWatch Metric Math](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) per creare una metrica composita (`CPU User + CPU System`) e impostare un allarme da attivare quando l'utilizzo medio supera il 60%. Quando viene attivato, valuta la possibilità di ridimensionare il cluster utilizzando una delle seguenti opzioni:
+ Opzione 1 (consigliata): [aggiorna la dimensione del broker alla dimensione](https://docs.aws.amazon.com//msk/latest/developerguide/msk-update-broker-type.html) successiva più grande. Ad esempio, se la dimensione corrente è`kafka.m5.large`, aggiorna il cluster da utilizzare`kafka.m5.xlarge`. Tieni presente che quando aggiorni le dimensioni dei broker nel cluster, Amazon MSK disconnette i broker in modo continuativo e riassegna temporaneamente la leadership delle partizioni ad altri broker. Un aggiornamento delle dimensioni richiede in genere 10-15 minuti per broker.
+ Opzione 2: se ci sono argomenti in cui tutti i messaggi sono stati acquisiti da produttori che utilizzano scritture ininterrotte (in altre parole, i messaggi non sono codificati e l'ordinamento non è importante per i consumatori), [espandi il cluster](https://docs.aws.amazon.com//msk/latest/developerguide/msk-update-broker-count.html) aggiungendo altri broker. Inoltre, aggiungi partizioni agli argomenti esistenti con la velocità di trasmissione effettiva più elevata. Successivamente, utilizza `kafka-topics.sh --describe` per assicurarti che le partizioni appena aggiunte vengano assegnate ai nuovi broker. Il vantaggio principale di questa opzione rispetto alla precedente è la possibilità di gestire risorse e costi in modo più granulare. Inoltre, è possibile utilizzare questa opzione se il carico della CPU supera in modo significativo il 60%, poiché questa forma di dimensionamento in genere non comporta un aumento del carico per i broker esistenti.
+ Opzione 3: espandi il cluster MSK Provisioned aggiungendo broker, quindi riassegna le partizioni esistenti utilizzando lo strumento di riassegnazione delle partizioni denominato. `kafka-reassign-partitions.sh` Tuttavia, se utilizzi questa opzione, il cluster dovrà spendere risorse per replicare i dati da broker a broker dopo la riassegnazione delle partizioni. Rispetto alle due opzioni precedenti, questa opzione può inizialmente aumentare in modo significativo il carico sul cluster. Di conseguenza, Amazon MSK sconsiglia di utilizzare questa opzione quando l'utilizzo della CPU è superiore al 70%, perché la replica causa un carico aggiuntivo della CPU e del traffico di rete. Amazon MSK consiglia di utilizzare questa opzione solo se le due opzioni precedenti non sono percorribili.
Altre raccomandazioni:
+ Monitora l'utilizzo totale della CPU per broker come proxy per la distribuzione del carico. Se i broker hanno un utilizzo della CPU costantemente irregolare, potrebbe essere un segno che il carico non è distribuito uniformemente all'interno del cluster. Si consiglia di utilizzare [Cruise Control per gestire continuamente la distribuzione del carico](https://docs.aws.amazon.com//msk/latest/developerguide/cruise-control.html) tramite l'assegnazione delle partizioni.
+ Monitora la latenza di produzione e utilizzo. La latenza di produzione e utilizzo può aumentare linearmente con l'utilizzo della CPU.
+ **Intervallo di scrape JMX**: se si abilita il monitoraggio aperto con la [funzionalità Prometheus](https://docs.aws.amazon.com/msk/latest/developerguide/open-monitoring.html), si consiglia di utilizzare un intervallo di scrape di 60 secondi o superiore (scrape\$1interval: 60s) per la configurazione dell'host Prometheus (prometheus.yml). La riduzione dell'intervallo di scrape può comportare un utilizzo elevato della CPU sul cluster.
### Monitoraggio dello spazio su disco
Per evitare di esaurire lo spazio su disco per i messaggi, crea un CloudWatch allarme che controlli la `KafkaDataLogsDiskUsed` metrica. Quando il valore di questo parametro raggiunge o supera l'85%, esegui una o più delle seguenti operazioni:
+ Utilizza [Scalabilità automatica per i cluster Amazon MSK](msk-autoexpand.md). Puoi anche aumentare manualmente lo spazio di archiviazione del broker come descritto nella sezione [Ridimensionamento manuale per broker Standard](manually-expand-storage.md).
+ Riduci il periodo di conservazione dei messaggi o la dimensione del log. Per informazioni su come eseguire queste operazioni, consulta [Regolazione dei parametri di conservazione dei dati](#bestpractices-retention-period).
+ Elimina argomenti non utilizzati.
Per informazioni su come configurare e utilizzare gli allarmi, consulta [Using Amazon CloudWatch Alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). Per un elenco completo di parametri di Amazon MSK, consulta la sezione [Monitora un cluster Amazon MSK Provisioned](monitoring.md).
### Regolazione dei parametri di conservazione dei dati
Il consumo di messaggi non li rimuove dal log. Per liberare regolarmente spazio su disco, puoi specificare in modo esplicito un periodo di conservazione, ovvero il periodo di permanenza dei messaggi nel log. Puoi inoltre specificare una dimensione del log di conservazione. Quando viene raggiunto il periodo di conservazione o la dimensione del log di conservazione, Apache Kafka inizia a rimuovere i segmenti inattivi dal log.
Per specificare una policy di conservazione a livello di cluster, imposta uno o più dei seguenti parametri: `log.retention.hours`, `log.retention.minutes`, `log.retention.ms` o `log.retention.bytes`. Per ulteriori informazioni, consulta [Configurazioni Amazon MSK personalizzate](msk-configuration-properties.md).
Puoi anche specificare i parametri di conservazione a livello di argomento:
+ Per specificare un periodo di conservazione per argomento, utilizza il comando seguente.
```
kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name TopicName --add-config retention.ms=DesiredRetentionTimePeriod
```
+ Per specificare una dimensione del log di conservazione per argomento, utilizza il comando seguente.
```
kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name TopicName --add-config retention.bytes=DesiredRetentionLogSize
```
I parametri di conservazione specificati a livello di argomento hanno la precedenza sui parametri a livello di cluster.
### Accelerazione del ripristino dei log dopo un arresto non corretto
Dopo un arresto non corretto, un broker può impiegare del tempo per riavviarsi poiché esegue il ripristino dei log. Per impostazione predefinita, Kafka utilizza solo un thread per directory di log per eseguire questo ripristino. Ad esempio, se si dispone di migliaia di partizioni, il completamento del ripristino dei log può richiedere ore. Per velocizzare il ripristino dei log, si consiglia di aumentare il numero di thread utilizzando la proprietà di configurazione [https://docs.aws.amazon.com/msk/latest/developerguide/msk-configuration-properties.html](https://docs.aws.amazon.com/msk/latest/developerguide/msk-configuration-properties.html). È possibile impostarlo sul numero di core CPU.
### Monitoraggio della memoria di Apache Kafka
Ti consigliamo di monitorare la memoria utilizzata da Apache Kafka. In caso contrario, il cluster potrebbe diventare non disponibile.
Per determinare la quantità di memoria utilizzata da Apache Kafka, puoi monitorare il parametro `HeapMemoryAfterGC`. `HeapMemoryAfterGC` è la percentuale di memoria heap totale utilizzata dopo la rimozione di oggetti inutili (garbage collection). Ti consigliamo di creare un CloudWatch allarme che agisca quando un `HeapMemoryAfterGC` aumento supera il 60%.
Le operazioni che è possibile eseguire per ridurre l'utilizzo della memoria variano. Dipendono dal modo in cui si configura Apache Kafka. Ad esempio, se si utilizza la consegna transazionale dei messaggi, è possibile ridurre il valore `transactional.id.expiration.ms` nella configurazione di Apache Kafka da `604800000` ms a `86400000` ms (da 7 giorni a 1 giorno). Ciò riduce l'ingombro di memoria di ciascuna transazione.
### Non aggiungere broker non MSK
Per i cluster MSK Provisioned ZooKeeper basati su MSK, se si utilizzano ZooKeeper i comandi Apache per aggiungere broker, questi broker non vengono aggiunti al cluster MSK Provisioned e ZooKeeper Apache conterrà informazioni errate sul cluster. Ciò potrebbe comportare la perdita di dati. Per le operazioni supportate del cluster MSK Provisioned, vedere. [Caratteristiche e concetti chiave di Amazon MSK](operations.md)
### Abilitazione della crittografia dei dati in transito
Per informazioni sulla crittografia dei dati in transito e su come abilitarla, consulta [Crittografia Amazon MSK in transito](msk-encryption.md#msk-encryption-in-transit).
### Riassegnazione delle partizioni
Per spostare le partizioni su broker diversi sullo stesso cluster MSK Provisioned, è possibile utilizzare lo strumento di riassegnazione delle partizioni denominato. `kafka-reassign-partitions.sh` Si consiglia di non riassegnare più di 10 partizioni in una singola chiamata per operazioni sicure. `kafka-reassign-partitions` Ad esempio, dopo aver aggiunto nuovi broker per espandere un cluster o aver spostato le partizioni per rimuovere i broker, è possibile ribilanciare il cluster riassegnando le partizioni ai nuovi broker. Per informazioni su come aggiungere broker a un cluster MSK Provisioned, vedere. [Espandi il numero di broker in un cluster Amazon MSK](msk-update-broker-count.md) Per informazioni su come rimuovere broker da un cluster MSK Provisioned, vedere. [Rimuovere un broker da un cluster Amazon MSK](msk-remove-broker.md) Per informazioni sullo strumento di riassegnazione delle partizioni, consulta la sezione relativa all'[espansione del cluster](https://kafka.apache.org/documentation/#basic_ops_cluster_expansion) nella documentazione di Apache Kafka.
# Le migliori pratiche per i broker Express
Questo argomento descrive alcune best practice da seguire quando si utilizzano i broker Express. I broker Express sono preconfigurati per garantire disponibilità e durabilità elevate. Per impostazione predefinita, i dati sono distribuiti su tre zone di disponibilità, la replica è sempre impostata su 3 e la replica minima sincronizzata è sempre impostata su 2. Tuttavia, ci sono ancora alcuni fattori da considerare per ottimizzare l'affidabilità e le prestazioni del cluster.
## Considerazioni sul lato client
La disponibilità e le prestazioni dell'applicazione dipendono non solo dalle impostazioni lato server ma anche dalle impostazioni client.
+ Configura i tuoi client per un'elevata disponibilità. In un sistema distribuito come Apache Kafka, garantire un'elevata disponibilità è fondamentale per mantenere un'infrastruttura di messaggistica affidabile e tollerante ai guasti. I broker andranno offline per eventi pianificati e non pianificati, ad esempio aggiornamenti, patch, guasti hardware e problemi di rete. Un cluster Kafka è tollerante nei confronti di un broker offline, pertanto i clienti Kafka devono anche gestire il failover dei broker con garbo. [Consulta i dettagli completi nelle raccomandazioni sulle migliori pratiche per i clienti Apache Kafka.](bestpractices-kafka-client.md)
+ Esegui test delle prestazioni per verificare che le configurazioni dei tuoi client ti consentano di raggiungere i tuoi obiettivi prestazionali anche quando riavviamo i broker in condizioni di picco. È possibile riavviare i broker del cluster dalla console MSK o utilizzando MSK. APIs
## Considerazioni sul lato server
**Topics**
+ [Dimensionamento corretto del cluster: numero di broker per cluster](#brokers-per-express-cluster)
+ [Monitoraggio dell'utilizzo della CPU](#bestpractices-monitor-cpu-express)
+ [Dimensioni corrette del cluster: numero di partizioni per broker Express](#partitions-per-express-broker)
+ [Monitora il numero di connessioni](#monitor-connection-count)
+ [Riassegnazione delle partizioni](#bestpractices-express-reassign-partitions)
### Dimensionamento corretto del cluster: numero di broker per cluster
Scegliere il numero di broker per il cluster basato su Express è semplice. Ogni broker Express è dotato di una capacità di throughput definita per l'ingresso e l'uscita. È consigliabile utilizzare questa capacità di throughput come mezzo principale per dimensionare il cluster (e quindi considerare altri fattori come il numero di partizioni e connessioni, descritti di seguito).
Ad esempio, se la tua applicazione di streaming richiede il 45% MBps della capacità di ingresso (scrittura) e il 90% MBps dei dati in uscita (lettura), puoi semplicemente utilizzare 3 broker express.m7g.large per soddisfare le tue esigenze di throughput. Ogni broker express.m7g.large gestirà il 15% dell'ingresso e il 30% dell'uscita. MBps MBps Consulta la tabella seguente per i limiti di throughput consigliati per ogni dimensione del broker Express. Se il throughput supera i limiti consigliati, potresti riscontrare un peggioramento delle prestazioni e dovresti ridurre il traffico o scalare il cluster. Se la velocità effettiva supera i limiti consigliati e raggiunge la quota per broker, MSK limiterà il traffico dei clienti per evitare ulteriori sovraccarichi.
Puoi anche utilizzare il nostro foglio di calcolo (vedi [MSK Sizing and Pricing) per valutare diversi scenari e](https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Fdy7oqpxkwhskb.cloudfront.net%2FMSK_Sizing_Pricing.xlsx&wdOrigin=BROWSELINK) prendere in considerazione altri fattori, come il numero di partizioni.
La tabella seguente elenca il throughput massimo consigliato per broker per ogni dimensione dell'istanza.
| Dimensioni istanza | Ingresso () MBps | Uscita () MBps |
| --- | --- | --- |
| `express.m7g.large` | 15.6 | 31,2 |
| `express.m7g.xlarge` | 31,2 | 62,5 |
| `express.m7g.2xlarge` | 62,5 | 125,0 |
| `express.m7g.4xlarge` | 124,9 | 249,8 |
| `express.m7g.8xlarge` | 250,0 | 500,0 |
| `express.m7g.12xlarge` | 375,0 | 750,0 |
| `express.m7g.16xlarge` | 500,0 | 1000,0 |
### Monitoraggio dell'utilizzo della CPU
Ti consigliamo di mantenere l'utilizzo totale della CPU per i tuoi broker (definito come utente CPU più sistema CPU) al di sotto del 60%. Quando hai a disposizione almeno il 40% della CPU totale del cluster, Apache Kafka può ridistribuire il carico della CPU tra i broker del cluster, se necessario. Ciò può essere necessario a causa di eventi pianificati o non pianificati. Un esempio di evento pianificato è l'aggiornamento di una versione del cluster durante il quale MSK aggiorna i broker di un cluster riavviandoli uno alla volta. Un esempio di evento non pianificato è un guasto hardware in un broker o, nel peggiore dei casi, un guasto AZ in cui tutti i broker di una AZ sono interessati. Quando i broker con partition lead repliche vanno offline, Apache Kafka riassegna la leadership delle partizioni per ridistribuire il lavoro agli altri broker del cluster. Seguendo questa best practice, potete assicurarvi di avere abbastanza spazio di crescita della CPU nel cluster per tollerare eventi operativi come questi.
Puoi [usare Using math expression with CloudWatch metrics](https://docs.aws.amazon.com///AmazonCloudWatch/latest/monitoring/using-metric-math.html) nella *Amazon CloudWatch User Guide* per creare una metrica composita che sia CPU User \$1 CPU System. Imposta un allarme che si attiva quando il parametro composito raggiunge un utilizzo medio della CPU del 60%. Quando viene attivato questo allarme, dimensiona il cluster utilizzando una delle seguenti opzioni:
+ Opzione 1: [aggiorna la dimensione del broker alla dimensione](msk-update-broker-type.md) successiva più grande. Tieni presente che quando aggiorni le dimensioni dei broker nel cluster, Amazon MSK disconnette i broker in modo continuativo e riassegna temporaneamente la leadership delle partizioni ad altri broker.
+ Opzione 2: [espandi il cluster aggiungendo broker, quindi riassegnando](msk-update-broker-count.md) le partizioni esistenti utilizzando lo strumento di riassegnazione delle partizioni denominato. `kafka-reassign-partitions.sh`
**Altri consigli**
+ Monitora l'utilizzo totale della CPU per broker come proxy per la distribuzione del carico. Se i broker utilizzano costantemente la CPU in modo disomogeneo, è possibile che il carico non sia distribuito in modo uniforme all'interno del cluster. Consigliamo di utilizzare [Cruise Control](cruise-control.md) per gestire continuamente la distribuzione del carico tramite l'assegnazione delle partizioni.
+ Monitora la latenza di produzione e utilizzo. La latenza di produzione e utilizzo può aumentare linearmente con l'utilizzo della CPU.
+ Intervallo di scrape JMX: se si abilita il monitoraggio aperto con la funzione Prometheus, si consiglia di utilizzare un intervallo di scrape di 60 secondi o superiore () per la configurazione host Prometheus (). `scrape_interval: 60s` `prometheus.yml` La riduzione dell'intervallo di scrape può comportare un utilizzo elevato della CPU sul cluster.
### Dimensioni corrette del cluster: numero di partizioni per broker Express
Se hai un numero elevato di partizioni e un throughput ridotto in cui hai un numero di partizioni più elevato, ma non invii traffico su tutte le partizioni, puoi comprimere più partizioni per broker, purché tu abbia eseguito test e test delle prestazioni sufficienti per verificare che il cluster rimanga integro con un numero di partizioni più elevato. Se il numero di partizioni per broker supera il valore massimo consentito e il cluster si sovraccarica, ti verrà impedito di eseguire le seguenti operazioni:
+ Aggiornamento della configurazione del cluster
+ Aggiorna il cluster a un broker di dimensioni inferiori
+ Associa un Gestione dei segreti AWS segreto a un cluster con SASL/SCRAM autenticazione
Un cluster sovraccarico con un numero elevato di partizioni può inoltre comportare la mancanza dei parametri di Kafka sullo scraping di Prometheus e CloudWatch su Prometheus.
Per informazioni sulla scelta del numero di partizioni, consulta [Apache Kafka Supports 200K Partitions Per Cluster](https://blogs.apache.org/kafka/entry/apache-kafka-supports-more-partitions). Ti consigliamo inoltre di eseguire i tuoi test per determinare la dimensione giusta per i tuoi broker. Per ulteriori informazioni sulle diverse dimensioni dei broker, consulta[Dimensioni dei broker Amazon MSK](broker-instance-sizes.md).
Per informazioni sul numero consigliato di partizioni (incluse le repliche leader e follower) per ogni broker Express, consulta. [Quota di partizione Express Broker](limits.md#msk-express-broker-partition-quota) Il numero consigliato di partizioni non viene applicato e rappresenta una procedura consigliata per gli scenari in cui si invia traffico attraverso tutte le partizioni tematiche assegnate.
### Monitora il numero di connessioni
Le connessioni dei client ai broker consumano risorse di sistema come memoria e CPU. A seconda del meccanismo di autenticazione utilizzato, è necessario effettuare un monitoraggio per assicurarsi di rispettare i limiti applicabili. Per gestire i tentativi di connessione non riusciti, puoi impostare il parametro di configurazione `reconnect.backoff.ms` sul lato client. Ad esempio, se desideri che un client riprovi a connettersi dopo 1 secondo, imposta su`reconnect.backoff.ms`. `1000` Per ulteriori informazioni sulla configurazione dei nuovi tentativi, consulta la documentazione di Apache [Kafka](bestpractices-kafka-client.md#bestpractices-kafka-client-client-availability).
****
| Dimensione | Quota |
| --- | --- |
| [Numero massimo di connessioni TCP per broker (controllo degli accessi IAM)](iam-access-control.md) | 3000 |
| Numero massimo di connessioni TCP per broker (IAM) | 100 al secondo |
| Numero massimo di connessioni TCP per broker (non IAM) | MSK non impone limiti di connessione per l'autenticazione non IAM. È tuttavia necessario monitorare altre metriche come l'utilizzo della CPU e della memoria per assicurarsi di non sovraccaricare il cluster a causa di connessioni eccessive. |
### Riassegnazione delle partizioni
Per spostare le partizioni su broker diversi sullo stesso cluster MSK Provisioned, è possibile utilizzare lo strumento di riassegnazione delle partizioni denominato. `kafka-reassign-partitions.sh` Si consiglia di non riassegnare più di 20 partizioni in una singola chiamata per operazioni sicure. `kafka-reassign-partitions` Ad esempio, dopo aver aggiunto nuovi broker per espandere un cluster o aver spostato le partizioni per rimuovere i broker, è possibile ribilanciare il cluster riassegnando le partizioni ai nuovi broker. Per informazioni su come aggiungere broker a un cluster MSK Provisioned, vedere. [Espandi il numero di broker in un cluster Amazon MSK](msk-update-broker-count.md) Per informazioni su come rimuovere broker da un cluster MSK Provisioned, vedere. [Rimuovere un broker da un cluster Amazon MSK](msk-remove-broker.md) Per informazioni sullo strumento di riassegnazione delle partizioni, consulta la sezione relativa all'[espansione del cluster](https://kafka.apache.org/documentation/#basic_ops_cluster_expansion) nella documentazione di Apache Kafka.
# Le migliori pratiche per i client Apache Kafka
Quando si lavora con Apache Kafka e Amazon MSK, è importante configurare correttamente sia il client che il server per prestazioni e affidabilità ottimali. Questa guida fornisce consigli sulla configurazione lato client basata sulle best practice per Amazon MSK.
Per informazioni sulle best practice di Amazon MSK Replicator, consulta. [Best practice per l'utilizzo del replicatore MSK](msk-replicator-best-practices.md) Per le best practice dei broker Standard ed Express, consulta. [Le migliori pratiche per i broker Standard ed Express](bestpractices-intro.md)
**Topics**
+ [Disponibilità del client Apache Kafka](#bestpractices-kafka-client-client-availability)
+ [Prestazioni del client Apache Kafka](#bestpractices-kafka-client-performance)
+ [Monitoraggio del client Kafka](#bestpractices-kafka-client-monitoring)
## Disponibilità del client Apache Kafka
In un sistema distribuito come Apache Kafka, garantire un'elevata disponibilità è fondamentale per mantenere un'infrastruttura di messaggistica affidabile e tollerante ai guasti. I broker andranno offline per eventi pianificati e non pianificati, come aggiornamenti, patch, guasti hardware e problemi di rete. Un cluster Kafka è tollerante nei confronti di un broker offline, pertanto i clienti Kafka devono anche gestire il failover dei broker con garbo. Per garantire un'elevata disponibilità dei clienti Kafka, consigliamo queste best practice.
**Disponibilità dei produttori**
+ Impostato `retries` per indicare al produttore di riprovare a inviare messaggi non riusciti durante il failover del broker. Consigliamo un valore intero massimo o un valore elevato simile per la maggior parte dei casi d'uso. In caso contrario, si interromperà l'elevata disponibilità di Kafka.
+ Imposta `delivery.timeout.ms` per specificare il limite superiore per il tempo totale tra l'invio di un messaggio e la ricezione di una conferma dal broker. Ciò dovrebbe riflettere i requisiti aziendali relativi alla durata di validità di un messaggio. Imposta il limite di tempo sufficientemente alto da consentire un numero sufficiente di tentativi per completare l'operazione di failover. Si consiglia un valore pari o superiore a 60 secondi per la maggior parte dei casi d'uso.
+ Impostato `request.timeout.ms` al valore massimo, una singola richiesta deve attendere prima di tentare un nuovo invio. Consigliamo un valore pari o superiore a 10 secondi per la maggior parte dei casi d'uso.
+ Imposta `retry.backoff.ms` per configurare il ritardo tra i tentativi per evitare tempeste di tentativi e impatto sulla disponibilità. Consigliamo un valore minimo di 200 ms per la maggior parte dei casi d'uso.
+ Imposta `acks=all` per configurare una durabilità elevata; questa impostazione deve essere in linea con una configurazione lato server di `RF=3` e `min.isr=2` garantire che tutte le partizioni in ISR riconoscano la scrittura. Durante un singolo broker offline, questo è il, cioè. `min.isr` `2`
**Disponibilità dei consumatori**
+ Impostata `latest` inizialmente `auto.offset.reset` per gruppi di consumatori nuovi o ricreati. In questo modo si evita il rischio di aggiungere carico al cluster consumando l'intero argomento.
+ Impostato `auto.commit.interval.ms` quando si utilizza`enable.auto.commit`. Si consiglia un valore minimo di 5 secondi per la maggior parte dei casi d'uso per evitare il rischio di carico aggiuntivo.
+ Implementa la gestione delle eccezioni all'interno del codice di elaborazione dei messaggi del consumatore per gestire errori transitori, ad esempio un interruttore automatico o una sospensione con back-off esponenziale. In caso contrario, si possono verificare arresti anomali dell'applicazione, che possono causare un ribilanciamento eccessivo.
+ Imposta `isolation.level` per controllare la modalità di lettura dei messaggi transazionali:
Per impostazione predefinita, consigliamo di impostare sempre in `read_uncommitted` modo implicito. Questo non è presente in alcune implementazioni del client.
Quando si utilizza lo storage su più livelli, `read_uncommitted` si consiglia un valore pari a
+ `client.rack`Impostare per utilizzare la lettura della replica più vicina. Si consiglia di impostare su per ridurre `az id ` al minimo i costi e la latenza del traffico di rete. Consulta [Riduci i costi del traffico di rete dei tuoi utenti Amazon MSK grazie alla consapevolezza dei rack](https://aws.amazon.com/blogs/big-data/reduce-network-traffic-costs-of-your-amazon-msk-consumers-with-rack-awareness/).
**Ribilanciamenti per i consumatori**
+ Imposta su `session.timeout.ms` un valore maggiore del tempo di avvio di un'applicazione, incluso qualsiasi jitter di avvio implementato. Consigliamo un valore di 60 secondi per la maggior parte dei casi d'uso.
+ Imposta `heartbeat.interval.ms` per perfezionare il modo in cui il coordinatore del gruppo considera un consumatore sano. Consigliamo un valore di 10 secondi per la maggior parte dei casi d'uso.
+ Imposta uno shutdown hook nell'applicazione per chiudere in modo sicuro il consumatore su SIGTERM, anziché affidarti ai timeout delle sessioni per identificare quando un consumatore lascia un gruppo. Le applicazioni Kstream possono impostare un valore di. `internal.leave.group.on.close` `true`
+ Impostato `group.instance.id` su un valore distinto all'interno del gruppo di consumatori. Idealmente un nome host, un task-id o un pod-id. Ti consigliamo di impostarlo sempre per comportamenti più deterministici e una migliore correlazione dei log durante la risoluzione dei problemi. client/server
+ Imposta `group.initial.rebalance.delay.ms` su un valore in linea con il tempo medio di implementazione. In questo modo si interrompono i ribilanciamenti continui durante l'implementazione.
+ Impostato `partition.assignment.strategy` per utilizzare gli assegnatori permanenti. Consigliamo l'uno o l'altro. `StickyAssignor` `CooperativeStickyAssignor`
## Prestazioni del client Apache Kafka
Per garantire prestazioni elevate dei clienti Kafka, consigliamo queste best practice.
**Prestazioni del produttore**
+ Impostato `linger.ms` per controllare la quantità di tempo che un produttore attende per il riempimento di un batch. I lotti più piccoli sono costosi dal punto di vista computazionale per Kafka in quanto si traducono in più thread e operazioni contemporaneamente. I/O Consigliamo i seguenti valori.
Un valore minimo di 5 ms per tutti i casi d'uso, inclusa la bassa latenza.
Consigliamo un valore più alto di 25 ms, per la maggior parte dei casi d'uso.
Si consiglia di non utilizzare mai un valore pari a zero in casi d'uso a bassa latenza. (Un valore pari a zero in genere causa latenza indipendentemente dal sovraccarico di I/O).
+ Impostato `batch.size` per controllare la dimensione del batch inviato al cluster. Si consiglia di aumentarlo a un valore di 64 KB o 128 KB.
+ Impostato `buffer.memory` quando si utilizzano batch di dimensioni maggiori. Consigliamo un valore di 64 MB per la maggior parte dei casi d'uso.
+ Impostato `send.buffer.bytes` per controllare il buffer TCP utilizzato per ricevere i byte. Consigliamo un valore pari a -1 per consentire al sistema operativo di gestire questo buffer quando si esegue un produttore su una rete ad alta latenza.
+ Imposta compression.type per controllare la compressione dei batch. Consigliamo lz4 o zstd di eseguire un produttore su una rete ad alta latenza.
**Prestazioni per i consumatori**
+ Impostato `fetch.min.bytes` per controllare la dimensione minima di recupero valida per ridurre il numero di recuperi e il carico del cluster.
Consigliamo un valore minimo di 32 byte per tutti i casi d'uso.
Si consiglia un valore più alto di 128 byte per la maggior parte dei casi d'uso.
+ Imposta fetch.max.wait.ms per determinare per quanto tempo il consumatore aspetterà prima che fetch.min.bytes venga ignorato. Consigliamo un valore di 1000 ms per la maggior parte dei casi d'uso.
+ Consigliamo che il numero di utenti sia almeno uguale al numero di partizioni per migliorare il parallelismo e la resilienza. In alcune situazioni, puoi scegliere di avere un numero di utenti inferiore al numero di partizioni per argomenti a bassa velocità di trasmissione.
+ Impostato `receive.buffer.bytes` per controllare il buffer TCP utilizzato per ricevere i byte. Consigliamo un valore pari a -1 per consentire al sistema operativo di gestire questo buffer quando si esegue un consumer su una rete ad alta latenza.
**Connessioni client**
Il ciclo di vita delle connessioni ha un costo computazionale e di memoria su un cluster Kafka. Troppe connessioni create contemporaneamente causano un carico che può influire sulla disponibilità di un cluster Kafka. Questo impatto sulla disponibilità può spesso portare le applicazioni a creare ancora più connessioni, causando così un errore a cascata, con conseguente interruzione completa. È possibile ottenere un numero elevato di connessioni se create a una velocità ragionevole.
Consigliamo le seguenti attenuazioni per gestire alti tassi di creazione di connessioni:
+ Assicurati che il meccanismo di distribuzione delle applicazioni non si riavvii tutto producers/consumers in una volta, ma preferibilmente in batch più piccoli.
+ A livello di applicazione, lo sviluppatore deve assicurarsi che venga eseguito un jitter casuale (random sleep) prima di creare un client di amministrazione, un client di produzione o un client consumer.
+ A SIGTERM, quando si chiude la connessione, è necessario eseguire uno sleep casuale per garantire che non tutti i client Kafka vengano chiusi contemporaneamente. Il sonno casuale deve avvenire entro il timeout precedente al verificarsi di SIGKILL.
**Example Esempio A (Java)**
```
sleepInSeconds(randomNumberBetweenOneAndX);
this.kafkaProducer = new KafkaProducer<>(this.props);
```
**Example Esempio B (Java)**
```
Runtime.getRuntime().addShutdownHook(new Thread(() -> {
sleepInSeconds(randomNumberBetweenOneAndTwentyFive);
kafkaProducer.close(Duration.ofSeconds(5));
});
```
+ A livello di applicazione, lo sviluppatore deve assicurarsi che i client vengano creati una sola volta per applicazione secondo uno schema singleton. Ad esempio, quando si utilizza lambda, il client deve essere creato in un ambito globale e non nel gestore del metodo.
+ Consigliamo di monitorare il numero di connessioni con l'obiettivo di rimanere stabile. creation/close/shiftLa connessione è normale durante le implementazioni e il failover del broker.
## Monitoraggio del client Kafka
Il monitoraggio dei clienti Kafka è fondamentale per mantenere la salute e l'efficienza del vostro ecosistema Kafka. Che tu sia un amministratore di Kafka, uno sviluppatore o un membro del team operativo, abilitare le metriche lato client è fondamentale per comprendere l'impatto aziendale durante eventi pianificati e non pianificati.
Ti consigliamo di monitorare le seguenti metriche lato client utilizzando il tuo meccanismo di acquisizione delle metriche preferito.
Quando richiedi assistenza con AWS, includi eventuali valori anomali osservati durante l'incidente. Includi anche un esempio dei log dell'applicazione client che descrivono in dettaglio gli errori (non gli avvisi).
**Metriche del produttore**
+ byte-rate
+ record-send-rate
+ records-per-request-avg
+ acks-latency-avg
+ request-latency-avg
+ request-latency-max
+ record-error-rate
+ record-retry-rate
+ frequenza di errore
**Nota**
Gli errori transitori relativi ai nuovi tentativi non sono motivo di preoccupazione, in quanto fanno parte del protocollo di Kafka per la gestione di problemi transitori come il failover dei leader o le ritrasmissioni di rete. `record-send-rate`confermerà se i produttori stanno ancora procedendo con i nuovi tentativi.
**Metriche relative ai consumatori**
+ records-consumed-rate
+ bytes-consumed-rate
+ frequenza di recupero
+ records-lag-max
+ record-error-rate
+ fetch-error-rate
+ tasso di sondaggio
+ rebalance-latency-avg
+ tasso di commissione
**Nota**
Frequenze di fetch e commitrate elevate causeranno un carico non necessario sul cluster. È ottimale eseguire richieste in batch più grandi.
**Metriche comuni**
+ connection-close-rate
+ connection-creation-rate
+ numero di connessioni
**Nota**
Una connessione elevata creation/termination causerà un carico non necessario sul cluster.