Risoluzione dei problemi del servizio OpenSearch di Amazon - Amazon OpenSearch Service

Risoluzione dei problemi del servizio OpenSearch di Amazon

In questa sezione viene descritto come identificare e risolvere problemi comuni del servizio OpenSearch di Amazon. Consulta le informazioni contenute in questa sezione prima di contattare AWS Support.

Impossibile accedere a OpenSearch Dashboards

L'endpoint OpenSearch Dashboard non supporta le richieste firmate. Se la policy di controllo accessi per il dominio consente l'accesso solo a determinati utenti o ruoli IAM e non è stata configurata l'autenticazione Amazon Cognito, è possibile che venga ricevuto il seguente messaggio di errore quando si prova ad accedere a Dashboards:

"User: anonymous is not authorized to perform: es:ESHttpGet"

Se il dominio OpenSearch Service utilizza l'accesso VPC, è possibile che tale errore non si manifesti, ma la richiesta potrebbe scadere. Per ulteriori informazioni su come correggere questo problema e le varie opzioni di configurazione disponibili, vedi Controllo dell'accesso a OpenSearch DashboardsInformazioni sulle policy d'accesso nei domini VPC e Gestione di accessi e identità nel servizio OpenSearch di Amazon.

Impossibile accedere al dominio VPC

Consulta Informazioni sulle policy d'accesso nei domini VPC e Test dei domini VPC.

Cluster in stato di sola lettura

Rispetto alle versioni precedenti di Elasticsearch, OpenSearch ed Elasticsearch 7.x utilizzano un sistema diverso per il coordinamento del cluster. In questo nuovo sistema, quando il cluster perde il quorum, il cluster non è disponibile finché non si esegue un'azione. La perdita del quorum può assumere due forme:

  • Se il cluster utilizza nodi master dedicati, la perdita del quorum si verifica quando metà o più nodi non sono disponibili.

  • Se il cluster non utilizza nodi master dedicati, la perdita del quorum si verifica quando metà o più nodi di dati non sono disponibili.

Se si verifica una perdita del quorum e il cluster ha più di un nodo, OpenSearch Service ripristina il quorum e posiziona il cluster in uno stato di sola lettura. Sono disponibili due opzioni:

Se preferisci utilizzare il cluster così com'è, verifica che lo stato del cluster sia verde utilizzando la seguente richiesta:

GET _cat/health?v

Se lo stato del cluster è rosso, ti consigliamo di ripristinare il cluster da uno snapshot. Puoi anche consultare Cluster in stato rosso per la risoluzione dei problemi. Se l’integrità del cluster è verde, controlla che tutti gli indici previsti siano presenti utilizzando la seguente richiesta:

GET _cat/indices?v

Quindi esegui alcune ricerche per verificare che i dati previsti siano presenti. In caso affermativo, puoi rimuovere lo stato di sola lettura utilizzando la seguente richiesta:

PUT _cluster/settings { "persistent": { "cluster.blocks.read_only": false } }

Se si verifica una perdita del quorum e il cluster ha un solo nodo, OpenSearch Service sostituisce il nodo e non posiziona il cluster in uno stato di sola lettura. In caso contrario, le opzioni sono le stesse: utilizza il cluster così com'è o ripristina da uno snapshot.

In entrambe le situazioni, OpenSearch Service invia due eventi al tuo AWS Health Dashboard. Il primo segnala la perdita del quorum. Il secondo si verifica dopo che OpenSearch Service ha ripristinato correttamente il quorum. Per ulteriori informazioni su come utilizzare AWS Health Dashboard, consultare la Guida per l'utente di AWS Health.

Cluster in stato rosso

Uno stato rosso del cluster indica che almeno una partizione primaria e le sue repliche non sono assegnate a un nodo. OpenSearch Service continua a provare a eseguire snapshot automatici di tutti gli indici indipendentemente dal loro stato, ma gli snapshot non riescono se lo stato rosso del cluster persiste.

Le cause più comuni di uno stato rossi del cluster sono nodi del cluster con errori e arresto anomalo del processo di OpenSearch causati da un carico di elaborazione costantemente elevato.

Nota

OpenSearch Service archivia gli snapshot automatici per 14 giorni, indipendentemente dallo stato del cluster. Pertanto, se lo stato rosso del cluster persiste per più di due settimane, l'ultimo snapshot automatico integro verrà eliminato e i dati del cluster potrebbero essere persi definitivamente. Se il dominio OpenSearch Service entra nello stato rosso del cluster, AWS Support potrebbe contattare l'utente per chiedere se si preferisce risolvere il problema personalmente o se si desideri ricevere assistenza dal team di supporto. È possibile impostare un allarme CloudWatch per ricevere una notifica quando si verifica uno stato rosso del cluster.

