Résolution des problèmes liés à Amazon OpenSearch Service

Cette rubrique explique comment identifier et résoudre les problèmes courants d'Amazon OpenSearch Service. Consultez les informations de cette section avant de contacter Support AWS.

Impossible d'accéder aux OpenSearch tableaux de bord

Le point de terminaison OpenSearch Dashboards ne prend pas en charge les demandes signées. Si la stratégie de contrôle d'accès de votre domaine n'accorde l'accès qu'à certains rôles IAM et que vous n'avez pas configuré l'authentification Amazon Cognito, vous pouvez recevoir l'erreur suivante lorsque vous tentez d'accéder à Dashboards :

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

Si votre domaine OpenSearch de service utilise l'accès VPC, il se peut que vous ne receviez pas cette erreur, mais la demande peut expirer. Pour en savoir plus sur la correction ce problème et les différentes options de configuration disponibles Contrôle de l'accès aux tableaux de bord , consultez À propos des politiques d'accès aux VPC domaines et Identity and Access Management dans Amazon OpenSearch Service.

Impossible d'accéder au domaine VPC

Consultez À propos des politiques d'accès aux VPC domaines et VPCDomaines de test.

Cluster en lecture seule

Par rapport aux versions antérieures d'Elasticsearch OpenSearch et à Elasticsearch 7. x utiliser un système différent pour la coordination des clusters. Dans ce nouveau système, lorsque le cluster perd le quorum, le cluster est indisponible jusqu'à ce que vous preniez des mesures. La perte de quorum peut prendre deux formes :

En cas de perte de quorum et que votre cluster possède plusieurs nœuds, le OpenSearch service rétablit le quorum et place le cluster en mode lecture seule. Vous avez deux options :

Si vous préférez utiliser le cluster tel quel, vérifiez que l'état du cluster est vert à l'aide de la demande suivante :

GET _cat/health?v

Si l'état du cluster est rouge, nous vous recommandons de restaurer le cluster à partir d'un instantané. Vous pouvez également consulter Statut de cluster rouge pour connaître les étapes de dépannage. Si l'état du cluster est vert, vérifiez que tous les index attendus sont présents à l'aide de la demande suivante :

GET _cat/indices?v

Ensuite, exécutez quelques recherches pour vérifier que les données attendues sont présentes. Si c'est le cas, vous pouvez supprimer l'état en lecture seule à l'aide de la demande suivante :

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

En cas de perte du quorum et que votre cluster ne possède qu'un seul nœud, le OpenSearch service remplace le nœud et ne place pas le cluster en mode lecture seule. Sinon, vos options sont les mêmes : utilisez le cluster en l'état ou restaurez-le à partir d'un instantané.

Dans les deux cas, le OpenSearch service envoie deux événements à votre AWS Health Dashboard. La premier événement vous informe de la perte du quorum. La seconde se produit une fois que le OpenSearch service a rétabli le quorum avec succès. Pour plus d'informations sur l'utilisation du AWS Health Dashboard, consultez le guide de AWS Health l'utilisateur.

Statut de cluster rouge

Un statut de cluster rouge signifie qu'au moins une partition principale et ses répliques ne sont pas allouées à un nœud. OpenSearch Le service continue d'essayer de prendre des instantanés automatisés de tous les index, quel que soit leur statut, mais les instantanés échouent tant que l'état du cluster rouge persiste.

Les causes les plus courantes d'un état de cluster rouge sont les nœuds de cluster défaillants et le blocage du OpenSearch processus dû à une charge de traitement continue importante.

Finalement, des partitions rouges entraînent des clusters rouges et des index rouges entraînent des partitions rouges. Pour identifier les index à l'origine de l'état du cluster rouge, OpenSearch voici quelques API utiles.

La suppression des index rouges constitue le moyen le plus rapide de résoudre un statut de cluster rouge. En fonction de la raison de l'état du cluster rouge, vous pouvez ensuite redimensionner votre domaine de OpenSearch service pour utiliser des types d'instances plus grands, davantage d'instances ou davantage de stockage basé sur EBS et essayer de recréer les index problématiques.

