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/EventsV2`espace 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 dimensions`Subscriber`, `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 .
| Métrique | Unit | Signification |
| --- | --- | --- |
| FilterEvaluated | Nombre | Événements évalués par rapport aux filtres de l'abonné |
| FilterMatched | Nombre | Événements correspondant à tous les filtres |
| EventDeliveryAttempts | Nombre | Tentatives de livraison, comptées par événement. Soustrayez EventsDelivered pour compter les tentatives infructueuses |
| TargetInvocations | Nombre | Appels adressés à la cible ; un appel peut contenir un lot d'événements |
| RetryInvocationAttempts | Nombre | Émis uniquement lors d'une nouvelle tentative, évalué comme la profondeur de la nouvelle tentative : la deuxième tentative est 1, la troisième est 2. Le nombre d'échantillons est le nombre de nouvelles tentatives |
| EventsDelivered | Nombre | Événements acceptés par la cible |
| EgressBytes | Octets | Octets transmis à la cible |
| EventTransformationFailures | Nombre | Événements dont l'Transformerexpression cible universelle a échoué Input |
| IngestionToInvocationStartTime | Millisecondes | Temps écoulé entre l'arrivée de l'événement dans le bus et le début de l'appel cible. Non émis lorsque la tentative a échoué avant d'appeler la cible |
| IngestionToInvocationEndTime | Millisecondes | Temps écoulé entre l'arrivée de l'événement dans le bus et la fin de l'appel cible |
| OnFailureDestinationDelivered | Nombre | Enregistrements écrits dans la file d'attente des lettres mortes |
| OnFailureDestinationFailed | Nombre | Enregistrements qui n'ont pas pu être écrits dans la file d'attente de lettres mortes |
| EventsDropped | Nombre | Événements qui ont épuisé les nouvelles tentatives sans file d'attente pour les enregistrer |
| ApproximateBacklogAge | Millisecondes | Âge de l'événement le plus ancien que l'abonné n'a pas encore organisé |
| SubscriberLogRecordsDropped | Nombre | Enregistrez les enregistrements qui n'ont pas pu être écrits, car la livraison du journal est la meilleure solution |
Le nombre de bus de votre compte est également indiqué dans l'`AWS/Usage`espace de noms `ResourceCount` avec `Service` `EventBridge` et une `Resource` valeur commençant par`EventsV2/`, afin que vous puissiez émettre une alarme lorsque vous approchez du quota de bus. Pour les quotas, voir[Quotas de bus événementiels personnalisés](eb-quota.md#eb-custom-bus-quotas).
## Publication de métriques
Chaque `PutRawEvents` appel `PutEvents` and produit également des métriques dans l'`AWS/EventsV2`espace 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.
| Métrique | Unit | Signification |
| --- | --- | --- |
| PublishEventsApproximateCallCount | Nombre | Publier les appels reçus |
| PublishEventsApproximateSuccessCallCount | Nombre | Publier les appels qui ont renvoyé le protocole HTTP 200 |
| PublishEventsApproximateFailedCallCount | Nombre | Publier les appels qui ont renvoyé une erreur |
| PublishEventsApproximateThrottledCallCount | Nombre | Publiez les appels rejetés avec ThrottlingException |
| PublishEventsEntryCount | Nombre | Participations aux appels de publication |
| PublishEventsFailedEntriesCount | Nombre | Entrées ayant échoué lors d'un appel accepté, signalées dans la réponse comme entrées ayant échoué |
| PublishEventsIngressBytes | Octets | Octets de charge utile d'événements stockés. Absent, plutôt que 0, pour les appels qui ne stockaient rien. Tendances liées à la ligne d'entrée de votre facture, qui arrondit chaque entrée à un Ko entier. |
Les dimensions dépendent de la métrique et de l'auteur de la publication.
+ Chaque métrique est publiée avec la seule `EventBus` dimension : les totaux du bus.
+ Pour les événements qui arrivent via une source d'événements, les mesures de comptage sont également publiées avec `EventBus` et`EventSource`, afin que vous puissiez voir la part d'une source. `PublishEventsIngressBytes`n'a pas de `EventSource` panne.
+ `PublishEventsIngressBytes`est également publié au propriétaire du bus avec `EventBus` et`PublisherAccount`, afin que celui-ci puisse voir le nombre d'octets stockés par chaque compte de 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.
+ `SUBSCRIBER_MATCHED`: un événement correspond aux filtres de l'abonné et est entré en livraison.
+ `EVENT_DELIVERY_ATTEMPT`: une tentative pour invoquer la cible, avec son résultat, son nombre de tentatives et sa durée. Il s'agit de l'enregistrement décrit dans le reste de cette section.
+ `EVENT_TRANSFORMATION_FAILURE`: l'`Input`expression `Transformer` ou la cible universelle a échoué pour un événement, avec l'erreur.
+ `ON_FAILURE_DESTINATION_DELIVERY_ATTEMPT`: une tentative d'écriture d'un enregistrement dans la file d'attente des lettres mortes.
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.
1. **Le niveau de journalisation de l'abonné. **`LogConfiguration.Level`décide quels enregistrements sont EventBridge émis. Sa valeur par défaut est`OFF`, ce qui n'en émet aucune.
1. **Une livraison de CloudWatch journaux. ** Les enregistrements vous parviennent via le mécanisme de distribution automatique CloudWatch des journaux Amazon Logs, qui associe l'abonné à une destination qui vous appartient. Sans elle, les enregistrements n'ont nulle part où atterrir et aucun groupe de journaux n'apparaît seul.
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. `LogConfiguration`compte deux membres.
`Level`
Le niveau minimum d'un enregistrement. Les enregistrements situés en dessous ne sont pas émis. `OFF`, la valeur par défaut, n'émet rien. `ERROR`émet uniquement des tentatives de livraison infructueuses. `INFO`émet chaque tentative de livraison, y compris celles qui ont réussi.
`IncludePayload`
Indique si un enregistrement contient la charge utile de votre événement. `ON_ERROR_ONLY`, la valeur par défaut, l'affiche uniquement sur les enregistrements de défaillances. `FULL`l'affiche sur tous les disques. Consultez [Charges utiles dans les enregistrements de journal](#eb-custom-bus-observability-payload).
Vous pouvez définir le `LogConfiguration` moment où vous créez un abonné, ou plus tard avec`UpdateSubscriber`. 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 avec`DescribeSubscriber`, 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é. `INFO`enregistre 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-arn`est 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 `Level``ERROR`.
```
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_type`est `EVENT_DELIVERY_ATTEMPT` destiné à une tentative de livraison ; les autres types sont répertoriés au début de cette section. `resource_arn`est 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_level`est le niveau de l'enregistrement lui-même : une tentative réussie l'est `INFO` et une tentative échouée l'est`ERROR`, c'est pourquoi les échecs `Level` `ERROR` sont toujours enregistrés. `details`est un objet contenant l'état de livraison et les champs sur lesquels vous créez des requêtes et des alarmes.
`outcome` et `attempt_count`
`SUCCESS`ou `FAILURE` pour cette tentative, et de quelle tentative il s'agissait, les nouvelles tentatives sont dénombrables.
`terminal_kind`
Présent sur le seul enregistrement qui indique comment l'événement s'est terminé : `EVENTS_DELIVERED``ON_FAILURE_DESTINATION_DELIVERED`, ou `EVENTS_DROPPED` lorsque les nouvelles tentatives ont été épuisées et qu'aucune destination en cas d'échec n'a été configurée.
`target_arn` et `target_properties`
La cible visée par la tentative et les paramètres cibles que l'abonné a résolus pour cet événement. `target_properties`est omis lorsque l'abonné ne configure aucun paramètre.
`ingestion_to_start_latency_ms` et `ingestion_to_complete_latency_ms`
Millisecondes entre l'ingestion de l'événement et le début et la fin de cette tentative.
`target_input`
Les octets envoyés à la cible, mot pour mot. Il s'agit d'un champ de charge utile ; voir[Charges utiles dans les enregistrements de journal](#eb-custom-bus-observability-payload).
`event_detail`, `event_metadata` et `event_system_metadata`
L'événement EventBridge s'est déroulé comme il se doit. `event_system_metadata`contient les identifiants par lesquels vous corrélez les enregistrements. `event_detail`n'apparaît que lorsqu'il diffère de`target_input`, ce qui est le cas lorsque l'abonné dispose d'un transformateur.
Pour diagnostiquer une livraison qui n'est jamais arrivée, lisez les dossiers de l'abonné dans cet ordre. `outcome`indique si l'objectif EventBridge a été atteint. `attempt_count`indique s'il est toujours en train de réessayer, car un événement sans `terminal_kind` enregistrement n'est pas terminé. `terminal_kind`indique comment cela s'est terminé et sépare un événement en lettre morte de celui qui a été abandonné. `target_arn``target_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](eb-custom-bus-subscribers.md#eb-custom-bus-subscribers-nothing-arrived).
### Charges utiles dans les enregistrements de journal
`IncludePayload`contrôle deux champs et aucun autre : `details.target_input` et`details.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. `FULL`intè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.
**Important**
Un enregistrement de journal contenant une charge utile contient vos données. Avec`FULL`, le groupe de journaux contient une copie de chaque corps d'événement envoyé par l'abonné, et toute personne capable de lire le groupe de journaux peut lire ces corps. `FULL`Utilisez-le pendant que vous débugez un abonné, puis renvoyez-le à`ON_ERROR_ONLY`. Cela limite à la fois l'exposition et le volume que vous stockez.
## 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, voir[Journalisation des appels Amazon EventBridge d'API à l'aide AWS CloudTrail](logging-using-cloudtrail.md).