Google Home Vitals (Cloud)

Diese Dashboards und Benachrichtigungen helfen Ihnen, proaktiv eine hochwertige Integration in das Google Home-Ökosystem aufrechtzuerhalten. Google unterstützt Partner bei der Entwicklung eines hochwertigen Ökosystems für alle Kunden.

Das Dashboard enthält drei Abschnitte, die jeweils einen wichtigen Aspekt abdecken, der zur Qualität einer Integration beiträgt.

  1. Messwerte für die Kommunikation zwischen Google und Partner: Hier wird der Zustand von Aufrufen von Google an Ihr Cloud-Backend gemessen.

  2. System Health – Partner to Google Metrics (Systemstatus – Partner-zu-Google-Messwerte): Hier wird der Status von Aufrufen von Ihrem System an Google gemessen.

  3. Gerätezustand – Genauigkeit des Status: Misst die Genauigkeit der in Google-Systemen gespeicherten Status, die zur Bearbeitung von Nutzeranfragen verwendet werden.

Wenn Messwerte ihre Zielwerte nicht erreichen, werden sie rot hervorgehoben, um auf ein Problem hinzuweisen, das sich auf die Nutzerfreundlichkeit auswirken könnte. Die folgenden Informationen enthalten Details zu den einzelnen Zielen und dazu, warum sie für Ihre Nutzer wichtig sind.

Wenn Sie über die folgende Schaltfläche nicht direkt zum Dashboard gelangen, können Sie es aufrufen, indem Sie die Seite Übersicht auswählen, dann Dashboards und in der Liste Meine Dashboards das Google Home Vitals Dashboard (Cloud) auswählen.

Zum Dashboard

Messwerte von Google an Partner

Mit der Messwert Erfolgsrate bei Anfragen/Ausführungen >= 99,5% wird gemessen, wie oft Nutzerbefehle korrekt ausgeführt werden.So werden Assistant-Antworten wie „Ich kann das Gerät nicht erreichen“ oder die fälschliche Bestätigung eines Befehls, der nicht ausgeführt wurde, vermieden.

Was definiert einen „Erfolg“?

Eine Transaktion wird als erfolgreich markiert, wenn die Google Home-Plattform eine gültige Antwort erhält, die angibt, dass die beabsichtigte Aktion ausgeführt oder der angeforderte Status abgerufen wurde.

Antworten, die nicht blockierende Ausnahmen enthalten (z. B. ein SUCCESS-Status in Verbindung mit einer lowBattery-Ausnahme), werden als erfolgreiche Transaktionen gezählt. Der Befehl wurde vom Gerät empfangen und der Intent wurde trotz der Warnung ausgeführt.

Was ist ein „Fehler“?

Die Fehler, die unter Gängige Plattformfehlercodes als Partner Actionable gekennzeichnet sind, werden bei der Berechnung der Erfolgsraten für QUERY und EXECUTE als „Fehler“ betrachtet.

Der Messwert Latenz bei Abfrage/Ausführung (p90) <= 1.000 ms misst die Wartezeit für angeforderte Aktionen und trägt dazu bei, dass Nutzer nicht zu lange warten müssen, z. B. einige Sekunden, bis das Licht ausgeschaltet wird.

Latenzmesswerte

Die Latenz ist ein wichtiger Indikator dafür, wie schnell Ihre Integration für den Endnutzer reagiert. Im Dashboard wird die P90-Latenz (90. Perzentil) erfasst. Sie gibt an, wie die „langsamsten“ Nutzer die Latenz wahrnehmen. Ein P90-Wert von 800 ms bedeutet beispielsweise, dass 90% der Anfragen innerhalb von 800 ms oder weniger beantwortet werden.

Google misst die Latenz für Statusprüfungen und Gerätebefehle unterschiedlich, um die technische Genauigkeit zu gewährleisten.

1. ABFRAGELATENZ (FRAGESTELLEND)

Damit wird die Cloud-to-cloud-Umlaufzeit gemessen, wenn Google den aktuellen Status eines Geräts anfordert.

  • Start: Google sendet eine action.devices.QUERY-Anfrage an Ihre Fulfillment-URL.
  • Messzeitraum: Die Zeit, die Ihre Cloud benötigt, um die vollständige HTTP-Antwort zu empfangen, zu verarbeiten und an Google zurückzusenden.
  • Ende: Google empfängt und bestätigt die Nutzlast der endgültigen Antwort von Ihrem Dienst.

2. EXECUTE-Latenz (Aktion)