In definitiva, partizioni rosse causano cluster rossi e indici rossi causano partizioni rosse. Per identificare gli indici che causano uno stato rosso del cluster, OpenSearch dispone di alcune utili API.

  • GET /_cluster/allocation/explain sceglie la prima partizione non assegnata che trova e spiega perché non può essere allocata a un nodo:

    { "index": "test4", "shard": 0, "primary": true, "current_state": "unassigned", "can_allocate": "no", "allocate_explanation": "cannot allocate because allocation is not permitted to any of the nodes" }
  • GET /_cat/indices?v mostra lo stato di integrità, il numero di documenti e l'utilizzo del disco per ogni indice:

    health status index uuid pri rep docs.count docs.deleted store.size pri.store.size green open test1 30h1EiMvS5uAFr2t5CEVoQ 5 0 820 0 14mb 14mb green open test2 sdIxs_WDT56afFGu5KPbFQ 1 0 0 0 233b 233b green open test3 GGRZp_TBRZuSaZpAGk2pmw 1 1 2 0 14.7kb 7.3kb red open test4 BJxfAErbTtu5HBjIXJV_7A 1 0 green open test5 _8C6MIXOSxCqVYicH3jsEA 1 0 7 0 24.3kb 24.3kb

L'eliminazione degli indici rossi è il modo più rapido per risolvere uno stato rosso del cluster. A seconda del motivo per cui si ha uno status del cluster rosso, è possibile quindi ricalibrare il dominio OpenSearch Service perché usi tipi di istanze più grandi, più istanze o più archiviazione basata su EBS, e provare quindi a creare di nuovo gli indici problematici.

Se non è possibile eliminare un indice problematico, puoi ripristinare una snapshot, eliminare documenti dall'indice, modificarne le impostazioni, ridurre il numero di repliche o eliminare altri indici per liberare spazio su disco. La fase importante è quella di risoluzione dello stato rosso del cluster prima di riconfigurare il dominio OpenSearch Service. Riconfigurare un dominio con un cluster in stato rosso può peggiorare il problema e portare al blocco del dominio nello stato di configurazione Processing (Elaborazione) finché lo stato rosso non sarà risolto.

Correzione automatico di cluster rossi

Se lo stato del cluster è rosso continuamente per più di un'ora, OpenSearch Service tenta di correggerlo automaticamente reindirizzando le partizioni non allocate o ripristinando le snapshot precedenti.

Se non riesce a correggere uno o più indici rossi e lo stato del cluster rimane rosso per un totale di 14 giorni, OpenSearch Service interviene ulteriormente solo se il cluster soddisfa almeno uno dei seguenti criteri:

  • Ha una sola zona di disponibilità

  • Non ha nodi principali dedicati

  • Contiene i tipi di istanze espandibili (T2 o T3)

Al momento, se il cluster soddisfa uno di questi criteri, OpenSearch Service invia quotidianamente notifiche nei prossimi 7 giorni spiegando che se non correggi questi indici, tutte le partizioni non assegnate verranno eliminate. Se lo stato del cluster è ancora rosso dopo 21 giorni, OpenSearch Service elimina le partizioni non assegnate (archiviazione e calcolo) su tutti gli indici rossi. Per ciascuno di questi eventi si ricevono notifiche nel pannello Notifications (Notifiche) della console OpenSearch Service. Per ulteriori informazioni, consultare Eventi sull’integrità del cluster.

Ripristino da un carico di elaborazione costantemente elevato

Per determinare se un cluster è in stato rosso a causa di un carico di elaborazione costantemente elevato su un nodo di dati, monitora i seguenti parametri del cluster.

Parametro pertinente Descrizione Ripristino
JVMMemoryPressure

Specifica la percentuale massima dell'heap di Java utilizzata per tutti i nodi di dati in un cluster. Visualizza la statistica Massimo per questo parametro e cerca drop sempre minori nella pressione della memoria mano aman mano che il garbage collector Java riesce a recuperare memoria sufficiente. Questo modello è probabilmente dovuto a query complesse o campi di dati di grandi dimensioni.

