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.

Observabilité pour le bus d'événements personnalisé : métriques, journaux et CloudTrail

Trois sources vous indiquent ce que font un bus et ses abonnés. Les CloudWatch métriques Amazon figurant dans l'AWS/EventsV2espace de noms sont activées pour chaque abonné ; pour vous avertir en cas d'échec des livraisons, utilisez le calcul OnFailureDestinationDelivered des EventsDropped métriques pour signaler EventDeliveryAttempts un échec EventsDelivered de livraison. Les journaux des abonnés enregistrent chaque tentative de livraison sous forme d'enregistrement JSON ; ils sont désactivés jusqu'à ce que vous LogConfiguration.Level sélectionniez l'abonné. AWS CloudTrail enregistre les appels d'API qui créent et modifient les bus, les abonnés et les sources d'événements.

Métriques

Les métriques des abonnés comportent deux dimensionsSubscriber, EventBus chacune contenant l'ARN de la ressource. Lorsque l'abonné appartient à un compte différent de celui du bus, émet EventBridge également la métrique avec EventBus et SubscriberAccount afin que le propriétaire du bus puisse voir la consommation par compte. Le tableau suivant répertorie les métriques .

Le nombre de bus de votre compte est également indiqué dans l'AWS/Usageespace de noms ResourceCount avec Service EventBridge et une Resource valeur commençant parEventsV2/, afin que vous puissiez émettre une alarme lorsque vous approchez du quota de bus. Pour les quotas, voirQuotas de bus événementiels personnalisés.

Publication de métriques

Chaque PutRawEvents appel PutEvents and produit également des métriques dans l'AWS/EventsV2espace de noms, ce qui vous permet de lancer une alerte en cas d'appels de publication limités ou échoués pour un bus, par exemple un appel PublishEventsApproximateThrottledCallCount dont la EventBus dimension est définie sur. orders Le compte du propriétaire du bus reçoit toutes les statistiques publiées. Un compte qui publie sur un bus dont il n'est pas propriétaire les reçoit également, sur son propre compte, pour ses propres appels.

Les dimensions dépendent de la métrique et de l'auteur de la publication.

Journaux des abonnés

Un abonné peut enregistrer ce qui s'est passé lors de chaque événement qu'il a essayé de diffuser. La journalisation se fait par abonné et est désactivée lorsque vous en créez un, de sorte qu'un nouvel abonné n'enregistre rien tant que vous ne l'avez pas configuréLogConfiguration. Chaque enregistrement est un document JSON avec un message_type qui indique ce qu'il décrit.

La livraison des grumes constitue le meilleur effort. Un enregistrement qui ne peut pas être écrit est compté dans la SubscriberLogRecordsDropped métrique au lieu d'être réessayé indéfiniment. Lorsque le bus est chiffré à l'aide d'une clé gérée par le client, EventBridge crypte les champs de charge utile de chaque enregistrement sous cette clé avant son départ EventBridge, de sorte qu'un compte de destination qui ne peut pas utiliser la clé voit l'enregistrement sans cette clé. Le record d'un événement rejoué est conservé details.delivery_type REPLAY ; celui d'un événement en direct est conservé. LIVE

Les deux paramètres qui produisent un enregistrement

Deux paramètres indépendants doivent exister pour que vous puissiez lire un seul enregistrement.

Définissez les deux paramètres avant de commencer à diagnostiquer un problème de livraison plutôt qu'après. Seuls les abonnés disposent d'une configuration de journal. Les bus et les sources d'événements n'en ont aucune. Vous activez donc la connexion d'un abonné à la fois. LogConfigurationcompte deux membres.

Vous pouvez définir le LogConfiguration moment où vous créez un abonné, ou plus tard avecUpdateSubscriber. Une mise à jour prend effet sans recréer l'abonné. Ni la réponse de création ni la réponse de mise à jour ne renvoient le champ en écho, alors confirmez la valeur stockée avecDescribeSubscriber, qui la renverra.

Activer la journalisation pour un abonné

Les étapes suivantes enregistrent chaque tentative de livraison pour un abonné existant et transmettent les enregistrements à un groupe de CloudWatch journaux du même compte. La première commande est un EventBridge appel et les autres sont des appels CloudWatch Logs. Commencez par augmenter le niveau de connexion de l'abonné. INFOenregistre les succès comme les échecs, ce qui vous permet de savoir si un événement a été organisé.

aws eventsv2 update-subscriber \
    --subscriber-arn arn:aws:events:us-east-1:111122223333:subscriber/large-orders/EXAMPLE1234567890abcdef \
    --log-configuration '{ "Level": "INFO", "IncludePayload": "FULL" }'

Créez ensuite le groupe de journaux de destination. Le nom doit commencer par/aws/vendedlogs/. CloudWatch Logs gère la politique de ressources de diffusion pour vous uniquement sous ce préfixe ; pour un groupe de journaux en dehors de celui-ci, vous devez gérer cette politique vous-même.

