Analítica

A análise de IBM® watsonx™ Assistant fornece estatísticas de visão geral sobre o número de interações com usuários e taxas de restrição. As analíticas não acumulam estatísticas em regiões. Com uma topologia ativa / passiva, essa abordagem para análise é suficiente. No entanto, usar uma topologia ativa / ativa provavelmente requer que você use webhooks para reunir dados de interação e construir data warehouses customizados e relatórios para entender o uso total.

Histórico de sessão para chat web e API v2

O histórico de sessão permite que chats web mantenham o histórico de conversa e o contexto quando os usuários atualizam uma página ou mudam para uma página diferente no mesmo website. Esse recurso não funciona em instâncias, por isso conversas em andamento precisam ser reiniciadas.

faturamento

A IBM calcula sua conta com base na conta do IBM Cloud. O IBM® watsonx™ Assistant calcula as métricas médias mensais do usuário (MAU) agregando dentro de uma instância de serviço específica, conforme a seguir:

• A mesma MAU usada em dois recursos de assistente diferentes na mesma instância de serviço conta como uma MAU
• A mesma MAU usada em dois recursos de assistente diferentes em instâncias de serviço diferentes conta como duas MAUs

Para uma topologia ativa/ativa, no cenário de pior caso, a contagem MAU pode acabar sendo dobrada para um período de faturamento.

Monitoring

Os provedores de entroncamento SIP podem ser configurados para verificar ativamente o funcionamento dos controladores de borda de sessão (SBCs) do watsonx Assistant enviando mensagens periódicas de OPÇÕES SIP para cada zona dentro de uma região. Uma falha para receber uma resposta pode ser usada para fornecer notificação de uma falha para acionar um failover manual ou para automatizar a remoção da zona com falha da lista de rotas..

Recuperação de falhas

O provedor de entroncamento SIP desempenha um papel importante na detecção e gerenciamento de um failover, especialmente se um failover automático for esperado entre as regiões. Geralmente, os provedores de entroncamento SIP devem ser configurados para tratar cada zona em uma região como ativa / ativa e duas regiões em que um assistente é configurado como ativo / passivo. Os provedores de entroncamento SIP devem sempre ser configurados para equilibrar a carga e o failover entre as zonas em uma única região.

Indisponibilidade total

As falhas de integração telefônica têm dois tipos. O primeiro tipo é uma interrupção completa na qual os controladores de borda de sessão em todas as três zonas regionais ficam inacessíveis. Esse tipo de indisponibilidade é mais fácil de detectar e manipular porque o provedor de entroncamento SIP é imediatamente notificado por tempos limites SIP de que a chamada falha e pode ser configurada para failover automático ou o roteamento de chamadas pode ser reconfigurado manualmente no provedor de entroncamento SIP para direcionar o tráfego para fora da região com falha em direção à região de backup passivo.. Se um failover for automatizado e um backup regional for ativado, será sempre melhor tentar uma zona diferente primeiro e redirecionar o tráfego para a região de backup passivo somente se um número pré-configurado de falhas ocorrer em um curto período. Isso evitará um failover desnecessário entre as regiões no caso de uma pequena indisponibilidade.

IBM® watsonx™ Assistant fornece um nome completo do domínio (FQDN) round-robin que inclui os endereços IP para cada zona na região. Muitos provedores de entroncamento SIP tentam novamente cada IP automaticamente no FQDN quando ocorrem falhas. Para suportar a recuperação de desastre, o provedor de serviços pode precisar configurar dois troncos SIP separados, um para cada região e somente quando todas as zonas em uma única região falharem, a chamada deverá ser alternada para a região de backup. É importante configurar os tempos limite de falha do SIP INVITE no provedor de entroncamento SIP para um valor baixo o suficiente para evitar longas latências de configuração de chamada quando estiver acontecendo um failover.

Interrupção parcial