I tipi di istanza x86 utilizzano il garbage collector (GC) Concurrent Mark Sweep (CMS), che viene eseguito insieme ai thread dell'applicazione per tenere le pause brevi. Se CMS non è in grado di recuperare memoria sufficiente durante le raccolte normali, attiva una garbage collection (GC) completa, che può portare a lunghe pause dell'applicazione con un impatto sulla stabilità del cluster.

I tipi di istanza Graviton basati su ARM utilizzano il garbage collector (GC) Garbage-First (G1), che è simile a CMS, ma utilizza ulteriori brevi pause e deframmentazione heap per ridurre ulteriormente la necessità di garbage collection complete.

In entrambi i casi, se l'utilizzo della memoria continua a crescere oltre quello che il garbage collector può recuperare durante le garbage collection complete, OpenSearch viene interrotto in maniera anomala e restituisce un errore di memoria insufficiente. Su tutti i tipi di istanza, è preferibile mantenere l'utilizzo al di sotto dell'80%.

L'API _nodes/stats/jvm offre un riepilogo delle statistiche JVM, dell'utilizzo dei pool di memoria e della garbage collection:

GET domain-endpoint/_nodes/stats/jvm?pretty

Imposta interruttori di memoria per JVM. Per ulteriori informazioni, consultare JVM OutOfMemoryError.

Se il problema persiste, elimina indici non necessari, riduci il numero o la complessità delle richieste per il dominio, aggiungi istanze oppure utilizza tipi di istanza di dimensioni maggiori.

CPUUtilization Specifica la percentuale di risorse della CPU utilizzate per i nodi di dati in un cluster. Visualizza la statistica Maximum (Massimo) per questo parametro e cerca un modello continuo di utilizzo elevato. Aggiungi nodi di dati o passa a tipi di istanza più grandi per i nodi di dati esistenti.
Nodi Specifica il numero di nodi in un cluster. Visualizza la statistica Minimum (Minimo) per questo parametro. Questo valore fluttua quando il servizio distribuisce un nuovo parco di istanze per un cluster. Aggiungi nodi di dati.

Stato giallo del cluster

Un cluster in stato giallo indica che le partizioni principali per tutti gli indici sono allocate sui nodi in un cluster, ma che le partizioni di replica per almeno un indice non lo sono. I cluster a nodo singolo inizializzano sempre con stato giallo perché non c'è un altro nodo al quale OpenSearch Service possa assegnare una replica. Per portare il cluster in stato verde, aumenta il numero di nodi. Per ulteriori informazioni, consultare Dimensionamento dei domini Amazon OpenSearch Service.

I cluster a più nodi potrebbero avere brevemente uno stato di cluster giallo dopo la creazione di un nuovo indice o dopo un errore di nodo. Questo stato si risolve automaticamente quando OpenSearch replica i dati nel cluster. Anche la mancanza di spazio su disco può provocare uno stato del cluster giallo; il cluster può distribuire partizioni di replica solo se i nodi dispongono dello spazio su disco per ospitarle.

ClusterBlockException

L'errore ClusterBlockException può presentarsi per i motivi indicati di seguito.

Mancanza di spazio di archiviazione disponibile

Se uno o più nodi nel tuo cluster hanno meno del 20% dello spazio di archiviazione disponibile o meno di 20 GB di spazio di archiviazione, le operazioni di scrittura di base, ad esempio l'aggiunta di documenti e la creazione di indici, possono iniziare a dare errori. Calcolo dei requisiti di archiviazione fornisce una sintesi delle modalità di utilizzo dello spazio su disco da parte di OpenSearch Service.

Per evitare problemi, monitorare il parametro FreeStorageSpace nella console OpenSearch Service e crea allarmi CloudWatch che si attivano quando FreeStorageSpace scende sotto una determinata soglia. GET /_cat/allocation?v fornisce anche un utile riepilogo dell'allocazione delle partizioni e dell'utilizzo del disco. Per risolvere i problemi associati a una mancanza di spazio di archiviazione, ricalibrare il dominio OpenSearch Service in modo che utilizzi tipi di istanza più grandi, più istanze o più archiviazione basata su EBS.

Blocco dei dischi per memoria insufficiente

Quando il parametro JVMMemoryPressure supera il 92% per 30 minuti, OpenSearch Service esegue il trigger di un meccanismo di protezione e blocca tutte le operazioni di scrittura per evitare che il cluster entri in stato rosso. Quando la protezione è attiva, le operazioni di scrittura hanno esito negativo con errore ClusterBlockException, non è possibile creare nuovi indici e viene generato l'errore IndexCreateBlockException.

