Surveillance des applications

Vos applications et services dépendent d’Auth0. La surveillance de l’état de santé d’Auth0 vous permet de signaler des erreurs spécifiques aux clients ou de réduire l’impact sur les utilisateurs en cas de problème avec Auth0.

Il existe de nombreuses façons de surveiller Auth0 et chaque approche est complémentaire. Vous devez choisir en fonction de vos besoins et de vos possibilités d’investissement.

L’approche la plus simple pour surveiller Auth0 :

• Mettre en place une requête périodique pour effectuer une transaction d’authentification.

• Si la demande aboutit, Auth0 fonctionne correctement.

• Si la demande échoue, cela peut indiquer :

  • un problème avec Auth0

  • un problème spécifique au locataire utilisé pour la transaction synthétique

  • ou simplement une demande qui a échoué.

Pour les transactions synthétiques, utilisez un environnement aussi proche que possible de la configuration de votre locataire de production. Vous pouvez même utiliser le même locataire de production. Étant donné que la mise en place de transactions synthétiques avec des flux de redirection et des fournisseurs tiers peut s’avérer délicate, il est recommandé d’utiliser le Octroi par mot de passe du propriétaire de la ressource. Ce flux n’implique pas de redirections de navigateur et ne nécessite pas d’interface utilisateur.

Si vous utilisez les règles ou des connexions personnalisées à la base de données ou d’autres points d’extension, la ou les transactions synthétiques doivent être configurées de manière à utiliser les règles et/ou les scripts personnalisés de la base de données afin de garantir le bon fonctionnement de cet aspect du système.

Des outils tels que Pingdom simplifient la configuration des transactions synthétiques.

Nous recommandons d’exécuter des transactions synthétiques à intervalles d’une minute. Avec cette approche simple, cette fréquence ne consommera pas beaucoup de votre quota de limite anti-attaques Auth0, tout en fournissant des réponses opportunes.

Les transactions synthétiques sont un moyen simple et peu coûteux de contrôler la santé d’un locataire Auth0. Cependant, elles présentent certaines limitations :

• Les transactions synthétiques ne représentent pas l’expérience de l’utilisateur final. Au lieu de cela, elles vous donnent une mesure de substitution pour eux.

• Les transactions synthétiques peuvent ne pas utiliser les mêmes flux que vos utilisateurs.

• Elles manquent d’atomicité (elles sont généralement exécutées une fois par minute) et ne rendent pas compte des erreurs que vos utilisateurs finaux auraient pu constater.

Si vous souhaitez obtenir des données plus granulaires, lisez Suivi des erreurs et Mesures et journaux.

Cette approche est utile pour suivre les erreurs dans les appels existants à Auth0. Elle consiste à signaler les erreurs chaque fois qu’un appel à Auth0 échoue. Sentry est un outil couramment utilisé pour ces cas, qui fonctionne à la fois sur les scénarios du côté client et dorsaux.

Cette approche est utile car elle vous permet de connaître les erreurs réelles que rencontrent vos utilisateurs finaux. Cependant, comme vous ne suivez que les erreurs (et non toutes les demandes), il n’est pas possible d’avoir une perception précise du « nombre » d’utilisateurs finaux concernés : s’agit-il de 1 % ou de 5 %? Il n’est pas non plus nécessaire de mettre en place un « appel synthétique » distinct, qui pourrait consommer une partie de votre quota de limite anti-attaques, surtout s’il est mal configuré.

Cette approche est utile si les appels à Auth0 sont effectués à partir d’un système dorsal que vous contrôlez. C’est le cas pour :

• la plupart des appels à l’Auth0 Management API

• les appels à l’Authentication API à partir d’applications Web classiques et d’applications de communication entre machines (en savoir plus sur les types de clients).

L’approche consiste à utiliser des métriques et/ou des journaux pour suivre les taux d’erreur sur les appels à Auth0. Les métriques/journaux rapportent les taux d’erreur qui décrivent précisément ce que les utilisateurs finaux rencontrent, sans vous obliger à mettre en place un « appel synthétique » séparé, qui pourrait consommer une partie de votre quota de limite anti-attaques, en particulier s’il est mal configuré.

Quelles que soient les méthodes de surveillance que vous utilisez, il est courant de recevoir une alerte ou une page lorsque des erreurs se produisent à un taux particulier. Ce taux dépend de votre application.

Lorsque votre équipe reçoit une alerte d’Auth0, nous recommandons d’ajouter un lien vers Vérifier l’état d’Auth0 à la charge utile/ « playbook » de l’alerte. Cela leur permettra de vérifier rapidement le canal officiel de rapport d’état d’Auth0 pour voir si le problème provient d’Auth0 ou de votre application/service.

• Vérifier l’état d’Auth0
• Vérifier l’état des services externes
• Surveiller Auth0 à l’aide du Gestionnaire des opérations du centre de système