Si la suppression d'un index problématique n'est pas possible, vous pouvez restaurer un instantané, supprimer des documents de l'index, modifier les paramètres d'index, réduire le nombre de réplicas ou supprimer d'autres index pour libérer de l'espace sur le disque. L'étape importante consiste à résoudre l'état du cluster rouge avant de reconfigurer votre domaine OpenSearch de service. La reconfiguration d'un domaine avec un statut de cluster rouge peut aggraver le problème et entraîner le blocage du domaine dans un état de configuration En cours de traitement tant que vous n'aurez pas résolu le statut.

Correction automatique des clusters rouges

Si l'état de votre cluster reste rouge pendant plus d'une heure, le OpenSearch service tente de le corriger automatiquement en redirigeant les partitions non allouées ou en effectuant une restauration à partir d'anciens instantanés.

S'il ne parvient pas à corriger un ou plusieurs index rouges et que l'état du cluster reste rouge pendant 14 jours au total, le OpenSearch service ne prend d'autres mesures que si le cluster répond à au moins l'un des critères suivants :

À l'heure actuelle, si votre cluster répond à l'un de ces critères, OpenSearch Service vous envoie des notifications quotidiennes au cours des 7 prochains jours expliquant que si vous ne corrigez pas ces index, toutes les partitions non attribuées seront supprimées. Si l'état de votre cluster est toujours rouge au bout de 21 jours, OpenSearch Service supprime les partitions non attribuées (stockage et calcul) sur tous les index rouges. Vous recevez des notifications dans le panneau Notifications de la console de OpenSearch service pour chacun de ces événements. Pour plus d’informations, consultez Événements relatifs à l'état du cluster.

Récupération après une importante charge de traitement continue

Pour déterminer si un statut de cluster rouge est dû à une importante charge de traitement continue sur un nœud de données, surveillez les métriques de cluster suivantes.

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

Statut de cluster jaune

Un statut de cluster jaune signifie que les partitions principales de tous les index sont attribuées aux nœuds d'un cluster, sauf pour les partitions de réplica d'au moins un index. Les clusters à nœud unique s'initialisent toujours avec un statut de cluster jaune car il n'existe aucun autre nœud auquel le OpenSearch Service peut attribuer une réplique. Pour obtenir un statut de cluster vert, augmentez votre nombre de nœuds. Pour en savoir plus, consultez Dimensionnement des domaines Amazon OpenSearch Service.

Les clusters à plusieurs nœuds peuvent brièvement présenter un statut de cluster jaune après la création d'un nouvel index ou après une défaillance de nœud. Cet état se résout automatiquement au fur et à mesure que OpenSearch les données sont répliquées dans le cluster. Un manque d'espace disque peut également provoquer un statut de cluster jaune ; le cluster peut uniquement distribuer des partitions de réplica si les nœuds disposent de l'espace disque nécessaire pour les accueillir.

ClusterBlockException

Vous pouvez recevoir une erreur ClusterBlockException pour les raisons suivantes.

Manque d'espace de stockage disponible

Si un ou plusieurs nœuds de votre cluster disposent d'un espace de stockage inférieur à la valeur minimale de 1) 20 % de l'espace de stockage disponible ou 2) 20 GiB d'espace de stockage, les opérations d'écriture de base telles que l'ajout de documents et la création d'index peuvent commencer à échouer. Calcul des exigences de stockagefournit un résumé de la façon dont le OpenSearch Service utilise l'espace disque.

Pour éviter tout problème, surveillez la FreeStorageSpace métrique dans la console de OpenSearch service et créez des CloudWatch alarmes qui se déclenchent en cas de FreeStorageSpace chute en dessous d'un certain seuil. GET /_cat/allocation?vfournit également un résumé utile de l'allocation des partitions et de l'utilisation du disque. Pour résoudre les problèmes liés au manque d'espace de stockage, adaptez votre domaine de OpenSearch service pour utiliser des types d'instances plus importants, davantage d'instances ou davantage de stockage basé sur EBS.