Quando il parametro JVMMemoryPressure torna all'88% o a valori inferiori per cinque minuti, la protezione viene disattivata e le operazioni di scrittura sul cluster vengono sbloccate.

JVM OutOfMemoryError

Un errore OutOfMemoryError JVM in genere significa che è stato raggiunto uno dei seguenti interruttori JVM.

Interruttore Descrizione Proprietà impostazione cluster
Interruttore padre Percentuale totale di memoria heap JVM consentita per tutti gli interruttori. Il valore di default è 95%. indices.breaker.total.limit
Interruttore campo dati Percentuale di memoria heap JVM consentita per caricare in memoria un singolo campo di dati. Il valore predefinito è 40%. Se vengono caricati dati con campi di grandi dimensioni, è possibile che sia necessario aumentare tale limite. indices.breaker.fielddata.limit
Interruttore richieste Percentuale di memoria heap JVM consentita per le strutture di dati utilizzate nelle risposte a una richiesta di servizio. Il valore predefinito è 60%. Se le richieste di servizio prevedono il calcolo di aggregazioni, è consigliabile aumentare tale limite. indices.breaker.request.limit

Nodi cluster con errori

Le istanze Amazon EC2 potrebbero andare incontro a terminazioni e riavvii imprevisti. Di solito, OpenSearch Service provvede a riavviare i nodi automaticamente, Tuttavia, è possibile che uno o più nodi in un cluster OpenSearch rimangano in una condizione di errore.

Per verificare questa eventualità, aprire il pannello di controllo del dominio nella console OpenSearch Service. Passa alla scheda Integrità del cluster e scegli il parametro Numero totale di nodi. Verifica se il numero di nodi indicati è inferiore al numero che hai configurato per il tuo cluster. Se dal parametro emerge che uno o più nodi restano non disponibili per più di un giorno, contatta AWS Support.

È inoltre possibile impostare un allarme CloudWatch per ricevere una notifica quando si verifica questo problema.

Nota

Il parametro Numero totale di nodi non è preciso durante le modifiche della configurazione del cluster e durante la manutenzione di routine per il servizio. Si tratta di un comportamento normale. Il parametro tornerà a indicare il numero corretto di nodi del cluster a breve. Per ulteriori informazioni, consultare Modifiche alla configurazione in Amazon OpenSearch Service.

Per proteggere i cluster da terminazioni e riavvii imprevisti dei nodi, è necessario creare almeno una replica per ogni indice nel dominio OpenSearch Service.

Limite massimo di partizioni superato

OpenSearch, così come le versioni 7.x di Elasticsearch hanno un'impostazione di default per non più di 1.000 partizioni per nodo. OpenSearch/ElasticSearch genera un errore se una richiesta, ad esempio la creazione di un nuovo indice, provoca il superamento di questo limite. Se si verifica questo errore, sono disponibili diverse opzioni:

  • Aggiungere più nodi di dati al cluster.

  • Aumentare l'impostazione _cluster/settings/cluster.max_shards_per_node.

  • Utilizzare l'API _shrink per ridurre il numero di partizioni sul nodo.

Dominio bloccato nello stato di elaborazione

Il dominio OpenSearch Service entra nello stato "Elaborazione" quando si trova durante una modifica della configurazione. Se si avvia una modifica della configurazione, lo stato del dominio cambia in "Elaborazione" mentre OpenSearch Service crea un nuovo ambiente. Nel nuovo ambiente, OpenSearch Service avvia un nuovo set di nodi applicabili (come dati, principali o UltraWarm). Al termine della migrazione, i nodi più vecchi vengono terminati.

Il cluster può rimanere bloccato nello stato "Elaborazione" se si verifica una di queste situazioni:

  • Un nuovo set di nodi dati non può essere avviato.

  • La migrazione della partizione al nuovo set di nodi dati non riesce.

Per i passaggi di risoluzione dettagliati in ciascuna di queste situazioni, consulta Perché il mio dominio del servizio OpenSearch di Amazon è bloccato nello stato "Elaborazione"?.

Saldo di burst EBS basso

Il servizio OpenSearch ti invia una notifica sulla console quando il saldo di burst EBS di uno dei tuoi volumi a scopo generico (SSD) è inferiore al 70% e una notifica di follow-up se il saldo scende al di sotto del 20%. Per risolvere questo problema, puoi aumentare le dimensioni del cluster o ridurre gli IOPS di lettura e scrittura in modo da poter accreditare il saldo di burst. Puoi monitorare il saldo di burst EBS con il parametro BurstBalance di CloudWatch. Per ulteriori informazioni, consulta General Purpose SSD volumes (gp2) (Volumi SSD a scopo generico [gp2]).

