Os balanceadores de carga de aplicativo externos globais permitem
personalizar suas próprias respostas de erro quando um código de status de erro HTTP (4xx e
5xx) é gerado. É possível personalizar respostas de erro para erros gerados pelo
balanceador de carga e pelas instâncias de back-end. Também é possível personalizar respostas
de erro para códigos de resposta de erro gerados quando o tráfego é negado pelo
Google Cloud Armor.
Veja um exemplo de uma página de erro personalizada em que é possível configurar respostas de erro para seu aplicativo de consumidor voltado para fora com o branding e o logotipo da sua própria empresa, links para páginas relacionadas e mensagens personalizadas.
Ao usar uma política de resposta de erro personalizada, é possível configurar respostas de erro diferentes para códigos de status de erro HTTP, domínios de URL, caminhos de URL e campos de parâmetro e cabeçalho de solicitação HTTP diferentes.
Retornar respostas de erro personalizadas ajuda a melhorar a experiência dos usuários, oferecendo os seguintes benefícios:
- Proporciona uma experiência de marca consistente
- Fornece informações contextuais e relevantes para melhorar a usabilidade e a experiência do usuário
- Reduz o impacto negativo da inatividade e erros no lado do cliente
- Melhora a segurança da rede
Se você não configurar uma política de resposta de erro personalizada, um objeto de erro genérico sem marca será exibido, conforme mostrado na Figura 2.
Casos de uso
O recurso personalizado de resposta de erro atende a muitos casos de uso. Nesta seção, veremos alguns exemplos gerais.
Definir sua própria página de manutenção
É possível retornar uma página de erro com o branding e as informações da empresa quando seus back-ends não estiverem íntegros ou no modo de manutenção. É possível criar páginas de erro contextuais que contenham informações úteis, como números de telefone da central de atendimento ou quando os usuários precisam tentar acessar o site novamente. Você tem a opção de personalizar páginas de erro com base na correspondência de condições de erro, como nome do host e código do erro HTTP.
Definir sua própria página de erro padrão
É possível configurar respostas de erro personalizadas por códigos de erro específicos. Por
exemplo, você pode configurar uma página de erro com uma mensagem "Fazer login ou registro"
para um código de resposta HTTP 401 (Unauthorized). Também é possível configurar uma página de erro
padrão que contenha o branding da empresa e outras informações relevantes sobre todos os outros
códigos de erro HTTP das séries 4xx e 5xx.
Definir respostas de erro para regras de segurança
É possível retornar uma página de erro personalizada para os códigos de resposta de erro gerados
quando o tráfego é negado pelas políticas de segurança do Google Cloud Armor. Você precisa
configurar a página de erro com o mesmo código de erro HTTP da série 4xx ou 5xx
que você inseriu na regra de segurança do Google Cloud Armor.
Reduzir o impacto da inatividade
Quando aplicável, é possível configurar uma resposta de erro para retornar um código de status HTTP 200 (OK)
e exibir uma página da Web estática para que os usuários vejam mais informações contextuais e
úteis em vez de uma página de erro durante o tempo de inatividade.
Personalizar respostas de erro com base no tipo de solicitação do cliente
É possível personalizar uma resposta de erro com base em cabeçalhos e parâmetros de solicitação HTTP, por exemplo, o cabeçalho Content-Type. Ao rotear a solicitação original para o
serviço de erro, o roteamento pode considerar o cabeçalho Content-Type para
exibir uma página da Web (para solicitações de navegadores) ou JSON (para solicitações
de um API da Web).
Como funcionam as políticas personalizadas de resposta de erro
Uma política personalizada de resposta de erro pode ser definida em três níveis do recurso de mapa de URL: o nível do balanceador de carga, o nível do domínio do URL e o nível do caminho do URL.
Nível do balanceador de carga. A política é aplicada a todo o tráfego recebido pelo balanceador de carga.
Nível do domínio do URL. A política é aplicada ao tráfego direcionado a um nome de domínio ou nome de host específico, por exemplo,
www.example.com.Nível do caminho do URL. A política é aplicada ao tráfego direcionado a um caminho específico, por exemplo,
www.example.com/images/*. Nesse nível, também é possível usar condições de correspondência avançadas com cabeçalhos e parâmetros de solicitação HTTP, por exemplo,Content-Type:application/json.
A tabela a seguir mostra uma política personalizada de resposta de erro aplicada no nível do balanceador de carga, do domínio do URL e do caminho do URL do mapa de URL.
| Nível da política | Campo da API |
|---|---|
| Balanceador de carga | urlMaps.defaultCustomErrorResponsePolicy |
| Domínio do URL | pathMatchers[].defaultCustomErrorResponsePolicy |
| Caminho do URL |
|
Se você configurar uma política de resposta de erro personalizada em vários níveis do recurso de mapa de URL, o objeto de erro especificado pela política personalizada no menor nível do mapa de URL será retornado. As políticas de resposta de erro definidas em um nível inferior do mapa de URL são mais específicas e têm precedência sobre as políticas de resposta de erro definidas em um nível superior do mapa de URL.
Por exemplo, uma política de resposta de erro personalizada no nível do balanceador de carga será aplicada somente se a política corresponder às condições de erro e nenhuma política correspondente for definida para o código de erro nos níveis mais baixos (o domínio do URL ou Caminho do URL. Da mesma forma, uma política de resposta de erro personalizada no nível do domínio do URL será aplicada somente se a política corresponder às condições de erro e nenhuma política correspondente for definida para o código de erro no nível inferior (o caminho do URL). Para saber mais sobre essa configuração, consulte Configurar políticas granulares de resposta de erro personalizada para diferentes domínios, caminhos e códigos de resposta de erro.
Especificar várias regras de resposta de erro para corresponder a códigos de resposta de erro HTTP
Em qualquer nível de uma política de resposta de erro personalizada, é possível especificar várias regras de resposta de erro. Essas regras podem corresponder uma resposta de erro HTTP a códigos de erro específicos ou a um intervalo de códigos de erro. Se você especificar uma regra para um intervalo de códigos de erro, bem como regras para códigos de erro específicos, as regras com códigos de erro específicos terão precedência.
Por exemplo, suponha que você configure uma regra para um código de erro
401 (Unauthorized) e outra regra para todos os códigos de erro da série 4xx. Se o serviço de back-end
retornar um código de erro 401, a regra que
corresponde ao erro 401 será aplicada. No entanto, se o serviço de back-end retornar um
código de erro 403, a regra para erros 4xx entrará em vigor.
Substitua o código de resposta HTTP
As regras de resposta de erro permitem modificar o código de resposta HTTP retornado pelo
balanceador de carga. Isso significa que você pode substituir o código de resposta
gerado pelo servidor e definir o código de resposta final da
solicitação. É possível especificar para retornar qualquer código de resposta HTTP, incluindo
200 (OK), as séries 4xx ou 5xx de códigos de resposta ou qualquer outro
código de resposta de três dígitos. Para saber mais sobre a substituição do código de resposta,
consulte Configurar uma página de erro para um código de erro específico de um host
específico.
Se você definir um código de resposta de substituição, ele será capturado como um novo campo
overrideResponseCodeServed nos registros de balanceamento de carga. Este campo
é preenchido apenas para as solicitações em que é aplicado um código de resposta de substituição
pela política de resposta de erro personalizada.
O código status registrado no campo httpRequest
não é afetado.
Ele captura o código de resposta HTTP gerado pelo servidor ou a resposta HTTP
que o balanceador de carga retorna. Esse código de status pode ser diferente do
código real fornecido ao cliente se o código de resposta for modificado por uma
política de resposta a erros.
Armazenar respostas de erro personalizadas em cache
Uma resposta de erro personalizada pode ser armazenada em cache especificando uma política de armazenamento em cache negativo para o back-end que gerou o erro. O motivo disso é aplicar um controle refinado sobre o armazenamento em cache para erros ou redirecionamentos comuns. Isso diminui a latência da resposta, o que possibilita reduzir a carga nas origens e melhorar a experiência do usuário final.
Uma política de armazenamento em cache negativo definida para o back-end que gerou o
erro sempre terá precedência sobre os metadados Cache-Control definidos para o
objeto de erro no serviço de erro. Além disso, se um código de resposta de substituição for
retornado pelo balanceador de carga, uma política de armazenamento em cache negativo é aplicada
com base no valor do código de resposta de substituição e não de acordo com o
código de resposta original retornado pelo back-end ao balanceador de carga. Se um erro
(HTTP 200) for retornado como um código de resposta de substituição, a política de armazenamento em cache negativo
não se aplica.
Se o time to live (TTL) da resposta de falha não tiver expirado, o balanceador de carga continua a disponibilizar conteúdo armazenado em cache sem rotear a solicitação para um serviço ou bucket de back-end. No entanto, esse comportamento depende se o Cloud CDN está ativado para seu balanceador de carga.
O Cloud CDN está ativado para o balanceador de carga
Nesta seção, descrevemos o comportamento do balanceador de carga quando o Cloud CDN está ativado e respostas de erro personalizadas são usadas.
Quando uma solicitação é recebida pelo balanceador de carga, ele verifica o cache do Cloud CDN. Se o balanceador de carga encontrar uma resposta à solicitação do usuário armazenada em cache, o balanceador de carga retorna a resposta armazenada em cache para o usuário. Essa resposta armazenada em cache pode ser o conteúdo solicitado pelo usuário ou um objeto de erro personalizado.
Se houver uma ausência no cache, a solicitação será processada pelo balanceador de carga e enviada para o back-end.
Se o back-end veicular uma resposta sem erro, essa resposta será retornada ao usuário final. No entanto, se uma solicitação do cliente encontrar um erro, (um código de resposta HTTP
4xxou5xx), o balanceador de carga tenta receber o objeto de erro personalizado do serviço de erro que foi especificado da seguinte maneira:O balanceador de carga verifica todas as políticas de resposta de erro personalizadas e recebe o caminho apropriado do objeto de erro personalizado que corresponde ao código de status de erro e outras condições de correspondência.
O balanceador de carga encaminha a solicitação do objeto de erro personalizado para o serviço de erros especificado na política de resposta de erro personalizada. O termo serviço de erro refere-se ao bucket ou serviço de back-end que exibe o conteúdo de erro personalizado.
O balanceador de carga retorna o objeto de erro personalizado ao cliente que fez a solicitação. Ele também envia o objeto ao Cloud CDN para armazenamento em cache do objeto de erro pelo tempo especificado pelo
cdnPolicy.negativeCachingPolicy[].ttl
O Cloud CDN está desativado para o balanceador de carga
Se o Cloud CDN estiver desativado, recomendamos o uso de um bucket de back-end como o serviço de erro e não um serviço de back-end. Isso ocorre porque um serviço de back-end não pode armazenar conteúdo em cache se o Cloud CDN estiver desativado. No entanto, os buckets de back-end têm recurso de armazenamento em cache integrado e podem armazenar respostas de erro em cache, mesmo que o Cloud CDN esteja desativado.
Limitações
Respostas de erro personalizadas são compatíveis apenas com o Balanceador de carga de aplicativo externo global. Os modos regional e clássico não são compatíveis.
Se não for possível buscar o objeto de erro personalizado no serviço de erro, por exemplo, se o caminho do conteúdo estiver configurado incorretamente, um objeto de erro genérico sem marca vai ser exibido.
A política de resposta de erro personalizada não monitora nem filtra o objeto retornado pelo serviço de erro em busca de riscos de segurança. Portanto, você precisa ser diligente para eliminar vulnerabilidades e limitar o impacto de uma possível exposição.
As respostas de erro personalizadas são compatíveis apenas com buckets do Cloud Storage legíveis publicamente.
Para evitar configurações incorretas ao usar um bucket do Cloud Storage, consulte as práticas recomendadas comuns do Cloud Storage.
As respostas de erro personalizadas não funcionam se o balanceador de carga de aplicativo externo global tiver apenas buckets de back-end. É necessário ter pelo menos um serviço de back-end também anexado ao balanceador de carga, além do bucket de back-end.
Os cabeçalhos de resposta personalizados definidos com base na origem da resposta de erro não são aplicados às respostas de saída.
Preços
Não há custo extra para usar respostas de erro personalizadas. Os preços padrão para o balanceamento de carga do Google Cloud são aplicáveis. Para saber mais informações, consulte Preços.