Pression mémoire élevée de la JVM

Lorsque la MemoryPressure métrique JVM dépasse 92 % pendant 30 minutes, le OpenSearch service déclenche un mécanisme de protection et bloque toutes les opérations d'écriture pour empêcher le cluster d'atteindre le statut rouge. Lorsque la protection est activée, les opérations d'écriture échouent avec une erreur ClusterBlockException, aucun nouvel index ne peut être créé et l'erreur IndexCreateBlockException est générée.

Lorsque la MemoryPressure métrique JVM revient à 88 % ou moins pendant cinq minutes, la protection est désactivée et les opérations d'écriture sur le cluster sont débloquées.

Une pression élevée sur la mémoire de la JVM peut être due à des pics de demandes adressées au cluster, à des allocations de partitions déséquilibrées entre les nœuds, à un trop grand nombre de partitions dans un cluster, à des explosions de données de champ ou de mappage d'index, ou à des types d'instances incapables de gérer les charges entrantes. Cela peut également être dû à l'utilisation d'agrégations, de caractères génériques ou de longues plages de temps dans les requêtes.

Pour réduire le trafic vers le cluster et résoudre les problèmes de forte pression sur la mémoire de la JVM, essayez l'une ou plusieurs des solutions suivantes :

En général, pour éviter une forte pression sur la mémoire de la JVM à l'avenir, suivez ces meilleures pratiques :

Erreur lors de la migration vers le mode Multi-AZ avec mode veille

Les problèmes suivants peuvent se produire lorsque vous migrez un domaine existant vers le mode Multi-AZ avec mode veille.

Création d'un index, d'un modèle d'index ou d'une politique ISM lors de la migration de domaines sans mode veille vers des domaines en mode veille

Si vous créez un index lors de la migration d'un domaine de Multi-AZ sans mode veille vers mode veille et que le modèle d'index ou la politique ISM ne respectent pas les directives de copie de données recommandées, cela peut entraîner une incohérence des données et la migration peut échouer. Pour éviter cette situation, créez le nouvel index avec un nombre de copies de données (y compris les nœuds principaux et les répliques) multiple de trois. Vous pouvez vérifier la progression de la migration à l'aide de l'DescribeDomainChangeProgressAPI. Si vous rencontrez une erreur liée au nombre de répliques, corrigez-la, puis contactez le AWS Support pour réessayer la migration.

Nombre de copies de données incorrect

Si vous ne disposez pas du bon nombre de copies de données dans votre domaine, la migration vers Multi-AZ with Standby échouera.

JVM OutOfMemoryError

Une erreur JVM OutOfMemoryError signifie généralement que l'un des disjoncteurs suivants du circuit JVM a été atteint.

Nœuds de cluster en échec

Les instances Amazon EC2 peuvent s'arrêter et redémarrer de manière inattendue. Généralement, le OpenSearch service redémarre les nœuds pour vous. Cependant, il est possible qu'un ou plusieurs nœuds d'un OpenSearch cluster restent en état de défaillance.

Pour vérifier cette condition, ouvrez le tableau de bord de votre domaine sur la console OpenSearch de service. Accédez à l'onglet Santé du cluster et recherchez la métrique Total des nœuds. Vérifiez si le nombre de nœuds indiqué est inférieur au nombre que vous avez configuré pour votre cluster. Si la métrique indique qu'un ou plusieurs nœuds sont en panne pendant plus d'une journée, contactez AWS Support.

Vous pouvez également définir une CloudWatch alarme pour vous avertir lorsque ce problème survient.

Pour protéger vos clusters contre les fermetures et les redémarrages inattendus de nœuds, créez au moins une réplique pour chaque index de votre domaine de OpenSearch service.

Limite maximale de partitions dépassée

OpenSearch ainsi que 7. Les versions x d'Elasticsearch ont un paramètre par défaut de 1 000 partitions maximum par nœud. OpenSearch/Elasticsearch génère une erreur si une demande, telle que la création d'un nouvel index, vous fait dépasser cette limite. Si vous rencontrez cette erreur, vous disposez de plusieurs options :