Impossibile abilitare i log di verifica

Quando si prova ad abilitare la pubblicazione del log di verifica utilizzando la console OpenSearch Service è possibile che si manifesti il seguente errore:

La policy di accesso alle risorse specificata per il gruppo di flussi di log di CloudWatch Logs non concede autorizzazioni sufficienti affinché il servizio OpenSearch di Amazon possa creare un flusso di log. Controllare la policy di accesso alle risorse.

Se si verifica questo errore, verificare che l'elemento resource della policy includa l'ARN del gruppo di log corretto. Se lo fa, procedere come indicato di seguito:

  1. Attendere qualche minuto.

  2. Aggiornare la pagina nel browser Web.

  3. Scegli Seleziona gruppo esistente.

  4. Per Gruppo di log esistente, scegliere il gruppo di log creato prima di ricevere il messaggio di errore.

  5. Nella sezione Policy di accesso, scegli Seleziona policy esistente.

  6. Per Policy esistente, scegliere la policy creata prima di ricevere il messaggio di errore.

  7. Scegli Enable (Abilita).

Se l'errore persiste anche dopo aver ripetuto il processo più volte, contattare AWS Support.

Impossibile chiudere l'indice

OpenSearch Service supporta l'API _close solo per OpenSearch ed Elasticsearch versione 7.4 e successive. Se si utilizza una versione più vecchia e si sta ripristinando un indice da uno snapshot, è possibile eliminare l'indice esistente (prima o dopo la reindicizzazione). L'altra possibilità è utilizzare i campi rename_pattern e rename_replacement per rinominare l'indice quando viene ripristinato:

POST /_snapshot/my-repository/my-snapshot/_restore { "indices": "my-index-1,myindex-2", "include_global_state": true, "rename_pattern": "my-index-(\\d)", "rename_replacement": "restored-my-index-$1" }

Se prevedi di reindirizzare, ridurre o suddividere un indice, è opportuno interrompere eventuali operazioni di scrittura su di esso prima di eseguire l'operazione.

Controlli delle licenze client

Le distribuzioni predefinite di Logstash e Beats includono un controllo di licenza proprietario e non riescono a connettersi alla versione open source di OpenSearch. Assicurarsi di utilizzare le distribuzioni Apache 2.0 (OSS) di questi client con OpenSearch Service.

Limitazione delle richieste

Se si ricevono errori 403 Request throttled due to too many requests o 429 Too Many Requests persistenti, considerare il dimensionamento verticale. Il servizio OpenSearch di Amazon limita le richieste se il payload fa sì che l'utilizzo della memoria superi la dimensione massima dell'heap Java.

Impossibile eseguire SSH nel nodo

Non è possibile utilizzare SSH per accedere a uno qualsiasi dei nodi nel cluster OpenSearch e non è possibile modificare direttamente opensearch.yml. Invece, usa la console, AWS CLI o gli SDK per configurare il dominio. È possibile specificare alcune impostazioni a livello di cluster anche utilizzando l'API REST OpenSearch. Per ulteriori informazioni, consultare Riferimento dell'API di configurazione per il servizio OpenSearch di Amazon e Operazioni supportate.

Per maggiori dettagli sulle prestazioni del cluster, è possibile pubblicare log di errori e log lenti in CloudWatch.

Errore snapshot "Non valido per la classe di archiviazione dell'oggetto"

Gli snapshot di OpenSearch Service non supportano la classe di archiviazione S3 Glacier. È possibile che si verifichi questo errore quando si prova a elencare gli snapshot se il bucket S3 include una regola del ciclo di vita che trasferisce gli oggetti alla classe di archiviazione S3 Glacier.

Se è necessario ripristinare uno snapshot dal bucket, ripristinare gli oggetti da S3 Glacier, copiare gli oggetti su un nuovo bucket e registrare il nuovo bucket come archivio di snapshot.

Intestazione dell'host non valida

OpenSearch Service richiede che i client specifichino Host nelle intestazioni della richiesta. A valore Host valido è l'endpoint del dominio senza https://, come:

Host: search-my-sample-domain-ih2lhn2ew2scurji.us-west-2.es.amazonaws.com

Se si riceve un errore Invalid Host Header quando si esegue una richiesta, controllare che il client includa l'endpoint del dominio OpenSearch Service (e non, ad esempio, il relativo indirizzo IP) nell'intestazione Host.

