Risoluzione dei problemi del OpenSearch servizio Amazon

Questo argomento descrive come identificare e risolvere i problemi più comuni OpenSearch di Amazon Service. Consulta le informazioni contenute in questa sezione prima di contattare AWS Support.

Impossibile accedere alle OpenSearch dashboard

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

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

Se il tuo dominio di OpenSearch servizio utilizza l'accesso VPC, potresti non ricevere questo errore, ma la richiesta potrebbe scadere. Per ulteriori informazioni su come correggere questo problema e le varie opzioni di configurazione disponibili, consulta Controllo dell'accesso ai OpenSearch dashboard, Informazioni sulle policy d'accesso nei domini VPC e Gestione delle identità e degli accessi in AmazonOpenSearchServizio.

Impossibile accedere al dominio VPC

Consultare 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 usa un sistema diverso per il coordinamento dei 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 di quorum e il cluster ha più di un nodo, OpenSearch Service ripristina il quorum e imposta il cluster in uno stato di sola lettura. Sono disponibili due opzioni:

• Rimuovi lo stato di sola lettura e utilizza il cluster così com'è.

• Ripristina il cluster o i singoli indici da uno snapshot.

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 di quorum e il cluster ha un solo nodo, OpenSearch Service sostituisce il nodo e non pone 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 il servizio invia due eventi al tuo AWS Health Dashboard. Il primo segnala la perdita del quorum. Il secondo si verifica dopo che il OpenSearch Servizio ha ripristinato con successo 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. OpenSearchIl servizio continua a cercare di scattare istantanee automatiche di tutti gli indici indipendentemente dal loro stato, ma le istantanee falliscono mentre lo stato del cluster rosso persiste.

Le cause più comuni di questa condizione sono nodi del cluster con errori e crash del processo OpenSearch causato da un carico di elaborazione costantemente elevato.

Nota

OpenSearchIl servizio archivia le istantanee automatiche 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 tuo dominio di OpenSearch servizio inserisce lo stato di cluster rosso, AWS Support potresti contattarti per chiederti se desideri risolvere il problema da solo o se desideri che il team di supporto ti assista. Puoi impostare un allarme CloudWatch per ricevere una notifica quando si verifica questa situazione.

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

• 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 dello stato di cluster rosso, potresti quindi ridimensionare il tuo dominio di OpenSearch servizio per utilizzare tipi di istanze più grandi, più istanze o più storage basato su EBS e provare a ricreare 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. Il passaggio importante consiste nel risolvere lo stato del cluster rosso prima di riconfigurare il dominio di OpenSearch servizio. 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 è continuamente rosso per più di un'ora, il OpenSearch servizio tenta di correggerlo automaticamente reindirizzando gli shard non allocati o ripristinando gli 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, il OpenSearch servizio 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 tuo cluster soddisfa uno di questi criteri, il OpenSearch Servizio ti invia notifiche giornaliere nei prossimi 7 giorni spiegando che se non correggi questi indici, tutti gli shard non assegnati verranno eliminati. Se lo stato del cluster è ancora rosso dopo 21 giorni, il OpenSearch servizio elimina gli shard non assegnati (archiviazione ed elaborazione) su tutti gli indici rossi. Riceverai notifiche nel pannello Notifiche della Console di OpenSearch assistenza per ciascuno di questi eventi. Per ulteriori informazioni, consulta 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
JVM MemoryPressure	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 superare quello che il Garbage Collector può recuperare durante le raccolte complete, si OpenSearch blocca con un errore di memoria esaurita. 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, consulta 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 vengono sempre inizializzati con uno stato di cluster giallo perché non esiste nessun altro nodo a cui il OpenSearch servizio può 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 i dati vengono OpenSearch replicati 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 del cluster hanno uno spazio di archiviazione inferiore al valore minimo di 1) 20% dello spazio di archiviazione disponibile o 2) 20 GB di spazio di archiviazione, le operazioni di scrittura di base come l'aggiunta di documenti e la creazione di indici possono iniziare a fallire. Calcolo dei requisiti di archiviazionefornisce un riepilogo di come il OpenSearch Servizio utilizza lo spazio su disco.

Per evitare problemi, monitora la FreeStorageSpace metrica nella console di OpenSearch assistenza e crea CloudWatch allarmi da attivare quando FreeStorageSpace scende al di sotto di una determinata soglia. GET /_cat/allocation?vfornisce anche un utile riepilogo dell'allocazione degli shard e dell'utilizzo del disco. Per risolvere i problemi associati alla mancanza di spazio di archiviazione, ridimensiona il tuo dominio di OpenSearch servizio per utilizzare tipi di istanze più grandi, più istanze o più storage basato su EBS.

Pressione di memoria JVM elevata

Quando la MemoryPressure metrica JVM supera il 92% per 30 minuti, OpenSearch Service attiva un meccanismo di protezione e blocca tutte le operazioni di scrittura per impedire al cluster di raggiungere lo 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 la MemoryPressure metrica JVM torna all'88% o inferiore per cinque minuti, la protezione viene disabilitata e le operazioni di scrittura sul cluster vengono sbloccate.