Damit wird die Zeit gemessen, die vergeht, bis ein Befehl bestätigt wird, wenn Google eine Steuerungsanfrage an ein Gerät sendet.

  • Start: Google sendet eine action.devices.EXECUTE-Anfrage an Ihre Fulfillment-URL.
  • Messzeitraum: Die Zeit, die deine Cloud benötigt, um den Befehl zu empfangen und eine Bestätigungsantwort zurückzugeben.
  • Ende: Google erhält die Statusantwort SUCCESS, PENDING oder OFFLINE.
  • Technischer Umfang: Mit dieser Messgröße wird die Zeit für die „Antwortbestätigung“ zwischen der Cloud von Google und Ihrer Cloud gemessen. Es wird nicht die Zeit gemessen, die die physische Hardware (z. B. eine Glühbirne) benötigt, um den physischen Status zu ändern, da dies oft eine lokale Mesh-Netzwerklatenz außerhalb des Cloud-to-Cloud-Pfads beinhaltet.

Optionen zur Latenzreduzierung

Architekturempfehlungen für das geografische Routing

Wenn die Implementierung von Anycast-IP nicht möglich ist, empfehlen wir die folgenden kostengünstigen Alternativen, um sicherzustellen, dass Nutzer vom nächstgelegenen regionalen Rechenzentrum bedient werden.

  1. Global Load Balancing (GLB)

    Verwenden Sie anstelle von statischem Routing einen globalen Application Load Balancer (bei den meisten großen Cloud-Anbietern verfügbar).

    • Funktionsweise:Sie konfigurieren einen einzelnen globalen Einstiegspunkt (URL) am Netzwerkrand. Der Load-Balancer erkennt automatisch den geografischen Ursprung der Anfrage aus den Fulfillment-Clustern von Google und leitet den Traffic an das nächstgelegene regionale fehlerfreie Back-End weiter.

    • Vorteil:Diese Option bietet die Leistung von Anycast mit deutlich geringerer Konfigurationskomplexität und geringeren Kosten.

  2. Standortbezogenes DNS (GeoDNS)

    • Funktionsweise:Konfigurieren Sie Ihren DNS-Anbieter so, dass Ihre Fulfillment-URL basierend auf dem geografischen Standort der DNS-Anfrage in verschiedene IP-Adressen aufgelöst wird.

    • Implementierung:Ihr DNS-Anbieter muss für die Egress-Punkte von Google optimiert sein. Wenn die regionalen Fulfillment-Dienste von Google (z. B. in den USA, der EU oder Asien) Ihre Domain auflösen, erhalten sie die IP-Adresse für das Rechenzentrum in der jeweiligen Region.

Optimierungsstrategien auf der Anwendungsebene

Neben dem Routing auf Infrastrukturebene können Sie die folgenden Strategien auf Anwendungsebene implementieren, um die Latenz bei der Anfrageverarbeitung zu reduzieren.

  1. Die Proxy-Methode „Trampolin“

    Wenn Sie ein primäres Rechenzentrum betreiben müssen, verwenden Sie regionale Lightweight-Proxyserver (Trampolines), um den ersten Handshake zu verarbeiten.

    1. Google ruft Ihre globale URL auf.

    2. Ein regionaler Proxy (z. B. eine einfache Nginx- oder Lambda-Funktion) empfängt die Anfrage.

    3. Der Proxy leitet die Nutzlast über Ihr internes Hochgeschwindigkeits-Backbone an die primäre Datenbank weiter.

    Vorteil:Dadurch wird die Zeit für den TCP-Handshake verkürzt, die bei Anfragen über große Entfernungen oft den größten Beitrag zur Latenz leistet.

  2. Hinweise zur Region für Zugriffstokens

    Während der Kontoverknüpfung (OAuth) kann Ihr System die Wohnregion des Nutzers ermitteln.

    Implementierung:Codieren Sie eine Regions-ID in der access_token, die an Google ausgegeben wird. Wenn Google eine Erfüllungsanfrage sendet, kann Ihr Gateway das Token sofort prüfen und die Anfrage an den richtigen regionalen Cluster weiterleiten, ohne dass eine Datenbanksuche erforderlich ist.

Systemzustand – Partner- zu Google-Messwerte

Wenn du eine Erfolgsrate von mindestens 99,5% beibehältst, wird sichergestellt, dass Gerätestatus in Google Home korrekt sind, Geräte hinzugefügt und entfernt werden, Automatisierungen ausgelöst werden und Verlaufsereignisse auf dem Tab „Aktivität“ des Google Home app (GHA) angezeigt werden.