Tipo di istanza M3 non valido

OpenSearch Service non supporta l'aggiunta o la modifica di istanze M3 in domini esistenti che eseguono OpenSearch o Elasticsearch versioni 6.7 o successive. È possibile continuare a utilizzare le istanze M3 con Elasticsearch 6.5 e versioni precedenti.

Si consiglia di scegliere un tipo di istanza più recente. Per i domini che eseguono OpenSearch o Elasticsearch 6.7 e versioni successive, si applicano le seguenti restrizioni:

  • Se il dominio esistente non utilizza istanze M3, non è più possibile passare a tali istanze.

  • Se si modifica un dominio esistente da un tipo di istanza M3 a un altro tipo di istanza, non è possibile tornare indietro.

Le query hot smettono di funzionare dopo aver abilitato UltraWarm

Quando si abilita UltraWarm in un dominio, se non ci sono sostituzioni preesistenti all'impostazione search.max_buckets, OpenSearch Service imposta automaticamente il valore su 10000 per evitare che le query con molta memoria saturino i nodi a caldo. Se le hot query utilizzano più di 10.000 bucket, potrebbero smettere di funzionare quando si attiva UltraWarm.

Poiché non è possibile modificare questa impostazione a causa della natura gestita del servizio OpenSearch di Amazon, è necessario aprire un caso di supporto per aumentare il limite. Gli aumenti di limite non richiedono un abbonamento Premium Support.

Impossibile eseguire il downgrade dopo l'aggiornamento

Gli aggiornamenti locali sono irreversibili, ma se si contatta il AWS Supporto, è possibile ripristinare lo snapshot automatico pre-aggiornamento in un nuovo dominio. Ad esempio, se si esegue l'aggiornamento di un dominio da Elasticsearch 5.6 a 6.4, AWS Support consente può ripristinare lo snapshot pre-aggiornamento in un nuovo dominio Elasticsearch 5.6. Se dal dominio originale è stato preso uno snapshot manuale, è possibile eseguire questa fase da soli.

È necessario il riepilogo dei domini di tutte le Regioni AWS

Lo script seguente utilizza il comando della AWS CLI describe-regions di Amazon EC2 per creare un elenco di tutte le regioni in cui potrebbe essere disponibile OpenSearch Service. Quindi richiama list-domain-names per ciascuna regione:

for region in `aws ec2 describe-regions --output text | cut -f4` do echo "\nListing domains in region '$region':" aws opensearch list-domain-names --region $region --query 'DomainNames' done

Per ogni regione si riceve il seguente output:

Listing domains in region:'us-west-2'... [ { "DomainName": "sample-domain" } ]

Le regioni in cui OpenSearch Service non è disponibile restituiscono il messaggio "Impossibile connettersi all'URL dell'endpoint".

Errore del browser durante l'utilizzo di OpenSearch Dashboards

Quando si utilizza Dashboards per visualizzare i dati nel dominio OpenSearch Service, il browser esegue il wrapping dei messaggi di errore del servizio in oggetti di risposta HTTP. Puoi usare gli strumenti di sviluppo comunemente disponibili nei Web browser, ad esempio la modalità di sviluppo in Chrome, per visualizzare gli errori del servizio sottostanti e semplificare le attività di debug.

Per visualizzare gli errori del servizio in Chrome

  1. Dalla barra dei menu principale di Chrome, scegliere Visualizza, Sviluppatore, Strumenti per gli sviluppatori.

  2. Scegliere la scheda Network (Rete).

  3. Nella colonna Status (Stato) scegliere qualsiasi sessione HTTP con stato 500.

Per visualizzare gli errori del servizio in Firefox

  1. Dal menu scegliere Tools (Strumenti), Web Developer (Sviluppatore Web), Network (Rete).

  2. Scegliere qualsiasi sessione HTTP con stato 500.

  3. Scegliere la scheda Response (Risposta) per visualizzare la risposta del servizio.

Asimmetria di partizioni e storage di nodi

L'asimmetria di partizioni di nodi si verifica quando uno o più nodi all'interno di un cluster presentano un numero significativamente maggiore di partizioni rispetto agli altri nodi. L'asimmetria di storage di nodi si verifica quando uno o più nodi all'interno di un cluster presentano una quantità di storage significativamente maggiore (disk.indices) rispetto agli altri nodi. Sebbene entrambe queste condizioni possano verificarsi temporaneamente, ad esempio quando un dominio ha sostituito un nodo e sta ancora allocando partizioni su quel nodo, se persistono, devono essere risolte.