aws logs create-log-group \
    --log-group-name /aws/vendedlogs/large-orders-delivery

Créez une source de diffusion. C'--resource-arnest l'ARN de l'abonné, qui permet à la source de produire les enregistrements de cet abonné. Réglez --log-type en fonction du niveau que vous avez configuré : INFO_LOGS pour Level INFO ou ERROR_LOGS pour LevelERROR.

aws logs put-delivery-source \
    --name large-orders-source \
    --resource-arn arn:aws:events:us-east-1:111122223333:subscriber/large-orders/EXAMPLE1234567890abcdef \
    --log-type INFO_LOGS

Créez une destination de livraison en nommant le groupe de journaux. La réponse contient l'ARN de destination, dont la commande suivante a besoin.

aws logs put-delivery-destination \
    --name large-orders-destination \
    --delivery-destination-configuration destinationResourceArn=arn:aws:logs:us-east-1:111122223333:log-group:/aws/vendedlogs/large-orders-delivery

Enfin, associez la source à la destination. Utilisez l'ARN de destination de la réponse précédente.

aws logs create-delivery \
    --delivery-source-name large-orders-source \
    --delivery-destination-arn destination-arn

Les enregistrements apparaissent désormais dans le groupe de journaux. Ils arrivent plus tard que la livraison elle-même, car le pipeline de journaux les regroupe. Tenez donc compte de ce décalage lorsque vous lisez un groupe de journaux juste après la publication. Trois propriétés de ce câblage déterminent jusqu'où il s'étend. Une destination est un groupe de journaux, un compartiment Amazon S3 ou un flux Amazon Data Firehose, et les commandes ci-dessus sont les mêmes pour chacun : seules les destinationResourceArn modifications sont effectuées. Une diffusion associe exactement une source à exactement une destination, de sorte que l'envoi des enregistrements d'un abonné vers une deuxième destination entraîne une deuxième livraison. La destination peut se trouver PutDeliveryDestinationPolicy sur un compte différent de celui de l'abonné. Dans ce cas, le compte de destination doit appeler la destination pour autoriser la livraison. C'est ainsi qu'un compte central collecte les enregistrements des abonnés dont il n'est pas propriétaire.

Lire un relevé de livraison

EventBridge émet un enregistrement par tentative de livraison et par événement. Quatre domaines se situent au plus haut niveau. message_typeest EVENT_DELIVERY_ATTEMPT destiné à une tentative de livraison ; les autres types sont répertoriés au début de cette section. resource_arnest l'ARN de l'abonné qui a effectué la tentative. C'est ainsi que vous séparez les abonnés qui partagent un même groupe de journaux. log_levelest le niveau de l'enregistrement lui-même : une tentative réussie l'est INFO et une tentative échouée l'estERROR, c'est pourquoi les échecs Level ERROR sont toujours enregistrés. detailsest un objet contenant l'état de livraison et les champs sur lesquels vous créez des requêtes et des alarmes.

Pour diagnostiquer une livraison qui n'est jamais arrivée, lisez les dossiers de l'abonné dans cet ordre. outcomeindique si l'objectif EventBridge a été atteint. attempt_countindique s'il est toujours en train de réessayer, car un événement sans terminal_kind enregistrement n'est pas terminé. terminal_kindindique comment cela s'est terminé et sépare un événement en lettre morte de celui qui a été abandonné. target_arntarget_properties, et indiquez ce target_input qui a été envoyé et où, c'est là qu'un problème de transformateur ou de paramètre cible apparaît. Un échec est visible dans l'enregistrement dès que la tentative échoue, vous n'avez donc pas à attendre que les nouvelles tentatives soient terminées. Pour obtenir la procédure complète, consultez Résolution des problèmes : vous avez publié et rien n'est arrivé à la cible.

Charges utiles dans les enregistrements de journal

IncludePayloadcontrôle deux champs et aucun autre : details.target_input etdetails.event_detail. Tous les autres champs sont émis, quelle que soit la valeur que vous choisissez. Ainsi, un abonné qui exclut les charges utiles de ses enregistrements indique toujours le résultat, la cible, le nombre de tentatives et les latences. FULLintègre la charge utile dans chaque enregistrement, y compris les enregistrements des livraisons réussies. ON_ERROR_ONLY, la valeur par défaut, l'intègre uniquement dans les enregistrements d'échecs et omet les deux champs d'un enregistrement pour une livraison réussie.

Appels d'API entrants AWS CloudTrail

L'abonné enregistre les livraisons, et non les appels que vous passez pour les configurer. AWS CloudTrail enregistre les appels d'API de gestion, de sorte qu'une modification apportée à un bus, à un abonné ou à une source d'événements peut être auditée à partir de votre historique plutôt que d'un groupe de journaux. Pour savoir comment EventBridge s'intègre à CloudTrail, voirJournalisation des appels Amazon EventBridge d'API à l'aide AWS CloudTrail.