Domaine bloqué dans l'état de traitement

Votre domaine OpenSearch de service passe à l'état « En cours de traitement » lorsqu'il est en cours de modification de configuration. Lorsque vous initiez une modification de configuration, le statut du domaine passe à « Traitement » tandis que le OpenSearch service crée un nouvel environnement. Dans le nouvel environnement, OpenSearch Service lance un nouvel ensemble de nœuds applicables (tels que data, master ou UltraWarm). Une fois la migration terminée, les nœuds plus anciens sont résiliés.

Le cluster peut rester bloqué dans l'état « Processing » (Traitement en cours) si l'une de ces situations se produit :

Pour connaître les étapes de résolution détaillées dans chacune de ces situations, consultez Pourquoi mon domaine Amazon OpenSearch Service est-il bloqué dans l'état « En cours de traitement » ? .

Solde de débordement EBS faible

OpenSearch Le service vous envoie une notification sur console lorsque le solde de rupture EBS sur l'un de vos volumes à usage général (SSD) est inférieur à 70 %, et une notification de suivi si le solde tombe en dessous de 20 %. Pour résoudre ce problème, vous pouvez soit augmenter la capacité de votre cluster, soit réduire les IOPS de lecture et d'écriture afin que le solde de débordement puisse être crédité. Le solde de rafale reste à 0 pour les domaines avec des types de volumes gp3 et les domaines avec des volumes gp2 dont la taille de volume est supérieure à 1 000 Gio. Pour plus d'informations, consultez Volumes SSD à usage général (gp2). Vous pouvez surveiller l'équilibre des rafales EBS à l'aide de la BurstBalance CloudWatch métrique.

Impossible d'activer les journaux d'audit

L'erreur suivante peut s'afficher lorsque vous essayez d'activer la publication du journal d'audit à l'aide de la console OpenSearch de service :

La politique d'accès aux ressources spécifiée pour le groupe de CloudWatch journaux Logs n'accorde pas les autorisations suffisantes à Amazon OpenSearch Service pour créer un flux de journaux. Vérifiez la stratégie d'accès aux ressources.

Si vous rencontrez cette erreur, vérifiez que l'élément resource de votre politique inclut l'ARN du groupe de journaux qui convient. Si tel est le cas, procédez comme suit :

Si l'erreur persiste après avoir répété le processus plusieurs fois, contactez Support AWS.

Impossible de fermer l'index