O segundo tipo de falha é uma indisponibilidade parcial do serviço dentro da região. Uma indisponibilidade parcial é muito mais difícil de detectar e gerenciar devido ao grande número de variações em falhas de serviço que podem ocorrer em uma região. Às vezes, pequenos problemas afetam as características de desempenho da chamada, mas não causam a falha da chamada.

Para problemas que, por fim, fazem com que uma chamada falhe, há duas maneiras de seu assistente manipular a chamada. O primeiro é aceitar a chamada e, em seguida, transferi-la para um URI do SIP padrão configurado. É possível configurar essa configuração na integração de telefone e também é usado para falhas de chamada intermediária (mid-call).... O URI SIP de destino de transferência padrão é definido no campo Destino SIP quando uma chamada falha que está na guia Avançado da configuração de integração de telefone.

A integração de telefone também pode ser configurada para responder a um SIP INVITE com uma mensagem SIP 500 (serviço indisponível) se uma indisponibilidade for detectada durante a configuração da chamada em vez de transferir uma chamada para um agente em tempo real. Um SIP 500 pode então ser usado para redirecionar a chamada para outra zona, ou, se muitos SIP 500s forem recebidos, para outra região. Usar um erro SIP 500 INVITE é a maneira melhor de sinalizar uma falha em um provedor de entroncamento SIP de envio de dados, pois permite ao provedor redirecionar a chamada. O uso apenas do destino de transferência padrão para manipular falhas de chamadas é aceitável para cenários de baixo volume de chamada, mas pode resultar em grandes números de chamadas que são direcionadas para uma central de contato do cliente quando volumes de chamadas maiores são manipulados por seu assistente Para ativar esse recurso de resposta de erro 500 para uma instância específica, é necessário fazer uma solicitação para IBM.

Você deve se planejar para as indisponibilidades total e parcial do serviço. Uma boa primeira etapa é planejar um failover manual entre as regiões antes de ativar a automação É necessária uma réplica completa do watsonx Assistant em ambas as regiões, incluindo todo o treinamento de modelo de fala customizado. Quando a automação é ativada, é melhor iniciar com uma estratégia para detectar e executar failover para a região de backup passivo quando uma indisponibilidade regional completa for detecta.. Após a implementação, desenvolva uma estratégia para lidar com interrupções parciais, que devem cobrir a maior parte das condições de falha que podem ocorrer com uma implementação de integração de telefone

Monitoring

O chat web fornece um recurso de atendimento onError que permite que a página do host detecte tipos específicos de erros de indisponibilidade, em especial erros INITIAL_CONFIG, OPEN_CONFIG e MESSAGE_COMMUNICATION.

Para obter mais informações, consulte Ouvindo Erros

Recuperação de falhas

Manipular um failover para o bate-papo da web é simples, supondo que você configure uma integração de bate-papo da web extra em outra região. Quando o failover precisar ser acionado manualmente, execute as mudanças a seguir:

• O script de integração que contém seu ID de integração, região, ID da instância de serviço e ID da assinatura (se aplicável) precisa ser mudado ou atualizado para usar os IDs para a nova integração e região.
• Se você estiver usando integrações Salesforce ou ZenDesk para conexão com agentes humanos, atualize a configuração dentro desses sistemas para ter certeza de que eles podem se comunicar com a integração correta. Siga as instruções na guia Agente em tempo real na configuração do chat web para definir esses sistemas. Esse recurso é necessário apenas para obter o histórico de conversação para o agente
• Se você ativar a segurança de bate-papo da web e estiver usando cargas úteis criptografadas, a chave pública fornecida pela IBMque é usada para a criptografia pode ser diferente, dependendo da região Nesse caso, será necessário atualizar o sistema que gera o JSON Web Token (JWT) para usar a chave correta.

É possível definir uma configuração ativa/ativa do chat web usando IDs de integração diferentes nos scripts integrados e assegurando que a integração do chat web seja "aderida" pelo usuário. Caso contrário, se o usuário falhar em relação a uma integração diferente, o histórico de conversa poderá ser perdido.

Monitoring

Capturar e monitorar códigos de resposta de chamadas do /message. Os códigos de resposta do tráfego ativo do /message devem ser capturados e agregados.

