Cette suite de tableaux de bord et d'alertes vous aide à maintenir de manière proactive une intégration de haute qualité avec l'écosystème Google Home. Google s'engage à aider ses partenaires à développer un écosystème de haute qualité pour tous les clients.
Le tableau de bord comporte trois sections, chacune couvrant un élément clé qui contribue à la qualité d'une intégration globale.
Métriques Google vers partenaire : mesure l'état des appels de Google vers votre backend cloud.
État du système : métriques partenaire vers Google : mesure l'état des appels de votre système vers Google.
État de l'appareil : précision de l'état : mesure la précision des états stockés dans les systèmes Google, qui sont utilisés pour répondre aux requêtes des utilisateurs.
Lorsque les métriques n'atteignent pas leurs valeurs cibles, elles sont mises en évidence en rouge pour indiquer un problème qui pourrait avoir un impact sur l'expérience utilisateur. Les informations suivantes fournissent des détails sur chaque cible et sur son importance pour vos utilisateurs.
Si le bouton suivant ne vous redirige pas directement vers le tableau de bord, vous pouvez y accéder en sélectionnant la page Présentation , puis Tableaux de bord , et enfin Tableau de bord Google Home Vitals (Cloud) dans la liste Mes tableaux de bord.
Métriques Google vers partenaire
La métrique Taux de réussite des requêtes/exécutions >= 99, 5 % mesure la fréquence à laquelle les commandes des utilisateurs sont exécutées correctement.Cela permet d'éviter les réponses de l'Assistant telles que "Je ne parviens pas à joindre l'appareil" ou de confirmer à tort une commande qui n'a pas été exécutée.
Qu'est-ce qu'une "réussite" ?
Une transaction est considérée comme une réussite si la plate-forme Google Home reçoit une réponse valide indiquant que l'action prévue a été exécutée ou que l'état demandé a été récupéré.
Les réponses qui incluent des exceptions non bloquantes (par exemple, un état SUCCESS accompagné d'une exception lowBattery) sont comptabilisées comme des transactions réussies.
La commande a atteint l'appareil et l'intent a été satisfait malgré l'avertissement.
Qu'est-ce qu'un "échec" ?
Les erreurs trouvées dans Codes d'erreur courants de la plate-forme et marquées comme Action requise du partenaire sont considérées comme des "échecs" lors du calcul des taux de réussite des requêtes et des exécutions. De plus, les erreurs trouvées dans Erreurs et exceptions sont également des "échecs", à l'exception des cas suivants :
| Exceptions d'échec | ||
|---|---|---|
| aboveMaximumLightEffectsDuration | armLevelNeeded | inOffMode |
| alreadyArmed | bagFull | lockedToRange |
| alreadyAtMax | belowMinimumLightEffectsDuration | lowBattery |
| alreadyAtMin | binFull | maxSpeedReached |
| alreadyClosed | cancelArmingRestricted | minSpeedReached |
| alreadyDisarmed | deadBattery | notSupported |
| alreadyDocked | degreesOutOfRange | Hors connexion |
| alreadyInState | deviceJammingDetected | percentOutOfRange |
| alreadyLocked | deviceNotMounted | rangeTooClose |
| alreadyOff | deviceNotReady | remoteSetDisabled |
| alreadyOn | deviceOffline | safetyShutOff |
| alreadyOpen | deviceTurnedOff | targetAlreadyReached |
| alreadyPaused | discreteOnlyOpenClose | tooManyFailedAttempts |
| alreadyStarted | functionNotSupported | valueOutOfRange |
| alreadyStopped | inAutoMode | |
| alreadyUnlocked | inEcoMode |
La métrique Latence des requêtes/exécutions (p90) <= 1 000 ms mesure le temps d'attente de l'action demandée et permet de s'assurer que les utilisateurs n'ont pas à attendre trop longtemps (par exemple, quelques secondes pour que leur lumière s'éteigne).
Statistiques relatives à la latence
La latence est un indicateur essentiel de la réactivité de votre intégration pour l'utilisateur final. Le tableau de bord suit la latence du 90e centile (P90), qui représente l'expérience de vos utilisateurs les plus "lents" (par exemple, un P90 de 800 ms signifie que 90 % des requêtes sont reconnues en 800 ms ou moins).
Google mesure la latence différemment pour les vérifications d'état et les commandes d'appareil afin de garantir la précision technique.
1. Latence des requêtes (interrogative)
Cette métrique mesure le temps d'aller-retour Cloud-to-cloud lorsque Google demande l'état actuel d'un appareil.
- Début : Google envoie une requête
action.devices.QUERYà votre URL de traitement. - Fenêtre de mesure : temps nécessaire à votre cloud pour recevoir, traiter et transmettre la réponse HTTP complète à Google.
- Fin : Google reçoit et reconnaît la charge utile de réponse finale de votre service.
2. Latence d'exécution (action)
Cette métrique mesure le temps de reconnaissance de la commande lorsque Google envoie une requête de contrôle à un appareil.
- Début : Google envoie une requête
action.devices.EXECUTEà votre URL de traitement. - Fenêtre de mesure : temps nécessaire à votre cloud pour recevoir la commande et renvoyer une réponse de reconnaissance.
- Fin : Google reçoit la réponse d'état
SUCCESS,PENDINGouOFFLINE. - Champ d'application technique : cette métrique mesure le temps de "reconnaissance de la réponse" entre le cloud de Google et le vôtre. Elle ne mesure pas le temps nécessaire au matériel physique (par exemple, une ampoule) pour effectuer le changement d'état physique, car cela implique souvent une latence du réseau maillé local en dehors du chemin cloud à cloud.
Options de réduction de la latence
Recommandations d'architecture pour le géoroutage
Si l'implémentation d'une adresse IP Anycast n'est pas possible, nous vous recommandons les alternatives économiques suivantes pour vous assurer que les utilisateurs sont desservis par le centre de données régional le plus proche.
Équilibrage de charge au niveau mondial (GLB)
Au lieu du routage statique, utilisez un équilibreur de charge d'application global (disponible auprès de la plupart des principaux fournisseurs de services cloud).
Fonctionnement : vous configurez un point d'entrée global unique (URL) situé à la périphérie du réseau. L'équilibreur de charge détecte automatiquement l'origine géographique de la requête à partir des clusters de traitement de Google et achemine le trafic vers votre backend régional opérationnel le plus proche.
Avantage : cette solution offre les performances d'Anycast avec une complexité et un coût de configuration nettement inférieurs.
DNS géolocalisé (GeoDNS)
Fonctionnement : configurez votre fournisseur DNS pour qu'il résolve votre URL de traitement en différentes adresses IP en fonction de l'emplacement géographique de la requête DNS.
Implémentation : assurez-vous que votre fournisseur DNS est optimisé pour les points de sortie de Google. Lorsque les services de traitement régionaux de Google (par exemple, aux États-Unis, dans l'UE ou en Asie) résolvent votre domaine, ils reçoivent l'adresse IP du centre de données de cette région spécifique.
Stratégies d'optimisation au niveau de la couche application
Au-delà du routage au niveau de l'infrastructure, vous pouvez implémenter les stratégies suivantes au niveau de la couche application pour réduire la latence lors du traitement des requêtes.
Méthode de proxy "Trampoline"
Si vous devez conserver un centre de données principal, utilisez des serveurs proxy régionaux légers (Trampolines) pour gérer la première prise de contact.
Google accède à votre URL globale.
Un proxy régional (par exemple, une fonction Nginx ou Lambda légère) reçoit la requête.
Le proxy transfère la charge utile via votre réseau fédérateur interne à haut débit vers la base de données principale.
Avantage : cette solution réduit le temps de "prise de contact TCP", qui est souvent le principal facteur de latence pour les requêtes longue distance.
Conseils sur la région du jeton d'accès
Lors du processus d'association de compte (OAuth), votre système peut identifier la région d'origine de l'utilisateur.
Implémentation : encodez un identifiant de région dans le
access_tokenémis pour Google. Lorsque Google envoie une requête de traitement, votre passerelle peut inspecter immédiatement le jeton et acheminer la requête vers le cluster régional approprié sans avoir à effectuer de recherche dans la base de données.
État du système : métriques partenaire vers Google
Le maintien d'un taux de réussite >= 99, 5 % permet de s'assurer que les états des appareils sont corrects dans Google Home, que les appareils sont ajoutés et supprimés, que les automatisations se déclenchent et que les événements d'historique s'affichent dans l'onglet "Activité" de l'Google Home app (GHA).
Le taux de réussite est calculé en fonction des codes de réponse HTTP renvoyés par Google lorsque votre cloud envoie des mises à jour d'état. Pour s'assurer que les partenaires ne sont pas pénalisés en cas de problèmes d'infrastructure côté Google, la métrique exclut les erreurs internes de Google du nombre d'échecs. Les appels d'API inclus dans le calcul se trouvent dans la documentation de référence de l'API HomeGraph.
Qu'est-ce qu'une "réussite" ?
- 2xx (réussite) : la mise à jour de l'état a été reçue et traitée par Home Graph.
Qu'est-ce qu'un "échec" ?
- 4xx (erreur du partenaire) : ces erreurs représentent des échecs et indiquent un problème avec la requête envoyée depuis votre cloud. Voici quelques codes courants :
- 400 Requête incorrecte : le serveur n'a pas pu traiter la requête en raison d'une syntaxe non valide. Les causes courantes incluent un JSON mal formé ou l'utilisation de la valeur "null" au lieu de "" pour une valeur de chaîne.
- 404 Introuvable : la ressource demandée est introuvable. En règle générale, cela signifie que Google ne trouve pas l'appareil demandé. Cela peut également signifier que le compte utilisateur n'est pas associé ou qu'un
agentUserIdnon valide a été reçu. Assurez-vous que l'agentUserIdcorrespond à la valeur fournie dans votre réponse SYNC et que vous gérez correctement les intentsDISCONNECT. - 429 Ressource épuisée : votre intégration a dépassé le quota alloué. Pour savoir comment gérer les quotas, consultez les instructions de l'étape 1 plus haut dans le tableau de bord.
État de l'appareil : précision de l'état
Atteindre ou dépasser une précision de l'état >= 99,5 % permet de s'assurer que les utilisateurs voient des résultats corrects lorsqu'ils consultent l'état des appareils ou utilisent des fonctionnalités d'IA telles que "Demander à Home". Si la précision de l'état est faible, les automatisations peuvent ne pas se déclencher et les entrées d'historique peuvent ne pas s'afficher dans l'onglet "Activité" de GHAau bon moment. Pour en savoir plus, consultez la section Signaler l'état.
Le tableau de bord de qualité effectue ce suivi toutes les heures à l'aide de deux métriques distinctes : Précision globale et Combinaison type/caractéristique la plus basse.
1. Composants de précision
La métrique est dérivée d'"échantillons" dans lesquels Google peut vérifier l'état signalé par rapport à un résultat d'intent connu.
2. Métriques du tableau de bord (calcul horaire)
Le tableau de bord calcule la précision sur un intervalle d'une heure. Si une heure comporte moins de 100 échantillons au total (S_Total < 100), la précision pour cette heure est définie sur N/A.
Vue 1 : Précision globale (moyenne globale)
Cette métrique représente la précision totale de votre intégration pour tous les types d'appareils et toutes les caractéristiques combinés. Elle fournit une moyenne pondérée de l'état de santé de l'ensemble de votre écosystème.
- Calcul : précision totale de l'état sur tous les appareils / total de l'état sur tous les appareils.
Vue 2 : Combinaison type/caractéristique la plus basse
Cette métrique identifie la catégorie spécifique la moins fiable de votre intégration. Elle empêche les appareils à volume élevé et de haute qualité de masquer les appareils à faible volume et de faible qualité. Par exemple, si vous avez un volume élevé de lumières avec une précision de l'état supérieure à 99,5 %, mais un faible volume d'interrupteurs avec une faible précision de l'état, cette métrique met en évidence l'amélioration nécessaire sur les interrupteurs qui peuvent être perdus dans une valeur moyenne.
- Calcul : minimum de la précision de l'état / total de l'état pour toutes les combinaisons de caractéristiques/appareils.