OpenSearch Le service prend en charge l'_closeAPI uniquement pour les versions 7.4 OpenSearch et ultérieures d'Elasticsearch. Si vous utiliser une version plus ancienne et restaurez un index à partir d'un instantané, vous pouvez supprimer l'index existant (avant ou après l'avoir réindexé).

Vérifications des licences des clients

Les distributions par défaut de Logstash et Beats incluent une vérification de licence propriétaire et ne permettent pas de se connecter à la version open source de. OpenSearch Assurez-vous d'utiliser les distributions Apache 2.0 (OSS) de ces clients avec OpenSearch Service.

Limitation des demandes

Si vous recevez constamment des erreurs 403 Request throttled due to too many requests ou 429 Too Many Requests, envisagez une mise à l'échelle verticale. Amazon OpenSearch Service limite les demandes si la charge utile est susceptible d'entraîner une utilisation de la mémoire supérieure à la taille maximale du segment Java.

Impossible d'accéder au nœud via SSH

Vous ne pouvez pas utiliser SSH pour accéder aux nœuds de votre OpenSearch cluster, et vous ne pouvez pas les modifier opensearch.yml directement. Utilisez plutôt la console ou AWS CLI les SDK pour configurer votre domaine. Vous pouvez également spécifier quelques paramètres au niveau du cluster à l'aide des OpenSearch API REST. Pour en savoir plus, consultez le manuel Amazon OpenSearch Service API Reference etOpérations prises en charge dans Amazon OpenSearch Service.

Si vous avez besoin de plus d'informations sur les performances du cluster, vous pouvez publier des journaux d'erreurs et des journaux de lenteur sur CloudWatch.

Erreur d'instantané « Non valide pour la classe de stockage de l'objet »

OpenSearch Les instantanés de service ne prennent pas en charge la classe de stockage S3 Glacier. Vous pouvez rencontrer cette erreur lorsque vous essayez de répertorier les instantanés si votre compartiment S3 comprend une règle de cycle de vie qui transfère des objets vers la classe de stockage S3 Glacier.

Si vous devez restaurer un instantané à partir du compartiment, restaurez les objets à partir de S3 Glacier, copiez les objets dans un nouveau compartiment et enregistrez le nouveau compartiment en tant que référentiel d'instantanés.

En-tête d'hôte non valide

OpenSearch Le service nécessite que les clients le spécifient Host dans les en-têtes de demande. Une valeur Host valide est le point de terminaison du domaine sans https://, comme :

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

Si vous recevez un Invalid Host Header message d'erreur lorsque vous faites une demande, vérifiez que votre client ou proxy inclut le point de terminaison du domaine de OpenSearch service (et non, par exemple, son adresse IP) dans l'Hosten-tête.

Type d'instance M3 non valide

OpenSearch Le service ne prend pas en charge l'ajout ou la modification d'instances M3 à des domaines existants exécutant OpenSearch ou à des versions 6.7 ou ultérieures d'Elasticsearch. Vous pouvez continuer à utiliser des instances M3 avec des versions 6.5 et antérieures d'Elasticsearch.

Nous vous recommandons de choisir un type d'instance plus récent. Pour les domaines exécutant OpenSearch Elasticsearch 6.7 ou version ultérieure, les restrictions suivantes s'appliquent :

Les hot queries cessent de fonctionner après l'activation UltraWarm

Lorsque vous l'activez UltraWarm sur un domaine, s'il n'existe aucune dérogation préexistante au search.max_buckets paramètre, OpenSearch Service définit automatiquement la valeur sur pour empêcher les requêtes gourmandes en mémoire de 10000 saturer les nœuds chauds. Si vos requêtes actives utilisent plus de 10 000 compartiments, elles risquent de ne plus fonctionner lorsque vous les activez UltraWarm.

Comme vous ne pouvez pas modifier ce paramètre en raison de la nature gérée d'Amazon OpenSearch Service, vous devez ouvrir un dossier d'assistance pour augmenter la limite. L'augmentation des limites ne nécessite pas d'abonnement Premium Support.

Impossible de revenir à une version plus ancienne après la mise à niveau

Les mises à niveau sur place sont irréversibles, mais si vous contactez l'Assistance AWS, ils peuvent vous aider à restaurer l'instantané automatique d'avant la mise à niveau sur un nouveau domaine. Par exemple, si vous mettez à niveau un domaine d'Elasticsearch 5.6 vers la version 6.4, le AWS Support peut vous aider à restaurer le snapshot antérieur à la mise à niveau sur un nouveau domaine Elasticsearch 5.6. Si vous prenez un instantané manuel du domaine d'origine, vous pouvez effectuer cette étape vous-même.

Résumé nécessaire des domaines pour toutes les Régions AWS

Le script suivant utilise la AWS CLI commande amazon EC2 describe-regions pour créer une liste de toutes les régions dans lesquelles le OpenSearch service pourrait être disponible. Ensuite, il demande list-domain-namespour chaque région :

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

Vous recevez la sortie suivante pour chaque région :

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

Les régions dans lesquelles le OpenSearch service n'est pas disponible renvoient « Impossible de se connecter à l'URL du point de terminaison ».

Erreur du navigateur lors de l'utilisation des OpenSearch tableaux de bord

Votre navigateur intègre les messages d'erreur de service dans des objets de réponse HTTP lorsque vous utilisez des tableaux de bord pour afficher les données de votre domaine de OpenSearch service. Vous pouvez utiliser les outils de développement généralement disponibles dans les navigateurs Web, tels que Developer Mode dans Chrome, pour afficher les erreurs de service sous-jacentes et aider vos efforts de débogage.

Asymétrie des partitions et de stockage des nœuds

L'asymétrie des partitions d'un nœud se produit lorsqu'un ou plusieurs nœuds d'un cluster possèdent beaucoup plus de partitions que les autres nœuds. L'asymétrie de stockage d'un nœud se produit lorsqu'un ou plusieurs nœuds d'un cluster possèdent beaucoup plus de stockage (disk.indices) que les autres nœuds. Bien que ces deux conditions puissent se produire temporairement, comme lorsqu'un domaine a remplacé un nœud et lui alloue toujours des partitions, vous devez y remédier si elles persistent.

Pour identifier les deux types d'asymétrie, exécutez l'opération d'API _cat/allocation et comparez les entrées shards et disk.indices dans la réponse :

 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

Bien qu'une certaine asymétrie de stockage soit normale, tout écart de plus de 10 % par rapport à la moyenne est significatif. Lorsque la distribution des partitions est asymétrique, l'utilisation du CPU, du réseau et de la bande passante du disque peut également être asymétrique. Dans la mesure où plus de données signifient généralement plus d'opérations d'indexation et de recherche, les nœuds les plus chargés ont également tendance à être les plus sollicités en termes de ressources, tandis que les moins chargés représentent une capacité sous-utilisée.

Correction : utilisez des partitions dont le nombre est un multiple du nombre de nœuds de données pour garantir que chaque index est réparti uniformément sur les nœuds de données.

Asymétrie des partitions et du stockage des index

L'asymétrie des partitions d'un index se produit lorsqu'un ou plusieurs nœuds détiennent plus de partitions d'un index que les autres nœuds. L'asymétrie de stockage d'un index se produit lorsqu'un ou plusieurs nœuds détiennent une quantité disproportionnée du stockage total d'un index.

L'asymétrie d'index est plus difficile à identifier que l'asymétrie de nœuds car elle nécessite une certaine manipulation de la sortie de l'API _cat/shards. Examinez l'asymétrie de l'index s'il y a des indications d'asymétrie dans les métriques du cluster ou du nœud. Voici quelques indications courantes d'asymétrie d'index :

Correction : utilisez des partitions dont le nombre est un multiple du nombre de nœuds de données pour garantir que chaque index est réparti uniformément sur les nœuds de données. Si vous constatez toujours un stockage d'index ou un biais de partition, vous devrez peut-être forcer une réallocation de partition, ce qui se produit à chaque déploiement bleu/vert de votre domaine de service. OpenSearch

Opération non autorisée après la sélection de l'accès VPC

Lorsque vous créez un nouveau domaine à l'aide de la console de OpenSearch service, vous avez la possibilité de sélectionner un accès VPC ou public. Si vous sélectionnez l'accès au VPC, le OpenSearch service demande des informations sur le VPC et échoue si vous ne disposez pas des autorisations appropriées :

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

Pour activer cette requête, vous devez avoir accès aux opérations ec2:DescribeVpcs, ec2:DescribeSubnets et ec2:DescribeSecurityGroups. Cette exigence concerne uniquement la console. Si vous utilisez la AWS CLI pour créer et configurer un domaine avec un point de terminaison VPC, vous n'avez pas besoin d'accéder à ces opérations.

Blocage du chargement suite à la création d'un domaine VPC

Après avoir créé un nouveau domaine qui utilise un accès VPC, l'état de configuration du domaine ne dépasse pas le stade du chargement. Si ce problème se produit, vous avez probablement désactivé AWS Security Token Service (AWS STS) pour votre région.

Pour ajouter des points de terminaison VPC à votre VPC, le OpenSearch service doit assumer le rôle. AWSServiceRoleForAmazonOpenSearchService AWS STS Il doit donc être activé pour créer de nouveaux domaines utilisant l'accès VPC dans une région donnée. Pour en savoir plus sur l'activation et la désactivation AWS STS, consultez le guide de l'utilisateur IAM.

Demandes refusées à l' OpenSearch API

Avec l'introduction du contrôle d'accès basé sur des balises pour l' OpenSearch API, vous pourriez commencer à voir des erreurs de refus d'accès là où vous ne le faisiez pas auparavant. Cela peut être dû au fait qu'une ou plusieurs des stratégies d'accès contiennent le Deny utilisant la condition ResourceTag et ces conditions sont maintenant respectées.

Par exemple, la stratégie suivante est utilisée uniquement pour refuser l'accès à l'action CreateDomain de l'API de configuration, si le domaine comportait la balise environment=production. Bien que la liste d'actions inclue également ESHttpPut, la déclaration de refus ne s'appliquait pas à cette action ou à toute autre action ESHttp*.

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

Avec la prise en charge supplémentaire des balises pour les méthodes OpenSearch HTTP, une politique basée sur l'identité IAM comme celle décrite ci-dessus empêchera l'utilisateur attaché d'accéder à l'action. ESHttpPut Auparavant, en l'absence de la validation à l'aide de balises, l'utilisateur attaché pouvait toujours envoyer des requêtes PUT.

Si vous commencez à voir des erreurs d'accès refusé après la mise à jour des domaines au logiciel de service R20220323 ou version ultérieure, vérifiez les stratégies d'accès basées sur l'identité pour voir si tel est le cas et mettez-les à jour si nécessaire pour autoriser l'accès.

Impossible de se connecter à partir d'Alpine Linux

Alpine Linux limite la taille de réponse DNS à 512 octets. Si vous essayez de vous connecter à votre domaine de OpenSearch service depuis Alpine Linux version 3.18.0 ou inférieure, la résolution DNS peut échouer si le domaine se trouve dans un VPC et compte plus de 20 nœuds. Si vous utilisez une version d'Alpine Linux supérieure à 3.18.0, vous devriez être en mesure de résoudre plus de 20 hôtes. Pour plus d'informations, consultez les notes de mise à jour d'Alpine Linux 3.18.0.

Si votre domaine est dans un VPC, nous vous recommandons d'utiliser d'autres distributions de Linux, telles que Debian, Ubuntu, CentOS, Red Hat Enterprise Linux ou Amazon Linux 2, pour vous y connecter.

Trop de demandes pour Search Backpressure

Le contrôle d'admission basé sur le processeur est un mécanisme de contrôle d'accès qui limite de manière proactive le nombre de demandes adressées à un nœud en fonction de sa capacité actuelle, à la fois en cas d'augmentation organique et de pic de trafic. Les demandes excessives renvoient un code d'état HTTP 429 « Trop de demandes » en cas de rejet. Cette erreur indique soit des ressources de cluster insuffisantes, soit des demandes de recherche gourmandes en ressources, soit une augmentation involontaire de la charge de travail.

La contre-pression de recherche est à l'origine du rejet, ce qui peut aider à affiner les demandes de recherche gourmandes en ressources. En cas de pics de trafic, nous recommandons de réessayer côté client avec un recul et une instabilité exponentiels.

Erreur de certificat lors de l'utilisation du kit SDK

Comme AWS les SDK utilisent les certificats CA de votre ordinateur, les modifications apportées aux certificats sur les AWS serveurs peuvent provoquer des échecs de connexion lorsque vous tentez d'utiliser un SDK. Les messages d'erreur varient, mais ils contiennent en général le texte suivant :

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

Vous pouvez éviter ces défaillances en conservant les certificats CA et le système d'exploitation de votre ordinateur up-to-date. Si vous rencontrez ce problème dans un environnement d'entreprise et que vous ne gérez pas votre propre ordinateur, vous pourrez être amené à demander à un administrateur de vous aider pour effectuer la mise à jour.

La liste suivante présente les versions minimales requises pour le système d'exploitation et Java :

Les trois autorités de certification sont :

Les certificats racine des deux premières autorités sont disponibles auprès d'Amazon Trust Services, mais la solution la plus simple consiste à conserver votre ordinateur up-to-date . Pour en savoir plus sur les certificats fournis par ACM, reportez-vous aux Questions fréquentes (FAQ)AWS Certificate Manager.