Die Erfolgsrate wird anhand der HTTP-Antwortcodes berechnet, die von Google zurückgegeben werden, wenn deine Cloud Statusaktualisierungen sendet. Damit Partner nicht für Infrastrukturprobleme auf Google-Seite bestraft werden, werden interne Google-Fehler aus der Anzahl der Fehler ausgeschlossen. Die in die Berechnung einbezogenen API-Aufrufe finden Sie in der HomeGraph API-Referenz.

Was definiert einen „Erfolg“?

  • 2xx (Erfolg): Die Statusaktualisierung wurde von Home Graph erfolgreich empfangen und verarbeitet.

Was ist ein „Fehler“?

  • 4xx (Partnerfehler): Diese Fehler weisen auf ein Problem mit der Anfrage hin, die von Ihrer Cloud gesendet wurde. Häufige Codes sind:
    • 400 Bad Request: Der Server konnte die Anfrage aufgrund einer ungültigen Syntax nicht verarbeiten. Häufige Ursachen sind fehlerhaftes JSON oder die Verwendung von „null“ anstelle von „“ für einen Stringwert.
    • 404 Not Found: Die angeforderte Ressource wurde nicht gefunden. Das bedeutet in der Regel, dass Google das angeforderte Gerät nicht finden kann. Das kann auch bedeuten, dass das Nutzerkonto nicht verknüpft ist oder eine ungültige agentUserId empfangen wurde. Achte darauf, dass agentUserId mit dem in deiner SYNC-Antwort angegebenen Wert übereinstimmt und dass du DISCONNECT-Intents richtig verarbeitest.
    • 429 Resource Exhausted: Ihre Integration hat das zugewiesene Kontingent überschritten. Eine Anleitung zur Kontingentverwaltung finden Sie oben im Dashboard im Abschnitt „Schritt 1“.

Gerätezustand – Genauigkeit des Status

Wenn Sie die Anforderung State Accuracy >= 99,5% erfüllen oder übertreffen, werden Nutzern korrekte Ergebnisse angezeigt, wenn sie sich Gerätestatus ansehen oder KI-Funktionen wie „Ask Home“ verwenden. Wenn die Genauigkeit des Status niedrig ist, werden Automatisierungen möglicherweise nicht ausgelöst und Verlaufsereignisse werden möglicherweise nicht rechtzeitig auf dem Tab „Aktivität“ von GHA angezeigt. Weitere Informationen finden Sie unter Berichtstatus.

Das Qualitäts-Dashboard verfolgt dies stündlich anhand von zwei verschiedenen Messwerten: Gesamtgenauigkeit und Kombination mit dem niedrigsten Typ/Attribut.

1. Genauigkeitskomponenten

Der Messwert wird aus Stichproben abgeleitet, bei denen Google den gemeldeten Status mit einem bekannten Ergebnis der Intention vergleichen kann.

2. Dashboardmesswerte (stündliche Berechnung)

Im Dashboard wird die Genauigkeit auf Grundlage eines 1-Stunden-Intervalls berechnet. Wenn eine Stunde weniger als 100 Gesamtstichproben (S_Total < 100) enthält, wird die Genauigkeit für diese Stunde auf N/A festgelegt.

Ansicht 1: Gesamte Genauigkeit (globaler Durchschnitt)

Dies ist die Gesamtgenauigkeit Ihrer Integration für alle Gerätetypen und Merkmale zusammen. Er gibt einen gewichteten Durchschnitt des Zustands Ihres gesamten Ökosystems an.

  • Berechnung: Gesamte Genauigkeit des Status auf allen Geräten / Gesamter Status auf allen Geräten.

Ansicht 2: Kombination aus niedrigstem Typ und niedrigster Eigenschaft

Hier wird die unzuverlässigste Kategorie in Ihrer Integration ermittelt. So wird verhindert, dass Geräte mit hohem Volumen und hoher Qualität Geräte mit niedrigem Volumen und niedriger Qualität verbergen. Wenn Sie beispielsweise eine große Anzahl von Lichtern mit einer Genauigkeit des Status von über 99,5% haben, aber nur wenige Schalter mit einer niedrigen Genauigkeit des Status, wird deutlich, dass die Schalter verbessert werden müssen.Dies würde bei einem Durchschnittswert möglicherweise nicht auffallen.

  • Berechnung: Mindestwert von „State Accuracy“ / „State Total“ für alle Kombinationen aus Attribut und Gerät.
Weiter
Cloud Monitoring