Os balanceadores de carga de aplicações externos globais permitem-lhe personalizar as suas próprias respostas de erro quando é gerado um código de estado de erro HTTP (4xx e 5xx). Pode personalizar as respostas de erro para erros gerados pelo equilibrador de carga e pelas instâncias de back-end. Também pode personalizar as respostas de erro para códigos de resposta de erro gerados quando o tráfego é recusado pelo Google Cloud Armor.
Segue-se um exemplo de uma página de erro personalizada onde pode configurar respostas de erro para a sua aplicação de consumo voltada para o exterior com a sua própria imagem corporativa e logótipo, links para páginas relacionadas e mensagens personalizadas.
Ao usar uma política de resposta de erro personalizada, pode configurar diferentes respostas de erro para diferentes códigos de estado de erro HTTP, domínios de URL, caminhos de URL e campos de parâmetros e cabeçalhos de pedidos HTTP.
A devolução de respostas de erro personalizadas ajuda a melhorar a experiência dos seus utilizadores, oferecendo as seguintes vantagens:
- Oferece uma experiência de branding consistente
- Fornece informações contextuais e relevantes para melhorar a usabilidade e a experiência do utilizador
- Mitiga o impacto negativo do tempo de inatividade e dos erros do lado do cliente
- Melhora a segurança da rede
Se não configurar uma política de resposta de erro personalizada, é publicado um objeto de erro genérico sem marca, conforme mostrado na figura 2.
Exemplos de utilização
A funcionalidade de resposta de erro personalizada aborda muitos exemplos de utilização. Esta secção apresenta alguns exemplos de nível elevado.
Defina a sua própria página de manutenção
Pode devolver uma página de erro com o branding e as informações da empresa quando os seus back-ends não estiverem em bom estado ou estiverem em modo de manutenção. Pode criar páginas de erro contextuais que contenham informações úteis, como números de telefone do centro de contacto ou quando os utilizadores devem tentar aceder novamente ao Website. Tem a opção de personalizar as páginas de erro com base na correspondência das condições de erro, como o nome do anfitrião e o código de erro HTTP.
Defina a sua própria página de erro predefinida
Pode configurar respostas de erro personalizadas por códigos de erro específicos. Por exemplo, pode configurar uma página de erro com a mensagem "Iniciar sessão ou registar-se" para um código de resposta HTTP 401 (Unauthorized). Também pode configurar uma página de erro predefinida que contenha o branding da empresa e outras informações relevantes para todos os outros códigos de erro HTTP da série 4xx e da série 5xx.
Defina respostas de erro para regras de segurança
Pode devolver uma página de erro personalizada para códigos de resposta de erro gerados quando o tráfego é recusado pelas políticas de segurança do Cloud Armor. Tem de garantir que configura a página de erro com a mesma série 4xx ou série 5xx do código de erro HTTP que introduziu na regra de segurança do Cloud Armor.
Mitigue o impacto do tempo de inatividade
Quando aplicável, pode configurar uma resposta de erro para devolver um código de estado HTTP 200 (OK) e publicar uma página Web estática para que os utilizadores vejam informações mais contextuais e úteis em vez de uma página de erro durante o tempo de inatividade.
Personalize as respostas de erro com base no tipo de pedido do cliente
Pode personalizar uma resposta de erro com base nos cabeçalhos do pedido HTTP e nos
parâmetros, por
exemplo, o cabeçalho Content-Type. Ao encaminhar o pedido original para o serviço de erros, o encaminhamento pode ter em conta o cabeçalho Content-Type para publicar uma página Web (para pedidos de navegadores) ou JSON (para pedidos de uma API Web).
Como funcionam as políticas de resposta de erro personalizadas
Pode definir uma política de resposta de erro personalizada em três níveis do recurso de mapa de URLs: 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 equilibrador de carga.
Nível do domínio do URL. A política é aplicada ao tráfego direcionado para um nome de domínio ou um nome de anfitrião específico, por exemplo,
www.example.com.Nível do caminho de URL. A política é aplicada ao tráfego direcionado para um caminho específico, por exemplo,
www.example.com/images/*. Neste nível, também pode usar condições de correspondência avançadas com cabeçalhos de pedidos HTTP e parâmetros, por exemplo,Content-Type:application/json.
A tabela seguinte mostra uma política de resposta de erro personalizada aplicada ao nível do balanceador de carga, ao nível do domínio do URL e ao nível do caminho do URL do mapa de URLs.
| Nível da política | Campo da API |
|---|---|
| Balanceador de carga | urlMaps.defaultCustomErrorResponsePolicy |
| Domínio do URL | pathMatchers[].defaultCustomErrorResponsePolicy |
| Caminho de URL |
|
Se configurar uma política de resposta de erro personalizada em vários níveis do recurso de mapa de URLs, é devolvido o objeto de erro especificado pela política de erro personalizada no nível mais baixo do mapa de URLs. As políticas de resposta de erro definidas a um nível inferior do mapa de URLs são mais específicas e têm precedência sobre as políticas de resposta de erro definidas a um nível superior do mapa de URLs.
Por exemplo, uma política de resposta de erro personalizada ao nível do equilibrador de carga só é aplicada se a política corresponder às condições de erro e não tiver sido definida nenhuma política correspondente para o código de erro nos níveis inferiores: o domínio do URL ou o caminho do URL. Da mesma forma, uma política de resposta de erro personalizada ao nível do domínio do URL só é aplicada se a política corresponder às condições de erro e não tiver sido definida nenhuma política correspondente para o código de erro no nível inferior, ou seja, o caminho do URL. Para saber mais acerca desta configuração, consulte o artigo Configure políticas de resposta de erro personalizadas detalhadas para diferentes domínios, caminhos e códigos de resposta de erro.
Especifique várias regras de resposta de erro para corresponder a códigos de resposta de erro HTTP
Em qualquer nível numa política de resposta de erro personalizada, pode especificar várias regras de resposta de erro. Estas regras podem corresponder a uma resposta de erro HTTP com códigos de erro específicos ou um intervalo de códigos de erro. Se 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 têm precedência.
Por exemplo, suponha que configura 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 devolver um código de erro 401, é aplicada a regra que corresponde ao erro 401. No entanto, se o serviço de back-end devolver um código de erro 403, a regra para erros 4xx entra em vigor.
Substitua o código de resposta HTTP
As regras de resposta de erro permitem-lhe modificar o código de resposta HTTP devolvido pelo balanceador de carga. Isto significa essencialmente que pode substituir o código de resposta gerado pelo servidor e definir qual deve ser o código de resposta final para o pedido. Pode especificar a devolução de qualquer código de resposta HTTP, incluindo 200 (OK), a série 4xx ou a série 5xx de códigos de resposta, ou qualquer outro código de resposta de três dígitos. Para saber como substituir o código de resposta, consulte o artigo Configure uma página de erro para um código de erro específico para um anfitrião específico.
Se definir um código de resposta de substituição, este é capturado como um novo campo
overrideResponseCodeServed nos registos de equilíbrio de carga. Este campo
é preenchido apenas para os pedidos em que é aplicado um código de resposta de substituição
pela política de resposta de erro personalizada.
O código status registado no campo httpRequest
não é afetado.
Captura o código de resposta HTTP gerado pelo servidor ou a resposta HTTP devolvida pelo balanceador de carga. Este código de estado pode ser diferente do código real publicado para o cliente se o código de resposta for modificado por uma política de resposta de erro personalizada.
Coloque em cache respostas de erro personalizadas
É possível colocar em cache uma resposta de erro personalizada especificando uma política de colocação em cache negativa para o back-end que gerou o erro. O motivo para o fazer é aplicar um controlo detalhado sobre o armazenamento em cache para erros ou redirecionamentos comuns. Isto pode reduzir a carga nas suas origens e melhorar a experiência do utilizador final, reduzindo a latência de resposta.
Uma política de colocação em cache negativa definida para o back-end que gerou o erro tem sempre precedência sobre os metadados Cache-Control definidos para o objeto de erro no serviço de erros. Além disso, se o código de resposta de substituição for devolvido pelo equilibrador de carga, é aplicada uma política de colocação em cache negativa com base no valor do código de resposta de substituição e não com base no código de resposta original que o back-end devolveu ao equilibrador de carga. Se for devolvido um código sem erro (HTTP 200) como um código de resposta de substituição, não é aplicada uma política de colocação em cache negativa.
Se o tempo de vida (TTL) da resposta de falha não tiver expirado, o balanceador de carga continua a publicar conteúdo em cache sem encaminhar o pedido para um serviço de back-end ou um contentor de back-end. No entanto, este comportamento depende de o Cloud CDN estar ativado para o seu balanceador de carga.
O Cloud CDN está ativado para o balanceador de carga
Esta secção descreve o comportamento do balanceador de carga quando o Cloud CDN está ativado e são usadas respostas de erro personalizadas.
Quando um pedido é recebido pelo equilibrador de carga, este verifica a cache da RFC do Cloud CDN. Se o equilibrador de carga encontrar uma resposta em cache ao pedido do utilizador, o equilibrador de carga devolve a resposta em cache ao utilizador. Esta resposta em cache pode ser o conteúdo pedido pelo utilizador ou um objeto de erro personalizado.
Se houver uma cache em falta, o pedido é processado pelo equilibrador de carga e enviado para o back-end.
Se o back-end fornecer uma resposta sem erros, essa resposta é devolvida ao utilizador final. No entanto, se um pedido do cliente encontrar um erro (um código de resposta HTTP
4xxou5xx), o balanceador de carga tenta obter o objeto de erro personalizado do serviço de erro que especificou da seguinte forma:O balanceador de carga verifica todas as políticas de resposta de erro personalizadas e obtém o caminho adequado do objeto de erro personalizado que corresponde ao código de estado de erro e a outras condições de correspondência.
O equilibrador de carga encaminha o pedido do objeto de erro personalizado para o serviço de erros que especificou na política de resposta de erro personalizada. O termo serviço de erro refere-se ao contentor de back-end ou ao serviço de back-end que serve o conteúdo de erro personalizado.
O equilibrador de carga devolve o objeto de erro personalizado ao cliente que fez o pedido. Também envia o objeto para o Cloud CDN para colocar em cache o objeto de erro durante o período especificado por
cdnPolicy.negativeCachingPolicy[].ttl.
O Cloud CDN está desativado para o balanceador de carga
Se o Cloud CDN estiver desativado, recomendamos a utilização de um contentor de back-end como o serviço de erro e não um serviço de back-end. Isto deve-se ao facto de um serviço de back-end não poder colocar conteúdo em cache se o Cloud CDN estiver desativado. No entanto, os contentores de back-end têm uma capacidade de colocação em cache incorporada e podem colocar em cache respostas de erro, mesmo que o Cloud CDN esteja desativado.
Limitações
As respostas de erro personalizadas só são suportadas com o Application Load Balancer externo global. Os modos regional e clássico não são suportados.
Se não for possível obter o objeto de erro personalizado do serviço de erros, por exemplo, se o caminho do conteúdo estiver configurado incorretamente, é publicado um objeto de erro genérico sem marca.
A política de resposta de erro personalizada não monitoriza nem filtra o objeto devolvido pelo serviço de erro para verificar a existência de riscos de segurança. Assim, deve ser diligente na eliminação de vulnerabilidades e na limitação do impacto de uma potencial exposição.
As respostas de erro personalizadas só são suportadas em contentores do Cloud Storage legíveis publicamente.
Para evitar configurações incorretas ao usar um contentor do Cloud Storage, reveja as práticas recomendadas para o Cloud Storage.
As respostas de erro personalizadas não funcionam se o equilibrador de carga de aplicações externo global tiver apenas contentores de back-end. Tem de ter, pelo menos, um serviço de back-end também associado ao balanceador de carga, além do contentor de back-end.
Todos os cabeçalhos de resposta personalizados definidos com base na origem da resposta de erro personalizada não são aplicados às respostas de saída.
A política de resposta de erro personalizada aplica-se apenas a respostas HTTP que, na realidade, provêm dos back-ends. Se a resposta vier do front-end da Google (GFE), pode ver outros códigos de resposta HTTP inesperados.
As respostas de erro personalizadas são incompatíveis com os seguintes tipos de pedidos:
- Pedidos com corpos que acionam uma política de injeção de falhas.
- Pedidos grandes em que o serviço de back-end envia uma resposta antes de ler completamente o corpo.
- Pedidos que incluem um cabeçalho
Authorization. Se um pedido incluir um cabeçalhoAuthorization, o armazenamento na nuvem devolve uma respostaAuthentication Required.
Preços
Não existe um custo adicional para usar respostas de erro personalizadas. Aplica-se o preço padrão para o Google Cloud balanceamento de carga. Para mais informações, consulte a secção Preços.