Risoluzione dei problemi con Amazon OpenSearch Service

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 dashboard OpenSearch , Informazioni sulle policy d'accesso nei domini VPC e Identity and Access Management in Amazon OpenSearch Service.

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 ed Elasticsearch 7 OpenSearch . x utilizza 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 del 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 del 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 Service 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 correttamente il quorum. Per ulteriori informazioni sull'utilizzo di AWS Health Dashboard, consulta la Guida per l'AWS Health utente.

Cluster in stato rosso

Lo stato rosso del cluster indica che almeno uno shard primario e le relative repliche non sono allocati a un nodo. OpenSearch Il servizio continua a cercare di scattare istantanee automatiche di tutti gli indici indipendentemente dal loro stato, ma le istantanee falliscono finché persiste lo stato rosso del cluster.

Le cause più comuni dello stato rosso del cluster sono l'errore dei nodi del cluster e l'arresto anomalo del OpenSearch processo a causa di un carico di elaborazione continuo e intenso.

Nota

OpenSearch Il servizio archivia le istantanee automatizzate 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 del OpenSearch servizio assume lo stato di cluster rosso, AWS Support potresti contattarti per chiederti se desideri risolvere il problema da solo o se desideri ricevere assistenza dal team di supporto. Puoi impostare un CloudWatch allarme per avvisarti quando si verifica lo stato di un cluster rosso.

In definitiva, partizioni rosse causano cluster rossi e indici rossi causano partizioni rosse. Per identificare gli indici che causano lo stato rosso del cluster, 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 del cluster rosso, è possibile ridimensionare il dominio di OpenSearch servizio in modo da 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 rosso del cluster prima di riconfigurare il dominio di servizio. OpenSearch 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 le istantanee 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 intraprende ulteriori azioni 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, il OpenSearch Servizio invia notifiche giornaliere nei prossimi 7 giorni per spiegare 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 e calcolo) su tutti gli indici rossi. Riceverai notifiche nel pannello Notifiche della console di OpenSearch servizio 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 crescere oltre i limiti che il Garbage Collector può recuperare durante le Garbage Collection complete, OpenSearch si 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 si inizializzano sempre con uno stato di cluster giallo perché non esiste nessun altro nodo a cui Service può assegnare una replica. OpenSearch 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 durante la replica dei dati nel cluster. OpenSearch 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 GiB 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 servizio e crea CloudWatch allarmi da attivare quando FreeStorageSpace scende al di sotto di una certa 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 dominio del 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 evitare che il cluster raggiunga 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 meno 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 potrebbero verificarsi quando si migra un dominio esistente su Multi-AZ in modalità 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 con Standby e il modello di indice o la politica ISM non seguono le linee guida consigliate sulla 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 dei dati (compresi i nodi primari e le repliche) multiplo di tre. Puoi controllare l'avanzamento della migrazione utilizzando l'API. DescribeDomainChangeProgress Se si verifica un errore di conteggio delle repliche, correggilo e contatta l'AWS assistenza 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. Tuttavia, è possibile che uno o più nodi di un OpenSearch cluster rimangano in una condizione di errore.

Per verificare questa condizione, apri la dashboard del dominio nella console OpenSearch di servizio. 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 CloudWatch allarme per avvisarti 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 Amazon OpenSearch Service.

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

Limite massimo di partizioni superato