Per identificare entrambi i tipi di asimmetria, esegui l'operazione API _cat/allocation e confronta le voci shards e disk.indices nella risposta:

shards | disk.indices | disk.used | disk.avail | disk.total | disk.percent | host | ip | node 264 | 465.3mb | 229.9mb | 1.4tb | 1.5tb | 0 | x.x.x.x | x.x.x.x | node1 115 | 7.9mb | 83.7mb | 49.1gb | 49.2gb | 0 | x.x.x.x | x.x.x.x | node2 264 | 465.3mb | 235.3mb | 1.4tb | 1.5tb | 0 | x.x.x.x | x.x.x.x | node3 116 | 7.9mb | 82.8mb | 49.1gb | 49.2gb | 0 | x.x.x.x | x.x.x.x | node4 115 | 8.4mb | 85mb | 49.1gb | 49.2gb | 0 | x.x.x.x | x.x.x.x | node5

Sebbene alcune asimmetrie di storage siano normali, qualsiasi valore superiore al 10% rispetto alla media è significativo. Quando la distribuzione delle partizioni è asimmetrica, anche l'utilizzo della CPU, della rete e della larghezza di banda del disco può essere asimmetrico. Poiché un maggior numero di dati significa in genere un maggior numero di operazioni di indicizzazione e ricerca, i nodi più pesanti tendono ad essere anche quelli con maggiori risorse, mentre i nodi più leggeri rappresentano una capacità sottoutilizzata.

Correzione: utilizza conteggi di partizioni che siano multipli del numero di nodi di dati per garantire che ogni indice sia distribuito uniformemente tra i nodi di dati.

Asimmetria di partizioni e storage di indici

L'asimmetria di partizioni di indici si verifica quando uno o più nodi contengono più partizioni di un indice rispetto agli altri nodi. L'asimmetria di storage di indici si verifica quando uno o più nodi contengono una quantità sproporzionatamente elevata di storage totale di un indice.

L'asimmetria di indici è più difficile da identificare rispetto all'asimmetria di nodi perché richiede una certa manipolazione dell'output dell'API _cat/shards. Esamina l'asimmetria di indici per verificare se esiste qualche indicazione di asimmetria nei parametri del cluster o del nodo. Di seguito sono riportate le indicazioni comuni dell'asimmetria di indici:

  • Errori HTTP 429 che si verificano su un sottoinsieme di nodi di dati

  • Accodamento non uniforme delle operazioni di indicizzazione o di ricerca tra i nodi di dati

  • Utilizzo non uniforme dell'heap della JVM e/o della CPU tra i nodi di dati

Correzione: utilizza conteggi di partizioni che siano multipli del numero di nodi di dati per garantire che ogni indice sia distribuito uniformemente tra i nodi di dati. Se è ancora presente un'asimmetria di partizioni o storage di indici, potrebbe essere necessario forzare una riallocazione delle partizioni, che si verifica con ogni implementazione blu/verde del dominio del servizio OpenSearch.

Operazione non autorizzata dopo la selezione dell'accesso VPC

Quando si crea un nuovo dominio usando la console OpenSearch Service, è possibile scegliere tra accesso pubblico o accesso VPC. Se si seleziona Accesso VPC, OpenSearch Service esegue una query per informazioni VPC e non va a buon fine se non si dispone delle autorizzazioni corrette:

