Logo Performance HubPerformance Hub
Section du site : Documentation

Exemples d'enquête

Sur cette page

Ces exemples montrent comment répondre à des questions courantes avec les Journaux d'audit. Chacun présente la question, les filtres et les clics à utiliser, ainsi que les éléments à rechercher. Les mêmes étapes fonctionnent sur tout type de site : adaptez les filtres à votre propre question.

Référence rapide

Où le trouver : Paramètres (icône en forme d'engrenage, en bas à gauche) → Journaux d'audit

Qui peut l'utiliser : vous devez disposer d'un rôle qui inclut les Journaux d'audit et Identity and Access Management dans votre organisation, comme Organisation Administrator. Consultez Qui peut utiliser les Journaux d'audit.

Objectif : passer d'une question aux requêtes qui y répondent

Qui a déverrouillé l'entrée principale ?

Une salle de sport ou un centre de loisirs : l'entrée principale a été déverrouillée à distance et le responsable de service veut savoir qui l'a fait et pourquoi.

  1. Dans l'onglet Logs, cliquez sur Endpoint, saisissez /api/door-gate-access/* et cliquez sur Apply. La liste n'affiche que les requêtes Door & Gate Access.
  2. Définissez Range de façon à couvrir l'heure du déverrouillage.
  3. Cliquez sur la requête dont l'endpoint se termine par /front-entrance/unlock.

L'onglet Logs filtré sur /api/door-gate-access/*, avec la requête de déverrouillage de l'entrée principale ouverteL'onglet Logs filtré sur /api/door-gate-access/*, avec la requête de déverrouillage de l'entrée principale ouverte

Figure 1 : Toutes les requêtes de porte, avec le déverrouillage de l'entrée principale ouvert

Éléments à rechercher : User indique qui a déverrouillé la porte, ici oscar.tran@example.com. Request POST Body indique le motif donné, « Member forgot access card », et Response Body indique que la porte s'est déverrouillée.

Étape suivante : consultez l'historique de la porte elle-même dans les Journaux d'accès de Door & Gate Access, qui enregistrent chaque tentative de déverrouillage de la porte, y compris depuis l'application mobile.

Pourquoi un membre du personnel n'a-t-il pas pu modifier le rôle d'une personne ?

Une clinique de kinésithérapie : une coordinatrice a essayé d'attribuer un nouveau rôle à un collègue, sans succès.

  1. Dans l'onglet Logs, cliquez sur Status et choisissez 403 Forbidden.
  2. Cliquez sur la requête 403 Forbidden correspondant à l'heure de la modification du rôle.
  3. Dans AI Error Summary, cliquez sur Generate summary.

Le résumé AI Error Summary expliquant que la personne qui effectuait la modification n'avait pas l'autorisation d'attribuer ce rôleLe résumé AI Error Summary expliquant que la personne qui effectuait la modification n'avait pas l'autorisation d'attribuer ce rôle

Figure 2 : Le résumé explique pourquoi la modification du rôle a été refusée

Éléments à rechercher : le résumé indique que la personne « does not have permission to assign that role ». Comparez-le à Response Body, qui indique « You don't have permission to assign this role. » Request POST Body indique le rôle que la personne a essayé d'attribuer.

Étape suivante : demandez à un Organisation Administrator d'effectuer la modification, ou vérifiez le rôle de la personne. Consultez Modifier les rôles d'un utilisateur et Modèles de rôles.

Notre intégration de réservation a cessé de se synchroniser pendant la nuit

Un centre aquatique ou une installation municipale : les enregistrements d'arrivée provenant du système de réservation ont cessé d'apparaître pendant la nuit.

  1. Dans l'onglet Logs, cliquez sur Endpoint, saisissez /partner/v1/* et cliquez sur Apply.
  2. Définissez Range sur Last 24 hours.
  3. Regardez le statut au début de chaque ligne, puis cliquez sur les requêtes en échec pour lire leur Response Body.

Éléments à rechercher : les requêtes portant le badge api-key provenant de integrations@example.org. Ici, la liste affiche 429 Too Many Requests, lorsque l'intégration a envoyé trop de requêtes en peu de temps, et 503 Service Unavailable. Notez quand les échecs ont commencé et si des requêtes réussies ont suivi.

Étape suivante : cliquez sur Exporter au format CSV et envoyez le fichier au partenaire d'intégration afin qu'il puisse vérifier de son côté. Consultez Exporter les journaux et la page Erreurs de la Partner API.

Un webhook ne s'est pas enregistré

Un café, un magasin ou un établissement d'hôtellerie-restauration : un responsable a configuré un webhook pour envoyer les informations des visiteurs vers un autre système, et celui-ci ne s'est pas enregistré.

  1. Dans l'onglet Logs, cliquez sur Email et saisissez l'adresse e-mail complète du responsable, ici leo.hargreaves@example.com.
  2. Repérez les deux requêtes POST effectuées lorsque le responsable a enregistré le webhook : une 400 Bad Request et une 201 Created sur le même endpoint.
  3. Cliquez sur la 400 Bad Request, puis sur la 201 Created quelques minutes plus tard, et comparez-les.

Éléments à rechercher : le Response Body de la 400 indique « url must start with https:// ». Dans son Request POST Body, l'adresse ne commence pas par https://. Dans la 201, le responsable avait ajouté https:// et le webhook s'est enregistré.

Étape suivante : pour une requête en échec, cliquez sur Generate summary afin d'obtenir une explication en langage clair. Consultez AI Error Summary.

Qu'a fait un membre du personnel sur le départ la semaine dernière ?

Un bureau ou un espace de coworking : avant le départ d'un membre du personnel, son responsable souhaite disposer d'un historique de son activité récente.

  1. Dans l'onglet Logs, cliquez sur Email et saisissez l'adresse e-mail complète de la personne.
  2. Définissez Range sur Last 7 days.
  3. Faites défiler la liste jusqu'en bas afin que toutes les requêtes se chargent. L'export n'inclut que les lignes chargées.
  4. Cliquez sur Exporter au format CSV, puis sur Export.

Éléments à rechercher : les modifications plutôt que les consultations. Définissez successivement Method sur POST, PUT, PATCH ou DELETE pour voir les requêtes qui ont créé, modifié ou supprimé des éléments. Pour tout élément inattendu, ouvrez la requête et lisez son Request POST Body.

Étape suivante : lors de son départ, supprimez ses accès. Consultez Supprimer des utilisateurs. Conservez le fichier CSV conformément à la politique de votre organisation.

Quel site a enregistré le plus de requêtes en échec ?

Un opérateur multisite : plusieurs sites ont signalé des problèmes hier, et le siège veut savoir par où commencer.

  1. Dans l'onglet Tableau de bord, définissez Window de façon à couvrir la journée.
  2. Dans Errors Over Time, cliquez sur l'intervalle où les erreurs ont été les plus nombreuses. L'onglet Logs s'ouvre avec les requêtes en échec de cette période.
  3. Cliquez sur Installation, choisissez chaque site à tour de rôle et comparez le nombre de requêtes en échec de chacun.

Éléments à rechercher : un site qui compte beaucoup plus d'échecs que les autres, ou des échecs sur un même endpoint. Ouvrez quelques-unes de ses requêtes et lisez le Response Body, ou cliquez sur Generate summary.

Étape suivante : consultez Le tableau de bord pour les autres graphiques, et Installations pour les sites de votre organisation.