Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Utilisation de registres de schémas avec des sources d'événements Kafka dans Lambda
Les registres de schémas vous aident à définir et à gérer des schémas de flux de données. Un schéma définit la structure et le format d'un enregistrement de données. Dans le contexte des mappages de sources d'événements Kafka, vous pouvez configurer un registre de schémas pour valider la structure et le format des messages Kafka par rapport à des schémas prédéfinis avant qu'ils n'atteignent votre fonction Lambda. Cela ajoute une couche de gouvernance des données à votre application et vous permet de gérer efficacement les formats de données, de garantir la conformité des schémas et d'optimiser les coûts grâce au filtrage des événements.
Cette fonctionnalité fonctionne avec tous les langages de programmation, mais tenez compte des points importants suivants :
Powertools for Lambda fournit un support spécifique pour Java, Python TypeScript et assure la cohérence avec les modèles de développement Kafka existants et permet un accès direct aux objets métier sans code de désérialisation personnalisé
Cette fonctionnalité n'est disponible que pour les mappages de sources d'événements utilisant le mode provisionné. Le registre des schémas ne prend pas en charge les mappages de sources d'événements en mode à la demande. Si vous utilisez le mode provisionné et qu'un registre de schéma est configuré, vous ne pouvez pas passer en mode à la demande, sauf si vous supprimez d'abord la configuration de votre registre de schéma. Pour de plus amples informations, consultez Mode alloué.
Vous ne pouvez configurer qu'un seul registre de schéma par mappage de source d'événements (ESM). L'utilisation d'un registre de schémas avec votre source d'événements Kafka peut augmenter votre utilisation de l'unité Lambda Event Poller (EPU), ce qui constitue une dimension tarifaire pour le mode Provisioned.
Rubriques
Options du registre des schémas
Lambda prend en charge les options de registre de schéma suivantes :
Votre registre de schémas prend en charge la validation des messages dans les formats de données suivants :
-
Apache Avro
-
Tampons de protocole (Protobuf)
-
Schéma JSON (JSON-SE)
Pour utiliser un registre de schémas, assurez-vous d'abord que le mappage de votre source d'événements est en mode provisionné. Lorsque vous utilisez un registre de schéma, Lambda ajoute des métadonnées relatives au schéma à la charge utile. Pour plus d'informations, consultez Formats de charge utile et comportement de désérialisation.
Comment Lambda effectue la validation du schéma pour les messages Kafka
Lorsque vous configurez un registre de schémas, Lambda exécute les étapes suivantes pour chaque message Kafka :
-
Lambda interroge l'enregistrement Kafka de votre cluster.
-
Lambda valide les attributs de message sélectionnés dans l'enregistrement par rapport à un schéma spécifique de votre registre de schémas.
-
Si le schéma associé au message n'est pas trouvé dans le registre, Lambda envoie le message à un DLQ avec le code de motif.
SCHEMA_NOT_FOUND
-
-
Lambda désérialise le message conformément à la configuration du registre du schéma pour valider le message. Si le filtrage des événements est configuré, Lambda effectue ensuite le filtrage en fonction des critères de filtre configurés.
-
Si la désérialisation échoue, Lambda envoie le message à un DLQ avec le code de motif.
DESERIALIZATION_ERROR
Si aucun DLQ n'est configuré, Lambda supprime le message.
-
-
Si le message est validé par le registre des schémas et qu'il n'est pas filtré selon vos critères de filtre, Lambda appelle votre fonction avec le message.
Cette fonctionnalité est destinée à valider les messages déjà produits à l'aide de clients Kafka intégrés à un registre de schémas. Nous vous recommandons de configurer vos producteurs Kafka pour qu'ils fonctionnent avec votre registre de schémas afin de créer des messages correctement formatés.
Configuration d'un registre de schémas Kafka
Les étapes de console suivantes ajoutent une configuration de registre de schéma Kafka à votre mappage de source d'événements.
Pour ajouter une configuration de registre de schéma Kafka à votre mappage de source d'événements (console)
-
Ouvrez la page Fonction
de la console Lambda. -
Choisissez Configuration.
-
Choisissez Triggers.
-
Sélectionnez le mappage de source d'événements Kafka pour lequel vous souhaitez configurer un registre de schémas, puis choisissez Modifier.
-
Sous Configuration du sondeur d'événements, choisissez Configurer le registre des schémas. Le mappage de la source de votre événement doit être en mode provisionné pour que cette option soit visible.
-
Pour l'URI du registre de schéma, entrez l'ARN de votre registre de AWS Glue schémas ou l'URL HTTPS de votre registre de schémas Confluent Cloud ou de votre registre de schémas Confluent autogéré.
-
Les étapes de configuration suivantes indiquent à Lambda comment accéder à votre registre de schémas. Pour de plus amples informations, veuillez consulter Méthodes d'authentification pour votre registre de schémas.
-
Pour le type de configuration Access, choisissez le type d'authentification utilisé par Lambda pour accéder à votre registre de schémas.
-
Pour l'URI de configuration d'accès, entrez l'ARN du secret Secrets Manager pour vous authentifier auprès de votre registre de schémas, le cas échéant. Assurez-vous que le rôle d'exécution de votre fonction contient les autorisations appropriées.
-
-
Le champ Chiffrement s'applique uniquement si votre registre de schémas est signé par une autorité de certification (CA) privée ou une autorité de certification (CA) qui ne figure pas dans le magasin de confiance Lambda. Le cas échéant, fournissez la clé secrète contenant le certificat CA privé utilisé par votre registre de schémas pour le chiffrement TLS.
-
Pour le format d'enregistrement des événements, choisissez la manière dont vous souhaitez que Lambda fournisse les enregistrements à votre fonction après la validation du schéma. Pour plus d'informations, consultez la section Exemples de formats de charge utile.
-
Si vous choisissez JSON, Lambda fournit les attributs que vous sélectionnez dans l'attribut de validation du schéma ci-dessous au format JSON standard. Pour les attributs que vous ne sélectionnez pas, Lambda les fournit tels quels.
-
Si vous choisissez SOURCE, Lambda fournit les attributs que vous avez sélectionnés dans l'attribut de validation du schéma ci-dessous dans leur format source d'origine.
-
-
Pour l'attribut de validation du schéma, sélectionnez les attributs de message que Lambda doit valider et désérialiser à l'aide de votre registre de schémas. Vous devez sélectionner au moins l'une des options KEY ou VALUE. Si vous avez choisi JSON comme format d'enregistrement d'événement, Lambda désérialise également les attributs de message sélectionnés avant de les envoyer à votre fonction. Pour plus d'informations, consultez Formats de charge utile et comportement de désérialisation.
-
Choisissez Enregistrer.
Vous pouvez également utiliser l'API Lambda pour créer ou mettre à jour le mappage de votre source d'événements avec une configuration de registre de schéma. Les exemples suivants montrent comment configurer un registre de schéma AWS Glue ou un registre de schéma Confluent à l'aide du AWS CLI, qui correspond aux opérations d'CreateEventSourceMappingAPI UpdateEventSourceMappinget de la référence AWS Lambda d'API :
Important
Si vous mettez à jour un champ de configuration du registre de schéma à l'aide de l'update-event-source-mapping
API AWS CLI ou de l'API, vous devez mettre à jour tous les champs de configuration du registre de schéma.
Filtrage pour Avro et Protobuf
Lorsque vous utilisez les formats Avro ou Protobuf avec un registre de schémas, vous pouvez appliquer le filtrage des événements à votre fonction Lambda. Les modèles de filtre sont appliqués à la représentation JSON classique désérialisée de vos données après validation du schéma. Par exemple, avec un schéma Avro définissant les détails du produit, y compris le prix, vous pouvez filtrer les messages en fonction de la valeur du prix :
Note
Lors de la désérialisation, Avro est converti en JSON standard, ce qui signifie qu'il ne peut pas être reconverti directement en objet Avro. Si vous devez effectuer une conversion en objet Avro, utilisez plutôt le format SOURCE.
Pour la désérialisation de Protobuf, les noms de champs dans le JSON obtenu correspondent à ceux définis dans votre schéma, plutôt que d'être convertis en camel case comme le fait généralement Protobuf. Gardez cela à l'esprit lorsque vous créez des modèles de filtrage.
aws lambda create-event-source-mapping \ --function-name myAvroFunction \ --topics myAvroTopic \ --starting-position TRIM_HORIZON \ --kafka-bootstrap-servers '["broker1:9092", "broker2:9092"]' \ --schema-registry-config '{ "SchemaRegistryURI": "arn:aws:glue:us-east-1:123456789012:registry/myAvroRegistry", "EventRecordFormat": "JSON", "SchemaValidationConfigs": [ { "Attribute": "VALUE" } ] }' \ --filter-criteria '{ "Filters": [ { "Pattern": "{ \"value\" : { \"field_1\" : [\"value1\"], \"field_2\" : [\"value2\"] } }" } ] }'
Dans cet exemple, le modèle de filtre analyse l'value
objet en faisant correspondre les messages field_1
avec "value1"
et field_2
avec"value2"
. Les critères de filtre sont évalués par rapport aux données désérialisées, une fois que Lambda a converti le message du format Avro en JSON.
Pour des informations plus détaillées sur le filtrage des événements, consultez la section Filtrage des événements Lambda.
Formats de charge utile et comportement de désérialisation
Lorsque vous utilisez un registre de schémas, Lambda fournit la charge utile finale à votre fonction dans un format similaire à la charge utile d'événements normale, avec quelques champs supplémentaires. Les champs supplémentaires dépendent du SchemaValidationConfigs
paramètre. Pour chaque attribut que vous sélectionnez pour validation (clé ou valeur), Lambda ajoute les métadonnées de schéma correspondantes à la charge utile.
Note
Vous devez passer aws-lambda-java-events
Par exemple, si vous validez le value
champ, Lambda ajoute un champ appelé valueSchemaMetadata
à votre charge utile. De même, pour le key
champ, Lambda ajoute un champ appelé. keySchemaMetadata
Ces métadonnées contiennent des informations sur le format des données et l'ID de schéma utilisés pour la validation :
"valueSchemaMetadata": { "dataFormat": "AVRO", "schemaId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" }
Le EventRecordFormat
paramètre peut être défini sur JSON
ouSOURCE
, ce qui détermine la manière dont Lambda gère les données validées par le schéma avant de les transmettre à votre fonction. Chaque option offre des capacités de traitement différentes :
-
JSON
- Lambda désérialise les attributs validés au format JSON standard, ce qui rend les données prêtes à être utilisées directement dans les langages supportant le format JSON natif. Ce format est idéal lorsque vous n'avez pas besoin de conserver le format binaire d'origine ou de travailler avec des classes générées. -
SOURCE
- Lambda préserve le format binaire d'origine des données sous forme de chaîne codée en Base64, ce qui permet une conversion directe en objets Avro ou Protobuf. Ce format est essentiel lorsque vous travaillez avec des langages fortement typés ou lorsque vous devez conserver toutes les fonctionnalités des schémas Avro ou Protobuf.
Sur la base de ces caractéristiques de format et de considérations spécifiques à la langue, nous recommandons les formats suivants :
Langue | Avro | Protobuf | JSON |
---|---|---|---|
Java | SOURCE | SOURCE | SOURCE |
Python | JSON | JSON | JSON |
NodeJS | JSON | JSON | JSON |
.NET | SOURCE | SOURCE | SOURCE |
Autres | JSON | JSON | JSON |
Les sections suivantes décrivent ces formats en détail et fournissent des exemples de charges utiles pour chaque format.
Format JSON
Si vous choisissez JSON
comme telEventRecordFormat
, Lambda valide et désérialise les attributs de message que vous avez sélectionnés dans le SchemaValidationConfigs
champ (les attributs). key
and/or value
Lambda fournit ces attributs sélectionnés sous forme de chaînes codées en base64 de leur représentation JSON standard dans votre fonction.
Note
Lors de la désérialisation, Avro est converti en JSON standard, ce qui signifie qu'il ne peut pas être reconverti directement en objet Avro. Si vous devez effectuer une conversion en objet Avro, utilisez plutôt le format SOURCE.
Pour la désérialisation de Protobuf, les noms de champs dans le JSON obtenu correspondent à ceux définis dans votre schéma, plutôt que d'être convertis en camel case comme le fait généralement Protobuf. Gardez cela à l'esprit lorsque vous créez des modèles de filtrage.
Ce qui suit montre un exemple de charge utile, en supposant JSON
que vous choisissiez les EventRecordFormat
value
attributs key
et les deux comme : SchemaValidationConfigs
{ "eventSource":"aws:kafka", "eventSourceArn":"arn:aws:kafka:us-east-1:123456789012:cluster/vpc-2priv-2pub/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111-1", "bootstrapServers":"b-2.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092,b-1.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092", "records":{ "mytopic-0":[ { "topic":"mytopic", "partition":0, "offset":15, "timestamp":1545084650987, "timestampType":"CREATE_TIME", "key":"abcDEFghiJKLmnoPQRstuVWXyz1234==", //Base64 encoded string of JSON "keySchemaMetadata": { "dataFormat": "AVRO", "schemaId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" }, "value":"abcDEFghiJKLmnoPQRstuVWXyz1234", //Base64 encoded string of JSON "valueSchemaMetadata": { "dataFormat": "AVRO", "schemaId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" }, "headers":[ { "headerKey":[ 104, 101, 97, 100, 101, 114, 86, 97, 108, 117, 101 ] } ] } ] } }
Dans cet exemple :
-
Les deux
value
sontkey
des chaînes codées en base64 de leur représentation JSON après désérialisation. -
Lambda inclut des métadonnées de schéma pour les deux attributs dans
keySchemaMetadata
et.valueSchemaMetadata
-
Votre fonction peut décoder les
value
chaîneskey
et pour accéder aux données JSON désérialisées.
Le format JSON est recommandé pour les langages qui ne sont pas fortement typés, tels que Python ou Node.js. Ces langages prennent en charge nativement la conversion de JSON en objets.
Format source
Si vous le choisissez SOURCE
EventRecordFormat
, Lambda valide toujours l'enregistrement par rapport au registre du schéma, mais fournit les données binaires d'origine à votre fonction sans désérialisation. Ces données binaires sont fournies sous la forme d'une chaîne codée en Base64 des données d'octets d'origine, les métadonnées ajoutées par le producteur étant supprimées. Par conséquent, vous pouvez directement convertir les données binaires brutes en objets Avro et Protobuf dans votre code de fonction. Nous vous recommandons d'utiliser Powertools for AWS Lambda, qui désérialisera les données binaires brutes et vous fournira directement les objets Avro et Protobuf.
Par exemple, si vous configurez Lambda pour valider à la fois les value
attributs key
et mais que vous utilisez le SOURCE
format, votre fonction reçoit une charge utile comme celle-ci :
{ "eventSource": "aws:kafka", "eventSourceArn": "arn:aws:kafka:us-east-1:123456789012:cluster/vpc-2priv-2pub/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111-1", "bootstrapServers": "b-2.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092,b-1.demo-cluster-1.a1bcde.c1.kafka.us-east-1.amazonaws.com:9092", "records": { "mytopic-0": [ { "topic": "mytopic", "partition": 0, "offset": 15, "timestamp": 1545084650987, "timestampType": "CREATE_TIME", "key": "abcDEFghiJKLmnoPQRstuVWXyz1234==", // Base64 encoded string of Original byte data, producer-appended metadata removed "keySchemaMetadata": { "dataFormat": "AVRO", "schemaId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" }, "value": "abcDEFghiJKLmnoPQRstuVWXyz1234==", // Base64 encoded string of Original byte data, producer-appended metadata removed "valueSchemaMetadata": { "dataFormat": "AVRO", "schemaId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" }, "headers": [ { "headerKey": [ 104, 101, 97, 100, 101, 114, 86, 97, 108, 117, 101 ] } ] } ] } }
Dans cet exemple :
-
Les deux
key
etvalue
contiennent les données binaires d'origine sous forme de chaînes codées en Base64. -
Votre fonction doit gérer la désérialisation à l'aide des bibliothèques appropriées.
Il EventRecordFormat
est recommandé de choisir SOURCE
pour si vous utilisez des objets générés par Avro ou ProtoBuf, en particulier avec des fonctions Java. Cela est dû au fait que Java est fortement typé et nécessite des désérialiseurs spécifiques pour les formats Avro et Protobuf. Dans votre code de fonction, vous pouvez utiliser votre bibliothèque Avro ou Protobuf préférée pour désérialiser les données.
Utilisation de données désérialisées dans les fonctions Lambda
Powertools for vous AWS Lambda aide à désérialiser les enregistrements Kafka dans votre code de fonction en fonction du format que vous utilisez. Cet utilitaire simplifie l'utilisation des enregistrements Kafka en gérant la conversion des données et en fournissant des ready-to-use objets.
Pour utiliser Powertools AWS Lambda dans votre fonction, vous devez ajouter Powertools en tant que couche AWS Lambda ou en tant que dépendance lors de la création de votre fonction Lambda. Pour obtenir des instructions de configuration et plus d'informations, consultez les Powertools pour obtenir AWS Lambda la documentation correspondant à votre langue préférée :
Note
Lorsque vous travaillez avec l'intégration de registres de schémas, vous pouvez choisir SOURCE
ou JSON
formater. Chaque option prend en charge différents formats de sérialisation, comme indiqué ci-dessous :
Format | Prend en charge |
---|---|
SOURCE |
Avro et Protobuf (en utilisant l'intégration du registre du schéma Lambda) |
JSON |
Données JSON |
Lorsque vous utilisez le JSON
format SOURCE
or, vous pouvez utiliser Powertools pour vous aider AWS à désérialiser les données de votre code de fonction. Voici des exemples de gestion de différents formats de données :
Méthodes d'authentification pour votre registre de schémas
Pour utiliser un registre de schémas, Lambda doit pouvoir y accéder en toute sécurité. Si vous travaillez avec un registre de AWS Glue schémas, Lambda s'appuie sur l'authentification IAM. Cela signifie que le rôle d'exécution de votre fonction doit disposer des autorisations suivantes pour accéder au AWS Glue registre :
-
GetRegistrydans la référence de l'API AWS Glue Web
-
GetSchemaVersiondans la référence de l'API AWS Glue Web
Exemple de politique IAM requise :
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetRegistry", "glue:GetSchemaVersion" ], "Resource": [ "*" ] } ] }
Note
Pour les registres de AWS Glue schémas, si vous fournissez AccessConfigs
un AWS Glue registre, Lambda renverra une exception de validation.
Si vous travaillez avec un registre de schémas Confluent, vous pouvez choisir l'une des trois méthodes d'authentification prises en charge pour le Type
paramètre de votre KafkaSchemaRegistryAccessConfigobjet :
-
BASIC_AUTH — Lambda utilise le nom d'utilisateur et le mot de passe ou l'authentification par clé API et secret API pour accéder à votre registre. Si vous choisissez cette option, indiquez l'ARN du Secrets Manager contenant vos informations d'identification dans le champ URI.
-
CLIENT_CERTIFICATE_TLS_AUTH — Lambda utilise l'authentification TLS mutuelle avec les certificats clients. Pour utiliser cette option, Lambda doit avoir accès au certificat et à la clé privée. Indiquez l'ARN du Secrets Manager contenant ces informations d'identification dans le champ URI.
-
NO_AUTH — Le certificat CA public doit être signé par une autorité de certification (CA) présente dans le magasin Lambda Trust. Pour un certificat privé ou auto-signé, vous configurez le certificat d'autorité de certification racine du serveur. Pour utiliser cette option, omettez le
AccessConfigs
paramètre.
En outre, si Lambda a besoin d'accéder à un certificat CA privé pour vérifier le certificat TLS de votre registre de schémas, choisissez-le Type
et fournissez l'SERVER_ROOT_CA_CERT
ARN du Secrets Manager au certificat dans le champ URI.
Note
Pour configurer l'SERVER_ROOT_CA_CERT
option dans la console, fournissez l'ARN secret contenant le certificat dans le champ Chiffrement.
La configuration d'authentification de votre registre de schéma est distincte de toute authentification que vous avez configurée pour votre cluster Kafka. Vous devez configurer les deux séparément, même s'ils utilisent des méthodes d'authentification similaires.
Gestion des erreurs et résolution des problèmes liés au registre des schémas
Lorsque vous utilisez un registre de schémas avec votre source d'événements Amazon MSK, vous pouvez rencontrer diverses erreurs. Cette section fournit des conseils sur les problèmes courants et sur la manière de les résoudre.
Erreurs de configuration
Ces erreurs se produisent lors de la configuration de votre registre de schéma.
- Mode provisionné requis
-
Message d'erreur :
SchemaRegistryConfig is only available for Provisioned Mode. To configure Schema Registry, please enable Provisioned Mode by specifying MinimumPollers in ProvisionedPollerConfig.
Résolution : activez le mode provisionné pour le mappage de la source de votre événement en configurant le
MinimumPollers
paramètre dansProvisionedPollerConfig
. - URL de registre de schéma non valide
-
Message d'erreur :
Malformed SchemaRegistryURI provided. Please provide a valid URI or ARN. For example, https://schema-registry.example.com:8081 or arn:aws:glue:us-east-1:123456789012:registry/ExampleRegistry.
Solution : Fournissez une URL HTTPS valide pour le registre des schémas Confluent ou un ARN valide pour le registre des AWS Glue schémas.
- Format d'enregistrement d'événement non valide ou manquant
-
Message d'erreur :
EventRecordFormat is a required field for SchemaRegistryConfig. Please provide one of supported format types: SOURCE, JSON.
Résolution : Spécifiez SOURCE ou JSON EventRecordFormat dans la configuration de votre registre de schéma.
- Attributs de validation en double
-
Message d'erreur :
Duplicate KEY/VALUE Attribute in SchemaValidationConfigs. SchemaValidationConfigs must contain at most one KEY/VALUE Attribute.
Résolution : Supprimez les attributs KEY ou VALUE dupliqués de votre SchemaValidationConfigs. Chaque type d'attribut ne peut apparaître qu'une seule fois.
- Configuration de validation manquante
-
Message d'erreur :
SchemaValidationConfigs is a required field for SchemaRegistryConfig.
Solution : Ajoutez SchemaValidationConfigs à votre configuration en spécifiant au moins un attribut de validation (KEY ou VALUE).
Erreurs d'accès et d'autorisation
Ces erreurs se produisent lorsque Lambda ne peut pas accéder au registre du schéma en raison de problèmes d'autorisation ou d'authentification.
- AWS Glue Accès au registre du schéma refusé
-
Message d'erreur :
Cannot access Glue Schema with provided role. Please ensure the provided role can perform the GetRegistry and GetSchemaVersion Actions on your schema.
Solution : Ajoutez les autorisations requises (
glue:GetRegistry
etglue:GetSchemaVersion
) au rôle d'exécution de votre fonction. - Accès au registre du schéma Confluent refusé
-
Message d'erreur :
Cannot access Confluent Schema with the provided access configuration.
Solution : Vérifiez que vos informations d'authentification (stockées dans Secrets Manager) sont correctes et que vous disposez des autorisations nécessaires pour accéder au registre des schémas.
- Registre des AWS Glue schémas entre comptes
-
Message d'erreur :
Cross-account Glue Schema Registry ARN not supported.
Solution : utilisez un registre de AWS Glue schémas enregistré dans le même AWS compte que votre fonction Lambda.
- Registre de AWS Glue schémas interrégional
-
Message d'erreur :
Cross-region Glue Schema Registry ARN not supported.
Solution : utilisez un registre de AWS Glue schémas situé dans la même région que votre fonction Lambda.
- Problèmes d'accès secret
-
Message d'erreur :
Lambda received InvalidRequestException from Secrets Manager.
Solution : Vérifiez que le rôle d'exécution de votre fonction est autorisé à accéder au secret et que celui-ci n'est pas chiffré avec une AWS KMS clé par défaut si vous y accédez depuis un autre compte.
Erreurs de connexion
Ces erreurs se produisent lorsque Lambda ne parvient pas à établir une connexion au registre du schéma.
- Problèmes de connectivité VPC
-
Message d'erreur :
Cannot connect to your Schema Registry. Your Kafka cluster's VPC must be able to connect to the schema registry. You can provide access by configuring AWS PrivateLink or a NAT Gateway or VPC Peering between Kafka Cluster VPC and the schema registry VPC.
Solution : configurez votre réseau VPC pour autoriser les connexions au registre de schéma à l'aide AWS PrivateLink d'une passerelle NAT ou d'un peering VPC.
- Échec de la poignée de main TLS
-
Message d'erreur :
Unable to establish TLS handshake with the schema registry. Please provide correct CA-certificate or client certificate using Secrets Manager to access your schema registry.
Solution : Vérifiez que vos certificats CA et vos certificats clients (pour les MTL) sont corrects et correctement configurés dans Secrets Manager.
- Limitation
-
Message d'erreur :
Receiving throttling errors when accessing the schema registry. Please increase API TPS limits for your schema registry.
Résolution : augmentez les limites de débit d'API pour votre registre de schémas ou réduisez le taux de demandes provenant de votre application.
- Erreurs de registre de schéma autogérées
-
Message d'erreur :
Lambda received an internal server an unexpected error from the provided self-managed schema registry.
Solution : Vérifiez l'état et la configuration de votre serveur de registre de schémas autogéré.