You are not authorized to perform this operation. (Service: AmazonEC2; Status Code: 403; Error Code: UnauthorizedOperation

Per permettere questa query, è necessario disporre di accesso alle operazioni ec2:DescribeVpcs, ec2:DescribeSubnets ed ec2:DescribeSecurityGroups. Questo requisito riguarda solo la console. Se si utilizza AWS CLI per creare e configurare un dominio con un endpoint VPC, non è necessario accedere a tali operazioni.

Caricamento bloccato dopo la creazione di un dominio VPC

Dopo aver creato un nuovo dominio che usa l'accesso VPC, il valore di Configuration state (Stato di configurazione) del dominio potrebbe non andare mai oltre Loading (Caricamento). Se si verifica questo problema, è probabile che AWS Security Token Service (AWS STS) sia disabilitato per la tua regione.

Per aggiungere endpoint VPC al VPC, OpenSearch Service deve assumere il ruolo AWSServiceRoleForAmazonOpenSearchService. Pertanto, AWS STS deve essere abilitato per creare nuovi domini che usano l'accesso VPC in una determinata regione. Per ulteriori informazioni su come abilitare e disabilitare AWS STS, consultare la Guida per l'utente di IAM.

Richieste negate all'API OpenSearch

Con l'introduzione del controllo degli accessi basato su tag per l'API OpenSearch, è possibile che si verifichino errori di accesso negato che prima non si verificavano. Ciò potrebbe essere dovuto al fatto che una o più policy di accesso contiene Deny che usa la condizione ResourceTag e tali condizioni ora sono soddisfatte.

Ad esempio, la policy seguente utilizzata per negare l'accesso solo all'azione CreateDomain dall'API di configurazione, se il dominio aveva il tag environment=production. Anche se l'elenco delle azioni include anche ESHttpPut, la dichiarazione di negazione non si applicava a tale o ad altre azioni ESHttp*.

{ "Version": "2012-10-17", "Statement": [{ "Action": [ "es:CreateDomain", "es:ESHttpPut" ], "Effect": "Deny", "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:ResourceTag/environment": [ "production" ] } } }] }

Con l'aggiunta del supporto di tag per i metodi HTTP OpenSearch, una policy basata sull'identità IAM come la precedente causerà il rifiuto dell'accesso all'azione ESHttpPut all'utente collegato. In precedenza, in assenza di convalida di tag, l'utente collegato poteva comunque inviare richieste PUT.

Se inizi a scoprire errori di accesso negato dopo aver aggiornato i domini al software di servizio R20220323 o versioni successive, controlla le policy di accesso basate sull'identità per verificare se il problema è questo e aggiornali, se necessario, per consentire l'accesso.

Impossibile connettersi da Alpine Linux

Alpine Linux limita la dimensione della risposta DNS a 512 byte. Se si prova di connettersi al dominio OpenSearch Service da Alpine Linux, la risoluzione DNS può fallire se il dominio si trova in un VPC e ha più di 20 nodi. Se il proprio dominio è in un VPC, si consiglia di usare altre distribuzioni Linux, come Debian, Ubuntu, CentOS, Red Hat Enterprise Linux o Amazon Linux 2, per connettersi a esso.

Errore di certificato quando si utilizza un SDK

Poiché gli SDK AWS utilizzano i certificati CA del computer, le modifiche ai certificati sui server AWS possono causare errori di connessione quando si tenta di utilizzare un SDK. I messaggi di errore variano, ma in genere contengono il testo seguente:

Failed to query OpenSearch ... SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

È possibile evitare che si verifichino tali errori mantenendo aggiornati i certificati CA e il sistema operativo del computer. Se si riscontra questo problema in un ambiente aziendale e non si gestisce il computer in uso, potrebbe essere necessario richiedere all'amministratore assistenza con il processo di aggiornamento.

Nell'elenco seguente vengono riportati i requisiti minimi del sistema operativo e delle versioni di Java:

  • Le versioni di Microsoft Windows con aggiornamenti installati da gennaio 2005 in poi contengono nell'elenco di certificati attendibili almeno uno dei CA richiesti.

  • Mac OS X 10.4 con Java per Mac OS X 10.4 release 5 (febbraio 2007), Mac OS X 10.5 (ottobre 2007) e versioni successive contengono nell'elenco di certificati attendibili almeno uno dei CA richiesti.

  • Red Hat Enterprise Linux 5 (marzo 2007), 6 e 7 e CentOS 5, 6 e 7 contengono nell'elenco di certificati attendibili almeno uno dei CA richiesti.

  • Java 1.4.2_12 (maggio 2006), 5 aggiornamento 2 (marzo 2005) e tutte le versioni successive, incluso Java 6 (dicembre 2006), 7 e 8, contengono nell'elenco di certificati attendibili almeno uno dei CA richiesti.

Le tre autorità di certificazione sono:

  • Autorità di certificazione root Amazon 1

  • Autorità di certificazione root dei servizi Starfield - G2

  • Autorità di certificazione Starfield classe 2

I certificati root delle prime due autorità sono disponibili in Amazon Trust Services; tuttavia, la soluzione più semplice è mantenere aggiornato il computer. Per ulteriori informazioni sui certificati forniti da ACM, consulta le Domande frequenti su AWS Certificate Manager.

Nota

Attualmente, i domini OpenSearch Service nella regione us-east-1 usano certificati di una diversa autorità. Prevediamo di aggiornare la regione per l'uso di queste nuove autorità di certificazione in futuro.