Una pressione della memoria JVM elevata può essere causata da picchi nel numero di richieste al cluster, allocazioni di partizioni sbilanciate tra i nodi, troppe partizioni in un cluster, esplosioni di dati di campo o di mappatura degli indici o tipi di istanze che non sono in grado di gestire i carichi in ingresso. Può essere causata anche dall'utilizzo di aggregazioni, caratteri jolly o ampi intervalli temporali nelle query.

Per ridurre il traffico verso il cluster e risolvere problemi di pressione della memoria JVM elevata, prova una o più delle seguenti operazioni:

• Scala il dominio in modo che la dimensione massima dell'heap per nodo sia di 32 GB.

• Riduci il numero di partizioni eliminando gli indici vecchi o inutilizzati.

• Cancella la cache dei dati con l'operazione API POST index-name/_cache/clear?fielddata=true. Tieni presente che la cancellazione della cache può interrompere le query in corso.

In generale, per evitare una pressione della memoria JVM elevata in futuro, segui queste best practice:

• Evita l'aggregazione su campi di testo o modifica il tipo mappatura per i tuoi indici in keyword.

• Ottimizza le richieste di ricerca e indicizzazione scegliendo il numero corretto di partizioni.

• Imposta le policy ISM (Index State Management) per rimuovere gli indici inutilizzati con regolarità.

Errore durante la migrazione a Multi-AZ con Standby

I seguenti problemi possono verificarsi quando si esegue la migrazione di un dominio esistente a Multi-AZ con standby.

Creazione di un indice, di un modello di indice o di una politica ISM durante la migrazione da domini senza standby a domini con standby

Se si crea un indice durante la migrazione di un dominio da Multi-AZ senza Standby a Standby e il modello di indice o la policy ISM non seguono le linee guida consigliate per la copia dei dati, ciò può causare un'incoerenza dei dati e la migrazione potrebbe non riuscire. Per evitare questa situazione, crea il nuovo indice con un numero di copie di dati (inclusi i nodi primari e le repliche) multiplo di tre. Puoi controllare l'avanzamento della migrazione utilizzando l'API. DescribeDomainChangeProgress Se riscontri un errore nel conteggio delle repliche, correggi l'errore e contatta l'AWSassistenza per riprovare la migrazione.

Numero errato di copie dei dati

Se non disponi del numero corretto di copie dei dati nel tuo dominio, la migrazione a Multi-AZ con Standby avrà esito negativo.

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. In genere, OpenSearch Service riavvia i nodi automaticamente. ma è possibile che uno o più nodi in un cluster OpenSearch rimangano in una condizione di errore.

Per verificare questa condizione, apri la dashboard del dominio nella Console di OpenSearch assistenza. 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.

Puoi anche 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, consulta Apportare modifiche alla configurazione in AmazonOpenSearchServizio.

Per proteggere i cluster da terminazioni e riavvii imprevisti dei nodi, crea almeno una replica per ogni indice nel tuo dominio di servizio. OpenSearch

Limite massimo di partizioni superato

OpenSearcholtre a 7. Le versioni x di Elasticsearch hanno un'impostazione predefinita di non più di 1.000 shard per nodo. OpenSearch/Elasticsearch genera un errore se una richiesta, ad esempio la creazione di un nuovo indice, causa 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 tuo dominio di OpenSearch servizio entra nello stato «Elaborazione» quando è nel bel mezzo di una modifica alla configurazione. Quando si avvia una modifica alla configurazione, lo stato del dominio diventa «In elaborazione» mentre il OpenSearch servizio crea un nuovo ambiente. Nel nuovo ambiente, OpenSearch Service lancia un nuovo set di nodi applicabili (come dati, master oUltraWarm). 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 di dati non può essere avviato.

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

• Il controllo di convalida non è riuscito con errori.

Per i passaggi di risoluzione dettagliati in ognuna di queste situazioni, consulta Perché il mio dominio Amazon OpenSearch Service è bloccato nello stato «In elaborazione»? .

Saldo di burst EBS basso

