Esse conjunto de painéis e alertas ajuda você a manter de forma proativa uma integração de alta qualidade com o ecossistema do Google Home. O Google tem o compromisso de ajudar os parceiros a desenvolver um ecossistema de alta qualidade para todos os clientes.
O painel tem três seções, cada uma abrangendo uma parte essencial que contribui para a qualidade de uma integração geral.
Métricas do Google para o parceiro : mede a integridade das chamadas do Google para o back-end da nuvem.
Integridade do sistema: métricas do parceiro para o Google : mede a integridade das chamadas do seu sistema para o Google.
Integridade do dispositivo: precisão do estado : mede a precisão dos estados armazenados nos sistemas do Google, que são usados para atender às consultas do usuário.
Quando as métricas não atendem aos valores de destino, elas são destacadas em vermelho para indicar um problema que pode afetar a experiência do usuário. As informações a seguir fornecem detalhes sobre cada meta e por que ela é importante para os usuários.
Se o botão a seguir não levar você diretamente ao painel, selecione a página Visão geral e Painéis. Em seguida, na lista Meus painéis , selecione Painel do Google Home Vitals (nuvem) para acessar o painel.
Métricas do Google para o parceiro
A métrica Taxa de sucesso da consulta/execução >= 99,5% mede a frequência com que os comandos dos usuários são atendidos corretamente, o que ajuda a evitar respostas do Google Assistente, como "Não consigo acessar o dispositivo" ou a confirmação incorreta de um comando que não foi atendido.
O que define um "sucesso"?
Uma transação é marcada como bem-sucedida se a plataforma Google Home receber uma resposta válida indicando que a ação pretendida foi concluída ou que o estado solicitado foi recuperado.
As respostas que incluem exceções sem bloqueio (por exemplo, um status SUCCESS acompanhado de uma exceção lowBattery) são contadas como transações bem-sucedidas.
O comando chegou ao dispositivo e a intent foi atendida, apesar do aviso.
O que define uma "falha"?
Os erros encontrados em Códigos de erro comuns da plataforma que são marcados como Ação do parceiro necessária são considerados "falhas" ao calcular as taxas de sucesso de CONSULTA e EXECUÇÃO. Além disso, os erros encontrados em Erros e exceções também são "falhas", com as seguintes exceções:
| Exceções de falha | ||
|---|---|---|
| aboveMaximumLightEffectsDuration | armLevelNeeded | inOffMode |
| alreadyArmed | bagFull | lockedToRange |
| alreadyAtMax | belowMinimumLightEffectsDuration | lowBattery |
| alreadyAtMin | binFull | maxSpeedReached |
| alreadyClosed | cancelArmingRestricted | minSpeedReached |
| alreadyDisarmed | deadBattery | notSupported |
| alreadyDocked | degreesOutOfRange | offline |
| 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 |
A métrica Latência da consulta/execução (p90) <= 1.000 ms mede o tempo de espera da ação solicitada e ajuda a garantir que os usuários não precisem esperar muito tempo, por exemplo, alguns segundos para que a luz se apague.
Métricas de latência
A latência é um indicador essencial de como a integração é responsiva para o usuário final. O painel acompanha a latência do percentil 90 (P90), que representa a experiência dos usuários "mais lentos" (por exemplo, um P90 de 800 ms significa que 90% das solicitações são reconhecidas em 800 ms ou menos).
O Google mede a latência de maneira diferente para verificações de status e comandos de dispositivos para garantir a precisão técnica.
1. Latência da CONSULTA (interrogativa)
Isso mede o tempo de ida e volta Cloud-to-cloud quando o Google pede o estado atual de um dispositivo.
- Início: o Google envia uma solicitação
action.devices.QUERYpara o URL de fulfillment. - Janela de medição: o tempo necessário para que a nuvem receba, processe e transmita a resposta HTTP completa de volta ao Google.
- Fim: o Google recebe e reconhece o payload de resposta final do seu serviço.
2. Latência da EXECUÇÃO (ação)
Isso mede o tempo de reconhecimento do comando quando o Google envia uma solicitação de controle para um dispositivo.
- Início: o Google envia uma solicitação
action.devices.EXECUTEpara o URL de fulfillment. - Janela de medição: o tempo necessário para que a nuvem receba o comando e retorne uma resposta de reconhecimento.
- Fim: o Google recebe a resposta de status
SUCCESS,PENDINGouOFFLINE. - Escopo técnico: essa métrica mede o tempo de "reconhecimento de resposta" entre a nuvem do Google e a sua. Ela não mede o tempo necessário para que o hardware físico (por exemplo, uma lâmpada) conclua a mudança de estado físico, já que isso geralmente envolve a latência da rede de malha local fora do caminho da nuvem para a nuvem.
Opções de redução de latência
Recomendações arquitetônicas para georroteamento
Se a implementação de IP Anycast não for viável, recomendamos as seguintes alternativas econômicas para garantir que os usuários sejam atendidos pelo data center regional mais próximo.
Balanceamento de carga global (GLB, na sigla em inglês)
Em vez de roteamento estático, use um balanceador de carga de aplicativo global (disponível na maioria dos principais provedores de nuvem).
Como funciona:você configura um único ponto de entrada global (URL) que fica na borda da rede. O balanceador de carga detecta automaticamente a origem geográfica da solicitação dos clusters de fulfillment do Google e roteia o tráfego para o back-end regional íntegro mais próximo.
Benefício:isso oferece o desempenho do Anycast com complexidade e custo de configuração significativamente menores.
DNS com reconhecimento de localização geográfica (GeoDNS, na sigla em inglês)
Como funciona:configure o provedor de DNS para resolver o URL de fulfillment em diferentes endereços IP com base na localização geográfica da consulta de DNS.
Implementação:verifique se o provedor de DNS está otimizado para os pontos de saída do Google. Quando os serviços de atendimento regionais do Google (por exemplo, nos EUA, na UE ou na Ásia) resolvem seu domínio, eles recebem o endereço IP do data center nessa região específica.
Estratégias de otimização na camada de aplicativo
Além do roteamento no nível da infraestrutura, você pode implementar as seguintes estratégias na camada de aplicativo para reduzir a latência no processamento de solicitações.
Método de proxy "Trampolim"
Se você precisar manter um data center principal, use servidores proxy regionais leves (Trampolins) para lidar com o handshake inicial.
O Google acessa seu URL global.
Um proxy regional (por exemplo, uma função Nginx ou Lambda leve) recebe a solicitação.
O proxy encaminha o payload pela rede de alta velocidade interna para o banco de dados principal.
Benefício:isso reduz o tempo de "handshake TCP", que geralmente é o maior contribuinte para a latência de solicitações de longa distância.
Dicas de região do token de acesso
Durante o processo de vinculação de contas (OAuth), seu sistema pode identificar a região de origem do usuário.
Implementação:codifique um identificador de região no
access_tokenemitido para o Google. Quando o Google envia uma solicitação de fulfillment, seu gateway pode inspecionar imediatamente o token e rotear a solicitação para o cluster regional correto sem precisar de uma pesquisa no banco de dados.
Integridade do sistema: métricas do parceiro para o Google
Manter uma taxa de sucesso >= 99, 5% ajuda a garantir que os estados do dispositivo estejam corretos no Google Home, que os dispositivos sejam adicionados e removidos, que as automações sejam acionadas e que os eventos de histórico apareçam na guia "Atividade" do Google Home app (GHA).
A taxa de sucesso é calculada com base nos códigos de resposta HTTP retornados pelo Google quando a nuvem envia atualizações de estado. Para garantir que os parceiros não sejam penalizados por problemas de infraestrutura do Google, a métrica exclui erros internos do Google da contagem de falhas. As chamadas de API incluídas no cálculo são encontradas na referência da API HomeGraph.
O que define um "sucesso"?
- 2xx (sucesso): a atualização de estado foi recebida e processada pelo Home Graph.
O que define uma "falha"?
- 4xx (erro do parceiro): representam falhas e indicam um problema com a solicitação enviada da sua nuvem. Os códigos comuns incluem:
- 400 Solicitação inválida: o servidor não conseguiu processar a solicitação devido a uma sintaxe inválida. As causas comuns incluem JSON malformado ou o uso de nulo em vez de "" para um valor de string.
- 404 Não encontrado: o recurso solicitado não foi encontrado. Normalmente, isso significa que o Google não consegue encontrar o dispositivo solicitado. Também pode significar que a conta de usuário não está vinculada ou que um
agentUserIdinválido foi recebido. Verifique se oagentUserIdcorresponde ao valor fornecido na resposta SYNC e se você está processando intentsDISCONNECTcorretamente. - 429 Recurso esgotado: sua integração excedeu a cota alocada. Consulte as instruções na seção "Etapa 1" mais acima no painel para gerenciamento de cotas.
Integridade do dispositivo: precisão do estado
Atender ou exceder uma acurácia de estado >= 99,5% ajuda a garantir que os usuários vejam resultados corretos ao visualizar os estados do dispositivo ou usar recursos de IA, como o Pergunte ao Home. Se a precisão do estado for baixa, as automações poderão não ser acionadas e as entradas de histórico poderão não aparecer na guia "Atividade" do GHA no momento certo. Para mais informações, consulte Informar estado.
O painel de qualidade acompanha isso a cada hora usando duas métricas distintas: Precisão geral e a Combinação de tipo/característica mais baixa.
1. Componentes de precisão
A métrica é derivada de "amostras" em que o Google pode verificar o estado informado em relação a um resultado de intent conhecido.
2. Métricas do painel (cálculo por hora)
O painel calcula a precisão com base em um intervalo de 1 hora. Se uma hora tiver menos de 100 amostras totais (S_Total < 100), a precisão para essa hora será definida como N/D.
Visualização 1: precisão geral (média global)
Isso representa a precisão total da integração em todos os tipos e características de dispositivos combinados. Ela fornece uma média ponderada da integridade de todo o ecossistema.
- Cálculo: acurácia total do estado em todos os dispositivos / total do estado em todos os dispositivos.
Visualização 2: combinação de tipo/característica mais baixa
Isso identifica a categoria específica menos confiável na integração. Ela impede que dispositivos de alto volume e alta qualidade ocultem dispositivos de baixo volume e baixa qualidade. Por exemplo, se você tiver um grande volume de iluminação acima de 99,5% de acurácia de estado, mas um volume baixo de chaves com baixa acurácia de estado, isso destaca a melhoria necessária nas chaves que podem ser perdidas em um valor médio.
- Cálculo: mínimo de acurácia de estado / total de estado para todas as combinações de trait/dispositivo.