O ideal é salvar as estatísticas de código de resposta em um armazenamento de persistência externo. Esse armazenamento compartilhado pode agregar resultados de código de resposta de todas as instâncias implementadas de seu aplicativo e fornecer a maior fidelidade para determinar se um failover deve ser acionado..

Como alternativa, os códigos de resposta podem ser agregados e avaliados na memória para uma instância de seu aplicativo. Como apenas uma fração do tráfego está contribuindo para a decisão de failover, isso pode afetar a freqüência com que a decisão de failover age.

Com qualquer abordagem de agregação, exceder um limite definido pode acionar um failover. As abordagens comuns para determinar um failover incluem:

• Baseado em porcentagem: maior que X% das solicitações retornam um código de resposta non-200
• Baseado em consecutivos: X chamadas em uma linha retornam um código de resposta non-200
• Baseado em limite: chamadas X retornam uma resposta non-200 em um intervalo de tempo

Para evitar um failover desnecessário entre regiões, certifique-se de que um mecanismo de nova tentativa robusto esteja presente ao chamar o terminal /message.

Failover para APIs statelessv1 e v2

Para um failover bem-sucedido:

• As mudanças de dados de treinamento devem ser sincronizadas entre as regiões. Evite enviar por push mudanças atrasadas em uma grande janela de tempo (como dias) para minimizar o risco de mudanças de algoritmo que são implementadas pelo watsonx Assistant entre as regiões que estão sendo atualizadas.
• A mesma conta da IBM Cloud deve ser usada para as instâncias de serviço em todas as regiões para manter uma fatura geral única para os serviços.
• Os aplicativos clientes devem suportar:
  • IBM® watsonx™ Assistant Nome do host da API
  • Credenciais de instância de serviço
  • v1: workspace_id
  • v2: assistant_id

Embora isso não afete o fluxo de tempo de execução de chamar /message, se você estiver usando o controle de acesso de baixa granularidade que usa o IBM Identity and Access Management (IAM), certifique-se de que as políticas do IAM sejam sincronizadas nas regiões.  O IAM é um serviço global, mas os recursos customizados (assistentes e qualificações) usados pelo controle de acesso do watsonx Assistant significam que cada região, que possui recursos específicos, requer políticas específicas.

Para uma topologia ativa/passiva, algumas formas de padrão de disjuntor podem ser usadas. Uma única instância de serviço em uma região é usada exclusivamente, a menos que erros sejam detectadosNesse ponto, o sistema pode responder atualizando os metadados de failover relevantes para rotear o tráfego para a instância de serviço na outra região. Quando um failover acontece, é possível decidir continuar usando a nova região como a instância ativa ou se você deseja continuar usando a região inicial quando ela estabilizar.

Para uma topologia ativa/ativa, alguma forma de um balanceamento de carga pode ser usada, em que duas ou mais instâncias de serviço em regiões diferentes sempre recebem uma porcentagem de tráfego Lógica extra precisaria ser estabelecida para determinar quando puxar uma região fora de rotação. Essa lógica de monitoramento pode usar um padrão de interrupção de circuito semelhante à configuração ativa / passiva, ou depender de uma estrutura de monitoramento dedicada separada que determina o funcionamento da região Semelhante ao ativo / passivo, determinar quando inserir uma região de volta em rotação também precisaria ser considerado.

Failover para API stateful v2

O failover para a API stateful v2 é semelhante ao da stateless, mas estes detalhes devem ser considerados:

• O estado de uma conversa é persistido pelo watsonx Assistant em um banco de dados que está ligado a uma região específica. Como tal, um failover para o stateful v2 /message pode ser mais disruptivo..
• Para uma topologia ativa/passiva, assume-ser que todas as conversas em andamento estejam encerradas.
• Para uma topologia ativa/ativa, dadas as restrições de persistência bloqueadas por região da arquitetura v2 stateful /message, todas as voltas (chamadas de API /message ) de uma conversa (sessão) devem ocorrer na mesma região.