OpenSearchIl servizio invia una notifica sulla console quando il saldo EBS Burst su uno dei tuoi volumi General Purpose (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. Il saldo di espansione rimane a 0 per i domini con tipi di volumi gp3 e i domini con volumi gp2 con una dimensione del volume superiore a 1.000 GiB. Per ulteriori informazioni, consulta General Purpose SSD volumes (gp2) (Volumi SSD a scopo generico [gp2]). Puoi monitorare il saldo delle raffiche EBS con la metrica. BurstBalance CloudWatch

Impossibile abilitare i log di verifica

È possibile che si verifichi il seguente errore quando si tenta di abilitare la pubblicazione del registro di controllo utilizzando la console OpenSearch di servizio:

La politica di accesso alle risorse specificata per il gruppo di log CloudWatch Logs non concede autorizzazioni sufficienti ad Amazon OpenSearch Service per 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

OpenSearchIl servizio supporta l'_closeAPI solo per le versioni 7.4 OpenSearch e successive di Elasticsearch. 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).

Controlli delle licenze client

Le distribuzioni predefinite di Logstash e Beats includono un controllo della licenza proprietaria e non riescono a connettersi alla versione open source di. OpenSearch Assicurati 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. Amazon OpenSearch Service 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 puoi utilizzare SSH per accedere a uno qualsiasi dei nodi nel cluster OpenSearch e non puoi modificare direttamente opensearch.yml. Invece, usa la console, AWS CLI o gli SDK per configurare il dominio. Puoi specificare alcune impostazioni a livello di cluster utilizzando l'API REST OpenSearch. Per ulteriori informazioni, consulta Amazon OpenSearch Service API Reference eOperazioni supportate in Amazon OpenSearch Service.

Per ulteriori dettagli sulle prestazioni del cluster, puoi pubblicare log di errori e visualizzare log in CloudWatch.

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

OpenSearchLe istantanee del servizio 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

OpenSearchIl servizio richiede che i client lo Host specifichino 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 ricevi un Invalid Host Header errore quando effettui una richiesta, controlla che il tuo client o proxy includa l'endpoint del dominio del OpenSearch servizio (e non, ad esempio, il suo indirizzo IP) nell'Hostintestazione.

Tipo di istanza M3 non valido

OpenSearchIl servizio non supporta l'aggiunta o la modifica di istanze M3 ai domini esistenti in esecuzione OpenSearch o alle versioni 6.7 e successive di Elasticsearch. È 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 Elasticsearch 6.7 o 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 hot query smettono di funzionare dopo l'attivazione UltraWarm

Quando si abilita UltraWarm su un dominio, se non sono presenti sostituzioni preesistenti all'search.max_bucketsimpostazione, OpenSearch Service imposta automaticamente il valore per 10000 evitare che le query che richiedono molta memoria saturino i nodi caldi. Se le tue hot query utilizzano più di 10.000 bucket, potrebbero smettere di funzionare quando le abiliti. UltraWarm

Poiché non puoi modificare questa impostazione a causa della natura gestita di Amazon OpenSearch Service, devi aprire una richiesta di assistenza 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 AWS CLI comando describe-regions di Amazon EC2 per creare un elenco di tutte le regioni in cui il OpenSearch servizio potrebbe essere disponibile. Quindi richiede list-domain-namesper ogni 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 il servizio non è disponibile restituiscono «Impossibile connettersi all'URL dell'endpoint».

Errore del browser durante l'utilizzo delle OpenSearch dashboard

Il tuo browser inserisce i messaggi di errore del servizio negli oggetti di risposta HTTP quando utilizzi i dashboard per visualizzare i dati nel tuo OpenSearch dominio di servizio. 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 la memorizzazione degli indici o lo shard skew persistono, potrebbe essere necessario forzare una riallocazione degli shard, che si verifica con ogni distribuzione blu/verde del dominio del servizio. OpenSearch

Operazione non autorizzata dopo la selezione dell'accesso VPC

Quando crei un nuovo dominio utilizzando la console di OpenSearch servizio, hai la possibilità di selezionare VPC o accesso pubblico. Se si seleziona l'accesso VPC, il OpenSearch servizio richiede informazioni sul cloud privato virtuale e fallisce se non si dispone delle autorizzazioni appropriate:

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 tuo 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'OpenSearchAPI

Con l'introduzione del controllo degli accessi basato su tag per l'OpenSearchAPI, potresti iniziare a vedere errori di accesso negato laddove non lo facevi prima. 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 dei tag per i metodi OpenSearch HTTP, una politica basata sull'identità IAM come quella sopra riportata comporterà il rifiuto dell'accesso all'azione all'utente collegato. ESHttpPut 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 provi a connetterti al tuo dominio di OpenSearch servizio da Alpine Linux versione 3.18.0 o precedente, la risoluzione DNS può fallire se il dominio si trova in un VPC e ha più di 20 nodi. Se utilizzi Alpine Linux versione 3.18.0 o superiore, dovresti essere in grado di risolvere più di 20 host. Per ulteriori informazioni, consultate le note di rilascio di Alpine Linux 3.18.0.

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.

Troppe richieste per Search Backpressure

Il controllo degli accessi basato su CPU è un meccanismo di gatekeeping che limita in modo proattivo il numero di richieste a un nodo in base alla sua capacità attuale, sia per aumenti organici che per picchi di traffico. Le richieste eccessive restituiscono un codice di stato HTTP 429 «Too Many Requests» in caso di rifiuto. Questi errori indicano risorse del cluster insufficienti, richieste di ricerca ad alta intensità di risorse o un picco involontario del carico di lavoro.

Search Backpressure fornisce il motivo del rifiuto, che può aiutare a ottimizzare le richieste di ricerca che richiedono molte risorse. Per i picchi di traffico, consigliamo di ripetere i tentativi lato client con backoff e jitter esponenziali.

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 prevenire questi errori conservando i certificati CA e il sistema up-to-date 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 presso Amazon Trust Services, ma conservare il computer up-to-date è la soluzione più semplice. Per ulteriori informazioni sui certificati forniti da ACM, consulta le Domande frequenti su AWS Certificate Manager.

Nota

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