OpenSearch oltre 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, comporta 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 del OpenSearch servizio entra nello stato «Elaborazione» quando è nel bel mezzo di una modifica della configurazione. Quando si avvia una modifica alla configurazione, lo stato del dominio passa a «Elaborazione» mentre il OpenSearch Servizio crea un nuovo ambiente. Nel nuovo ambiente, OpenSearch Service lancia un nuovo set di nodi applicabili (come data, master 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 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 ciascuna di queste situazioni, consulta Perché il mio dominio Amazon OpenSearch Service è bloccato nello stato «Elaborazione»? .

Saldo di burst EBS basso

OpenSearch Il servizio ti invia una notifica sulla console quando il saldo di burst EBS 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 burst balance di EBS con la metrica. BurstBalance CloudWatch

Impossibile abilitare i log di verifica

Potresti riscontrare il seguente errore quando tenti di abilitare la pubblicazione dei registri di controllo utilizzando la OpenSearch console 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

OpenSearch Il 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 Service. OpenSearch

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 usare SSH per accedere a nessuno dei nodi del tuo OpenSearch cluster e non puoi modificarlo direttamente. opensearch.yml Utilizza invece la console o gli AWS CLI SDK per configurare il tuo dominio. Puoi specificare alcune impostazioni a livello di cluster anche utilizzando le API OpenSearch REST. Per ulteriori informazioni, consulta Amazon OpenSearch Service API Reference eOperazioni supportate in Amazon OpenSearch Service.

Se hai bisogno di maggiori informazioni sulle prestazioni del cluster, puoi pubblicare i log degli errori e gli slow log su. CloudWatch

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

OpenSearch Le istantanee del servizio non supportano la classe di storage 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 Il servizio richiede che i client lo 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 ricevi un Invalid Host Header errore durante la richiesta, verifica che il client o il proxy includa l'endpoint del dominio OpenSearch Service (e non, ad esempio, il relativo indirizzo IP) nell'Hostintestazione.

Tipo di istanza M3 non valido

OpenSearch Il servizio non supporta l'aggiunta o la modifica di istanze M3 a domini esistenti che eseguono OpenSearch o eseguono versioni di Elasticsearch 6.7 e 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 Elasticsearch 6.7 OpenSearch 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 evitare che le query che richiedono molta memoria 10000 saturino i nodi caldi. Se le tue hot query utilizzano più di 10.000 bucket, potrebbero smettere di funzionare quando 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 aggiorni un dominio da Elasticsearch 5.6 a 6.4, AWS Support può aiutarti a ripristinare lo snapshot precedente all'aggiornamento su 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 Amazon EC2 describe-regions per creare un elenco di tutte le regioni in cui OpenSearch il servizio potrebbe essere disponibile. Quindi chiama per ogni regione list-domain-names:

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 il OpenSearch servizio non è disponibile restituiscono «Impossibile connettersi all'URL dell'endpoint».

Errore del browser durante l'utilizzo OpenSearch delle dashboard

Il browser inserisce i messaggi di errore del servizio negli oggetti di risposta HTTP quando si utilizzano le dashboard per visualizzare i dati nel dominio del servizio. OpenSearch 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 dell'indice o lo shard skew persistono, potrebbe essere necessario forzare la riallocazione degli shard, operazione che si verifica con ogni distribuzione blu/verde del dominio di 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 Accesso VPC, il OpenSearch servizio richiede informazioni sul VPC 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 utilizzi la 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, probabilmente hai disabilitato AWS Security Token Service (AWS STS) per la tua regione.

Per aggiungere endpoint VPC al tuo VPC, OpenSearch Service deve assumere il ruolo. AWSServiceRoleForAmazonOpenSearchService Pertanto, AWS STS deve essere abilitato a creare nuovi domini che utilizzano l'accesso VPC in una determinata regione. Per ulteriori informazioni sull'attivazione e la disabilitazione AWS STS, consulta la IAM User Guide.

Richieste rifiutate all'API OpenSearch

Con l'introduzione del controllo degli accessi basato su tag per l' OpenSearch API, potresti iniziare a vedere errori di accesso negato dove 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 il supporto aggiunto dei tag per i metodi OpenSearch HTTP, una policy 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 tenti di 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 una versione di Alpine Linux successiva alla 3.18.0, dovresti essere in grado di risolvere più di 20 host. Per ulteriori informazioni, consulta 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 sulla CPU è un meccanismo di controllo che limita in modo proattivo il numero di richieste a un nodo in base alla sua capacità attuale, sia in caso di aumenti organici che di picchi di traffico. Un numero eccessivo di richieste restituisce un codice di stato HTTP 429 «Troppe richieste» in caso di rifiuto. Questi errori indicano risorse di cluster insufficienti, richieste di ricerca che richiedono molte 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. In caso di picchi di traffico, consigliamo di ripetere i tentativi sul lato client con backoff e jitter esponenziali.

Errore di certificato quando si utilizza un SDK

Poiché AWS gli SDK utilizzano i certificati CA del tuo computer, le modifiche ai certificati sui AWS server possono causare errori di connessione quando tenti 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

Puoi prevenire questi errori conservando i certificati CA e il sistema operativo del tuo computer. up-to-date 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 mantenere 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.